JNCIP-DC common mistakes
JNCIP-DC · Understand the traps and how to avoid them.
Assuming a single EVPN route type carries both MAC and IP reachability, then misreading show evpn database output when a host is silent on ARP.
Candidates memorize that Type 2 is 'the MAC route' and stop there, so they cannot explain why a local host appears in the MAC table but has no /32 or /128 host route, or why Type 5 prefixes appear only after a default route is configured.
What to do instead
Build a one-page route-type map: Type 1 Ethernet Auto-Discovery (aliasing, mass withdraw, split-horizon for multihoming), Type 2 MAC/IP (MAC-only, MAC+IP, IP-only for silent hosts), Type 3 Inclusive Multicast (BUM replication via ingress replication or PIM-SM), Type 4 Ethernet Segment (DF election), Type 5 IP Prefix (symmetric or asymmetric IRB). For each, note the exact show command and field that proves presence or absence, then practice correlating a missing host route with a missing MAC+IP advertisement rather than a routing failure.
Treating VXLAN VNI-to-VLAN mapping and the anycast gateway MAC as independent per-leaf settings and expecting them to match automatically across the fabric.
In a centrally routed or ERB design the VNI, VLAN ID, and anycast gateway MAC must be consistent on every leaf that hosts the same Layer 2 domain; labs built on one or two leaves never expose the mismatch, so candidates configure them ad hoc and are surprised when a VM migrated to another leaf loses its gateway.
What to do instead
Standardize a per-VLAN template: VLAN ID, VNI, anycast gateway IP and MAC, and route-target (target:1:VNI or target:ASN:VNI) derived from the same source of truth. Apply it identically on all leaves and spine-facing IRB interfaces, and verify with show ethernet-switching vxlan-tunnel-end-point remote and show interfaces irb that the gateway MAC is identical everywhere. In the exam, when a host loses gateway reachability after migration, check anycast MAC consistency before checking underlay routing.
Designing the underlay as a full mesh of EBGP sessions between every leaf and every spine but forgetting that the overlay's loopback peering depends on those loopbacks being advertised with the correct next-hop reachability.
Candidates focus on the EVPN overlay session state and assume 'underlay is up' once physical links are up, so they miss that the loopback /32 is not in the routing table, that BGP next-hop is unchanged, or that a route reflector is needed once the leaf count grows beyond a small lab.
What to do instead
Separate the two planes explicitly: underlay carries loopback /32s and p2p /31s with ECMP; overlay is a full mesh (or RR-based) of IBGP or EBGP sessions sourced from loopbacks carrying only EVPN. Verify with show route /32, show bgp summary for the overlay AFI, and show route table inet.0 for the remote VTEP. If route reflection is used, confirm the RR does not alter next-hop and that the client is configured as a client, not a peer.
Configuring multihoming (ESI-LAG) by setting an Ethernet Segment Identifier on the member links but leaving the DF election and split-horizon assumptions untested, then concluding the design is correct because the LAG came up.
An ESI-LAG comes up at Layer 2 even when the ESI is mismatched between peers or when the designated forwarder is not elected as expected, so link-state indicators give false confidence. Candidates rarely test BUM flooding from the access side or a single-member failure.
What to do instead
Validate in this order: ESI value identical on both peers, ES-Import route target matching, Type 1 and Type 4 routes present from both peers, DF election result per VLAN (show evpn ethernet-segment ... designated-forwarder), and BUM behavior with one member down. Confirm split-horizon prevents a frame from looping back to the originating peer. Practice a failover where the non-DF becomes DF and the LAG stays up.
Answering design questions about a collapsed spine-leaf versus a super-spine (3-stage versus 5-stage) fabric by quoting oversubscription ratios without stating the failure domain and control-plane scale implications.
Candidates treat oversubscription as the only design axis and forget that adding a super-spine layer changes BGP session count, route reflector placement, and blast radius; exam scenarios often hinge on those operational consequences rather than raw bandwidth.
What to do instead
For any topology question, answer along three axes: capacity (oversubscription per tier), control plane (session count, RR hierarchy, whether spines peer with each other), and failure domain (what a single spine or super-spine loss removes). State the numbers you assume and the scaling limit that forces the extra tier, such as leaf count exceeding what a single RR cluster should serve.
Treating a vPC or MC-LAG domain as automatically loop-free and placing a routed port-channel or Layer 3 link across the peer-link without checking the peer-link's role and STP behavior.
The peer-link carries control traffic and orphan handling, and misusing it for data forwarding or for routing adjacencies creates asymmetric paths and unexpected STP blocking that look like random packet loss in a lab.
What to do instead
Keep the peer-link dedicated to control and orphan traffic, never a transit path for routed traffic; verify with show vpc brief and show spanning-tree that the peer-link is not forwarding data VLANs unnecessarily. If a Layer 3 port-channel is required across peers, confirm it is not riding the peer-link and that routing adjacencies form over member links. In troubleshooting scenarios, check the peer-link first when you see intermittent loss between dual-homed hosts.
Assuming a firewall or service node inserted in the fabric is transparently steered by EVPN alone, without configuring the service insertion mechanism (PBR, service VRF, or a service leaf with policy) and the return path.
Candidates read 'service insertion' as an overlay feature that happens automatically once the firewall is attached, so they miss policy-based redirect on the client-facing leaf, the need for symmetric return, and the VRF or route-target plumbing that keeps stateful inspection in-path.
What to do instead
Design the path explicitly: classify traffic on the leaf, redirect to the service node's VTEP or interface with PBR or a service VRF, ensure the return traffic hits the same firewall instance (stateful symmetry), and verify with show policy-option and session tables on the firewall. Test both directions and a firewall failover. If the design uses a separate service VRF, confirm route leaking and route targets so the firewall sees both directions.
Writing automation playbooks that push full configuration to every device without idempotency or a dry-run step, then debugging the fabric after a partial push.
Candidates focus on getting a playbook to run once and never test re-runs, so a second execution duplicates interfaces or wipes a section not present in the template. Partial failure across a leaf pair then looks like a protocol bug.
What to do instead
Build templates around declarative resource modules with check mode and diff, stage changes per rack, and add a post-change assertion (BGP neighbor count, EVPN route count) that fails the run. Practice a deliberate mid-run abort and recovery. In exam scenarios about automation failures, look first for a non-idempotent task or a missing commit/confirmed-commit guard rather than a transport error.
Reading only interface counters and syslog when a tenant experiences intermittent drops, ignoring streaming telemetry, buffer and queue statistics, and the EVPN control-plane state that would localize the fault.
Traditional SNMP polling and show commands give a point-in-time view; intermittent microbursts and control-plane churn vanish between polls, so candidates chase the wrong layer and never correlate a drop with a BUM storm or a route withdrawal.
What to do instead
Adopt a layered triage order: physical (FCS, CRC, optics), underlay routing (ECMP hashing, next-hop reachability), overlay control plane (EVPN route presence and churn), then data plane (buffer drops, queue depth, PFC). Use streaming telemetry or gNMI for high-frequency counters and correlate timestamps with EVPN route events. Practice writing a triage checklist and applying it to a simulated intermittent-loss scenario.
Answering troubleshooting questions by proposing a configuration change immediately, without first isolating whether the fault is in the underlay, the overlay control plane, or the data plane.
Exam scenarios present a symptom (a host cannot reach a remote subnet) that can be caused at any of three layers, and candidates jump to the layer they know best, wasting time and sometimes 'fixing' a healthy layer while the real fault persists.
What to do instead
Use a fixed isolation sequence: can the local leaf reach the remote VTEP loopback? Is the MAC/IP in the local EVPN database and advertised? Is the remote route present with the right next-hop? Does the data plane forward (VXLAN encap, MTU, firewall)? Only after locating the failing layer propose a change, and state the verification command that will prove the fix.