Cisco DCCOR (350-601) common mistakes
Cisco DCCOR (350-601) · Understand the traps and how to avoid them.
Treating VXLAN as a flat L2 overlay and forgetting that end-host routing happens in the distributed anycast gateway, so the candidate picks a design where all inter-VLAN traffic hairpins to a single border leaf.
Candidates memorize the VXLAN encapsulation header but never build the mental model of spine/leaf roles, VNI-to-VLAN mapping, and where the first-hop gateway lives. They default to the classic core-aggregation-access habit of centralizing routing.
What to do instead
Draw the fabric on paper before answering: spine (underlay, no host ports), leaf (VTEP, anycast gateway SVI), border leaf (external handoff). Trace one packet from host A on leaf 1 to host B on leaf 2 and mark every encap/decap point. Practice explaining why distributed anycast gateway avoids tromboning and how the same MAC/IP is configured on every leaf.
Confusing underlay routing choices and their operational side effects, e.g. recommending OSPF where BGP EVPN is required, or forgetting that the underlay only needs to carry loopback-to-loopback reachability, not tenant routes.
The exam mixes 'what protocol carries the overlay control plane' with 'what protocol provides loopback reachability.' Candidates blur the two layers and answer with whichever protocol they use daily.
What to do instead
Maintain a two-column table: underlay (IS-IS or OSPF or eBGP, loopbacks, ECMP, PIM if multicast replication) versus overlay control plane (MP-BGP EVPN with route types 2, 3, 5). For each question, first ask 'which layer is this about?' before choosing a protocol.
Answering vPC questions by describing it as an active/active L2 link with a single control plane, and missing that both peers keep independent control planes while the peer-link carries CFSoE and orphan/STP convergence traffic.
vPC is often learned as 'like a port-channel but redundant,' and candidates carry over misconceptions from stackwise or VSS where one supervisor rules. The peer-link's role in convergence and its data-plane restrictions are under-studied.
What to do instead
Memorize the three vPC components (peer-link, peer-keepalive, member ports) and what each carries. Learn the failure scenarios: peer-link down triggers suspend on secondary member ports, peer-keepalive down alone does not. Then answer by naming which component failed and what state results.
Describing UCS service profile and pool relationships backwards, e.g. saying a service profile template is instantiated from a pool, or that a server is associated to a pool rather than to a profile derived from a template.
The UCS object model (orgs, pools, policies, templates, profiles) is hierarchical and candidates skim the GUI without learning the dependency direction. Exam questions probe the direction of instantiation and what happens on dissociate.
What to do instead
Build a one-page object map: org > pools (MAC, WWNN, WWPN, UUID, IP) and policies > service profile template > service profile > server association. For each object write 'consumes' and 'is consumed by.' Practice predicting behaviour when a profile is disassociated (identity stays with profile, not server) and when a pool is exhausted (association fails).
Treating Cisco Intersight and UCS Manager as interchangeable management paths, and answering questions about policy enforcement or firmware as if both work identically for standalone and fabric-interconnected servers.
Many candidates have hands-on time with only one platform. They assume Intersight-managed mode supports every UCSM feature or vice versa, and miss that some modes (e.g. Intersight managed mode replacing UCSM on supported hardware) change the policy model.
What to do instead
Write a comparison covering UCSM-managed, Intersight-managed, and standalone modes: which policies exist, where firmware is managed, how server profiles and templates are expressed, and which hardware supports each. Answer by first identifying the management mode stated in the question.
Confusing Fibre Channel zoning with VSANs, or answering that a zone set is enforced per port rather than per VSAN, and missing that zones are defined inside a VSAN and only the active zone set is enforced.
Zoning and VSANs are both 'segmentation' concepts and candidates collapse them. The activation semantics of zone sets and the difference between hard and soft zoning are frequently glossed over.
What to do instead
Create a layered diagram: physical port > VSAN > zone > zone set (active). Learn that VSAN isolates fabric services and zoning controls which members can see each other within a VSAN. Memorize hard zoning (by pWWN) versus soft zoning (by interface/domain) and what happens to traffic when the active zone set changes.
Answering NPV/NPIV questions by saying NPV gives the host a fabric-wide domain ID, or that NPV does full local switching like a normal switch.
The two features sound similar and candidates remember only 'NPV is lighter than NPIV.' The key distinctions (NPV uses the core switch's domain and forwards login, NPIV allows an N-port to register multiple WWNs) get swapped.
What to do instead
Memorize one line each: NPIV lets a single N-port log in with multiple WWNs (used by hypervisors and by NPV uplinks); NPV is an edge switch that does not consume a domain ID and passes FLOGI through to the core. Then answer by asking 'does this device need its own domain ID?'
Describing AAA and RBAC in a way that skips the authorization step, e.g. saying TACACS+ authenticates and authorizes in one exchange, or that RADIUS cannot carry per-command authorization attributes.
Candidates memorize 'TACACS+ is Cisco, RADIUS is standard' without learning the AAA phases or transport differences. Exam items test which protocol separates authentication and authorization and how attributes are carried.
What to do instead
Build a table: TACACS+ (TCP 49, encrypts whole payload, separates authentication/authorization/accounting, per-command authorization) versus RADIUS (UDP, encrypts only password, combines authentication and authorization in the reply). Then practice mapping a scenario (per-command privilege control, 802.1X, device admin) to the right protocol and the right AAA phase.
Treating first-hop security features as one thing, so the candidate picks DHCP snooping where dynamic ARP inspection is required, or forgets that DAI depends on the DHCP snooping binding table.
DHCP snooping, IP source guard, and DAI are usually studied together and their dependencies blur. Candidates answer with the feature name that sounds closest to the attack described.
What to do instead
Write an attack-to-control matrix: rogue DHCP server > DHCP snooping; ARP spoofing > DAI (requires snooping binding table); IP spoofing > IP source guard; rogue RA > RA Guard. For each control, note the trust-state requirement on uplinks and the failure mode when the binding table is empty (DAI drops or permits depending on configuration).
Answering automation questions with Ansible/NX-API/Terraform as interchangeable, ignoring whether the task is idempotent configuration, imperative CLI execution, or model-driven telemetry, and missing the role of the DME/object model behind NX-API.
Candidates learn tool names from job ads but not their execution models. The exam tests whether you know that NX-API exposes the Data Management Engine object model, that Ansible modules wrap CLI or API calls, and that Terraform tracks state.
What to do instead
Build a three-row table: tool, execution model (declarative with state vs imperative playbook), transport (HTTPS/JSON, SSH/CLI, NETCONF/RESTCONF), and idempotency. Learn the NX-API modes (CLI-based vs DME/JSON-RPC) and when each is appropriate. Then answer by identifying what the question actually requires: a one-off command, a repeatable desired state, or streaming telemetry.