JNCIE-DC common mistakes
JNCIE-DC · Understand the traps and how to avoid them.
Designing the fabric underlay with an IGP but never verifying that loopback-to-loopback reachability exists between every leaf and every spine before bringing up EVPN, then debugging overlay symptoms that are actually underlay black holes.
Candidates treat the underlay as a checkbox because the lab guide lists OSPF or eBGP configuration, and they assume that because adjacencies are up, the loopbacks are reachable. Asymmetric prefix advertisement or a missing loopback network statement leaves VTEP peering sessions stuck in Connect or Active while the physical links look healthy.
What to do instead
Before any EVPN configuration, run a systematic loopback reachability matrix (ping sourced from each leaf loopback to every spine loopback and to every other leaf loopback) and verify the routing table contains all VTEP loopbacks with the expected next hop. Treat this as a gate: do not proceed to overlay until the matrix is fully green.
Configuring EVPN-VXLAN Type-2 and Type-3 routes but forgetting to advertise the local VTEP address or to enable VXLAN encapsulation on the loopback, so the overlay forms control-plane adjacencies with no data-plane forwarding.
Candidates focus on the EVPN route types and VNI-to-VLAN mappings while overlooking that the VTEP source interface must be reachable and properly configured on both control and data planes. The control plane shows routes, so the candidate assumes forwarding works and only discovers the gap when traffic is tested.
What to do instead
For every VTEP, verify the VXLAN source-interface is the loopback used for BGP EVPN peering, that the VNI is bound to the correct VLAN, and that the encapsulation is active. Confirm with a targeted traffic test sourced from a host behind one leaf to a host behind a remote leaf, checking the MAC and IP learning tables on both ends.
Using a single anycast gateway MAC and IP across all leaves but failing to ensure consistent configuration (same virtual MAC, same gateway IP, same VNI-to-VLAN mapping) on every leaf that hosts the subnet.
Candidates build the anycast gateway on one leaf to prove it works, then copy partial configuration to other leaves without validating consistency. Inconsistent virtual MACs or gateway IPs cause ARP/ND replies to come from the wrong leaf, producing intermittent reachability that is hard to reproduce.
What to do instead
Define the anycast gateway parameters once as a template and apply identical values on every leaf. After deployment, verify from each leaf that the virtual MAC and gateway IP match the template, and test host mobility by moving a workload between leaves and confirming uninterrupted ARP/ND resolution and forwarding.
Treating multitenancy as VLAN separation only, reusing the same VNI or route-target across tenants, and not isolating tenant routing tables (VRFs) on the edge devices.
Candidates map tenants to VLANs and VNIs but do not carry the isolation through the EVPN route-target import/export policy and the L3 VRF configuration. Overlapping tenant IP space then leaks between tenants, or routes from one tenant appear in another tenant's table.
What to do instead
For each tenant, assign a dedicated VRF, a unique L3 VNI, and unique route targets for both import and export. Verify isolation by configuring overlapping subnets in two tenants and confirming that each tenant's routing table contains only its own routes and that cross-tenant pings fail.
Building DCI by stretching Layer 2 across sites without controlling the EVPN route-target scope, so MAC and IP routes from one site are imported into the other site's tables indiscriminately and the two sites become one failure domain.
Candidates extend the same VNI and route targets across the DCI link because that is the simplest way to make a test ping succeed. They do not consider that stretched L2 with unrestricted route import propagates unknown unicast, broadcast, and topology churn across sites, and that a single misbehaving host affects both data centers.
What to do instead
Design the DCI with explicit route-target policy: import only the specific tenant routes required, use separate L3 VNIs per site where possible, and apply route filtering or a route reflector hierarchy at the DCI boundary. Test failure isolation by injecting a route or MAC flap in one site and confirming the other site's tables remain stable.
Automating fabric provisioning with scripts that push configuration but never verify idempotency or roll back on partial failure, leaving devices in a half-configured state after a single error.
Candidates write automation to save time in the lab and treat the first successful run as proof of correctness. When a device rejects one command or a session drops mid-run, the script continues or stops without restoring prior state, and the candidate cannot tell which devices are consistent.
What to do instead
Structure automation as idempotent, declarative intent (desired state per device) with pre-change validation, post-change verification against the intent, and an explicit rollback path. Run the automation twice and confirm the second run makes no changes, then deliberately inject a failure and confirm the rollback restores a known-good state.
Configuring redundancy (MC-LAG, EVPN multihoming, or redundant uplinks) but not verifying that the failover actually converges, so the design looks redundant on paper while a single link failure causes a multi-second outage.
Candidates validate steady-state forwarding and assume redundancy works because the protocols are enabled. They do not test failure scenarios or check convergence timers, and they miss asymmetric configurations between the redundant peers that only matter during failover.
What to do instead
Build a failure test plan: for each redundant link, peer, and device, fail it deliberately and measure convergence and traffic loss. Verify that the redundant peers have matching configuration, that the designated forwarder election behaves as intended, and that traffic recovers within the design target.
Applying security policy only at the fabric edge and leaving intra-fabric east-west traffic unfiltered, or configuring ACLs that match on underlay addresses instead of the tenant overlay addresses.
Candidates think of security as perimeter firewalling and forget that a VXLAN fabric carries tenant traffic between leafs without passing through the edge. ACLs written against physical interface addresses never match the encapsulated tenant flows, so policy appears configured but enforces nothing.
What to do instead
Place policy at the distributed anycast gateway or a dedicated services leaf so it sees tenant IP addresses before encapsulation, and verify with traffic tests that permitted flows pass and denied flows drop. Confirm the ACL counters increment for the intended tenant flows, not for underlay transport traffic.
Diagnosing overlay problems by reading EVPN route tables only, without correlating the MAC learning table, the ARP/ND table, and the VXLAN tunnel endpoint state on both ends of the path.
Candidates learn the show commands for EVPN routes and stop there, so they see the route present and conclude the path is healthy. The actual fault may be a stale MAC entry, a missing ARP resolution, or a tunnel that is up on one side and down on the other, none of which appear in the EVPN table alone.
What to do instead
Use a layered troubleshooting sequence: underlay reachability, then BGP EVPN session and route presence, then VNI and tunnel state, then local MAC/ARP tables, then end-to-end traffic with counters at each hop. Compare both VTEPs side by side to find asymmetric state.
Ignoring control-plane scale limits when designing the fabric, such as the number of MAC addresses, EVPN routes, or ARP entries per leaf, and discovering the limit only when the topology grows.
Candidates design for the small lab topology and never check platform scale numbers or the impact of multihoming and mobility on route counts. As tenants and hosts are added, tables overflow and entries are silently dropped or aged out, producing intermittent connectivity that is attributed to other causes.
What to do instead
Estimate the worst-case table sizes (MACs, ARP/ND, EVPN routes per VNI and per tenant) from the design, compare against documented platform limits with headroom, and monitor table utilization during scale tests. If limits are close, adjust the design (route summarization, ARP suppression, limiting scope of stretched L2) before deployment.