Cisco DCIT 300-615 common mistakes
Cisco DCIT 300-615 · Understand the traps and how to avoid them.
Treating NX-OS data center troubleshooting as generic Cisco IOS troubleshooting: applying IOS-style show/debug syntax and IOS fault logic to Nexus switches instead of using NX-OS-specific commands and feature behaviour.
Most candidates prepare for CCNA/CCNP Enterprise or older IOS exams first, where interface, routing, and STP troubleshooting follows IOS conventions; NX-OS differs in command structure (e.g., 'show run' output format, feature-based licensing, 'show tech-support' bundles) and in how features like vPC and FabricPath alter forwarding.
What to do instead
Rebuild your mental command set around NX-OS: practise 'show running-config', 'show interface brief', 'show vpc', 'show vlan', 'show spanning-tree', 'show ip route vrf all', 'show tech-support' and 'show logging logfile' on a Nexus lab (CML, dCloud, or EVE-NG). For every troubleshooting topic, write down the NX-OS command you would run before the IOS equivalent, and verify output parsing on real NX-OS images.
Diagnosing vPC problems (peer-link down, vPC member port suspended, inconsistent VLANs) by looking only at the individual physical interface status and not at the vPC role, consistency, and peer-link state.
vPC is a Nexus-specific concept with no IOS equivalent, and the failure symptoms are subtle: both vPC peers can show interfaces 'up' while member ports are suspended due to type-1 consistency or peer-link issues. Candidates who have not operated vPC in a lab do not know to check 'show vpc', 'show vpc consistency-parameters', and 'show vpc peer-keepalive'.
What to do instead
Learn the vPC failure decision tree: check 'show vpc brief' for peer status and role, 'show vpc consistency-parameters global/vlan/interface' for type-1 vs type-2 mismatches, 'show vpc peer-keepalive' for heartbeat, and 'show port-channel summary' for peer-link state. Practise scenarios where the peer-link fails (secondary suspends member ports) and where VLANs are missing on one peer, and record the exact output signatures of each.
Assuming a routing adjacency problem is always a Layer 3 issue and skipping the Layer 1/2 verification path, so OSPF/BGP neighbors stuck in ExStart/Active are chased in routing config rather than in MTU, VLAN, or port-channel problems.
The exam's troubleshooting scenarios are layered by design, and many 'routing' tickets are caused by underlying L2 faults (MTU mismatch breaking OSPF DBD exchange, vPC or port-channel misconfiguration, VLAN not allowed on trunk). Candidates jump to the routing protocol because that is where the visible symptom appears.
What to do instead
Adopt a fixed bottom-up checklist for every adjacency ticket: interface up/up and error counters, trunk allowed VLANs, MTU end-to-end, port-channel/vPC state, then routing protocol state. Memorise signature causes: OSPF stuck in ExStart/Exchange usually means MTU mismatch; BGP stuck in Active/Connect usually means reachability or TCP 179 filtering; BGP in OpenSent/OpenConfirm points to capability or authentication mismatch.
Troubleshooting SAN switching (VSANs, zoning, FLOGI/FDISC, NPV/NPIV) with Ethernet assumptions, for example treating a missing zone as a VLAN problem or ignoring that zoning must be enforced in both the active zoneset and the correct VSAN.
Fibre Channel switching has its own state machine and terminology: FLOGI, FDISC, PLOGI, fabric login, zone membership, and zoneset activation. Candidates with a LAN background often do not know that an unactivated zoneset or a zone in the wrong VSAN produces exactly the same symptom as a physical link failure.
What to do instead
Study the FC login sequence and the show commands that expose each stage: 'show flogi database', 'show fcns database', 'show zoneset active', 'show zone', 'show fcalias', and 'show npv flogi-table'. In labs, break zoning deliberately (wrong VSAN, unactivated zoneset, missing member) and compare outputs; learn that NPV requires upstream NPIV and that server FLOGIs fail when the uplink is not NPIV-enabled.
Ignoring VRF context when troubleshooting routing or reachability, running 'show ip route' or 'ping' in the default VRF and concluding the path is broken when the tenant traffic lives in a non-default VRF.
Nexus platforms make heavy use of VRFs for tenant separation, and many commands default to the default VRF. Candidates who learned routing in a single-table environment forget that 'show ip route' without 'vrf all' hides tenant routes, and that ping/traceroute need the VRF specified.
What to do instead
Make VRF-qualified commands a habit: 'show ip route vrf all', 'show ip route vrf ', 'ping vrf ', 'show ip interface vrf all brief', 'show ip arp vrf all'. In practice labs, build a two-VRF topology with a route leaking or inter-VRF firewall and verify each diagnostic command both with and without the VRF keyword.
Misreading spanning-tree and loop symptoms on Nexus, for example assuming Rapid-PVST everywhere and not accounting for MST regions or for vPC's effect on STP topology, leading to wrong root bridge or blocked-port conclusions.
Nexus supports PVST+, Rapid-PVST+, and MST, and vPC changes STP behaviour (vPC peers act as a single logical bridge for the port-channel). Candidates who only know classic STP analysis misidentify the root, the blocked port, or the cause of a broadcast storm.
What to do instead
Practise 'show spanning-tree summary', 'show spanning-tree vlan ', 'show spanning-tree interface', and 'show spanning-tree mst configuration' on both PVST and MST designs. Learn the vPC+STP rules (primary peer is root, vPC ports are forwarding on both peers) and rehearse a loop scenario using 'show mac address-table' flapping and storm-control counters to localise the loop.
Skipping the control-plane and hardware-health checks when troubleshooting data-plane symptoms, so a forwarding problem caused by a failed supervisor, line card, or ASIC is chased in configuration.
Nexus troubleshooting requires distinguishing control-plane, data-plane, and management-plane faults. Candidates often only check interface counters and config, missing 'show module', 'show environment', 'show system resources', and 'show hardware' outputs that reveal a card in 'powered-up' vs 'ok' state or an ASIC error.
What to do instead
Add a hardware/health sweep to every scenario: 'show module', 'show environment', 'show system resources', 'show hardware capacity', 'show platform' (where supported), and 'show logging logfile' for hardware syslog IDs. Learn to read module states (ok, powered-up, failure, mismatch) and to correlate a line card state with the affected interfaces.
Treating ACI and Nexus stand-alone troubleshooting as the same skill, applying NX-OS CLI troubleshooting to ACI fabric faults instead of using the ACI object model, fault codes, and tenant/EPG constructs.
ACI is policy-driven and its troubleshooting surface is the APIC GUI/API and fault subsystem, not per-switch CLI. Candidates who only lab NX-OS stand-alone switches are lost when a question describes an EPG, contract, or fabric fault, and they misapply vPC or VLAN logic to ACI constructs.
What to do instead
Learn ACI-specific diagnostics: fault codes and their severity, tenant/VRF/BD/EPG/contract relationships, 'show' equivalents through the APIC CLI, endpoint learning ('show endpoint'), and fabric health. Lab a small ACI simulator or APIC sandbox, create a contract and EPG, then break it (missing contract, wrong BD, wrong domain association) and trace the fault in the GUI.
Not managing time and question triage: spending many minutes on one multi-part troubleshooting scenario and then rushing the rest, or changing an answer after over-analysing a 'most likely cause' question.
The exam presents scenario-style items that reward a structured diagnostic order; candidates who lack a repeatable method burn time re-reading and second-guessing. Anxiety and unfamiliarity with the item style compound this.
What to do instead
Build a timed practice routine: for each scenario, first identify the layer (L1/L2/L3/policy/hardware), then the single show command that discriminates between candidate causes, then the answer. Cap yourself at roughly 90 seconds per item in practice, review only flagged items at the end, and only change an answer when you can name the specific command output that contradicts your first choice.
Memorising command output without understanding the underlying protocol behaviour, so when a scenario shows an unfamiliar output format or a slightly different topology, the candidate cannot reason to the cause.
Troubleshooting exams test causal reasoning, not recall: the same symptom (e.g., vPC member port suspended) can arise from several causes, and the correct answer depends on interpreting state. Rote memorisation of 'show' outputs breaks as soon as the scenario varies.
What to do instead
For each technology, write a one-page cause-and-effect map: symptom, discriminating command, output signature, root cause, fix. Rebuild each map in a lab by injecting the fault yourself (shut an interface, remove a VLAN from a trunk, mismatch MTU, deactivate a zoneset) and observing the output change. Test yourself by predicting the output before running the command.