CCIE Enterprise Written Qualification: Decision-First Study

Prepare for the CCIE Enterprise Infrastructure written qualification by studying each domain as a choice between technologies. For every topic, state the control plane, the data plane, and the symptom you would observe when the choice is wrong. Worked scenarios, one comparison table, and a readiness rubric turn broad syllabus coverage into reusable decision rules rather than isolated facts.

Why the written qualification rewards decision-making over recall

The written qualification is built on Cisco's ENCOR core exam, which spans dual-stack architecture, virtualization, infrastructure, network assurance, security, and automation. Studying each domain as a set of technology choices keeps that breadth manageable and mirrors how the topics interact.

Cisco structures the CCIE Enterprise Infrastructure track around a core written exam and a hands-on lab exam. Passing the core exam serves as the qualification step toward the lab and also earns the Enterprise Core specialist certification on its own. The core exam's scope covers implementing dual stack (IPv4 and IPv6) architecture, virtualization, infrastructure, network assurance, security, and automation, so your preparation must connect domains rather than treat them as silos.

A decision-first method works like this: for each domain, list the competing technologies, write one sentence describing when each is the right choice, and note one observable symptom of picking the wrong one. Then test yourself with scenarios. Administrative details such as scheduling, fees, and validity belong to Cisco's certification pages rather than to study notes, so treat the certification page as your single reference for logistics and return here for the technical decisions.

Choosing an IPv6 transition method: dual stack, tunneling, or translation

Compare three coexistence families: dual stack (running IPv4 and IPv6 natively), tunneling (carrying one protocol inside the other), and translation (NAT64 with DNS64, or stateless NPTv6). The deciding constraints are application support and whether you need end-to-end addressing.

These methods differ in dependency and compatibility. Dual stack requires hosts, applications, and routing to support both protocols, but preserves native behavior for each. Tunneling, such as manually configured tunnels or GRE, carries IPv6 over an IPv4 core and depends on reachable tunnel endpoints. Translation changes the dependency: stateful NAT64 with DNS64 lets IPv6-only clients reach IPv4 servers, while stateless NPTv6 rewrites prefixes without port translation but requires a predictable prefix relationship.

Worked scenario: an enterprise migrates a branch with an internal inventory application that embeds IPv4 addresses directly in its client configuration. The engineer deploys NAT64 so clients can be IPv6-only, then the application breaks because literal IPv4 addresses inside application payloads are not rewritten by the translator. The better decision is dual stack on the branch, keeping the legacy application on IPv4 natively while routing IPv6 alongside it. The lesson is that translation handles packet-level reachability but not protocol payload contents, so application behavior constrains the method more than network capability does.

Advanced routing tie-breakers: OSPF, EIGRP, and BGP in one network

Learn each protocol's selection logic: OSPF cost within area rules, EIGRP's DUAL with feasible distance and feasible successors, and BGP's ordered attribute evaluation. Redistribution then decides which protocol's route actually gets installed, which is where decisions get hard.

Named concepts matter here. OSPF floods LSAs of specific types — router LSAs, network LSAs, summary LSAs for inter-area routes, external LSAs, and NSSA external LSAs — and area design controls where each appears. EIGRP's DUAL algorithm keeps a successor and, when the feasible condition is met, feasible successors for fast failover without recomputation. BGP evaluates attributes in a defined order, including weight, local preference, AS path, origin, and MED, which makes policy expression explicit rather than metric-driven.

Worked scenario: a router redistributes OSPF routes into EIGRP at two points so that a branch has redundant paths. Without controls, an external route injected at site A can be re-advertised and learned back at site B, and traffic can follow a path that exits the OSPF domain and re-enters it, creating a suboptimal or looping route. The better decision is to tag routes at redistribution, filter with route maps so external tags are never re-advertised, and set administrative distance or BGP attributes so internal paths are consistently preferred. The reason it matters is that path selection is only predictable when redistribution direction and preference are designed, not defaulted.

Separating VXLAN EVPN from SD-Access: two overlays, different jobs

Both technologies build overlays over an underlay, but VXLAN EVPN uses BGP EVPN as its control plane for Layer 2 and Layer 3 extension, while Cisco SD-Access uses LISP for locator and identity separation with VXLAN as the data plane.

In VXLAN EVPN, switches are leafs and spines; BGP EVPN advertises MAC and IP reachability so that host learning does not rely on data-plane flooding. Anycast gateways give each host the same gateway address at its local leaf. In SD-Access, roles are functional: fabric edges register endpoint identity-to-location mappings with the control plane node, fabric borders connect the fabric to external networks, and scalable group tags carry policy through the fabric independent of IP addresses.

Worked scenario: an engineer comfortable with VXLAN EVPN deploys SD-Access and configures the fabric edge, but endpoints cannot communicate between sites. The mistake is assuming BGP EVPN reachability knowledge transfers directly: in SD-Access, the missing step is usually LISP registration flow — the edge must register endpoints with the control plane node, and the border must be known to the fabric. The better decision is to trace the LISP flow first (endpoint to edge to control plane node to border) before touching data-plane encapsulation. The distinction matters because the two overlays share an encapsulation but not a control plane, and diagnosing them requires different questions.

Network assurance: SNMP polling versus model-driven telemetry

SNMP pulls data at intervals from MIB objects; model-driven telemetry pushes structured data, modeled in YANG and often transported over gRPC, on a subscription or on change. Push-based data gives faster visibility into short-lived events.

The two differ on three axes: direction (poll versus push), data model (object identifiers in a MIB versus structured nodes in a YANG model), and cadence (a polling interval versus a subscription rate or event trigger). SNMP remains useful for broad, low-rate health checks and mature tooling. Model-driven telemetry suits counters and state that change quickly, because the router sends the data without waiting to be asked.

Worked scenario: an operations team polls interface counters and error statistics every five minutes, yet users report intermittent application slowdowns that never align with the poll samples. The mistake is assuming periodic polling will capture a microburst or a short congestion episode; the averaging and timing of polls can simply miss it. The better decision is to add a model-driven telemetry subscription for the relevant interface counters at a tighter cadence, then correlate that stream with application response times. The lesson is that assurance design should match the collection mechanism to the timescale of the problem you are trying to observe, not to the tooling you already own.

SD-WAN: how control, management, and data planes divide the work

In Cisco SD-WAN, vManage provides management, vBond orchestrates control plane connections, and vSmart distributes control policy. Edge routers build the data plane, exchanging reachability through OMP using TLOCs that describe transport location, color, and encapsulation.

OMP, the Overlay Management Protocol, carries routes and TLOCs between edges and the vSmart controller. A TLOC binds a route to a specific transport: the WAN interface IP, a color that distinguishes transport characteristics such as business or public broadband, and the encapsulation. Centralized policy separates control policy (influencing routing and path selection) from data policy (influencing forwarding in the data plane), and both are pushed through the controllers rather than configured per-box.

Worked scenario: a branch advertises its service-side prefix, but a remote site cannot reach it even though both edges are registered. The engineer spends time verifying IPsec tunnels when the actual cause is upstream of the data plane: the prefix was never redistributed into OMP, or a centralized control policy restricts which TLOCs may receive it. The better decision is to check the control plane in order — OMP route advertisement, TLOC attributes, then control policy match actions — before inspecting the tunnels. The reason it matters is that data-plane encryption can be healthy while control-plane reachability is broken, and the planes fail independently.

Automation protocols, a self-check exercise, and a preparation sequence

NETCONF uses SSH with XML encoding and explicit configuration datastores, while RESTCONF uses HTTP with XML or JSON and a REST-style interface, both driven by YANG models. Prepare by converting each domain's comparisons into timed scenario practice against a rubric.

Compare the automation interfaces on transport, encoding, and semantics. NETCONF runs over SSH, exchanges XML, and distinguishes candidate and running configuration datastores, which supports validating a change before committing it. RESTCONF maps YANG onto HTTP methods, so it fits tooling that already speaks REST, and returns JSON or XML. Both expose device models defined in YANG; the choice usually follows the surrounding automation platform and the change workflow you need.

Practical exercise: build a one-page decision table covering one comparison from each domain (IPv6 transition, routing protocol, overlay, assurance, SD-WAN plane, automation protocol). For each row, write the control plane, the data plane, and one observable failure symptom from the scenarios above. Self-check rubric: at three points, pick a row and explain aloud, in under two minutes, when you would choose each option and what you would check first if it failed. A reasonable milestone is explaining every row without notes; treat scores from this rubric as learning milestones, not predictions of any exam result. Adaptable sequence: spend the first stretch on dual stack and advanced routing, the middle stretch on virtualization, overlays, and SD-WAN planes, and the final stretch on assurance and automation, finishing by rebuilding the table from memory and re-running the two-minute explanations.

• Rebuild the domain decision table from memory and compare it against your notes
• Re-explain both worked scenarios in your own words, naming the mistaken decision and the better one
• Trace one LISP registration flow and one OMP route exchange on paper, plane by plane
• Confirm each domain's control plane, data plane, and failure symptom without notes before scheduling

References and further reading

Use these references to explore the concepts and check the latest information from the relevant organizations.

• cisco.com

Continue your preparation

• Cisco Certified Internetwork Expert Enterprise Infrastructure Written Qualification Ccie Enterprise
• Study Guides