Skip to content
Log in Sign up My account

ENARSI Diagram Library

Exam-style topology exhibits and concept diagrams for ENARSI 300-410 v1.1. ENARSI is a troubleshooting exam, so most of these show a topology where something is subtly wrong or where you must predict a path. Trace the path yourself before reading the explanation.

1.0 Layer 3 Technologies

N01. Administrative distance decides between sources

Blueprint 1.1

graph TB
  P["Same prefix 10.50.0.0/24 learned from several sources"] --> S1["Connected: 0"]
  P --> S2["Static: 1"]
  P --> S3["eBGP: 20"]
  P --> S4["EIGRP internal: 90"]
  P --> S5["OSPF: 110"]
  P --> S6["IS-IS: 115"]
  P --> S7["RIP: 120"]
  P --> S8["EIGRP external: 170"]
  P --> S9["iBGP: 200"]
  S2 --> W["Lowest AD is installed in the RIB<br/>255 means never installed"]

When the same prefix with the same mask comes from two protocols, the lower AD wins and the metric is never compared across protocols. Longest prefix match still beats AD, because a /25 and a /24 are different routes. A floating static route uses an AD higher than the dynamic protocol (for example ip route 0.0.0.0 0.0.0.0 198.51.100.1 250) so it only installs when the dynamic route disappears.

N02. Two-point mutual redistribution feedback

Blueprint 1.3, 1.4

graph LR
  subgraph EIGRPD ["EIGRP AS 100"]
    R3["R3<br/>static 192.168.50.0/24<br/>redistributed: D EX, AD 170"]
  end
  subgraph OSPFD ["OSPF area 0"]
    R4["R4"]
  end
  R3 --- R1["R1<br/>EIGRP into OSPF<br/>OSPF into EIGRP"]
  R3 --- R2["R2<br/>EIGRP into OSPF<br/>OSPF into EIGRP"]
  R1 ---|"192.168.50.0/24 as O E2, AD 110"| R4
  R4 --- R2

R2 learns 192.168.50.0/24 as EIGRP external (AD 170) from R3 and as OSPF E2 (AD 110) from R1 through R4. OSPF wins, so R2 sends traffic for the prefix the long way through the OSPF domain, and if R1's path changes the two boundary routers can loop the route back and forth. The symptom on the exam is a suboptimal path or a flapping route in show ip route on one of two redistributing routers.

N03. Fixing redistribution feedback with tags

Blueprint 1.2, 1.3, 1.4

graph LR
  R3["R3 EIGRP domain"] --> R1["R1 route-map E2O<br/>set tag 100 on EIGRP into OSPF"]
  R1 -->|"OSPF routes carry tag 100"| R4["R4 OSPF domain"]
  R4 --> R2["R2 route-map O2E<br/>deny tag 100<br/>permit everything else"]
  R2 -->|"tag 100 routes are not sent back into EIGRP"| R3

Each boundary router tags routes as it redistributes them, and the other boundary router denies that tag when redistributing in the opposite direction. Configure it on both routers in both directions so neither domain receives its own routes back. A second fix for the AD problem is to raise OSPF external distance on the boundary routers, for example distance ospf external 175, so the EIGRP external route (170) wins.

N04. Route-map processing logic

Blueprint 1.2

graph TB
  RT["Route or packet"] --> SQ10{"Sequence 10:<br/>all match lines true?"}
  SQ10 -->|"yes, permit"| A10["Permitted, apply set lines, stop"]
  SQ10 -->|"yes, deny"| D10["Denied, stop"]
  SQ10 -->|"no"| SQ20{"Sequence 20:<br/>all match lines true?"}
  SQ20 -->|"yes"| A20["Act on sequence 20, stop"]
  SQ20 -->|"no"| IMP["Implicit deny at the end"]

Sequences are checked in order and the first matching sequence decides. Separate match lines in one sequence are ANDed, values on the same match line are ORed, and a sequence with no match line matches everything. In redistribution, a deny means "do not redistribute", and if the ACL inside a match denies a prefix it simply does not match that sequence.

N05. Summarization points

Blueprint 1.5

graph LR
  subgraph A1 ["OSPF area 1"]
    R1["R1<br/>10.1.0.0/24 to 10.1.3.0/24"]
  end
  R1 --- ABR["ABR<br/>area 1 range 10.1.0.0 255.255.252.0"]
  ABR ---|"area 0"| CORE["Core"]
  CORE --- ASBR["ASBR<br/>summary-address 172.16.0.0 255.255.0.0"]
  ASBR --- EXT["External routes 172.16.x.x"]
  CORE --- E1["EIGRP router<br/>ip summary-address eigrp 100 10.8.0.0 255.255.248.0<br/>on any interface"]

OSPF can only summarize at area borders: area range on an ABR for internal routes and summary-address on an ASBR for external routes. EIGRP can summarize on any outgoing interface and installs a discard route to Null0 with AD 5 on the summarizing router. A summary that covers addresses that do not exist can attract traffic that is then dropped at the Null0 route, which is a common troubleshooting answer.

N06. PBR next-hop decision

Blueprint 1.6

graph TB
  PK["Packet arrives on interface with<br/>ip policy route-map PBR"] --> M{"Matches a permit<br/>sequence?"}
  M -->|"no, or matches deny"| NR["Normal destination routing"]
  M -->|"yes"| T{"set ip next-hop<br/>or set ip default next-hop?"}
  T -->|"next-hop"| NH{"Next hop adjacent and up?"}
  NH -->|"yes"| USE["Forward to the PBR next hop"]
  NH -->|"no"| NR
  T -->|"default next-hop"| RIB{"Explicit route in RIB?<br/>default route does not count"}
  RIB -->|"yes"| NR
  RIB -->|"no"| USE2["Forward to the default next hop"]

set ip next-hop is used before the routing table, while set ip default next-hop is used only when the RIB has no explicit route for the destination. PBR is applied inbound on the interface where traffic arrives, so router-generated traffic needs ip local policy route-map instead. show route-map match counters and debug ip policy show whether packets are policy routed.

N07. VRF-Lite multi-tenant edge

Blueprint 1.7

graph LR
  subgraph PE ["Shared router R1"]
    VA["VRF CUST-A<br/>Gi0/0.10"]
    VB["VRF CUST-B<br/>Gi0/0.20"]
    GL["Global table<br/>Gi0/1"]
  end
  CA["Customer A LAN 10.10.0.0/16"] --- VA
  CB["Customer B LAN 10.10.0.0/16"] --- VB
  VA ---|"OSPF process 10 vrf CUST-A"| R2A["R2 Gi0/0.10, VRF CUST-A"]
  VB ---|"OSPF process 20 vrf CUST-B"| R2B["R2 Gi0/0.20, VRF CUST-B"]
  GL --- MGMT["Management network"]

Interfaces are bound with vrf forwarding NAME, which removes any IP address already configured, so the address must be re-entered afterwards. Each VRF needs its own routing process or address family, and overlapping customer prefixes are fine because the tables are separate. Commands such as ping, traceroute and show ip route need the vrf NAME keyword or they test the global table.

N08. BFD with OSPF and BGP

Blueprint 1.8

graph LR
  R1["R1<br/>bfd interval 50 min_rx 50 multiplier 3<br/>ip ospf bfd<br/>neighbor 10.0.0.2 fall-over bfd"] ---|"switch in path, link light stays on at R1"| SWX["L2 switch"]
  SWX --- R2["R2<br/>same BFD settings"]
  R1 -.->|"BFD control packets, UDP 3784"| R2

When a switch sits between two routers, the far link can fail while the near interface stays up, so OSPF and BGP would wait for their dead or hold timers. BFD sends fast hellos and, with 50 ms and a multiplier of 3, declares the neighbor down in about 150 ms, then tells the registered protocols to tear down the adjacency. BFD does not form adjacencies itself, so it only helps protocols that have been told to use it.

N09. EIGRP successor and feasible successor

Blueprint 1.9

graph LR
  R1["R1"] ---|"cost 2000"| R2["R2<br/>RD 1000"]
  R1 ---|"cost 1500"| R3["R3<br/>RD 2000"]
  R1 ---|"cost 800"| R4["R4<br/>RD 3200"]
  R2 ---|"1000"| NET["10.9.9.0/24"]
  R3 ---|"2000"| NET
  R4 ---|"3200"| NET

R1 computes FD via R2 = 3000, via R3 = 3500 and via R4 = 4000, so R2 is the successor with FD 3000. R3 is a feasible successor because its RD (2000) is lower than the current FD (3000). R4 is not, because its RD (3200) is higher than 3000, even though it would be a working path, and only feasible successors can be used for unequal-cost load balancing with variance.

N10. EIGRP stub routers and query scope

Blueprint 1.9

graph TB
  HUB["Hub"] --- CORE["Core router<br/>loses 10.0.0.0/24, no FS<br/>goes Active"]
  HUB --- S1["Spoke 1<br/>eigrp stub connected summary"]
  HUB --- S2["Spoke 2<br/>eigrp stub"]
  HUB --- S3["Spoke 3<br/>not stub"]
  CORE -->|"Query"| HUB
  HUB -->|"Query sent"| S3
  HUB -.->|"no Query, stub"| S1
  HUB -.->|"no Query, stub"| S2

When a router loses a route with no feasible successor it goes Active and queries its neighbors, but stub routers are never queried. That shrinks the query domain and reduces the risk of stuck-in-active (SIA). The default active timer is 3 minutes, and the router sends an SIA-Query at half that time before it resets a neighbor that never replies.

N11. EIGRP unequal-cost load balancing with variance

Blueprint 1.9

graph LR
  R1["R1<br/>variance 2"] ---|"FD 3000, successor"| PA["via R2"]
  R1 ---|"FD 3500, RD 2000, FS"| PB["via R3"]
  R1 ---|"FD 4000, RD 3200, not FS"| PC["via R4"]
  PA --> N["10.9.9.0/24"]
  PB --> N
  PC --> N

With variance 2, R1 can install any path whose FD is less than 2 times 3000 (6000), but only if that path is also a feasible successor. The R3 path qualifies, while the R4 path fails the feasibility condition even though its FD of 4000 is under 6000. Traffic is shared in proportion to the metrics, controlled by traffic-share balanced.

N12. OSPF area types and the LSAs they accept

Blueprint 1.10

graph LR
  ABR["ABR"] -->|"Types 1-5 normal"| NA["Normal area"]
  ABR -->|"Type 3 plus default Type 3, no Type 4 or 5"| ST["Stub area<br/>area 1 stub"]
  ABR -->|"Only default Type 3, no other 3, 4 or 5"| TS["Totally stubby<br/>area 2 stub no-summary on ABR"]
  ABR -->|"Type 3, Type 7 inside, no Type 5"| NS["NSSA<br/>area 3 nssa"]
  ABR -->|"Default Type 3, Type 7 inside"| TN["Totally NSSA<br/>area 4 nssa no-summary"]
  NS -->|"ABR translates Type 7 to Type 5"| ABR

Stub areas block Type 5 externals and get a default route instead, and totally stubby areas also block Type 3s except the default. NSSA allows a local ASBR by carrying externals as Type 7, which the ABR translates to Type 5 for the rest of the domain. A plain NSSA does not get a default route automatically, so the ABR needs default-information-originate on the area nssa command, while totally NSSA gets one by default.

Blueprint 1.10

graph TB
  subgraph A0 ["Area 0"]
    BB["Backbone router"]
  end
  subgraph A1 ["Area 1, transit area"]
    ABR1["ABR1 RID 1.1.1.1<br/>area 1 virtual-link 2.2.2.2"]
    ABR2["ABR2 RID 2.2.2.2<br/>area 1 virtual-link 1.1.1.1"]
  end
  subgraph A2 ["Area 2, no link to area 0"]
    R5["R5"]
  end
  BB --- ABR1
  ABR1 ---|"virtual link through area 1"| ABR2
  ABR2 --- R5

Area 2 has no physical connection to area 0, so a virtual link is built across area 1 to extend the backbone to ABR2. The command uses the router ID of the far ABR, not an interface address, and is configured on both ends. The transit area cannot be a stub or NSSA area, and the virtual link appears as an area 0 interface in show ip ospf virtual-links.

N14. OSPF path preference

Blueprint 1.10

graph TB
  P1["O intra-area"] -->|"preferred over"| P2["O IA inter-area"]
  P2 -->|"preferred over"| P3["O E1 / O N1<br/>external, metric adds internal cost"]
  P3 -->|"preferred over"| P4["O E2 / O N2<br/>external, metric fixed, default type"]

OSPF picks the route type first and only compares cost between routes of the same type. An intra-area route with cost 500 beats an inter-area route with cost 10. E1 always beats E2 for the same prefix, and E2 is the default for redistributed routes, with a seed metric of 20 (1 for routes redistributed from BGP).

N15. OSPF router types

Blueprint 1.10

graph TB
  subgraph A1 ["Area 1"]
    IR["Internal router<br/>all interfaces in area 1"]
  end
  subgraph A0 ["Area 0"]
    BR["Backbone router"]
  end
  IR --- ABR["ABR<br/>interfaces in area 0 and area 1"]
  ABR --- BR
  BR --- ASBR["ASBR<br/>redistributes from EIGRP"]
  ASBR --- EX["EIGRP domain"]

An internal router has all interfaces in one area, a backbone router has at least one interface in area 0, an ABR connects area 0 to another area, and an ASBR injects external routes. One router can hold several roles at once, for example an ABR that also redistributes is both ABR and ASBR. show ip ospf states whether the router is an area border or AS boundary router.

N16. BGP best-path selection

Blueprint 1.11

graph TB
  S0["Next hop reachable?"] --> S1["1. Highest weight (Cisco, local only)"]
  S1 --> S2["2. Highest local preference, default 100"]
  S2 --> S3["3. Locally originated"]
  S3 --> S4["4. Shortest AS path"]
  S4 --> S5["5. Lowest origin: IGP, then EGP, then incomplete"]
  S5 --> S6["6. Lowest MED"]
  S6 --> S7["7. eBGP over iBGP"]
  S7 --> S8["8. Lowest IGP metric to next hop"]
  S8 --> S9["9. Oldest eBGP path"]
  S9 --> S10["10. Lowest router ID"]
  S10 --> S11["11. Lowest neighbor address"]

Each step is only used when the previous ones tie. Weight is local to one router and is not advertised, local preference is shared inside the AS, and MED is by default compared only between paths from the same neighboring AS. A route whose next hop is not reachable is never a candidate, which is the first thing to check when a prefix shows in the table without a >.

N17. iBGP full mesh vs route reflector

Blueprint 1.11

graph TB
  subgraph FM ["Full mesh, n(n-1)/2 = 6 sessions"]
    F1["R1"] --- F2["R2"]
    F1 --- F3["R3"]
    F1 --- F4["R4"]
    F2 --- F3
    F2 --- F4
    F3 --- F4
  end
  subgraph RR ["Route reflector, 3 sessions"]
    RR1["RR<br/>neighbor x route-reflector-client"] --- C1["Client 1"]
    RR1 --- C2["Client 2"]
    RR1 --- C3["Client 3"]
  end

iBGP split horizon stops a router from advertising an iBGP-learned route to another iBGP peer, so without reflection every iBGP speaker must peer with every other one. A route reflector relaxes the rule: routes from a client go to all clients and non-clients, and routes from a non-client go only to clients. The ORIGINATOR_ID and CLUSTER_LIST attributes prevent loops between reflectors, and the RR does not change the next hop.

N18. The next-hop-self problem

Blueprint 1.11

graph TB
  ISP["ISP AS 65100<br/>203.0.113.1"] ---|"eBGP 203.0.113.0/30"| R1["R1 AS 65000<br/>border"]
  R1 ---|"iBGP, OSPF inside"| R2["R2 AS 65000<br/>internal"]
  R2 -.-|"learns 8.8.8.0/24 next hop 203.0.113.1<br/>no route to 203.0.113.1"| X["Route not usable"]

iBGP does not change the next hop of routes learned from eBGP, so R2 sees the ISP address 203.0.113.1 as next hop. If that /30 is not in R2's IGP, the route is in the BGP table but not marked best and never reaches the RIB. Fix it with neighbor 10.0.0.2 next-hop-self on R1, or by advertising the external link into the IGP as a passive interface.

N19. Influencing traffic with local preference and AS-path prepend

Blueprint 1.11

graph LR
  subgraph AS65000 ["AS 65000"]
    R1["R1<br/>inbound: set local-preference 200"]
    R2["R2<br/>outbound: prepend 65000 65000"]
  end
  R1 ---|"preferred exit"| ISPA["ISP A"]
  R2 ---|"backup"| ISPB["ISP B"]
  ISPA --- NET["Internet"]
  ISPB --- NET

Local preference is set on routes you receive, and it controls outbound traffic: the whole AS leaves through R1 because 200 beats the default 100. AS-path prepending is applied to routes you advertise, and it influences inbound traffic by making the path through ISP B look longer to the rest of the Internet. Remember the direction mapping: inbound policy affects outbound traffic, and outbound policy affects inbound traffic.

N20. BGP inbound and outbound policy attachment points

Blueprint 1.11

graph LR
  PEER["eBGP peer"] -->|"updates"| IN["neighbor x route-map IN-POL in<br/>prefix-list, filter-list"]
  IN --> TBL["BGP table, best path"]
  TBL --> OUT["neighbor x route-map OUT-POL out"]
  OUT -->|"updates"| PEER2["Other peers"]
  TBL --> RIB["RIB"]

Filters and route-maps can be applied per neighbor in each direction, and changes only take effect after the session is refreshed. Use clear ip bgp x soft in or soft out (route refresh) rather than a hard reset. If a route-map has no permit sequence that matches, the implicit deny drops every prefix, which shows up as zero prefixes received.

2.0 VPN Technologies

N21. MPLS LSP with label push, swap and pop

Blueprint 2.1

graph TB
  CE1["CE1"] -->|"IP packet"| PE1["PE1 ingress LSR<br/>PUSH label 22"]
  PE1 -->|"label 22"| P1["P1<br/>SWAP 22 to 35"]
  P1 -->|"label 35"| P2["P2 penultimate hop<br/>POP, implicit null"]
  P2 -->|"IP packet"| PE2["PE2 egress LSR"]
  PE2 --> CE2["CE2"]

The ingress LSR pushes a label, each P router swaps it, and penultimate hop popping removes the label one hop before the egress so the egress does only one lookup. The egress advertises implicit null (label 3) to request PHP. LDP discovers neighbors with hellos to 224.0.0.2 on UDP 646 and forms sessions on TCP 646, and show mpls forwarding-table shows the local label, outgoing label and next hop for each prefix.

N22. MPLS L3VPN with RD, RT and VPNv4

Blueprint 2.2

graph TB
  CEA1["CE-A site 1<br/>10.1.0.0/16"] ---|"eBGP, OSPF, EIGRP or static"| PE1["PE1<br/>vrf CUST-A<br/>RD 65000:1<br/>RT export 65000:100<br/>RT import 65000:100"]
  PE1 ===|"MP-BGP VPNv4<br/>65000:1:10.1.0.0/16, VPN label"| PE2["PE2<br/>vrf CUST-A<br/>RT import 65000:100"]
  PE1 ---|"LDP transport label"| P["P router"]
  P --- PE2
  PE2 --- CEA2["CE-A site 2"]

The RD is prepended to the IPv4 prefix to form a unique 96-bit VPNv4 route, so overlapping customer prefixes stay distinct in MP-BGP. The route target is an extended community that decides which VRFs import the route, so a missing or mismatched RT import is the usual reason a remote site's routes are missing. Packets carry two labels: an outer transport label from LDP to reach the egress PE and an inner VPN label from MP-BGP to pick the VRF.

N23. DMVPN phases and traffic paths

Blueprint 2.3

graph TB
  subgraph PH1 ["Phase 1"]
    direction TB
    H1["Hub mGRE"] --- A1["Spoke A p2p GRE"]
    H1 --- B1["Spoke B p2p GRE"]
    A1 -.->|"A to B always via hub"| H1
  end
  subgraph PH2 ["Phase 2"]
    direction TB
    H2["Hub mGRE<br/>no summarization, next hop preserved"] --- A2["Spoke A mGRE"]
    H2 --- B2["Spoke B mGRE"]
    A2 ===|"direct spoke-to-spoke tunnel"| B2
  end
  subgraph PH3 ["Phase 3"]
    direction TB
    H3["Hub mGRE<br/>ip nhrp redirect, summary allowed"] --- A3["Spoke A mGRE<br/>ip nhrp shortcut"]
    H3 --- B3["Spoke B mGRE<br/>ip nhrp shortcut"]
    A3 ===|"shortcut after redirect"| B3
  end

Phase 1 is hub and spoke only. Phase 2 allows direct spoke-to-spoke tunnels but the hub must preserve the original next hop, which means no summarization and no ip next-hop-self eigrp for EIGRP or a broadcast network type with the hub as DR for OSPF. Phase 3 lets the hub summarize and uses NHRP redirect and shortcut to build spoke-to-spoke paths.

N24. NHRP registration, resolution and redirect (Phase 3)

Blueprint 2.3

sequenceDiagram
  participant SA as Spoke A
  participant H as Hub NHS
  participant SB as Spoke B
  SA->>H: NHRP Registration Request: tunnel IP to NBMA IP
  H->>SA: Registration Reply
  SB->>H: NHRP Registration Request
  H->>SB: Registration Reply
  SA->>H: First data packet for Spoke B LAN
  H->>SB: Hub forwards the packet
  H->>SA: NHRP Redirect (traffic indication)
  SA->>H: NHRP Resolution Request for Spoke B LAN
  H->>SB: Forwards Resolution Request
  SB->>SA: Resolution Reply sent directly
  Note over SA: Installs NHRP shortcut route
  SA->>SB: Later traffic goes direct over a spoke-to-spoke tunnel

Spokes register their tunnel-to-NBMA mapping with the hub, which is the next hop server. In Phase 3 the hub sends a redirect when it forwards traffic between spokes, and the spoke then resolves the remote address and installs a shortcut. If spoke-to-spoke tunnels never form, check that ip nhrp redirect is on the hub, ip nhrp shortcut is on the spokes, and that IPsec or ACLs allow spoke-to-spoke traffic.

3.0 Infrastructure Security

N25. AAA method list fallback

Blueprint 3.1

graph TB
  L["aaa authentication login VTY group tacacs+ local"] --> Q{"TACACS+ server reachable?"}
  Q -->|"no, ERROR"| LOC["Try local username database"]
  Q -->|"yes"| R{"Server reply"}
  R -->|"PASS"| OK["Login allowed"]
  R -->|"FAIL"| NO["Login denied, local is NOT tried"]

The next method in a list is only tried when the previous one returns an error, such as no server reachable. A rejection (FAIL) from the server ends the process, so a user who exists only in the local database cannot log in while TACACS+ is up. The method list must be applied with login authentication VTY under the lines, or the default list is used.

N26. uRPF strict vs loose

Blueprint 3.2

graph LR
  subgraph ST ["Strict: reachable-via rx"]
    PA["Packet src 10.5.5.5<br/>arrives on Gi0/1"] --> CA{"Route to 10.5.5.5<br/>points out Gi0/1?"}
    CA -->|"yes"| FA["Forward"]
    CA -->|"no"| DA["Drop"]
  end
  subgraph LO ["Loose: reachable-via any"]
    PB["Packet src 10.5.5.5<br/>arrives on Gi0/1"] --> CB{"Any route to 10.5.5.5<br/>in the FIB?"}
    CB -->|"yes"| FB["Forward"]
    CB -->|"no"| DB["Drop"]
  end

Strict mode needs the best route back to the source to use the arrival interface, so it drops legitimate traffic on asymmetric paths such as dual-homed edges. Loose mode only needs some route to the source, which still blocks spoofed bogon or unallocated addresses. A default route does not satisfy either check unless allow-default is added.

N27. Control plane policing classes

Blueprint 3.3

graph TB
  CP["control-plane<br/>service-policy input COPP"] --> C1["CRITICAL: BGP, OSPF, EIGRP, BFD<br/>conform transmit"]
  CP --> C2["MANAGEMENT: SSH, SNMP, NTP, TACACS+<br/>police moderate rate"]
  CP --> C3["NORMAL: ICMP, traceroute<br/>police low rate"]
  CP --> C4["UNDESIRABLE: known bad ports<br/>drop"]
  CP --> C5["class-default<br/>police low rate"]

A good CoPP design gives routing protocols the most room, rate-limits management and ICMP, and catches everything else in class-default. Troubleshooting questions often show a routing adjacency flapping because its protocol fell into a heavily policed class, or SSH failing because its ACL entry is missing. show policy-map control-plane shows conformed and exceeded counters per class.

N28. IPv6 RA guard and DHCPv6 guard

Blueprint 3.4

graph LR
  RTR["Legitimate router"] -->|"RA permitted"| P1["Gi1/0/1<br/>device-role router"]
  P1 --- SW["Access switch"]
  SW --- P2["Gi1/0/10<br/>RA guard: device-role host"]
  ROGUE["Rogue host sending RAs"] -->|"RA dropped"| P2
  SW --- P3["Gi1/0/11<br/>DHCPv6 guard: device-role client"]
  RDHCP["Rogue DHCPv6 server"] -->|"Advertise and Reply dropped"| P3

RA guard drops Router Advertisements arriving on ports classified as host-facing, so a rogue host cannot become the default gateway for the segment. DHCPv6 guard does the same for server messages on client ports. Other IPv6 first hop features build on the binding table learned from ND and DHCPv6 snooping: ND inspection validates ND messages and source guard drops traffic from addresses not in the table.

N29. Time-based and extended ACL placement

Blueprint 3.2

graph LR
  USR["Users 10.1.0.0/16"] -->|"Gi0/1 in<br/>extended ACL near source"| R1["R1"]
  R1 --- WAN["WAN"]
  WAN --- R2["R2"]
  R2 -->|"Gi0/0 out<br/>standard ACL near destination"| SRV["Servers 10.9.0.0/24"]
  TR["time-range WORKHOURS<br/>periodic weekdays 8:00 to 18:00"] -.-> R1

Extended ACLs match source, destination, protocol and ports, so they go close to the source to drop traffic early. Standard ACLs match only the source, so they go close to the destination to avoid blocking other paths. A time-based ACL entry references a time-range and is only active inside that window, which depends on the router clock being correct, so check NTP when it behaves unexpectedly.

4.0 Infrastructure Services

N30. DHCP relay DORA

Blueprint 4.4

sequenceDiagram
  participant C as Client
  participant R as Router Gi0/1 10.1.1.1 with ip helper-address
  participant S as DHCP server 10.9.9.10
  C->>R: DHCPDISCOVER broadcast, UDP 67
  R->>S: Unicast relay, giaddr 10.1.1.1
  S->>R: DHCPOFFER from pool matching giaddr
  R->>C: DHCPOFFER
  C->>R: DHCPREQUEST broadcast
  R->>S: Unicast relay
  S->>R: DHCPACK
  R->>C: DHCPACK, address bound

Broadcasts do not cross routers, so ip helper-address on the client-facing interface turns them into unicasts to the server. The relay writes its interface address into giaddr, and the server uses giaddr to choose the matching pool. If clients get no address, check the helper is on the right interface, that the server has a pool for that subnet, and that the server has a route back to the giaddr subnet.

N31. DHCPv6 address assignment modes

Blueprint 4.4

graph TB
  RA["Router Advertisement flags"] --> SL["SLAAC only<br/>A=1, M=0, O=0<br/>address built from the RA prefix"]
  RA --> SS["Stateless DHCPv6<br/>A=1, O=1<br/>address by SLAAC, DNS and options by DHCPv6"]
  RA --> SF["Stateful DHCPv6<br/>M=1<br/>address and options by DHCPv6"]
  SS --> DH["Client to ff02::1:2, UDP 547<br/>Solicit, Advertise, Request, Reply"]
  SF --> DH

The M (managed) flag tells hosts to get addresses from DHCPv6, and the O (other config) flag tells them to get only other options such as DNS. On IOS XE, ipv6 nd managed-config-flag and ipv6 nd other-config-flag set them on the interface. DHCPv6 clients listen on UDP 546 and servers on 547, and ipv6 dhcp relay destination is the IPv6 equivalent of a helper address.

N32. SNMPv3 security levels

Blueprint 4.2

graph LR
  NA["noAuthNoPriv<br/>username only"] --> AN["authNoPriv<br/>HMAC SHA or MD5<br/>integrity and authentication"]
  AN --> AP["authPriv<br/>authentication plus encryption<br/>AES or DES"]
  AP --> CFG["snmp-server group NMS v3 priv<br/>snmp-server user admin NMS v3 auth sha KEY1 priv aes 128 KEY2"]

SNMPv3 has three security levels, and the group level must match what the user is configured with. A group defined with priv requires users that have both auth and priv passwords, otherwise the manager gets authentication or decryption errors. SNMPv2c relies only on community strings sent in clear text, which is why the exam treats v3 authPriv as the secure option.

N33. IP SLA, object tracking and static route failover

Blueprint 4.5

graph LR
  SLA["ip sla 10<br/>icmp-echo 203.0.113.1 source-interface Gi0/0<br/>frequency 5"] --> TRK["track 10 ip sla 10 reachability"]
  TRK --> RT1["ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 10"]
  RT2["ip route 0.0.0.0 0.0.0.0 198.51.100.1 5<br/>floating static"]
  RT1 -->|"track up: installed"| RIB["RIB default route"]
  RT2 -->|"only when track 10 is down"| RIB

The SLA operation does nothing until it is started with ip sla schedule 10 life forever start-time now, which is a frequent missing line in exhibits. The track object follows the SLA result, the tracked static route is withdrawn when it goes down, and the floating static with AD 5 takes over. show track and show ip sla statistics confirm whether the probe and track object are up.

N34. NetFlow v5 vs v9 export

Blueprint 4.6

sequenceDiagram
  participant R as Router exporter
  participant C as Collector
  Note over R,C: Version 5: fixed format, IPv4 only
  R->>C: v5 export packet with fixed fields
  Note over R,C: Version 9: template based
  R->>C: Template FlowSet: field types and lengths
  R->>C: Data FlowSet using template ID
  R->>C: Template resent periodically
  R->>C: More Data FlowSets

NetFlow v5 has a fixed record format and cannot describe IPv6, MPLS labels or custom fields. NetFlow v9 sends templates that describe the record layout, so the collector cannot decode data until it has received the template, which explains a short gap after a collector restarts. Flexible NetFlow exports with v9 or IPFIX.

N35. Device management access

Blueprint 4.1

graph LR
  ADM["Admin 10.99.0.5"] -->|"SSH, TCP 22"| VTY["line vty 0 4<br/>transport input ssh<br/>access-class MGMT in<br/>login local"]
  OTH["Other host 10.20.0.5"] -.->|"refused by access-class"| VTY
  ADM -->|"HTTPS, TCP 443"| WEB["ip http secure-server"]
  ADM -->|"SCP over SSH"| FILE["ip scp server enable"]

SSH needs a hostname, a domain name, an RSA key and transport input ssh on the lines, and SSH version 2 is the recommended setting. access-class filters who can reach the VTY lines, and it is applied under the line, not on an interface. TFTP uses UDP 69 with no authentication, while SCP and SFTP run over SSH and are the secure choices for file transfer.

N36. Catalyst Center Assurance data flow

Blueprint 4.7

graph LR
  DEV["Routers, switches"] -->|"SNMP, syslog, NetFlow, streaming telemetry"| CC["Catalyst Center Assurance"]
  CC --> HS["Health scores<br/>network, client, application"]
  CC --> IS["Issues with suggested actions"]
  CC --> PT["Path trace"]
  CC --> TL["Time travel, history"]

Assurance collects telemetry from devices and turns it into health scores, issues and suggested fixes. Path trace shows the hop-by-hop path between two endpoints and flags ACLs that would block the flow. Time travel lets you look back at the state of a device or client at the moment a problem happened.