CCIE Enterprise common mistakes
CCIE Enterprise · Understand the traps and how to avoid them.
Declaring a routing task done once the control plane comes up (OSPF neighbors FULL, BGP session Established) without checking that routes are actually installed in the RIB/FIB and that traffic forwards from the correct source.
Candidates stop at the first CLI output that looks healthy because adjacency state is the easiest thing to see, and time pressure discourages end-to-end testing.
What to do instead
Adopt a fixed per-task verification ladder: neighbor/adjacency state -> 'show ip route' / 'show bgp' for the specific prefix -> 'show ip cef' for the next hop -> ping/traceroute sourced from the exact interface or VRF the task specifies. Only then move on.
Configuring a technically working solution that violates a stated constraint in the task (wrong VLAN/VRF/AS/interface, adding static routes where dynamic routing is required, changing something the ticket says must stay untouched).
Under exam time pressure candidates skim the requirement text and jump to configuration, then never re-read the paragraph before verifying.
What to do instead
Before touching a device, rewrite each ticket as a short numbered constraint list (protocol, numbers, interfaces, forbidden changes, verification command). Re-read that list after configuring and check every line off explicitly.
Leaving Layer 2 inconsistencies in place: trunk allowed-VLAN lists that omit the required VLAN, native VLAN mismatch, wrong STP mode/priority or portfast/BPDU guard on host ports, and err-disabled ports never recovered.
Layer 2 problems are silent until a specific host or VLAN is tested, so candidates configure the L3 overlay and never validate per-VLAN forwarding.
What to do instead
After any L2 change run 'show interfaces trunk', 'show vlan brief', 'show spanning-tree vlan X' and 'show interfaces status err-disabled', then test connectivity in every affected VLAN before moving to L3.
Misconfiguring multicast RPF: wrong PIM mode or RP address, missing 'ip pim sparse-mode' on the transit/RPF interface, or no IGMP querier/snooping handling, and never validating the (S,G) state with 'show ip mroute'.
Multicast depends on the unicast RPF path, which candidates forget to align with the configured RP, and they check group membership rather than the mroute table.
What to do instead
Verify in order: unicast route back to the source exists on the RPF interface, PIM enabled on that interface, RP reachable and consistently configured, then confirm (S,G) state and flags in 'show ip mroute' and test with a receiver joined before the sender starts.
In SD-WAN, leaving devices with partial control connections because system-ip/site-id/org-name or TLOC color/encapsulation do not match the controller configuration, and never confirming OMP peering or service-VPN route exchange.
Candidates treat template attachment as success and do not distinguish between 'device is reachable' and 'all TLOCs are up and OMP routes are exchanged'.
What to do instead
Check every TLOC's control connections individually, confirm OMP sessions are up and routes are received, verify the service VPN is present on the device, and test overlay reachability across the VPN before considering the task complete.
In SD-Access, building the overlay before the fabric underlay is proven: missing loopback reachability, wrong border/control-plane node roles, LISP pub/sub sessions down, VXLAN tunnels not formed, or anycast gateway configured on the wrong node.
The fabric has many interdependent layers and candidates jump to host onboarding and then chase symptoms instead of checking underlay, LISP, then VXLAN in order.
What to do instead
Validate bottom-up: underlay routing and loopbacks between fabric nodes -> LISP map-server/map-resolver sessions and map-cache entries -> VXLAN tunnel reachability and anycast-GW config on all edge nodes -> then host onboarding and fabric host-tracking entries.
Ignoring tunnel/overlay overhead: MTU and MSS left at defaults across DMVPN/IPsec/VXLAN/MPLS paths, NHRP registration or redirect/shortcut not verified for spoke-to-spoke traffic, and QoS markings dropped or not copied into the tunnel header.
Small pings succeed while large packets and specific flows fail, so the tunnel appears healthy; candidates also assume phase-3 spoke-to-spoke works without checking NHRP.
What to do instead
Set tunnel and physical MTU deliberately, clamp TCP MSS, test with DF-bit pings at expected payload sizes, confirm NHRP registrations and shortcut behaviour with 'show ip nhrp', and verify QoS with 'show policy-map interface' on both tunnel and physical interfaces.
Sequencing wired/wireless authentication incorrectly: DHCP/DNS blocked before 802.1X completes, dACL or SGT policy enforced too strictly to let the supplicant authenticate, CoA not handled, or SGT inline tagging missing on the trunk so policy never matches.
Candidates focus on making the authentication succeed and forget that the access path must be permissive during boot, and that segmentation needs tagging plus a policy definition end to end.
What to do instead
Allow the pre-auth bootstrap (DHCP/DNS/ISE reachability) in the pre-auth policy, verify sessions with 'show authentication sessions interface' and 'show access-session', confirm SGT assignment and tagging on uplinks, and test the enforcement path with real traffic rather than trusting the policy table.
Applying ACL/NAT/QoS without reasoning about order of operations and return path: NAT inside/outside or static entries inverted, ACLs blocking the return or routing protocol traffic, zone-based firewall with no return inspection, or markings applied after queuing so they have no effect.
Each feature works in isolation, so the candidate checks the feature configuration rather than how the features interact on the actual traffic path.
What to do instead
Trace one flow end to end: confirm interface direction of ACLs, verify translations with 'show ip nat translations', check return-path reachability, apply marking as close to the source as possible and verify classification and queuing counters with 'show policy-map interface'.
Automation tasks failed by tooling/format errors rather than logic: wrong RESTCONF/NETCONF headers, media type or auth, guessing YANG paths instead of reading the model tree, Python/Ansible scripts that are not idempotent, and no get-before/get-after validation.
Candidates memorise one working request or playbook and reuse it without adapting to the model, transport, or device, and they do not check that the change actually landed.
What to do instead
Inspect the YANG tree first and build the payload from it; validate the transport (URI, Content-Type/Accept, auth, encoding) with a simple GET before any POST/PUT; make scripts idempotent by reading current state; and always re-read state after the change and check status codes rather than assuming success.