Cisco Certified Internetwork Expert (CCIE) Enterprise Infrastructure Study Guide

Cisco Certified Internetwork Expert (CCIE) Enterprise Infrastructure Study Guide

Issuing body: Cisco Jurisdiction: Global (vendor certification — not a legal license to practice) Level: Expert (highest Cisco tier) Prerequisites: Must pass the core qualifying exam (350-401 ENCOR) before scheduling the lab. Typically several years of senior hands-on experience. (Source: catalogue record computer-cert-003.) Renewal: 3-year validity; renew by lab exam, core exam, or continuing education credits.

1. What this exam is

CCIE Enterprise Infrastructure is the most prestigious vendor networking credential in existence: a written qualifier (ENCOR, shared with CCNP) plus an 8-hour hands-on lab where you design, build, troubleshoot, and optimize a full enterprise network under exam conditions. It doesn't test whether you know networking — it tests whether you can do networking at speed, under pressure, with broken things, the way a principal engineer does during a 2 a.m. outage with executives on the bridge. Pass rates are low because the lab punishes shallow knowledge: anything you "kind of know" will cost you 45 minutes you don't have.

2. Pathway and exam format

• Typical path: CCNA → CCNP Enterprise (ENCOR + ENARSI/ENSDWI) → 3–5 years of senior enterprise/data-center networking → CCIE written (ENCOR, if not already passed) → 6–12 months of dedicated lab practice → lab attempt.
• Written qualifier: 350-401 ENCOR (same as CCNP core). Valid as lab qualifier for 3 years.
• Lab: 8 hours, two modules — Design (3 hours, scenario-based: interpret requirements, produce a design) and Deploy/Operate/Optimize (5 hours, hands-on: configure, troubleshoot, optimize on real gear/topologies). Lab fee ~$1,600–1,900 USD (varies by location; mobile labs exist). Scored on task completion against an answer key with partial credit.
• Lab strategy is a discipline unto itself: read the entire lab first (30 min), identify dependencies between tasks (some tasks' verification depends on earlier tasks working), do the quick wins first, and never spend >30 min stuck — mark and return. Speed comes from not troubleshooting your own typos: use a consistent config method, verify each section before moving on.

3. Knowledge domains (with theory)

The lab blueprint spans the CCNP corpus at expert depth plus: advanced routing (BGP/MPLS), multicast, QoS, security services, SDA/SD-WAN, automation, and design methodology. The differentiator vs CCNP is integration: every technology interacts with every other, and the lab tests the interactions.

Advanced routing: BGP as a design language

iBGP scaling designs: route reflector hierarchies (clusters within clusters; know the loop-prevention: originator-ID and cluster-list), confederations (sub-ASes with eBGP-like behavior inside — know when each fits: RRs for most enterprises, confederations for very large/migrating networks). BGP add-paths (advertise multiple paths for faster failover — the answer to "BGP reconverges too slowly for our SLA").

BGP policy architecture: route maps + communities + AS-path filters as a system. Expert patterns: consistent community taxonomy (e.g., 65000:100 = backup path, 65000:200 = customer), peer-group templating, prefix-lists generated from IRR data, RPKI/ROA validation (origin validation — the hijack defense; know the states: valid/invalid/not-found and the policy implications).

MPLS L3VPN (the service-provider/large-enterprise core): VRFs + route distinguishers (RD makes overlapping addresses unique: 65000:1:10.0.0.0/8) + route targets (RT controls import/export between VRFs — the policy knob) + MP-BGP VPNv4 (carries RD+labels) + LDP/RSVP label distribution. Know the packet walk: ingress PE pushes two labels (VPN label + transport label), P routers swap transport only, penultimate hop popping, egress PE pops VPN label and VRF-routes. Inter-AS options (A/B/C) at a conceptual level.

DMVPN / FlexVPN (large-scale WAN): mGRE + NHRP (spoke-to-spoke dynamic tunnels — the scaling insight: hub doesn't hairpin spoke-to-spoke traffic) + IPsec. Phase 1/2/3 differences (phase 3: NHRP redirect/shortcut for true spoke-to-spoke). EIGRP/OSPF/BGP over DMVPN (routing protocol choice implications: EIGRP with NHRP, OSPF point-to-multipoint).

Convergence engineering: BFD (sub-second detection), BGP PIC (prefix-independent convergence — precomputed backup paths in FIB), LFA/rLFA (loop-free alternates for IGP fast reroute), BGP timers tuning vs stability trade-offs. The expert question is always: "converge in X ms without false positives" — answer with the detection/propagation/computation decomposition and pick mechanisms per layer.

Multicast at expert depth

PIM-SM shared tree (*,G) → SPT switchover (spt-threshold), RP placement and redundancy (Anycast-RP with MSDP, BSR, Auto-RP), SSM (232.0.0.0/8, no RP — receiver-driven), BIDIR-PIM for many-to-many. RPF check (multicast forwarded only on the interface toward the source per the unicast table — the loop prevention). MSDP for inter-domain. The lab's multicast tasks are usually "it doesn't work" → RPF failure or RP misplacement.

QoS as a system

The QoS pipeline: classification (NBAR, ACLs, DSCP trust) → marking (DSCP at the edge, trust boundary concept) → policing (drop/mark-down excess — single/dual rate) → queuing (LLQ priority queue for voice + CBWFQ classes + WRED for TCP-friendly drops) → shaping (buffer excess to smooth bursts). Per-hop behaviors: EF (voice, strict priority, police it), AFxy (assured forwarding: x=priority, y=drop precedence), CS (class selector backward-compat), default/BE. Key models: DiffServ (the Internet-scale model — per-hop, no signaling) vs IntServ/RSVP (per-flow reservation — doesn't scale, legacy). The design questions: where's the trust boundary (access edge), how much to provision the PQ (voice bandwidth + ~33% — over-provisioning PQ starves everything else), WRED thresholds per AF drop precedence. Math: serialization delay, jitter budgets (voice: <30 ms jitter, <150 ms one-way delay, <1% loss — memorize), LLQ bandwidth reservation vs interface bandwidth.

Security services integration

Zone-based firewall (zone pairs, class-maps/policy-maps, self zone), NAT at scale (PAT pools, NAT64 concepts), IPsec at scale (DMVPN/FlexVPN above; GETVPN for private WANs — group key server, any-to-any without tunnels), control-plane protection (CoPP policies by protocol queue), 802.1X/MAB/WebAuth with ISE (authorization policies, SGT inline tagging — TrustSec end-to-end), device hardening at template scale.

SDA and SD-WAN (the automation-era enterprise)

SD-Access fabric: underlay (IS-IS, the transport) + overlay (LISP for endpoint ID/location separation, VXLAN for encapsulation) + controller (DNA Center) + policy (ISE/SGT). Know the packet walk (edge node encapsulates to border) and the roles (edge, border, control-plane node). Host tracking (LISP map-server) replaces flooding. SD-WAN (Viptela): vManage (config), vSmart (policy/OMP control plane), vBond (orchestration/authentication), vEdge/cEdge (data plane). OMP (overlay management protocol — like BGP for the overlay: routes, TLOCs, service chaining). Policy: centralized (vSmart: topology, traffic engineering via SLA-aware routing) vs localized (device templates). The expert angle: OMP route selection, TLOC preferences, DIA (direct internet access) policy, and failure-mode behavior (what happens when vSmart is unreachable — data plane keeps forwarding on last-known state).

Design methodology (the Design module)

Requirements → constraints → design: the lab's design module grades structured thinking: restate requirements, identify constraints (budget, existing gear, RTO/RPO, compliance), produce topology, addressing, protocol selection with justification, and failure-mode analysis. Always design for the failure modes: what happens when each link/device/protocol fails, and what's the blast radius? Document assumptions — graded designs reward explicit trade-off reasoning over "correct" answers.

Automation at expert level

YANG models + NETCONF/RESTCONF for real (not vocabulary — actually driving config), EEM for event-driven device automation, Python (netmiko/Nornir/napalm patterns) for multi-device orchestration, model-driven telemetry (gRPC dial-out streaming vs SNMP polling — the scale insight: telemetry streams at 10s intervals from 1000 devices; polling doesn't). Know when automation is the answer vs when it's overkill.

4. Key formulas and expert numbers

• BGP convergence: detection (BFD ~150 ms) + best-path recompute + peer update propagation + FIB install. PIC edge pre-computes alternates → ~50–200 ms failover.
• Voice budget: one-way delay <150 ms (ITU G.114), jitter <30 ms, loss <1%. LLQ size = voice bandwidth × 1.33.
• MPLS label stack: 20-bit label, 3-bit EXP (QoS), 1-bit bottom-of-stack, 8-bit TTL. Two labels typical in L3VPN (transport + VPN).
• QoS math: policer CIR/PIR, shaper buffering delay = burst / CIR. WRED: min-threshold → max-threshold linear drop probability.
• Availability: same series/parallel math as always; the expert move is quantifying each design option's availability and cost.
• BFD: detect time = transmit interval × multiplier (50 ms × 3 = 150 ms typical). Faster than any IGP timer tuning without the false-positive risk.

5. Worked examples

Example 1 — BGP slow convergence, PIC design. Scenario: Dual-homed data center; link failure causes 30–60 s traffic blackholes while BGP reconverges; SLA demands <1 s. Solution: (1) BFD on eBGP sessions (150 ms detection). (2) BGP PIC Edge: bgp pic edge pre-installs backup paths in FIB — failover becomes a FIB rewrite (~100 ms), not a control-plane reconvergence. (3) Ensure a backup path actually exists in BGP (add-paths or diverse peering) — PIC can't invent paths. (4) Tune bgp advertisement-interval down on the edge. Verify: shut the primary, measure loss duration with continuous ping. The insight: separate detection (BFD), decision (precomputed PIC), and propagation — optimize each.

Example 2 — MPLS L3VPN route leaking between customers. Scenario: Customer A routes appear in Customer B's VRF. Diagnose. Solution: Route targets control import/export — the leak means overlapping RTs. Check: show vrf detail (import/export RT lists), show bgp vpnv4 unicast (which RTs are attached). RDs were probably unique (no collision error) but RTs misconfigured (e.g., both VRFs exporting to 65000:100 and importing it). Fix: distinct RT per customer; verify with show ip route vrf B (A's prefixes gone). Lesson: RD = uniqueness, RT = policy. Confusing them is the classic MPLS bug.

Example 3 — Multicast RPF failure. Scenario: New video source; receivers get nothing; unicast works fine. Solution: Multicast uses RPF — packets accepted only on the interface the router would use to reach the source. Check show ip rpf <source>: if the RPF interface ≠ the interface the multicast arrives on (asymmetric routing, or a new link changed the unicast best path), packets drop silently. Fix: align unicast routing (or static mroute ip mroute to pin RPF). Also verify RP: show ip pim rp mapping — wrong RP = no shared tree. The diagnostic order (RPF → RP → PIM neighbors → IGMP) solves most multicast tickets.

Example 4 — SD-WAN DIA policy gone wrong. Scenario: After enabling Direct Internet Access at branches, guest traffic works but corporate SaaS breaks intermittently. Solution: DIA policy (vSmart centralized data policy) is matching too broadly or NAT is misapplied. Check: the data policy sequence (order matters — first match wins), NAT pool exhaustion on the cEdge (show ip nat statistics), and whether corporate SaaS was supposed to be backhauled (policy exception missing). Fix: precise match criteria (DSCP/app-aware via NBAR), separate NAT pools, verify with show sdwan policy. Lesson: centralized policy is powerful and therefore dangerous — always verify match order and scope.

Example 5 — QoS: voice quality fine, bulk transfers starving. Scenario: LLQ configured for voice; during calls, backup traffic drops to near zero; after calls, backups saturate the link and voice degrades. Solution: Two bugs: (1) PQ over-provisioned or unpoliced — LLQ needs an explicit policer (priority 256 with implicit police; excess voice remarkdropped). Actually the starvation during calls suggests the PQ is too large or there's no fair-queue left for the rest — check priority percent vs absolute. (2) No shaper on the backup class — backups burst and fill queues, adding jitter. Fix: police the PQ at voice-needs + margin, CBWFQ with minimum bandwidth guarantees per class, WRED on bulk classes, and shape egress to the contracted CIR. Verify: show policy-map interface (drops per class tell the story).

6. Standards and regulations cross-reference

• IETF: RFC 4271 (BGP-4), 4760 (MP-BGP), 4364 (L3VPN), 6513/6514 (mVPN), 4601 (PIM-SM), 2474/2475 (DiffServ), 3550 (RTP — the voice payload QoS protects), 6793 (BGP 4-octet ASNs), 6480-6493 (RPKI suite).
• IEEE: 802.1Q/bah (PBB), 802.3ad LACP, 802.1AX, data-center bridging (802.1Qbb PFC, 802.1Qaz ETS — lossless Ethernet for storage).
• ITU-T: G.114 (voice delay), Y.1564 (service activation testing).
• MEF (Metro Ethernet Forum): E-Line/E-LAN/E-Tree service definitions — carrier Ethernet literacy.
• FCC Part 15 / EECC / CALEA — regulatory context for wireless and carrier designs (as in CCNP).
• PCI DSS v4.0 / ISO 27001 — segmentation and audit in enterprise designs; the design module may impose compliance constraints.

7. Pitfalls, traps, and lab strategy

Lab trap patterns:

1. The dependency trap: task 12's verification needs task 4's BGP working. Read everything first; build in dependency order.
2. The typo tax: at expert speed, 80% of "troubleshooting" is your own typos. Develop a ritual: configure → show run | section → verify → next.
3. The rabbit-hole trap: 30-minute rule — if you're stuck, mark it and move on. Partial credit rewards breadth; perfectionism fails labs.
4. The design-module trap: writing config instead of design. The design module wants requirements analysis, topology, protocol justification, failure modes — not CLI.
5. The "it worked in the sim" trap: the lab runs real topologies with real convergence times. Wait for protocols to converge before verifying.
6. The automation trap: don't automate what you can configure faster by hand in the lab — automation is tested as knowledge, the lab is mostly CLI.

Preparation strategy: 6–12 months, 10–15 hrs/week. Build a personal lab (EVE-NG/CML) and do full 8-hour mock labs monthly. Keep an error log — every mistake you make twice is a lab point lost. Study groups help: explaining BGP policy to someone else is the fastest way to find your own gaps. Know the blueprint's verbs: "configure" vs "troubleshoot" vs "describe" vs "design" demand different depths.

8. Practice problems

P1. Two RRs in the same cluster; a client advertises a route. The other RR reflects it back. How is the loop prevented, and what attribute proves it? Answer: Cluster-list: each RR prepends its cluster-ID when reflecting; a RR receiving a route with its own cluster-ID in the list drops it. Originator-ID (the original iBGP speaker's RID) prevents reflection back to the originator. Verify: show ip bgp <prefix> shows cluster-list/originator-ID.

P2. An MPLS L3VPN CE can't reach a remote site. show ip route vrf CUST on the ingress PE lacks the remote prefix. Walk the diagnostic chain. Answer: (1) CE-PE routing: is the prefix in the VRF RIB? (show ip route vrf CUST, check the PE-CE protocol: eBGP/OSPF/EIGRP/static.) (2) Redistribution into MP-BGP: show bgp vpnv4 unicast vrf CUST <prefix> — present? (3) RT policy: does the egress PE export an RT the ingress imports? (4) Label path: show mpls forwarding-table / LSP to the egress PE loopback intact? (5) Egress: prefix in egress VRF RIB and advertised to remote CE? The chain is VRF RIB → VPNv4 → RT → transport → remote VRF RIB.

P3. Voice calls across a DMVPN hub-and-spoke have 300 ms delay though the underlay RTT is 40 ms. What's the likely cause and fix? Answer: Spoke-to-spoke traffic hairpinning through the hub (DMVPN phase 1, or phase 2/3 NHRP shortcut not working). Check: show ip nhrp on spokes (do they have each other's NBMA mappings?), phase config (phase 3 needs ip nhrp redirect on hub + ip nhrp shortcut on spokes). Fix NHRP shortcut so spokes build direct tunnels. 300 ms ≈ hub detour + queuing.

P4. Design the BGP policy for: AS 65001, two upstreams; outbound all via ISP-A; inbound prefer ISP-A; never transit; customers in AS 65002-65005 must be reachable even if ISP-A fails. Answer: Outbound: local-pref 200 on ISP-A ingress, 100 on ISP-B. Inbound: prepend 3× toward ISP-B; announce customer aggregates toward both (customers need reachability via either). Anti-transit: outbound prefix-lists permit only own + customer prefixes; no iBGP between upstreams' routes (they're eBGP anyway); ensure no neighbor x route-reflector-client misconfig leaking. Failure mode: ISP-A down → local-pref irrelevant, ISP-B paths remain (longer AS_PATH but valid) — customers still reachable. Document the convergence time expectation.

P5. A network must converge link failures in <200 ms. The IGP is OSPF with default timers. Give the layered solution and the risk of each layer. Answer: (1) BFD 50×3 (150 ms detection; risk: false positives on lossy links — tune multiplier up there). (2) LFA FRR precomputed alternates (risk: not always available in all topologies; check coverage with show ip ospf fast-reroute). (3) SPF throttling tuned (risk: CPU churn under flapping — pair with summarization). (4) BGP PIC edge if BGP is involved. Never just lower OSPF hello/dead timers aggressively — that's the amateur answer with CPU and false-positive costs.

P6. You're given a design-module style prompt: "Connect 3 data centers, 50 branches, dual ISP per site, <1 s failover, PCI segmentation for cardholder systems, 2-year growth 2×." Sketch the design rationale (not config). Answer: Core: MPLS L3VPN or SD-WAN overlay (choose SD-WAN for policy agility + DIA; MPLS for deterministic SLA — justify the choice against the <1 s failover: SD-WAN with BFD + OMP gives sub-second; MPLS needs FRR). DC interconnect: DCI via SD-WAN or dedicated (latency/bandwidth math). Segmentation: separate VRF/VPN per PCI scope (cardholder VRF with no internet route, dedicated firewall context), TrustSec/SGT for microsegmentation within. Routing: eBGP to ISPs with local-pref/prepend policy; iBGP + RRs in DCs. Addressing: hierarchical (DC/region/site blocks) enabling summarization. Growth: 2× means 50% headroom in tunnel/route scale + controller sizing (vSmart/vManage cluster, not single). Failure modes: per-site dual-ISP with BFD; controller loss = data plane survives on last state (document); document RTO per failure type. Assumptions listed explicitly.

Original ETS reference writing, verified against public sources on 2026-09-30. Thin sourcing is flagged inline. Not legal advice — confirm current editions with the issuing body.