CCNP Data Center common mistakes
CCNP Data Center · Understand the traps and how to avoid them.
On vPC questions, the candidate assumes both peer switches load-share every frame and picks the answer in which both member links carry traffic for any flow.
vPC is mentally compressed to 'active/active', so candidates skip the loop-prevention detail: broadcast, unknown-unicast and multicast frames are forwarded by only one peer, and orphan ports plus peer-link state change the path.
What to do instead
Before selecting, redraw the topology and label which peer is primary, which ports are orphan, and whether the peer-link and peer-keepalive are up; then trace broadcast/unknown-unicast and known-unicast separately instead of once.
The candidate reads a route-map, prefix-list or distribute-list applied to a neighbor and evaluates it from the neighbor's point of view rather than the local router's.
'in' and 'out' feel like they describe the direction traffic travels toward you, so candidates silently flip the direction and eliminate the correct option during elimination.
What to do instead
Rewrite each policy line in your own words as 'routes I receive' (in) or 'routes I send' (out) relative to the router that holds the configuration, then evaluate against that rewritten sentence.
The candidate predicts an HSRP/VRRP failover to the higher-priority standby router without checking whether preemption is enabled or whether the priorities and interface tracking are what the stem says.
Priority comparison is the memorable part of first-hop redundancy, so preempt, group numbers, tracking decrements and the initial active election get treated as background detail.
What to do instead
For every FHRP item, write down four values before answering: current active, current standby, preempt yes/no, and any tracked-object decrement; if any is unknown, the failover answer is unsafe.
The candidate changes a policy (BIOS, boot order, vNIC placement, UUID pool) in a UCS service profile and assumes the running server picks it up at the next boot without a re-acknowledge or re-deploy.
Policies and service profiles are studied as a naming hierarchy, so the distinction between a change that stages a pending activity and one that requires the profile to be unbound and redeployed is glossed over.
What to do instead
Memorize the binding chain (pool to policy to service profile to template to server) and, for each change type, state out loud whether it is 'reboot required' or 're-acknowledge required' before looking at the options.
The candidate answers UCS fabric interconnect questions as if the pair were a standard switch stack, assuming a single management IP, ordinary spanning tree between the pair, and data traffic crossing the fabric interconnect.
The cluster, end-host mode and unified-port concepts are learned late and superficially, so default switching assumptions from LAN study carry over.
What to do instead
Sketch the two-fabric design first (separate management IPs, A/B side, end-host mode hiding MAC learning from upstream), and treat any answer implying cross-fabric traffic as wrong until proven otherwise.
The candidate configures zones in a VSAN and then expects the new membership to affect traffic immediately, without activating the zone set or checking the active zone set.
Zoning is remembered as 'make a zone', and the separate objects, the zone set, the activation step and the default-zone behaviour are under-practised.
What to do instead
Adopt a fixed checklist for every zoning item: VSAN, zone membership (pWWN or FC ID), zone set, activate, verify active zone set; answer only after all five boxes are filled.
The candidate mixes up NPIV and NPV, or misassigns port roles such as F, E, TE, NP and TF, when asked where the login is proxied and which device holds the domain ID.
The acronyms differ by one letter and both describe a server login seen through an upstream switch, so the functional difference is never separated in memory.
What to do instead
Anchor each to one sentence: NPIV gives one physical port many fabric logins; NPV makes the switch a host-like proxy with no domain ID of its own. Recite that before reading the options.
The candidate answers an ACI question by naming the correct object but places it at the wrong level, for example attaching an EPG directly to a VRF or assuming a bridge domain can span VRFs.
The tenant hierarchy is memorized as a list of terms rather than as a containment and binding tree, so parent-child and provider/consumer relationships collapse together.
What to do instead
Draw the tree tenant to VRF to bridge domain to application profile to EPG, with the EPG-to-BD and BD-to-VRF bindings marked, before every ACI item; place each object in the drawing first, then choose.
The candidate reads an Ansible playbook or NX-API call and predicts the result of a second run, or of a run with check mode or missing facts, as if the task simply re-executes the command.
Automation items are skimmed as 'what does this module do', so idempotency, state versus command modules, gather_facts, delegation and loop ordering are not evaluated line by line.
What to do instead
Re-read the task with three questions: is it declarative (state) or imperative (command), what does it change on run two, and does it depend on a fact, register or handler that the play may not have set.
The candidate enables DHCP snooping, dynamic ARP inspection and IP source guard together and assumes all three work, without checking that the uplink is trusted and that the snooping binding table is actually being populated.
Each first-hop security feature is learned as an isolated topic, so the dependency chain between them, trust state on uplinks and binding-table prerequisites are not treated as ordering constraints.
What to do instead
For any Layer 2 security scenario, answer in dependency order: DHCP snooping plus trusted uplink first, binding table populated second, then dynamic ARP inspection, then IP source guard; an option that skips a prerequisite is wrong.