Skip to content
Log in Sign up My account

ENCOR Diagram Library

Exam-style topology exhibits and concept diagrams for ENCOR 350-401 v1.2, grouped by blueprint domain. For each one, work out what it shows before you read the explanation. The exam often shows a drawing like these and asks what happens next, which device does the job, or which port blocks.

1.0 Architecture

E01. Three-tier vs two-tier campus

Blueprint 1.1

graph TB
  subgraph T3 ["Three-tier"]
    C1["Core 1"] --- C2["Core 2"]
    D1["Dist A1"] --- C1
    D1 --- C2
    D2["Dist A2"] --- C1
    D2 --- C2
    D3["Dist B1"] --- C1
    D3 --- C2
    D4["Dist B2"] --- C1
    D4 --- C2
    AA["Access bldg A"] --- D1
    AA --- D2
    AB["Access bldg B"] --- D3
    AB --- D4
  end
  subgraph T2 ["Two-tier collapsed core"]
    CD1["Core/Dist 1"] --- CD2["Core/Dist 2"]
    AX["Access 1"] --- CD1
    AX --- CD2
    AY["Access 2"] --- CD1
    AY --- CD2
  end

The three-tier design adds a dedicated core when there are several distribution blocks (usually several buildings), so distribution pairs do not need a full mesh between them. The two-tier design collapses core and distribution into one redundant pair and suits a single building or a small campus. Every access switch is dual-homed in both designs, so expect questions on which design fits a given size and why the core exists.

E02. Layer 2 access vs routed access

Blueprint 1.1

graph TB
  subgraph L2A ["Layer 2 access"]
    direction TB
    DA1["Dist 1<br/>HSRP active, STP root"] ---|"L2 trunk"| DA2["Dist 2<br/>HSRP standby"]
    DA1 ---|"trunk, forwarding"| SA["Access switch<br/>VLAN 10"]
    DA2 ---|"trunk, STP blocking"| SA
  end
  subgraph L3A ["Routed access"]
    direction TB
    DB1["Dist 1"] ---|"routed p2p"| DB2["Dist 2"]
    DB1 ---|"routed /31 or /30"| SB["Access switch<br/>SVI 10 is the gateway"]
    DB2 ---|"routed /31 or /30"| SB
  end

In Layer 2 access the default gateway lives on the distribution pair, so you need an FHRP and spanning tree blocks one uplink per VLAN. In routed access the access switch is the gateway, the uplinks are routed links with ECMP, no FHRP is needed and STP is confined to the access switch. The trade-off the exam looks for is faster convergence and no blocked links in exchange for VLANs that cannot span access switches.

E03. Spine-leaf fabric

Blueprint 1.1

graph TB
  SP1["Spine 1"]
  SP2["Spine 2"]
  SP1 --- L1["Leaf 1"]
  SP2 --- L1
  SP1 --- L2["Leaf 2"]
  SP2 --- L2
  SP1 --- L3["Leaf 3"]
  SP2 --- L3
  SP1 --- L4["Leaf 4<br/>border leaf"]
  SP2 --- L4
  L1 --- S1["Servers"]
  L2 --- S2["Servers"]
  L3 --- S3["Servers"]
  L4 --- WAN["WAN / Internet"]

Every leaf connects to every spine, and there are no leaf-to-leaf or spine-to-spine links. Any server reaches any other server in the same number of hops (leaf, spine, leaf), which gives predictable latency for east-west traffic. You scale bandwidth by adding spines and scale ports by adding leaves.

E04. SSO with NSF

Blueprint 1.1

graph LR
  subgraph SW ["Chassis or stack"]
    ACT["Active supervisor<br/>runs control plane"] -->|"state and config sync"| STB["Standby supervisor<br/>hot standby"]
  end
  NBR["Neighbor router<br/>NSF-aware"] ---|"OSPF / BGP adjacency"| SW
  ACT -.->|"failure: switchover"| STB

SSO keeps a standby supervisor synchronised with the active one, so a supervisor failure does not reset line cards and Layer 2 forwarding continues. SSO alone does not keep routing adjacencies up. NSF (graceful restart) lets NSF-aware neighbors keep forwarding to the restarting router while it rebuilds its routing tables, which is why the exam pairs SSO with NSF.

E05. Catalyst SD-WAN planes

Blueprint 1.2

graph TB
  MGR["SD-WAN Manager<br/>(vManage)<br/>management plane"]
  VAL["SD-WAN Validator<br/>(vBond)<br/>orchestration plane"]
  CTL["SD-WAN Controller<br/>(vSmart)<br/>control plane"]
  E1["WAN Edge site A<br/>data plane"]
  E2["WAN Edge site B<br/>data plane"]
  E1 -.->|"1. authenticate, learn controllers"| VAL
  E2 -.->|"1. authenticate"| VAL
  E1 ---|"DTLS/TLS: OMP"| CTL
  E2 ---|"DTLS/TLS: OMP"| CTL
  E1 ---|"DTLS/TLS: NETCONF"| MGR
  E2 ---|"DTLS/TLS: NETCONF"| MGR
  E1 ===|"IPsec data plane tunnel"| E2

Know which component sits in which plane: Manager is management (GUI, templates, monitoring), Validator is orchestration (first point of contact, authentication, NAT traversal), Controller is control (OMP routes, TLOCs and policy), and WAN Edges are the data plane. Control traffic goes through the controllers, but user traffic goes directly edge to edge over IPsec. The Validator needs a reachable public address because edges behind NAT contact it first.

E06. SD-WAN TLOCs and data plane tunnels

Blueprint 1.2

graph LR
  subgraph SA ["Site A edge, system IP 1.1.1.1"]
    A1["TLOC color mpls"]
    A2["TLOC color biz-internet"]
  end
  subgraph SB ["Site B edge, system IP 2.2.2.2"]
    B1["TLOC color mpls"]
    B2["TLOC color biz-internet"]
  end
  A1 ===|"IPsec + BFD"| B1
  A2 ===|"IPsec + BFD"| B2
  A1 -.-|"only if reachable and not restricted"| B2
  A2 -.-|"only if reachable and not restricted"| B1

A TLOC is identified by system IP, color and encapsulation. Edges try to build IPsec tunnels between every pair of reachable TLOCs, and the restrict keyword on a color limits tunnels to the same color only. BFD runs inside each tunnel to measure loss, latency and jitter, which is what application-aware routing uses to choose a path.

E07. OMP route and TLOC advertisement

Blueprint 1.2

sequenceDiagram
  participant EA as Edge A
  participant C as SD-WAN Controller
  participant EB as Edge B
  EA->>C: OMP update: prefix 10.1.0.0/16 via TLOC 1.1.1.1 mpls
  EA->>C: TLOC route: public and private IP, color, encap
  Note over C: Applies centralized control policy
  C->>EB: OMP route 10.1.0.0/16, next hop TLOC 1.1.1.1 mpls
  C->>EB: TLOC route for 1.1.1.1 mpls
  EB->>EA: Builds IPsec tunnel to the TLOC, BFD starts
  EB->>EA: User traffic flows directly, not via the controller

OMP runs only between edges and controllers, and the controller acts like a route reflector with policy. Edges never peer OMP with each other directly. A question that asks where user traffic flows after the edge learns the route expects the direct edge-to-edge tunnel.

E08. SD-Access fabric roles

Blueprint 1.3

graph TB
  CTRL["Catalyst Center<br/>automation and assurance"]
  ISE["ISE<br/>identity and SGT policy"]
  CP["Control plane node<br/>LISP map server/resolver"]
  BN["Border node<br/>exit to outside"]
  IN["Intermediate node<br/>underlay only"]
  ED1["Edge node 1"]
  ED2["Edge node 2"]
  FU["Fusion router<br/>shared services, DHCP, DNS"]
  H1["Host A"] --- ED1
  H2["Host B"] --- ED2
  ED1 --- IN
  ED2 --- IN
  IN --- BN
  BN --- FU
  CP -.-|"LISP"| ED1
  CP -.-|"LISP"| ED2
  CP -.-|"LISP"| BN
  CTRL -.- ISE

Edge nodes connect endpoints and register them with the control plane node. The control plane node is the LISP map server and map resolver, the border node connects the fabric to everything outside it, and intermediate nodes only route underlay IP. The fusion router or firewall sits outside the fabric and leaks routes between virtual networks and shared services, which is how the fabric interoperates with the traditional campus.

E09. SD-Access endpoint registration and packet walk

Blueprint 1.3

sequenceDiagram
  participant A as Host A
  participant E1 as Edge 1
  participant CP as Control plane node
  participant E2 as Edge 2
  participant B as Host B
  B->>E2: Connects, authenticates, gets SGT
  E2->>CP: LISP Map-Register: EID of Host B at RLOC Edge 2
  A->>E1: Frame to Host B
  E1->>CP: LISP Map-Request for Host B
  CP->>E1: Map-Reply: RLOC is Edge 2
  E1->>E2: VXLAN packet with VNI and source SGT
  Note over E2: Decapsulate, check SGACL on egress
  E2->>B: Original frame delivered

This is the SD-Access division of labour: LISP is the control plane, VXLAN is the data plane, and TrustSec SGTs are the policy plane. The SGT travels in the VXLAN header and policy is normally enforced at the egress edge. The underlay is plain routed IP, typically IS-IS when Catalyst Center LAN automation builds it.

E10. QoS trust boundary

Blueprint 1.4

graph TB
  PC["PC<br/>marks DSCP 46"] --> PH["IP phone<br/>voice EF, CoS 5"]
  PH -->|"trust boundary here"| AS["Access switch<br/>conditional trust via CDP"]
  AS -->|"trunk, CoS and DSCP trusted"| DS["Distribution"]
  DS --> WAN["WAN router<br/>LLQ for EF"]

The trust boundary is the first point where the network accepts the markings it receives, normally the access port where the phone connects. The switch trusts the phone (often only when CDP detects a phone) and the phone re-marks the PC traffic behind it to 0. If the PC could keep its own DSCP 46 it would get into the priority queue, which is the security point the exam tests.

E11. MQC classification and queuing on a WAN edge

Blueprint 1.4

graph LR
  PKT["Packet out Gi0/0/0"] --> Q1{"match dscp ef?"}
  Q1 -->|"yes"| LLQ["class VOICE<br/>priority percent 10<br/>policed under congestion"]
  Q1 -->|"no"| Q2{"match dscp cs3?"}
  Q2 -->|"yes"| CB1["class SIGNALING<br/>bandwidth percent 5"]
  Q2 -->|"no"| Q3{"match ERP ACL or af21?"}
  Q3 -->|"yes"| CB2["class CRITICAL-DATA<br/>bandwidth percent 30, WRED"]
  Q3 -->|"no"| DEF["class-default<br/>fair-queue"]

Classes are checked in the order they appear in the policy-map and the first match wins, with anything unmatched landing in class-default. The priority class is served first but is policed to its rate during congestion, while bandwidth is a minimum guarantee. Queuing only has an effect when the interface is congested.

2.0 Virtualization

E12. Type 1 vs type 2 hypervisors

Blueprint 2.1

graph TB
  subgraph H1 ["Type 1, bare metal"]
    direction TB
    VM1["VM"] --- HV1["Hypervisor<br/>ESXi, KVM, Hyper-V"]
    VM2["VM"] --- HV1
    VS1["Virtual switch"] --- HV1
    HV1 --- HW1["Server hardware"]
  end
  subgraph H2 ["Type 2, hosted"]
    direction TB
    VM3["VM"] --- HV2["Hypervisor app<br/>VirtualBox, Workstation"]
    HV2 --- OS["Host operating system"]
    OS --- HW2["PC hardware"]
  end

A type 1 hypervisor runs directly on the hardware and is what data centres use. A type 2 hypervisor runs as an application on a host operating system and is common on laptops for labs. VMs connect to a virtual switch inside the hypervisor, which then uplinks through the physical NICs.

E13. VRF-Lite path separation

Blueprint 2.2

graph LR
  RA["Site router A<br/>VRF RED, VRF BLUE"] ---|"Gi0/1.10 VRF RED 10.0.10.0/30"| RB["Core router<br/>VRF RED, VRF BLUE"]
  RA ---|"Gi0/1.20 VRF BLUE 10.0.20.0/30"| RB
  HR["Host RED 192.168.1.10"] --- RA
  HB["Host BLUE 192.168.1.10"] --- RA
  RB --- SR["RED servers"]
  RB --- SB["BLUE servers"]

Each VRF has its own routing table, so the two tenants can even reuse 192.168.1.0/24. Without MPLS, VRF-Lite needs one Layer 3 link (often an 802.1Q subinterface) per VRF on every hop, and the routing protocol runs once per VRF. Verification uses show ip route vrf RED and ping vrf RED, and a plain show ip route shows only the global table.

E14. GRE over IPsec header stacks

Blueprint 2.2

graph LR
  subgraph G ["Plain GRE, adds 24 bytes"]
    G1["New IP<br/>proto 47"] --> G2["GRE"] --> G3["Original IP"] --> G4["Data"]
  end
  subgraph T ["GRE over IPsec, transport mode"]
    T1["New IP<br/>proto 50"] --> T2["ESP"] --> T3["GRE"] --> T4["Original IP"] --> T5["Data"] --> T6["ESP trailer, auth"]
  end
  subgraph N ["GRE over IPsec, tunnel mode"]
    N1["IPsec IP<br/>proto 50"] --> N2["ESP"] --> N3["GRE IP<br/>proto 47"] --> N4["GRE"] --> N5["Original IP"] --> N6["Data"] --> N7["ESP trailer, auth"]
  end

GRE is IP protocol 47 and adds a 20-byte outer IP header plus a 4-byte GRE header, so it carries multicast and routing protocols but has no encryption. ESP is IP protocol 50 and encrypts what it wraps. Transport mode reuses the GRE tunnel IP header and saves 20 bytes compared with tunnel mode, which is why the tunnel MTU and ip tcp adjust-mss matter in tunnel questions.

E15. IKEv2 tunnel setup

Blueprint 2.2

sequenceDiagram
  participant R1 as Router 1
  participant R2 as Router 2
  R1->>R2: IKE_SA_INIT: proposals, DH, nonce (UDP 500)
  R2->>R1: IKE_SA_INIT reply
  R1->>R2: IKE_AUTH: identity, auth, child SA proposal
  R2->>R1: IKE_AUTH reply: IKE SA and first child SA up
  R1->>R2: ESP protected traffic (UDP 4500 if NAT is detected)

IKEv2 builds the IKE SA and the first IPsec child SA in four messages. IKE uses UDP 500 and switches to UDP 4500 when NAT traversal is detected. On IOS XE, show crypto ikev2 sa and show crypto ipsec sa confirm each stage, and rising encaps with zero decaps points to a problem on the far side.

E16. LISP registration and resolution

Blueprint 2.3

sequenceDiagram
  participant ITR as ITR
  participant MR as Map-Resolver
  participant MS as Map-Server
  participant ETR as ETR
  ETR->>MS: Map-Register: EID prefix 10.2.0.0/16 at my RLOC
  ITR->>MR: Map-Request for EID 10.2.0.5
  MR->>MS: Forwards Map-Request
  MS->>ETR: Forwards to the authoritative ETR
  ETR->>ITR: Map-Reply: EID 10.2.0.0/16, RLOC, priority, weight
  Note over ITR: Caches the mapping
  ITR->>ETR: Data encapsulated to the RLOC (UDP 4341)

LISP separates identity (EID) from location (RLOC). ETRs register their EID prefixes with the map server, ITRs ask the map resolver, and the authoritative ETR answers the ITR directly. LISP control messages use UDP 4342 and the data plane uses UDP 4341.

E17. VXLAN encapsulation

Blueprint 2.3

graph TB
  O1["Outer Ethernet"] --> O2["Outer IP<br/>VTEP to VTEP"] --> O3["Outer UDP<br/>dst port 4789"] --> O4["VXLAN header<br/>24-bit VNI"] --> I1["Inner Ethernet<br/>original frame"] --> I2["Payload"]

VXLAN wraps a complete Layer 2 frame in UDP so it can cross a routed underlay between VTEPs. The 24-bit VNI allows about 16 million segments compared with 4094 VLANs. The extra headers add about 50 bytes, so the underlay MTU must be raised to carry full-size frames.

3.1 Layer 2

E18. DTP negotiation outcomes

Blueprint 3.1.a

graph LR
  A1["dynamic auto"] ---|"result: ACCESS"| A2["dynamic auto"]
  B1["dynamic auto"] ---|"result: TRUNK"| B2["dynamic desirable"]
  C1["dynamic desirable"] ---|"result: TRUNK"| C2["dynamic desirable"]
  D1["trunk"] ---|"result: TRUNK"| D2["dynamic auto"]
  E1["trunk"] ---|"result: mismatch, no working trunk"| E2["access"]
  F1["trunk + nonegotiate"] ---|"result: TRUNK"| F2["trunk"]
  G1["trunk + nonegotiate"] ---|"result: ACCESS on far end"| G2["dynamic auto"]

Auto plus auto is the classic trap: both sides wait, so the link stays an access link. Desirable actively asks and forms a trunk with trunk, desirable or auto. switchport nonegotiate stops DTP frames, so the far side must be hard-coded as a trunk.

E19. Native VLAN and allowed list mismatch

Blueprint 3.1.a

graph LR
  SW1["SW1 Gi1/0/24<br/>trunk native 1<br/>allowed 10,20,30"] ---|"802.1Q trunk"| SW2["SW2 Gi1/0/24<br/>trunk native 99<br/>allowed 10,20"]
  H30a["PC VLAN 30"] --- SW1
  H30b["PC VLAN 30"] --- SW2

The native VLAN mismatch causes CDP to log a native VLAN mismatch, and untagged frames from VLAN 1 on SW1 land in VLAN 99 on SW2, joining two broadcast domains. VLAN 30 is not in SW2's allowed list, so the two VLAN 30 hosts cannot talk even though the trunk is up. Use show interfaces trunk to compare native and allowed VLANs on both ends.

E20. EtherChannel negotiation outcomes

Blueprint 3.1.b

graph LR
  L1["LACP active"] ---|"bundle forms"| L2["LACP active"]
  L3["LACP active"] ---|"bundle forms"| L4["LACP passive"]
  L5["LACP passive"] ---|"no bundle"| L6["LACP passive"]
  P1["PAgP desirable"] ---|"bundle forms"| P2["PAgP auto"]
  P3["PAgP auto"] ---|"no bundle"| P4["PAgP auto"]
  N1["on"] ---|"bundle forms"| N2["on"]
  N3["on"] ---|"no bundle"| N4["LACP active"]

LACP (IEEE 802.3ad) uses active and passive, PAgP (Cisco) uses desirable and auto, and on uses no protocol at all. At least one side must actively negotiate, and on only works with on. Member ports must also match speed, duplex, switchport mode, native and allowed VLANs, or they show as suspended or standalone in show etherchannel summary.

E21. RSTP port roles in a triangle

Blueprint 3.1.c

graph TB
  SW1["SW1 ROOT<br/>priority 4096"]
  SW2["SW2<br/>priority 32768, lower MAC"]
  SW3["SW3<br/>priority 32768, higher MAC"]
  SW1 ---|"SW1 Gi0/1 DESIGNATED / SW2 Gi0/1 ROOT"| SW2
  SW1 ---|"SW1 Gi0/2 DESIGNATED / SW3 Gi0/1 ROOT"| SW3
  SW2 ---|"SW2 Gi0/2 DESIGNATED / SW3 Gi0/2 ALTERNATE, discarding"| SW3

SW1 has the lowest bridge ID, so it is root and all its ports are designated. SW2 and SW3 each pick their root port toward SW1. On the SW2 to SW3 link both have the same root path cost, so the lower sender bridge ID (SW2) wins the designated role and SW3's port becomes the alternate, which RSTP keeps discarding and can promote immediately if its root port fails.

E22. MST regions

Blueprint 3.1.c

graph LR
  subgraph R1 ["Region CAMPUS, revision 1"]
    A1["SW-A<br/>MST1 = VLAN 10-20<br/>MST2 = VLAN 30-40"] --- A2["SW-B<br/>same name, revision, mapping"]
  end
  subgraph R2 ["Region DC, revision 3"]
    B1["SW-C"] --- B2["SW-D"]
  end
  A2 ---|"boundary ports: IST / CST only"| B1
  A1 ---|"boundary"| PV["Rapid PVST+ switch"]

Switches are in the same MST region only when name, revision number and VLAN-to-instance mapping all match. Inside a region each MSTI can have its own root and topology, but between regions only instance 0 (the IST) is seen, as part of the common spanning tree. A mismatch in any one of the three values splits the region, which is a common troubleshooting answer.

3.2 Layer 3

E23. EIGRP vs OSPF at a glance

Blueprint 3.2.a

graph LR
  subgraph EI ["EIGRP"]
    E1["Advanced distance vector, DUAL"]
    E2["AD 90 internal, 170 external"]
    E3["IP protocol 88, 224.0.0.10"]
    E4["Metric: bandwidth and delay"]
    E5["Summarize on any interface"]
    E6["Unequal-cost load balancing with variance"]
  end
  subgraph OS ["OSPF"]
    O1["Link state, SPF"]
    O2["AD 110"]
    O3["IP protocol 89, 224.0.0.5 and .6"]
    O4["Cost = reference bandwidth / interface bandwidth"]
    O5["Summarize only on ABR or ASBR"]
    O6["Equal-cost load balancing only"]
  end

The comparison questions focus on algorithm, administrative distance, metric, where summarization is allowed and load balancing. OSPF's default reference bandwidth is 100 Mbps, so every link of 100 Mbps or faster gets cost 1 unless you raise auto-cost reference-bandwidth. EIGRP is the only one of the two that can load balance over unequal-cost paths.

E24. OSPF multi-area design and LSA flow

Blueprint 3.2.b

graph LR
  subgraph A1 ["Area 1"]
    R1["R1 internal"]
  end
  subgraph A0 ["Area 0 backbone"]
    R2["R2 ABR"]
    R3["R3 backbone"]
    R4["R4 ABR"]
  end
  subgraph A2 ["Area 2"]
    R5["R5 ASBR"]
  end
  EXT["External EIGRP domain"]
  R1 ---|"Type 1, 2 stay in area 1"| R2
  R2 ---|"Type 3 summaries both ways"| R3
  R3 --- R4
  R4 ---|"Type 3 and Type 4 into area 2"| R5
  EXT -->|"redistribute"| R5
  R5 -->|"Type 5 floods to all normal areas"| R4

Type 1 (router) and Type 2 (network) LSAs never leave their area. ABRs turn them into Type 3 summaries for other areas, and an ABR advertises a Type 4 so routers in other areas can reach the ASBR that originated Type 5 externals. All non-backbone areas must touch area 0, and summarization is done with area range on the ABR or summary-address on the ASBR.

E25. OSPF neighbor state machine

Blueprint 3.2.b

stateDiagram-v2
  [*] --> Down
  Down --> Init: Hello received
  state "2-Way" as TwoWay
  Init --> TwoWay: Own RID seen in neighbor Hello
  TwoWay --> TwoWay: DROther to DROther stops here
  TwoWay --> ExStart: Adjacency needed, elect master
  ExStart --> Exchange: DBD packets
  Exchange --> Loading: LSR and LSU
  Loading --> Full: Databases synchronised
  Full --> Down: Dead timer expires

Two DROthers on a broadcast segment staying at 2-Way is normal and is a popular trap. A neighbor stuck in ExStart or Exchange usually means an MTU mismatch. A neighbor stuck in Init means Hellos only work in one direction, often because of an ACL or a mismatched authentication setting on one side.

E26. DR and BDR election on a broadcast segment

Blueprint 3.2.b

graph TB
  SWX["Shared Ethernet segment 10.0.0.0/24"]
  RA["RA<br/>priority 1, RID 4.4.4.4<br/>DR"] --- SWX
  RB["RB<br/>priority 1, RID 3.3.3.3<br/>BDR"] --- SWX
  RC["RC<br/>priority 1, RID 2.2.2.2<br/>DROther"] --- SWX
  RD["RD<br/>priority 0, RID 9.9.9.9<br/>never DR or BDR"] --- SWX

The highest priority wins and the highest router ID breaks a tie, and priority 0 removes a router from the election. RD has the highest RID but priority 0, so RA becomes DR and RB becomes BDR. The election is not preemptive, so a better router that boots later does not take over until the DR and BDR fail. DROthers send updates to 224.0.0.6 (DR and BDR), and the DR floods them to 224.0.0.5 (all OSPF routers).

E27. OSPF adjacency checklist

Blueprint 3.2.b

graph TB
  S["Neighbor not forming"] --> C1{"Same area and subnet?"}
  C1 -->|"no"| F1["Fix area ID or addressing"]
  C1 -->|"yes"| C2{"Hello and dead timers match?"}
  C2 -->|"no"| F2["Fix timers"]
  C2 -->|"yes"| C3{"Authentication matches?"}
  C3 -->|"no"| F3["Fix key or type"]
  C3 -->|"yes"| C4{"Area flags match, stub or NSSA?"}
  C4 -->|"no"| F4["Fix area type"]
  C4 -->|"yes"| C5{"Interface passive?"}
  C5 -->|"yes"| F5["Remove passive-interface"]
  C5 -->|"no"| C6{"Stuck in ExStart or Exchange?"}
  C6 -->|"yes"| F6["MTU mismatch"]
  C6 -->|"no"| F7["Check unique RID and network type"]

The values that must match for an adjacency are area, subnet and mask, hello and dead timers, authentication and area type flags. A passive interface sends no Hellos at all. Network type mismatches, such as point-to-point on one side and broadcast on the other, can bring the adjacency to Full while routes still fail to install correctly.

E28. eBGP between directly connected neighbors

Blueprint 3.2.c

graph LR
  subgraph AS1 ["AS 65001"]
    R1["R1<br/>neighbor 203.0.113.2 remote-as 65002<br/>network 10.1.0.0 mask 255.255.0.0"]
  end
  subgraph AS2 ["AS 65002"]
    R2["R2<br/>neighbor 203.0.113.1 remote-as 65001"]
  end
  R1 ---|"Gi0/0 203.0.113.0/30, TCP 179, TTL 1"| R2

eBGP neighbors are normally directly connected, and IOS sends eBGP packets with TTL 1 by default. The session runs over TCP 179, and the network statement only advertises a prefix when an exact match (prefix and mask) is in the routing table. If the session does not come up, check the remote AS, the neighbor address and reachability on TCP 179.

E29. BGP finite state machine

Blueprint 3.2.c

stateDiagram-v2
  [*] --> Idle
  Idle --> Connect: Start, TCP connect attempt
  Connect --> OpenSent: TCP up, OPEN sent
  Connect --> Active: TCP attempt failed
  Active --> OpenSent: TCP up, OPEN sent
  Active --> Idle: Error
  OpenSent --> OpenConfirm: Valid OPEN received
  OpenConfirm --> Established: KEEPALIVE received
  Established --> Idle: Notification or hold timer expires

Established is the only state where routes are exchanged. A neighbor flapping between Idle and Active usually cannot complete the TCP session, which points to reachability, a wrong neighbor address or an ACL blocking TCP 179. In show ip bgp summary, a number in the State/PfxRcd column means Established and shows how many prefixes were received.

E30. Policy-based routing overview

Blueprint 3.2.d

graph LR
  G["Guest LAN 10.50.0.0/24"] --> R["Edge router<br/>Gi0/2 ip policy route-map GUEST"]
  C["Corp LAN 10.10.0.0/24"] --> R
  R -->|"guest: set ip next-hop 198.51.100.1"| ISPB["ISP B, cheap broadband"]
  R -->|"corp: routing table, default route"| ISPA["ISP A, primary"]

PBR overrides the routing table for traffic that matches a route-map, using criteria such as source address rather than only destination. It is applied to the ingress interface, so it affects packets arriving on that interface and not traffic the router generates itself. Traffic that does not match falls back to normal destination-based routing.

3.3 IP Services

E31. NTP stratum and PTP clock roles

Blueprint 3.3.a

graph TB
  subgraph NTP ["NTP hierarchy"]
    direction TB
    GPS["Reference clock, stratum 0"] --> S1["Server stratum 1"]
    S1 --> S2["Core router stratum 2"]
    S2 --> S3["Access switch stratum 3"]
  end
  subgraph PTP ["PTP (IEEE 1588)"]
    direction TB
    GM["Grandmaster clock"] --> BC["Boundary clock<br/>slave upstream, master downstream"]
    BC --> TC["Transparent clock<br/>corrects for residence time"]
    TC --> OC["Ordinary clock<br/>end device"]
  end

Each NTP hop adds one to the stratum, and a lower stratum is closer to the reference clock. A device configured with ntp master advertises itself as a source (stratum 8 by default). PTP achieves sub-microsecond accuracy with hardware timestamping, and the exam expects you to tell boundary clocks (which terminate and regenerate PTP) from transparent clocks (which pass it through and add a correction).

E32. NAT address terms

Blueprint 3.3.b

graph TB
  H["Inside host<br/>inside local 10.1.1.10"] -->|"Gi0/1 ip nat inside"| R["NAT router"]
  R -->|"Gi0/0 ip nat outside<br/>inside global 203.0.113.5"| NET["Internet"]
  NET --> W["Web server<br/>outside global 198.51.100.80<br/>outside local 198.51.100.80"]

Inside and outside describe which side of the router the host is on, while local and global describe where the address is seen from. The inside local address is the private address of the inside host, and the inside global address is what the Internet sees. PAT (overload) maps many inside locals to one inside global by tracking source ports, and show ip nat translations lists all four address columns.

E33. HSRP with interface tracking

Blueprint 3.3.c

graph TB
  ISP1["ISP 1"] ---|"Gi0/0 tracked"| R1["R1<br/>priority 110, preempt<br/>track 1 decrement 20<br/>ACTIVE"]
  ISP2["ISP 2"] --- R2["R2<br/>priority 100, preempt<br/>STANDBY"]
  R1 ---|"VIP 10.1.1.1"| LAN["LAN 10.1.1.0/24<br/>hosts use gateway 10.1.1.1"]
  R2 --- LAN

R1 is active with priority 110. If its tracked uplink goes down, its priority drops to 90 and R2 (priority 100, preempt) takes over the virtual IP. The default HSRP priority is 100, preempt is off by default, and the default track decrement is 10, so a decrement of 10 here would only drop R1 to 100, equal to R2, which does not guarantee a failover. HSRP version 1 uses 224.0.0.2 and version 2 uses 224.0.0.102 on UDP 1985, while VRRP uses 224.0.0.18, IP protocol 112, and preempts by default.

E34. PIM sparse mode: shared tree and shortest-path tree

Blueprint 3.3.d

graph TB
  SRC["Source 10.9.9.9"] --> FHR["First-hop router<br/>sends Register to RP"]
  FHR -->|"(S,G) tree to RP"| RP["Rendezvous point"]
  RP -->|"shared tree (*,G)"| MID["R-mid"]
  MID --> LHR["Last-hop router"]
  LHR --> RCV["Receiver joined 239.1.1.1"]
  FHR -.->|"SPT (S,G) after switchover"| LHR

Receivers first join the shared tree rooted at the RP, shown as (,G). The source's first-hop router registers with the RP in unicast Register messages, and the RP joins toward the source and sends Register-Stop. On IOS the last-hop router switches to the shortest-path tree (S,G) after the first packet by default, so traffic can bypass the RP entirely. Bidirectional PIM uses only (,G) shared trees and never switches to an SPT.

E35. IGMP join and leave

Blueprint 3.3.d

sequenceDiagram
  participant H as Host
  participant R as Last-hop router
  participant RP as RP
  R->>H: General Query to 224.0.0.1
  H->>R: IGMPv2 Membership Report for 239.1.1.1
  R->>RP: PIM (*,G) Join toward the RP
  RP->>R: Multicast traffic down the shared tree
  R->>H: Traffic for 239.1.1.1
  H->>R: IGMPv2 Leave to 224.0.0.2
  R->>H: Group-specific Query for 239.1.1.1
  Note over R: No report, so prune the group

IGMP runs between hosts and their router, and PIM runs between routers. In IGMPv2 the host sends its report to the group address and its leave to 224.0.0.2, and the router confirms with a group-specific query before pruning. IGMPv3 reports go to 224.0.0.22 and can list specific sources, which is what SSM needs.

E36. Source-specific multicast

Blueprint 3.3.d

graph TB
  RCV["Receiver<br/>IGMPv3 join (10.9.9.9, 232.1.1.1)"] --> LHR["Last-hop router<br/>ip pim ssm default"]
  LHR -->|"PIM (S,G) join straight to source"| MID["Transit router"]
  MID --> FHR["First-hop router"]
  FHR --> SRC["Source 10.9.9.9"]

SSM uses the 232.0.0.0/8 range and needs IGMPv3 on receivers, because the host names both the source and the group. There is no RP and no shared tree, so the last-hop router builds an (S,G) tree directly toward the source. SSM suits one-to-many applications where the receiver knows the source address in advance.

E37. MSDP between rendezvous points

Blueprint 3.3.d

graph LR
  subgraph D1 ["PIM domain A"]
    S["Source"] --> RPA["RP A"]
  end
  subgraph D2 ["PIM domain B"]
    RPB["RP B"] --> RV["Receiver"]
  end
  RPA ---|"MSDP peering, TCP 639<br/>Source-Active message"| RPB

Each PIM-SM domain has its own RP, and MSDP lets RPs tell each other about active sources using Source-Active messages over TCP 639. When RP B has receivers for the group, it joins toward the source in domain A. MSDP is also how Anycast RP shares source information between several RPs that use the same address.

E38. Multicast RPF check

Blueprint 3.3.d

graph LR
  SRC["Source 10.9.9.9"] --- R1["R1"]
  R1 ---|"Gi0/1, unicast route to 10.9.9.9"| R3["R3"]
  R1 --- R2["R2"]
  R2 ---|"Gi0/2, not the route to source"| R3
  R3 --> RX["Receivers"]

R3 accepts multicast from 10.9.9.9 only on Gi0/1, because that is the interface its unicast routing table uses to reach the source. A copy arriving on Gi0/2 fails the RPF check and is dropped, which prevents loops. If the unicast route and the multicast path disagree, a static mroute fixes the RPF interface.

4.0 Network Assurance

E39. SNMP and syslog flows

Blueprint 4.1

graph LR
  NMS["NMS"] -->|"GET / SET, UDP 161"| DEV["Router agent"]
  DEV -->|"Trap / Inform, UDP 162"| NMS
  DEV -->|"Syslog, UDP 514"| SYS["Syslog server"]
  subgraph SEV ["Syslog severity"]
    L0["0 emergencies"] --- L1["1 alerts"] --- L2["2 critical"] --- L3["3 errors"]
    L3 --- L4["4 warnings"] --- L5["5 notifications"] --- L6["6 informational"] --- L7["7 debugging"]
  end

The manager polls the agent on UDP 161 and the agent sends traps and informs to UDP 162, where informs are acknowledged and traps are not. Syslog levels run from 0 (most severe) to 7, and setting logging trap 4 sends levels 0 through 4. Interface up/down messages are level 3 and line protocol changes are level 5, so the configured level decides whether they reach the server.

E40. Flexible NetFlow building blocks

Blueprint 4.2

graph LR
  REC["flow record<br/>match = key fields<br/>collect = non-key fields"] --> MON["flow monitor<br/>record + exporter + cache"]
  EXP["flow exporter<br/>destination, source, transport udp"] --> MON
  MON -->|"ip flow monitor MON input"| INT["Interface Gi0/0"]
  INT -->|"export packets"| COL["NetFlow collector"]

Flexible NetFlow has three parts: a record that defines which fields identify a flow, an exporter that defines where the data goes, and a monitor that ties them together and is applied to an interface in a direction. Key fields (match) define a unique flow, and non-key fields (collect) are just counted or recorded. Verify with show flow monitor MON cache and show flow exporter.

E41. SPAN, RSPAN and ERSPAN

Blueprint 4.3

graph LR
  subgraph LOC ["Local SPAN"]
    P1["Source Gi1/0/1"] --> SW1["Switch"] --> AN1["Analyzer Gi1/0/48"]
  end
  subgraph RS ["RSPAN"]
    P2["Source port"] --> SWA["Source switch"] -->|"RSPAN VLAN over trunks"| SWB["Destination switch"] --> AN2["Analyzer"]
  end
  subgraph ER ["ERSPAN"]
    P3["Source port"] --> RA["Source router or switch"] -->|"GRE over routed network"| RB["Destination device"] --> AN3["Analyzer"]
  end

Local SPAN copies traffic to a port on the same switch. RSPAN carries the copy across Layer 2 trunks in a dedicated VLAN configured with remote-span. ERSPAN wraps the copy in GRE so it can cross a routed network, and both ends must use the same ERSPAN ID.

E42. IP SLA tracking for default route failover

Blueprint 4.4

graph LR
  R1["R1<br/>ip sla 1 icmp-echo 8.8.8.8<br/>track 1 ip sla 1 reachability"] ---|"Gi0/0 primary, next hop 203.0.113.1"| ISP1["ISP 1"]
  R1 ---|"Gi0/1 backup, next hop 198.51.100.1"| ISP2["ISP 2"]
  ISP1 --> INET["Internet 8.8.8.8"]
  ISP2 --> INET

The primary default route is ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1, and the backup is a floating static with a higher administrative distance, such as 10. When the probe fails, the track object goes down, the primary route is removed and the floating route installs. The probe must be pinned to the primary path (source interface or a host route) or it will succeed through the backup and the route will flap.

E43. Catalyst Center workflow

Blueprint 4.5

graph TB
  D["Design<br/>sites, IP pools, settings, images"] --> P["Policy<br/>virtual networks, group policy, QoS"]
  P --> V["Provision<br/>discover, assign, push config"]
  V --> A["Assurance<br/>health scores, issues, path trace"]
  A -.->|"feedback"| D

Catalyst Center (formerly DNA Center) organises work into Design, Policy, Provision and Assurance. Design defines what the network should look like, Policy defines intent, Provision pushes it to devices and Assurance checks the result with telemetry. A question that asks where you define DHCP and DNS servers for a site expects Design.

E44. NETCONF and RESTCONF stacks

Blueprint 4.6

graph TB
  subgraph NC ["NETCONF"]
    direction TB
    N1["Content: YANG-modelled data, XML"] --- N2["Operations: get, get-config, edit-config"]
    N2 --- N3["Messages: rpc, rpc-reply"]
    N3 --- N4["Transport: SSH, TCP 830"]
  end
  subgraph RC ["RESTCONF"]
    direction TB
    R1["Content: YANG-modelled data, XML or JSON"] --- R2["Methods: GET, POST, PUT, PATCH, DELETE"]
    R2 --- R3["URI: /restconf/data/module:container"]
    R3 --- R4["Transport: HTTPS"]
  end

Both protocols carry YANG-modelled data. NETCONF uses XML RPCs over SSH on port 830 and supports candidate datastores and locking. RESTCONF maps the same data to HTTP methods over HTTPS, can use JSON (application/yang-data+json), and is enabled on IOS XE with restconf plus ip http secure-server.

5.0 Security

E45. AAA with TACACS+

Blueprint 5.1

sequenceDiagram
  participant U as Admin
  participant R as Router NAS
  participant T as TACACS+ server
  U->>R: SSH login as netadmin
  R->>T: Authentication START (TCP 49)
  T->>R: Authentication PASS
  U->>R: configure terminal
  R->>T: Authorization request for the command
  T->>R: Authorization PASS
  R->>T: Accounting record for the command
  T->>R: Accounting acknowledged

TACACS+ uses TCP 49, encrypts the whole payload, and separates authentication, authorization and accounting, which is what allows per-command authorization. RADIUS uses UDP 1812 and 1813, encrypts only the password and combines authentication with authorization. The method list aaa authentication login default group tacacs+ local falls back to local only when the server is unreachable, not when it rejects the user.

E46. 802.1X port authentication

Blueprint 5.4

sequenceDiagram
  participant S as Supplicant
  participant A as Switch authenticator
  participant R as RADIUS server ISE
  A->>S: EAP-Request Identity (EAPoL)
  S->>A: EAP-Response Identity
  A->>R: RADIUS Access-Request with EAP
  R->>A: Access-Challenge
  A->>S: EAP method exchange
  S->>A: Credentials
  A->>R: Access-Request
  R->>A: Access-Accept with VLAN or SGT
  A->>S: EAP-Success, port authorized

The supplicant speaks EAP over LAN (EAPoL) to the switch, and the switch relays EAP inside RADIUS to the authentication server. The switch never sees the credentials in the clear for tunnelled methods such as PEAP or EAP-TLS. The Access-Accept can return a VLAN, a downloadable ACL or an SGT, which is how endpoint security ties into TrustSec.

E47. Control plane policing

Blueprint 5.2

graph LR
  IN["Packets to the router itself"] --> CP["control-plane<br/>service-policy input COPP"]
  CP --> C1["class ROUTING<br/>OSPF, BGP: police high"]
  CP --> C2["class MGMT<br/>SSH, SNMP: police medium"]
  CP --> C3["class ICMP<br/>police low"]
  CP --> C4["class-default<br/>police low"]
  C1 --> RP["Route processor CPU"]
  C2 --> RP
  C3 --> RP
  C4 --> RP
  TR["Transit traffic"] -.->|"not affected"| FWD["Forwarded in hardware"]

CoPP is MQC applied under control-plane, and it protects the CPU from floods aimed at the router. It only affects traffic destined to or punted to the control plane, not traffic passing through. The trap is to forget that the ACLs used in class-maps must permit the traffic you want to classify, because a deny simply means "not in this class".

E48. TrustSec SGT classification, propagation and enforcement

Blueprint 5.4

graph TB
  U["Employee laptop"] -->|"802.1X, ISE assigns SGT 10"| AC["Access switch<br/>classification"]
  AC -->|"inline tagging, CMD header SGT 10"| DS["Distribution<br/>propagation"]
  DS -->|"SXP, TCP 64999, IP to SGT map"| FW["Firewall or router<br/>no inline tagging support"]
  DS -->|"inline tag"| DC["DC switch<br/>enforcement, SGACL"]
  DC --> SRV["Server SGT 20"]

TrustSec has three phases: classify the endpoint with an SGT, propagate the tag, and enforce policy with SGACLs based on source and destination group. Hardware that supports it carries the tag inline in the Cisco Meta Data header, and devices that cannot use SXP to share IP-to-SGT mappings over TCP 64999. Enforcement is usually at the egress device, close to the destination.

E49. MACsec hop-by-hop encryption

Blueprint 5.4

graph TB
  H["Host"] ===|"MACsec encrypted, 802.1AE"| SW1["Access switch"]
  SW1 -.->|"clear inside the switch"| SW1
  SW1 ===|"MACsec encrypted"| SW2["Distribution switch"]
  SW2 ===|"MACsec encrypted"| SW3["Core switch"]

MACsec (IEEE 802.1AE) encrypts frames on each link at Layer 2, and each switch decrypts, processes and re-encrypts the frame. That means the switch can still apply QoS, ACLs and inspection, unlike end-to-end IPsec. Keys are negotiated with MKA, and the host-to-switch case is usually tied to 802.1X.

6.0 Automation and AI

E50. REST API call flow with status codes

Blueprint 6.5

sequenceDiagram
  participant S as Python script
  participant C as Catalyst Center
  S->>C: POST /dna/system/api/v1/auth/token with Basic auth
  C->>S: 200 OK, body contains Token
  S->>C: GET /dna/intent/api/v1/network-device with X-Auth-Token
  C->>S: 200 OK, JSON list of devices
  S->>C: POST a request that starts a task
  C->>S: 202 Accepted, taskId returned
  S->>C: GET with an expired token
  C->>S: 401 Unauthorized

Know the common codes: 200 OK, 201 Created, 202 Accepted (work started asynchronously), 204 No Content, 400 Bad Request, 401 Unauthorized (missing or bad credentials), 403 Forbidden (authenticated but not allowed), 404 Not Found and 500 Internal Server Error. Catalyst Center returns a token from the auth endpoint and expects it in the X-Auth-Token header. A 202 means you must poll the task ID to learn whether the job succeeded.

E51. REST API security controls

Blueprint 5.3

graph LR
  CL["API client"] -->|"HTTPS only, TLS"| GW["API endpoint"]
  GW --> AU{"Valid token or key?"}
  AU -->|"no"| E401["401 Unauthorized"]
  AU -->|"yes"| AZ{"Role allows this call?"}
  AZ -->|"no"| E403["403 Forbidden"]
  AZ -->|"yes"| RL{"Under rate limit?"}
  RL -->|"no"| E429["429 Too Many Requests"]
  RL -->|"yes"| OK["200 / 201 / 202"]

REST API security relies on transport encryption (HTTPS), authentication (basic auth to obtain a token, API keys or OAuth bearer tokens) and authorization by role. A client that is authenticated but lacks permission gets 403, while one with missing or wrong credentials gets 401. Credentials should never be hard-coded in scripts or sent over plain HTTP.

E52. EEM applet structure

Blueprint 6.6

graph TB
  EV["Event detector<br/>syslog, track, timer, CLI, interface"] --> AP["event manager applet UPLINK-DOWN<br/>event syslog pattern<br/>GigabitEthernet0/0, changed state to down"]
  AP --> A1["action 1.0 cli command enable"]
  A1 --> A2["action 2.0 cli command conf t"]
  A2 --> A3["action 3.0 cli command interface Gi0/0"]
  A3 --> A4["action 4.0 syslog msg Uplink bounced"]

An EEM applet has exactly one event statement and a series of actions that run in label order, sorted as strings rather than numbers. CLI actions start in user EXEC mode, so an applet that changes configuration needs enable and configure terminal actions first. Common event detectors are syslog patterns, track objects, timers, CLI commands and interface counters.

E53. Agent-based vs agentless configuration management

Blueprint 6.7

graph TB
  subgraph AG ["Agent based, pull"]
    PM["Puppet server, TCP 8140<br/>manifests"] --- PA["Puppet agent on node"]
    CS["Chef server, HTTPS<br/>cookbooks and recipes, Ruby"] --- CA["chef-client on node"]
    SM["Salt master, ZeroMQ 4505/4506"] --- SA["Salt minion"]
  end
  subgraph AL ["Agentless, push"]
    AN["Ansible control node<br/>YAML playbooks"] -->|"SSH or API"| N1["Router"]
    AN -->|"SSH or API"| N2["Switch"]
  end

Puppet and Chef use agents that pull configuration from a server. SaltStack normally uses minion agents with a master that pushes over ZeroMQ, and it also has an agentless SSH mode. Ansible is agentless and pushes changes over SSH or APIs from a control node using YAML playbooks, which makes it the usual answer for network devices that cannot run an agent.

E54. YANG data tree to JSON payload

Blueprint 6.2, 6.3

graph LR
  M["module ietf-interfaces"] --> C["container interfaces"]
  C --> L["list interface<br/>key name"]
  L --> F1["leaf name: GigabitEthernet2"]
  L --> F2["leaf description: WAN"]
  L --> F3["leaf enabled: true"]
  L --> F4["leaf type: ianaift:ethernetCsmacd"]

YANG containers become JSON objects, lists become JSON arrays, and leaves become key-value pairs. In RESTCONF JSON the top-level key is prefixed with the module name, as in "ietf-interfaces:interfaces". Booleans such as enabled are JSON true or false without quotes, which is a common trap in payload construction questions.