Cisco DCID 300-610 common mistakes
Cisco DCID 300-610 · Understand the traps and how to avoid them.
When sizing a vPC domain, the candidate treats the peer-link as a normal data-forwarding link and omits the dedicated vPC peer-keepalive link, then cannot explain why a single-supervisor failure causes the secondary vPC to suspend its ports.
Candidates memorize 'vPC needs two links' but conflate the roles. The peer-link carries control-plane and orphan traffic and must not be used for keepalive; keepalive should traverse a separate Layer 3 path (management network or dedicated link) so that a peer-link failure does not also break keepalive and trigger a dual-active scenario. Without a separate keepalive path, the peer-link failure detection logic cannot distinguish a link failure from a device failure.
What to do instead
Draw the vPC control plane explicitly: peer-link on the dedicated port-channel, peer-keepalive on a routed link through a separate switch or direct link. State the failure behavior: peer-link down with keepalive up causes secondary vPC ports to be suspended while primary stays active; keepalive down with peer-link up keeps vPCs up but disables the peer-link failure protection. Verify with 'show vpc' and 'show vpc peer-keepalive'.
The candidate designs an OTV or VXLAN EVPN extension between data centers without specifying the underlay MTU and control-plane mapping, and then answers questions about broadcast containment or ARP suppression as if the overlay handled them automatically.
Overlay technologies are taught as feature lists. Candidates do not connect the requirement for an increased MTU on all underlay links (for VXLAN encapsulation) or the need to map VLANs to VNIs and configure ARP suppression at the edge. They also miss that OTV uses a dedicated overlay interface and join interface, and that the join interface must be reachable via the underlay IGP.
What to do instead
For every overlay design, write the underlay prerequisites as a checklist: jumbo MTU end to end, loopback reachability, PIM or ingress replication for BUM traffic, VLAN-to-VNI mapping, and ARP suppression scope. For OTV, list the join interface, overlay interface, and site VLAN/Site ID. Test the design by tracing a broadcast frame from an access port to the remote site.
When planning Cisco UCS B-Series or C-Series compute, the candidate sizes the fabric interconnect or Fabric Extender uplinks by counting only server-facing bandwidth and ignores oversubscription and the requirement for disjoint A/B fabric paths.
Candidates focus on the number of servers and their NICs, then divide total throughput by port count. They forget that each server must have at least one path to Fabric A and one to Fabric B, that mezzanine cards and VIC adapters present specific port counts per fabric, and that uplink oversubscription is calculated per fabric, not in aggregate. They also miss that disjoint fabrics mean no traffic should cross between A and B.
What to do instead
Build a per-fabric bandwidth table: server vNIC count per fabric, per-server bandwidth, total per fabric, then uplink port count and oversubscription ratio. Confirm that no vNIC is pinned to both fabrics and that the fabric interconnect uplinks are split evenly. For C-Series, verify the same with vPC or VPC domain pairs and separate northbound switches.
The candidate configures a UCS service profile with a boot policy that points to a SAN LUN but does not verify that the SAN boot LUN is zoned and masked to both fabric paths, and then cannot explain why the server boots only when one fabric is down.
Candidates treat SAN boot as a single-path configuration. They create one zone or one LUN mask and assume multipath will work. In reality, each vHBA has its own WWPN, each fabric has its own zone set, and the LUN must be masked to both initiator WWPNs with the same LUN ID. If one path is missing, the boot policy may still succeed on the surviving path, hiding the defect until a fabric outage.
What to do instead
For each service profile, list both vHBA WWPNs, the corresponding zones on each fabric, and the LUN masking entries. Use the UCS boot policy with a SAN boot target and verify with 'show boot' and multipath status in the OS. Test by disabling one fabric uplink and confirming the server still boots and sees both paths.
When designing a SAN for Cisco MDS or Nexus, the candidate picks ISL trunking or port-channel without considering the difference between Fibre Channel port-channel (SAN port-channel) and FCoE VFC interfaces, and misstates the domain ID and principal switch election rules.
Candidates learn that MDS uses VSANs and port-channels but do not separate the concepts: a SAN port-channel is a bundle of E-ports with a single domain ID, while a VFC is a virtual Fibre Channel interface bound to an Ethernet interface and a VSAN. They also confuse principal switch election (lowest WWN wins by default, priority can override) with domain ID assignment, and may not know that a port-channel requires compatible parameters on both ends.
What to do instead
Create a comparison table: ISL, SAN port-channel, FCoE VFC, NPV/NPIV. For each, state the interface type, the domain ID behavior, and the configuration prerequisites. For principal switch election, state the default rule and how priority changes it. Practice reading 'show fcdomain' and 'show port-channel database' outputs.
The candidate designs zoning with a single zone set and all initiators and targets in one zone, ignoring the recommendation for single-initiator-single-target zones and the need for a backup zone set.
Candidates equate zoning with access control lists and assume fewer zones are simpler. They do not consider that a single large zone allows any initiator to see any target, increasing the risk of accidental LUN access and making troubleshooting harder. They also forget that only one zone set can be active at a time and that a backup zone set is needed for change rollback.
What to do instead
Design zones as single-initiator to single-target (or single-initiator to multiple-targets only when required), with a naming convention that includes the host and array. Maintain an active zone set and a separate backup zone set, and document the activation procedure. Verify with 'show zoneset active' and 'show zone' on each VSAN.
When designing data center network services, the candidate places a firewall or load balancer in routed mode without defining the inside and outside VLANs, the default gateway, and the asymmetric routing behavior, and then cannot answer questions about return traffic.
Candidates understand that a firewall separates zones but do not model the Layer 2 and Layer 3 topology around it. They may put the firewall in transparent mode but still assign it an IP address, or put it in routed mode but leave the servers' default gateway on the core switch, creating asymmetric flows. They also miss that load balancers may need one-arm or two-arm designs depending on whether source NAT is used.
What to do instead
For each service device, draw the interfaces, VLANs, IP addresses, and default gateways. State whether the device is routed, transparent, or one-arm, and trace a client-to-server flow in both directions. For load balancers, state the VIP, pool members, and whether source NAT or direct server return is used. Verify with packet captures or 'show conn' on the firewall.
The candidate configures Cisco Application Centric Infrastructure (ACI) tenants and EPGs but does not map the bridge domain, VRF, and contract relationships correctly, leading to a design where an EPG cannot reach a shared service or where contracts are applied in the wrong direction.
Candidates treat ACI as a VLAN-based network and assume EPGs in the same bridge domain can communicate freely. In ACI, EPGs within the same bridge domain still require a contract unless intra-EPG isolation is disabled or a contract is provided. They also confuse the provider and consumer roles of a contract and apply a contract to the wrong EPG, or forget that a VRF is required for routed communication between bridge domains.
What to do instead
For each application, list the EPGs, their bridge domains, the VRFs, and the contracts with explicit provider and consumer EPGs. State whether the contract is unidirectional or bidirectional and whether a taboo contract is needed for isolation. Verify with 'show endpoint' and contract statistics, and test with a ping between EPGs in different bridge domains.
When designing infrastructure automation, the candidate writes a Cisco Intersight or Ansible playbook that assumes idempotency but does not handle API rate limits, authentication token expiry, or the difference between declarative and imperative modules, and then cannot explain why a rerun changes the configuration.
Candidates learn automation as scripting and do not consider the operational constraints of the platform. Intersight uses OAuth tokens with expiry and rate limits; Ansible modules may be imperative (each task makes a change) or declarative (desired state). Without handling these, a playbook may fail midway or repeatedly reconfigure devices. They also miss that some modules require a check mode or diff to be safe.
What to do instead
For each automation workflow, document the authentication method, token lifetime, rate limits, and whether the module is idempotent. Use check mode or dry-run first, and add error handling for token refresh and API throttling. For Intersight, use the SDK with token refresh; for Ansible, prefer declarative modules and use '--check' before applying. Verify by running the playbook twice and confirming no changes on the second run.
The candidate designs a data center with redundant power and cooling but does not calculate the power budget per rack or verify that the UPS and PDU topology matches the server's dual-power-supply requirement, and then cannot answer questions about fault tolerance during a PDU failure.
Candidates focus on the network and compute layers and treat physical infrastructure as a given. They do not calculate the actual power draw of the planned servers, switches, and storage, nor do they map each device's power supplies to separate PDUs on separate UPS feeds. As a result, a single PDU failure can take down both power supplies of a device if both are connected to the same PDU.
What to do instead
Build a rack elevation with power budgets: device, power supply count, watts per supply, PDU A and PDU B loading, and UPS capacity. Verify that each dual-corded device connects one supply to PDU A and one to PDU B, and that PDU A and PDU B are on separate UPS feeds. State the expected behavior during a PDU or UPS failure. Confirm with 'show environment' or the data center infrastructure management (DCIM) tool.