Cisco ENARSI 300-410 common mistakes
Cisco ENARSI 300-410 · Understand the traps and how to avoid them.
Reading a routing table or show output and accepting the first matching route without tracing the recursive next-hop resolution to the egress interface.
Candidates memorize EIGRP/OSPF metric rules but practice mostly on flat topologies, so they never build the habit of following a next hop through multiple recursion levels, default routes, or a floating static that quietly overrides a dynamic route.
What to do instead
For every route question, force a written trace: prefix, AD, metric, next hop, recursive resolution, egress interface. Practice with overlapping static routes, default-information originate, and summary routes that black-hole traffic, then verify with show ip route and traceroute reasoning before choosing an answer.
Treating EIGRP feasibility condition and route selection as simple lowest-metric comparison, ignoring reported distance, feasible distance, and variance semantics.
The feasibility condition (reported distance < feasible distance) is counterintuitive, and candidates confuse advertised/reported distance with the local metric, so they misjudge when a feasible successor exists and when variance actually installs a second path.
What to do instead
Drill the terms separately: reported distance is the neighbor's metric to the destination, feasible distance is the local best metric, and a feasible successor requires RD < FD. Work through variance arithmetic (multiplier applied to FD, only feasible successors qualify) with small three-router topologies until the inequality is automatic.
Assuming OSPF areas, LSAs, and virtual links behave the same in OSPFv3 or that IPv6 OSPF configuration mirrors IPv4 line for line.
Candidates learn OSPFv2 syntax first and carry it over, missing that OSPFv3 uses interface-level configuration, link-local next hops, and different LSA type numbering (with Type 8/9 link and intra-area prefix LSAs).
What to do instead
Build a side-by-side OSPFv2/OSPFv3 comparison table covering configuration model, LSA types, next-hop addressing, and authentication (IPsec vs. native). Lab an ABR with a virtual link and a stub/NSSA area in both versions and compare show ip ospf database output.
Configuring a VRF-lite or MPLS L3VPN scenario without verifying route-target import/export symmetry and the resulting VRF routing table.
Candidates focus on the MP-BGP neighbor coming up and declare success, forgetting that a session can be Established while prefixes are silently dropped due to mismatched route targets, missing RD, or a next-hop that is unreachable inside the VRF.
What to do instead
Adopt a fixed verification order: VRF definition, RD, route-target both directions, MP-BGP address-family activation, then show ip route vrf and show bgp vpnv4 unicast all. Practice a deliberately broken RT to see the failure signature, and confirm next-hop-self or a route-map where the PE-CE next hop is not redistributed.
Debugging DMVPN or IPsec tunnel failures by changing crypto parameters at random instead of isolating phase 1, phase 2, and NHRP/routing layers.
Tunnel establishment spans IKE, IPsec SA, NHRP registration, and overlay routing; candidates conflate a phase 2 mismatch with a routing problem, or assume a spoke registration failure is a crypto issue, so changes never converge.
What to do instead
Use a layered checklist: IKE (proposal, PSK/cert, identity), IPsec (transform set, ACL/protected networks), NHRP (network-id, NHS, registration), then overlay routing. Verify each layer with show crypto ikev2 sa, show crypto ipsec sa, show dmvpn, and show ip nhrp before touching the next layer.
Answering control-plane policing and CoPP questions as if CPP protects data traffic, or confusing it with interface ACLs and uRPF.
CPP, uRPF, ACLs, and AAA all live under 'security' and candidates group them by name rather than by what they inspect and where they apply, so they pick the wrong tool for a stated symptom such as CPU spikes from BGP updates.
What to do instead
Map each feature to a one-line purpose: CoPP filters traffic destined to the device's own control plane via a policy-map on control-plane; uRPF validates source reachability; ACLs filter transit/interface traffic; AAA authenticates access. Practice reading a control-plane policy-map and predicting which protocol classes drop under load.
Configuring AAA and device hardening (SSH, local fallback, privilege levels) without testing the authentication and authorization path end to end.
Candidates stop once the config is syntactically accepted, not noticing that a missing aaa authorization or a wrong method list locks out management, or that 'login local' versus 'login authentication ' changes behavior silently.
What to do instead
Always include a local fallback user and test with a second session before closing the first. Verify with show aaa servers, show running-config | section aaa, and an actual login at each privilege level; practice recovering a device locked out by an AAA misconfiguration using console access.
Configuring DHCP relay/snooping, NAT, or NTP and assuming the service works because the command was accepted, without checking trust states, option 82, or translation tables.
These services fail silently: DHCP snooping drops offers on untrusted ports, NAT may not translate without a matching inside/outside interface pair or route, and NTP stays unsynchronized due to stratum or authentication mismatch. Candidates rarely inspect state.
What to do instead
Define a per-service verification command set: show ip dhcp snooping binding and show ip dhcp snooping statistics; show ip nat translations and show ip nat statistics with debug ip nat; show ntp status and show ntp associations. Lab each service with one deliberate misconfiguration and confirm the exact failure output.
Writing or reading automation snippets (EEM applets, Python with NETCONF/RESTCONF, guest shell) without validating data models, encoding, or event triggers against the device behavior.
Candidates treat automation questions as syntax recall and ignore that YANG paths, JSON/XML encoding, NETCONF datastores (candidate vs. running), and EEM event specifiers determine whether the action actually fires or commits.
What to do instead
Practice reading a YANG model to derive a valid path, then perform a get-config and edit-config against candidate and running datastores, observing commit behavior. For EEM, map event (syslog, timer, CLI) to action and test with a harmless applet; verify with show event manager policy registered and show event manager history events.
Assuming a feature is supported or behaves identically across platforms and IOS/IOS-XE versions when answering configuration or troubleshooting scenarios.
Exam scenarios often hinge on platform-specific behavior (for example, which features run in hardware vs. software, or how VRF-aware services are supported), and candidates answer from generic memory instead of the constraints implied by the scenario.
What to do instead
When a scenario names a platform or version, reason from stated constraints rather than defaults, and practice identifying which verification command would confirm behavior on that platform. Maintain a short notes file of version-dependent gotchas you have personally labbed, and flag anything you cannot verify rather than guessing.