DCNP common mistakes
DCNP · Understand the traps and how to avoid them.
When a question describes a leaf-spine topology with ECMP and asks why a flow is pinned to one uplink, the candidate answers 'STP is blocking the other links' instead of recognizing that a hash-based ECMP flow policy keeps a single flow on one path.
Candidates carry over campus switching habits where redundant links are blocked by Spanning Tree, and never internalize that modern data center fabrics run Layer 3 ECMP with all links active, so per-flow hashing (not link blocking) explains the observed behavior.
What to do instead
Before answering any fabric path question, state the forwarding model out loud: is this L2 with STP, L3 ECMP, or an overlay with an underlay ECMP? Then map the symptom to the model. Drill the distinction that ECMP load-balances flows, not packets, and that a single flow's hash is deterministic; practice identifying when rehashing (e.g., more entropy fields) is the fix versus when a link is genuinely down.
The candidate treats VXLAN as a complete replacement for the underlay and cannot explain that VXLAN requires a routed, ECMP-capable IP underlay with MTU headroom, so they misdiagnose tunnel failures as VTEP misconfiguration when the real cause is underlay routing or MTU.
Overlay concepts are learned in isolation (VNI, VTEP, encap) without connecting them to the physical/IP underlay, and candidates underestimate how much of troubleshooting depends on understanding BGP/OSPF underlay reachability and the extra 50+ bytes of encapsulation.
What to do instead
Study the overlay as a layered stack: physical links, routed underlay (e.g., eBGP), VTEP reachability, then VNI-to-VLAN mapping and MAC learning. For every overlay troubleshooting scenario, walk the layers bottom-up and explicitly check underlay route to the remote VTEP and path MTU. Practice explaining what happens to a frame at each layer.
On EVPN questions, the candidate confuses the control-plane and data-plane roles, for example claiming EVPN carries tenant data or that MAC learning must be flood-and-learn, rather than recognizing BGP EVPN as the control plane distributing MAC/IP and IMET routes while VXLAN forwards data.
EVPN route types (Type 2 MAC/IP, Type 3 IMET, Type 5 IP prefix) are memorized as a list without a mental model of which route does what, so the candidate cannot reason about symmetric IRB, anycast gateway, or ARP suppression under exam pressure.
What to do instead
Build a one-page map of EVPN route types to their function and to the failure each solves (Type 3 for BUM replication via ingress replication, Type 2 for MAC/IP reachability and ARP suppression, Type 5 for prefix routing). For each, write the question 'what breaks if this route is missing?' and verify you can answer it without notes.
The candidate answers SDN questions by equating 'SDN' with 'a controller GUI' or 'OpenFlow only', and cannot distinguish a centralized control plane from a distributed one or explain intent-based versus imperative configuration.
Vendor marketing conflates management planes, controllers, and SDN, and candidates learn product names rather than architecture. They then fail questions that test the separation of control and data planes, or that ask where policy is enforced in a fabric controller model.
What to do instead
Anchor on the definitional test: is the control plane logically centralized and does it program forwarding devices via an API? Then classify each technology you study (OpenFlow, BGP EVPN with a controller, fabric manager, intent API) against that test. Practice describing the same fabric in both imperative and intent terms to see the difference.
The candidate misapplies network virtualization terminology, treating VRFs, VLANs, and VXLAN VNIs as interchangeable segmentation tools, and cannot state which layer provides isolation versus which provides stretch.
The terms overlap in casual usage and each vendor implements them differently; candidates memorize definitions without mapping them to a concrete packet or configuration, so they cannot reason about where a tenant boundary actually lives.
What to do instead
For each construct, write its scope (local L2, device-local L3, fabric-wide L2/L3), its identifier, and its failure symptom. Then trace a packet from a VM through vSwitch, VNI, VRF, and VLAN and label each boundary. Quiz yourself by asking 'which construct prevents tenant A from reaching tenant B at Layer 3?' until the answer is instant.
For segmentation and security questions, the candidate assumes a VLAN or subnet boundary is a security boundary and picks 'create a new VLAN' as the fix for lateral-movement risk, instead of choosing stateful policy enforcement or micro-segmentation with an explicit allow-list.
Legacy design habits treat L2 separation as isolation, and candidates do not internalize that routing between VLANs, shared services, and overlay gateways can bypass that separation; they also underweight east-west traffic in modern data centers.
What to do instead
Reframe every segmentation question around the threat: who can talk to whom, and what enforces it? Learn to distinguish L2 separation, L3 ACLs, stateful firewalls, and distributed micro-segmentation by where enforcement occurs and whether it follows the workload. Practice designing an allow-list policy for a three-tier app and identifying every path that bypasses a naive VLAN-only design.
The candidate applies campus security reflexes to the data center, such as relying on 802.1X port authentication or DHCP snooping as the primary control for server-to-server traffic, rather than recognizing that in a fabric the enforcement point is often the VTEP or a policy group attached to the workload.
Most study material and prior experience is campus-oriented, and candidates do not adapt when the access layer becomes a virtual switch or a leaf VTEP where the endpoint identity is a VNI or policy tag, not a physical port.
What to do instead
Make a table of security controls and ask 'where does this live in a leaf-spine/overlay fabric?' For each control, identify the fabric equivalent (port-based auth becomes workload identity/policy group; VLAN ACL becomes distributed firewall rule). Study one vendor-neutral micro-segmentation model end to end and be able to describe enforcement at the source host.
On automation questions, the candidate picks the tool by name recognition (e.g., 'use Ansible' or 'use Python') without matching the mechanism to the requirement, such as choosing an agent-based model when the scenario demands agentless, or a declarative intent model when the task is procedural.
Tool familiarity substitutes for architectural reasoning, and candidates do not practice mapping requirements (idempotency, scale, state reconciliation, event-driven reaction) to tool categories, so they cannot discriminate among similar-sounding options.
What to do instead
Create a decision matrix: agent vs agentless, declarative vs imperative, pull vs push, synchronous API vs event-driven. For each exam-style requirement, name the property it implies and the tool class that provides it. Practice writing a short justification for each choice, since the exam tests reasoning, not brand recall.
When troubleshooting, the candidate jumps straight to a configuration change or blames the overlay, skipping the ordered evidence-gathering steps (interface counters, underlay reachability, control-plane adjacencies, then data-plane forwarding), and cannot articulate a methodical isolation path.
Real-world pressure rewards fast fixes, and candidates have not been taught a repeatable troubleshooting model, so they pattern-match to the last outage they saw and lose points on questions that test the diagnostic sequence or the first command to run.
What to do instead
Adopt and rehearse a fixed model: define the symptom, scope it (one host, one rack, one tenant, all), verify the layer below before the layer above, and confirm with counters or logs before changing anything. Practice writing the first three commands you would run for ten common symptoms (no connectivity, high latency, asymmetric path, BUM flooding, MTU black hole).
The candidate ignores operational telemetry semantics, for example reading a rising interface error counter or a BUM storm as normal, or misinterpreting streaming telemetry versus SNMP polling intervals when asked how to detect a microburst.
Monitoring is studied as a list of protocols rather than as a measurement problem; candidates do not connect sampling interval, counter type, and event duration, so they cannot reason about why polling misses short spikes or why a counter reset matters.
What to do instead
For each telemetry method (SNMP poll, syslog, sFlow, streaming telemetry, in-band network telemetry), write what it measures, its time granularity, and the failure it can and cannot detect. Then work a microburst scenario end to end and justify why high-frequency streaming telemetry is required. Confirm you can interpret counter deltas and resets correctly.