JNCDS-DC common mistakes
JNCDS-DC · Understand the traps and how to avoid them.
Designing an EVPN-VXLAN fabric by memorizing that 'spines are Layer 3 and leaves are Layer 2' without being able to justify where routing happens, where the default gateway lives, and how the underlay and overlay are separated when asked to draw a topology.
Candidates learn vendor reference topologies as slogans rather than as design trade-offs, so they can recall the label but not defend the placement of IRB interfaces, anycast gateways, or the underlay IGP when a scenario changes the requirements.
What to do instead
Practice producing a one-page design rationale for three fabric sizes (small, medium, large) that states explicitly: underlay protocol and its role, overlay control plane, where the distributed anycast gateway sits, and what changes if the customer wants Layer 2 extension to a legacy pod. Be able to explain why each choice was made, not just name it.
Treating 'collapsed core', 'spine-leaf', and 'super-spine' as interchangeable terms and failing to match the topology to stated scale, oversubscription, and east-west traffic requirements in a scenario question.
The vocabulary is familiar from marketing material, so candidates assume the terms are synonyms and skip the quantitative reasoning about port counts, rack density, and oversubscription ratios that the question is actually testing.
What to do instead
Build a simple sizing worksheet: number of racks, servers per rack, uplink speed, desired oversubscription ratio, and number of available spine ports. Work two or three examples by hand so you can compute whether a two-tier fabric suffices or a third tier is required, and be ready to state the oversubscription ratio implied by a given design.
Assuming a working underlay automatically means a working overlay, and troubleshooting EVPN problems by re-checking OSPF or BGP underlay adjacencies instead of verifying VXLAN tunnel endpoints, MAC learning, and EVPN route types.
Candidates conflate the two planes because both use BGP in many designs, and they lack a layered troubleshooting habit that separates underlay reachability from overlay control-plane and data-plane state.
What to do instead
Memorize the layered checklist: loopback-to-loopback reachability, VTEP source interface up, VXLAN UDP 4789 permitted, EVPN session established, Type 2 and Type 3 routes present, MAC address learned locally and remotely. Practice articulating which command output proves each layer before moving to the next.
Configuring a vPC or MC-LAG pair without being able to explain peer-link versus peer-keepalive roles, what happens during a peer-link failure, and why orphan ports and graceful consistency matter.
The configuration is often copied from templates, so candidates never internalize the failure semantics, and exam questions that probe split-brain behavior or Type 1 consistency checks expose the gap.
What to do instead
Study the state machine: what happens on peer-link down, what the secondary peer does to its vPC member ports, how the keepalive prevents dual-active, and which configuration mismatches trigger Type 1 consistency suspension. Draw the failure scenarios and predict forwarding behavior for each.
Designing an IP fabric underlay that relies on a single area or flat IGP without considering Summarization boundaries, and then being unable to answer questions about route scale, convergence, or BGP autonomous system numbering in the overlay.
Candidates focus on getting adjacencies up in a lab and never confront scale questions, so they miss the design reasoning about area design, ECMP hashing, BFD timers, and whether iBGP or eBGP is used for the EVPN overlay.
What to do instead
For each underlay choice (OSPF single area, OSPF multi-area, IS-IS, eBGP), write the trade-offs in terms of convergence, Summarization, operational complexity, and vendor support. Also decide and justify the overlay ASN plan, including why eBGP with distinct ASNs per leaf is often preferred for policy and troubleshooting.
Placing all Layer 3 gateways on a central firewall or core pair and stretching Layer 2 across the fabric, rather than using distributed anycast gateways, and then failing scenario questions that ask about traffic tromboning or firewall asymmetry.
Candidates carry over traditional campus or three-tier designs where gateways are centralized, and they do not connect that choice to the latency, hairpinning, and stateful-inspection problems it creates in a leaf-spine fabric.
What to do instead
Be able to explain anycast gateway mechanics: same IP and MAC on every leaf, local proxy ARP, and how a host's first-hop is always local. Then contrast with centralized gateway designs and articulate exactly which flows would traverse the firewall twice and why that breaks stateful inspection unless you design for it.
Treating security and services insertion as an afterthought, drawing a firewall or load balancer as a single box in the middle of the fabric without specifying whether it is inline, one-arm, or service-chained, and without saying how return traffic is steered.
Candidates separate 'network design' from 'security design' in their mental model, so they produce topologies that look clean but cannot answer how stateful devices see both directions of a flow or how asymmetric routing is avoided.
What to do instead
Practice three insertion patterns (inline bump-in-the-wire, one-arm with PBR or VRF leaking, and service chaining with a dedicated services leaf) and for each state the traffic path in both directions, the failure behavior if the appliance dies, and the scaling limit. Always state how return traffic reaches the same stateful device.
Answering segmentation questions by saying 'use VLANs' or 'use VRFs' without distinguishing tenant separation in the overlay from underlay segmentation, and without explaining route leaking between VRFs when shared services are required.
The terms are used loosely in documentation, so candidates blur the boundary between Layer 2 segments, Layer 3 VRFs, and EVPN tenant contexts, and they have never configured a controlled route leak between two VRFs.
What to do instead
Map the layers explicitly: VLAN to Layer 2 segment, VRF to Layer 3 tenant, EVPN VNI to the overlay instantiation of each. Then practice a shared-services design where a firewall VRF leaks specific prefixes into tenant VRFs, and be able to describe the route-target import and export policy that makes the leak selective rather than a full merge.
Describing automation as 'use Ansible' or 'use Python' without being able to say which data model, transport, and idempotency mechanism applies, or how configuration drift and rollback are handled.
Candidates memorize tool names from job listings instead of understanding the model-driven programmability stack, so they cannot answer questions that ask why NETCONF with YANG differs from screen-scraping CLI over SSH.
What to do instead
Learn the stack in layers: data model (YANG), encoding (XML or JSON), transport (NETCONF over SSH, RESTCONF over HTTPS), and tooling (Ansible modules, Python libraries, or a controller). For each, state whether it is idempotent, whether it supports candidate configuration and commit-rollback, and how you would detect and remediate drift.
Ignoring operational lifecycle questions such as upgrade strategy, configuration backup, monitoring telemetry, and change validation, and answering only the greenfield design portion of a scenario.
Candidates prepare for design and configuration tasks and treat operations as filler, but scenario questions often hinge on how a fabric is upgraded or how a failure is detected, which requires concrete knowledge of ISSU limits, telemetry options, and validation steps.
What to do instead
For a fabric you have designed, write a short runbook covering: pre-change backup and validation commands, upgrade order and whether hitless upgrade is actually supported for your protocols, telemetry streaming versus polling for fabric health, and the specific checks that confirm the change succeeded. Being able to narrate this runbook is what separates a passing scenario answer from a partial one.