# PacketMentor — Full Content > 1:1 mentorship for Cisco networking careers — CCNA, CCNP, CompTIA Network+, and Fortinet NSE 4. US-focused, senior-engineer-led, "don't just pass the CCNA — get hired." This is the fuller-content variant of /llms.txt. It contains the complete markdown of every topic page and blog post so language models can answer user questions with accurate, up-to-date content and cite packetmentor.com as the source. For a summarised index of all training programs, resources, and pages, see https://packetmentor.com/llms.txt. --- # Topics 129 topic pages, ordered by natural study sequence. --- ## OSI Model & TCP/IP — https://packetmentor.com/topics/osi-tcp-ip/ > Two networking reference models compared side-by-side. The seven OSI layers, the four TCP/IP layers, and which one the real internet actually runs on (spoiler: not OSI). ## Mental model The OSI model is a teaching tool. Nobody actually built the internet to OSI's seven layers — TCP/IP, with its four layers, came first and won. But OSI's seven-layer breakdown is so good at *describing* what a network does that everyone in the industry still uses the layer numbers when talking about problems. When a senior engineer says *"that's a layer-3 issue"*, they mean it's an IP routing problem. *"Layer 2"* means switching, MAC addresses, VLANs. *"Layer 7"* means application-level (HTTP, DNS, SSH). Learning the layers gives you that vocabulary. ## The seven OSI layers, in plain English | # | Layer | What lives here | Example | |---|---|---|---| | 7 | Application | The app you're using | HTTP, DNS, SMTP, SSH | | 6 | Presentation | Format / encryption | TLS, ASCII, JPEG | | 5 | Session | Conversation state | SSL session, NetBIOS | | 4 | Transport | End-to-end reliability + ports | TCP, UDP | | 3 | Network | Logical addressing + routing | IP, ICMP, OSPF | | 2 | Data Link | Local frame delivery + MAC | Ethernet, 802.1Q, ARP, STP | | 1 | Physical | Bits on wire / radio | Cat6 cable, 1000BASE-T, RJ-45 | **The exam mnemonic:** *All People Seem To Need Data Processing* (top to bottom). Or the cleaner: *Please Do Not Throw Sausage Pizza Away* (bottom to top). ## The four TCP/IP layers — what actually exists | TCP/IP Layer | Maps to OSI | What it is | |---|---|---| | Application | 5 + 6 + 7 | All the app protocols smushed together | | Transport | 4 | TCP and UDP. Ports live here. | | Internet | 3 | IP, ICMP. Routing happens here. | | Network Access | 1 + 2 | Ethernet, Wi-Fi, fiber — the wire and the frame format | If you're reading an RFC or vendor doc, you'll see TCP/IP terms. If you're talking to a CCNA instructor or troubleshooting a ticket, you'll hear OSI numbers. Be fluent in both. ## How layers actually wrap each other (encapsulation) When your laptop sends an HTTP request, each lower layer wraps the data from the layer above it. Read the diagram inside-out — HTTP is the payload; each outer layer adds its own header (and Ethernet also adds a trailer).
OSI encapsulation stackNested rectangles showing an HTTP payload wrapped by TCP, then IP, then an Ethernet frame with header and trailer, sent as bits on the wire.ETH hdrETH trailerL2 Ethernet frameIP hdrL3 packetTCP hdrL4 segmentL7 HTTP payloadL7 payload — the actual HTTP request (data)L4 TCP header wraps L7 (segment; ports, seq/ack)L3 IP header wraps L4 (packet; src/dst IP)L2 Ethernet header + trailer wrap L3 (frame; MAC + FCS)L1 bits on the wire ──▶Sender: wrap inside-out (L7 → L2)Receiver: unwrap outside-in (L2 → L7)
Encapsulation: L7 payload sits at the centre. Each outer layer adds its header (L2 also adds a trailer). On the wire it's all just L1 bits.
The receiver unwraps in the reverse order. Each layer reads its own header, strips it, and passes the rest up. The CCNA-favorite terms for the wrapped unit at each layer: - **Layer 7** payload: **data** - **Layer 4**: **segment** (TCP) or **datagram** (UDP) - **Layer 3**: **packet** - **Layer 2**: **frame** - **Layer 1**: **bits** ## Practical use — naming problems by layer When a user says *"the internet is down"*, the goal is to figure out which layer broke. Top-down or bottom-up, both work — pros usually go bottom-up because lower layers being broken makes higher layers irrelevant. | Symptom | Layer | What to check | |---|---|---| | Cable physically unplugged | 1 | `show interfaces` for "line protocol down" | | Port up, no traffic flowing | 2 | MAC table, STP state, VLAN assignment | | Can ping local gateway, can't ping outside | 3 | Routing table, ACLs, default route | | Can ping by IP but not by hostname | 7 | DNS resolution | | Web works, SSH doesn't | 4–7 | Firewall / ACL on specific ports | ## Common mistakes 1. **Mixing up OSI and TCP/IP layer numbers.** TCP/IP doesn't have layer numbers — saying "layer 5 of TCP/IP" is nonsense. Use OSI numbers (1–7) when numbering. 2. **Calling ARP a Layer 3 protocol.** It uses IP info but operates on MAC addresses — it's Layer 2 (or 2.5, depending on who you ask). 3. **Putting routing at Layer 2.** Switches are Layer 2 (MAC). Routers are Layer 3 (IP). A "Layer 3 switch" is a switch with routing capabilities — it does both. 4. **Calling everything above Layer 4 "the application".** Strictly, sessions and encryption are 5 and 6. In practice TCP/IP collapses them, but for the CCNA exam know the OSI distinctions. 5. **Forgetting the OSI model is descriptive, not prescriptive.** Real protocols often span layers or skip them. The model is for thinking, not for strict classification. ## Lab to try tonight 1. Open Wireshark and capture traffic on your laptop's interface. 2. Open a web page — capture for 30 seconds. 3. Pick one HTTP packet. Expand the layers in Wireshark — you'll see Ethernet (L2), IP (L3), TCP (L4), HTTP (L7). 4. Note the source/destination at each layer: MAC at L2, IP at L3, port at L4, URL at L7. 5. Bonus: open a DNS query packet. Note how DNS uses UDP at L4 (not TCP) and lives at L7. ## Cheat strip | Layer | Number | Sticks in memory as | |---|---|---| | Physical | 1 | Cables and bits | | Data Link | 2 | Frames and MAC addresses (switches) | | Network | 3 | Packets and IP addresses (routers) | | Transport | 4 | Ports — TCP (reliable) or UDP (fast) | | Session | 5 | Conversation state | | Presentation | 6 | Encryption + formatting (TLS, JPEG) | | Application | 7 | The thing the user clicked | ## Frequently asked questions **Q: Why does everyone still teach the OSI model if TCP/IP won?** A: OSI's seven layers are a better *teaching* tool — the finer breakdown gives senior engineers precise vocabulary ("that's a layer-2 issue" vs "that's a layer-3 issue"). TCP/IP's four layers are what the internet actually runs on. Every real-world diagnostic uses OSI numbers even though the protocol stack is TCP/IP. Learn both, use OSI numbers when talking to other engineers. **Q: What layer does a firewall operate at?** A: Depends on the firewall. A traditional packet-filter firewall works at L3/L4 (IP addresses and ports). A stateful firewall adds session tracking, still mostly L3/L4. A next-generation firewall (NGFW) inspects L7 (application data — HTTP headers, TLS SNI, protocol identification via deep packet inspection). A WAF (Web Application Firewall) is purely L7. When a vendor says "next-gen firewall", they mean L7-aware. **Q: Is ARP a Layer 2 or Layer 3 protocol?** A: Officially L2 — ARP frames have no IP header. But it works with IP information (mapping IPs to MACs), so some texts call it Layer 2.5. For CCNA, the safe answer is "Layer 2." What matters is knowing that ARP is broadcast-scope (never crosses a router) and that its job is IP-to-MAC resolution on the same broadcast domain. **Q: What layer is HTTPS at?** A: L7 (application) for HTTP itself, wrapped in TLS which sits between L4 (TCP) and L7. Some texts put TLS at L6 (presentation) which matches OSI's original layer breakdown. In practice, "HTTPS = HTTP + TLS + TCP" — three layers in the same protocol stack. When troubleshooting, remember: the TCP handshake happens first (L4), then TLS negotiation (L6/L7), then the HTTP request (L7). **Q: Does anything actually implement OSI's Session and Presentation layers?** A: Not as standalone protocols in mainstream networks. TCP/IP collapses session state into TCP itself, and presentation-layer concerns (encoding, encryption) live inside application protocols (TLS handles encryption, application code handles character sets). The clearest surviving example is TLS at L6 — everything else at L5/L6 is application-embedded. This is exactly why TCP/IP's four-layer model won: L5/L6 as separate layers turned out to be unnecessary in practice. --- ## Cisco IOS Device Management — https://packetmentor.com/topics/ios-device-management/ > How you actually log into and configure a Cisco device. Covers console / SSH / Telnet access, command modes (user / privileged / config), saving config, banners, the password types, and modern best practices for line security. ## Mental model A Cisco device runs IOS, which exposes a command-line interface. You connect to that CLI through one of several access methods, navigate through a hierarchy of command modes, and either inspect (with `show` commands) or configure (with everything else). Every Cisco engineer's day-1 muscle memory: ``` R1> ← user EXEC (show some things, ping, traceroute) R1> enable ← move up to privileged EXEC R1# ← privileged EXEC (all show commands, debug, reload) R1# configure terminal R1(config)# ← global config (change device settings) R1(config)# interface GigabitEthernet0/0 R1(config-if)# ← interface config (change one interface) ``` `exit` moves you back one level. `end` jumps all the way to privileged EXEC. `Ctrl+Z` is the keyboard shortcut for `end`. ## The three ways in | Method | Used for | Encryption | |---|---|---| | **Console** | First setup, password recovery, troubleshooting when network is down | None (physical cable) | | **SSH (VTY)** | Daily remote management | SSH-2 protocol (RFC 4253) — port 22. Note: SSH is *not* TLS; it has its own crypto transport. | | **AUX / OOB management** | Out-of-band backup access (over a separate management network or modem) | Varies | | **Telnet (VTY)** | DON'T USE — port 23, unencrypted | None | **Always disable Telnet, always enable SSH.** Telnet sends passwords in plain text — any attacker on the path can read them. There's zero reason to allow it in 2026. ## Configuring SSH and disabling Telnet ``` R1(config)# hostname R1 R1(config)# ip domain-name corp.local ! required for crypto key gen R1(config)# crypto key generate rsa modulus 2048 ! generate SSH keys ! Configure VTY lines (remote access) R1(config)# line vty 0 15 R1(config-line)# transport input ssh ! only SSH allowed R1(config-line)# login local ! use local username database R1(config-line)# exec-timeout 10 0 ! kick idle sessions after 10 min ! Create a local user R1(config)# username admin privilege 15 secret strong-password ! Console line — set a password R1(config)# line console 0 R1(config-line)# login local R1(config-line)# logging synchronous ! stop log msgs interrupting your typing R1(config-line)# exec-timeout 0 0 ! console doesn't time out (debatable) ``` **Critical:** the `secret` keyword stores a hashed password. The older `password` keyword stores it in plaintext (or weakly reversible Type 7). Always `secret`, never `password`. ## Password types — know your hash Cisco IOS supports several password storage formats: | Type | What it is | Use? | |---|---|---| | **Type 0** | Plaintext | Never | | **Type 7** | Weakly reversible | Never — decoded in seconds | | **Type 5** | MD5 hash | Acceptable, weak by modern standards | | **Type 8** | PBKDF2-SHA256 | Good | | **Type 9** | scrypt | Best — use this for new configs | ``` ! Type 9 (scrypt) — modern, strong R1(config)# username admin algorithm-type scrypt secret strong-password ! Enable password encryption for all stored passwords R1(config)# service password-encryption ``` `service password-encryption` upgrades any remaining Type 0 to Type 7 (still weak, but at least not plaintext). It doesn't downgrade stronger hashes. ## Saving and reloading ``` R1# copy running-config startup-config ! save the current config R1# wr ! shortcut for the same R1# show running-config ! what's running now R1# show startup-config ! what will load on next reload R1# reload ! reboot ``` **Forgetting to save is the #1 mistake of new engineers.** Make config changes → forget to save → device reloads (planned or panic) → all your changes gone. Always end a config session with `wr`. ## Banners A banner shows on login. Two types you'll meet: ``` R1(config)# banner motd # Enter TEXT message. End with the character '#'. WARNING: Authorized access only. Activity is logged. # R1(config)# banner login # Welcome to corporate router R1. # ``` `motd` (message of the day) appears before login. `login` appears after authentication. Use `motd` for legal warnings — courts have ruled this matters for prosecuting unauthorized access. ## The four "show" commands you'll run constantly ``` R1# show running-config ! the live config R1# show ip interface brief ! one-line summary of every interface R1# show version ! IOS version, uptime, model, serial R1# show running-config | section interface ! filter to interface configs ``` `|` pipes the output through filters. `| include X`, `| begin X`, `| section X`, `| exclude X` — all useful. CCNA loves to test the difference between `include` (lines containing) and `section` (whole subsection starting with). ## Common mistakes 1. **Leaving Telnet enabled.** `transport input ssh` on every VTY line, every device. 2. **`service password-encryption` and thinking it's secure.** It uses weak Type 7 — decoded with online tools in seconds. Use stronger algorithms for important secrets (Type 8 or 9). 3. **No console password.** A physical attacker can connect to the console port and get unrestricted access. Always set a console password. 4. **`exec-timeout 0 0` on VTY lines.** Means idle sessions never time out. A walked-away admin's session is a permanent open door. Set 10 min or less for VTY. 5. **Forgetting `copy running startup`.** The single most common reason for "my config disappeared after reboot." 6. **Putting the `enable password` instead of `enable secret`.** The old `enable password` stores Type 7. `enable secret` stores Type 5/8/9. Always `secret`. 7. **Using the same `enable secret` across every device.** If one device is compromised, the secret is reused everywhere. Use TACACS+/RADIUS (centralized [AAA](/topics/aaa/)) so each user has unique credentials. 8. **Disabling DNS-lookup on console without realizing why.** `no ip domain-lookup` is a common config item — without it, mistyping a command makes the router try to DNS-resolve it as a hostname, timing out for ~30 seconds. Most engineers add this on every device. ## Lab to try tonight 1. Console into a fresh Cisco router (CML, Packet Tracer, or real device). 2. Set hostname, enable secret (Type 9), and a console password. 3. Configure SSH: generate RSA key 2048, create a local user, enable SSH on VTY lines, disable Telnet. 4. From another device, SSH in. Verify Telnet fails. 5. Configure a `motd` banner with a legal warning. 6. Make some config changes. Run `show running-config` then `show startup-config` — note they differ. 7. `wr`. Re-run both — they now match. 8. Reload. Verify your changes survived. 9. Bonus: configure AAA pointing at a RADIUS / TACACS+ server (see [AAA topic](/topics/aaa/)). ## Cheat strip | Concept | Plain English | |---|---| | **Modes** | user (R1>) → priv (R1#) → config (R1(config)#) | | **Console** | Physical cable. Day-1 setup, password recovery. | | **SSH / VTY** | Daily remote access. Port 22, encrypted. | | **Telnet** | Never use. Plaintext. | | **`enable secret`** | Privileged password. Hashed. | | **`secret` (in `username`)** | Hashed user password. Always this, never `password`. | | **Type 9** | scrypt — best password hash | | **`service password-encryption`** | Type 0 → 7. Weak but better than nothing. | | **`copy run start`** | Save config. Survive reboot. | | **`exit` / `end` / `Ctrl+Z`** | Back one level / all the way out | | **`wr`** | Shortcut for `copy run start` | --- ## IPv4 Addressing — https://packetmentor.com/topics/ipv4-addressing/ > 32-bit addresses, dotted decimal, classful vs classless, private ranges, and the special addresses (loopback, broadcast, APIPA) you should never accidentally use for production hosts. ## Mental model An IPv4 address is just a 32-bit number — about four billion possible values. We write it as four 8-bit chunks (octets) separated by dots, in decimal, because nobody wants to read `11000000.10101000.00001010.00000101` aloud. ``` 192.168.10.5 ← human-readable 11000000.10101000.00001010.00000101 ← what the network actually sees ``` Every IPv4 address has two pieces glued together: - **Network portion** — the part shared by everyone on the same LAN - **Host portion** — the part unique to each device on that LAN The **subnet mask** is what draws the line between them. `/24` says *"first 24 bits are network, last 8 are host."* Everything to the left of the line is shared; everything to the right is unique. ## How to read a /N mask | /N | Bits on | Hosts per subnet | Use case | |---|---|---|---| | /8 | 8 | 16,777,214 | Huge legacy block | | /16 | 16 | 65,534 | Big enterprise LAN | | /24 | 24 | 254 | Standard LAN segment | | /30 | 30 | 2 | Point-to-point WAN link | | /32 | 32 | 1 (just the host) | Loopbacks, host routes | Mask is the inverse of "host bits" — `/24` means 24 network bits, so 32−24 = 8 host bits = 2⁸ = 256 addresses minus 2 (network + broadcast) = 254 usable hosts. ## Three private address ranges (RFC 1918) These ranges never get routed on the public internet. Use them freely inside your own network: | Range | Size | Typical use | |---|---|---| | **10.0.0.0/8** | 16.7M addresses | Enterprises that want lots of room | | **172.16.0.0/12** (172.16–172.31) | 1M addresses | Mid-size enterprises | | **192.168.0.0/16** | 65K addresses | Home routers, small offices | If you see a packet on the public internet with a private source IP, it's misconfigured or malicious — internet routers drop it. ## Special addresses you need to know | Address | What it is | Don't use it for | |---|---|---| | 0.0.0.0 | Unspecified / "any" | Hosts (it means "I don't have one yet") | | 127.0.0.0/8 | Loopback (commonly 127.0.0.1) | Anything other than localhost | | 169.254.0.0/16 | APIPA (link-local) | Real hosts — means DHCP failed | | 224.0.0.0/4 | Multicast | Unicast hosts (it's for groups) | | 255.255.255.255 | Local broadcast | Anything (it's a destination only) | | First IP of any subnet | Network address | Hosts | | Last IP of any subnet | Broadcast address | Hosts | If a user's laptop has a `169.254.x.x` IP, it didn't get an answer from a DHCP server — the OS assigned itself a placeholder. Always check this when troubleshooting "no internet." ## Classful (legacy) vs Classless (modern) Before 1993, IPv4 was split into classes based on the first few bits: - **Class A**: 1.x – 126.x, default mask /8 - **Class B**: 128.x – 191.x, default mask /16 - **Class C**: 192.x – 223.x, default mask /24 - **Class D**: 224.x – 239.x, multicast - **Class E**: 240.x – 255.x, reserved CIDR (Classless Inter-Domain Routing) replaced this in 1993. **Modern networking is classless** — you use whatever prefix length fits. The terms "Class A network" or "Class C network" are only useful for talking about legacy protocol behavior. Say `/24`, not "Class C." The CCNA exam still references the classes, so know them. But never design a network around them. ## Commands ### Assign an IPv4 address to a Cisco interface ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 192.168.10.1 255.255.255.0 R1(config-if)# no shutdown ``` ### View interface IP configuration ``` R1# show ip interface brief R1# show ip interface GigabitEthernet0/0 R1# show running-config interface GigabitEthernet0/0 ``` `show ip interface brief` is the bread-and-butter command — one-line summary of every interface and its IP. ## Common mistakes 1. **Confusing subnet mask with wildcard mask.** Subnet mask = `255.255.255.0`. Wildcard mask = `0.0.0.255` (inverse). Use the right one in the right context (ACLs and OSPF use wildcard; interface configs use subnet). 2. **Assigning the network or broadcast address to a host.** The first IP of a subnet is the network, the last is the broadcast. Neither is usable. `.0` and `.255` on a /24 are off-limits. 3. **Using private IPs and forgetting NAT.** Hosts inside the network are 10.0.0.5; the public internet doesn't route to that. Without NAT on the edge router, return traffic never arrives. 4. **Assigning 169.254.x.x manually to a host.** This is the APIPA range — reserved for failed DHCP. A real host with this address will get filtered or behave weirdly on most networks. 5. **Treating /31 as unusable.** Many engineers learned "you can't use /31 because there's only 2 addresses, both reserved." RFC 3021 fixed this in 2000 — modern routers happily use /31 for point-to-point links, saving IPs. Use /31, not /30, on point-to-point WAN. 6. **Picking the same private range as another network you'll later merge with.** Two acquired companies both using 192.168.1.0/24 → painful renumber. Plan large ranges (10.x) from day one. ## Lab to try tonight 1. On any router, configure `ip address 10.10.10.1 255.255.255.252` on an interface. Calculate by hand: what's the network, broadcast, and other usable IP? 2. Verify with `show ip interface brief`. 3. On a PC, manually set an IP in the same /30 range. Ping the router. Confirm reachability. 4. Now set the PC's IP to the network address (10.10.10.0) — observe the failure. 5. Change to a different private range entirely (172.16.0.1/24). Configure on a second router interface. Confirm independent operation. 6. Bonus: enable a /31 on a point-to-point WAN link. Verify both ends can ping each other with only 2 addresses in the subnet. ## Cheat strip | Concept | Plain English | |---|---| | **32-bit address** | Four octets, 0–255 each | | **Subnet mask** | Tells you where network ends and host begins | | **Private ranges** | 10/8 · 172.16/12 · 192.168/16. Internal only. | | **/30 vs /31** | Both for point-to-point. /31 (RFC 3021) saves 2 IPs. | | **169.254.x.x (APIPA)** | DHCP failed. Real hosts shouldn't have this. | | **127.0.0.1** | Loopback — "this same machine" | | **0.0.0.0** | "Any" — used in default routes and unspecified contexts | | **/N notation** | Modern. Classful network classes (A/B/C) are exam-only legacy. | ## Frequently asked questions **Q: What are the private IPv4 address ranges?** A: Three blocks (RFC 1918): `10.0.0.0/8` (one /8, 16.7M addresses), `172.16.0.0/12` (sixteen /16s, 1M addresses), and `192.168.0.0/16` (256 /24s, 65K addresses). Never routable on the public internet — NAT translates them to public addresses at the network edge. Home routers use `192.168.0.0/24` or `192.168.1.0/24`; enterprises typically use `10.0.0.0/8` for headroom. **Q: What's the difference between a public and a private IP?** A: Public IPs are globally unique and routable across the internet — assigned by IANA via regional registries (ARIN in North America). Private IPs (RFC 1918) can be reused by anyone since they never appear on public networks. Every internet-facing device needs a public IP; everything behind NAT shares one public IP. Public IPv4 is exhausted — new allocations cost money, which is why IPv6 exists. **Q: What's APIPA and when does it kick in?** A: Automatic Private IP Addressing — a Windows client picks a random `169.254.0.0/16` address when DHCP fails. If you see `169.254.x.x` on a client, it means DHCP didn't respond — either the DHCP server is down, the relay is misconfigured, or the client is on the wrong VLAN. Not useful for actual connectivity; it's a diagnostic flag. **Q: Is 0.0.0.0 a valid IP address?** A: Not as a source or destination for user traffic — it means "no IP" (unset) or "any IP" (as a wildcard in ACLs, routing, and socket binds). A default route is `0.0.0.0/0` — meaning "match anything." A server that binds to `0.0.0.0` listens on all its interfaces. Never assign it to an interface. --- ## Spine-Leaf Architecture (Modern Data Center Topology) — https://packetmentor.com/topics/spine-leaf-architecture/ > The flat two-tier fabric that replaced the classic three-tier core/distribution/access model inside modern data centers — every leaf reaches every spine in exactly one hop, giving predictable latency and easy scale-out. ## Mental model Classic campus networks are **three-tier**: access → distribution → core. That model was optimised for **north-south** traffic — users at the access edge talking to servers or the internet, which sat at or beyond the core. Modern applications flipped it: microservices, virtualisation, container orchestration, and big-data workloads generate huge **east-west** traffic (server-to-server within the same DC), and three-tier's per-tier oversubscription makes east-west slow and unpredictable. **Spine-leaf** flattens the DC to two tiers. Every leaf switch (the top-of-rack, connecting servers) is directly cabled to every spine switch (the backbone). Two servers on different racks always talk over the same two-hop path: `server → leaf1 → spine → leaf2 → server`. Latency is deterministic. Bandwidth is easy to scale. ## The layout ``` Spine 1 Spine 2 Spine 3 Spine 4 │ │ │ │ ┌──────┼──────┬───────┼──────┬───────┼──────┬───────┼──────┐ │ │ │ │ │ │ │ │ │ Leaf-A Leaf-B Leaf-C Leaf-D Leaf-E ... │ │ │ │ │ servers servers servers servers servers ``` Rules: - **No leaf-to-leaf uplinks.** All east-west goes leaf → spine → leaf. - **No spine-to-spine uplinks.** Spines only forward between leaves. - **Every leaf connects to every spine.** With 4 spines and 24 leaves, that's 96 spine-leaf uplinks. - **Uniform port count** on spines (so all leaves have equal reach). ## Why it beats three-tier for the DC | Property | Three-tier (core/dist/access) | Spine-leaf | |---|---|---| | Layers between two servers | 5 hops (worst case: access → dist → core → dist → access) | 2 hops always (leaf → spine → leaf) | | Latency | Variable — depends on where the two servers sit | Deterministic — same for any pair | | Scaling bandwidth | Upgrade core links (expensive, disruptive) | Add another spine (parallel, non-disruptive) | | Scaling port count | Add distribution + access | Add another leaf | | Spanning-Tree convergence | Central bottleneck | Rarely uses STP — routing overlays instead | | Redundancy | Distribution-tier bottleneck if one distro fails | Any single spine or leaf can fail; all others keep forwarding | ## What runs on spine-leaf in practice - **Layer 3 to the edge.** Every leaf terminates an L3 boundary — no VLANs stretched across leaves. This kills classic STP problems. - **ECMP (Equal-Cost Multi-Path) routing** — traffic is spread across all spines. OSPF, BGP (usually eBGP-in-the-DC), or IS-IS handle the underlay. - **VXLAN overlay** — L2 segments needed by tenants are extended over the L3 fabric via VXLAN tunnels between leaves, letting VMs move between racks without renumbering. - **EVPN control plane** — BGP EVPN advertises MAC/IP reachability across the overlay. ## When you'd still use three-tier - **Campus networks** with heavy north-south traffic (users at access edge → internet/central servers). Three-tier's aggregation model handles this well. - **Very small deployments** — a two-tier collapsed-core is often enough. - **Environments with legacy L2 requirements** where the applications assume flat VLAN behaviour and can't tolerate L3 boundaries at every rack. ## The classic CCNA question *"Which topology is most common in modern data centers?"* → **spine-leaf**. *"What kind of traffic does spine-leaf optimise for?"* → **east-west (server-to-server)**. *"How many spine switches does each leaf connect to?"* → **all of them** (leaves fan out to every spine). ## The #1 mistake **Cabling a spine-leaf like a three-tier network** — adding leaf-to-leaf uplinks or spine-to-spine uplinks. This creates layer-3 forwarding loops or convergence issues and defeats the deterministic 2-hop property. The whole point is that spines never talk to each other and leaves never talk to each other directly. ## Related deep-dives - [Hierarchical network design](/topics/hierarchical-network-design/) — the classic three-tier campus model - [VXLAN basics](/topics/vxlan-basics/) — the overlay that runs on top of the fabric - [SDN controllers](/topics/sdn-controllers/) — the controller model that manages large spine-leaf fabrics --- ## Private IPv4 Addressing (RFC 1918) — https://packetmentor.com/topics/private-ipv4-addressing/ > The three private IPv4 ranges — 10/8, 172.16/12, and 192.168/16 — reserved for internal networks, hidden behind NAT, and never routable on the public internet. ## Mental model The internet ran out of unique IPv4 addresses long ago — 32 bits gives you only about 4 billion, and there are far more devices than that. **RFC 1918** carved out three ranges that anyone can reuse inside their own network, as long as they don't leak onto the public internet. Every home, office, and data centre uses these same ranges independently, and NAT (Network Address Translation) is what lets them all share the internet through public IPs. ## The three private ranges | Range | CIDR | Old class | Hosts (theoretical max) | Typical use | |---|---|---|---|---| | **10.0.0.0 – 10.255.255.255** | 10.0.0.0/8 | Class A | 16,777,214 | Enterprise, service providers, cloud VPCs | | **172.16.0.0 – 172.31.255.255** | 172.16.0.0/12 | Class B block | 1,048,574 | Mid-size networks, campus labs | | **192.168.0.0 – 192.168.255.255** | 192.168.0.0/16 | Class C block | 65,534 | Home, small office, SOHO routers | The old class labels don't matter for routing anymore (we've been classless since CIDR arrived in 1993), but they're still handy for remembering which range is which size. ## Why they exist Two things wouldn't work without RFC 1918: 1. **Address conservation.** Every device inside a corporate network would otherwise need a globally-unique public IPv4. There aren't enough left. Private ranges + NAT let millions of internal hosts share a handful of public IPs. 2. **Isolation by default.** Because internet backbone routers **drop packets** to or from RFC 1918 addresses, your internal `10.10.5.20` file server is unreachable from the outside — a free layer of security you don't have to configure. ## Special-purpose ranges (not RFC 1918 but often confused) | Range | Purpose | |---|---| | 127.0.0.0/8 | Loopback — packets never leave the host (127.0.0.1 is the classic) | | 169.254.0.0/16 | Link-local / APIPA — a Windows/Mac/Linux client assigns itself one when DHCP fails | | 224.0.0.0/4 | Multicast | | 100.64.0.0/10 | Carrier-grade NAT (CGN) — ISP-internal, not usable in customer networks | | 0.0.0.0/8 | "This network" — the default route uses 0.0.0.0/0 | | 255.255.255.255 | Limited broadcast — never routed | Seeing `169.254.x.x` on your laptop is a telltale sign DHCP is broken. ## How you'll see this on the exam - **"Which of these can be used on the public internet?"** → Anything **not** in the three RFC 1918 ranges (and not loopback, APIPA, multicast, or reserved). - **Given a network diagram, identify which addresses need NAT** → any host in `10.0.0.0/8`, `172.16-31.0.0/12`, or `192.168.0.0/16` that talks to the internet needs to be translated. - **Duplicate private ranges across a merged network** → the classic acquisition/merger problem: both companies use `192.168.1.0/24` for their office, and now they can't route to each other without renumbering or double-NAT. ## Real-IOS: configuring an inside private LAN + NAT to the internet ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# description LAN — inside NAT R1(config-if)# ip address 192.168.1.1 255.255.255.0 R1(config-if)# ip nat inside R1(config-if)# no shutdown ! R1(config)# interface GigabitEthernet0/1 R1(config-if)# description WAN — outside NAT R1(config-if)# ip address 203.0.113.5 255.255.255.252 R1(config-if)# ip nat outside R1(config-if)# no shutdown ! R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255 R1(config)# ip nat inside source list 1 interface GigabitEthernet0/1 overload ``` Now every host in `192.168.1.0/24` reaches the internet by being translated to the router's outside IP `203.0.113.5`. See the dedicated [NAT topic](/topics/nat/) for the full walkthrough. ## The #1 mistake **Using a public IP by mistake on your internal network.** New engineers sometimes pick `1.1.1.1` or `8.8.8.8` for a lab because they're memorable — and then wonder why their internal hosts can't reach Google DNS or Cloudflare (those *are* Google DNS and Cloudflare, and now your router thinks the "internal" host is on the internet). Always start internal designs from the RFC 1918 ranges. ## Quick verification ``` R1# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 192.168.1.1 YES manual up up GigabitEthernet0/1 203.0.113.5 YES manual up up ! R1# show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 203.0.113.5:1024 192.168.1.10:53212 8.8.8.8:443 8.8.8.8:443 ``` --- ## TCP vs UDP — https://packetmentor.com/topics/tcp-vs-udp/ > Two flavors of Layer 4 transport. TCP gives reliability and order at the cost of latency; UDP gives speed with no safety net. Covers the 3-way handshake, ports, when to use each, and the protocols that pick the wrong one. ## Mental model When your application sends data over the network, it has a choice: do you want **reliable delivery in order** (TCP) or **fast, lightweight, no guarantees** (UDP)? - **TCP** wraps every byte in a sequence number, acknowledges delivery, retransmits on loss, and reassembles in order. Costs: extra packets, extra round-trips, latency. - **UDP** just throws packets at the destination and forgets them. Costs: nothing — but if anything's lost, reordered, or duplicated, your app has to handle it. The choice is application-by-application. Browsers pick TCP. DNS picks UDP. VoIP picks UDP because a delayed audio packet is worse than a lost one — by the time you retransmit, the conversation moved on. ## TCP — the 3-way handshake Before TCP sends any data, it establishes a connection through three packets: ``` Client Server │ ───── SYN (seq=100) ──────► │ │ ◄──── SYN-ACK (seq=500, ack=101) ── │ │ ───── ACK (ack=501) ──────► │ │ │ │ ◄────── application data ─────────► │ ``` After this dance, both sides have synchronized sequence numbers and know the connection is established. Closing follows a similar 4-way FIN/ACK exchange. ## UDP — there is no handshake ``` Client Server │ ─── UDP datagram ──► │ │ │ │ ◄── UDP datagram (maybe) ─── │ ``` That's the whole protocol. No setup, no teardown, no ack. UDP's job is to add the source and destination ports to a packet and get out of the way. ## Header overhead | Protocol | Header size | Why | |---|---|---| | TCP | 20 bytes (40 with options) | Sequence #, ack #, flags, window, etc. | | UDP | **8 bytes** | Just src port, dst port, length, checksum | For tiny payloads, UDP's 8-byte header is a meaningful efficiency win. For a 1-byte ping, TCP would need 60 bytes of headers; UDP needs 36. ## Ports — the same on both protocols, but separately A port is a 16-bit number (0–65535) tagged onto every TCP and UDP packet. The pair (IP + port) identifies a unique conversation endpoint. | Range | Name | Purpose | |---|---|---| | 0–1023 | Well-known | Standard protocols (HTTP 80, SSH 22, DNS 53) | | 1024–49151 | Registered | Vendor-assigned (Cisco TFTP, MS-SQL, etc.) | | 49152–65535 | Ephemeral | Source ports the OS picks for outbound connections | **Key gotcha:** TCP port 80 and UDP port 80 are different things. They share the number, not the conversation. Most well-known protocols are TCP, but DNS uses both (UDP for queries, TCP for zone transfers and big responses). ## Common ports — memorize these | Port | Protocol | Notes | |---|---|---| | 20, 21 | TCP | FTP (data, control) | | 22 | TCP | SSH | | 23 | TCP | Telnet (don't use — unencrypted) | | 25 | TCP | SMTP | | 53 | UDP + TCP | DNS | | 67, 68 | UDP | DHCP (server, client) | | 69 | UDP | TFTP | | 80 | TCP | HTTP | | 110 | TCP | POP3 | | 123 | UDP | NTP | | 143 | TCP | IMAP | | 161, 162 | UDP | SNMP (poll, trap) | | 443 | TCP | HTTPS | | 514 | UDP | Syslog | | 3389 | TCP | RDP | CCNA exam loves to ask about port numbers. Memorize the common ones. ## When to use which **Use TCP when:** - Data must arrive intact and in order (web pages, files, email) - You can tolerate slight latency for reliability - The application doesn't already handle loss **Use UDP when:** - Speed matters more than reliability (VoIP, video, online gaming) - The application implements its own reliability (QUIC, TFTP) - The query/response is tiny and a retransmit is cheaper than a connection setup (DNS) ## Commands ### See active TCP connections on a Cisco router ``` R1# show tcp brief R1# show ip sockets R1# show tcp statistics ``` ### Test reachability of a specific port ``` R1# telnet 10.0.0.1 80 ! quick "is the TCP port open?" test ``` If `telnet` connects, port 80 TCP is reachable. If it hangs or refuses, it's not. (Doesn't work for UDP — `telnet` is TCP-only.) ## Common mistakes 1. **Assuming HTTPS is UDP.** It's TCP, port 443. (TLS sits on top of TCP.) HTTP/3 uses UDP — but for CCNA, HTTPS = TCP/443. 2. **Thinking SSH and Telnet share the same port.** SSH is 22, Telnet is 23. Easy to confuse on the exam. 3. **Forgetting DNS uses both.** UDP/53 for normal queries (small response). TCP/53 for zone transfers and any response larger than ~512 bytes (EDNS now supports more in UDP, but TCP fallback still exists). 4. **Forgetting source vs destination port direction.** A client connecting to a web server uses an ephemeral source port (e.g. 49000) and destination port 80. The server's reply has source 80, destination 49000. Mistakes here cause ACL rules to fail. 5. **Using `telnet` to test UDP ports.** Doesn't work — telnet is TCP only. For UDP, use `nc -u host port` on Linux or specific protocol clients. ## Lab to try tonight 1. Open Wireshark, start a capture. 2. From your laptop, browse to any HTTPS site. Find the TCP 3-way handshake (SYN, SYN-ACK, ACK) in the capture. 3. Also find a DNS query. Confirm it's UDP/53. 4. In a terminal: `nslookup -type=A google.com` while capturing. See exactly one request and one response, both UDP/53. 5. Try `telnet google.com 443` — connects (TCP/443 open). 6. Try `telnet google.com 53` — fails (Google's DNS is UDP/53, not TCP/53 on that interface). ## Cheat strip | Concept | Plain English | |---|---| | **TCP** | Reliable, ordered, connection-based. HTTP, SSH, SMTP. | | **UDP** | Fire-and-forget. DNS, DHCP, VoIP, video. | | **3-way handshake** | SYN → SYN-ACK → ACK (TCP only) | | **Sequence numbers** | TCP uses them to reorder and detect loss | | **Port range 0–1023** | Well-known (HTTP 80, SSH 22, DNS 53) | | **Port range 49152+** | Ephemeral — client-side source ports | | **TCP/80 ≠ UDP/80** | Different conversations entirely | | **DNS uses both** | UDP for queries, TCP for big responses + zone transfers | ## Frequently asked questions **Q: When should I use TCP vs UDP?** A: TCP when correctness matters more than latency — file transfer, web pages, email, SSH. UDP when latency matters more than correctness — voice, video, gaming, DNS queries. TCP guarantees delivery and ordering at the cost of retransmission delay; UDP just fires and forgets, leaving the application to handle any reliability it wants. If you don't know which to pick, default to TCP. **Q: Why does DNS use both UDP and TCP?** A: UDP for normal queries (small, one round-trip, retry-if-lost is fine) — over 99% of DNS traffic is UDP 53. TCP for zone transfers between servers (large payloads) and for responses larger than 512 bytes (which happens with DNSSEC signatures, big TXT records, etc.). Modern clients also use TCP-fallback when the UDP response has the TC (truncated) flag set. **Q: Does UDP have a checksum?** A: Yes, but in IPv4 it's optional (a checksum of zero means "not calculated"). In IPv6 the UDP checksum is mandatory. In practice virtually every implementation sets it because Ethernet's CRC only catches errors in-frame — errors introduced by intermediate devices or memory would sail through without a UDP checksum. If you see UDP-checksum-zero, it's almost always a middlebox stripping it. **Q: What's QUIC and how does it relate to TCP/UDP?** A: QUIC is a transport protocol built on UDP that provides reliable, ordered, encrypted, multiplexed delivery — effectively "TCP replacement" without the TCP handshake latency and without head-of-line blocking. Google runs the majority of google.com traffic over QUIC (HTTP/3 = HTTP over QUIC). From the network's perspective it's UDP on port 443; from the application's perspective it behaves like TCP+TLS. **Q: Why does TCP have a three-way handshake?** A: To synchronise the initial sequence numbers in both directions and confirm both sides can send and receive. SYN (client) → SYN-ACK (server acknowledges + sends its own SYN) → ACK (client acknowledges server's SYN). Two-way isn't enough because you need each side to confirm it received the other's sequence number. This is also what SYN-flood attacks abuse — half-opening thousands of connections and never sending the final ACK, exhausting the server's connection table. --- ## Interface & Cable Issues: Collisions, Errors, Duplex/Speed Mismatch — https://packetmentor.com/topics/duplex-speed-mismatch/ > Late collisions, input errors, CRC counters, and the classic auto-negotiation trap where one side ends up half-duplex and the link crawls at 1% of its rated speed. ## Mental model Layer-1 and layer-2 problems don't always announce themselves. A cable that's marginal, a duplex mismatch, or a bent pin can leave the link **up** but the throughput at 1% of what you'd expect. The counters on `show interfaces` are how you diagnose it — they tick up silently while users complain the network is "slow". ## Duplex mismatch — the classic **Full-duplex** = send and receive at the same time (no collisions possible). **Half-duplex** = one at a time; use CSMA/CD to detect collisions on the wire. If **one end is full-duplex and the other is half-duplex**, both ends *think* they're right and the link stays up — but the behaviour is broken: | Side | What it sees | |---|---| | Full-duplex side | It transmits whenever it wants. The half side is transmitting too — collisions on the wire. But the full side won't detect them (it's not listening for collisions). It sees **CRC errors** and **runts** (frames chopped off by collisions). | | Half-duplex side | It backs off on collisions (CSMA/CD). But since the full side keeps hammering, the half side sees **late collisions** — collisions after the first 512 bit-times, which should be impossible in a healthy half-duplex network. | **Net effect:** the link "works" but at ~10-30% of nominal throughput, with retransmissions everywhere. ## Speed mismatch Modern Ethernet auto-negotiates speed AND duplex. If one side is hard-coded to 100/full and the other is set to auto, the auto side can usually detect speed via parallel detection but **defaults to half-duplex** — giving you the mismatch above. **Rule of thumb: don't mix.** Either both sides auto or both sides hard-coded to the same values. ## Reading the counters ``` SW1# show interfaces GigabitEthernet0/1 GigabitEthernet0/1 is up, line protocol is up ... Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX ... 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 babbles, 0 late collisions, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output ``` | Counter | What it means | Likely cause | |---|---|---| | **CRC** | Frame arrived, its FCS doesn't match | Bad cable, EMI, duplex mismatch (full side) | | **runts** | Frame < 64 bytes | Chopped by a collision; duplex mismatch, bad cable | | **giants** | Frame > MTU | MTU mismatch, jumbo-frame misconfig | | **input errors** | Umbrella (CRC + runts + giants + frame + overrun + ignored) | Look at the sub-counters | | **collisions** | Normal on half-duplex, always zero on full | Presence on a "full-duplex" port = mismatch | | **late collisions** | Collision after the first 512 bit-times | Cable too long, or duplex mismatch (half side) | | **input drops / no buffer** | Interface can't keep up | Micro-bursts, undersized buffer | | **interface resets** | Link flapped | Bad cable, SFP, or negotiation loop | ## Deliberate fix — real IOS If auto-negotiation is misbehaving, hard-code both ends. Do this on **both switches** so they agree: ``` SW1(config)# interface GigabitEthernet0/1 SW1(config-if)# speed 1000 SW1(config-if)# duplex full ``` To go back to auto (recommended on modern kit): ``` SW1(config-if)# speed auto SW1(config-if)# duplex auto ``` ## Cable / physical checks - **Wrong pinout** — straight-through vs crossover mattered on old gear. Modern switches with Auto-MDIX handle either. If you disabled MDIX (`no mdix auto`), you're back to caring about pinouts. - **Cable category too low for the speed** — Cat5 unshielded on a 10 Gbps port will not negotiate at 10 Gbps (see [cable categories](/topics/cable-categories-cat5-cat8/)). - **Bent pin or loose connector** — CRC spikes on one port only, other ports fine. - **EMI near industrial equipment** — CRC on the whole switch stack. Move the cables away from the motor / VFD / fluorescent ballast. ## The #1 mistake **Assuming "link up" = "link healthy".** The Ethernet link-status LED will happily glow green while the port is dropping 40% of frames to CRC and running at effective 30 Mbps on a gigabit port. Always check the counters after any change, and reset them (`clear counters GigabitEthernet0/1`) so you're looking at fresh data. ## Related topic-page verification lab Try it on the [live console](/exam/labs/console/): ``` SW1# clear counters SW1# show interfaces Gi0/1 | include duplex|error|collision SW1# configure terminal SW1(config)# interface Gi0/1 SW1(config-if)# speed 100 SW1(config-if)# duplex half SW1(config-if)# end SW1# show interfaces Gi0/1 | include duplex ``` --- ## Subnetting — https://packetmentor.com/topics/subnetting/ > Definitive CCNA-level subnetting guide — magic-number method, VLSM, wildcard masks, enterprise IP plans, 8 worked practice problems, and the subnetting-at-the-speed-of-conversation drill. ## Mental model An IP address is just **32 bits** split into two halves: the **network portion** (everyone on this network has these bits in common) and the **host portion** (unique per device on this network). The **subnet mask** tells you where the split lives. A `/24` mask means "the first 24 bits are network, the last 8 bits are host" — so you've got 8 bits = 256 addresses = 254 usable hosts. Subnetting means moving that boundary to the right — taking host bits and using them as network bits. Steal 2 bits and you split your `/24` into four `/26` subnets. Each `/26` has 6 host bits = 64 addresses = 62 usable hosts. This is the *only* concept in subnetting. Everything else — the math, the magic-number trick, VLSM, wildcard masks — is just consequences of that one rule. ## Anatomy of a 32-bit address Let's look at `192.168.10.85` with mask `/26` in full detail. ``` IP: 192 .168 .10 .85 11000000 .10101000 .00001010 .01010101 Mask: 255 .255 .255 .192 11111111 .11111111 .11111111 .11000000 ← /26 = 26 ones ``` The mask's `1` bits define the **network**. The `0` bits define the **host**. Apply the mask (binary AND between IP and mask): ``` 11000000 .10101000 .00001010 .01000000 = 192.168.10.64 ``` So `192.168.10.85/26` is on the network `192.168.10.64/26`. The first 26 bits (`11000000 10101000 00001010 01`) are the network identifier — every device on this subnet shares these bits. The remaining 6 bits (`010101`) are the host portion that makes this device unique on its segment. You will almost never do this binary calculation in real life. But understanding *why* it works is the unlock. ## The four numbers you always compute For any subnet, you need: 1. **Network address** — first IP, all host bits = 0 2. **Broadcast address** — last IP, all host bits = 1 3. **First usable host** — network + 1 4. **Last usable host** — broadcast − 1 Example: `192.168.10.64/26` - Network: `192.168.10.64` - Broadcast: `192.168.10.127` - First host: `192.168.10.65` - Last host: `192.168.10.126` - **Usable hosts: 62** (64 − 2 for network + broadcast) The network address and broadcast address cannot be assigned to a device. That's the `−2` everyone forgets on test day. ## The magic-number method (use this on the exam) Given a subnet mask, find the **interesting octet** — the octet that isn't 255 or 0. Compute `256 − that octet`. That's your **block size**. Subnets always start at multiples of the block size. ### Walk-through: `/26` (mask 255.255.255.192) - Interesting octet: **192** (fourth octet) - Block size: **256 − 192 = 64** - Subnets: 0, 64, 128, 192 — four subnets in a /24 | Subnet | Network | Broadcast | First host | Last host | |---|---|---|---|---| | 1 | 192.168.10.0 | 192.168.10.63 | .1 | .62 | | 2 | 192.168.10.64 | 192.168.10.127 | .65 | .126 | | 3 | 192.168.10.128 | 192.168.10.191 | .129 | .190 | | 4 | 192.168.10.192 | 192.168.10.255 | .193 | .254 | ### Walk-through: `/27` (mask 255.255.255.224) - Interesting octet: **224** (fourth octet) - Block size: **256 − 224 = 32** - Subnets: 0, 32, 64, 96, 128, 160, 192, 224 — eight /27s in a /24, each with 30 usable hosts. ### Walk-through: `/22` (mask 255.255.252.0) - Interesting octet: **252** (third octet) - Block size: **256 − 252 = 4** - Subnets in the third octet: 0, 4, 8, 12, 16, … 252 — 64 /22s in a /16, each with 1,022 usable hosts. The trick is the same — just applied one octet earlier when the mask crosses an octet boundary. ### Walk-through: `/21` (mask 255.255.248.0) - Block size: **256 − 248 = 8** (in the third octet) - Subnets: 0, 8, 16, 24, … 248 — 32 /21s in a /16, each with 2,046 usable hosts. ## CIDR cheat strip (memorize) | CIDR | Subnet mask | Block size | Usable hosts | Common use | |---|---|---|---|---| | /16 | 255.255.0.0 | 65,536 | 65,534 | Large enterprise site | | /20 | 255.255.240.0 | 4,096 | 4,094 | Mid enterprise site | | /22 | 255.255.252.0 | 1,024 | 1,022 | Branch office, large VLAN | | /23 | 255.255.254.0 | 512 | 510 | Large user VLAN | | /24 | 255.255.255.0 | 256 | 254 | Default subnet for VLANs | | /25 | 255.255.255.128 | 128 | 126 | Smaller VLAN | | /26 | 255.255.255.192 | 64 | 62 | Conference room, small office | | /27 | 255.255.255.224 | 32 | 30 | Small VLAN | | /28 | 255.255.255.240 | 16 | 14 | Server segment, DMZ | | /29 | 255.255.255.248 | 8 | 6 | Tiny segment, transit link | | /30 | 255.255.255.252 | 4 | 2 | Classic point-to-point WAN | | /31 | 255.255.255.254 | 2 | 2 | Modern point-to-point (RFC 3021) | | /32 | 255.255.255.255 | 1 | 1 | Host route, loopback | **Memorize the "Usable hosts" column.** CCNA exam questions like "minimum mask for 100 hosts?" become trivial: 100 < 126 = **/25**. ## Subnetting at the speed of conversation The pros don't pull out a calculator. The thought process is: > *"They need 50 hosts. 50 < 62, so /26 works. Block size 64. Start at .0 — next subnet at .64. Broadcast of the first = .63. Done."* That's the full mental loop. With practice it takes 5 seconds. ### The drill Pick a random IP and mask, predict network / broadcast / first / last *out loud*, then verify on a subnet calculator. Do 20 a day for a week. By day 8 your reflex is built. Free drill site: subnettingpractice.com. Aim for under **45 seconds per problem**. ## VLSM — Variable-Length Subnet Masking Real networks have segments of different sizes. A user VLAN needs 200 hosts. A server VLAN needs 30. A point-to-point WAN link needs 2. Allocating a `/24` to each wastes thousands of addresses. **VLSM** is the practice of using **different mask lengths** within a single allocation. It's how the modern internet was made possible after the address-class system collapsed in the 1990s. ### The VLSM rule: always allocate largest first The algorithm: 1. List your subnet requirements, sorted **largest host count first**. 2. Allocate the largest subnet from the start of your address space. 3. Allocate the next subnet immediately after. 4. Repeat until done. ### Worked example: allocate from `192.168.10.0/24` Requirements (in any order): - Branch office: 100 hosts - DC server segment: 50 hosts - Storage segment: 20 hosts - 4× point-to-point WAN links: 2 hosts each Step 1 — sort by size: | Requirement | Hosts needed | Mask needed | Subnet size | |---|---|---|---| | Branch office | 100 | /25 (126 usable) | 128 | | DC servers | 50 | /26 (62 usable) | 64 | | Storage | 20 | /27 (30 usable) | 32 | | 4× WAN P2P | 2 each | /30 (2 usable) | 4 each | Step 2 — allocate from `.0`: ``` 192.168.10.0/25 → Branch office (.0 – .127) 128 addresses 192.168.10.128/26 → DC servers (.128 – .191) 64 addresses 192.168.10.192/27 → Storage (.192 – .223) 32 addresses 192.168.10.224/30 → WAN link A (.224 – .227) 4 addresses 192.168.10.228/30 → WAN link B (.228 – .231) 4 addresses 192.168.10.232/30 → WAN link C (.232 – .235) 4 addresses 192.168.10.236/30 → WAN link D (.236 – .239) 4 addresses Spare (.240 – .255) 16 addresses ``` You've packed 248 addresses of usable allocation into a `/24` with no overlap and 16 addresses spare for growth. If you'd allocated four `/24`s naively (one per requirement) you would have needed a `/22` — four times the address space. ### Why largest-first matters Imagine you allocated WAN links first at `.0/30`. Now you want a `/25` (128 addresses). The next `/25` boundary is `.128` — so addresses `.4` through `.127` are now stuck "in the middle" and you can't use them for a single `/25` because that block has to start at a `/25` boundary (multiple of 128). You'd burn 124 addresses to bad ordering. Always largest first. The rule has saved more enterprise IP plans than any single other practice. ## Reverse-engineering: from host count to mask Common exam pattern: "You need 350 hosts on a segment. What's the smallest mask?" The thought process: 1. Smallest 2^n ≥ 350 + 2 (for network + broadcast) = 512 = 2^9 2. So you need **9 host bits**. 3. 32 − 9 = **/23 mask**. 4. Sanity check: /23 = 510 usable hosts ≥ 350. ✓ Try a few: - 24 hosts → smallest 2^n ≥ 26 = 32 = 2^5 → /27 - 60 hosts → smallest 2^n ≥ 62 = 64 = 2^6 → /26 - 200 hosts → smallest 2^n ≥ 202 = 256 = 2^8 → /24 - 1,000 hosts → smallest 2^n ≥ 1,002 = 1,024 = 2^10 → /22 This is two seconds with the table memorized. Don't waste exam time computing 2^n. ## Wildcard masks (for OSPF and ACLs) OSPF and ACLs use a **wildcard mask** instead of a subnet mask. A wildcard mask is the **bit-inverse** of the subnet mask. | Subnet mask | Wildcard mask | |---|---| | 255.255.255.0 (/24) | 0.0.0.255 | | 255.255.255.128 (/25) | 0.0.0.127 | | 255.255.255.192 (/26) | 0.0.0.63 | | 255.255.255.224 (/27) | 0.0.0.31 | | 255.255.255.240 (/28) | 0.0.0.15 | | 255.255.255.248 (/29) | 0.0.0.7 | | 255.255.255.252 (/30) | 0.0.0.3 | | 255.255.252.0 (/22) | 0.0.3.255 | | 255.255.0.0 (/16) | 0.0.255.255 | **Quick conversion:** for each octet, `wildcard = 255 − subnet`. So `255.255.255.192` → `0.0.0.63`. Use cases you'll see all the time: ``` R1(config-router)# network 192.168.10.0 0.0.0.255 area 0 # OSPF — match /24 R1(config)# access-list 10 permit 10.0.0.0 0.255.255.255 # ACL — match /8 ``` `0` bits in the wildcard mean "this bit must match exactly." `1` bits mean "wild — don't care." Same logic as a subnet mask, inverted. ## Subnetting across octet boundaries Almost everything in CCNA labs uses subnets within a single octet (the fourth octet). Real networks routinely subnet across the third octet for larger ranges. The key insight: **the magic-number trick works in whatever octet the mask is "interesting" in.** For `/19` (mask 255.255.224.0): - Interesting octet: **224** in the **third octet**. - Block size in the third octet: **256 − 224 = 32**. - Subnets: third-octet values 0, 32, 64, 96, 128, 160, 192, 224. - So `10.0.0.0/19` covers `10.0.0.0` – `10.0.31.255` (32 × 256 addresses = 8,192). - Next /19 starts at `10.0.32.0` and covers `10.0.32.0` – `10.0.63.255`. Practice this on `/18`, `/17`, /20, /21, /22, /23 until it's reflex. ## Special IPv4 addresses you must recognize Some address ranges are reserved or have special meaning. The CCNA exam tests recognition. | Range | Meaning | |---|---| | `0.0.0.0/0` | Default route — "anywhere I don't have a specific route to" | | `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | RFC 1918 private addresses | | `127.0.0.0/8` | Loopback — `127.0.0.1` is "this host" | | `169.254.0.0/16` | Link-local / APIPA — auto-assigned when DHCP fails | | `100.64.0.0/10` | Carrier-grade NAT (CGNAT) — ISP shared space, not routable on the public internet | | `224.0.0.0/4` | Multicast | | `240.0.0.0/4` | Experimental / reserved | | `255.255.255.255` | Limited broadcast | | `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24` | Documentation only — used in textbooks and RFCs (TEST-NET) | ## Enterprise IP plan — full worked example You're designing IP for a mid-size US enterprise with: - HQ campus: 800 users + 200 servers + 50 IoT devices - Branch A: 150 users - Branch B: 80 users + 20 servers - Branch C: 25 users (small office) - 6 point-to-point WAN links between sites - 10 loopback addresses for routing protocols Available: `10.50.0.0/16`. ### Step 1 — allocate per site Allocate at /20 boundaries (4,096 addresses each): ``` 10.50.0.0/20 → HQ campus (4,094 hosts) 10.50.16.0/20 → Branch A (4,094 hosts) 10.50.32.0/20 → Branch B (4,094 hosts) 10.50.48.0/20 → Branch C (4,094 hosts) 10.50.64.0/20 → Reserved (growth) (4,094 hosts) … 10.50.240.0/20 → Infrastructure (WAN links + loopbacks) ``` ### Step 2 — subnet within HQ (`10.50.0.0/20`) HQ needs: - Users: 800 → /22 (1,022 hosts) - Servers: 200 → /24 (254 hosts) - IoT: 50 → /26 (62 hosts) ``` 10.50.0.0/22 → HQ users (.0.0 – .3.255) 10.50.4.0/24 → HQ servers (.4.0 – .4.255) 10.50.5.0/26 → HQ IoT (.5.0 – .5.63) 10.50.5.64/26 → Reserved 10.50.6.0/23 → Reserved (growth) 10.50.8.0/21 → Reserved (growth) ``` ### Step 3 — subnet within Branch A (`10.50.16.0/20`) 150 users → /24 with room to grow. ``` 10.50.16.0/24 → Branch A users (254 hosts) 10.50.17.0/24 → Reserved (growth) 10.50.18.0/24 → Reserved (growth) … ``` ### Step 4 — WAN links + loopbacks from `10.50.240.0/20` ``` 10.50.240.0/30 → HQ ↔ Branch A 10.50.240.4/30 → HQ ↔ Branch B 10.50.240.8/30 → HQ ↔ Branch C 10.50.240.12/30 → Branch A ↔ Branch B 10.50.240.16/30 → Branch A ↔ Branch C 10.50.240.20/30 → Branch B ↔ Branch C 10.50.241.1/32 → HQ Router loopback 10.50.241.2/32 → Branch A Router loopback 10.50.241.3/32 → Branch B Router loopback 10.50.241.4/32 → Branch C Router loopback ... etc. ``` Notice the principles: - **Largest allocations first** at each level. - **Reserve before you need it** — growth space is much cheaper than re-numbering 800 hosts later. - **Predictable structure** — every site is a /20, every WAN link is a /30 starting at .240. New engineers can predict where things live. This is the kind of plan you'd build in real life. Spend 30 minutes designing it once, save 30 hours of "wait, where does Branch D go?" later. ## Common mistakes 1. **Off-by-one on broadcast.** `.0/26` broadcast is `.63`, not `.64`. The last address in the block belongs to that subnet's broadcast — the next subnet starts after. 2. **Forgetting the −2 for usable hosts.** A `/26` has 64 addresses but only **62** usable hosts. 3. **Picking the wrong mask for the host count.** "We need 30 hosts" → many students pick `/27` (30 usable). Works exactly to the limit — no headroom. In production always go one size bigger if you can afford it. 4. **Mixing classful and classless thinking.** Old IPv4 classes (A=/8, B=/16, C=/24) are dead. CIDR replaced them in the 1990s. Don't say "class C network" — say "/24" or "192.168.0.0/24". 5. **Confusing the network and broadcast addresses in routing.** Static routes use the **network** address, never the broadcast. `ip route 192.168.10.64 255.255.255.192 ...` is correct; `192.168.10.127 255.255.255.192` is wrong. 6. **VLSM allocated smallest-first.** Eats your address space with unusable gaps. Always largest first. 7. **Wildcard ≠ subnet mask.** A common ACL bug. `access-list 10 permit 10.0.0.0 255.0.0.0` matches **nothing** because the wildcard `255.0.0.0` means "match the first octet exactly, ignore the rest." You wanted `0.255.255.255`. 8. **Forgetting that 127.0.0.0/8 is reserved as loopback.** Never allocate it on a real interface and never route it. Pinging 127.0.0.1 is a fine local-stack test — what you can't do is reach 127.0.0.1 on another host, since every device's 127.0.0.1 is itself. 9. **Using `/31` on equipment that doesn't support it.** RFC 3021 allows /31 on point-to-point links, but very old gear barfs. Stick with `/30` if you don't control both ends. ## Practice problems with worked solutions Try these *before* looking at the solutions. --- **Problem 1.** What is the network address of `172.16.85.200/27`? **Solution:** - /27, block size = 32, interesting octet = 4th. - Largest multiple of 32 ≤ 200 = **192**. - Network: `172.16.85.192/27`. --- **Problem 2.** Given `192.168.5.0/24`, list all /29 subnets and their usable host ranges. **Solution:** - /29 in a /24 = 32 subnets (256 / 8). - Block size 8. - `.0/29` (.1–.6), `.8/29` (.9–.14), `.16/29` (.17–.22), `.24/29` (.25–.30), … all the way to `.248/29` (.249–.254). --- **Problem 3.** You need to support 500 hosts on one segment. What's the smallest mask? **Solution:** - Smallest 2^n ≥ 502 = 512 = 2^9. - 9 host bits = 32 − 9 = **/23 mask** (510 usable hosts). --- **Problem 4.** What is the broadcast of `10.10.32.0/19`? **Solution:** - /19, block size in 3rd octet = 32. - Next /19 boundary after .32.0 is .64.0. - Broadcast = next boundary − 1 = `10.10.63.255`. --- **Problem 5.** Convert `255.255.255.240` to wildcard mask. **Solution:** - 255 − 240 = 15. - Wildcard: **`0.0.0.15`**. --- **Problem 6.** VLSM problem. You have `192.168.100.0/24`. Allocate: - A: 60 hosts - B: 25 hosts - C: 12 hosts - D, E, F: 2 hosts each (P2P) **Solution (largest first):** | Segment | Hosts | Mask | Network | Broadcast | |---|---|---|---|---| | A | 60 | /26 | 192.168.100.0 | 192.168.100.63 | | B | 25 | /27 | 192.168.100.64 | 192.168.100.95 | | C | 12 | /28 | 192.168.100.96 | 192.168.100.111 | | D | 2 | /30 | 192.168.100.112 | 192.168.100.115 | | E | 2 | /30 | 192.168.100.116 | 192.168.100.119 | | F | 2 | /30 | 192.168.100.120 | 192.168.100.123 | Total used: 124 addresses out of 256. Plenty of spare. --- **Problem 7.** A router has interface `Gi0/0` with IP `10.5.4.30/29`. Will host `10.5.4.34` be on the same subnet? **Solution:** - /29 → block size 8 → subnets at .0, .8, .16, .24, .32, .40, … - `.30` falls in `.24/29` (range .24 – .31). - `.34` falls in `.32/29` (range .32 – .39). - Different subnets — **no, they're not on the same segment**. This is exactly the kind of trap exam questions use. Plot both addresses on the magic-number map before answering. --- **Problem 8.** How many `/27` subnets fit in a `/22`? **Solution:** - /22 = 1,024 addresses. /27 = 32 addresses. - 1,024 / 32 = **32 /27 subnets**. Alternative: subtract the prefix lengths → 27 − 22 = 5 bits of difference → 2^5 = 32. ## Common interview questions These come up in entry-level network engineer interviews. Practice answering each in under 30 seconds out loud. - *"Walk me through how you'd subnet a /24 for 4 VLANs of 50 users each."* - *"What's the difference between a subnet mask and a wildcard mask?"* - *"You're given 10.10.10.85/27. What's the network, broadcast, and how many usable hosts?"* - *"Explain VLSM in one minute. When would you use it?"* - *"Why do we lose 2 addresses per subnet? Are there any exceptions?"* The third bullet trips most candidates — the answer is `network = .64, broadcast = .95, 30 usable`. If you can't do it in 10 seconds, drill the magic-number trick more. ## IPv6 subnetting — a brief note IPv6 subnetting is different in scale but easier in math. Every interface typically gets a `/64` (18 quintillion addresses). You subnet at boundaries of 4 bits (called *nibbles*) — `/48`, `/52`, `/56`, `/60`, `/64`. The math is hexadecimal, not decimal. But you almost never run into "out of host bits" since each `/64` is enormous. See [IPv6 Basics](/topics/ipv6-basics/) for the IPv6-specific story. ## Lab to try tonight 1. **Magic-number drill** — take any `/24` (e.g. `10.10.10.0/24`). Subnet it into eight `/27`s. Write out network and broadcast for each on paper, then verify with a subnet calculator. 2. **Mixed-size practice** — build a small Packet Tracer topology with three routers and three subnets sized for: 100 hosts, 30 hosts, 2 hosts. Pick the smallest mask that works for each. Assign IPs. 3. **Static routing** — configure static routes between the routers from step 2. Confirm all hosts can ping each other. 4. **VLSM challenge** — take a single `/22` and chop it into subnets of decreasing size (one /24, one /26, two /28s, four /30s). Confirm no overlap on paper, then deploy in Packet Tracer. 5. **Wildcard mask drill** — convert these subnet masks to wildcard masks: /16, /19, /23, /25, /28, /30. Do them out loud, then check. 6. **Enterprise plan drill** — design an IP plan for a fictional 3-branch enterprise with HQ (500 hosts), Branch A (100 hosts), Branch B (50 hosts), and 3 WAN links. Use `172.20.0.0/16`. Spend 20 minutes on it. Compare with a colleague if possible. ## Cheat strip | Need to find… | Use this | |---|---| | **Block size** | 256 − interesting octet of the mask | | **Where does subnet X start** | Always a multiple of block size | | **Broadcast** | Next subnet boundary − 1 | | **Usable hosts** | 2^(host bits) − 2 | | **Smallest mask for N hosts** | Find smallest 2^n − 2 ≥ N | | **Wildcard mask** | 255 − each octet of subnet mask | | **How many /Y in a /X** | 2^(Y − X) | | **/30** | 4 addresses, 2 usable — classic point-to-point | | **/31** | 2 addresses, both usable (RFC 3021) — modern point-to-point | | **/32** | Single host — loopback or host route | | **VLSM rule** | Always allocate largest subnet first | | **Special: 127.0.0.0/8** | Loopback — never route, never assign | | **Special: 169.254.0.0/16** | APIPA — DHCP failure indicator | | **Special: 0.0.0.0/0** | Default route | ## Frequently asked questions **Q: How do I subnet quickly without a calculator?** A: Use the magic-number trick. Find the interesting octet (the one the mask splits), then compute `block size = 256 − mask value in that octet`. Every subnet starts at a multiple of the block size. Broadcast is one below the next subnet. This works in under 15 seconds once practised — it's the method senior engineers use in interviews. **Q: What's the difference between VLSM and FLSM?** A: FLSM (Fixed-Length Subnet Masking) gives every subnet the same size — wastes address space when subnets have very different host counts. VLSM (Variable-Length Subnet Masking) lets each subnet be sized to actual need — a /30 point-to-point link and a /24 user LAN can coexist in the same parent block. Modern designs are always VLSM; FLSM is an exam-only concept now. **Q: Can I use a /31 in production?** A: Yes, on point-to-point links between modern gear (RFC 3021, since 2001). /31 gives you 2 usable addresses — perfect for a point-to-point link — with zero waste. Every Cisco IOS from the last 15 years supports it. The only reason to still use /30 is if you're interoperating with very old equipment that treats the "network" address as unreachable. **Q: How is IPv6 subnetting different from IPv4?** A: You almost never worry about host count — every interface typically gets a /64 (18 quintillion addresses). Subnetting happens at nibble boundaries (/48, /52, /56, /60, /64) so the hex maths is trivial. Enterprises typically get a /48 from their provider and carve /64s per VLAN. There's no "smallest mask for N hosts" calculation — every LAN is a /64, full stop. --- ## IPv6 Basics — https://packetmentor.com/topics/ipv6-basics/ > 128-bit addresses, hex notation, the :: shortcut, address types (global, link-local, multicast), SLAAC, and why IPv6 is finally happening 25 years after it was supposed to. ## Mental model IPv4 has ~4 billion addresses, which is much less than the number of devices that want to be online. IPv6 has **128 bits** of address space — 340 undecillion addresses (3.4 × 10³⁸). For practical purposes, infinite. The pain: 128-bit addresses are unreadable in binary or decimal. IPv6 uses hex notation in 8 groups of 4 digits, separated by colons: ``` 2001:0db8:acad:0001:0000:0000:0000:0005 ``` That's a lot to type. Two shortcuts make it bearable: 1. **Drop leading zeros within a group:** `0db8` → `db8`, `0001` → `1`. 2. **One `::` per address collapses a run of zero groups:** `0000:0000:0000:0005` → `::5`. Final compressed form: ``` 2001:db8:acad:1::5 ``` ## The standard split: /64 prefix + /64 interface ID By convention (and protocol requirement for SLAAC), every IPv6 subnet is `/64`: - First 64 bits = network prefix - Last 64 bits = host (interface ID) That gives every subnet 2⁶⁴ ≈ 18 quintillion hosts — wildly excessive, by design. The math is simple. Don't overthink it. ## Three address types you need to know | Type | Range | Purpose | |---|---|---| | **Global Unicast** | 2000::/3 (mostly 2001::/16) | Routable on the public internet. Like IPv4 public. | | **Link-Local** | fe80::/10 | Only valid on a single link. Auto-assigned. Every IPv6 interface has one. | | **Unique Local (ULA)** | fc00::/7 | Internal use, not routed on the public internet. Like IPv4 private (RFC 1918). | | **Multicast** | ff00::/8 | Groups. IPv6 has no broadcast — multicast replaces it. | | **Loopback** | ::1/128 | localhost. Same role as 127.0.0.1. | | **Unspecified** | ::/128 | "I don't have an address yet." Like 0.0.0.0. | For CCNA: focus on Global Unicast, Link-Local, and Multicast. ULA is the IPv6 RFC 1918 equivalent — not used as widely as you'd expect. ## Link-Local — the address every IPv6 interface auto-gets Every IPv6 interface generates a link-local address as soon as it comes up — without configuration. Format: `fe80::` + a 64-bit interface identifier (often derived from the MAC). It's only valid on the local link (one switch / one cable). Routers don't forward link-local traffic between subnets. **Why it matters:** routing protocols (OSPFv3, EIGRPv6) and Neighbor Discovery use link-local addresses for peering — not the global ones. This trips up engineers who configure global IPv6 but forget link-local will be present too. ## SLAAC — hosts pick their own address In IPv4, hosts almost always get their IP from DHCP. In IPv6, there's a built-in alternative: **SLAAC** (Stateless Address Autoconfiguration). How it works: 1. Router periodically advertises the /64 prefix on the link. 2. Host hears it, takes the prefix, and generates its own /64 interface ID (random or based on MAC). 3. Host checks no one else is using that full address (Duplicate Address Detection). 4. Done — host has a unique IPv6, no DHCP server involved. SLAAC doesn't hand out DNS or domain info. For that, you either use **DHCPv6** in parallel or rely on **RDNSS** options in Router Advertisements. ## Commands ### Enable IPv6 + assign addresses ``` R1(config)# ipv6 unicast-routing ! enable IPv6 globally R1(config)# interface GigabitEthernet0/0 R1(config-if)# ipv6 address 2001:db8:acad:1::1/64 ! global unicast R1(config-if)# ipv6 address autoconfig ! or let SLAAC do it R1(config-if)# ipv6 enable ! creates link-local even without a global ``` ### Verify ``` R1# show ipv6 interface brief R1# show ipv6 interface GigabitEthernet0/0 R1# show ipv6 neighbors ! IPv6 equivalent of ARP table R1# show ipv6 route ``` ## Common mistakes 1. **Forgetting `ipv6 unicast-routing`.** Without it, the router has IPv6 addresses but won't route between them. Always enable globally. 2. **Using `::` twice in one address.** RFC says one `::` per address only. `2001::1::5` is ambiguous (couldn't tell how many zero groups each side has). 3. **Confusing IPv6 link-local with IPv4 APIPA.** APIPA (169.254.x.x) means "DHCP failed, here's a self-assigned address." IPv6 link-local (fe80::/10) is always present, always valid, and used by routing protocols. Different beasts. 4. **Treating IPv6 like a larger IPv4.** Some IPv4 reflexes don't apply. There's no broadcast in IPv6 (use multicast). There's no NAT in standard IPv6 (every device has a globally unique address). ARP is replaced by Neighbor Discovery. 5. **Forgetting that 2001:db8::/32 is reserved for documentation.** Never use it in production — it's the equivalent of 192.0.2.0/24 in examples. Picking it for a real network → public internet doesn't route it. 6. **Skipping IPv6 because "we're not there yet."** Most cellular networks are IPv6-primary today. Major cloud providers, content delivery networks, and ISP backbones run IPv6 heavily. CCNA tests IPv6; production runs it. Time to learn. ## Lab to try tonight 1. Take any IPv6 address in long form. Practice compressing it to short form by hand. Verify with a calculator. 2. On a router, enable `ipv6 unicast-routing`. Configure `ipv6 address 2001:db8:acad:1::1/64` on an interface. Confirm with `show ipv6 interface brief`. 3. Connect a PC. Set it to "Auto" for IPv6. Observe it pick up an address via SLAAC. 4. Run `ping 2001:db8:acad:1::1` from the PC. Verify reachability. 5. `show ipv6 neighbors` on the router — should show the PC's MAC and IPv6. 6. Bonus: configure OSPFv3 between two routers on a /64 link. Note that neighbor adjacencies form using link-local (fe80::) addresses, not the global ones you configured. ## Cheat strip | Concept | Plain English | |---|---| | **128 bits** | 8 hex groups, 4 digits each | | **::** | Collapse one run of all-zero groups. Once per address. | | **/64** | Standard subnet prefix length | | **Global Unicast** | 2000::/3 — routable, like IPv4 public | | **Link-Local** | fe80::/10 — local-link only, always present | | **Multicast** | ff00::/8 — groups. Replaces IPv4 broadcast. | | **SLAAC** | Hosts auto-generate IPv6 from router advertisements | | **`ipv6 unicast-routing`** | Must be on for the router to forward IPv6 | | **2001:db8::/32** | Reserved for examples / documentation. Never production. | ## Frequently asked questions **Q: Why did we need IPv6?** A: IPv4 exhaustion. IPv4 has 4.3 billion addresses; the world has ~5 billion internet users and 20+ billion IoT devices. IANA ran out of new IPv4 blocks in 2011; regional registries followed. NAT bought time but broke end-to-end reachability. IPv6 has 2^128 addresses — enough for every atom on Earth's surface to have several. Adoption is now over 40% in the US per Google's stats. **Q: What's an IPv6 link-local address?** A: Every IPv6 interface auto-generates an address in `fe80::/10` used only on the local link (never routed). Two hosts on the same segment can talk using link-local addresses without any global assignment. Neighbor Discovery, OSPFv3, and RIPng all use link-local for their control-plane traffic. When you see `fe80::` you know it's on-link. **Q: What replaced ARP in IPv6?** A: Neighbor Discovery Protocol (NDP), which runs over ICMPv6. Instead of ARP request/reply, IPv6 uses Neighbor Solicitation (NS) and Neighbor Advertisement (NA). NDP also handles router discovery (RS/RA), Duplicate Address Detection, and Redirect messages. Because NDP uses multicast instead of broadcast, it's more efficient — the target host receives the query, not everyone on the link. **Q: Do I need dual-stack forever?** A: Ideally no — the endgame is IPv6-only. Reality: many enterprise apps, older SaaS, and edge cases still require IPv4 for years. The pragmatic path is dual-stack now, IPv6-primary next, IPv4-as-a-service via NAT64 for legacy destinations. Big tech (Meta, Microsoft internal, T-Mobile mobile) are already IPv6-only internally with NAT64 at the edge. **Q: How do I write an IPv6 address in short form?** A: Two rules: (1) drop leading zeros in each group (`0db8 → db8`); (2) replace ONE run of all-zero groups with `::` (`fe80:0:0:0:0:0:0:1 → fe80::1`). You can only use `::` once per address (otherwise it's ambiguous). Example: `2001:0db8:0000:0000:0000:0000:0000:0001` → `2001:db8::1`. --- ## ARP — Address Resolution Protocol — https://packetmentor.com/topics/arp/ > How a host turns an IP address into the MAC address it needs to actually deliver a frame. Broadcast question, unicast answer, cached for hours. Also covers Gratuitous ARP, Proxy ARP, and the ARP spoofing attack. ## Mental model A host has an IP packet to send to `10.0.0.50`. The packet needs to be wrapped in an Ethernet frame, and that frame needs a **destination MAC address**. But the host only knows the destination's IP, not its MAC. ARP's job: turn an IP into a MAC. The protocol is brutally simple: 1. Host broadcasts a Layer-2 frame to everyone: *"Who has IP 10.0.0.50? Reply with your MAC."* 2. The target host hears its own IP and replies unicast: *"I am 10.0.0.50, my MAC is bb:bb:bb:bb."* 3. Both sides remember the mapping in their ARP cache for ~4 hours. That's the whole protocol. The rest is variations and edge cases. ## The ARP table — view it ``` R1# show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 10.0.0.1 - aaaa.bbbb.cccc ARPA GigabitEthernet0/0 Internet 10.0.0.50 4 dddd.eeee.ffff ARPA GigabitEthernet0/0 ``` Each entry: an IP, the MAC it maps to, and how long until it expires. `Age -` means it's a local interface (never expires). On a Linux laptop: `arp -a`. On Windows: `arp -a`. ## ARP only works within a broadcast domain ARP frames are L2 broadcasts. They don't cross routers. So ARP only resolves IPs that are **on the same subnet** as the asker. When a host wants to reach an IP on a *different* subnet, it sends the packet to its **default gateway's** MAC instead. The host: 1. Notices the destination IP isn't in its own subnet. 2. ARPs for its default gateway's IP. 3. Wraps the packet in a frame destined for the gateway's MAC. 4. The gateway (a router) unwraps, re-wraps for the next hop, and forwards. This is why your computer ARPs for `10.0.0.1` (the router) when you `ping 8.8.8.8` — the destination MAC for the frame leaving your NIC is the router's, not Google's. ## Gratuitous ARP (GARP) Sometimes a host sends an ARP reply that nobody asked for: *"Hey, I'm 10.0.0.50, my MAC is X."* This is **gratuitous ARP**. Used to: - Announce a new IP assignment (after DHCP) - Refresh other hosts' caches after a failover (HSRP/VRRP do this) - Detect duplicate IPs on the wire (if someone replies, "that's my IP", you have a conflict) ## Proxy ARP A router answers ARP requests for IPs that aren't its own — pretending to be the destination so the host sends frames to the router, which then routes them properly. Used in some legacy networks where hosts have wrong subnet masks. **Mostly an anti-pattern in modern networking** — disable it in production. ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# no ip proxy-arp ``` ## ARP spoofing — the classic attack An attacker sends gratuitous ARP replies claiming to be the default gateway: *"Hey everyone, I'm 10.0.0.1, my MAC is X."* All victim hosts update their ARP cache and start sending Layer-2 frames to the attacker. The attacker can now read, modify, or forward traffic as MITM. **The defense: Dynamic ARP Inspection (DAI)** on switches. DAI watches ARP packets and validates them against the DHCP Snooping binding table. ARP replies that don't match a legit DHCP lease get dropped. ## Commands ``` ! View ARP table on a Cisco device R1# show arp R1# show ip arp ! Clear an ARP entry (forces re-resolution) R1# clear ip arp 10.0.0.50 ! Adjust ARP cache timeout (default 4 hours = 14400 seconds) R1(config)# interface GigabitEthernet0/0 R1(config-if)# arp timeout 1800 ! 30 minutes ! Static ARP entry (manually pin an IP-MAC mapping) R1(config)# arp 10.0.0.50 dddd.eeee.ffff arpa ! Disable Proxy ARP R1(config-if)# no ip proxy-arp ``` ## Common mistakes 1. **Confusing ARP table with MAC address table.** ARP table (on hosts and routers): IP → MAC. MAC address table (on switches): MAC → port. Different layers, different purposes. 2. **Static ARP entries left in place after a server moves.** A static entry never times out. If you set `arp 10.0.0.50 aaaa.bbbb.cccc` and the actual server later changes its NIC, traffic blackholes. Use sparingly. 3. **Leaving Proxy ARP on.** Default-on for historical reasons. Disable it on modern networks — it hides misconfiguration and creates security risks. 4. **Forgetting ARP only works in the same broadcast domain.** Hosts can't ARP for an IP behind a router. Always check default gateway settings when "ping by IP doesn't work" troubleshooting starts. 5. **Confusing IPv6 Neighbor Discovery with ARP.** IPv6 doesn't use ARP — it uses **Neighbor Discovery Protocol (NDP)**, which is conceptually similar but uses multicast (not broadcast) and runs over ICMPv6. The exam tests this distinction. 6. **Not realizing the gateway's MAC is what your frames are addressed to.** When you ping anywhere off-subnet, the destination MAC of the outgoing frame is your router's MAC, not the remote host's. Surprises Wireshark beginners constantly. ## Lab to try tonight 1. Open a terminal on your laptop. Run `arp -a` (or `ip neigh` on Linux). Note the entries. 2. Ping a device on your LAN. Run `arp -a` again — the new entry is the device's MAC. 3. Ping a public IP (e.g. 8.8.8.8). Note that **8.8.8.8 doesn't appear in your ARP table** — only your gateway does. 4. Open Wireshark, start capture. Run `arp -d *` (Windows) or `sudo arp -d ` (Linux) to clear an entry. Re-ping. Watch the ARP request (broadcast) and ARP reply (unicast). 5. Bonus: set up a small lab with DHCP Snooping + Dynamic ARP Inspection. Run a free ARP-spoofing tool from one host. Watch DAI block the bogus replies. ## Cheat strip | Concept | Plain English | |---|---| | **ARP** | IP → MAC address resolver | | **Request** | Layer-2 broadcast asking "who has X?" | | **Reply** | Unicast answer with the responder's MAC | | **Cache** | IP↔MAC mappings kept ~4 hours | | **Gratuitous ARP** | Unsolicited reply — used for announcements and failover | | **Proxy ARP** | Router answers for others. Mostly disable in production. | | **ARP spoofing** | Attacker claims to be the gateway. Defend with DAI. | | **IPv6 equivalent** | Neighbor Discovery (NDP) — multicast, not broadcast | | **Off-subnet** | ARP only resolves IPs on your own broadcast domain. Off-subnet = use gateway. | ## Frequently asked questions **Q: What's the difference between ARP and RARP?** A: ARP resolves an IP to a MAC (I know the IP, I need the MAC). RARP does the reverse (I know my MAC, I need my IP) — used by diskless workstations in the 1980s to get an IP at boot. RARP has been dead for decades — replaced by BOOTP, then DHCP. CCNA scope: know ARP inside-out, know RARP existed. **Q: What is gratuitous ARP?** A: An ARP reply nobody asked for — a device announcing "hey everyone, this IP is at this MAC." Used at boot to detect duplicate IPs (if someone replies, you have a conflict) and by HSRP/VRRP to notify neighbours after a failover ("the virtual IP is now at my MAC"). Also used by attackers for ARP spoofing — which is why Dynamic ARP Inspection (DAI) exists. **Q: Does IPv6 use ARP?** A: No — IPv6 uses Neighbor Discovery Protocol (NDP), which does the same job with better mechanics. NDP runs over ICMPv6 and includes: neighbour solicitation (like ARP request), neighbour advertisement (like ARP reply), router solicitation, and router advertisement. Because NDP uses multicast instead of broadcast, it's more efficient on large networks. **Q: What is proxy ARP and should I disable it?** A: Proxy ARP is when a router answers ARP requests on behalf of a host on another subnet — making two subnets look like one big subnet from the client's perspective. Useful for weird legacy setups (subnetting a shared broadcast domain retrofit-style), dangerous everywhere else because it hides misconfigurations. Modern Cisco default is off on most images (`no ip proxy-arp` on interfaces). Leave it off unless you have a specific reason. **Q: How long does an ARP entry stay in the cache?** A: Cisco default is 4 hours (14400 seconds). Windows default is variable (was 2 minutes on older versions; modern Windows uses reachability-based aging). Change with `arp timeout N` at the interface level. Shorter timeout = more ARP traffic; longer = staler cache when things change. Default is fine for most. --- ## ICMP — Internet Control Message Protocol — https://packetmentor.com/topics/icmp/ > The network's diagnostic channel. Covers echo / reply (ping), destination unreachable, TTL exceeded (traceroute), and the security trade-offs of blocking ICMP at the firewall. ## Mental model IP itself is dumb — it routes packets and that's it. When something goes wrong (no route, dropped packet, looped traffic), IP doesn't know how to tell you. **ICMP is the channel IP uses to send those error messages.** It's also the protocol behind two universal diagnostics: - **`ping`** — sends ICMP Echo Request, gets ICMP Echo Reply, measures round-trip time - **`traceroute`** — sends packets with increasing TTL values, gets ICMP TTL Exceeded back from each hop, builds the path So when you "ping a host" or "traceroute to a server," you're using ICMP. When your router says "Destination host unreachable," that's an ICMP packet. ## Message types you should know | Type | Code | Name | When you'll see it | |---|---|---|---| | **0** | 0 | Echo Reply | "Pong" — the reply to a ping | | **3** | 0 | Net Unreachable | Router has no route to the destination network | | **3** | 1 | Host Unreachable | Reached the destination subnet but the specific host doesn't answer | | **3** | 3 | Port Unreachable | Reached the host, but nothing's listening on that UDP port | | **3** | 4 | Fragmentation Needed | The packet's too big for the next link, DF bit set — Path MTU Discovery uses this | | **5** | 0 | Redirect | "Use a different gateway for that destination" | | **8** | 0 | Echo Request | "Ping" — the question half | | **11** | 0 | TTL Exceeded in Transit | Traceroute hears this from each hop | For CCNA, focus on: **0 (Echo Reply), 3 (Unreachable), 8 (Echo Request), 11 (TTL Exceeded).** ## How ping actually works ``` PC Target │ ─── Echo Request (type 8) ──► │ │ │ │ ◄──── Echo Reply (type 0) ───── │ ``` If the round-trip succeeds, ping prints the latency. If it fails: - **No reply at all** → host might be down, ICMP blocked, or routing is broken - **Destination unreachable** → a router along the path returned an ICMP type 3 - **TTL expired** → routing loop somewhere; the packet bounced until TTL reached 0 ## How traceroute actually works ``` Hop 1: Send packet with TTL=1 Router 1 decrements to 0, drops, sends back ICMP type 11 Now you know hop 1's IP. Hop 2: Send packet with TTL=2 Router 1 decrements to 1, forwards. Router 2 decrements to 0, drops, sends back ICMP type 11. Now you know hop 2's IP. ...repeat until you reach the destination, which replies normally. ``` Linux/Mac `traceroute` uses UDP probes by default. Windows `tracert` uses ICMP Echo Requests by default. Both work, slightly different behavior at the destination. ## Commands ### Ping from a Cisco router ``` R1# ping 8.8.8.8 R1# ping 8.8.8.8 size 1500 df-bit ! larger packet, set Don't Fragment R1# ping 8.8.8.8 source GigabitEthernet0/0 ``` Extended ping (interactive prompt) gives you more options: ``` R1# ping Protocol [ip]: Target IP address: 8.8.8.8 Repeat count [5]: 100 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: GigabitEthernet0/0 ``` ### Traceroute ``` R1# traceroute 8.8.8.8 R1# traceroute 8.8.8.8 source GigabitEthernet0/0 ``` ### Block specific ICMP types with ACL ``` ip access-list extended FILTER-ICMP deny icmp any any redirect ! block type 5 deny icmp any any echo ! block inbound pings (controversial) permit icmp any any ! allow everything else ``` ## Should you block ICMP at the firewall? This is a debate that's been going on for 25 years. Short version: **Blocking ALL ICMP is wrong.** It breaks: - Path MTU Discovery (causes packet loss with no good error message) - Traceroute (useful diagnostic for users + ops) - Network diagnostics generally **Blocking SOME ICMP is reasonable.** Block: - Echo Request from the internet → your hosts (stops trivial host scanning) - Redirect messages (avoid being misdirected by attackers) - Timestamp Request/Reply (legacy, rarely needed) **Always allow:** - Type 3 (Destination Unreachable) — including code 4 (Fragmentation Needed) for PMTUD - Type 11 (TTL Exceeded) — so traceroute works inbound ## Common mistakes 1. **"My ping doesn't work, the network is broken."** A target host might be configured to ignore ICMP without any actual network issue. Always test with multiple tools (ping + curl + nc) before declaring outage. 2. **Blocking ICMP entirely at the perimeter.** Breaks PMTUD silently. Users will report intermittent loading of large files / HTTPS pages and you'll waste hours debugging. 3. **Confusing TTL with timeout.** TTL is in hops, not seconds. A packet doesn't "expire after N seconds" — it expires after N routers decrement it to zero. Default TTL is 64 (Linux/macOS) or 128 (Windows). 4. **Trusting ICMP source addresses.** ICMP error messages can be spoofed. Don't make critical routing decisions based on unauthenticated ICMP. 5. **Confusing ICMP and ICMPv6.** IPv6 has its own ICMPv6, which is much more important — it carries Neighbor Discovery (the ARP replacement), Router Advertisements (SLAAC), and Multicast Listener Discovery. **Never block ICMPv6** at routers — IPv6 won't function. ## Lab to try tonight 1. From your laptop: `ping google.com`. Use Wireshark to confirm the packets are ICMP type 8 (request) and type 0 (reply). 2. `traceroute google.com` (or `tracert` on Windows). Note the hops increasing in TTL. 3. From a Cisco router: `ping 8.8.8.8 size 1500 df-bit`. If you get "M.M.M.M.M" output, fragmentation is required but Don't Fragment bit is set — your path has an MTU smaller than 1500. 4. Configure an ACL that blocks inbound Echo Request on a router interface. Verify pings now fail from outside but the host is still reachable on other protocols. 5. Remove the ACL. Confirm pings work again. ## Cheat strip | Concept | Plain English | |---|---| | **ICMP** | IP's error/diagnostic channel | | **Type 0 / 8** | Echo Reply / Request (ping) | | **Type 3** | Destination Unreachable (with sub-codes) | | **Type 11** | TTL Exceeded (traceroute uses this) | | **TTL** | Hop count, not seconds. Default 64 or 128. | | **PMTUD** | Path MTU Discovery — needs ICMP type 3 code 4 | | **`ping`** | Uses ICMP type 8 / 0 | | **`traceroute`** | Uses TTL trick to map hops | | **Never block all ICMP** | Breaks the network in subtle ways | --- ## IPv6 Address Types: Unicast, Anycast, Multicast, and EUI-64 — https://packetmentor.com/topics/ipv6-address-types/ > The three modes IPv6 uses to move packets — one-to-one (unicast), one-to-nearest (anycast), one-to-many (multicast) — plus the EUI-64 trick that generates a host portion from a MAC address. ## Mental model IPv6 got rid of broadcasts entirely. Instead, everything is either **unicast** (talk to one), **anycast** (talk to the nearest one of many), or **multicast** (talk to all subscribers of a group). If you catch yourself typing "broadcast" in an IPv6 context, you're wrong — that concept doesn't exist here. ## The three address types | Type | What it does | Range | Example | |---|---|---|---| | **Unicast** | One destination, one recipient | Multiple prefixes (below) | `2001:db8::5` | | **Anycast** | Same address on multiple hosts; routers deliver to the *nearest* one | Uses unicast address space; role determined by config | Root DNS servers (13 clusters, one anycast IP each) | | **Multicast** | One-to-many; recipients subscribe to the group | `ff00::/8` | `ff02::1` = all nodes on the link | Anycast has no dedicated prefix — you enable it by assigning the same unicast address to multiple hosts and letting routing pick the shortest path. Useful for CDN edges, DNS, and time servers. ## Unicast sub-types (the three you'll be asked about) ### Global unicast — `2000::/3` The public internet. Every globally reachable IPv6 host has one. Structure: ``` | 48-bit global routing prefix | 16-bit subnet ID | 64-bit interface ID | | from your ISP | your choice | the host | ``` Example: `2001:db8:acad:10::5` — RFC 3849's `2001:db8::/32` is reserved for documentation, hence the constant appearance in Cisco material. ### Unique local — `fc00::/7` (practically `fd00::/8`) The IPv6 answer to RFC 1918. Private, not routable on the public internet, but organisationally globally-unique because the middle 40 bits are randomized. Format: ``` fd | 40-bit random global ID | 16-bit subnet ID | 64-bit interface ID | ``` Two organisations can merge without renumbering, because their random 40-bit IDs collide with probability approaching zero. ### Link local — `fe80::/10` **Every IPv6-enabled interface has one, automatically.** Only valid on the local link — routers never forward link-local packets. Used for: - Neighbor Discovery Protocol (NDP), IPv6's ARP replacement - OSPFv3 / EIGRPv6 hello packets (routing protocols use link-locals as next-hops on point-to-point links) - Router advertisements - Interior DHCPv6 message exchanges You can talk to another host on the same segment using its link-local address, but you need to specify the outgoing interface because `fe80::1` is ambiguous across your host's interfaces: ``` R1# ping fe80::1 Output Interface: GigabitEthernet0/0 ``` ### Loopback / unspecified / mapped | Address | Purpose | |---|---| | `::1/128` | Loopback — same as `127.0.0.1` in IPv4 | | `::/128` | Unspecified — used as source address before an interface has a valid IP | | `::ffff:0:0/96` | IPv4-mapped IPv6 — dual-stack applications see IPv4 sockets as `::ffff:192.0.2.5` | ## Multicast — the CCNA short list You'll be expected to recognise these well-known groups: | Address | Group | |---|---| | `ff02::1` | All nodes on the link (IPv4 equivalent: `224.0.0.1`) | | `ff02::2` | All routers on the link | | `ff02::5` | OSPFv3 all-SPF-routers (was `224.0.0.5`) | | `ff02::6` | OSPFv3 all-DR-routers (was `224.0.0.6`) | | `ff02::9` | RIPng routers | | `ff02::a` | EIGRP for IPv6 | | `ff02::d` | PIM routers | | `ff02::1:ffXX:XXXX` | Solicited-node multicast (used by NDP for MAC lookup) | The **solicited-node** address is IPv6's clever trick — instead of broadcasting an ARP request to every host, a sender constructs the multicast address `ff02::1:ff` + the last 24 bits of the target's IPv6 address, and only the target listens on that specific multicast group. ## EUI-64 — burning the MAC into the address If you configure `ipv6 address /64 eui-64` on an interface, IOS derives the 64-bit host portion from the interface's 48-bit MAC: 1. Split the MAC in half: `AA:BB:CC` | `DD:EE:FF` 2. Insert `FF:FE` in the middle: `AA:BB:CC:FF:FE:DD:EE:FF` 3. Flip the seventh bit (the U/L bit) of the first octet: `AA` (`10101010`) → `A8` (`10101000`) The result becomes the interface ID appended to the prefix. ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ipv6 address 2001:db8:1::/64 eui-64 R1(config-if)# end R1# show ipv6 interface GigabitEthernet0/0 | include 2001 2001:DB8:1:0:A8BB:CCFF:FEDD:EEFF, subnet is 2001:DB8:1::/64 ``` That last IP identifies the interface uniquely without needing a DHCP server — SLAAC uses this to auto-address hosts on the network. ## Configuring each type in IOS ``` R1(config)# interface GigabitEthernet0/0 ! ! Global unicast — pick your own host portion R1(config-if)# ipv6 address 2001:db8:1::1/64 ! ! Or derive it via EUI-64 R1(config-if)# ipv6 address 2001:db8:2::/64 eui-64 ! ! Or accept a prefix from the router via SLAAC (client style) R1(config-if)# ipv6 address autoconfig ! ! Link-local — automatic on any enabled interface, or set manually R1(config-if)# ipv6 enable R1(config-if)# ipv6 address fe80::1 link-local ! R1(config-if)# end ! R1# show ipv6 interface brief GigabitEthernet0/0 [up/up] FE80::1 2001:DB8:1::1 2001:DB8:2:0:A8BB:CCFF:FEDD:EEFF ``` ## The #1 mistake **Forgetting that every IPv6-capable interface has a link-local address**, even if you never assign a global one. `fe80::` addresses show up in `ping` responses, in routing-protocol next-hops, in NDP tables — new engineers think they're seeing garbage. They're not; they're seeing IPv6 doing its job. ## Quick recap - Broadcast is gone. Multicast fills that role. - Every interface gets a link-local (`fe80::`) automatically. - Global unicast = internet routable (`2000::/3`); unique local = private (`fd00::/8`). - EUI-64 generates the host portion from the MAC — used by SLAAC and by manual `eui-64` command. - Anycast is a routing pattern, not a distinct address class — same IP on multiple hosts, nearest wins. --- ## MAC Address Table — https://packetmentor.com/topics/mac-address-table/ > How a switch learns where every device is and decides where to forward each frame. Covers source-MAC learning, destination-MAC lookup, unknown-unicast flooding, and the CAM table on Cisco switches. ## Mental model A hub broadcasts every frame out every port. Dumb but works. A switch is smarter: it remembers where each device lives and forwards frames only to the port where the destination actually is. How does it know? It **learns from the source MAC of every frame it sees**: > *"This frame arrived on port Gi0/3 with source MAC aa:aa:aa. Therefore aa:aa:aa lives on port Gi0/3. I'll remember that."* The MAC address table (also called the **CAM table** — Content-Addressable Memory) is just that memory: a list of MAC ↔ port mappings, per VLAN. When a new frame arrives, the switch: 1. Records the source MAC + port (learning) 2. Looks up the destination MAC 3. If known → sends out the one matching port (unicast) 4. If unknown → floods to all other ports in the same VLAN (let the network figure it out) 5. The destination eventually replies → switch learns its location too That's the whole protocol. Plug-and-play, no configuration. ## Reading the table ``` SW1# show mac address-table Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- 10 aaaa.aaaa.aaaa DYNAMIC Gi0/1 10 bbbb.bbbb.bbbb DYNAMIC Gi0/2 20 cccc.cccc.cccc DYNAMIC Gi0/5 99 1234.5678.9abc STATIC Gi0/24 ``` Read aloud: *"MAC `aaaa.aaaa.aaaa` is on port Gi0/1 in VLAN 10. Learned dynamically. Use this entry to forward frames addressed to it."* **Types:** - **DYNAMIC** — learned from observed traffic. Ages out after 300 seconds of no activity. - **STATIC** — manually configured (or learned via port-security sticky). ## Aging — entries don't live forever If a switch hasn't seen any frames from `aaaa.aaaa.aaaa` for 300 seconds (default), the entry ages out. The switch forgets where it lives. This is intentional — if a device moves from port Gi0/1 to Gi0/3, the old entry needs to expire so the new one can take over. But it also means: 5 minutes of silence and the switch will flood the next frame addressed to that MAC. Adjust the aging timer: ``` SW1(config)# mac address-table aging-time 600 ! 10 minutes ``` ## Static MAC entries Pin a specific MAC to a specific port permanently: ``` SW1(config)# mac address-table static aaaa.bbbb.cccc vlan 10 interface GigabitEthernet0/5 ``` Used for: - Critical servers that should always live on a specific port - Some security setups (combined with port security) - Workarounds for unusual gear Use sparingly. Static entries don't age, so a moved device → table mismatch → traffic blackhole until you fix it. ## Unknown unicast flooding — the "broken silence" problem If a server is quiet for >5 minutes (no outbound traffic), its MAC ages out. Now when a client tries to talk to it, the switch doesn't know where it lives → **floods to every port in the VLAN**. Bandwidth waste, security exposure. Mitigations: - Raise the aging timer beyond your longest silent server (`mac address-table aging-time 1800` = 30 min) - Or: pin critical servers with static entries - Or: configure devices to send periodic heartbeats (most do automatically) ## Commands ``` ! View the entire table SW1# show mac address-table ! Filter by VLAN, MAC, or interface SW1# show mac address-table vlan 10 SW1# show mac address-table address aaaa.bbbb.cccc SW1# show mac address-table interface GigabitEthernet0/1 ! Count entries SW1# show mac address-table count ! Manually clear (forces re-learning on next traffic) SW1# clear mac address-table dynamic SW1# clear mac address-table dynamic interface GigabitEthernet0/1 ! Static entry SW1(config)# mac address-table static aaaa.bbbb.cccc vlan 10 interface Gi0/5 ! Adjust aging SW1(config)# mac address-table aging-time 600 ``` ## Common mistakes 1. **Confusing MAC table with ARP table.** Both contain MAC addresses, but they're different layers and different devices. MAC table = on switches, maps MAC → port. ARP table = on hosts and routers, maps IP → MAC. Don't mix them up. 2. **Forgetting MAC addresses are per-VLAN.** The same MAC can theoretically appear in two VLANs (rare but possible) — the table tracks them separately. Always include `vlan` when troubleshooting. 3. **Assuming flooding only happens at boot.** Any aged-out entry causes flooding when traffic resumes. On a 50-port switch in a chatty environment, this can be constant low-level flooding. 4. **Setting aging too low (or zero).** Aging time of 30 seconds = constant flooding. Aging time of 0 = entries never age, but mobile devices that move ports get stuck. Default 300s is sane. 5. **Trying to filter by MAC at L2.** Filtering on a switch is by port (port security) or by Layer-3 ACL on a routed interface. There's no native "block traffic from MAC X" command on basic IOS switches. 6. **Not recognizing the MAC flooding attack.** An attacker rapidly sends frames with millions of bogus source MACs → fills the CAM table → switch starts flooding everything to all ports (because it can't learn new entries). Defend with **port security** to cap learned MACs per port. ## Lab to try tonight 1. One switch, three PCs in the same VLAN. Connect them. 2. Don't generate any traffic yet. Run `show mac address-table` — likely empty for those ports. 3. Ping from PC-A to PC-B. Re-run the command. Now both MACs appear. 4. Open Wireshark on PC-C. Ping PC-A → PC-B. Confirm PC-C does NOT see the ping traffic (switch sent it only to PC-B's port — that's the whole point of a switch). 5. Wait 5 minutes (or `clear mac address-table dynamic`). Re-ping. With an empty table, the switch initially floods — PC-C briefly sees the first frame in Wireshark before the table re-populates. 6. Add a static entry pinning PC-B's MAC. Verify it survives `clear mac address-table dynamic`. ## Cheat strip | Concept | Plain English | |---|---| | **MAC table / CAM** | Switch's memory of "who lives on which port" | | **Learning** | From source MAC of incoming frames | | **Forwarding** | Looking up destination MAC | | **Unknown unicast flooding** | Forward to all ports in VLAN if dest is unknown | | **Aging time** | Default 300s. Entries expire if no traffic. | | **Static entry** | Manually pinned. Doesn't age. | | **MAC flooding attack** | Overflow the table → forced flooding. Defend with port-security. | | **Per-VLAN** | Same MAC can appear in different VLANs separately | --- ## TCP 3-Way Handshake — https://packetmentor.com/topics/tcp-three-way-handshake/ > The three packets every TCP connection starts with — SYN, SYN-ACK, ACK. Covers sequence numbers, the half-open state, SYN floods, and why HTTPS connections feel slower than they should over high-latency links. ## Mental model TCP is connection-oriented. Before either side can send any data, they have to **agree they're talking to each other** and **synchronize state** — specifically, the sequence numbers each side will use to label its bytes. This agreement is the **3-way handshake**. Three packets. About 1.5 round-trip times. Then ESTABLISHED — actual data can flow. This is why a fresh TCP connection over a 100 ms link takes ~150 ms before the first byte of HTTP request even leaves the client. Cumulative effect explains why opening a fresh HTTPS page (TCP + TLS handshakes) over satellite or distant transcontinental links feels sluggish. ## The three packets ``` Client Server │ │ │ ── SYN (seq=100) ───────────────► │ client picks initial seq │ │ │ ◄── SYN-ACK (seq=500, ack=101) ── │ server picks its own, ACKs client+1 │ │ │ ── ACK (ack=501) ──────────────► │ client ACKs server+1 │ │ │ ◄══════ ESTABLISHED ═══════════► │ data flows both ways ``` What each flag means: - **SYN** (Synchronize): "I want to start a connection. My initial sequence number is X." - **SYN-ACK** (both flags set): "OK. Also, my initial sequence is Y." - **ACK**: "Confirmed." Why is the server's reply called SYN-ACK and not just ACK? Because both directions of the connection need synchronization — server sends its own SYN at the same time as ACKing the client's. ## Sequence numbers — what's really happening TCP labels every byte of payload with a sequence number. The handshake establishes the starting point for each direction. - Client picks **ISN_C** (Initial Sequence Number) randomly — say 100. - Server picks **ISN_S** randomly — say 500. - After the handshake: client will start its payload at 101, server at 501. Both sides know what to expect. ISNs are random for security. If they were predictable (early TCP implementations used a simple counter), attackers could inject packets into existing connections without seeing them. Modern stacks use ISN randomization. ## Half-open connections and SYN flood attacks After step 1 (client sends SYN), the server reserves resources (a TCB — Transmission Control Block) for this potential connection. The server is now in **SYN_RECV** state. If the client never sends the final ACK (step 3), the server's reserved resources sit there until a timeout (~60 seconds). This is **half-open**. **SYN flood attack:** an attacker sends thousands of SYN packets from spoofed source IPs. Server reserves a TCB for each. Real clients can't get connections because the server's resources are exhausted. **Defense:** SYN cookies. Server doesn't reserve a TCB until step 3 — it encodes connection state into the SYN-ACK's sequence number, then verifies it when the client's ACK comes back. No memory used until handshake completes. ``` R1(config)# tcp synwait-time 10 ! shorter SYN_RECV timeout ``` Most modern OS stacks enable SYN cookies under attack automatically. Mostly a server-side defense. ## Connection teardown — the 4-way (FIN-ACK) Closing is similar but uses **FIN** instead of SYN. Each side sends its own FIN — so four packets total in a graceful close: ``` Client → Server: FIN Server → Client: ACK Server → Client: FIN Client → Server: ACK ``` Half of the connection can stay open if one side is still sending. **RST** (reset) is the rude alternative — slams the door, no acknowledgment, no graceful exit. Used when something's gone wrong. ## Capturing it — what Wireshark shows Filter `tcp.flags.syn == 1 && tcp.flags.ack == 0` to find SYN packets only. Look for the three-packet sequence: | # | Source | Dest | Flags | Seq | Ack | |---|---|---|---|---|---| | 1 | client | server | SYN | 100 | — | | 2 | server | client | SYN, ACK | 500 | 101 | | 3 | client | server | ACK | 101 | 501 | | 4 | client | server | PSH, ACK | 101 | 501 | (the actual HTTP request) | Open Chrome's DevTools network tab and you'll see "Initial connection" timing — that's the handshake. Add "SSL" timing for the TLS layer on top. ## Latency penalty — why fresh connections feel slow Each round-trip is one full latency cycle. The handshake adds 1.5 RTT (one full RTT for client SYN → server SYN-ACK, plus a half RTT for client ACK). Then: - HTTP: payload can hitchhike on the ACK → no extra RTT - HTTPS: TLS adds 1-2 more RTT for the TLS handshake On a 100 ms link: | Step | Cumulative time | |---|---| | TCP handshake | 150 ms | | TLS handshake (TLS 1.2) | 350 ms | | First request / response | 500 ms | That's why a fresh HTTPS page on a slow link feels sluggish even when bandwidth is fine. Reusing connections (HTTP keep-alive, TLS session resumption, HTTP/2 multiplexing, QUIC) is how modern protocols dodge this. ## Commands — observing TCP state on Cisco ``` R1# show tcp brief R1# show tcp brief all ! includes LISTEN ports R1# show ip sockets R1# show tcp statistics ``` Useful for verifying which TCP services are listening on the router (SSH, NETCONF, RESTCONF) and what state existing connections are in. ## Common mistakes 1. **Thinking TCP guarantees delivery instantly.** TCP guarantees eventual delivery (or notifies of failure). Under packet loss, it retransmits — which adds latency. Real-time apps prefer UDP for this reason. 2. **Confusing SYN flood with DDoS.** SYN flood is one specific kind of DoS. Modern DDoS uses many vectors (HTTP floods, DNS amplification, etc.) — SYN flood is one of the oldest. 3. **Assuming RST means hostility.** RST happens for many legitimate reasons — packet to a closed port, application restart, firewall rule. Don't assume malice. 4. **Filtering RST/FIN at the firewall thinking it "protects" servers.** Drops break TCP teardown — clients can't tell connections are closed cleanly. Worse experience. 5. **Half-open monitoring as "throughput."** Half-open connections aren't sending data — they're stuck. Don't include them in throughput math. 6. **Sequence number wrap-around.** TCP seq is 32-bit (~4 GB). On 10 Gbps links you can wrap in seconds. TCP timestamps (RFC 7323) handle the wrap; ancient stacks broke under high-speed long-distance links. ## Lab to try tonight 1. Open Wireshark on your laptop. Start capture. 2. Visit any HTTPS site. Stop capture. 3. Filter `tcp.flags.syn == 1`. Find the SYN packet. 4. Right-click → "Follow TCP Stream." See the full conversation. 5. Look at the first 3 packets — SYN, SYN-ACK, ACK. Note the seq numbers. 6. Find the FIN packets at the end — verify the 4-packet graceful close. 7. Compare timing: time between packet 1 (SYN) and packet 2 (SYN-ACK) ≈ your RTT to the server. ## Cheat strip | Concept | Plain English | |---|---| | **SYN** | "I want to talk" + my starting seq number | | **SYN-ACK** | "OK" + my starting seq number | | **ACK** | Final confirmation | | **ESTABLISHED** | Both sides synced, data can flow | | **FIN** | "I'm done" (one direction) | | **RST** | "Close immediately" (no graceful exit) | | **ISN** | Initial Sequence Number — random for security | | **SYN flood** | DoS attack via half-open connections | | **SYN cookies** | Defense — don't reserve resources until step 3 | | **1.5 RTT** | Handshake latency. Plus 1-2 RTT for TLS. | --- ## Verify IP Parameters on the Client OS (Windows / macOS / Linux) — https://packetmentor.com/topics/client-os-ip-verification/ > The commands to check a laptop's IP, gateway, DNS, ARP table, and route table on Windows, macOS, and Linux — the ones you'll run before you ever SSH into a switch. ## Mental model Before you SSH into a switch or router, verify the client. Nine times out of ten the problem is on the laptop: DHCP failed, DNS is unset, or the default gateway isn't reachable. Every OS has the same information — you just type slightly different commands to get at it. ## The three-column cheat sheet | Question | Windows | macOS | Linux | |---|---|---|---| | **My IP + mask + gateway + DNS** | `ipconfig /all` | `ifconfig` + `scutil --dns` | `ip addr` + `resolvectl status` | | **Just the essentials** | `ipconfig` | `ifconfig en0 \| grep inet` | `ip -br addr` | | **Default gateway / route table** | `route print` | `netstat -rn` | `ip route` | | **ARP table** | `arp -a` | `arp -an` | `ip neigh` | | **Reachability by IP** | `ping 8.8.8.8` | `ping 8.8.8.8` | `ping 8.8.8.8` | | **Path trace** | `tracert 8.8.8.8` | `traceroute 8.8.8.8` | `traceroute 8.8.8.8` (or `mtr`) | | **Name → IP resolution** | `nslookup google.com` | `dig google.com` | `dig google.com` | | **Renew DHCP lease** | `ipconfig /renew` | *(off/on network toggle)* | `sudo dhclient -r && sudo dhclient` | | **Flush DNS cache** | `ipconfig /flushdns` | `sudo dscacheutil -flushcache` | `sudo resolvectl flush-caches` | ## Reading `ipconfig /all` (Windows) ``` Ethernet adapter Ethernet: Connection-specific DNS Suffix . : corp.example.com Description . . . . . . . . . . . : Intel(R) Ethernet Connection I219-V Physical Address. . . . . . . . . : 3C-52-82-1A-4B-77 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.1.42(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Sunday, August 9, 2026 8:12:31 AM Lease Expires . . . . . . . . . . : Monday, August 10, 2026 8:12:30 AM Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 192.168.1.1 8.8.8.8 ``` Six values to check: **IP**, **mask**, **gateway**, **DNS**, **DHCP server**, **lease** timestamps. ## Reading `ip addr` (Linux) ``` $ ip addr 2: enp3s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 3c:52:82:1a:4b:77 brd ff:ff:ff:ff:ff:ff inet 192.168.1.42/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0 valid_lft 79832sec preferred_lft 79832sec inet6 fe80::3e52:82ff:fe1a:4b77/64 scope link noprefixroute valid_lft forever preferred_lft forever ``` - Interface state: `UP,LOWER_UP` — cable connected + link protocol up. - `inet 192.168.1.42/24` — v4 address and prefix length. - `inet6 fe80::.../64 scope link` — the automatic link-local IPv6 (see [ipv6-address-types](/topics/ipv6-address-types/)). For route + gateway: ``` $ ip route default via 192.168.1.1 dev enp3s0 proto dhcp metric 100 192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.42 metric 100 ``` The `default via 192.168.1.1` line is your gateway. ## Reading `ifconfig` (macOS) macOS still ships `ifconfig`. Filter for the IP: ``` $ ifconfig en0 | grep inet inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::3e52:82ff:fe1a:4b77%en0 prefixlen 64 secured scopeid 0x4 ``` `netmask 0xffffff00` = `255.255.255.0` = /24. Gateway lives in `netstat -rn`: ``` $ netstat -rn | grep default default 192.168.1.1 UGSc en0 ``` DNS servers on macOS aren't in `ifconfig` — use `scutil`: ``` $ scutil --dns | grep 'nameserver\[' | head -3 nameserver[0] : 192.168.1.1 nameserver[1] : 8.8.8.8 ``` ## Systematic triage — the "bottom-up" ladder When a user says *"the internet is broken"*, run the ladder — first failure = broken layer. ``` 1. ipconfig /all ← Do I have an IP? Gateway? DNS? 2. ping 127.0.0.1 ← Is my TCP/IP stack alive? (L3-4 loopback) 3. ping ← Is my NIC responding? (L2 self) 4. ping ← Is my subnet reachable? (L2/L3 local) 5. ping 8.8.8.8 ← Does routing work? (L3 remote) 6. ping google.com ← Does DNS work? (L7 name-service) 7. tracert google.com ← Where's the hop that fails? (path) ``` Every step maps to an OSI layer. If ping to gateway works but ping to `8.8.8.8` doesn't, routing is broken between your subnet and the outside. If DNS fails but ping-by-IP works, look at `nslookup` / `dig`. ## The #1 mistake **Assuming APIPA `169.254.x.x` means "internet is broken"**. That address means **DHCP silently failed** — your NIC assigned itself a link-local as a fallback. The wireless is up, the cable is plugged in, but no DHCP server answered. Fix DHCP (on the router / server) — not the NIC. ## Related deep-dives - [DHCP](/topics/dhcp/) — how the address you see in `ipconfig` gets assigned - [DNS](/topics/dns/) — how `nslookup`/`dig` turn a name into an IP - [ARP](/topics/arp/) — how your OS learns the MAC that goes with the gateway IP - [OSI + TCP/IP](/topics/osi-tcp-ip/) — the mental model behind the ping ladder --- ## VLANs — https://packetmentor.com/topics/vlans/ > Definitive CCNA-level VLAN guide — broadcast domains, access vs trunk ports, 802.1Q tagging, native VLAN, voice VLANs, VTP, VLAN design, the 6-step trunk debug, security pitfalls, and 7 worked exam scenarios. ## Mental model A VLAN is a way to pretend one physical switch is several separate switches. That's the whole concept. Everything else — trunks, tagging, native VLANs, VTP, voice VLANs — is plumbing to make that pretense work consistently across more than one physical switch. When you put a port in **VLAN 10**, that port is electrically connected to the same VLAN-10 broadcast domain as every other VLAN-10 port across every switch in your network. A port in **VLAN 20** is a completely different broadcast domain — as if you'd unplugged the cable between them. Three facts that follow from this and that the CCNA exam tests endlessly: 1. **Each VLAN = one broadcast domain.** Broadcasts from VLAN 10 never reach VLAN 20. 2. **Each VLAN = one IP subnet.** You can't put 192.168.10.0/24 hosts on both VLAN 10 and VLAN 20 and expect them to talk. 3. **VLANs only carry traffic between themselves through a router or L3 switch.** No exceptions in a pure Layer-2 network. ## Why VLANs exist Before VLANs, every broadcast domain needed its own physical switch. To separate "users" from "servers" from "phones," you bought three switches and three sets of cables. Expensive, inflexible, hard to change. VLANs let you take **one** switch (or, with trunking, a campus full of switches) and logically split it into as many broadcast domains as you want. Common uses: - **User vs server segmentation** — broadcast storms on the user VLAN don't melt the server VLAN. - **Security boundaries** — guest Wi-Fi traffic isolated from corporate Wi-Fi. - **Voice prioritization** — IP phones live on a dedicated VLAN with QoS marking applied uniformly. - **Department / tenant segregation** — HR can't see Finance broadcasts. - **Multi-tenant data centers** — each customer in their own VLAN(s). - **IoT containment** — security cameras and badge readers locked in a separate VLAN with strict ACLs. ## Topology In a typical CCNA topology: - **PC1** and **PC3** are both in **VLAN 10** but on different physical switches (SW1 and SW2). They can ping each other — frames cross the trunk between SW1 and SW2 with an 802.1Q tag identifying VLAN 10. - **PC1** (VLAN 10) and **PC2** (VLAN 20) are connected to the *same* physical switch but in different VLANs. They cannot ping each other — to the network they're on different switches. The trunk between SW1 and SW2 carries both VLAN 10 and VLAN 20 simultaneously. Each frame on the trunk has a 4-byte 802.1Q tag identifying which VLAN it belongs to. ## Access ports vs trunk ports Every switch port operates in exactly one of two main modes: | Port mode | Belongs to | Frames on the wire | Used for | |---|---|---|---| | **Access** | One VLAN | Untagged | End devices (PCs, printers, APs, phones via voice VLAN) | | **Trunk** | Many VLANs | Tagged with 802.1Q (except native VLAN) | Switch-to-switch links, switch-to-router for sub-interfaces, switch-to-hypervisor | When a frame enters an **access port** in VLAN 10, the switch tags it internally with VLAN 10. When that frame exits another access port in VLAN 10, the switch strips the tag back off. The end device never sees the tag. When a frame enters a **trunk port**, the switch reads the existing tag to know which VLAN it belongs to. When the frame exits a trunk port, the switch leaves the tag in place — so the next switch knows the VLAN, too. Exception: traffic in the **native VLAN** travels untagged across the trunk (more on this below). ### Configure an access port ``` SW1(config)# interface GigabitEthernet0/1 SW1(config-if)# switchport mode access SW1(config-if)# switchport access vlan 10 SW1(config-if)# spanning-tree portfast SW1(config-if)# spanning-tree bpduguard enable ``` The last two lines aren't required for VLAN function but are best practice on every host-facing access port. PortFast skips STP's state machine for host ports (no risk of a host generating BPDUs); BPDU Guard err-disables the port if a BPDU *does* arrive (someone plugged in a rogue switch). ### Configure a trunk port ``` SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# switchport trunk encapsulation dot1q SW1(config-if)# switchport mode trunk SW1(config-if)# switchport nonegotiate SW1(config-if)# switchport trunk allowed vlan 10,20,30,99 SW1(config-if)# switchport trunk native vlan 999 ``` - `encapsulation dot1q` — only needed on platforms that historically supported ISL (Cisco proprietary, dead). Modern Catalysts skip this line; older 3750-era still needs it. - `mode trunk` — explicitly trunk, not auto-negotiate. - `nonegotiate` — disable DTP (Dynamic Trunking Protocol). DTP is a security risk (can be exploited to trunk-attach a rogue switch) and explicit beats implicit. - `allowed vlan` — list which VLANs cross this trunk. Default is all VLANs (1–4094), which is rarely what you want. - `native vlan 999` — frames in VLAN 999 travel untagged. Critical to set this to an unused VLAN (not VLAN 1, ever). ## 802.1Q tagging — what's actually on the wire A standard Ethernet frame: ``` | Dest MAC (6) | Src MAC (6) | Type (2) | Payload | FCS (4) | ``` The same frame with 802.1Q tagging: ``` | Dest MAC (6) | Src MAC (6) | TPID (2)=0x8100 | TCI (2) | Type (2) | Payload | FCS (4) | ``` A **4-byte tag** is inserted after the source MAC: - **TPID (2 bytes)** — Tag Protocol Identifier, always `0x8100` for 802.1Q. - **TCI (2 bytes)** — Tag Control Information, which contains: - **PCP (3 bits)** — Priority Code Point (CoS / Class of Service, 0–7, used by QoS) - **DEI (1 bit)** — Drop Eligible Indicator - **VID (12 bits)** — VLAN ID (0–4095, but 0 and 4095 reserved, so practically 1–4094) 12 bits of VLAN ID = 4,094 usable VLANs. That's why CCNA tests "VLAN ID range 1–4094." The frame's MTU effectively grows by 4 bytes. Modern switches handle this transparently. Older gear may need a higher MTU on trunk ports (called "jumbo frames" or "baby giants") — usually `system mtu 1504` or higher. ## The native VLAN — the #1 trunk gotcha On a trunk, exactly one VLAN is the **native VLAN** — its frames travel **untagged**. By default this is VLAN 1. Why does this exist? Historical compatibility with hubs and unmanaged switches that don't understand tags. If a tagged frame in VLAN 1 hit a dumb device, the dumb device would see a weird 4-byte payload and drop it. Untagged native frames just look like normal Ethernet. In modern networks the native VLAN is a vulnerability and a source of bugs: - **Security:** an attacker can perform a *double-tagging* attack — wrap a frame in two 802.1Q tags. The first tag (matching the trunk's native VLAN) is stripped by the first switch; the inner tag survives and the frame lands in the wrong VLAN. - **Bugs:** if SW1 has native VLAN 1 and SW2 has native VLAN 99, untagged frames from one side land in the wrong VLAN on the other. Best practice in 2026: set the native VLAN to an explicit unused VLAN (e.g., 999) on *both ends* of every trunk, and **tag the native VLAN** explicitly with `vlan dot1q tag native` so nothing travels untagged. ``` SW1(config)# vlan 999 SW1(config-vlan)# name UNUSED-NATIVE SW1(config)# vlan dot1q tag native SW1(config-if)# switchport trunk native vlan 999 ``` When configured this way, all traffic on the trunk is tagged, including the native VLAN. No untagged frame surprises. ## Voice VLANs IP phones plug into an access port but need to be in a different VLAN from the PC daisy-chained behind them. Cisco's solution is the **voice VLAN** — a special concept where one port is in two VLANs: - **Data VLAN** — for the PC behind the phone, untagged. - **Voice VLAN** — for the phone itself, 802.1Q tagged with CoS 5 (high priority). ``` SW1(config)# interface Gi1/0/1 SW1(config-if)# switchport mode access SW1(config-if)# switchport access vlan 10 ! data VLAN SW1(config-if)# switchport voice vlan 110 ! voice VLAN SW1(config-if)# mls qos trust cos ! preserve phone's QoS markings ``` The phone gets its VLAN assignment via CDP / LLDP-MED from the switch and tags voice traffic accordingly. PC behind the phone runs untagged on VLAN 10. This is technically not a "real" trunk port — it's an access port with one extra VLAN exception. CCNA exam calls this out specifically. ## Allowed-VLAN list on trunks By default a trunk allows **all** VLANs (1–4094). In most production networks you want to restrict this: ``` SW1(config-if)# switchport trunk allowed vlan 10,20,30,99,999 ``` Why restrict? - **Smaller broadcast scope** — VLAN 30's broadcast only reaches switches where VLAN 30 exists. - **Smaller failure domain** — STP topology changes only ripple through VLANs that actually need to be present. - **Security** — even if a VLAN exists in the database, it cannot cross trunks where it's not in the allowed list. - **Easier troubleshooting** — `show interfaces trunk` shows you exactly what's supposed to be there. **Adding to the list later:** ``` SW1(config-if)# switchport trunk allowed vlan add 40 ``` Crucial: the word `add`. Without it, you **overwrite** the list and may lose 10, 20, 30 in the process. Common production outage. ## VTP — VLAN Trunking Protocol VTP synchronizes the VLAN database across switches. Set up VLAN 50 on one switch; VTP propagates it to every other switch in the same VTP domain. | VTP mode | What it does | |---|---| | **Server** | Can add/edit/delete VLANs; advertises changes | | **Client** | Receives advertisements; can't change VLANs locally | | **Transparent** | Manages its own VLANs locally; just forwards advertisements through | VTP sounds useful but has a notorious failure mode: **a switch with a higher VTP revision number wipes the VLAN database of every other switch** when added to the domain. Catastrophic outages have resulted from plugging in a lab switch that had been used in a domain with a higher revision number. **2026 best practice:** disable VTP, or run **VTP v3 in transparent mode**. Most modern shops manage VLANs via configuration management (Ansible / NetBox) instead of VTP. See [VTP](/topics/vtp/) for the full picture. ## VLAN design — how to actually choose VLAN IDs A clean VLAN design saves operations pain forever. Some conventions that work in real enterprises: | VLAN ID range | Use | |---|---| | 1 | **Never use** — Cisco default + management. Quarantine. | | 2–9 | Reserved for special purposes (management VLAN, native VLAN — pick separate IDs from data) | | 10–99 | User VLANs (10 = USERS, 20 = SALES, 30 = ENG, etc.) | | 100–199 | Voice VLANs (110 = USER-VOICE, 120 = SALES-VOICE) | | 200–299 | Server / DC VLANs | | 300–399 | Guest, BYOD, untrusted | | 400–499 | DMZ, public-facing | | 999 | Native VLAN on trunks (unused for any host) | | 1002–1005 | **Never use** — reserved by Cisco for FDDI/Token Ring (legacy) | The pattern doesn't matter as much as **picking one and sticking to it**. A new engineer should be able to look at VLAN 120 and immediately know "it's voice for the Sales department" without checking docs. **Name every VLAN** — `name USERS`, `name SALES-VOICE`. CCNA exam loves to test that you remember to do this. ## Verification commands ``` SW1# show vlan brief SW1# show vlan id 10 SW1# show interfaces trunk SW1# show interfaces Gi1/0/1 switchport SW1# show interfaces status vlan 10 SW1# show mac address-table vlan 10 SW1# show spanning-tree vlan 10 ``` `show vlan brief` confirms each VLAN exists and which ports belong. `show interfaces trunk` confirms which trunks are formed and which VLANs they carry. `show interfaces Gi1/0/1 switchport` shows the full operational state of a single port — mode, access VLAN, voice VLAN, allowed VLANs if trunk, native VLAN, etc. This is the daily-driver troubleshooting command. ## The 6-step trunk debug workflow When a host in VLAN X can't reach another host in VLAN X across a trunk: 1. **Is the trunk actually a trunk?** `show interfaces Gi0/24 switchport | include Mode` on both ends. Both must say `Operational Mode: trunk`. If one says `dynamic auto` or `static access`, fix it. 2. **Is VLAN X in the trunk's allowed list?** `show interfaces trunk` — check the "Vlans allowed" column. 3. **Does VLAN X exist in the VLAN database on both switches?** `show vlan brief` — VLAN X must appear as `active`. 4. **Is VTP pruning it?** `show vtp status` — if pruning is enabled and there's no active access port in VLAN X downstream, VTP may skip it. Add a placeholder port or disable pruning. 5. **Native VLAN matches?** `show interfaces trunk | include Native` on both ends. Mismatch = CDP errors in the log + frames landing in wrong VLAN. 6. **Physical layer?** `show interfaces Gi0/24 status` should say `connected`. If `notconnect` or `err-disabled`, fix the cable / port-security / BPDU Guard config first. This catches 95% of cases. The blog post [trunk-not-passing-vlan](/blog/trunk-not-passing-vlan/) walks each step in detail. ## Security pitfalls ### 1. VLAN hopping via double-tagging Attacker on VLAN 1 (which is also the trunk's native VLAN) sends a frame with two 802.1Q tags. First switch strips the outer tag (since it matches the native VLAN — untagged). Inner tag says "I'm in VLAN 20." Frame is now in VLAN 20 illegally. **Mitigation:** never use VLAN 1 as a host VLAN OR as a native VLAN. Tag the native VLAN explicitly (`vlan dot1q tag native`). ### 2. DTP (Dynamic Trunking Protocol) abuse DTP is the protocol that auto-negotiates whether a port becomes a trunk. An attacker can send DTP frames and convince a switch port to become a trunk — gaining access to all VLANs. **Mitigation:** `switchport nonegotiate` on every port. Explicitly configure access or trunk; never auto. ### 3. Rogue switch attaches via PortFast If a user-facing port has PortFast (skip STP) and an attacker plugs in a malicious switch, that switch joins the network as a forwarding peer and can sniff VLAN traffic. **Mitigation:** **BPDU Guard** on every PortFast port. If a BPDU arrives, the port goes err-disabled. ### 4. Private VLANs vs regular VLANs For environments where you need many hosts in one subnet but isolated from each other (hotel Wi-Fi, multi-tenant), use **Private VLANs** instead of regular VLANs. See [Private VLANs](/topics/private-vlans/). ## Worked exam scenarios --- **Scenario 1.** SW1 has VLAN 10 with ports Gi0/1, Gi0/2 in it. SW1's trunk to SW2 has allowed-vlan `1,20,30`. PC on Gi0/1 (VLAN 10) wants to ping a PC in VLAN 10 on SW2. Will it work? **Answer:** No. VLAN 10 is not in the trunk's allowed list. Frames are silently dropped at the trunk. Fix: `switchport trunk allowed vlan add 10` on SW1's trunk. --- **Scenario 2.** Two switches have trunks between them. SW1 native VLAN = 1. SW2 native VLAN = 99. CDP is enabled. What happens? **Answer:** CDP logs a `%CDP-4-NATIVE_VLAN_MISMATCH` error on both. Untagged frames from SW1 land in VLAN 99 on SW2; untagged frames from SW2 land in VLAN 1 on SW1. Possible silent VLAN leak. Fix: align native VLAN on both ends to the same unused VLAN ID. --- **Scenario 3.** A user complains their VoIP phone works but their PC behind the phone gets no IP. The port has `switchport access vlan 10` and `switchport voice vlan 110`. The data VLAN's DHCP server is configured. What's broken? **Answer:** Most likely cause: VLAN 10 isn't on the trunk uplink to the DHCP server's network. The phone has its own VLAN 110 trunked correctly. Check `show interfaces trunk` for VLAN 10. (Also check DHCP relay / `ip helper-address` on the VLAN 10 SVI.) --- **Scenario 4.** SW1, SW2, SW3 are in a triangle. All three trunks have allowed VLAN list `10,20`. VLAN 20 has 0 active hosts. Why might `show spanning-tree vlan 20` still be running? **Answer:** STP runs for every VLAN that exists in the database and is allowed on a trunk, regardless of host count. To skip STP for VLAN 20 you'd need to either remove it from the allowed list or enable VTP pruning (or both). --- **Scenario 5.** You configure a new VLAN 50 on SW1 only. PC on SW2 in VLAN 50 (assigned to Gi0/3 with `switchport access vlan 50`) can't reach a PC on SW1 in VLAN 50. Why? **Answer:** VLAN 50 doesn't exist in SW2's VLAN database. The port command `switchport access vlan 50` puts the port in VLAN 50 logically, but without a corresponding `vlan 50` entry in the database, SW2 may show "VLAN does not exist" or silently drop traffic. Run `vlan 50` then `name USERS-50` on SW2. --- **Scenario 6.** A switch reboots and all VLAN configuration is gone. Why? **Answer:** The VLAN database lives in `vlan.dat` in flash, **separate from running-config and startup-config**. If you only saved `running-config` with `copy run start` but didn't save the VLAN database (which on most platforms saves automatically), the VLANs vanish on reboot. Modern IOS handles this transparently, but VTP-transparent and certain backup/restore patterns can lose `vlan.dat`. --- **Scenario 7.** Why can't a host in VLAN 10 ping a host in VLAN 20 on the same switch, even though both are in subnet `192.168.10.0/24`? **Answer:** Same subnet doesn't matter. Different VLAN = different broadcast domain = different L2 world. The host in VLAN 10 ARPs for the target IP; the ARP request never reaches VLAN 20. The host gets no reply. This is the most common conceptual mistake in CCNA — VLAN ≠ subnet, but each VLAN must have its own unique subnet. ## Common mistakes 1. **VLAN exists on SW1 but not on SW2.** Frames get tagged VLAN 10 on the trunk, arrive at SW2, but SW2 doesn't know what VLAN 10 is — frames get dropped silently. Always create the same VLAN database on both ends. 2. **Forgetting to allow the VLAN on the trunk.** Default is all VLANs allowed, but if someone previously restricted, the new VLAN won't pass. Use `switchport trunk allowed vlan add ...`, not `switchport trunk allowed vlan ...` (which overwrites). 3. **Native VLAN mismatch.** SW1 says native is VLAN 1, SW2 says native is VLAN 99 — Spanning Tree complains via CDP, and untagged frames potentially leak between VLANs. Set both sides to the same unused VLAN. 4. **Putting real devices in VLAN 1.** VLAN 1 is the default management VLAN. Putting users or servers in VLAN 1 is a security anti-pattern. Use unused VLAN IDs starting at 10, 20, etc. 5. **VLAN ≠ subnet, but they should align.** Each VLAN is its own broadcast domain → each VLAN gets its own IP subnet. Two devices in different VLANs cannot talk without a router (or L3 switch SVI), even if you assigned them the same IP subnet. 6. **PortFast on a switch-to-switch link.** If anything other than a host plugs in, you've created a 1-second loop window. Pair with BPDU Guard always. 7. **VTP misuse.** Lab switch with high revision number wipes production VLANs. Disable VTP or run v3 transparent in 2026. 8. **DTP left enabled on access ports.** Default mode on many platforms is `dynamic auto` which can be exploited into trunking. Always `switchport mode access` + `switchport nonegotiate`. 9. **Overwriting the allowed list with `vlan` instead of `vlan add`.** Outage in one command. 10. **Not tagging the native VLAN.** Modern security best practice is `vlan dot1q tag native` so no frame travels untagged on a trunk. ## Lab to try tonight 1. **Two-switch basic VLAN** — Drop two switches and four PCs in Packet Tracer. Create VLAN 10 and VLAN 20 on both switches. Assign PC1 + PC3 to VLAN 10; PC2 + PC4 to VLAN 20. Trunk between switches with native VLAN 999. Verify PC1↔PC3 (same VLAN cross-switch) works and PC1↔PC2 (different VLAN, same switch) does not. 2. **Add inter-VLAN routing** — Add a router on a stick (or L3 switch SVI). Configure VLAN 10 gateway + VLAN 20 gateway. Verify PC1↔PC2 now works through the router. 3. **Break the trunk on purpose** — Change native VLAN on one side. Watch `show interfaces trunk` and check log messages for CDP mismatch. Restore. 4. **Allowed-list trap** — Start with allowed list `10,20`. Try `switchport trunk allowed vlan 30`. Observe — 10 and 20 are now gone. Restore with `switchport trunk allowed vlan add` syntax. 5. **Voice VLAN** — Add a Cisco IP phone in Packet Tracer between the PC and switch. Configure access VLAN 10 + voice VLAN 110. Verify the phone gets a VLAN-110 IP from a separate DHCP pool and the PC behind it gets VLAN-10 IP. 6. **Security drills** — Plug a second switch into a PortFast access port. Watch BPDU Guard err-disable the port instantly. Re-enable with `shutdown` / `no shutdown` after fixing. 7. **Bonus: VLAN database survival** — Reboot a switch with `write erase` first; confirm `vlan.dat` survives (it lives in flash, not NVRAM, on modern switches). ## Cheat strip | Concept | Plain English | |---|---| | **VLAN** | One physical switch pretending to be N switches | | **Access port** | Belongs to one VLAN, untagged on the wire | | **Trunk port** | Carries many VLANs, frames tagged with 802.1Q (except native) | | **802.1Q tag** | 4-byte header inserted after src MAC. VID is 12 bits = 4094 usable VLAN IDs | | **Native VLAN** | The one VLAN whose frames travel untagged on a trunk. Default is VLAN 1 — never leave this default | | **`vlan dot1q tag native`** | Tag native VLAN too. Best practice in 2026 | | **Voice VLAN** | Access port + extra tagged voice VLAN. Phone tags voice; PC behind phone is untagged data | | **VLAN 1** | Default + management. Never put hosts in it | | **VLANs 1002-1005** | Reserved by Cisco for FDDI/Token Ring (legacy). Don't use | | **VLAN database** | Lives in `flash:vlan.dat`, separate from startup-config | | **Inter-VLAN routing** | Needs a router or L3 switch SVI — pure L2 cannot cross VLANs | | **Allowed list** | `switchport trunk allowed vlan ...` controls which VLANs cross a given trunk. Use `add` to extend | | **VTP** | VLAN synchronization protocol. Risky — prefer transparent mode or disable | | **DTP** | Dynamic Trunking Protocol — auto-negotiates trunks. Disable with `switchport nonegotiate` | | **Trunk gotchas** | Allowed list, native VLAN, DB exists on both ends, VTP pruning, physical layer | | **VLAN hopping** | Double-tagging attack. Mitigate by tagging native + not using VLAN 1 | | **PortFast + BPDU Guard** | Mandatory pair on host access ports | ## Frequently asked questions **Q: What's the difference between a VLAN and a subnet?** A: A VLAN is a Layer-2 broadcast domain (switching concept — MAC addresses stay inside it). A subnet is a Layer-3 IP address range (routing concept). Best-practice mapping is one VLAN = one subnet, so people conflate them, but they're independent concepts. Two VLANs with the same subnet is a misconfiguration that leaks broadcasts; one VLAN with two subnets works (called *secondary IP* on the SVI) but is confusing. **Q: Do I need a router for inter-VLAN routing?** A: Not if you have a Layer-3 switch — a Cat9300, Cat3850, or any switch that supports SVIs can route between VLANs internally at line rate. This replaced the old "router on a stick" design (one router with a single trunk uplink) in every modern network. A dedicated router is only needed if you have a Layer-2-only switch or if you're doing something the switch can't (NAT, complex ACLs, VPN termination). **Q: What's VLAN 1 and why should I avoid using it?** A: VLAN 1 is the default VLAN — every access port is in VLAN 1 out of the box, and control-plane traffic (CDP, DTP, VTP) rides on it across trunks. Attackers who reach a rogue trunk port can pivot into VLAN 1. Move user traffic off VLAN 1 (change the access VLAN) and prune VLAN 1 from trunks where possible. Don't disable it — you can't — just don't put anything valuable in it. **Q: What's the difference between access and trunk ports?** A: Access ports carry ONE VLAN (untagged) — used for end devices like PCs, printers, phones. Trunk ports carry MANY VLANs (each tagged with its VLAN ID via 802.1Q) — used between switches or between a switch and a router. A common mistake: leaving a port in `dynamic auto` and letting it negotiate to trunk when you intended access, which enables VLAN-hopping attacks. Always explicitly set `switchport mode access` on access ports. --- ## Trunks & 802.1Q Tagging — https://packetmentor.com/topics/trunks-and-802-1q/ > How switches carry multiple VLANs over a single link using 802.1Q tags. Includes DTP behavior, native VLAN gotchas, and the allowed-VLAN list. ## Mental model An access port is a single-purpose wire — it belongs to exactly one VLAN and frames go through naked (untagged). A trunk is a shared wire — it carries many VLANs by stamping each frame with an "I belong to VLAN N" sticker called the **802.1Q tag**. That stamp is 4 bytes inserted into the Ethernet header. Without it, the receiving switch would have no way to know which VLAN a given frame belongs to. ## The 802.1Q tag, byte by byte ``` +-------------+-------------+-------------+-------------+ | TPID (2) | PCP | DEI | VID (12 bits) | | 0x8100 | 3b | 1b | 1–4094 | +-------------+-------------+-------------+-------------+ ``` - **TPID** — fixed value `0x8100`, tells the receiver "this is a tagged frame" - **PCP** — Priority Code Point, used by QoS (CoS values 0–7) - **DEI** — Drop Eligible Indicator (rarely used) - **VID** — the VLAN ID itself, 12 bits = values 1 through 4094 (0 and 4095 reserved) You don't memorize this byte-by-byte for the exam, but you should remember that **the tag is 4 bytes** — that's why an Ethernet frame on a trunk can be up to 1522 bytes instead of the usual 1518. ## Commands ### Configure a trunk port (both ends) ``` SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# switchport trunk encapsulation dot1q ! on older switches only SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk native vlan 999 SW1(config-if)# switchport trunk allowed vlan 10,20,30 ``` Mirror exactly on the other end. ### Restrict the allowed list (adding/removing VLANs) ``` ! Add VLAN 40 to an existing allowed list SW1(config-if)# switchport trunk allowed vlan add 40 ! Remove VLAN 20 SW1(config-if)# switchport trunk allowed vlan remove 20 ! Replace the entire list SW1(config-if)# switchport trunk allowed vlan 10,30,40 ! Allow everything (default) SW1(config-if)# switchport trunk allowed vlan all ``` **Gotcha:** plain `switchport trunk allowed vlan 40` REPLACES the list — it does not add. Always use `add` / `remove` when modifying an existing trunk. ## Verification ``` SW1# show interfaces trunk SW1# show interfaces GigabitEthernet0/24 switchport SW1# show vlan brief ``` `show interfaces trunk` is the most useful single command: it confirms which interfaces are trunks, which VLANs they carry, and what the native VLAN is. ## Common mistakes 1. **Native VLAN mismatch.** The biggest CCNA exam trap. If SW1's native is VLAN 1 and SW2's native is VLAN 99, CDP/LLDP raises a `%CDP-4-NATIVE_VLAN_MISMATCH` and STP behavior gets weird. Set both sides to the same unused VLAN ID. 2. **`switchport trunk allowed vlan 40` instead of `... add 40`.** This silently replaces the whole allowed list. Suddenly VLANs 10, 20, 30 stop crossing the trunk. 3. **Forgetting to set `switchport mode trunk` and relying on DTP.** Dynamic Trunking Protocol can auto-negotiate trunks, but it's a security risk (VLAN-hopping attacks). Always hard-code mode trunk + `switchport nonegotiate`. 4. **Mismatched encapsulation.** On older switches that support both ISL and 802.1Q, you must explicitly set encapsulation to dot1q. ISL is legacy, never use it in 2026. 5. **Putting management traffic on the native VLAN.** A misconfigured trunk could leak management frames into a user VLAN. Keep the management VLAN separate from the native VLAN. ## Lab to try tonight 1. Two switches, three VLANs (10/20/30), three PCs per switch (one per VLAN). 2. Configure the inter-switch link as a trunk on both ends. Set native VLAN to 999. Allow VLANs 10, 20, 30 only. 3. Confirm PC1-VLAN10 can ping PC4-VLAN10 (same VLAN, across the trunk). 4. Verify with `show interfaces trunk` that the allowed list is exactly 10,20,30. 5. Run `switchport trunk allowed vlan 40` on one side. Check what happens to existing inter-VLAN traffic. (Spoiler: it dies.) 6. Recover with `switchport trunk allowed vlan add 10,20,30` to add the lost VLANs back. ## Cheat strip | Concept | Plain English | |---|---| | **Trunk** | A port that carries multiple VLANs by tagging frames with 802.1Q | | **802.1Q tag** | 4 bytes inserted into the Ethernet header; contains the VLAN ID (1–4094) | | **Native VLAN** | The one VLAN whose frames travel **untagged** on a trunk. Set explicitly. | | **Allowed list** | Which VLANs may cross this trunk. `add`/`remove` to modify safely. | | **DTP** | Cisco's trunk-negotiation protocol. Turn it off in production. | | **Frame size** | Tagged frame = 1522 bytes max (1518 + 4 tag). Some old gear chokes on >1518. | --- ## Cabling & Media Standards — https://packetmentor.com/topics/cabling-and-media/ > What's actually inside the cables and fiber you're plugging in — Cat5e/6/6A/8, single-mode vs multi-mode fiber, transceivers (SFP/SFP+/QSFP), distance and bandwidth limits, when to use what. ## Mental model The physical layer determines how fast and how far. Get this wrong and the rest of the stack works perfectly while users complain about slow networks. Two big categories of media: - **Copper twisted pair** — cheap, terminates with RJ45, runs up to 100 meters. The default for desk drops, APs, IP phones, cameras. - **Fiber optic** — more expensive, multiple connector types, runs from 100m to many kilometers. The default for switch-to-switch uplinks, datacenter spine-leaf, building-to-building, ISP last mile. Within each category, multiple grades exist for different bandwidth and distance targets. ## Copper twisted pair — Cat ratings All Ethernet over copper uses 8 wires in 4 twisted pairs. The category number determines bandwidth and distance. | Cat | Max bandwidth | Max distance | Used for | Year | |---|---|---|---|---| | **Cat5** | 100 Mbps | 100 m | Legacy 10/100 Ethernet | 1995 | | **Cat5e** | 1 Gbps | 100 m | Most modern access ports | 2001 | | **Cat6** | 1 Gbps full / 10 Gbps to 55 m | 100 m / 55 m | Better margins, multi-gig PoE | 2002 | | **Cat6A** | 10 Gbps | 100 m | Modern Wi-Fi 6/6E AP uplinks, datacenter copper | 2008 | | **Cat7 / Cat7A** | 10 / 40 Gbps | 100 / 50 m | Niche; not widely deployed in N. America | 2010 | | **Cat8** | 25-40 Gbps | 30 m | Datacenter top-of-rack short-haul copper | 2016 | Common confusions: - **Cat6 caps at 1 Gbps over 100m**, but supports 10 Gbps if the run is ≤55m. Many people quote "Cat6 = 10 Gbps" without the distance caveat. - **Cat6A is the practical 10 Gbps copper standard for full 100m runs.** If you're building today and want headroom, use Cat6A everywhere. - **Cat7 is rarely seen in US enterprise.** Most installers skip from Cat6A to fiber for longer or faster runs. - **Cat8 is short-haul only.** Designed for ToR copper jumpers in datacenters; useless for general office cabling. ### Shielding - **UTP** (Unshielded Twisted Pair) — the standard. Cheaper, easier to terminate. - **STP / FTP / S/FTP** — Shielded variants. Reduce alien crosstalk, more expensive, harder to ground properly, required for some industrial environments. For 99% of enterprise installs, UTP is fine. STP only matters in high-EMI environments (factories, hospitals near MRI). ### Termination RJ45 connectors on both ends. Two wiring standards exist: - **T568A** — green pair on pins 1/2 - **T568B** — orange pair on pins 1/2 (more common in N. America) Both work. The rule: **be consistent across both ends of a cable**. Mixing A and B on the same cable creates a crossover (used to be needed for switch-to-switch; auto-MDIX handles it now). ## Fiber optic — types and modes Fiber transmits light, not electricity. Two fundamental types: | Type | Core diameter | Color | Used for | Distance | |---|---|---|---|---| | **Multi-mode (MMF)** | 50 µm or 62.5 µm | Orange / Aqua / Lime | Short-range, intra-building | up to ~550 m | | **Single-mode (SMF)** | 9 µm | Yellow | Long-range, inter-building, ISP | 10 km – 80+ km | Why the difference? Single-mode's tiny core forces light into a single path → less dispersion → much longer distance. Multi-mode's wider core allows multiple paths → cheaper transceivers but signal disperses faster. ### Multi-mode grades (OM) Multi-mode fiber comes in OM grades. Higher number = better bandwidth × distance product. | Grade | Color | 10 Gbps reach | 40/100 Gbps reach | |---|---|---|---| | **OM1** | Orange | 33 m | not supported | | **OM2** | Orange | 82 m | not supported | | **OM3** | Aqua | 300 m | 100 m | | **OM4** | Aqua / Magenta | 400 m | 150 m | | **OM5** | Lime green | 400 m | 150 m (also supports SWDM) | OM3 and OM4 are the modern defaults for datacenter MMF. OM1/OM2 are legacy and should be replaced. ### Single-mode (OS1 / OS2) OS1 and OS2 are similar; OS2 is slightly better for outdoor/long-haul. Single-mode supports speeds from 1G to 800G+ over distances from a few hundred meters (with cheap transceivers) to 80+ km (with long-haul DWDM). ### Connectors Multiple fiber connector types exist. Common ones: | Connector | Where | |---|---| | **LC** | Most common in datacenters and modern switches. Small form factor, two fibers per duplex pair. | | **SC** | Older, larger; still common in carrier deployments. | | **MPO / MTP** | 12 or 24 fibers in one connector. Used for high-density spine-leaf and breakout cables. | | **ST** | Legacy bayonet, mostly retired. | **Polish type matters** for connector loss — UPC (blue, lower loss) vs APC (green, even lower loss, used in PON / carrier networks). Don't mix them at a single connection. ## Transceivers — what plugs into the switch port A switch port doesn't natively know what cable it's talking to. You insert a **transceiver** (a small pluggable module) into the switch's SFP/QSFP cage, which converts between the switch's electrical interface and the optical or copper media on the cable. | Form factor | Speed | Cable | Use | |---|---|---|---| | **SFP** | 1 Gbps | MMF / SMF / copper (RJ45) | Access switch uplinks | | **SFP+** | 10 Gbps | MMF / SMF / DAC | 10 Gbps server / switch ports | | **SFP28** | 25 Gbps | MMF / SMF / DAC | Modern server NICs | | **QSFP+** | 40 Gbps (4×10) | MMF / SMF / DAC / AOC | Spine-leaf, datacenter aggregation | | **QSFP28** | 100 Gbps (4×25) | MMF / SMF / DAC / AOC | Modern spine, datacenter backbone | | **QSFP-DD** | 400/800 Gbps | MMF / SMF | Hyperscale datacenters | **Cable choices for transceiver speeds:** - **DAC (Direct Attach Copper)** — short (≤7 m) passive copper cable with transceivers built into both ends. Cheap. Use for top-of-rack server connections. - **AOC (Active Optical Cable)** — same idea but with fiber. Longer (up to ~30 m) than DAC. Used for mid-rack to top-of-rack runs that don't justify pluggable optics. - **Pluggable optics + structured fiber** — most flexible. Use for inter-switch links and anything over ~10 m. ### Vendor lock — the dirty secret Many switch vendors "validate" only their own-branded transceivers. A generic 10G SFP+ from a third-party (FS, ProLabs) physically works and often costs 1/10 the price of a Cisco-branded one — but on stricter platforms (Catalyst 9000, Nexus), the port may refuse the optic without `service unsupported-transceiver` configured. ``` SW1(config)# service unsupported-transceiver SW1(config)# no errdisable detect cause gbic-invalid ``` This is technically supported on most Cisco gear. Use third-party optics with eyes open. ## Distance + bandwidth chart — the reference card | Goal | Use | |---|---| | 1 Gbps to a desk, ≤100m | Cat5e UTP + RJ45 | | 10 Gbps to a desk or AP, ≤100m | Cat6A UTP + RJ45 (and a 10G port) | | 1 Gbps switch-to-switch in the same building, ≤300m | OM3 + 1G SFP optics | | 10 Gbps switch-to-switch in the same building, ≤300m | OM3 + 10G SFP+ optics | | 25-100 Gbps spine-to-leaf in datacenter, ≤100m | OM4 + 25/100G optics | | 10 Gbps between two buildings, ≤10 km | Single-mode + 10GBASE-LR SFP+ | | 10-40 Gbps to an ISP, ≤40 km | Single-mode + 10GBASE-ER / 40GBASE-ER4 | | Server NIC to ToR, ≤7 m | DAC cable (passive) | | Server NIC to ToR, ≤30 m | AOC cable | ## Common mistakes 1. **Quoting "Cat6 = 10 Gbps" without distance.** It's 10 Gbps only to 55m. For full 100m runs at 10G, use Cat6A. 2. **Mismatched transceivers.** Both ends must use the same standard. A 10G-SR (multi-mode short range) on one end and 10G-LR (single-mode long range) on the other won't link. 3. **Mixing MMF and SMF.** Single-mode optics aimed into multi-mode fiber lose power; multi-mode optics into single-mode get refracted away from the core. Either way, no link. 4. **OM3 over 40G QSFP+ at 400m.** OM3 caps at 100m for 40/100G. Use OM4 or single-mode for longer. 5. **Forgetting MPO polarity.** 12-fiber MPO trunks have a polarity (A, B, or C) — wrong polarity means the TX of one device hits the TX of the other. Buy patch cords that match your trunk type. 6. **PoE+ on Cat5e.** Works for short runs but heat buildup is a real concern. Cat6 minimum for sustained PoE+, Cat6A for PoE++ (802.3bt). Full [Power over Ethernet](/topics/power-over-ethernet/) breakdown covers the standards (802.3af / at / bt), classes, and switch power-budget math. 7. **Buying expensive Cat8 for office cabling.** Cat8 is short-haul datacenter copper. For a typical desk drop, Cat6A is the modern standard. 8. **Connecting APC to UPC.** Polish mismatch = ~1 dB+ loss. Stick with one polish type per fiber path. ## Lab to try tonight This is hard to lab without real cables and switches. What you can do: 1. Look at your existing patch panels. Identify the cable Cat rating (printed on the jacket). 2. Open your switch and look at its uplink ports. SFP cage? SFP+? QSFP? Note the form factor. 3. If you have an SFP-capable switch, pull out a transceiver and read the label. It'll say something like `1000BASE-LX` (1G single-mode) or `10GBASE-SR` (10G multi-mode short range). 4. From the CLI, `show interface Gi1/1 transceiver` (Cisco) shows the optical power — useful for "is this fiber okay" diagnostics. 5. In CML or EVE-NG, fiber/copper choice is abstracted away — but you can simulate distance/loss issues by changing link delay parameters. ## Cheat strip | Concept | Plain English | |---|---| | **Cat5e** | 1 Gbps to 100m — the access-port standard | | **Cat6A** | 10 Gbps to 100m — the modern AP / 10G access standard | | **Cat8** | 25-40 Gbps to 30m — datacenter ToR copper only | | **Multi-mode (MMF)** | Short-range fiber, ~550m max, OM3/OM4 = aqua jacket | | **Single-mode (SMF)** | Long-range fiber, 10-80 km, OS2 = yellow jacket | | **OM3 / OM4** | Multi-mode grades; OM4 better at 40/100G | | **OS1 / OS2** | Single-mode grades; OS2 for outdoor / long-haul | | **LC** | Most common modern fiber connector | | **MPO / MTP** | 12 or 24 fibers in one connector — high-density spine-leaf | | **SFP / SFP+ / SFP28** | 1 / 10 / 25 Gbps pluggable transceivers | | **QSFP+ / QSFP28** | 40 / 100 Gbps pluggable transceivers | | **DAC** | Direct-attach copper, ≤7m, cheapest 10/25G option | | **AOC** | Active optical cable, ≤30m, pre-terminated fiber | | **`service unsupported-transceiver`** | Allows 3rd-party optics on strict Cisco platforms | | **Distance + speed first** | Pick the cable, then pick the transceiver. Not the other way around. | --- ## Spanning Tree Protocol (STP) — https://packetmentor.com/topics/spanning-tree/ > Definitive CCNA-level STP guide — why loops are catastrophic, bridge ID + priority election, three port roles, five port states, BPDU anatomy, PortFast + BPDU Guard + Root Guard + Loop Guard, RSTP convergence, MSTP overview, and 8 worked scenarios. ## Mental model A switched LAN with a Layer-2 loop is a disaster. A single broadcast frame circulates forever (Ethernet has no TTL field), gets duplicated at each switch, and within seconds saturates every link. CPUs spike trying to process the storm, MAC tables thrash because the source MAC appears on multiple ports, the network is dead. But you **want** redundant cabling for fault tolerance — one cable can be unplugged or damaged at any time. So how do you get redundant cabling without loops? **Spanning Tree Protocol's** answer: **logically block** the redundant paths until they're needed. STP runs an election to pick a single "root" switch, then has every other switch compute the best path back to the root. Any port that isn't on the best path gets **blocked** — physically connected, but Layer-2 silent. When a link fails, STP unblocks the previously-blocked port and a new path becomes active. Convergence takes anywhere from 1–2 seconds (RSTP) to ~50 seconds (classic 802.1D). Three versions you'll encounter: | Protocol | Year | Convergence | Default on | |---|---|---|---| | **STP (802.1D)** | 1990 | 30–50 s | Legacy gear only | | **RSTP (802.1w) / Rapid-PVST+** | 2001 | 1–2 s | Modern Cisco default | | **MSTP (802.1s)** | 2002 | 1–2 s | Multi-vendor / very-many-VLAN environments | This page focuses on 802.1D fundamentals plus the RSTP improvements. For full RSTP/MSTP coverage see [Rapid STP & MSTP](/topics/rstp-mstp/). ## Why loops are catastrophic — a worked example Imagine SW1 and SW2 connected by **two** parallel cables. PC1 sends a broadcast frame onto SW1. 1. SW1 sees the broadcast, floods it out every other port — including both cables to SW2. 2. SW2 receives the broadcast on Cable A, floods it out every other port — including Cable B back toward SW1. 3. SW1 receives its own broadcast on Cable B, treats it as new, floods it out every other port — including Cable A toward SW2. 4. Repeat infinitely. Now there are two copies circulating. Then four. Then eight. Within 30 seconds the link is saturated. MAC table thrashing makes unicast frames behave erratically too. The CPU is so busy processing storm frames that management access is impossible. The only fix is to physically disconnect a cable and let the network recover. This is why STP is on by default everywhere. It's not optional. ## How the election works — four steps ### Step 1: Pick a root Every switch starts thinking *it* is the root. They send **BPDUs** (Bridge Protocol Data Units) every 2 seconds advertising their **Bridge ID**, which is: ``` Bridge ID = (4-bit Priority + 12-bit Extended-System-ID) + 48-bit MAC address = 8 bytes total ``` **Lowest Bridge ID wins.** Since priority comes first in the comparison, that dominates. Default priority is 32768 (sometimes written 32769 = 32768 + 1 because the lower 12 bits of "priority" are actually the VLAN ID — Cisco's PVST+ encoding). If priorities tie, MAC address is the tiebreaker. **Lower MAC** = wins. This is the trap: by default, the oldest switch (often slowest, most loaded) tends to have the lowest MAC and wins by accident. ### Step 2: Pick a root port on every other switch Each non-root switch finds its best path back to the root. "Best" = lowest accumulated **path cost** (sum of port costs along the path). The interface on that path becomes the **Root Port (RP)**. Every non-root switch has exactly one RP. Tiebreaker order if costs are equal: 1. Lower sender Bridge ID 2. Lower sender Port ID ### Step 3: Pick a designated port on every segment For each LAN segment (each link), STP picks the switch with the lowest cost back to root. **That switch's port on this segment** becomes the **Designated Port (DP)**. The root bridge's ports are all designated ports — by definition, the root has cost 0 to itself. ### Step 4: Block everything else Any port that isn't a Root Port or a Designated Port becomes **Alternate / Blocked (BLK)**. Traffic doesn't forward through it. It listens for BPDUs in case the network topology changes and it needs to be unblocked. ## Port costs (memorize) | Link speed | STP cost (802.1D) | RSTP cost | |---|---|---| | 10 Mbps | 100 | 2,000,000 | | 100 Mbps | 19 | 200,000 | | 1 Gbps | 4 | 20,000 | | 10 Gbps | 2 | 2,000 | | 100 Gbps | — | 200 | The exam usually uses **classic 802.1D values** (100/19/4/2). Memorize these four. Path cost = sum of all port costs from your switch *back* to the root, counting only the port you receive on at each hop. ## Bridge ID — the binary detail Cisco PVST+ encodes Bridge ID like this: ``` | 4-bit priority (multiple of 4096) | 12-bit VLAN ID | 48-bit MAC | ``` That's why setting `spanning-tree vlan 10 priority 0` gives bridge priority 10 (priority 0 + VLAN 10 = 10). And why valid priorities are multiples of 4096: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, ... 61440. You don't set the priority *value* directly in practice — use: ``` SW1(config)# spanning-tree vlan 10 root primary ! sets priority to 24576 (common case) SW1(config)# spanning-tree vlan 10 root secondary ! sets priority to 28672 ``` These macros set priorities below the default 32768 so your designated root and backup root win the election regardless of MAC. **Nuance worth knowing:** `root primary` isn't a fixed value. If the current root has the default 32768 priority, the macro sets the local switch to 24576. But if the current root already has a lower-than-default priority (e.g., someone else ran `root primary` first), IOS sets the new local priority to 4096 *below* the current root's value — enough to win. So the value you end up with depends on the network's current state. If you want a fixed, predictable priority, set it explicitly with `spanning-tree vlan 10 priority 24576`. ## The five port states (classic STP) When STP runs the election, ports move through states: | State | Forward data? | Learn MAC? | Send BPDU? | Duration | |---|---|---|---|---| | **Disabled** | No | No | No | n/a | | **Blocking** | No | No | No | Forever (until topology changes) | | **Listening** | No | No | Yes | Forward delay (15s default) | | **Learning** | No | Yes | Yes | Forward delay (15s default) | | **Forwarding** | Yes | Yes | Yes | Until topology changes | Total transition Blocking → Forwarding = ~30 seconds (15s Listening + 15s Learning). Plus 20-second Max Age timer if the change is detected via missing BPDUs. That's the "50 second convergence" of classic STP. **RSTP collapses this to three states:** | RSTP state | Equivalent to STP | |---|---| | **Discarding** | Blocking + Listening + Disabled | | **Learning** | Learning | | **Forwarding** | Forwarding | And RSTP doesn't wait for timers — it uses a sync/proposal handshake to advance to Forwarding immediately when safe. Sub-second convergence in practice. ## Cisco STP variants — the alphabet soup | Variant | What it is | |---|---| | **STP (802.1D)** | The original, one STP instance per network | | **PVST+** (Cisco default historically) | One STP instance **per VLAN**. Wraps 802.1D inside Cisco tagging. | | **RSTP (802.1w)** | Faster 802.1D, sub-second convergence | | **Rapid-PVST+** (Cisco modern default) | RSTP per VLAN. The 2026 standard for Cisco-only networks. | | **MSTP (802.1s)** | Groups VLANs into instances to scale. Multi-vendor standard. | For the CCNA exam: know that Rapid-PVST+ is the default modern Cisco mode. Activate explicitly: ``` SW1(config)# spanning-tree mode rapid-pvst ``` ## BPDU anatomy A BPDU (Bridge Protocol Data Unit) is the message switches send each other to run STP. Two types: | BPDU type | Purpose | |---|---| | **Configuration BPDU** | Sent every 2s by the root, propagated by designated ports. Contains root info + path cost + sender ID. | | **Topology Change Notification (TCN) BPDU** | Sent when a switch detects a topology change. Propagated back to root. Root then floods configuration BPDUs with the TC flag set. | BPDUs travel to the multicast MAC `01:80:C2:00:00:00` — every switch listens to that address by default. You can't filter BPDUs at the data plane unless you specifically configure BPDU Filter (rarely correct). ## PortFast + BPDU Guard + Root Guard + Loop Guard Four STP-related features every modern access network uses. Each protects against a different failure. ### PortFast Skip Listening + Learning on access ports. Port goes straight to Forwarding when link comes up. User PCs and IP phones don't wait 30 seconds for an IP. ``` SW1(config-if)# spanning-tree portfast ``` Global default for access ports: ``` SW1(config)# spanning-tree portfast default ``` PortFast on a **switch-to-switch link is dangerous** — if a real switch plugs in, you bypass STP's loop-prevention startup. Always pair with BPDU Guard. ### BPDU Guard If a PortFast port ever receives a BPDU, **err-disable the port immediately**. The assumption: only hosts plug into PortFast ports; if a BPDU arrives, someone plugged in a switch where they shouldn't have. ``` SW1(config-if)# spanning-tree bpduguard enable ``` Global default for PortFast ports: ``` SW1(config)# spanning-tree portfast bpduguard default ``` To recover from err-disable: `shutdown` then `no shutdown` on the port (after removing the rogue device). Or configure auto-recovery: ``` SW1(config)# errdisable recovery cause bpduguard SW1(config)# errdisable recovery interval 300 ``` ### Root Guard Prevent an unexpected switch from claiming the root role. If a port receives a "superior BPDU" (better Bridge ID than the current root), the port goes into **root-inconsistent** state — blocked until the superior BPDU stops. ``` SW1(config-if)# spanning-tree guard root ``` Place on **distribution-layer downlinks to access switches** — these should never see a BPDU claiming root. ### Loop Guard If a designated port stops receiving BPDUs (e.g., a unidirectional link failure where TX works but RX doesn't), STP normally promotes the formerly-blocked alternate to Forwarding — which can cause a loop if the original link is still half-up. **Loop Guard** detects this: if a non-designated port stops receiving BPDUs, it transitions to **loop-inconsistent** (blocked) instead of forwarding. ``` SW1(config-if)# spanning-tree guard loop ``` Or globally: ``` SW1(config)# spanning-tree loopguard default ``` ### UDLD — the layer-1 friend **UDLD** (Unidirectional Link Detection) is layer-1 protection that pairs with Loop Guard. It detects a unidirectional fiber link (one direction broken, the other still working) and shuts the port. ``` SW1(config-if)# udld enable ``` Loop Guard + UDLD together cover both layer-2 (BPDU starvation) and layer-1 (one-way fiber) failures. ## Configuration — the production access-port template A modern access port that protects against every STP mishap: ``` SW1(config)# interface Gi1/0/1 SW1(config-if)# switchport mode access SW1(config-if)# switchport access vlan 10 SW1(config-if)# switchport voice vlan 110 SW1(config-if)# switchport port-security SW1(config-if)# switchport port-security maximum 3 SW1(config-if)# switchport port-security violation restrict SW1(config-if)# switchport port-security mac-address sticky SW1(config-if)# spanning-tree portfast SW1(config-if)# spanning-tree bpduguard enable SW1(config-if)# no cdp enable SW1(config-if)# no lldp transmit ``` Memorize: **PortFast + BPDU Guard** on every host port. **Port Security** to limit MACs. **No CDP/LLDP** outward — these advertise your network's identity to whoever plugs in. ## Configuration — the production root election template ``` ! Make distribution switch DIST-1 the root for all VLANs DIST-1(config)# spanning-tree vlan 1-4094 root primary ! Make DIST-2 the secondary DIST-2(config)# spanning-tree vlan 1-4094 root secondary ! Use Rapid-PVST+ everywhere ALL_SWITCHES(config)# spanning-tree mode rapid-pvst ! On distribution downlinks (access-facing), apply Root Guard DIST-1(config-if)# spanning-tree guard root ``` This pattern (deliberate root + secondary, Rapid-PVST+, Root Guard on access-facing dist ports) is the foundation of every well-designed campus. ## Verification ``` SW1# show spanning-tree SW1# show spanning-tree vlan 10 SW1# show spanning-tree summary SW1# show spanning-tree root SW1# show spanning-tree blockedports SW1# show spanning-tree interface Gi1/0/1 detail ``` `show spanning-tree` is the daily driver. Per VLAN, it tells you: - Who the root is (Bridge ID, MAC) - Your local switch's Bridge ID - Every port's role (Root / Designated / Alternate / Backup), state (Forwarding / Discarding), cost, type (P2P / Shared / Edge) `show spanning-tree blockedports` quickly lists ports in blocked state — useful for confirming the topology matches your design. `show spanning-tree summary` shows STP mode + globally-enabled features (PortFast default, BPDU Guard default, etc.). ## The 6-step STP debug When a network is unstable and you suspect STP: 1. **Identify the root.** `show spanning-tree root`. Is it the switch you expect? If not, something's claiming root unexpectedly. 2. **Check for unexpected topology changes.** `show spanning-tree summary | include changes`. High count = flapping link generating constant TCs. 3. **Are any ports in inconsistent state?** `show spanning-tree | include inconsistent`. Root-inconsistent (Root Guard tripped), loop-inconsistent (Loop Guard tripped), or err-disabled (BPDU Guard tripped). 4. **Are timers consistent across the network?** All switches in the same STP domain should use the same Hello (2s) and Max Age (20s). Mismatch causes flap. 5. **Check for unidirectional links.** `show udld` shows any link in undetermined state. UDLD + Loop Guard catches these. 6. **Look at logging.** `show log | i SPANTREE` shows BPDU Guard trips, port-state transitions, root changes. Pattern-match. ## Worked scenarios --- **Scenario 1.** Three switches in a triangle, all with default priority (32768). MACs: SW1 = aaa, SW2 = bbb, SW3 = ccc (in order). Who becomes root? **Answer:** SW1 (lowest MAC since priorities tie). The bridge ID comparison is `32769.aaa` vs `32769.bbb` vs `32769.ccc` — lowest wins. --- **Scenario 2.** You want SW2 to be root for VLAN 10 and root for nothing else. How? **Answer:** ``` SW2(config)# spanning-tree vlan 10 root primary SW2(config)# spanning-tree vlan 1,20-4094 priority 32768 ! revert to default for others ``` Or explicitly: ``` SW2(config)# spanning-tree vlan 10 priority 8192 ! 8192 < 32768 (default), wins for VLAN 10 only ``` --- **Scenario 3.** A new switch added to the network has lower MAC than your current root. What happens? **Answer:** It claims root. The whole topology re-converges, blocked ports change, traffic patterns shift. Possibly to a slower path. This is why you **always** hard-code your designated root with `root primary`. --- **Scenario 4.** A user accidentally plugs a small unmanaged switch into a PortFast access port (chained their laptop and an old hub). What happens? **Answer:** The unmanaged switch doesn't speak STP, so it just floods broadcasts. If the user happens to have a loop (plugged the same hub into two access ports), you get a broadcast storm. PortFast bypasses STP startup, so the loop forms instantly. Fix: BPDU Guard is the wrong protection here (unmanaged switch doesn't send BPDUs). Use **Storm Control** instead: ``` SW1(config-if)# storm-control broadcast level 1.0 SW1(config-if)# storm-control action shutdown ``` --- **Scenario 5.** Switch port stuck in `err-disabled` after a BPDU arrived. What do you do? **Answer:** 1. Investigate: `show log | include LINK-3-UPDOWN` to find when. `show interface Gi1/0/1 status` shows the `err-disabled` reason. 2. Remove the rogue device. 3. Recover: `shutdown` + `no shutdown` on the port. Or wait for auto-recovery if configured. --- **Scenario 6.** Convergence is taking 30+ seconds after a link fails. What's wrong? **Answer:** You're running classic 802.1D (or Cisco PVST+). Move to Rapid-PVST+: ``` SW1(config)# spanning-tree mode rapid-pvst ``` This must be set on **every** switch in the STP domain. Mixed modes work but at the slow convergence pace of the slowest. --- **Scenario 7.** A blocked port is suddenly forwarding. What changed? **Answer:** STP topology change. Either: - The path it was the alternate for failed (e.g., the root port's cable was unplugged or the upstream switch died). - A topology change BPDU told the local switch the previous DR/root is gone. Check `show spanning-tree summary | include changes` for the TC count. If high and growing, there's a flapping link somewhere. Hunt it with `show interfaces | include input errors` or `show log`. --- **Scenario 8.** You want PortFast on a server port without disabling BPDU Guard's protection. Possible? **Answer:** PortFast + BPDU Guard is exactly the right combo. PortFast skips state-machine delay; BPDU Guard catches any BPDU arrival. Configure both. The server doesn't speak STP so BPDUs never arrive legitimately, and the protection stays armed. ## Common mistakes 1. **Letting the oldest switch win the root election.** Default priority + lowest MAC = oldest gear becomes root by accident. Always `root primary` on your designated root. 2. **Forgetting PortFast on access ports.** Without PortFast, a workstation takes ~30s to forward after link-up. Users see "no network" on boot. Enable PortFast. 3. **PortFast without BPDU Guard.** Rogue switch in a PortFast port → instant loop. Always pair PortFast + BPDU Guard. 4. **Different STP modes mixed across switches.** PVST+ on one, MST on another, RSTP on a third. Works technically; convergence inconsistent. Standardize. 5. **Disabling STP entirely.** Almost always wrong. Even "loop-free design" gets a misplugged cable. STP is your safety net. 6. **No root planning.** New switch added with low MAC → claims root → traffic re-routes badly. Plan root placement. 7. **Root Guard missing from access downlinks.** Distribution switches should refuse to honor any BPDU claiming superior root on access-facing ports. Without Root Guard, an attacker can run a malicious switch that wins root and pulls traffic through them. 8. **Loop Guard + UDLD not deployed on fiber inter-switch trunks.** Unidirectional fiber failure is rare but devastating — UDLD detects, Loop Guard contains. 9. **Manual priority that doesn't account for MST/Rapid-PVST+ encoding.** Setting `priority 1` doesn't work — must be multiple of 4096. Use `root primary` instead of raw priority for safety. 10. **Forgetting that VLAN 1 STP often runs separately on PVST+.** Every VLAN has its own STP. Hard-code roots per VLAN (or use a single range macro). ## Lab to try tonight 1. **Triangle setup** — three switches (SW1, SW2, SW3) connected in a full triangle. Two PCs (one on SW2, one on SW3). 2. **Default behavior** — boot all three with defaults. Run `show spanning-tree` on each. Identify the root, the blocked port. Note the convergence after `shutdown` of an inter-switch link. 3. **Force a root** — `spanning-tree vlan 1 root primary` on SW1. Confirm SW1 is now root regardless of MAC. Verify by `show spanning-tree root`. 4. **Failover drill** — shut the link between SW1 and SW2. Watch the previously-blocked SW2-SW3 link unblock. Time the convergence. 5. **Move to Rapid-PVST+** — `spanning-tree mode rapid-pvst` on all three. Re-time the convergence (should drop to ~1-2 s). 6. **PortFast + BPDU Guard** — on an access port, enable both. Plug in a PC — should come up instantly. Plug in another switch — should err-disable instantly. Recover with shut/no-shut. 7. **Root Guard demo** — on SW1's link to SW2, enable `spanning-tree guard root`. Attempt to make SW2 root by setting its priority lower. Watch SW1's port go root-inconsistent. 8. **MST experiment (advanced)** — convert all three switches to `spanning-tree mode mst` with one region. Group VLANs into MST instances. Verify multiple roots can coexist (different instance = different root). 9. **Storm Control** — manually create a Layer-2 loop (loop two ports together with no STP). Watch the storm. Enable `storm-control broadcast level 1.0` and watch the port shut down instead of bringing the network down. 10. **Bonus: UDLD** — simulate a unidirectional fiber by adding asymmetric ACLs blocking one direction of BPDUs. Verify UDLD detects. ## Cheat strip | Concept | Plain English | |---|---| | **Why STP exists** | L2 loops melt the network — STP blocks redundant paths until needed | | **Root bridge** | The one switch every other points to. Lowest Bridge ID wins. Always hard-code. | | **Bridge ID** | Priority (default 32768) + MAC. Lower wins. | | **Root port (RP)** | Best path **toward** root. One per non-root switch. Forwarding. | | **Designated port (DP)** | Best port **on a segment** toward root. Forwarding. | | **Blocked / Alternate** | Anything that isn't RP or DP. Listens for BPDUs only. | | **Port states (classic)** | Disabled → Blocking → Listening → Learning → Forwarding | | **Port states (RSTP)** | Discarding → Learning → Forwarding | | **Convergence** | 802.1D ~50s, RSTP ~1-2s. Always use Rapid-PVST+ | | **STP cost (802.1D)** | 10M=100, 100M=19, 1G=4, 10G=2 | | **Default Hello / Max Age / Forward Delay** | 2s / 20s / 15s | | **BPDU** | Multicast to 01:80:C2:00:00:00 every 2s | | **`root primary` / `root secondary`** | Sets priority to 24576 / 28672 | | **Priority multiples** | Must be multiple of 4096 (0, 4096, 8192, …) | | **PortFast** | Skip listen/learn on access ports | | **BPDU Guard** | Err-disable a port if it receives a BPDU | | **Root Guard** | Block a port if it tries to claim superior root | | **Loop Guard** | Block port if it stops receiving BPDUs (unidirectional fiber detection) | | **UDLD** | Layer-1 unidirectional link detection. Partner to Loop Guard | | **Rapid-PVST+** | Modern Cisco default. One RSTP per VLAN | | **MST (802.1s)** | Groups VLANs into instances. Scales to 1000+ VLANs | | **STP storm reality** | Without STP, any L2 loop = network down in seconds | ## Frequently asked questions **Q: What's the difference between STP, RSTP, and MSTP?** A: STP (802.1D, 1990) converges in 30-50 seconds — too slow for modern networks. RSTP (802.1w, 2001) converges in under a second by using explicit handshake between switches instead of timer-based recalculation. MSTP (802.1s) lets you map multiple VLANs onto a smaller number of spanning-tree instances to reduce CPU load — useful with hundreds of VLANs. Almost every modern Cisco switch runs Rapid PVST+ (Cisco's per-VLAN RSTP flavour) by default. **Q: How do I make a specific switch the root bridge?** A: `spanning-tree vlan 10 priority 4096` on the switch you want as root. The lowest priority wins the root election; 4096 is well below the default (32768) but leaves room to designate a secondary root with `priority 8192`. Never trust the default election — the oldest switch (lowest MAC address) usually wins by accident, which puts your root somewhere random. Always explicitly set root and backup-root per VLAN. **Q: What is BPDU Guard and where should I enable it?** A: BPDU Guard shuts down a port immediately if it receives a BPDU. Enable it on every access port (where you plug in PCs, phones, printers) — those devices should never send BPDUs. If a user plugs in a rogue switch (accidental or malicious), BPDU Guard triggers err-disable and the port goes down before the rogue can influence your spanning tree. Best paired with `spanning-tree portfast bpduguard default` at the global level. **Q: Why is PortFast dangerous on trunk ports?** A: PortFast skips the listening/learning states and puts the port into forwarding immediately. On an access port going to a PC that's fine — the PC will never send BPDUs. On a trunk port to another switch, PortFast means the port forwards traffic before spanning tree has resolved the topology — creating a temporary loop that can bring the whole network down. Cisco has PortFast for trunk (`portfast trunk`) for special cases, but never enable regular PortFast on a trunk. **Q: What's the difference between Root Guard, BPDU Guard, and Loop Guard?** A: All three protect spanning tree, but from different failures. BPDU Guard shuts a port down on any BPDU (protects access ports from rogue switches). Root Guard puts a port into `root-inconsistent` if it receives a superior BPDU (protects your root election from a rogue switch being elected root). Loop Guard puts a port into `loop-inconsistent` if BPDUs stop arriving on a non-designated port (protects against unidirectional link failures). In production, use all three at the appropriate ports. --- ## EtherChannel (Link Aggregation) — https://packetmentor.com/topics/etherchannel/ > Bundle multiple physical links between two switches into one logical Port-Channel — more bandwidth, instant failover, and STP sees it as a single link. Covers LACP, PAgP, static, and load-balancing methods. ## Mental model Two switches connected by one cable: STP sees one path, you get one link's worth of bandwidth, and if that cable dies you're disconnected. Connect them with **four** cables instead and STP — being STP — will block three of them to prevent a loop. You paid for four cables, you can only use one. EtherChannel is the trick that lets STP see all four cables as **one logical link** (a Port-Channel). Now nothing gets blocked, all four links forward traffic in parallel, and if one cable fails you lose 25% of bandwidth but stay online. ## Three ways to form an EtherChannel | Mode | Protocol | When to use | |---|---|---| | **LACP** | 802.1AX (industry standard) | Always your first choice — works with non-Cisco gear | | **PAgP** | Cisco-proprietary | Legacy Cisco-only environments | | **Static (on)** | None — both sides forced on | When negotiation isn't possible / for max performance | For LACP and PAgP, both ends negotiate before bringing the bundle up. For static, you tell both sides "you're a Port-Channel, end of story" — risky if one side is misconfigured (creates a loop). ### LACP modes (`active` / `passive`) - **active** — actively sends LACP packets - **passive** — answers if asked, doesn't initiate - At least **one** side must be active ### PAgP modes (`desirable` / `auto`) - **desirable** — actively negotiates - **auto** — passive, answers only - At least **one** side must be desirable ## Commands ### LACP — the typical case ``` ! Both SW1 and SW2 — pick matching ports SW1(config)# interface range GigabitEthernet0/1 - 4 SW1(config-if-range)# channel-protocol lacp SW1(config-if-range)# channel-group 1 mode active ! SW1(config)# interface Port-channel 1 SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk allowed vlan 10,20,30 ``` Configure the **Port-channel** interface (the logical one), not the individual physical interfaces. Settings on Po1 propagate to all members. ### Static (no negotiation) ``` SW1(config-if-range)# channel-group 1 mode on ``` Make sure both ends are `on` — mismatched modes create a black hole. ### Choose a load-balancing method ``` SW1(config)# port-channel load-balance src-dst-ip ``` Default is `src-dst-mac` — good enough for switch-to-switch in a flat LAN. For router-to-switch or many-to-one flows, use `src-dst-ip` so different conversations actually hash to different physical links. ## Verification ``` SW1# show etherchannel summary SW1# show etherchannel 1 detail SW1# show interfaces Port-channel 1 SW1# show lacp neighbor ``` The most useful one: `show etherchannel summary`. The bundle is healthy if you see `Po1(SU)` and `(P)` next to each member port — `S` = layer 2 / switch, `U` = in use, `P` = bundled. ## Common mistakes 1. **Mismatched settings on member ports.** All ports in a bundle must have identical speed, duplex, native VLAN, allowed VLAN list, and switchport mode. One mismatch and the port falls out of the bundle. 2. **One end LACP, other end PAgP.** They don't speak each other's protocols. Bundle never forms. Both ends must use the same negotiation. 3. **Both ends in passive / auto.** Neither side initiates negotiation → bundle never forms. At least one side must be active (LACP) or desirable (PAgP). 4. **Configuring physical interfaces individually after bundling.** Once `channel-group 1` is on a port, that port inherits everything from `Port-channel 1`. Configure on Po1, not on the members. 5. **Static `on` on one end, LACP on the other.** Static sends no LACP packets — the LACP side waits for negotiation that never comes. Both ends must agree on mode. 6. **Default load-balancing on a router-to-switch link.** Default `src-dst-mac` hashes everything from the router to the same physical link (router's MAC never changes). Use `src-dst-ip` for variety. ## Lab to try tonight 1. Two switches connected with four physical Ethernet links. 2. Verify STP behavior first: `show spanning-tree` should show three of the four links blocked. 3. Configure LACP EtherChannel on all four ports of both switches (one side active, other side passive). 4. Run `show etherchannel summary` — should show all four members bundled and in use. 5. Re-run `show spanning-tree` — now you should see ONE Port-channel interface, no blocked links. 6. Unplug one cable. Verify the Port-channel stays up with 3 members. Plug it back, watch it re-bundle. 7. Bonus: change load-balancing method and observe the change in `show etherchannel load-balance`. ## Cheat strip | Concept | Plain English | |---|---| | **EtherChannel / Port-Channel** | 2–8 physical links bundled into one logical interface | | **LACP** | Industry-standard negotiation (use this) | | **PAgP** | Cisco-only negotiation (avoid unless required) | | **Static `on`** | No negotiation — both sides forced | | **Po1** | Shorthand for Port-Channel 1, the logical interface | | **Load-balancing** | How traffic is distributed across member links. `src-dst-ip` is the safe default. | | **Failure** | One member dies → bundle stays up minus that bandwidth | ## Frequently asked questions **Q: What's the difference between LACP and PAgP?** A: LACP (802.3ad) — the IEEE standard, works between any vendors. Modes: `active` (initiates) and `passive` (responds). PAgP — Cisco proprietary. Modes: `desirable` (initiates) and `auto` (responds). Also both support `on` (unconditional, no negotiation) which is dangerous — a misconfigured link can bring down the channel. Best practice: LACP `active` on both sides for interoperability. **Q: How many links can I bundle in an EtherChannel?** A: Up to 8 active links per bundle. LACP allows 16 configured (8 active + 8 standby ready to take over). Aggregation is done by the load-balancing hash — throughput scales roughly linearly if flows are diverse, less if you have one big flow (a single TCP flow always uses the same link — you can't split a flow across bundle members). **Q: What's an EtherChannel misconfig guard?** A: `spanning-tree etherchannel guard misconfig` — Spanning Tree kills the port channel if the two ends disagree on membership. Common cause: one side has 4 ports in the channel, the other side has 3 — a fourth port is "orphan" on one end and creates a loop. Guard shuts the whole channel down until you fix it. Always enable it. **Q: Can I bundle links of different speeds?** A: No — all bundle members must have the same speed and duplex. LACP will refuse to bundle a 1Gb port with a 10Gb port. All members should also be in the same VLAN (for L2 channels) or same subnet (for L3 channels), same trunk configuration, same STP path cost. Any mismatch and the port drops out of the bundle. **Q: What's the difference between Layer 2 and Layer 3 EtherChannel?** A: L2 (default) — the bundle is a single logical trunk or access port, participates in Spanning Tree as one entity. L3 — you configure `no switchport` and assign an IP directly to the port-channel interface, making the bundle a routed link. L3 EtherChannel is common between distribution and core switches; L2 is common between access and distribution. --- ## Inter-VLAN Routing — https://packetmentor.com/topics/inter-vlan-routing/ > How devices in different VLANs talk to each other. Covers router-on-a-stick (with sub-interfaces), Layer-3 switch SVIs, and when to pick each. ## Mental model VLANs are broadcast domains. Two PCs in different VLANs are, from the network's perspective, on different switches. They can't talk to each other at Layer 2 — there is no Layer 2 path between them, by design. To make them talk, you need something at Layer 3 — a **router** (or a switch that can route, called a Layer-3 switch). The Layer-3 device has an interface in each VLAN. A frame from VLAN 10 arrives at the router, the router strips the Layer-2 header, makes a routing decision based on destination IP, and sends the packet back out into the appropriate VLAN. Two ways to wire this up: | Approach | What it is | Best for | |---|---|---| | **Router-on-a-stick** | One physical router interface, one sub-interface per VLAN, all over a trunk | Small networks (≤ 4 VLANs), labs, branch routers | | **Layer-3 switch (SVIs)** | A switch with built-in routing — one "switched virtual interface" per VLAN | Production. Standard for any campus / data center. | ## Router-on-a-stick A single physical router interface carries traffic for multiple VLANs by using **sub-interfaces**, one per VLAN, each tagged with that VLAN's 802.1Q ID. ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# no shutdown R1(config)# interface GigabitEthernet0/0.10 R1(config-subif)# encapsulation dot1q 10 R1(config-subif)# ip address 10.0.10.1 255.255.255.0 R1(config)# interface GigabitEthernet0/0.20 R1(config-subif)# encapsulation dot1q 20 R1(config-subif)# ip address 10.0.20.1 255.255.255.0 ``` The corresponding switch port becomes a trunk: ``` SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk allowed vlan 10,20 ``` PC-A in VLAN 10 sends to PC-B in VLAN 20 → frame goes up the trunk → router's Gi0/0.10 sub-interface receives → router routes to Gi0/0.20 sub-interface → frame goes back down the trunk with VLAN 20 tag. **The bottleneck:** every inter-VLAN packet traverses the trunk twice. If the trunk is 1 Gbps, all inter-VLAN traffic shares that 1 Gbps. Fine for small offices, terrible for data centers. ## Layer-3 switch with SVIs Modern Catalyst switches have routing built in. Instead of sending traffic out to a router, the switch routes between VLANs *in hardware* using **Switched Virtual Interfaces (SVIs)** — one virtual L3 interface per VLAN. ``` SW1(config)# ip routing ! enable routing on the switch SW1(config)# vlan 10 SW1(config-vlan)# name USERS SW1(config)# vlan 20 SW1(config-vlan)# name SERVERS SW1(config)# interface vlan 10 SW1(config-if)# ip address 10.0.10.1 255.255.255.0 SW1(config-if)# no shutdown SW1(config)# interface vlan 20 SW1(config-if)# ip address 10.0.20.1 255.255.255.0 SW1(config-if)# no shutdown ``` That's it. The switch is now the default gateway for both VLANs, and inter-VLAN traffic switches in hardware at wire-speed. ## Layer-3 routed port (for uplinks) An L3 switch can also have a **routed port** — a port that acts like a router interface (not part of any VLAN): ``` SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# no switchport ! turn off Layer-2 behavior SW1(config-if)# ip address 10.0.99.1 255.255.255.252 ``` Used for point-to-point uplinks between L3 switches or to routers — no VLAN, no STP, just routing. ## Verification ``` R1# show ip interface brief R1# show ip route SW1# show ip interface vlan 10 SW1# show ip route ``` On an L3 switch, `show ip route` should display directly-connected routes for each SVI — that's how it knows it can deliver inter-VLAN traffic. ## Common mistakes 1. **Forgetting to enable `ip routing` on a Layer-3 switch.** SVIs come up, but the switch refuses to route between them. Always `ip routing` first. 2. **Setting hosts' default gateway to the wrong VLAN's SVI.** Each PC must have its default gateway pointed to its own VLAN's SVI (or sub-interface). Mixing them up = host can't reach anything off-subnet. 3. **Trunk port doesn't allow the VLAN.** Router-on-a-stick relies on the trunk carrying all the relevant VLANs. If the switch's `switchport trunk allowed vlan` list doesn't include VLAN 20, sub-interface Gi0/0.20 will never see traffic. 4. **Sub-interface encapsulation mismatch.** The number after `encapsulation dot1q` must match the VLAN ID on the switch side. `Gi0/0.10 encapsulation dot1q 99` is a config bug. 5. **Forgetting `no switchport` on a routed port.** Without it, the port is still a switchport and can't accept an IP address. 6. **Putting the routed port back into a VLAN by mistake.** Once `no switchport` is set, the port is L3. Re-issuing `switchport` reverts it — but any IP config is removed silently. ## Lab to try tonight 1. One Layer-3 switch (or a router + a Layer-2 switch). Two PCs in VLAN 10 and 20. 2. Approach A — Router-on-a-stick: configure sub-interfaces on the router, trunk on the switch. Set each PC's default gateway to the sub-interface IP. Confirm inter-VLAN ping works. 3. Approach B — L3 switch SVIs: enable `ip routing` on the switch, configure SVIs for VLAN 10 and 20, remove the router entirely. Set each PC's gateway to its SVI IP. Confirm inter-VLAN ping works. 4. Measure latency on each approach (use `ping -t` or repeated pings). The L3 switch should be noticeably lower. 5. Disable `ip routing` on the L3 switch. Confirm inter-VLAN ping now fails (despite SVIs being up). ## Cheat strip | Concept | Plain English | |---|---| | **Inter-VLAN routing** | Layer-3 device routing between VLANs | | **Router-on-a-stick** | One trunk + one sub-interface per VLAN on a router | | **SVI** | Switched Virtual Interface — L3 interface for a VLAN on a switch | | **Routed port** | L3 port on a switch (`no switchport`) — no VLAN, point-to-point use | | **`encapsulation dot1q N`** | Tells a sub-interface to tag/untag with VLAN N | | **`ip routing`** | The command that turns on routing on a Layer-3 switch | | **Default gateway** | Each host points to its VLAN's L3 interface | --- ## Wireless LAN Basics — https://packetmentor.com/topics/wireless-lan-basics/ > Definitive CCNA-level Wi-Fi fundamentals — SSID / BSS / ESS / BSSID terminology, autonomous vs lightweight APs, CAPWAP tunnel anatomy, WLC discovery (DHCP option 43 + DNS), Wi-Fi standards generations, security (WPA / WPA2 / WPA3), roaming, and 7 worked scenarios. ## Mental model Wi-Fi extends a wired Layer-2 LAN over the air. Devices that can't be cabled — phones, laptops, IoT, conference-room cameras — connect through an **access point (AP)** that bridges them to the wired network. For a small office with 2–3 APs, each AP can be configured standalone. For an enterprise with 50+ APs across floors and buildings, you don't want to log into each one. You centralize on a **wireless LAN controller (WLC)**. Each AP just provides the radio; the WLC handles SSIDs, security, VLAN mapping, RF tuning, and roaming. Practical wiring note: APs mounted in the ceiling are almost never plugged into a separate power adapter — the switch port powers them over the same Cat6 cable via [Power over Ethernet](/topics/power-over-ethernet/). A Wi-Fi 6 AP typically needs PoE+ (802.3at, 30 W); Wi-Fi 6E / 7 with multi-gig uplinks often needs PoE++ (802.3bt). Three things to internalize before anything else: 1. **The air is a shared half-duplex medium.** Two devices on the same channel within range share the airtime. Half-duplex means at any instant, only one is transmitting. CSMA/CA (collision avoidance) coordinates who talks when. 2. **A Wi-Fi network on the air looks different from on the wire.** What clients see is the SSID; what the AP actually advertises is a BSSID per radio. Multiple BSSIDs can broadcast the same SSID. 3. **Roaming is the hard part.** When a client moves between APs, the handoff needs to be fast (< 100 ms for voice) without losing connection. The WLC's job is to coordinate. ## Wi-Fi standards — the generations | IEEE name | Marketing name | Year | Band | Max raw rate | |---|---|---|---|---| | 802.11a | — | 1999 | 5 GHz | 54 Mbps | | 802.11b | — | 1999 | 2.4 GHz | 11 Mbps | | 802.11g | — | 2003 | 2.4 GHz | 54 Mbps | | 802.11n | **Wi-Fi 4** | 2009 | 2.4 + 5 GHz | 600 Mbps | | 802.11ac | **Wi-Fi 5** | 2013 | 5 GHz | 6.9 Gbps | | 802.11ax | **Wi-Fi 6** | 2019 | 2.4 + 5 GHz | 9.6 Gbps | | 802.11ax (6 GHz) | **Wi-Fi 6E** | 2020 | 6 GHz | 9.6 Gbps | | 802.11be | **Wi-Fi 7** | 2024 | 2.4 + 5 + 6 GHz | 46 Gbps | For the CCNA exam: recognize each, know which bands they use. For deep coverage of Wi-Fi 6 / 6E / 7 features (OFDMA, MU-MIMO, MLO, etc.) see [Wi-Fi 6/6E/7 Features](/topics/wifi-6-7-features/). ## Frequency bands — 2.4 GHz vs 5 GHz vs 6 GHz | Band | Channels (US) | Range | Congestion | Use | |---|---|---|---|---| | **2.4 GHz** | 1, 6, 11 (only 3 non-overlapping) | Long (penetrates walls) | Highly congested — Bluetooth, microwaves, IoT | Legacy + IoT | | **5 GHz** | ~25 non-overlapping 20 MHz channels | Shorter, blocked by walls more | Lower | Default for enterprise | | **6 GHz** | 14 non-overlapping 80 MHz channels | Similar to 5 GHz | Almost empty (Wi-Fi 6E only) | New deployments | 2.4 GHz has only 3 non-overlapping channels in the US (1, 6, 11) because the band is small and channels overlap. 5 GHz has many more, which is why it's the modern default for enterprise. 6 GHz is fresh spectrum opened in 2020 — only Wi-Fi 6E+ clients can use it. For deep RF physics (path loss, SNR, RSSI, antenna patterns), see [Wireless RF Fundamentals](/topics/wireless-rf-fundamentals/). ## The terminology — SSID, BSS, BSSID, ESS This is the single most-tested set of definitions in CCNA wireless. Internalize: | Term | Stands for | What it is | Example | |---|---|---|---| | **SSID** | Service Set Identifier | The Wi-Fi network name a user sees | `Corp-Wifi` | | **BSS** | Basic Service Set | One AP's radio coverage area | The lobby AP's coverage | | **BSSID** | Basic Service Set ID | The AP radio's MAC address (uniquely identifies a BSS) | `ec:1d:8b:33:44:55` | | **ESS** | Extended Service Set | Multiple BSSes broadcasting the same SSID | All 50 APs broadcasting `Corp-Wifi` | | **IBSS** | Independent BSS | Ad-hoc Wi-Fi (no AP) — peer-to-peer | Phone hotspot in ad-hoc mode | **The relationship:** - One **AP** has one or more **BSSes** (one per active SSID per radio). - Each **BSS** has a unique **BSSID** (the radio MAC). - Many BSSes broadcasting the same **SSID** form an **ESS**. - An **SSID** is the human-readable name. A **BSSID** is the machine-readable identifier. You can have: - 1 AP × 1 SSID × 1 BSS × 1 BSSID - 1 AP × 3 SSIDs × 3 BSSes × 3 BSSIDs (each SSID has its own BSSID on the same radio) - 50 APs × 1 SSID × 50 BSSes × 50 BSSIDs = 1 ESS (the canonical enterprise pattern) ## AP modes — autonomous vs lightweight **Autonomous AP** — standalone, configures itself, no controller needed. Each AP holds its own config (WLAN definitions, security keys, VLAN mappings). Used in: - Home / SOHO with 1-3 APs. - Branch with no WLC. - Testing / labs. **Lightweight AP (LAP)** — depends on a WLC. The AP just provides the radio; everything else (auth, VLAN assignment, RF management, roaming coordination) lives on the WLC. The enterprise standard. A lightweight AP boots → finds the WLC → forms a CAPWAP tunnel → downloads its config. From that point, the AP is just a remote radio. | | Autonomous | Lightweight | |---|---|---| | Config location | On the AP | On the WLC (pushed to AP) | | Scale | Tens of APs | Thousands | | Roaming coordination | None (each AP independent) | WLC orchestrates fast roaming | | RF tuning | Manual per AP | WLC's RRM (Radio Resource Management) auto-tunes | | Firmware updates | One AP at a time | WLC pushes to all APs | | Cost | Lower upfront | Higher (WLC + APs) | | When to choose | Small site, no controller | Enterprise, multi-site, mobility | Modern Cisco APs (Catalyst 9100 series) can run in either mode — boot determines which. ## CAPWAP — how APs and WLCs actually talk **CAPWAP** (Control And Provisioning of Wireless Access Points, RFC 5415) is the tunnel protocol between lightweight APs and the WLC. Two channels: | Channel | UDP port | Purpose | Encrypted? | |---|---|---|---| | **Control** | **5246** | Config, policy, RF management, AP status | Yes (DTLS) | | **Data** | **5247** | Client traffic encapsulated to/from WLC | Optional (DTLS) | The key insight: **client traffic is tunneled from AP to WLC** before being released onto the wired network. So: - Client connects to AP-23 in Building B. - Client's frames are CAPWAP-encapsulated by AP-23. - Tunnel goes to WLC (perhaps in a different building, even data center). - WLC decapsulates and forwards onto the configured VLAN. Because it's tunneled, the AP and WLC don't have to be on the same VLAN or even the same subnet. The AP can be at a branch; the WLC can be at HQ over the WAN. As long as IP reachability exists between them. The other mode: **FlexConnect**, where the AP **switches client traffic locally** instead of tunneling to the WLC. Useful for branch offices where the WAN to the WLC is too slow to hairpin all traffic through. See [AP Operating Modes](/topics/ap-operating-modes/). ## WLC discovery — how an AP finds its WLC When a lightweight AP boots, it doesn't know where the WLC is. It tries multiple discovery methods, in order: 1. **Static IP** — if previously configured, the AP saves the WLC IP locally. Try it first. 2. **Local subnet broadcast** — broadcast a "Discovery Request" on the local subnet. Works if WLC is on the same VLAN. 3. **DHCP Option 43** — the DHCP server hands out a vendor-specific option containing the WLC IP(s). 4. **DNS** — the AP queries DNS for `CISCO-CAPWAP-CONTROLLER.` (where local-domain comes from the DHCP-provided DNS suffix). 5. **Manually configured IP** — administratively set on the AP's console. The standard enterprise pattern: DHCP Option 43 or DNS. Once the AP discovers the WLC IP, it sends a CAPWAP Join Request and forms the tunnel. ### DHCP Option 43 syntax (Cisco IOS DHCP server) ``` R1(config)# ip dhcp pool LWAPP-VLAN R1(dhcp-config)# network 10.20.30.0 255.255.255.0 R1(dhcp-config)# default-router 10.20.30.1 R1(dhcp-config)# option 43 hex f104.0a01.0102 ! WLC IP = 10.1.1.2 ``` The hex format encodes WLC IP addresses. `f1` = sub-option type 0xF1 (WLC IP list), `04` = length 4 bytes, then the IP in hex. Multiple IPs concatenate. ### DNS approach (often easier to manage) Create a DNS A record for `CISCO-CAPWAP-CONTROLLER.example.com` pointing at your WLC IP(s). APs receiving a DHCP-provided DNS suffix of `example.com` automatically query for this name. ## Security — WPA, WPA2, WPA3 | Standard | Year | Authentication | Encryption | Status in 2026 | |---|---|---|---|---| | **WEP** | 1997 | Shared key | RC4 | **Broken since 2001. Never use.** | | **WPA** | 2003 | PSK or 802.1X | TKIP | Stopgap. Deprecated. Don't use. | | **WPA2 Personal** | 2004 | PSK (4-way handshake) | AES-CCMP | Still common for home/SMB | | **WPA2 Enterprise** | 2004 | 802.1X + RADIUS | AES-CCMP | Common enterprise default | | **WPA3 Personal** | 2018 | SAE (replaces PSK with stronger handshake) | AES-CCMP | New deployments default | | **WPA3 Enterprise** | 2018 | 802.1X + RADIUS | AES-CCMP / AES-GCMP | New enterprise default | **Defaults for new 2026 deployments:** - Home / SMB / guest SSID: **WPA3-Personal** with SAE. - Corporate SSID: **WPA3-Enterprise + 802.1X** with EAP-TLS (cert-based) or PEAP (cert + password). - 6 GHz band: **WPA3 mandatory** — Wi-Fi 6E doesn't allow older security on this band. For the full picture see [Wi-Fi Security](/topics/wifi-security/). ### 802.1X / EAP — enterprise authentication When a client joins an Enterprise SSID: 1. AP/WLC sees a new device, sends an **EAP Identity Request**. 2. Client sends its identity (username or cert). 3. WLC forwards EAP messages to the RADIUS server ([Cisco ISE](/topics/cisco-ise-basics/), FreeRADIUS, etc.) via the RADIUS protocol. 4. Authentication happens (cert validation, password check, posture check). 5. On success, RADIUS returns a per-session encryption key (PMK) and possibly a VLAN/dACL. 6. Client and AP derive the session keys via the 4-way handshake. 7. Client is authenticated, encrypted, and assigned to its policy. See [802.1X / dot1x](/topics/dot1x/) for the wired equivalent (same protocol, different transport). ## Roaming — the WLC's hardest job When a Wi-Fi client moves from AP-23 to AP-24, the network needs to: 1. Detect the client is on AP-24 now. 2. Switch CAPWAP tunnel context. 3. Continue the existing TCP connections seamlessly. 4. Avoid re-authenticating from scratch (slow). Three roaming techniques: | Technique | What it does | |---|---| | **Layer-2 roaming** | Within the same subnet — easy. Client keeps its IP. | | **Layer-3 roaming** | Across subnets — needs tunneling back to anchor AP/WLC. | | **802.11r (Fast Transition / FT)** | Pre-authenticates with neighboring APs. < 50 ms handoff. Required for voice. | | **802.11k** | Helps client discover neighbor APs | | **802.11v** | Lets WLC suggest a better AP to a client | For voice + video: enable 802.11r + 802.11k + 802.11v on the WLAN. Without these, voice calls drop during roaming. ## Configuration on a Cisco 9800 WLC (CLI snippet) GUI is the primary interface, but CLI exists: ``` WLC(config)# wlan Corp-Wifi 1 Corp-Wifi WLC(config-wlan)# security wpa WLC(config-wlan)# security wpa wpa3 WLC(config-wlan)# security wpa wpa3 ciphers gcmp256 WLC(config-wlan)# security wpa akm dot1x-sha256 WLC(config-wlan)# aaa-override WLC(config-wlan)# client vlan 10 WLC(config-wlan)# no shutdown ``` For 802.1X you'd also configure RADIUS servers and a method-list, similar to wired AAA. ## Verification (Catalyst 9800) ``` WLC# show ap summary WLC# show wireless wlan summary WLC# show wireless client summary WLC# show wireless client mac-address detail WLC# show ap name AP-LOBBY config general WLC# show wireless interface summary WLC# show wireless mobility summary ``` `show ap summary` = all APs joined to the WLC + their state. `show wireless client summary` = all clients + their SSID + AP + signal strength + IP. On the AP itself (Cisco IOS-XE for Catalyst APs): ``` AP# show capwap detail AP# show capwap client mn AP# show ip interface brief ``` ## The 6-step Wi-Fi debug When clients can't connect or can't pass traffic: 1. **Is the AP joined to the WLC?** `show ap summary` — state should be Registered. 2. **Is the SSID broadcasting?** Use a Wi-Fi scanner app from a phone — see if you can detect the SSID. If not, check `show wireless wlan summary` for state. 3. **Can the client associate?** Check `show wireless client mac-address detail`. State should reach `Run`. 4. **Authentication succeeded?** If 802.1X, check RADIUS server logs. Common failures: expired cert, wrong password, RADIUS server unreachable. 5. **Did the client get an IP?** DHCP server side. CAPWAP delivers client traffic to the configured VLAN; verify `ip helper-address` on the SVI. 6. **Can the client ping the gateway?** If yes, network is fine; problem is downstream. If no, check VLAN config + ACLs. ## Worked scenarios --- **Scenario 1.** A client connects to "Corp-Wifi" near AP-A, then walks to AP-B, also broadcasting "Corp-Wifi". What changed and what stayed the same? **Answer:** - **Same:** SSID, ESS, client's IP, encryption keys (if 802.11r enabled). - **Different:** BSSID (the radio MAC of the AP it's associated to — now AP-B's MAC instead of AP-A's), BSS (now AP-B's coverage area), possibly channel. --- **Scenario 2.** A new branch site has 6 lightweight APs but no WLC on-site. The corporate WLC is at HQ over a 50 Mbps WAN link. What design choice avoids hairpinning all client traffic through HQ? **Answer:** Configure the APs in **FlexConnect** mode. Client data is switched locally at the AP onto a local VLAN, while control plane still goes to HQ via CAPWAP. Saves WAN bandwidth and improves performance. --- **Scenario 3.** An AP boots but never appears as Registered on the WLC. What are the top three checks? **Answer:** 1. **CAPWAP ports open?** UDP 5246 + 5247 from the AP subnet to the WLC IP. Test with `telnet WLC-IP 5246` — should at least open TCP-like to confirm reachability (though CAPWAP is UDP, this rules out path-level firewalls). 2. **AP found the WLC?** Check the AP's console: `show capwap client mn`. If it can't see the WLC, fix DHCP Option 43 or DNS. 3. **AP IOS matches WLC?** Major version mismatches prevent CAPWAP join. Upgrade or downgrade as needed. --- **Scenario 4.** Why does an enterprise typically use lightweight APs instead of autonomous? **Answer:** Centralized management at scale. With 100+ APs, individually managing config, RF channels, firmware, security keys is impractical. The WLC handles RF tuning (RRM), client load-balancing, roaming optimization, fast 802.1X auth, and centralized policy. --- **Scenario 5.** You want the same SSID broadcast on 2.4 GHz and 5 GHz from the same physical AP. How many BSSIDs? **Answer:** Two BSSIDs — one per radio. The radios have different physical MAC addresses (often differing in the low bits). The SSID is the same; the BSSIDs differ. Clients see "Corp-Wifi" and choose which radio to associate with (band steering helps them prefer 5 GHz). --- **Scenario 6.** A client says "I can see the Wi-Fi but can't connect." `show wireless client mac-address ` shows state `Authenticating`. Most likely cause? **Answer:** 802.1X / RADIUS issue. Either RADIUS server unreachable from WLC, wrong shared secret, expired client cert, or wrong username/password. Check RADIUS server logs first. --- **Scenario 7.** Why doesn't WEP work for security anymore? **Answer:** WEP's RC4 implementation is fundamentally broken — known cryptographic weaknesses since 2001 allow recovering the key by capturing a few minutes of traffic. Tools like `aircrack-ng` automate this. There is no fix; the protocol itself is unsalvageable. WPA2/WPA3 use AES which has no comparable weakness. ## Common mistakes 1. **Two APs broadcasting the same SSID with different security settings.** Clients get unpredictable behavior. Make all APs in an ESS identical. 2. **Forgetting CAPWAP firewall ports.** UDP 5246 + 5247 blocked = AP can't join WLC. The error is silent — AP just doesn't show up. 3. **APs and WLC on different subnets without discovery configured.** Lightweight APs default to subnet broadcast for discovery. Across subnets, configure DHCP Option 43 or DNS. 4. **Forgetting to set DTIM / beacon intervals for IoT.** Battery devices wake up at DTIM intervals to check for buffered frames. Wrong intervals drain battery fast. 5. **Mixing 2.4 GHz + 5 GHz without band-steering.** Modern clients prefer 5 GHz but some legacy gear glues to 2.4. Enable band-steering on the WLC. 6. **Co-channel interference.** Two APs on the same channel in range constantly contend. Plan reuse: 1/6/11 for 2.4 GHz; let RRM auto-tune 5 GHz. 7. **Skipping 802.11r for voice deployments.** Voice handoff requires < 50 ms; without FT, the EAP re-auth alone takes 100+ ms and calls drop. 8. **Using WPA2-PSK in 2026 production.** WPA3-Personal (SAE) is a drop-in upgrade and adds forward secrecy + offline-attack protection. 9. **Forgetting that 6 GHz mandates WPA3.** If you try to broadcast a WPA2-only SSID on 6 GHz, clients can't join — 6 GHz blocks legacy security entirely. 10. **High AP density without RF planning.** Cramming APs every 10 feet doesn't help if they're all on the same channels — they just create more co-channel interference. Run a predictive survey. ## Lab to try tonight If you have access to a Cisco Catalyst 9800 WLC (CML, EVE-NG, or [Cisco DevNet Sandbox](https://devnetsandbox.cisco.com)): 1. **Bring up WLC + AP** — virtual 9800 + virtual AP. Wait for the AP to register. 2. **Configure SSID** — create `LAB-WIFI` with WPA2-PSK key `cisco123`. Map to VLAN 10. Enable broadcast. 3. **Client test** — connect a laptop, verify it gets a `10.0.0.x` DHCP address. 4. **CAPWAP inspection** — on the AP: `show capwap detail`. Observe control + data tunnel state. 5. **Multi-SSID** — add a `GUEST` SSID mapped to VLAN 20 with captive-portal redirect. 6. **WPA3 upgrade** — change `LAB-WIFI` to WPA3-Personal. Reconnect from a supported client. 7. **802.1X with RADIUS** — stand up FreeRADIUS on a Linux VM. Configure WLAN security as 802.1X. Test from a corporate cert. 8. **Multi-AP roaming** — if you can join a second AP, walk a client between them. Observe BSSID change in `show wireless client mac-address detail`. 9. **Bonus: FlexConnect** — convert an AP to FlexConnect mode. Verify client traffic is now switched locally at the AP, not tunneled to the WLC. 10. **Bonus: Wireshark on CAPWAP** — capture between AP and WLC. Decode the CAPWAP tunnel to see encapsulated client frames. ## Cheat strip | Term | Plain English | |---|---| | **AP** | Access Point — the radio. Bridges Wi-Fi to wired. | | **WLC** | Wireless LAN Controller — central brain for many APs | | **SSID** | Network name (`Corp-Wifi`) — human-facing | | **BSS** | One AP's radio coverage area | | **BSSID** | The AP radio's MAC address — uniquely identifies a BSS | | **ESS** | Many BSSes broadcasting the same SSID — one logical network | | **IBSS** | Ad-hoc Wi-Fi (no AP). Rare. | | **Autonomous AP** | Standalone, holds its own config | | **Lightweight AP** | Depends on WLC. Enterprise standard. | | **CAPWAP** | Tunnel between LAP and WLC. UDP 5246 (control, DTLS) + 5247 (data) | | **DHCP Option 43** | Hands AP the WLC IP via DHCP | | **CISCO-CAPWAP-CONTROLLER** | DNS-based WLC discovery name | | **FlexConnect** | Mode where AP switches client traffic locally instead of tunneling to WLC | | **WEP / WPA** | Broken. Never use. | | **WPA2-PSK** | Still common at home/SMB | | **WPA3-Personal (SAE)** | 2026 home/SMB default — replaces PSK with stronger handshake | | **WPA2/3-Enterprise** | 802.1X + RADIUS. Enterprise standard | | **6 GHz mandates WPA3** | No legacy security allowed | | **802.11r (FT)** | Fast Transition for sub-50ms roaming. Required for voice | | **802.11k / v** | Help clients discover and switch to better APs | | **Bands** | 2.4 GHz (congested, 3 non-overlapping ch) · 5 GHz (~25 ch) · 6 GHz (14 × 80 MHz, Wi-Fi 6E only) | | **Generations** | Wi-Fi 4 (n) · 5 (ac) · 6 (ax) · 6E · 7 (be) | ## Frequently asked questions **Q: What's the difference between 2.4 GHz and 5 GHz?** A: 2.4 GHz has better range (lower frequency travels further and through walls better) but only three non-overlapping channels (1, 6, 11) and is crowded — microwave ovens, Bluetooth, baby monitors all use it. 5 GHz has shorter range but many more non-overlapping channels (20+ depending on region), less interference, and higher throughput. Modern enterprise designs put voice + laptops on 5 GHz and only fall back to 2.4 for IoT / older devices. **Q: What's the difference between SSID and BSSID?** A: SSID is the network name humans see ("CorporateWiFi"). BSSID is the MAC address of an individual AP's radio broadcasting that SSID. One SSID typically = many BSSIDs (one per AP, sometimes one per radio band per AP). When your phone "roams" between APs, it's switching BSSIDs while staying on the same SSID. **Q: What's a rogue AP and how do I detect one?** A: An AP on your network you didn't authorise — could be an employee plugging in a personal router (unmalicious but insecure) or an attacker running an evil twin (broadcasting your SSID to trick users into connecting). Detect via WLC rogue detection (Cisco WLCs classify unknown BSSIDs as rogues), wireless intrusion prevention (WIPS), or physical audit. Every enterprise WLAN should have rogue detection enabled. **Q: Should I hide my SSID for security?** A: No — it's security theatre. Hidden SSIDs (broadcasts with a blank name) are trivially discovered — every client probe-request reveals the SSID. And hidden SSIDs actively hurt battery life (clients constantly probe for the network by name). Real security = WPA3 (or WPA2-Enterprise with 802.1X), not SSID hiding. **Q: What channel width should I use — 20, 40, or 80 MHz?** A: 20 MHz on 2.4 GHz always (there's not enough spectrum for wider channels). On 5 GHz: 40 MHz is a good default in most environments. 80 MHz gives higher peak throughput but eats spectrum — with dense AP deployment you actually get *less* aggregate capacity because APs interfere. Only use 160 MHz for very sparse deployments (home). --- ## WLAN Architectures — Autonomous, Centralized (WLC), Cloud, Embedded — https://packetmentor.com/topics/wlan-architectures/ > Definitive CCNA-level WLAN architecture guide — autonomous vs centralized vs cloud-managed vs embedded WLC, split-MAC duty division, CAPWAP tunnel, AP modes (Local / FlexConnect / Bridge), WLC discovery, redundancy / N+1 / SSO, when each architecture fits. ## Mental model Wi-Fi started simple: one AP, configured locally, broadcasting an SSID. For a small office with 1–3 APs, that's still fine — the **autonomous AP** model. The problem: you can't scale autonomy. With 200 APs across an enterprise campus you can't SSH into each one to push a config change. Roaming between APs gets weird (each AP decides independently when to release a client). Tracking clients across the network is impossible. APs doing independent radio management step on each other's channel assignments. The fix: **split the AP's duties**. Time-sensitive radio work (encryption, beacon timing, MAC ACK) stays on the AP — it has to, because microsecond responses matter. Everything else (config, policy, RADIUS auth, RF management, roaming decisions, location services) moves to a central **WLC** (Wireless LAN Controller). The lightweight AP becomes a radio with brains relocated to the WLC. This is **split-MAC architecture**. It's been the standard for enterprise Wi-Fi since ~2008. ## Four WLAN architectures — what to use when | Architecture | Where control lives | Sweet spot | Trade-offs | |---|---|---|---| | **Autonomous AP** | Inside each AP | ≤ 3-5 APs, no controller budget | No roaming optimization, manual config per AP, no central RF tuning | | **Centralized (WLC)** | Dedicated WLC appliance | Single-campus enterprise, 5–1000+ APs | Hairpin traffic through WLC (unless FlexConnect); WLC is a critical dependency | | **Cloud-managed** | Vendor's cloud (Meraki, Cisco Spaces, Mist) | Multi-site, distributed orgs, MSP-friendly | Recurring subscription, internet-dependent control plane | | **Embedded WLC** | Running on an access switch (e.g., Catalyst 9300 with EWC) | Small-to-mid campus (≤100 APs), no separate WLC budget | Switch CPU shared between switching + WLC duties | CCNA scope: **Autonomous** + **Centralized** in depth. **Cloud-managed** + **Embedded** at the recognition level. ### Autonomous AP — standalone Each AP holds its own config. SSID definitions, security keys, VLAN mappings all live in the AP's startup config. To change something, you log into the AP. To deploy 50 APs, you configure 50 APs. Pros: - No WLC cost. - No WLC = no single point of failure. - Survives WAN outages (no controller dependency). Cons: - No coordinated roaming between APs. - No central RF channel/power management. - Manual config replication is error-prone. - No client tracking or location services. - Each AP a separate management surface. In 2026 use cases: home offices, micro-branches (1-3 APs), labs, kiosks. Anywhere a real enterprise WLAN is overkill. ### Centralized — Lightweight AP + WLC The default for enterprise. Every AP is "lightweight" — runs only the time-critical radio code. Config lives on the WLC. CAPWAP tunnel between AP and WLC carries control + data. Pros: - One management surface for hundreds/thousands of APs. - Coordinated roaming (handoff < 50ms with 802.11r). - RRM (Radio Resource Management) auto-tunes channels + power across APs. - Central policy (per-SSID, per-VLAN, per-user). - Client visibility (one query lists every client). - Easy upgrades (WLC pushes firmware to all APs). Cons: - WLC failure = AP service degrades (depends on mode — see "AP modes" below). - Client traffic may hairpin through WLC, adding latency + bandwidth tax. - Requires WLC purchase and licensing. - Network paths must reach the WLC. ### Cloud-managed — Meraki / Cisco Spaces / Mist The control plane lives in the vendor's cloud, not your network. APs reach out to the cloud over the internet for config and management. Client data still flows locally (does NOT hairpin to the cloud). Pros: - Manage thousands of APs across hundreds of sites from one cloud GUI. - Zero-touch deployment (ship the AP to a branch; it phones home). - AI/ML features (Mist Marvis, Meraki Insight) — anomaly detection, root-cause hints. - No on-prem WLC to maintain. Cons: - Recurring subscription cost. - Internet outage = no management (data plane still works locally for existing APs). - Vendor lock-in — Meraki APs only work with Meraki cloud. - Less granular control vs traditional WLC. Use case: distributed retail, hospitality, K-12 schools, MSPs, anywhere "central WLC at HQ" doesn't fit the topology. ### Embedded WLC — controller on a switch A WLC instance running directly on a Catalyst 9300 / 9500 access switch (using Catalyst 9800-CL Embedded Wireless Controller). The switch performs its normal duties plus runs the WLC code. Pros: - No separate WLC hardware. - Tight integration with the wired network. - Lower TCO for mid-size sites. Cons: - Switch CPU shared between switching + WLC. - Lower AP capacity than a dedicated WLC (typically up to 200 APs vs 6,000 on a 9800-80). - Tighter coupling: switch maintenance affects wireless control plane. Use case: smaller campuses with ≤ 100 APs that already use Catalyst 9000-series access switches. ## Split-MAC architecture — what runs where In a centralized WLC deployment, the AP and WLC each own different responsibilities: | Function | AP | WLC | |---|---|---| | 802.11 frame encryption (WPA2/3) | **✓** | | | Beacon transmission | **✓** | | | Probe response | **✓** | | | MAC ACK (sub-millisecond) | **✓** | | | Decryption of incoming frames | **✓** | | | Authentication (802.1X / PSK 4-way handshake) | | **✓** | | AAA / RADIUS proxy | | **✓** | | Roaming coordination | | **✓** | | RF channel + power management (RRM) | | **✓** | | Client tracking + location services | | **✓** | | Config push to APs | | **✓** | | QoS policy + per-WLAN rate limits | | **✓** | | Captive portal / web auth | | **✓** | | Rogue AP detection | Both | **✓** (correlates) | | Mesh / point-to-point links | **✓** | (coordinated) | The split line is **"must respond in microseconds = AP"** versus **"can respond in milliseconds = WLC."** ## CAPWAP — the AP↔WLC tunnel **CAPWAP** (Control And Provisioning of Wireless APs, RFC 5415) is the protocol that connects each lightweight AP to its WLC. Two channels: | Channel | UDP port | Purpose | Encrypted? | |---|---|---|---| | **Control** | **5246** | Config, policy, RF management, AP status | Yes (DTLS always) | | **Data** | **5247** | Client traffic encapsulated to/from WLC | Optional (DTLS) | Key insight: **client traffic is tunneled from AP to WLC** before being released on the wired network (in Local mode). Implications: - AP and WLC don't need to be on the same VLAN or subnet. - Client traffic crosses the WAN if the WLC is at HQ — bandwidth tax. - WLC sees and can policy every client packet. - Adds latency proportional to AP-to-WLC distance. ## AP Modes — Local vs FlexConnect vs others The WLC tells the AP how to operate: | Mode | Behavior | Use | |---|---|---| | **Local** | Default. Client traffic tunneled to WLC. | Campus where WLC and APs are nearby. | | **FlexConnect** | Client traffic switched locally at AP (data plane); control plane still to WLC. | Branch offices with slow / metered WAN to WLC. | | **Sniffer** | AP forwards every captured 802.11 frame to a Wireshark host. | Troubleshooting roaming, association, auth. | | **Monitor** | No client service. AP just scans the air. | Dedicated RF / rogue detection / location anchor. | | **Rogue Detector** | Listens for unauthorized APs. | Compliance environments. | | **Bridge / Mesh** | Wireless backhaul. AP acts as RAP or MAP. | Outdoor, warehouse, port/yard, P2P building links. | | **SE-Connect** | Streams spectrum data to Spectrum Expert. | Hunt non-Wi-Fi interference. | Full detail in [AP Operating Modes](/topics/ap-operating-modes/). ### FlexConnect deep dive — the most CCNA-relevant non-Local mode FlexConnect (formerly H-REAP) was built for branches with a centralized WLC at HQ. The trade-off: - Control plane to WLC over WAN — minimal traffic. - Data plane switched locally at the AP — no hairpinning of every Wi-Fi packet across the WAN. - AP can stay operational (in "Standalone" state) during WAN outages, authenticating clients using cached creds. When to use FlexConnect: any branch with slow WAN where you don't want every client packet hairpinning to HQ. ## WLC discovery — how a lightweight AP finds its controller A factory-fresh AP has no config — just enough firmware to discover a WLC. Discovery order: 1. **Static IP** — if the AP was previously joined, the WLC IP is cached in flash. 2. **Layer-2 broadcast** — broadcast on the local subnet (rarely works in 2026 since AP and WLC are usually on different subnets). 3. **DHCP Option 43** — the DHCP server hands out the WLC IP(s) alongside the AP's normal DHCP lease. 4. **DNS** — the AP queries DNS for `CISCO-CAPWAP-CONTROLLER.` (using DNS suffix from DHCP). 5. **Manual** — set on AP console. Enterprise default: **DHCP Option 43 or DNS**. DNS is often easier to maintain (one record vs hex-encoded option 43). ### DHCP Option 43 syntax (Cisco IOS DHCP server) ``` R1(config)# ip dhcp pool AP-VLAN R1(dhcp-config)# network 10.20.30.0 255.255.255.0 R1(dhcp-config)# default-router 10.20.30.1 R1(dhcp-config)# option 43 hex f104.0a01.0102 ! WLC IP = 10.1.1.2 ``` The hex format encodes WLC IPs: - `f1` = sub-option type 0xF1 (WLC IP list) - `04` = length 4 bytes - `0a01.0102` = `10.1.1.2` in hex (10 = 0x0a, 1 = 0x01, etc.) Multiple WLC IPs concatenate: `f108.0a01.0102.0a01.0103` for two WLCs. ### DNS approach Create an A record `CISCO-CAPWAP-CONTROLLER.example.com → `. APs that receive DHCP with DNS suffix `example.com` will query for this name automatically. Multiple A records for HA. ## Once discovered — the CAPWAP join sequence ``` 1. AP sends Discovery Request (broadcast / unicast). 2. WLC responds with Discovery Response. 3. AP selects WLC (if multiple respond — based on priority + load). 4. AP sends CAPWAP Join Request. 5. WLC validates AP (cert check, model whitelist). 6. WLC responds with Join Response. 7. AP downloads firmware (if version mismatch). 8. AP downloads config (SSIDs, security, VLAN maps). 9. AP transitions to Run state. 10. AP starts broadcasting SSIDs and serving clients. ``` Verify the sequence on the AP console: ``` AP# show capwap client mn AP# show capwap detail ``` ## WLC redundancy — keeping wireless alive when the WLC fails A single WLC is a single point of failure. Three common redundancy patterns: ### N+1 redundancy (oldest) Multiple primary WLCs + one backup. Each AP has a primary, secondary, and tertiary WLC in its config. If the primary fails, APs join the secondary. Slow failover (re-join the secondary = ~30 seconds). ### HA SSO (High Availability with Stateful Switchover) Two WLCs configured as a single logical pair. Active + Standby. The Standby mirrors the Active's state in real time. When the Active fails, Standby takes over **instantly** (sub-second), and APs don't even know — they keep their CAPWAP tunnel to the same "WLC IP" (a shared management IP). Modern Catalyst 9800 default. The right answer for enterprise. ### Stretched / DC redundancy Multiple WLC pairs across data centers. APs select the nearest reachable WLC via priorities. Used for global enterprises. ## Mobility groups — coordinated roaming across WLCs When APs are spread across multiple WLCs (e.g., separate WLCs per building), roaming across WLCs needs coordination. **Mobility Group** — a set of WLCs that share client context. When a client roams from WLC-A's AP to WLC-B's AP, WLC-A and WLC-B exchange the client's state so the handoff is seamless. ``` WLC-A(config)# wireless mobility group name CAMPUS-MOBILITY WLC-A(config)# wireless mobility group member ip 10.0.0.2 public-ip 10.0.0.2 ``` Without mobility groups: cross-WLC roaming = full re-auth, including 802.1X — slow, voice calls drop. ## Configuration patterns (Catalyst 9800 WLC) ``` ! Define a WLAN WLC(config)# wlan Corp-Wifi 1 Corp-Wifi WLC(config-wlan)# security wpa wpa3 WLC(config-wlan)# security wpa wpa3 ciphers gcmp256 WLC(config-wlan)# security dot1x authentication-list ISE-AUTH WLC(config-wlan)# client vlan 10 WLC(config-wlan)# no shutdown ! Define a policy profile (what to do with clients on this WLAN) WLC(config)# wireless profile policy Corp-Policy WLC(config-wireless-policy)# vlan 10 WLC(config-wireless-policy)# no shutdown ! Tag — bind WLAN + policy to APs WLC(config)# wireless tag policy Corp-Tag WLC(config-policy-tag)# wlan Corp-Wifi policy Corp-Policy ! Apply to APs WLC(config)# ap aaaa.bbbb.cccc policy-tag Corp-Tag ``` Modern Catalyst 9800 uses **tags** (Policy, Site, RF) to apply config to APs in groups. Older AireOS WLCs used the AP-group concept. ## Verification (Catalyst 9800) ``` WLC# show ap summary WLC# show ap join stats summary WLC# show wireless client summary WLC# show wireless wlan summary WLC# show wireless tag policy summary WLC# show wireless mobility summary WLC# show capwap session WLC# show ap config general AP-LOBBY ``` `show ap summary` = all APs joined + their state. `show wireless client summary` = all clients + AP + SSID + signal. ## The 6-step WLAN architecture debug When clients aren't connecting on a centralized WLAN: 1. **Is the AP joined to the WLC?** `show ap summary` — state should be `Registered` (joined). If not joined, fix CAPWAP path (Option 43, DNS, firewall blocking UDP 5246/5247). 2. **Is the WLAN broadcasting?** `show wireless wlan summary`. State should be `Enabled` and broadcast set. SSID visible from a phone Wi-Fi scanner. 3. **Can the client associate?** `show wireless client mac-address detail`. State should reach `Run`. If stuck at `Authentication`, RADIUS/802.1X issue. 4. **VLAN + DHCP?** Client got an IP? Trace the CAPWAP data plane: WLC decapsulates and forwards on the configured VLAN. `ip helper-address` on that VLAN's SVI? 5. **Mode-specific issues?** If FlexConnect, verify trunk on the AP's local switch port. If Local, verify WLC has IP path to the client's VLAN. 6. **HA / failover state?** `show redundancy` on the WLC HA pair. Active should be `Active`; Standby should be `Hot Standby`. ## Worked scenarios --- **Scenario 1.** A new branch has 8 lightweight APs but the WLC is at HQ over a 50 Mbps WAN. Which AP mode minimizes WAN load? **Answer:** **FlexConnect**. Client data is switched locally at the AP (uses the local VLAN trunk on the AP's switch port); only control plane traffic to the WLC goes over the WAN. --- **Scenario 2.** An AP boots but doesn't appear on the WLC. `show ap summary` shows nothing. Top three checks? **Answer:** 1. **CAPWAP ports** — UDP 5246/5247 open from AP subnet to WLC? 2. **WLC discovery** — DHCP Option 43 or DNS `CISCO-CAPWAP-CONTROLLER.` configured? 3. **AP firmware** — major version mismatch with WLC prevents join. Match versions. --- **Scenario 3.** Why might an enterprise prefer Embedded WLC over a dedicated 9800? **Answer:** Mid-size site, ≤ 100 APs, already using Catalyst 9300 access switches. Embedded WLC avoids a separate hardware purchase + licensing while reusing existing switch CPU. Trade-off is lower AP scale and shared switch CPU. --- **Scenario 4.** Cloud-managed (Meraki) loses internet connectivity for 4 hours. What happens to existing Wi-Fi clients? **Answer:** Existing clients stay connected and continue to pass traffic (data plane is local, not cloud-dependent). New management changes can't be pushed during the outage. Some advanced features (cloud-based analytics, certain policy types) may be unavailable. Network functions for end users mostly unaffected. --- **Scenario 5.** Two WLCs are deployed in HA SSO. The Active fails. What does an AP experience? **Answer:** Sub-second failover. The AP keeps its CAPWAP tunnel to the same logical management IP (now answered by the formerly-Standby WLC). Clients don't drop. SSO maintains the AP's state through the failover. --- **Scenario 6.** A client roams from an AP on WLC-A to an AP on WLC-B. The roam is slow and the user hears a voice call hiccup. What's missing? **Answer:** Either (a) **mobility group** between WLC-A and WLC-B isn't configured — they don't share client context, so cross-WLC roams require full re-auth, or (b) **802.11r (FT)** isn't enabled on the WLAN. Both should be configured for voice deployments. --- **Scenario 7.** A new building's APs join a remote WLC over WAN. Latency is 50ms one-way. Why might users see slow Wi-Fi performance? **Answer:** In Local mode, every Wi-Fi packet hairpins through the WLC — adding 100ms round-trip to every packet. Apps that are latency-sensitive (voice, video, interactive) degrade. **Solution:** convert these APs to FlexConnect mode so data switches locally. ## Common mistakes 1. **Trying to manually configure a lightweight AP via console.** Only the WLC pushes config. If an AP isn't joining, fix the discovery path — don't try to console-config it. 2. **Firewall blocking CAPWAP.** UDP 5246/5247 closed = silent failure. AP just doesn't appear on the WLC. 3. **Forgetting that WLC reachability matters.** A lightweight AP with no path to the WLC is useless. Plan WLC HA + redundant network paths. 4. **One central WLC for global enterprise.** Cross-continent CAPWAP control plane adds latency for every config change. Deploy regional WLCs or use cloud-managed for distributed orgs. 5. **Mixing autonomous and lightweight modes.** A given AP runs one mode. Converting requires firmware re-flash. Pick a strategy. 6. **Hairpinning branch traffic to HQ WLC unnecessarily.** Use FlexConnect mode at branches to switch traffic locally. 7. **Skipping mobility groups across multi-WLC deployments.** Cross-WLC roams become full re-auths. Slow. Configure mobility groups. 8. **No WLC HA in production.** Single WLC = single point of failure for all wireless. Always deploy HA SSO pair. 9. **Using DHCP Option 43 without verifying the hex encoding.** A wrong byte = AP can't parse the WLC IP. DNS-based discovery is easier to verify. 10. **Embedded WLC overload.** Pushing 200 APs through a Catalyst 9300 EWC strains the switch CPU. Stay within rated scale (typically 100-200 APs). 11. **Trying to manage Meraki + Catalyst from one pane.** Different ecosystems. Catalyst Center bridges some of this gap but expect operational seams. ## Lab to try tonight Best path: use Cisco DevNet's Always-On wireless sandbox or reservable Catalyst 9800 sandbox. 1. **Reserve a 9800 + AP sandbox** — Cisco DevNet Sandboxes → Wireless → Catalyst 9800. 2. **Verify APs joined** — `show ap summary` — confirm Registered state. 3. **CAPWAP details** — `show capwap session` on the WLC. Note UDP 5246 control + 5247 data. 4. **Discovery inspection** — `show ap join stats summary` shows how each AP found this WLC (Option 43, DNS, etc.). 5. **Create a WLAN** — WPA2-Personal SSID `LAB-WIFI`, map to VLAN 10. Verify it appears in `show wireless wlan summary`. 6. **Connect a client** — laptop / phone. Verify with `show wireless client summary`. 7. **Mode change** — switch one AP from Local to FlexConnect. Verify with `show ap config general `. 8. **Mobility group** — if the sandbox has two WLCs, configure mobility group between them. `show wireless mobility summary`. 9. **HA SSO** — if the sandbox includes an HA pair, fail the Active WLC (`reload`). Watch Standby take over. Verify APs stay registered. 10. **Bonus** — RRM observation. `show ap dot11 5ghz summary` to see RF coordination (channel, power assignments per AP). ## Cheat strip | Concept | Plain English | |---|---| | **Autonomous AP** | Standalone, full config local. Small offices, ≤3-5 APs | | **Lightweight AP** | Just the radio. Brain on WLC. Enterprise standard | | **Centralized WLC** | Dedicated WLC appliance + lightweight APs | | **Cloud-managed** | Meraki / Cisco Spaces / Mist — control plane in vendor cloud | | **Embedded WLC** | WLC code running on a Catalyst 9300/9500 switch | | **Split-MAC** | Time-critical functions on AP, mgmt on WLC | | **CAPWAP** | Tunnel between LAP and WLC (UDP 5246 control / 5247 data) | | **DHCP Option 43** | Hands WLC IP via DHCP — hex-encoded | | **CISCO-CAPWAP-CONTROLLER** | DNS-based WLC discovery name | | **Local mode** | Default. Data hairpinned to WLC. | | **FlexConnect** | Data switched locally at AP. Branch use. | | **Monitor / Sniffer / Bridge / SE-Connect** | Specialized AP modes | | **HA SSO** | Stateful WLC failover. Sub-second. Modern default. | | **N+1 redundancy** | Primary + backup WLC. Failover ~30s. Older model. | | **Mobility Group** | Coordinated client context across multiple WLCs | | **9800 WLC** | Cisco's modern WLC platform (replaces older AireOS WLCs) | | **Tags (Policy / Site / RF)** | 9800's grouping model for applying config to APs | | **`show ap summary`** | Daily-driver — all APs + state | | **`show wireless client summary`** | All clients + AP + SSID + signal | | **CCNA depth** | Autonomous vs Centralized in depth · Cloud + Embedded recognize-level | --- ## Wi-Fi Security — WEP, WPA, WPA2, WPA3 — https://packetmentor.com/topics/wifi-security/ > Twenty-five years of wireless security in one page. Why WEP is broken, why WPA is a stop-gap, why WPA2 ruled for two decades, and what WPA3 actually fixes. ## Mental model Wireless is fundamentally an open broadcast — anyone within radio range hears your packets. Wi-Fi security is the cryptography that makes those broadcasts unreadable to anyone without the key. The history is a story of breakage and patches: - **WEP** (1997): the original attempt. Broken by 2001 because of weak RC4 IV usage. Cracking tools became laptop-installable. **Never use.** - **WPA** (2003): emergency patch on WEP-era hardware while WPA2 was being finalized. Vulnerable to dictionary attacks. **Deprecated.** - **WPA2** (2004): proper rewrite with AES-CCMP. Solid for ~15 years. Still acceptable in 2026 (though deprecated for new deployments). - **WPA3** (2018): replaces PSK with SAE (Simultaneous Authentication of Equals) — adds forward secrecy, kills offline dictionary attacks, beefs up enterprise crypto. ## Personal vs Enterprise Every WPA variant has two modes: | Mode | How it authenticates | Best for | |---|---|---| | **Personal (PSK / SAE)** | Pre-shared key (a password everyone knows) | Home, small office, guest networks | | **Enterprise (802.1X)** | Each user authenticates against a RADIUS server | Corporate, university, anywhere with managed users | Both encrypt the data link the same way. They differ only in how the keys are derived. - **PSK** = everyone with the password is welcome. If the password leaks, change it on every device. - **802.1X** = each user has their own credentials. Disable one user without affecting others. For CCNA, know both flavors and the key differences. ## What each standard actually does ### WEP (1997, BROKEN) - RC4 stream cipher with 24-bit IV (initialization vector) - IVs reused too often → key recovered from ~10 minutes of traffic - 64-bit "WEP" key is really 40-bit + 24-bit IV — laughably weak - **Cracking tools:** aircrack-ng, 5 lines of bash. Do not use WEP for anything. ### WPA (2003, DEPRECATED) - Same RC4 cipher but with TKIP (Temporal Key Integrity Protocol) - Per-packet key mixing — fixed the IV reuse problem - Designed to run on old WEP hardware via firmware update — that constraint limited its strength - Vulnerable to chopchop and Beck-Tews attacks (2008) ### WPA2 (2004, ACCEPTABLE) - New cipher: **AES-CCMP** (AES in counter mode with CBC-MAC). Strong, modern, hardware-accelerated on most chipsets. - Personal: PSK with 8–63 character password. **Vulnerable to offline dictionary attack** if the 4-way handshake is captured. - Enterprise: 802.1X with PEAP / EAP-TLS / EAP-FAST. - KRACK vulnerability (2017) — patched in all major OSes. ### WPA3 (2018, CURRENT) - Personal: replaces PSK with **SAE (Simultaneous Authentication of Equals)** — also known as the Dragonfly handshake. **Forward secrecy** (capturing the handshake doesn't help an attacker), no offline dictionary attack. - Enterprise: optional 192-bit suite with GCMP-256 + SHA-384 — for high-security environments. - Protected Management Frames (PMF) mandatory — prevents deauth/disassoc spoofing attacks. - **Easy Connect** for IoT / headless devices via QR code. ## The 4-way handshake (in 90 seconds) When a WPA2 / WPA3 client associates with an AP, both sides go through a 4-message exchange to derive session keys: ``` 1. AP → Client: ANonce (AP's random nonce) 2. Client → AP: SNonce + MIC (proves client has the PSK / SAE result) 3. AP → Client: GTK (group key for multicast) + MIC 4. Client → AP: ACK ``` After this, both sides have: - A **PTK** (Pairwise Transient Key) — unique per client, encrypts unicast - A **GTK** (Group Temporal Key) — shared, encrypts multicast/broadcast The handshake is recorded if someone captures the exchange. In WPA2 PSK, a captured handshake plus a dictionary can brute-force the password offline (no need to be near the AP anymore). WPA3's SAE makes this infeasible. ## Configuration — Cisco 9800 WLC ### WPA3-Personal ``` WLC(config)# wlan WIFI-HOME 1 WIFI-HOME WLC(config-wlan)# security wpa WLC(config-wlan)# security wpa wpa3 WLC(config-wlan)# security wpa wpa3 ciphers gcmp256 WLC(config-wlan)# security wpa wpa3 dot11w required WLC(config-wlan)# security wpa psk WLC(config-wlan)# security wpa psk set-key ascii 0 my-passphrase WLC(config-wlan)# no shutdown ``` ### WPA2/WPA3 mixed (transition mode) For environments with both new and legacy clients: ``` WLC(config-wlan)# security wpa WLC(config-wlan)# security wpa wpa2 WLC(config-wlan)# security wpa wpa3 WLC(config-wlan)# security wpa wpa2 ciphers aes WLC(config-wlan)# security wpa wpa3 ciphers gcmp256 ``` Modern clients use WPA3; legacy clients fall back to WPA2. ### WPA3-Enterprise ``` WLC(config-wlan)# security wpa wpa3 dot11w required WLC(config-wlan)# security dot1x authentication-list AUTH-RADIUS WLC(config-wlan)# no security wpa psk ``` The RADIUS server (`AUTH-RADIUS`) handles 802.1X authentication. ## Common mistakes 1. **Still running WEP somewhere.** Audit. There's always one legacy IoT device that someone enabled WEP for in 2012 and forgot. 2. **WPA2 with a weak PSK.** "Cisco123" is in every dictionary. WPA2 PSK strength entirely depends on password complexity. Use a 16+ character random string. 3. **Mixed-mode WPA2/WPA3 with weak ciphers.** Mixed mode falls back to the lowest common denominator. Pin your minimum: `security wpa wpa2 ciphers aes` (don't allow TKIP). 4. **WPA-Enterprise without certificate validation.** Clients that don't validate the RADIUS server's certificate can be MITM'd by an evil twin AP. Always deploy proper CA certs and enable cert validation on supplicants. 5. **PMF (Protected Management Frames) optional or disabled.** Without PMF, an attacker can deauth clients. WPA3 requires PMF; WPA2 should enable it where supported. 6. **Treating PSK like it's secure forever.** PSK is shared. Someone leaves the company, they still have the Wi-Fi key. Either rotate it regularly, or use Enterprise so you can disable just their account. 7. **Disabling SSID broadcast as "security."** It's not. Tools list hidden SSIDs in seconds. Hidden SSID just makes legitimate users' lives harder. ## Lab to try tonight If you have a home AP or a Cisco WLC sandbox: 1. Configure two WLANs: one WPA2-Personal, one WPA3-Personal. 2. Connect a modern phone (WPA3-capable) to each. Check which standard it actually negotiates. 3. Try to crack the WPA2 handshake with aircrack-ng using a tiny dictionary that includes your test password. Should work. 4. Try the same against WPA3 — fails by design (SAE doesn't expose a handshake usable for offline cracking). 5. Configure mixed-mode WPA2/WPA3. Connect both modern and legacy devices. Verify each negotiates its best protocol. 6. Bonus: set up WPA3-Enterprise with FreeRADIUS and one test user. Configure your laptop's supplicant. Watch the EAP exchange in Wireshark. ## Cheat strip | Standard | Year | Status | Use? | |---|---|---|---| | **WEP** | 1997 | BROKEN since 2001 | Never | | **WPA** | 2003 | Deprecated | No | | **WPA2-Personal** | 2004 | Acceptable | Legacy ok | | **WPA2-Enterprise** | 2004 | Acceptable | Legacy ok | | **WPA3-Personal** | 2018 | Current | **Yes** | | **WPA3-Enterprise** | 2018 | Current | **Yes** | | **Personal mode** | | PSK / SAE — one password | Home, guest | | **Enterprise mode** | | 802.1X + RADIUS — per-user | Corporate | | **PMF** | | Protected Management Frames | Always enable | | **AES-CCMP** | | WPA2's cipher | Solid | | **GCMP-256** | | WPA3's strong cipher | Modern | --- ## Switching Operation — https://packetmentor.com/topics/switching-operation/ > How a switch actually decides where to forward each frame. Covers source-MAC learning, destination-MAC lookup, the three outcomes (forward / flood / drop), and store-and-forward vs cut-through. ## Mental model A switch does one thing per frame: decide which port (if any) to send it out. The decision is mechanical: 1. **Receive** a frame on a port. 2. **Learn** — record the source MAC of this frame against the port it came in on (in the [MAC address table](/topics/mac-address-table/)). 3. **Look up** the destination MAC in the same table. 4. **Forward, Flood, or Drop** based on the lookup result. This happens billions of times a second in a busy LAN. Hardware does it at wire-speed. ## The three outcomes ### Forward (the common case) Destination MAC is in the table, mapped to a specific port. Send the frame out **only that one port**. No one else sees it. ``` Frame arrives on Gi0/1 destined for dd:dd:dd CAM table says dd:dd:dd is on Gi0/5 → forward out Gi0/5 only ``` This is what makes switches different from hubs — and dramatically more efficient. Traffic between PC-A and PC-B doesn't disturb PC-C. ### Flood (unknown destination) Destination MAC isn't in the table. The switch sends the frame out **every other port in the same VLAN** — every port except the one the frame came in on. The hope: somewhere out there, the destination exists and will reply, which lets the switch learn its port. ``` Frame arrives on Gi0/1 destined for ee:ee:ee (unknown) → flood out Gi0/2, Gi0/3, Gi0/4, ..., everywhere except Gi0/1 ``` Three triggers cause flooding: - **Unknown unicast** — destination not in MAC table - **Broadcast** — destination FF:FF:FF:FF:FF:FF (always flooded) - **Multicast** — flooded unless IGMP snooping is configured ### Drop If the destination MAC is on **the same port the frame arrived on**, the switch drops the frame. Two hosts on the same physical port (impossible normally, but possible through a hub) would already have heard the frame — no point forwarding it back. Less common: drops happen for security policy (port security violation, ACL on an SVI, STP-blocked port). ## Store-and-forward vs cut-through Two switching modes: | Mode | Behavior | Trade-off | |---|---|---| | **Store-and-forward** | Buffer the entire frame, check FCS (frame check sequence), then forward | Slightly higher latency but no corrupt frames forwarded | | **Cut-through** | Forward as soon as the first 14 bytes (destination MAC) are read | Lowest latency but corrupt frames propagate | | **Fragment-free** | Cut-through, but wait for the first 64 bytes (catches collision fragments) | Compromise between the two | **Modern Cisco Catalyst switches default to store-and-forward.** Cut-through exists on data-center switches (Nexus, some merchant silicon) where every microsecond of latency matters. For CCNA, know all three terms; in real life, store-and-forward is what you have. ## Why the switch never reads the IP header Switches are **Layer 2 devices**. They see frames and MACs, full stop. The IP header inside the frame is irrelevant to switching decisions. That's why: - Switching doesn't need a router involved (Layer 3) when destination is in the same VLAN - Different VLANs can't talk without a router because the switch refuses to forward frames between VLANs — even though they share the same physical hardware - ACLs on regular switches operate on MAC / port; for IP-based filtering on a switch, you need a Layer-3 switch with SVIs ## Per-VLAN switching The MAC table is **per-VLAN**. A switch maintains separate tables for VLAN 10 and VLAN 20. ``` SW1# show mac address-table vlan 10 10 aaaa.aaaa.aaaa DYNAMIC Gi0/1 10 bbbb.bbbb.bbbb DYNAMIC Gi0/2 SW1# show mac address-table vlan 20 20 cccc.cccc.cccc DYNAMIC Gi0/5 ``` When a frame arrives, the switch looks up the destination MAC **only within the VLAN tagged on the frame**. Same MAC in two different VLANs? Two separate entries, treated independently. ## Switching modes you can set ``` SW1(config)# switching-mode store-and-forward ! default on most platforms SW1(config)# switching-mode cut-through ! some platforms only ``` Most Catalyst switches don't expose this — they're hardwired to one mode. Nexus and Data Center platforms expose it. ## Common mistakes 1. **Expecting switches to look at IP addresses.** They don't. Layer 2 only. If you need IP-based filtering, you need a Layer-3 switch (SVIs) or a router. 2. **Forgetting flooding happens on unknown unicast.** A quiet server whose MAC ages out causes its next inbound frame to flood every port. Mitigation: longer aging time or static MAC entries for critical servers. 3. **Confusing "flooding" with "broadcasting."** Broadcast = destination MAC `FF:FF:FF:FF:FF:FF`, by definition reaches everyone. Flooding = forwarding behavior, can happen for unicast / broadcast / multicast. 4. **Thinking VLANs use Layer-3 separation.** They use Layer-2 separation. Same physical switch, separate broadcast domains. Inter-VLAN traffic needs a router. 5. **Setting cut-through and being surprised by corrupted frames.** Cut-through propagates errored frames before the FCS is checked. Bad cabling or marginal optics → cascading errors. Use store-and-forward unless you have a specific reason. 6. **Misunderstanding switch fabric capacity.** A switch's "switching capacity" (sometimes called backplane) is what it can move in aggregate, not per port. A 24-port 1 Gbps switch might have 48 Gbps full-duplex switching capacity (24 × 1 × 2). Anything less and the switch is **oversubscribed**. ## Lab to try tonight 1. One switch, three PCs in the same VLAN. 2. Run `show mac address-table` — empty (no traffic yet). 3. Ping PC-A from PC-B. Re-run — both MACs appear. 4. Open Wireshark on PC-C. Ping PC-A from PC-B again. Confirm PC-C does NOT see the ping (forward, not flood). 5. `clear mac address-table dynamic`. Repeat the ping. PC-C briefly sees the first frame in Wireshark (flooded), then the table re-populates and subsequent frames don't flood. 6. Add static MAC entry pinning PC-A. Confirm it survives `clear mac address-table dynamic`. 7. Bonus: add VLAN 20, put PC-C in it. Try to ping from PC-A (VLAN 10) to PC-C (VLAN 20). Fails — different VLANs, no router. ## Cheat strip | Concept | Plain English | |---|---| | **Learn** | Record source MAC against inbound port | | **Look up** | Search CAM table for destination MAC | | **Forward** | Known destination → send to that one port | | **Flood** | Unknown destination / broadcast → send everywhere else in VLAN | | **Drop** | Destination is on the same port frame arrived on | | **Store-and-forward** | Default. Buffer full frame, check FCS. | | **Cut-through** | Forward after 14 bytes. Fast, error-prone. | | **Fragment-free** | Forward after 64 bytes. Catches collision fragments. | | **Per-VLAN table** | Different MACs tracked separately per VLAN | --- ## CDP & LLDP — Neighbor Discovery — https://packetmentor.com/topics/cdp-lldp/ > How devices learn about their directly-connected neighbors. CDP is Cisco-proprietary; LLDP is the vendor-neutral standard. Both shout the same info: who I am, what model, what IOS, what port — invaluable for troubleshooting. ## Mental model You walk into a new network. You SSH into one switch. You don't know what's connected to which port. **CDP / LLDP solves that** — every neighbor introduces itself, periodically and unsolicited. A Cisco switch broadcasts a multicast frame every 60 seconds saying *"I'm SW1, a Catalyst 9300, IOS 17.6, my Gi0/24 is on this wire."* Every neighbor records it. You run `show cdp neighbors` and see a table of who's on every port — model, IOS version, IP, peer's port number. That's the entire concept. Different name (CDP / LLDP / FDP for Foundry / EDP for Extreme), same idea. ## CDP vs LLDP | | CDP | LLDP | |---|---|---| | **Origin** | Cisco-proprietary | IEEE 802.1AB (industry standard) | | **Default state on Cisco** | Enabled globally + per interface | Disabled globally; needs enabling | | **Carries** | Device ID, platform, capabilities, IP, IOS, native VLAN, port-ID, duplex | Same kind of info | | **Hello interval** | 60s (default) | 30s (default) | | **Hold time** | 180s (3× hello) | 120s (4× hello) | | **Best when** | Pure Cisco environments | Multi-vendor environments | Most production networks run **both**. CDP works between Cisco devices. LLDP fills in for non-Cisco gear (printers, IP cameras, Aruba APs, anything not made by Cisco). ## Commands ### CDP ``` SW1# show cdp neighbors ! one-line per neighbor (most useful) SW1# show cdp neighbors detail ! verbose — IOS version, IP address SW1# show cdp interface ! which interfaces have CDP active SW1# show cdp entry R1 ! deep info about one specific neighbor ! Globally enable / disable SW1(config)# cdp run ! default on Cisco — keep it SW1(config)# no cdp run ! turn off entirely ! Per-interface SW1(config-if)# cdp enable SW1(config-if)# no cdp enable ! disable on this port only ``` ### LLDP ``` SW1# show lldp neighbors SW1# show lldp neighbors detail SW1# show lldp ! global status ! Enable globally (Cisco IOS default is OFF for LLDP) SW1(config)# lldp run ! Per-interface — direction matters! SW1(config-if)# lldp transmit ! send LLDP SW1(config-if)# lldp receive ! accept incoming LLDP SW1(config-if)# no lldp transmit ! mute outbound ``` LLDP separates transmit and receive — useful for "listen but don't reveal" scenarios. ## Sample output — what you'll see ``` SW1# show cdp neighbors Device ID Local Intrfce Holdtme Capability Platform Port ID R1.corp Gig 0/24 168 R ISR4331 Gig 0/0 SW2.corp Gig 0/23 151 S WS-C2960-48 Gig 0/1 AP-12.corp Gig 0/15 122 T AIR-AP3802 Gig 0 ``` In 5 seconds you know: R1 is a router on Gi0/24, SW2 is a switch on Gi0/23, and AP-12 is an access point on Gi0/15. ## Security implications CDP / LLDP **leaks information**. Any device on the LAN running `tcpdump` can read: - Device hostname → guess at naming convention - Platform → "Cisco 9300, IOS 17.6 — what vulnerabilities affect that version?" - Native VLAN ID → VLAN hopping attack hint - Power consumption, duplex, port-ID — info that helps an attacker map the network **The fix:** disable on user-facing ports. Keep enabled on inter-switch / inter-router trunks where you actually need it. ``` SW1(config)# interface range GigabitEthernet0/1 - 23 ! access ports SW1(config-if-range)# no cdp enable SW1(config-if-range)# no lldp transmit SW1(config-if-range)# no lldp receive ``` Then leave it on for uplinks where adjacent devices need to discover each other. ## Voice VLANs and CDP A specific case where you can't simply disable CDP: **Cisco IP phones use CDP** to learn their voice VLAN ID from the switch automatically. ``` SW1(config-if)# switchport mode access SW1(config-if)# switchport access vlan 10 ! data VLAN SW1(config-if)# switchport voice vlan 100 ! voice VLAN SW1(config-if)# cdp enable ! phone needs this ``` The phone sends CDP toward the switch, asking *"what's my voice VLAN?"* The switch replies with VLAN 100. The phone tags voice traffic accordingly. Without CDP, manual phone config is needed. LLDP-MED (Media Endpoint Discovery) is the multi-vendor equivalent — modern IP phones support it. Polycom, Yealink, and modern Cisco phones use LLDP-MED. ## Common mistakes 1. **Leaving CDP on every port.** Security risk on user-facing ports. Disable on access ports unless they connect to IP phones / APs / specific devices that need it. 2. **Disabling CDP everywhere.** Now you've lost a key troubleshooting tool. Targeted disable, not global. 3. **Forgetting LLDP is off by default on Cisco.** You add a third-party device, can't see it in CDP. Solution: turn on LLDP globally. 4. **Trusting CDP/LLDP info as authoritative.** It's whatever the neighbor *claims* to be. Spoofable. Use as a hint, not a source of truth for ACLs / security policies. 5. **Voice VLAN doesn't work after CDP disable.** Forgot the phone uses CDP. Re-enable on phone ports. 6. **Confusing CDP frame multicast address.** CDP uses `01:00:0c:cc:cc:cc`. LLDP uses `01:80:c2:00:00:0e`. Both reach all bridges that support the protocol on the segment. ## Lab to try tonight 1. Two Cisco devices connected by a single cable. 2. Wait ~2 minutes after boot. Run `show cdp neighbors` on each side. Verify each shows the other. 3. Run `show cdp neighbors detail` — note all the info disclosed (IOS, IP, native VLAN, etc.). 4. Capture with Wireshark on a span port: filter `cdp`. See the periodic CDP frames every 60 seconds. 5. Enable LLDP globally on both: `lldp run`. Re-verify with `show lldp neighbors`. 6. Disable CDP on one interface: `no cdp enable`. Re-check — only the other side still sees this device. 7. Bonus: connect a third-party device (any non-Cisco router/switch). Try CDP — doesn't work. Try LLDP — works. ## Cheat strip | Concept | Plain English | |---|---| | **CDP** | Cisco-proprietary discovery. Default on. | | **LLDP** | IEEE 802.1AB. Vendor-neutral. Default off on Cisco. | | **Hello interval** | CDP 60s, LLDP 30s | | **`show cdp neighbors`** | Daily-driver troubleshooting command | | **`detail`** | Adds IOS version, IP, native VLAN — more useful, more leakage | | **Security risk** | Leaks platform/version info — disable on user ports | | **Voice VLAN** | Cisco IP phones use CDP. Keep CDP on phone ports. | | **LLDP-MED** | Multi-vendor voice equivalent | | **Multicast MACs** | CDP 01:00:0c:cc:cc:cc · LLDP 01:80:c2:00:00:0e | ## Frequently asked questions **Q: Should I disable CDP for security?** A: On ports facing users or the internet: yes (`no cdp enable` on the interface). CDP announces device type, IOS version, IP addresses, and platform — great intel for an attacker. On switch-to-switch trunks: leave it on because it powers PoE negotiation, VoIP phone discovery, and network topology tooling. Best practice: `no cdp run` globally then re-enable per-interface where needed, or leave global on and disable per-interface for user ports. **Q: What's the difference between CDP and LLDP?** A: CDP is Cisco proprietary (also on some Cisco-aligned vendors like Meraki). LLDP (802.1AB) is the IEEE standard — works between Cisco, Juniper, Arista, HP, etc. Both send similar info (neighbour name, port, VLAN) at similar intervals (60s default). In a mixed-vendor environment, enable both — CDP for Cisco-to-Cisco, LLDP for cross-vendor. **Q: What are the default CDP timers?** A: Send every 60 seconds, hold time 180 seconds (3× the send interval). Change with `cdp timer ` and `cdp holdtime `. In stable networks, defaults are fine. Only tune down for faster failure detection — and if you're doing that for redundancy, you'd rather use a routing protocol's own hellos. **Q: Why does LLDP-MED matter for VoIP phones?** A: LLDP-MED (Media Endpoint Discovery) is the extension that lets a Cisco IP phone learn its voice VLAN, power budget (PoE class), and QoS settings automatically from the switch. Without it, you'd manually configure the phone. With it, plug the phone in and it comes up in the right VLAN with the right power — zero-touch deployment. Enable with `lldp med-tlv-select` on access ports. **Q: Where is CDP information stored?** A: In the CDP neighbour table, refreshed by incoming CDP announcements. View with `show cdp neighbors` (brief) or `show cdp neighbors detail` (full, including IP addresses and IOS versions). Entries age out after the hold time (180s default). Empty output means either CDP is disabled, the neighbour isn't Cisco, or the link is broken. --- ## Static Routing — https://packetmentor.com/topics/static-routing/ > Definitive CCNA-level static routing guide — next-hop vs exit-interface vs fully-specified, default routes, floating statics, summary routes, recursive lookup, IPv6 statics, AD reference, 8 worked scenarios, and the static-routing debug workflow. ## Mental model A router only knows two kinds of networks: 1. **Directly attached** — networks on one of its own interfaces. Learned automatically when you configure an IP + mask on an interface. 2. **Reachable through some other router** — has to be told how to get there. Static routing is the "telling" — manually configured entries. Three legitimate use cases for static routing in 2026: | Scenario | Why static fits | |---|---| | Tiny networks (≤3 routers) | OSPF/EIGRP overhead isn't worth it | | Stub networks (branch with one path out) | No alternative to choose between — dynamic routing buys nothing | | Default routes | Catch-all to the internet — no dynamic protocol expresses this naturally | For anything bigger than ~5 routers with redundant paths, use a dynamic protocol. Static routing doesn't recover from failures by itself unless you've layered a floating static or scripted reconvergence. ## How a static route enters the routing table Three conditions must all be true for a static route to appear in `show ip route`: 1. **You configured it** with `ip route ...`. 2. **The next-hop is reachable.** The router must have a route to the next-hop IP (or the exit interface must be `up/up`). 3. **No higher-priority route exists** for the same prefix at a better (lower) AD. If you write a static route but it doesn't show in the route table, it's almost always condition 2: the next-hop isn't reachable. Test with `ping ` from the router. ## Three syntaxes — which to use when ### Syntax 1 — next-hop IP ``` R1(config)# ip route 10.2.0.0 255.255.255.0 10.0.1.2 ``` Router does an ARP lookup for `10.0.1.2` to resolve the next-hop's MAC, then forwards. **Use on:** Ethernet, GRE tunnels, any multi-access medium where ARP makes sense. ### Syntax 2 — exit interface only ``` R1(config)# ip route 10.2.0.0 255.255.255.0 Serial0/0/0 ``` Router sends packets directly out the named interface — no ARP needed (point-to-point links). **Use on:** Serial / HDLC / PPP / point-to-point sub-interfaces. Never on plain Ethernet (causes catastrophic ARP for every destination IP). ### Syntax 3 — fully-specified (both) ``` R1(config)# ip route 10.2.0.0 255.255.255.0 GigabitEthernet0/0 10.0.1.2 ``` Most explicit — tells the router both the exit interface and the next-hop. Helpful in scenarios with multiple paths or when you want to avoid recursive lookups. **Use on:** any scenario where you want explicitness, especially when the next-hop is reachable through multiple interfaces. ### The three-way comparison | Form | Exit-interface ARP overhead | Recursive lookup | Recommended for | |---|---|---|---| | Next-hop only | One ARP per next-hop (cached) | Yes (find next-hop in routing table first) | Ethernet, most cases | | Exit-interface only | No ARP (point-to-point) | No | Serial / PPP / GRE point-to-point | | Fully-specified | One ARP cached | No | Multi-interface routers, explicit production config | ## Default route — the catch-all A default route matches **anything** that doesn't match a more specific route: ``` R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 ``` Read aloud: *"for any destination, send to `203.0.113.1`."* This is the route that points to the internet on every home/edge router. Without it, any traffic to an unknown destination is dropped (and the router may even send an ICMP unreachable back). Verify with: ``` R1# show ip route 0.0.0.0 Gateway of last resort is 203.0.113.1 to network 0.0.0.0 ``` The phrase **"Gateway of last resort"** in show output is your hint that a default route exists. If missing, no default is set. Default routes can be: - **Static** — `ip route 0.0.0.0 0.0.0.0 ` - **OSPF** — `default-information originate` injects a default into OSPF - **EIGRP** — redistribute a static default into EIGRP - **BGP** — receive a default from your ISP (the most common in service-provider environments) ## Floating static — the backup route A **floating static** is a static route with **artificially high administrative distance** so it's only used if the primary path fails: ``` ! Primary path: OSPF learns 10.2.0.0/24 (AD 110) ! Backup path: static with AD 200 R1(config)# ip route 10.2.0.0 255.255.255.0 10.99.99.2 200 ``` | Time | OSPF state | Active route | |---|---|---| | Normal | Up | OSPF (AD 110) wins | | OSPF link fails | Down | Static (AD 200) takes over | | OSPF recovers | Up | OSPF (AD 110) wins again | The floating static "floats" — present in the config always, but only inserted into the routing table when the better source disappears. Use cases: - Backup WAN link (primary = MPLS via OSPF; backup = LTE via static) - Failover to a different egress router - Maintenance-window simulation (administratively bump primary AD, watch static take over) **Critical:** specify the AD. Static's default AD is 1 — beats everything. A "backup" static with default AD = 1 becomes the primary path. ## Administrative Distance — the AD ladder When the same prefix is learned from multiple sources, the router compares AD first. **Lower AD wins.** | Source | AD | |---|---| | Connected | 0 | | Static | **1** | | EIGRP summary route | 5 | | External BGP (eBGP) | 20 | | Internal EIGRP | 90 | | IGRP (legacy) | 100 | | OSPF | 110 | | IS-IS | 115 | | RIP | 120 | | External EIGRP | 170 | | Internal BGP (iBGP) | 200 | | Unreachable | 255 | You'll be quizzed on the order in interviews and on the CCNA exam. Memorize the connected → static → eBGP → EIGRP → OSPF → RIP → iBGP ladder. See [Routing Decision Process](/topics/routing-decision-process/) for the full process. ## Recursive lookup — what happens behind the scenes When you write: ``` ip route 10.2.0.0 255.255.255.0 10.0.1.2 ``` The router does: 1. Packet arrives destined for `10.2.0.0/24`. 2. Routing table says: "via `10.0.1.2`." 3. Router needs to know how to reach `10.0.1.2`. Look up `10.0.1.2` in the routing table. 4. Finds: `10.0.1.0/30 is directly connected, Gi0/1`. 5. ARP for `10.0.1.2` on `Gi0/1`. Get the MAC. 6. Build the Ethernet frame and send. The lookup for `10.0.1.2` is the **recursive lookup**. If the routing table can't find the next-hop, the static route is removed from the route table (still in running-config, but not active). This is why "next-hop unreachable" is the #1 cause of "my static route isn't showing up." Always verify next-hop reachability first. ## Summary routes (poor-man's summarization with statics) You can advertise a static summary by writing a single static for a large block: ``` R1(config)# ip route 10.0.0.0 255.255.0.0 Null0 ``` Black-holes anything in `10.0.0.0/16` not matched by a more specific route. Used for: - BGP origination — advertise a summary you "own" without route flapping when child prefixes flap. - Loop prevention — prevent traffic from leaving your network for prefixes that shouldn't exist. The `Null0` is a virtual "drop" interface. Combined with a more specific route to the real next-hop, you get summarization with safety: ``` R1(config)# ip route 10.0.0.0 255.255.0.0 Null0 R1(config)# ip route 10.0.1.0 255.255.255.0 10.0.99.2 R1(config)# ip route 10.0.2.0 255.255.255.0 10.0.99.2 ``` If a packet arrives for `10.0.5.5` (which doesn't have a specific route), it hits the `/16` to Null0 and drops — no loop, no upstream confusion. ## IPv6 static routes Syntax mirrors IPv4 with `ipv6 route` and prefix notation: ``` R1(config)# ipv6 unicast-routing ! enable IPv6 routing globally R1(config)# ipv6 route 2001:db8:2::/64 2001:db8:1::2 ! next-hop R1(config)# ipv6 route 2001:db8:2::/64 GigabitEthernet0/0 ! exit interface R1(config)# ipv6 route ::/0 2001:db8:1::1 ! default route R1(config)# ipv6 route 2001:db8:3::/64 2001:db8:9::2 200 ! floating static ``` Verification: ``` R1# show ipv6 route R1# show ipv6 route static ``` All the same principles — next-hop, exit-interface, AD, floating — work identically. ## Configuration patterns — production-quality ``` ! With description for traceability R1(config)# ip route 10.2.0.0 255.255.255.0 10.0.1.2 name BRANCH-2-PRIMARY ! With description + AD for floating backup R1(config)# ip route 10.2.0.0 255.255.255.0 10.99.99.2 200 name BRANCH-2-BACKUP ! Default route via primary ISP R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 name DEFAULT-PRIMARY-ISP ! Floating default via backup ISP R1(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 200 name DEFAULT-BACKUP-ISP ! Black-hole an internal summary R1(config)# ip route 10.0.0.0 255.255.0.0 Null0 name ENTERPRISE-SUMMARY ``` The `name` keyword adds a human-readable description visible in `show ip route` — small touch, big help during outage debugging. ## Verification ``` R1# show ip route R1# show ip route static R1# show ip route 10.2.0.0 R1# show ip route 10.2.0.5 ! shows actual route for a specific IP R1# show ip cef R1# show ip cef 10.2.0.5 R1# show running-config | include ip route ``` `show ip route 10.2.0.5` is the daily-driver — type any destination IP and the router tells you exactly which route would be used. `show ip cef` (Cisco Express Forwarding) shows the FIB (Forwarding Information Base) — the hardware-accelerated forwarding table. Useful when you suspect software-vs-hardware forwarding inconsistencies. ## The 5-step static-routing debug When a static route "isn't working": 1. **Is the route in the running-config?** `show running-config | include ip route`. If not, you never saved it or there was a typo. 2. **Is the route in the routing table?** `show ip route static`. If in running-config but not in the route table → next-hop unreachable. Verify with `ping `. 3. **Mask correct?** `ip route 10.2.0.0 255.255.255.0` matches `10.2.0.0/24`. If the destination is `/23`, you wrote the wrong mask. 4. **Higher-priority route exists for the same prefix?** `show ip route ` — what AD won? If another protocol learned the same prefix at lower AD, your static is shadowed. 5. **Recursive lookup OK?** If the next-hop is several hops away, can the router get there? `show ip route ` and walk the chain. ## Worked scenarios --- **Scenario 1.** R1 needs to reach `192.168.50.0/24`. Next-hop is `10.0.0.2` on R1's Ethernet. Write the static route. **Answer:** ``` R1(config)# ip route 192.168.50.0 255.255.255.0 10.0.0.2 ``` --- **Scenario 2.** R1 has two paths to `10.5.0.0/24`: a primary via OSPF (AD 110) and a backup via static. You want the static to only kick in when OSPF fails. AD for the floating static? **Answer:** Any AD > 110. Common choice: 200. Anything from 111–254 works. AD 255 means unreachable (the route never installs). --- **Scenario 3.** A static route appears in `show running-config` but not in `show ip route`. The next-hop is `10.0.0.2`. What's wrong? **Answer:** The router can't reach `10.0.0.2` via any other route. Either the interface in that subnet is down, the next-hop IP is wrong, or there's no path to that next-hop at all. Test with `ping 10.0.0.2` from the router. --- **Scenario 4.** You configured `ip route 10.2.0.0 255.255.255.0 Serial0/0/0` on an Ethernet-attached router (no Serial interfaces at all). What happens? **Answer:** The static route never installs because `Serial0/0/0` doesn't exist. Use next-hop IP on Ethernet, or specify the correct interface. --- **Scenario 5.** R1 has a default route `ip route 0.0.0.0 0.0.0.0 203.0.113.1`. It also has a static for `10.0.0.0/8 via 10.99.99.2`. A packet arrives for `10.1.5.5`. Which route wins? **Answer:** The `/8` static. Longest-prefix match wins. `10.1.5.5` matches `10.0.0.0/8` (8 bits matching) and matches `0.0.0.0/0` (0 bits matching). `/8` > `/0`, so the more specific wins regardless of order in the config. --- **Scenario 6.** You want every router in the network to have a default route, but only the edge router has internet uplink. Most reliable approach? **Answer:** Two options: 1. **Manual:** Static `ip route 0.0.0.0 0.0.0.0 ` on every router, pointing at the next hop toward the edge. 2. **Better:** OSPF with `default-information originate` on the edge router — OSPF propagates the default to all neighbors automatically. The second scales better and adapts to topology changes; the first requires touching every router on edits. --- **Scenario 7.** A router has these two statics: ``` ip route 10.0.0.0 255.255.0.0 Null0 ip route 10.0.5.0 255.255.255.0 10.99.0.5 ``` A packet arrives for `10.0.6.10`. Where does it go? **Answer:** Null0 (the summary). `10.0.6.10` falls in `10.0.0.0/16` but not in `10.0.5.0/24`. Longest-prefix match → only the `/16` matches → packet hits Null0 and drops. This is the deliberate "loop-prevention summary" pattern. --- **Scenario 8.** You're configuring a floating static as backup for a primary route via EIGRP (AD 90). You write: ``` ip route 10.5.0.0 255.255.255.0 10.99.0.5 90 ``` Will this behave as a floating backup? **Answer:** No. With AD 90 (same as EIGRP), both routes have equal AD — the router may load-balance or be unpredictable. Use any AD > 90, typically 200, to make it strictly a backup. ## Common mistakes 1. **Wrong mask.** Writing `255.255.255.0` when the destination is a /16 means the route never matches. Double-check. 2. **Pointing to a next-hop that isn't reachable.** Route appears in `show running-config` but never in `show ip route`. Test next-hop reachability first. 3. **Using exit-interface on Ethernet without a next-hop.** Causes the router to ARP for every destination IP. Use next-hop on Ethernet, or fully-specified. 4. **Forgetting AD on a floating static.** Without an AD higher than the primary protocol's, both routes get equal weight and traffic load-balances unintentionally. 5. **Leaving floating static AD = 1.** Default AD for static is 1 — beats everything. If you don't specify a higher AD, your "backup" static overrides OSPF/EIGRP as the primary. 6. **Routing loops via reciprocal statics.** R1 says "10.2.0.0 via R2", R2 says "10.2.0.0 via R1." Packets bounce between them until TTL expires. Always trace routes end-to-end. 7. **No `ipv6 unicast-routing` for IPv6 statics.** IPv6 routes won't activate without the global enable, even if you've configured everything else. 8. **Forgetting that `Null0` drops packets, not "doesn't route them."** A summary to Null0 black-holes anything not matched by more specific entries. Intended for some designs; a surprise for others. 9. **Static default with no upstream connectivity check.** Static defaults don't track health. If the next-hop is alive but the path beyond it is broken, traffic still gets forwarded to a black hole. Combine with IP SLA + `track` to make a static health-aware: ``` R1(config)# ip sla 1 R1(config-ip-sla)# icmp-echo 8.8.8.8 source-interface Gi0/1 R1(config-ip-sla)# frequency 5 R1(config)# ip sla schedule 1 start-time now life forever R1(config)# track 1 ip sla 1 reachability R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1 ``` Now the default route is only installed when IP SLA confirms `8.8.8.8` is reachable. 10. **Hard-coding next-hops that change.** ISP-provided IPs may change. Use BGP if your upstream is multi-homed or large-scale; static only when the next-hop is fixed. ## Lab to try tonight 1. **Three-router line** — HQ in the middle, BR1 left, BR2 right. /30 links. LAN behind each branch. 2. **Configure statics on HQ** — reach BR1 LAN (`10.1.0.0/24`) and BR2 LAN (`10.2.0.0/24`). Test with `show ip route` and `ping`. 3. **Default routes on the branches** — each branch points its default to HQ. Verify with `show ip route 0.0.0.0`. 4. **Branch-to-branch traffic** — verify BR1 can reach BR2 via HQ (transit through HQ). 5. **Floating backup** — bring up a direct BR1↔BR2 link. Add a floating static on each branch with AD 200 pointing directly at the other branch. Verify it doesn't install while the primary (default through HQ) is healthy. 6. **Failure test** — `shutdown` the HQ↔BR2 link. Watch the floating static kick in. BR1↔BR2 traffic now goes directly. 7. **Recovery** — `no shutdown`. Watch primary re-take over, floating static deactivate. 8. **Null0 summary** — on HQ, add `ip route 10.0.0.0 255.0.0.0 Null0` as a black-hole summary. Confirm that any packet for an unassigned `10.x.x.x` falls into Null0. 9. **IP SLA-tracked default** — configure an IP SLA pinging an internet target. Tie the default route's installation to the track object. Block the internet target with an ACL — watch the default route disappear. 10. **Bonus: IPv6 static** — enable `ipv6 unicast-routing` on all three. Add IPv6 statics to mirror the IPv4 ones. Verify with `show ipv6 route`. ## Cheat strip | Need | Syntax | |---|---| | Static route (next-hop) | `ip route 10.2.0.0 255.255.255.0 10.0.1.2` | | Static route (exit interface) | `ip route 10.2.0.0 255.255.255.0 Serial0/0/0` | | Fully-specified | `ip route 10.2.0.0 255.255.255.0 Gi0/0 10.0.1.2` | | Default route | `ip route 0.0.0.0 0.0.0.0 ` | | Floating static (backup) | `ip route ... ` where AD > primary protocol AD | | Named route | `ip route ... name ` | | Black-hole summary | `ip route 10.0.0.0 255.0.0.0 Null0` | | IPv6 static | `ipv6 route 2001:db8::/64 ` | | Common AD values | Connected=0 · Static=1 · eBGP=20 · EIGRP=90 · OSPF=110 · RIP=120 · iBGP=200 | | Verify | `show ip route static` or `show ip route ` | | Remove | `no ip route ...` | | With IP SLA tracking | `ip route 0.0.0.0 0.0.0.0 track ` | | Recursive lookup | Next-hop must itself be reachable — chains until directly-connected | | `Gateway of last resort` | Phrase in `show ip route` that confirms a default exists | | When to use static | ≤3 routers · stub branches · defaults · floating backups | | When NOT to use | Anywhere dynamic routing fits — won't recover from failures | ## Frequently asked questions **Q: When should I use static routing instead of a dynamic protocol?** A: When the topology is stable and small — a small branch site with one WAN link, or a stub network where there's nothing to learn. Also for a default route pointing at the ISP (very common). Dynamic routing (OSPF, EIGRP, BGP) is worth the CPU cost as soon as you have redundancy, multiple sites, or frequent topology changes — statics don't recompute paths when a link fails. **Q: What's a default route?** A: A route matching everything (destination `0.0.0.0/0` in IPv4 or `::/0` in IPv6) — the "if nothing else matches, send it here" route. Almost every router has one, pointing at the next hop toward the internet. Configure with `ip route 0.0.0.0 0.0.0.0 `. Also called the "gateway of last resort" in `show ip route` output. **Q: What's the difference between a next-hop IP and an exit interface in a static route?** A: `ip route 10.0.0.0 255.0.0.0 192.168.1.1` (next-hop IP) tells the router "send this to that neighbour" — the router resolves the next-hop's MAC via ARP. `ip route 10.0.0.0 255.0.0.0 Serial0/0` (exit interface) tells the router "send this out that interface" — on point-to-point links this is fine; on Ethernet it triggers proxy-ARP for every destination, which is wasteful. Best practice on multi-access (Ethernet) links: always specify next-hop IP. **Q: What happens if I have both a static route and OSPF for the same prefix?** A: The static route wins because its administrative distance (AD) is 1 vs OSPF's 110 — lower AD is preferred. This is why manual statics can silently break dynamic routing: someone leaves a debug static in place, an OSPF path fails, and the fallback via OSPF never activates because the static is still "better" from the routing table's perspective. Use `ip route ... 254` (a "floating static" with higher AD) if you want the static to only be used when the dynamic route fails. **Q: How do I remove a static route?** A: `no ip route` followed by the same arguments used to add it. `no ip route 10.0.0.0 255.0.0.0 192.168.1.1` removes the exact route. If you don't remember the exact next-hop, `show run | include ip route 10.0.0.0` shows all matching lines. Removing a route doesn't remove any dynamic-protocol-learned version — those are still in the routing table. --- ## BPDU Guard & Root Guard — https://packetmentor.com/topics/bpdu-guard-root-guard/ > Two Spanning Tree security features that protect your STP topology from misconfiguration and rogue switches. BPDU Guard locks user-facing ports; Root Guard pins the root bridge so a misplaced switch can't hijack it. ## Mental model Spanning Tree's correctness depends on every switch agreeing on a single root bridge and stable port roles. Two ways this gets broken: 1. **Someone plugs a switch into a user-facing access port.** The new switch sends BPDUs. STP recalculates. Topology destabilizes. Sometimes the new switch even wins the root election if its bridge ID happens to be lower — now traffic flows through some random switch in a meeting room. 2. **A downstream switch tries to become root.** Whether by accident (someone hardcoded a low priority) or attack (someone trying to force traffic through their device), an unexpected switch claiming root status can hijack your topology. **BPDU Guard fixes #1. Root Guard fixes #2.** Both are essential in production switching environments. ## BPDU Guard — protect access ports The premise: PCs, printers, IP phones, IoT — none of them send BPDUs. So if a port that should connect only to end devices ever receives a BPDU, **something is wrong**. Maybe someone connected a switch. Maybe a misconfigured device. Either way, the safe response is to shut the port. BPDU Guard does exactly that: any BPDU on a protected port → err-disable the port immediately. ### Where it goes On every access port that has **PortFast** enabled: ``` SW1(config-if)# switchport mode access SW1(config-if)# spanning-tree portfast ! skip listening/learning SW1(config-if)# spanning-tree bpduguard enable ! shut on BPDU ``` PortFast + BPDU Guard is the standard combo. PortFast skips STP states for instant forwarding on access ports; BPDU Guard catches anyone abusing that. ### Global default You can enable both globally so every PortFast port automatically gets BPDU Guard: ``` SW1(config)# spanning-tree portfast bpduguard default SW1(config)# spanning-tree portfast default ``` Now every access port with PortFast also has BPDU Guard, automatically. Best practice. ## Root Guard — pin the root bridge The premise: you've deliberately chosen a root bridge (e.g. a core switch with `spanning-tree vlan 1 root primary`). You don't want some downstream switch — a closet switch, a user-deployed device — claiming better priority and becoming root. Root Guard protects this by inspecting BPDUs **arriving** on a designated port. If an incoming BPDU is "superior" (better priority than the current root's), Root Guard **blocks the port** rather than letting it influence root election. The port enters a special **root-inconsistent** state. Once the superior BPDUs stop arriving, the port recovers automatically (no manual intervention). ### Where it goes On ports facing **downstream** switches — switches that should never be root: ``` SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# spanning-tree guard root ``` That's it. The port now refuses to let anything "better" through it. ### When it kicks in ``` *Mar 1 12:34:56: STP: VLAN0010 Gi0/24 received superior BPDU, blocked by root guard *Mar 1 12:35:01: STP: VLAN0010 Gi0/24 root guard inconsistent (no superior BPDUs for 30s, recovering) ``` First message: blocked. Second message: superior BPDUs stopped, port recovers automatically. ## When to use each | Port type | BPDU Guard | Root Guard | |---|---|---| | Access port (PCs, phones, IoT) | ✓ | ✗ | | Trunk to downstream switch (closet, distribution) | ✗ | ✓ | | Trunk to upstream switch (where root might be) | ✗ | ✗ | BPDU Guard is binary — *no BPDUs allowed here at all*. Use on access ports. Root Guard is conditional — *BPDUs OK, but they better not be better than the current root*. Use on downstream-facing trunks. ## BPDU Filter — the dangerous cousin There's also **BPDU Filter**, which silently drops BPDUs without err-disabling. It sounds safer but it's not — it lets a connected switch operate as if it's a loop-free endpoint, which can cause real loops if the connection forms a loop. **BPDU Filter is dangerous. Avoid it.** BPDU Guard is the right tool. ``` ! NEVER do this on access ports SW1(config-if)# spanning-tree bpdufilter enable ! silent drop — DON'T ``` The one legitimate use of BPDU Filter: on ports that genuinely need to never send/receive BPDUs (rare service-provider edge cases). For 99% of CCNA-level networks, don't. ## Recovery from err-disable BPDU Guard puts the port in `err-disable`. Recovery options: ### Manual ``` SW1(config)# interface Gi0/5 SW1(config-if)# shutdown SW1(config-if)# no shutdown ``` ### Auto-recovery ``` SW1(config)# errdisable recovery cause bpduguard SW1(config)# errdisable recovery interval 300 ! 5 minutes ``` After 5 minutes, the port comes back up automatically. If the offending BPDUs are still arriving, it shuts again. Cycles until someone investigates. ## Common mistakes 1. **PortFast on a trunk port.** PortFast is for access ports only. A trunk in PortFast mode is a loop waiting to happen. The default config prevents this on Catalyst, but mis-applied `spanning-tree portfast trunk` on a real trunk = bad. 2. **BPDU Guard without PortFast.** Pointless — non-PortFast access ports go through listening/learning anyway, so a BPDU during that time is normal. Together they form the bundle. 3. **Root Guard on an upstream port facing the actual root.** Now your switch refuses to learn the legitimate root. Catastrophic. Apply Root Guard only on **downstream** ports. 4. **Forgetting err-disable recovery.** A momentary BPDU arrival → port permanently down until someone notices. Configure recovery (with caution — don't auto-recover if the cause is unclear). 5. **Confusing BPDU Guard and BPDU Filter.** BPDU Guard shuts on BPDU. BPDU Filter silently drops. Guard is safe; Filter is dangerous. Test before deploying either. 6. **No documentation.** When the port flaps to err-disable at 3 AM, the on-call engineer needs to know "this is BPDU Guard — someone connected an unauthorized switch." Document the policy. ## Lab to try tonight 1. One switch, two PCs on access ports, plus a spare switch for testing. 2. Configure PortFast + BPDU Guard on the access ports: ``` interface range Gi0/1 - 24 switchport mode access spanning-tree portfast spanning-tree bpduguard enable ``` 3. Plug PC into Gi0/1. Verify it works. 4. Replace PC with the spare switch. Watch Gi0/1 err-disable as soon as the spare switch sends a BPDU. 5. Confirm: `show interfaces status err-disabled` and the logs. 6. Restore: `shut` then `no shut`. Or configure `errdisable recovery cause bpduguard`. 7. Now apply Root Guard on a trunk: `spanning-tree guard root`. 8. From the downstream switch, force a low bridge priority that would otherwise win root election. Verify Root Guard blocks the port and logs `root guard inconsistent`. ## Cheat strip | Concept | Plain English | |---|---| | **BPDU Guard** | Access port + PortFast — err-disable on any BPDU | | **Root Guard** | Downstream trunk — block port if superior BPDU arrives | | **BPDU Filter** | Silently drop BPDUs. **Dangerous — avoid.** | | **PortFast** | Skip STP listening/learning — instant forwarding on access ports | | **`spanning-tree portfast bpduguard default`** | Global — enable both on all PortFast ports | | **`spanning-tree guard root`** | Per-interface — block port if it would change root | | **err-disable recovery** | Auto-recover after N seconds | | **root-inconsistent** | Special Root Guard state — recovers when superior BPDUs stop | --- ## Default Routing — https://packetmentor.com/topics/default-routing/ > The catch-all route every edge router needs. Covers static defaults, dynamic defaults (originated by OSPF/EIGRP/BGP), gateway of last resort, and the difference between a default and a summary route. ## Mental model A router's routing table is a list of "if destination matches X, send to Y" rules. The **most specific match wins**. So if you have: ``` 10.0.0.0/24 via R2 0.0.0.0/0 via R-ISP ``` A packet to `10.0.0.5` matches the first rule (more specific). A packet to `8.8.8.8` doesn't match the first, falls through to the second. The second rule — `0.0.0.0/0` — matches **everything**. It's the catch-all. Almost every edge router needs one, because no edge router knows every public-internet route (that's hundreds of thousands of entries). A default route is also called the **gateway of last resort**. ## Two ways to install a default route ### Method 1 — static default route The classic. Just type it in: ``` R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 ``` Read aloud: *"for any destination, send to 203.0.113.1."* Simple, reliable, used on 99% of branch and home routers. Verify: ``` R1# show ip route 0.0.0.0 Gateway of last resort is 203.0.113.1 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 203.0.113.1 ``` The `S*` means "static route, candidate default." The `*` is what matters — it's the candidate of last resort. ### Method 2 — let a routing protocol distribute it In larger networks, only the edge router (which faces the ISP) has the real default. Internal routers learn it via OSPF or EIGRP. **With OSPF:** ``` R-edge(config)# router ospf 1 R-edge(config-router)# default-information originate ``` This makes R-edge tell its OSPF neighbors *"I have a default route, send me anything unknown."* Internal routers install the default with `O*E2` in their tables. **With EIGRP:** ``` R-edge(config)# router eigrp 100 R-edge(config-router)# redistribute static ``` Or, on older IOS: ``` R-edge(config)# ip default-network 192.168.1.0 ``` ## Default route vs summary route These two get confused: - **Default route** = 0.0.0.0/0 — matches everything when nothing else does. - **Summary route** = aggregating many specific routes into one less-specific entry. E.g. `10.0.0.0/8` summarizing 10.1.0.0/24 + 10.2.0.0/24 + ... Both are less specific than alternatives, but a default matches *everything* not otherwise routed. A summary still only matches a defined range. ## Floating default — the backup If your primary internet path can die, install a second default with higher administrative distance — it kicks in only when the primary disappears: ``` R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1 ! primary, AD 1 R1(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1 100 ! backup, AD 100 ``` While the primary is up, only it shows in `show ip route`. When it fails, the backup automatically appears. ## Verification ``` R1# show ip route R1# show ip route 0.0.0.0 R1# show ip route 8.8.8.8 ! shows which route actually matches a specific destination ``` The third one is the most useful for troubleshooting: ask the router exactly which route it would use for a specific destination IP. ## Common mistakes 1. **Pointing the default to an unreachable next-hop.** If `203.0.113.1` isn't reachable from R1, the default appears in `show running-config` but never installs into `show ip route`. Test reachability first. 2. **Multiple defaults with same AD = unintentional load-balancing.** Two `ip route 0.0.0.0 0.0.0.0` statements with AD 1 each, pointing at different ISPs → traffic load-balances. Sometimes wanted, sometimes not. Specify distinct AD for active/backup. 3. **Default route loops.** R1's default points to R2. R2's default points to R1. Any unknown destination ping-pongs between them until TTL expires. Always trace defaults end-to-end. 4. **Forgetting `default-information originate` in OSPF.** Putting a static default on the edge router doesn't automatically share it via OSPF. Add the originate command, or internal routers won't know. 5. **Wrong subnet/mask spelling.** `ip route 0.0.0.0 0.0.0.0 ...` is the default. `ip route 0.0.0.0 255.0.0.0 ...` is **not** a default — it's a static for the 0.0.0.0/8 range, which doesn't really exist. Easy typo, hard to spot. 6. **Default route in MPLS L3VPN customer-facing.** When the provider runs OSPF/EIGRP/BGP with you, your default should come from them, not from you originating one to them. Coordination matters. ## Lab to try tonight 1. One router connected to a "fake ISP" (another router with a public-IP loopback). Internal LAN behind R1. 2. Configure a static default route on R1 pointing to the ISP. Verify with `show ip route 0.0.0.0`. 3. From the LAN, ping the ISP's public IP. Should work. 4. Remove the default. Ping again. Should fail with "Destination host unreachable." 5. Restore the default. Add a backup default with AD 100 pointing to a different ISP. Verify both appear in running-config; only the primary is in `show ip route`. 6. Shut the primary's outgoing interface. Watch the backup default appear in `show ip route`. Bring back the primary, watch the backup disappear. 7. Bonus: configure OSPF area 0 between R1 and an internal router R2. On R1, add `default-information originate`. Verify R2 learns the default with `O*E2`. ## Cheat strip | Concept | Plain English | |---|---| | **0.0.0.0/0** | The default route. Matches anything. | | **Gateway of last resort** | Same thing, different name | | **Most specific match wins** | More specific routes always beat the default | | **S\*** | Static candidate default in `show ip route` | | **O\*E2** | OSPF-learned default (external type 2) | | **default-information originate** | OSPF command to share your default with neighbors | | **Floating default** | Backup default with higher AD | | **AD (Admin Distance)** | Lower = more trustworthy. Static=1, OSPF=110, RIP=120. | --- ## Catalyst Boot Process — https://packetmentor.com/topics/catalyst-boot-process/ > What happens between powering on a Cisco device and the prompt appearing. Covers POST, ROMMON, IOS image selection, config register, boot variables, and password recovery. ## Mental model Every Cisco device boots through the same sequence: 1. **Power on** — hardware spins up. 2. **POST** (Power-On Self-Test) — checks RAM, CPU, ports, ASICs. 3. **ROMMON** (ROM Monitor) — minimal bootloader, locates IOS image. 4. **IOS load** — image copied from flash into RAM, decompressed, started. 5. **Config load** — startup-config copied from NVRAM into RAM as running-config. 6. **Operational** — CLI prompt appears. If any step fails, the boot stops there. Knowing the stages tells you where to look when a device won't come up. ## The four storage locations | Storage | What lives there | Persists on reload? | |---|---|---| | **ROM** | ROMMON bootloader + diagnostic image | Yes (firmware) | | **Flash** | IOS image file(s) — e.g. `c2960x-universalk9-mz.152-7.E3.bin` | Yes | | **NVRAM** | startup-config | Yes | | **RAM** | running-config + IOS process state | **No — lost on power off** | The bootflash on modern Catalyst switches is large enough to hold multiple IOS images. Older devices had just enough flash for one image + a bit of headroom for upgrades. ## The config register — boot behavior in one hex value The **config register** is a 16-bit value (shown in hex) that controls boot behavior. Default on most modern Cisco IOS: ``` R1# show version ... Configuration register is 0x2102 ``` Two bits matter for CCNA: - **Bits 0–3 (boot field)** — where to load IOS from: - `0x0` → stay in ROMMON - `0x1` → load mini-IOS from ROM - `0x2–0xF` → check boot system commands, fall back to first valid image in flash - **Bit 6** — **skip startup-config**: - `0` (default) → load startup-config - `1` → ignore startup-config (device boots with empty config) Common values: | Value | Meaning | |---|---| | **0x2102** | Default — normal boot, load startup-config | | **0x2142** | Skip startup-config (used for password recovery) | | **0x2100** | Boot to ROMMON only | Change it with: ``` R1(config)# config-register 0x2142 R1# reload ``` After reload, the device boots without loading the startup-config — letting you recover from a forgotten password. ## Boot system commands When the boot field is 0x2–0xF, IOS looks at `boot system` commands in the startup-config to decide which image to load. Multiple lines = ordered fallback: ``` R1(config)# boot system flash:c2960x-universalk9-mz.152-7.E3.bin R1(config)# boot system flash:c2960x-universalk9-mz.152-7.E0.bin R1(config)# boot system rom ``` Tries the first image. If missing/corrupt, tries the second. If both fail, falls back to the ROM-resident mini-IOS (limited functionality, just enough to recover). If no `boot system` commands exist, IOS loads the first valid image file it finds in flash. ## Password recovery — the practical use of 0x2142 Forgot the enable password? Process: 1. Console into the device. 2. Power cycle. Press **Ctrl+Break** during boot to interrupt and land in ROMMON. 3. From ROMMON, change the config register: `confreg 0x2142` 4. `reset` to reboot. Device now boots **without** the startup-config. 5. Enter privileged mode (no password — running-config is empty). 6. `copy startup-config running-config` — load the saved config back (now you have access). 7. Reset passwords as needed. 8. Restore normal boot: `config-register 0x2102` 9. `copy running-config startup-config` 10. `reload` Console access required (it's the rescue path). Without physical access, you can't do this — which is also why physical security of network equipment matters. ## Boot sequence troubleshooting What it looks like when things go wrong at each stage: | Symptom | Likely stage failing | |---|---| | Device totally dead, no LEDs | Power supply or hardware | | LEDs cycling, no console output | POST failure (hardware) | | `rommon 1 >` prompt | ROMMON loaded but no IOS — image missing or corrupt | | `boot:` prompt | Boot loader can't find image — check `boot system` | | Boots but prompt is `(Initial config dialog?)` | NVRAM blank — no startup-config | | Boots but missing features | Wrong IOS image — installed image lacks needed feature set | ## Commands — observe the boot environment ``` R1# show version ! IOS version, uptime, config-register, boot image R1# show flash: ! list IOS files in flash R1# show bootvar ! current boot variables R1# show running-config | include boot R1# dir flash: ! same as show flash:, longer format ``` `show version` is the single most useful "what's going on with this device" command. It shows hardware model, IOS version, uptime, reason for last reload, and config register — answer to "is this thing healthy?" in one screen. ## Image management — upgrades Upgrade flow: ``` ! Copy new image from TFTP server to flash R1# copy tftp: flash: ! Set boot variable to use new image R1(config)# boot system flash:c2960x-universalk9-mz.152-7.E4.bin ! Save and reload R1# wr R1# reload ``` Always **keep the old image** as a fallback. Don't delete it until the new one's been running stable for a week+. For newer Catalyst 9000 series running IOS-XE, the process is more sophisticated — `install` commands, packaged software (.bin or .pkg), and multiple boot modes (install vs bundle). ## Common mistakes 1. **Forgetting to save the config register change.** `config-register 0x2102` after password recovery — without it, the next reload still skips startup-config. 2. **No `boot system` commands when needed.** If you have multiple IOS images and don't specify, IOS picks the first valid file alphabetically. Surprising results. 3. **Pulling power during a flash upgrade.** Bricks the device. Always use UPS, never power-cycle during firmware install. 4. **Filling flash to 100%.** No room for upgrade images. Always keep ~30% headroom. 5. **Console access "not needed because we have SSH."** Until SSH doesn't work and you need to do password recovery. Always maintain console access. 6. **Mistaking the boot stages.** "It's stuck at ROMMON" vs "stuck at IOS load" vs "stuck at config load" — different stages, different fixes. Read the symptom carefully. ## Lab to try tonight 1. Cable up a Cisco switch with a console cable. Watch the boot in your terminal. 2. Identify each stage: POST messages, ROMMON banner, IOS load, config application. 3. From the running device: `show version`. Note the config register. 4. From the running device: `show bootvar` and `show flash:`. 5. Power-cycle. Press Ctrl+Break during ROMMON. Run `confreg 0x2142`. Reset. 6. Watch it boot without your config. Enable mode, no password. 7. `copy start run` to restore. Note: never `copy run start` here — you'd save the empty config! 8. Reset config-register back to 0x2102. `wr`. Reload. ## Cheat strip | Concept | Plain English | |---|---| | **POST** | Self-test on power on | | **ROMMON** | Bootloader. Minimal CLI. Used for password recovery. | | **IOS image** | In flash. Loaded into RAM. | | **startup-config** | In NVRAM. Loaded into RAM as running-config. | | **running-config** | In RAM. Lost on power off (unless saved). | | **0x2102** | Default config register — normal boot | | **0x2142** | Skip startup-config — password recovery | | **`boot system flash:...`** | Which image to load (multiple lines = fallback) | | **`show version`** | One-stop overview of hardware + boot state | | **Console access** | Required for password recovery. Never lose it. | --- ## Routing Decision Process — https://packetmentor.com/topics/routing-decision-process/ > How a router actually decides where to forward a packet. Longest prefix match, administrative distance, and metric — in that order. Covers why a /30 static beats a /16 OSPF even though OSPF is the better protocol. ## Mental model When a packet arrives at a router, the router asks a series of questions to decide where to send it. The order matters more than people realize: 1. **Longest prefix match** — among all routes that could reach the destination, pick the most specific (highest CIDR number). 2. **Administrative distance** — among routes with the same prefix length, pick the one from the most trusted source (lowest AD). 3. **Metric** — among routes with the same prefix length AND same source, pick the cheapest one. This is the entire decision-making process. Memorize the order — it explains every "why is my router doing X" mystery you'll meet. ## Why longest match comes first ``` Destination: 10.1.1.5 Routes in the table: 10.0.0.0/8 via R2 [OSPF — AD 110] 10.1.0.0/16 via R3 [OSPF — AD 110] 10.1.1.0/24 via R4 [Static — AD 1] ``` All three routes could deliver to 10.1.1.5. But **the /24 is more specific** than /16 or /8. The /24 wins, regardless of AD. If you had: ``` 10.1.1.0/24 via R4 [Static — AD 1] 10.1.1.4/30 via R5 [OSPF — AD 110] ``` The /30 (4 IPs) beats the /24 (256 IPs) for `10.1.1.5`, even though OSPF's AD is way higher than static's. **More specific always wins.** ## Administrative distance (AD) — the "trust score" When two protocols both have the same prefix, AD decides which to install in the routing table. Lower = more trusted. | Source | AD | |---|---| | Connected interface | 0 | | Static route | 1 | | EBGP | 20 | | EIGRP (internal) | 90 | | OSPF | 110 | | RIP | 120 | | EIGRP (external) | 170 | | IBGP | 200 | | Unreachable | 255 | Memorize the common ones: Connected=0, Static=1, OSPF=110, RIP=120. If R1 learns `10.0.0.0/24` from OSPF (AD 110) and also from RIP (AD 120), only the OSPF route is installed. RIP's version stays in its protocol database but never enters `show ip route`. ## Metric — when AD ties If two routes have the same prefix AND the same protocol (so same AD), the protocol's own metric breaks the tie: | Protocol | Metric | |---|---| | OSPF | Cost (`reference-bandwidth / interface-bandwidth`, summed across path; Cisco default reference = 100 Mbps = 10⁸ bps, so a 100 Mbps link costs 1) | | EIGRP | Composite of bandwidth + delay | | RIP | Hop count | | Static | None — first-configured wins | Two OSPF paths to the same destination with costs 4 and 10? The cost-4 path is installed; the cost-10 sits in the LSDB but isn't used unless the cost-4 fails. Equal-cost paths can both install (ECMP — equal-cost multi-path), giving you free load balancing. ## What "installed in the routing table" means ``` R1# show ip route 10.1.1.0/24 [110/20] via R3 10.1.0.0/16 [110/15] via R2 ``` The `[110/20]` is `[AD/metric]` — the candidates that won. Other learned routes don't appear here at all. To see them in the protocol's internal database: ``` R1# show ip ospf database R1# show ip eigrp topology ``` ## Floating static — using AD as a knob Static's default AD is 1, beating everything. But you can artificially raise it: ``` R1(config)# ip route 10.0.0.0 255.255.255.0 10.99.99.2 200 ``` That AD of 200 means: this static loses to OSPF (AD 110). It's a **floating static** — only used if OSPF disappears. Common backup pattern. See [Static Routing](/topics/static-routing/) for the deep dive. ## Commands ### Trace exactly which route a router would use ``` R1# show ip route 10.1.1.5 Routing entry for 10.1.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 192.168.1.2 Route metric is 0, traffic share count is 1 ``` The most useful single command for routing troubleshooting. Tells you the route, AD, metric, and next-hop the router actually picked. ### Compare protocol databases ``` R1# show ip route ! installed routes R1# show ip ospf database ! everything OSPF knows R1# show ip eigrp topology ! everything EIGRP knows R1# show ip protocols ! routing-protocol summary ``` ## Common mistakes 1. **Assuming AD beats prefix length.** It doesn't. Longest match is always checked first. A /30 static beats a /16 OSPF. 2. **Confusing metric across protocols.** OSPF cost 10 and EIGRP metric 30,000 aren't comparable — they're different units. AD decides which protocol wins; metric only matters within the same protocol. 3. **Expecting `show ip route` to show everything.** Only installed routes appear there. To see candidates that lost, check the protocol-specific database. 4. **Forgetting floating static's AD.** A backup static with no AD specified defaults to AD 1 and becomes the primary path. Always specify AD on backup statics. 5. **Misreading `[AD/metric]`.** People sometimes think both numbers are arbitrary identifiers. Left = administrative distance, right = metric. Both lower-is-better. 6. **Not understanding ECMP.** When two routes tie on all three criteria, both install. Traffic load-balances. If you expected only one path, check `show ip route` for multiple `via X` lines. ## Lab to try tonight 1. Three routers. R1 connected to R2 and R3. R2 and R3 both reach 10.2.2.0/24 directly. 2. Configure OSPF between R1, R2, R3. Verify R1 sees two OSPF routes to 10.2.2.0/24 (one via R2, one via R3). 3. Run `show ip route 10.2.2.0` — observe ECMP (equal-cost multi-path). 4. Configure a static route on R1: `ip route 10.2.2.0 255.255.255.0 ` (no AD specified). 5. Re-check `show ip route 10.2.2.0`. The static beats both OSPF routes (AD 1 vs 110). Both OSPF paths disappear. 6. Remove the static. Re-add with AD 200. Now OSPF wins, static stays dormant. 7. Bonus: add a more specific static for `10.2.2.0/28`. Now both routes coexist — /28 for traffic to .0-.15, /24 for the rest. ## Cheat strip | Step | Question | What wins | |---|---|---| | 1 | Which route is most specific? | Highest prefix length (/30 > /24 > /16 > /8 > /0) | | 2 | Same prefix — which protocol? | Lowest AD | | 3 | Same AD — which path? | Lowest metric | | **Default ADs** | Static=1, OSPF=110, RIP=120, EIGRP=90, Connected=0 | | **ECMP** | Same AD + same metric = both install, load-balance | | **`show ip route X`** | The fastest way to ask "what would the router do for X?" | --- ## TFTP and FTP: Network File Transfer Basics — https://packetmentor.com/topics/tftp-ftp-basics/ > The two file-transfer protocols the CCNA expects you to know — TFTP (UDP/69, one-shot config uploads) and FTP (TCP/20 + 21, larger IOS images). When to use which, and the copy commands that move files between flash and a remote server. > **Scope note:** this page covers the **protocols themselves** — how TFTP and FTP work on the wire, when to pick each. For the Cisco-side `copy … tftp:` / `copy … flash:` commands, `boot system`, and the flash / nvram / system: file-systems, see the companion topic → [Cisco IOS File System](/topics/ios-file-system/). ## Mental model Cisco devices need to move files: pushing a config to a TFTP server for backup, pulling a new IOS image from an FTP server, receiving a firmware upgrade. Both TFTP and FTP have been around since the 1980s, and they're both still on the exam because IOS still uses them under `copy`. **Rule of thumb:** if the file is small and the network is trusted, use TFTP. If the file is large or the network is untrusted, use FTP (or SCP/SFTP — but those are outside CCNA scope). ## TFTP vs FTP at a glance | Feature | TFTP | FTP | |---|---|---| | **Transport** | UDP/69 | TCP/21 (control) + TCP/20 (data, active) | | **Auth** | None | Username + password (plaintext) | | **Directory listing** | No | Yes (`ls`, `dir`) | | **File size** | Ideally < 32 MB (older impls capped at 32 MB) | Multi-GB | | **Reliability** | ACK per data block (512 B lock-step) | TCP handles it | | **Encryption** | No | No (SFTP/FTPS add it) | | **Firewall friendliness** | Single UDP port — easy | Two ports, plus active vs passive mode complexity | | **Typical use** | Router configs, small IOS images, PXE boot, VoIP phone TFTP option 150 | Larger IOS images, backups when auth is required | ## TFTP in a Cisco lab (the CCNA path) You'll almost always set up a TFTP server on a management workstation (Windows: Tftpd64 / SolarWinds TFTP; Linux: `tftpd-hpa`; Cisco DevNet: pre-loaded on Packet Tracer's server object) and then: ``` R1# copy running-config tftp: Address or name of remote host []? 10.0.99.5 Destination filename [R1-confg]? !! 4128 bytes copied in 0.512 secs ``` Reverse direction — pull a config or IOS image: ``` R1# copy tftp: flash: Address or name of remote host []? 10.0.99.5 Source filename []? c2900-universalk9-mz.SPA.158-3.M2.bin Destination filename [c2900-universalk9-mz.SPA.158-3.M2.bin]? Accessing tftp://10.0.99.5/... !!!!!!!! [OK - 33591768 bytes] ``` Every `!` is one successfully-ACKed 512-byte block. A `.` means a retransmit — a small handful is normal, a wall of dots means you're losing packets and should investigate the path. ## FTP in a Cisco lab FTP needs credentials. Set them globally so `copy` can pick them up: ``` R1(config)# ip ftp username admin R1(config)# ip ftp password Sup3rS3cret ``` Then: ``` R1# copy ftp: flash: Address or name of remote host []? 10.0.99.5 Source filename []? images/c2900-universalk9-mz.SPA.158-3.M2.bin Destination filename [c2900-universalk9-mz.SPA.158-3.M2.bin]? Loading images/c2900-universalk9-mz.SPA.158-3.M2.bin ... [OK - 33591768 bytes] ``` Real IOS also supports SCP (`ip scp server enable`) — outside CCNA scope but the go-to for anything production. ## The "which mode" FTP quirk (worth knowing) FTP has two data-channel modes: - **Active** — server initiates the data connection back to the client on client-chosen port. Firewalls hate this; NAT and stateful firewalls need FTP inspection to punch the hole. - **Passive (PASV)** — client initiates BOTH connections. Firewall-friendly, default on modern clients. IOS's `copy ftp:` uses passive by default. Nothing to configure — but if your topic asks *"why doesn't active FTP work through NAT?"* the answer is *the server's inbound data connection can't traverse the client-side NAT without FTP inspection*. ## PXE boot + TFTP — the DHCP option 66/150 pattern TFTP is what boots diskless devices (thin clients, VoIP phones, network appliances). The device DHCP-requests an IP, and the DHCP server hands back: - Option 66 (`next-server`) — the TFTP server IP - Option 67 (`filename`) — which file to fetch - Option 150 (Cisco-specific) — TFTP server list for Cisco IP phones See the [DHCP topic](/topics/dhcp/) for the option syntax. ## The #1 mistake **Using TFTP over a routed WAN.** TFTP has no encryption, no meaningful auth, and its lock-step ACK model tanks throughput once round-trip time exceeds a few ms. It's great LAN-side (management network, direct connection), a bad choice across a firewall or over VPN. Reach for FTP (or SCP) when the path isn't a single L2 hop. ## Verify a transfer went well ``` R1# dir flash: Directory of flash:/ 1 -rw- 33591768 Aug 9 2026 08:14:22 c2900-universalk9-mz.SPA.158-3.M2.bin 2 -rw- 2072 Mar 1 1993 00:05:12 cpconfig-2960.cfg 3 -rw- 856 Mar 1 1993 00:05:15 config.text 256000000 bytes total (162385920 bytes free) R1# verify /md5 flash:c2900-universalk9-mz.SPA.158-3.M2.bin .......................... verify /md5 (flash:c2900-universalk9-mz.SPA.158-3.M2.bin) = 6b3f95f2d0a4c7b1e9f3d8a2c5e6f9b1 ``` Compare the MD5 against the value Cisco published for the image — if they don't match, the image is corrupt or a middleman changed it. Never `boot system` an unverified image. --- ## FHRP — HSRP, VRRP & GLBP — https://packetmentor.com/topics/fhrp-hsrp/ > First-hop redundancy protocols. How two routers share one virtual IP so hosts don't notice when their default gateway fails. Covers HSRP states, election, preemption, and the GLBP load-balancing twist. ## Mental model Hosts on a LAN are configured with one default gateway — typically a single IP. If that gateway router dies, every host on the LAN is suddenly cut off until someone reconfigures the gateway. Bad. **FHRP (First-Hop Redundancy Protocol)** is the workaround. Two physical routers share a **virtual IP** that hosts use as the gateway. The active router answers ARP for that virtual IP. The standby sits quietly watching. If the active fails, the standby takes over the virtual IP within seconds — hosts never know anything changed. Three flavors you'll meet: | Protocol | Origin | Active routers | Load balancing | |---|---|---|---| | **HSRP** | Cisco-proprietary | 1 active, others standby | No (unless you split groups) | | **VRRP** | IETF open standard | 1 master, others backup | No | | **GLBP** | Cisco-proprietary | All active simultaneously | Yes — same virtual IP, different MACs | For CCNA: **HSRP is what gets tested most**. VRRP is conceptually identical with different terminology. GLBP is mentioned but rarely deep. ## HSRP — the dominant CCNA topic Two routers form an **HSRP group** (numbered 1–255). The group has a virtual IP and virtual MAC. Hosts use the virtual IP as their gateway. ### Priority + preemption — who's active Each router has an HSRP **priority** (1–255, default 100). Higher priority becomes active. If priorities tie, higher IP wins. ``` R1(config-if)# standby 1 priority 110 ``` But just having higher priority isn't enough — by default, HSRP doesn't auto-fail-back. If R1 boots first and becomes active, then R2 boots and has higher priority, **R2 won't take over unless preemption is enabled**: ``` R1(config-if)# standby 1 preempt ``` Set preempt on both routers, with priority on the preferred-active one. ### States (the lifecycle) A router moves through these as it joins: ``` Disabled → Init → Listen → Speak → Standby → Active ``` The two that matter day-to-day: - **Active** — the router currently answering for the virtual IP - **Standby** — the runner-up, ready to take over If you see a router stuck in `Listen` or `Speak` permanently, it's a misconfiguration (priority/preemption issue, group mismatch). ## Commands — HSRP basic config ``` ! On R1 (active) R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 10.0.0.2 255.255.255.0 R1(config-if)# standby version 2 R1(config-if)# standby 1 ip 10.0.0.1 ! the virtual IP R1(config-if)# standby 1 priority 110 ! higher than default 100 R1(config-if)# standby 1 preempt ! On R2 (standby) R2(config)# interface GigabitEthernet0/0 R2(config-if)# ip address 10.0.0.3 255.255.255.0 R2(config-if)# standby version 2 R2(config-if)# standby 1 ip 10.0.0.1 ! same virtual IP, same group # R2(config-if)# standby 1 priority 100 ! default — lower R2(config-if)# standby 1 preempt ``` **Always use `standby version 2`.** Version 2 supports more groups and uses a different virtual MAC range — required for modern features. ### Interface tracking — failover when an upstream link dies What if R1's WAN-facing interface dies but its LAN-facing interface is still up? Without help, R1 stays active — but it can't actually reach the internet. Hosts pointing at the virtual IP get a black hole. **Object tracking** monitors a tracked interface and adjusts priority when it goes down: ``` R1(config)# track 1 interface GigabitEthernet0/1 line-protocol R1(config-if)# standby 1 track 1 decrement 20 ``` If Gi0/1 goes down, R1's HSRP priority drops by 20 (from 110 to 90) — below R2's 100 — and R2 takes over. ## Verification ``` R1# show standby R1# show standby brief R1# show standby vlan 10 ! when running per-VLAN HSRP ``` `show standby brief` is the daily-driver — shows the group, virtual IP, current state, priority, and preempt status in one screen. ## VRRP — same idea, open standard ``` R1(config-if)# ip address 10.0.0.2 255.255.255.0 R1(config-if)# vrrp 1 ip 10.0.0.1 R1(config-if)# vrrp 1 priority 110 ``` VRRP differs from HSRP in three ways worth knowing: 1. **The master uses the actual virtual IP** as one of its real IPs by default. (HSRP uses a separate virtual IP.) 2. **Multicast addresses differ** (HSRP: 224.0.0.2, VRRP: 224.0.0.18). 3. **Vendor-agnostic**, so VRRP works between Cisco and non-Cisco routers. ## GLBP — when you want load balancing In HSRP/VRRP, the standby router sits doing nothing 99% of the time. GLBP fixes this: **all routers in the group are active simultaneously**, and hosts get different MACs for the same virtual IP — so traffic load-balances across the routers. ``` R1(config-if)# glbp 1 ip 10.0.0.1 R1(config-if)# glbp 1 priority 110 ``` GLBP elects an **AVG** (Active Virtual Gateway) which assigns **AVF** (Active Virtual Forwarder) roles. Cisco-only. Less commonly tested on CCNA but worth recognizing. ## Common mistakes 1. **Different HSRP groups on each router for the same VLAN.** Both routers need to be in the same group (same number). Mismatch → both stay Active independently, hosts get inconsistent gateways. 2. **Forgetting preempt.** Configure priority but not preempt → router with priority 110 still doesn't take over from a router with 100. Add preempt on both. 3. **Different virtual IPs configured on the two routers.** They must match exactly. Easy typo, hard to spot. 4. **No tracking of upstream.** Setting priority + preempt without tracking means HSRP fails over only when the actual LAN-facing interface dies — not when the WAN-facing interface dies. Always add tracking. 5. **Using HSRP version 1 in 2026.** Version 1 supports only 256 groups per interface and uses old virtual MAC formats. Always use `standby version 2`. 6. **Different timers between routers.** Hello / hold timers must match: `standby 1 timers 1 3`. Both ends. ## Lab to try tonight 1. Two routers (R1, R2), one LAN switch, two PCs. 2. Configure both routers with IPs in 10.0.0.0/24 (R1=.2, R2=.3). Both reach the same upstream. 3. Configure HSRP group 1, virtual IP 10.0.0.1, R1 priority 110, R2 priority 100, preempt on both. 4. Set both PCs' default gateway to 10.0.0.1. Ping anywhere external — works through R1. 5. Run `show standby brief` — R1 should be Active. 6. Shut R1's LAN interface. Watch R2 take over within seconds. Pings continue. 7. Re-enable R1. Watch R2 give Active back to R1 (because of preempt + priority). 8. Bonus: configure object tracking on R1's upstream interface. Shut it. Confirm R2 takes over (priority decrement working). ## Cheat strip | Concept | Plain English | |---|---| | **FHRP** | First-Hop Redundancy Protocol — shared gateway IP for failover | | **HSRP** | Cisco-proprietary. CCNA's default FHRP topic. | | **VRRP** | IETF open standard. Cross-vendor. | | **GLBP** | Cisco-only. Load-balances by handing out different MACs. | | **Virtual IP** | The IP hosts use as their gateway | | **Active / Standby** | HSRP states (Master / Backup in VRRP) | | **Priority** | 1–255, higher wins (default 100) | | **Preempt** | Required to actually let a higher-priority router take over | | **Tracking** | Lower priority when an upstream interface dies | | **Version 2** | Always use this on modern HSRP | ## Frequently asked questions **Q: What's the actual difference between HSRP, VRRP, and GLBP?** A: HSRP is Cisco-only. VRRP is the open IETF standard (RFC 5798) — works between Cisco, Juniper, Arista, etc. GLBP is Cisco-only and load-balances traffic across active routers (unlike HSRP/VRRP where one router is active). CCNA scope: HSRP is the deep-dive; VRRP + GLBP are recognition-level. **Q: Why does preempt matter so much?** A: Without preempt, priority is only checked at initial election. If R1 (priority 110) is active and fails, R2 (priority 100) takes over. R1 recovers — but stays as standby forever unless preempt is enabled. Six months later when R2 actually fails, everyone's surprised the "primary" has no traffic. Always configure preempt. **Q: What is HSRP interface tracking?** A: It watches an interface (usually the WAN uplink); if the tracked interface goes down, HSRP drops the local priority by a configured amount. Perfect for "router alive but no path out" scenarios. Without tracking, HSRP happily forwards traffic into a black hole. **Q: What does the virtual MAC address tell me?** A: HSRPv1 virtual MAC is `0000.0c07.acXX` where XX = group number in hex. HSRPv2 is `0000.0c9f.fXXX`. So `0000.0c07.ac01` = HSRPv1 group 1. This is a classic CCNA exam question — memorize the two prefixes. **Q: Should I use HSRPv1 or HSRPv2?** A: HSRPv2 unless you have a specific reason to stay on v1. v2 supports IPv6, 4096 groups (vs 255 in v1), and cleaner MD5 authentication. On modern IOS, HSRPv2 is a one-line change: `standby version 2`. **Q: What is a common cause of HSRP flapping?** A: Interface flap on a tracked interface, or hello timers set too aggressively. Also unicast issues if you skipped the `standby 1 timers msec 250 750` and the LAN has any packet loss. Look at `show standby brief` and `show standby internal` for state-change history. **Q: How does HSRP compare to a Layer-3 anycast setup?** A: Anycast (advertising the same IP from multiple routers via a routing protocol) is a modern data-center pattern that HSRP predates. In campus / branch, HSRP is still the default because clients don't run routing protocols. Anycast in a hospital or data center is fine because everything routes. ## What to learn next - **Deep-dive comparison**: [FHRP Comparison — HSRP vs VRRP vs GLBP](/topics/fhrp-comparison/). - **Try it live**: [HSRP Failover Simulator](/simulators/hsrp/) — kill routers + WAN uplinks and watch failover behavior in real time. - **Related blog**: [HSRP walkthrough — how default gateway redundancy actually works](/blog/hsrp-explained/). - **Next topic**: [Static routing done right](/topics/static-routing/) — often paired with HSRP for the outbound-from-HSRP path. --- ## SPAN, RSPAN & ERSPAN — Port Mirroring — https://packetmentor.com/topics/span-port-mirroring/ > How to copy traffic from one switch port to another for analysis. Covers local SPAN, RSPAN across switches via VLAN, ERSPAN over GRE for remote sites, and when each one is the right call. ## Mental model Switches forward frames only out the destination port — they're efficient that way. But sometimes you need to **see** the traffic for troubleshooting, security analysis, or compliance recording. Plugging Wireshark into an arbitrary port doesn't help — that port only sees its own frames. **SPAN (Switched Port Analyzer)** is Cisco's port-mirroring feature. The switch copies traffic from one or more source ports (or VLANs) to a designated destination port. The analyzer plugged into the destination port sees everything happening on the sources. Three flavors: | Feature | Where copies go | Use case | |---|---|---| | **SPAN** (local) | Another port on the *same* switch | Standalone troubleshooting | | **RSPAN** (Remote) | A dedicated VLAN spanning *multiple switches* | Centralized analyzer for a building | | **ERSPAN** (Encapsulated Remote) | Wrapped in GRE, sent across the routed network | Cloud analyzers, remote SOC | ## SPAN — local ``` SW1(config)# monitor session 1 source interface GigabitEthernet0/1 SW1(config)# monitor session 1 source interface GigabitEthernet0/2 SW1(config)# monitor session 1 destination interface GigabitEthernet0/24 ``` Now everything traveling on Gi0/1 and Gi0/2 (both directions by default) is also copied to Gi0/24. The destination port is **read-only** for the analyzer — it stops forwarding normal traffic. Direction options: ``` SW1(config)# monitor session 1 source interface Gi0/1 rx ! only inbound SW1(config)# monitor session 1 source interface Gi0/1 tx ! only outbound SW1(config)# monitor session 1 source interface Gi0/1 both ! default ``` You can also mirror entire VLANs: ``` SW1(config)# monitor session 1 source vlan 10 SW1(config)# monitor session 1 destination interface Gi0/24 ``` ## RSPAN — across multiple switches When the analyzer isn't on the same switch as the source, RSPAN extends SPAN across the network using a **dedicated RSPAN VLAN**. ``` ! On every switch in the path — create the RSPAN VLAN SW1(config)# vlan 999 SW1(config-vlan)# remote-span SW1(config-vlan)# exit ! Source switch SW1(config)# monitor session 1 source interface Gi0/1 SW1(config)# monitor session 1 destination remote vlan 999 ! Destination switch (where the analyzer lives) SW2(config)# monitor session 1 source remote vlan 999 SW2(config)# monitor session 1 destination interface Gi0/24 ``` The RSPAN VLAN must be allowed on every trunk between source and destination switches. ## ERSPAN — across routed networks When the analyzer is in a different IP subnet (cloud, remote SOC, central data center), RSPAN's VLAN-trunk requirement won't work. **ERSPAN** wraps mirrored traffic in **GRE** so it can ride over any routed path. ``` ! Source side SW1(config)# monitor session 1 type erspan-source SW1(config-mon-erspan-src)# source interface Gi0/1 SW1(config-mon-erspan-src)# destination SW1(config-mon-erspan-src-dst)# erspan-id 100 SW1(config-mon-erspan-src-dst)# ip address 10.99.99.10 ! analyzer IP SW1(config-mon-erspan-src-dst)# origin ip address 10.0.0.1 ! sender IP ! Destination side (the analyzer's switch) SW2(config)# monitor session 1 type erspan-destination SW2(config-mon-erspan-dst)# destination interface Gi0/24 SW2(config-mon-erspan-dst)# source SW2(config-mon-erspan-dst-src)# erspan-id 100 SW2(config-mon-erspan-dst-src)# ip address 10.99.99.10 ``` ERSPAN adds GRE header overhead (~50 bytes) — be mindful of MTU on the path. Heavy SPAN traffic over a constrained WAN can saturate. ## Verification ``` SW1# show monitor ! list all sessions SW1# show monitor session 1 ! detail for one session SW1# show monitor session 1 detail ``` Confirm: source ports, destination port, direction, session number. Easy to fat-finger. ## Common mistakes 1. **Source = destination same port.** Configuring a port as both source and destination → switch refuses or behaves weirdly. They must be different ports. 2. **Connecting an analyzer expecting normal traffic too.** Destination ports stop forwarding normal traffic. Don't plug a printer into a SPAN destination. 3. **Forgetting that the analyzer needs to handle the full traffic volume.** Mirroring two 1 Gbps ports → up to 2 Gbps copies to the destination. If the analyzer port is also 1 Gbps, drops happen. Use a faster destination port or sample. 4. **RSPAN VLAN not allowed on a transit trunk.** The mirror traffic is silently dropped between switches. Always verify the RSPAN VLAN is in the `switchport trunk allowed vlan` list on every transit trunk. 5. **ERSPAN MTU not configured.** GRE overhead pushes mirrored packets over the network's MTU → fragmentation or drops. Set `mtu` appropriately on the ERSPAN destination interface. 6. **Forgetting that SPAN copies aren't the same as the original.** Some VLAN tag information may be stripped depending on the source-port type (access vs trunk). For exact-fidelity capture, mirror a trunk port and use a SPAN-friendly analyzer. ## Lab to try tonight 1. One switch. PC-A on Gi0/1 (legitimate traffic). PC-B on Gi0/2 (also legitimate). Wireshark laptop on Gi0/24. 2. Configure: `monitor session 1 source interface Gi0/1` + `monitor session 1 destination interface Gi0/24`. 3. Generate traffic from PC-A. Capture on the Wireshark laptop. Verify you see PC-A's traffic. 4. Add Gi0/2 as a second source. Generate traffic from PC-B. Wireshark sees that too. 5. Try plugging an extra normal device into Gi0/24. Note: it can't communicate normally — destination ports are essentially "Wireshark only." 6. Bonus: RSPAN across two switches. Create the RSPAN VLAN, configure source on SW1 and destination on SW2, verify traffic from SW1 reaches the Wireshark laptop on SW2. ## Cheat strip | Concept | Plain English | |---|---| | **SPAN** | Local port mirroring on one switch | | **RSPAN** | Mirror across multiple switches via dedicated VLAN | | **ERSPAN** | Mirror across routed networks via GRE encapsulation | | **Source** | The port (or VLAN) being monitored | | **Destination** | Where the analyzer is connected. Read-only for normal traffic. | | **Direction** | rx / tx / both — default both | | **`monitor session N`** | The command structure for SPAN sessions | | **Use cases** | Wireshark, IDS, security recording, compliance | | **MTU caveat** | ERSPAN adds GRE overhead — watch path MTU | --- ## GRE Tunnels — https://packetmentor.com/topics/gre-tunnels/ > How to make two distant routers feel directly connected by wrapping IP inside IP. Covers tunnel interface config, MTU caveats, why GRE itself isn't encrypted, and the standard 'GRE over IPsec' combination. ## Mental model You have two routers separated by the public internet. You want them to feel like they're directly connected with a private link — so you can run OSPF between them, route between private subnets, send multicast, etc. **GRE (Generic Routing Encapsulation)** is the trick. Each router has a virtual `Tunnel0` interface that, when you put a packet in, wraps it in another IP header and shoots it across the internet to the other router. That router unwraps and forwards normally. ``` Inner packet: [ IP: 10.1.0.5 → 10.2.0.10 ][ TCP / payload ] After GRE: [ IP: pubA → pubB ][ GRE hdr ][ IP: 10.1.0.5 → 10.2.0.10 ][ TCP / payload ] ^^ added by GRE encapsulation ``` The outer IP uses the routers' public addresses. The inner IP is whatever the original packet was — private addresses, IPv6, whatever. The internet's routers see only the outer addressing. ## Two things GRE is good at, one thing it's not | | Capability | |---|---| | ✓ | Carries **any Layer-3 protocol** — IPv4, IPv6, multicast, AppleTalk, IPX | | ✓ | **Multicast / OSPF / EIGRP** can run inside (they need a directly-connected link feel) | | ✗ | **No encryption** — contents are visible to anyone on the path | That last point is why you almost always pair GRE with IPsec: - **GRE-over-IPsec** = GRE first, then IPsec wraps the GRE - IPsec gives encryption, GRE gives multicast support and protocol flexibility Pure IPsec can encrypt unicast IP, but doesn't natively carry multicast / OSPF — which is why GRE + IPsec is the standard combo for site-to-site VPNs that need internal routing protocols. ## Configuration — minimal GRE tunnel ``` ! R-A (one side of the tunnel) R-A(config)# interface Tunnel0 R-A(config-if)# ip address 10.99.99.1 255.255.255.252 ! tunnel IPs (private) R-A(config-if)# tunnel source 198.51.100.1 ! my public IP R-A(config-if)# tunnel destination 203.0.113.50 ! their public IP R-A(config-if)# tunnel mode gre ip ! default — explicit for clarity ! R-B (other side — mirror) R-B(config)# interface Tunnel0 R-B(config-if)# ip address 10.99.99.2 255.255.255.252 R-B(config-if)# tunnel source 203.0.113.50 R-B(config-if)# tunnel destination 198.51.100.1 R-B(config-if)# tunnel mode gre ip ``` Now `10.99.99.1` and `10.99.99.2` can ping each other through the tunnel — and the tunnel rides whatever internet path connects 198.51.100.1 and 203.0.113.50. ### Add routes to use the tunnel A static route pointing the remote private network through the tunnel: ``` R-A(config)# ip route 10.2.0.0 255.255.255.0 10.99.99.2 R-B(config)# ip route 10.1.0.0 255.255.255.0 10.99.99.1 ``` Or run OSPF over the tunnel: ``` R-A(config)# router ospf 1 R-A(config-router)# network 10.99.99.0 0.0.0.3 area 0 R-A(config-router)# network 10.1.0.0 0.0.0.255 area 0 ``` OSPF forms a neighborship across the tunnel as if R-A and R-B were directly connected. Pure IPsec can't do that — GRE makes it possible. ## MTU — the gotcha everyone hits GRE adds 24 bytes of overhead (20-byte outer IP + 4-byte GRE header). The inner packet's effective MTU drops: ``` Default MTU: 1500 - GRE overhead: -24 - IPsec overhead (if used): -52 (typical) = Effective MTU inside tunnel: ~1424 ``` If the inner packet is 1500 bytes with Don't-Fragment set, the router must fragment it after encapsulation, and many networks block fragmented IPsec. Users see "everything works except large transfers" — classic MTU symptom. Fix: ``` R-A(config-if)# ip mtu 1400 R-A(config-if)# ip tcp adjust-mss 1360 ! shrink TCP MSS for hosts ``` `ip tcp adjust-mss` is especially useful — the router rewrites TCP MSS in passing SYNs so endpoints negotiate a small-enough segment size. No user reconfiguration needed. ## Verification ``` R-A# show interfaces Tunnel0 R-A# show ip route ! routes via tunnel R-A# ping 10.99.99.2 ! is the tunnel up? R-A# show ip protocols ! OSPF running over tunnel ``` `show interfaces Tunnel0` confirms the tunnel state — `up/up` means good. `up/down` usually means the tunnel destination is unreachable (verify with a `ping` to the destination's public IP). ## GRE over IPsec — the standard combo In production you almost always want encryption. Two ways to combine: **Tunnel-mode IPsec (encrypts the GRE-wrapped packet):** ``` crypto isakmp policy 10 encr aes authentication pre-share group 14 crypto isakmp key supersecret address 203.0.113.50 crypto ipsec transform-set TS-AES esp-aes 256 esp-sha256-hmac crypto ipsec profile MYPROFILE set transform-set TS-AES interface Tunnel0 ip address 10.99.99.1 255.255.255.252 tunnel source 198.51.100.1 tunnel destination 203.0.113.50 tunnel protection ipsec profile MYPROFILE ! the magic line ``` `tunnel protection ipsec` is the modern way — encrypts the tunnel without separate crypto-map ACL drudgery. ## Common mistakes 1. **Forgetting MTU adjustment.** Tunnel works for ping but breaks for HTTPS, file transfers, video. Always set `ip mtu` and `ip tcp adjust-mss` on the tunnel interface. 2. **Recursive routing loops.** Tunnel source/destination are public IPs. If the router's routing table sends those public IPs **through the tunnel itself**, you've created a loop. Symptom: `%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing`. Fix: ensure tunnel endpoints are reachable via the underlying internet path, not via the tunnel. 3. **Identical tunnel interfaces on both sides (e.g. both /32).** Use a small /30 or /31 — both ends need IPs in the same subnet. 4. **Trying to run multicast over IPsec without GRE.** IPsec doesn't natively carry multicast. Wrap in GRE first. 5. **Skipping `tunnel mode gre ip`.** Default on Cisco IOS, but explicit is clearer. Other modes exist (`ipv6`, `ipsec ipv4`, `gre multipoint`) and the wrong one fails silently. 6. **Trusting GRE alone for sensitive data.** GRE is plain text on the wire. Anyone capturing on the path can read everything. Always layer with IPsec for production. ## Lab to try tonight 1. Two routers in CML or any IPsec-capable simulator with "public" links between them and private LANs behind. 2. Configure GRE Tunnel0 on both sides (without IPsec first). 3. Confirm tunnel comes up: `show interfaces Tunnel0` → `up/up`. Ping between tunnel IPs. 4. Configure static routes through the tunnel. Verify end-to-end ping from LAN-A to LAN-B. 5. Run OSPF area 0 across the tunnel. Confirm OSPF neighbor adjacency forms over Tunnel0. 6. Now layer in IPsec with `tunnel protection ipsec profile`. Wireshark the public link and confirm ESP packets only (no inner addressing visible). 7. Set `ip mtu 1400` and test large-file transfer behavior. ## Cheat strip | Concept | Plain English | |---|---| | **GRE** | Wraps IP inside IP — creates virtual point-to-point links | | **Tunnel source / destination** | The routers' public IPs | | **Tunnel interface** | Virtual L3 interface, gets its own IP | | **No encryption** | GRE is plain text. Use IPsec for privacy. | | **GRE over IPsec** | The standard combo for site VPNs with internal routing | | **MTU caveat** | Set `ip mtu 1400` and `ip tcp adjust-mss 1360` | | **Recursive routing** | Avoid sending tunnel destination through the tunnel itself | | **OSPF works** | Routing protocols run inside the tunnel as if directly connected | | **`tunnel protection ipsec`** | Modern way to add IPsec encryption to a GRE tunnel | --- ## VTP — VLAN Trunking Protocol — https://packetmentor.com/topics/vtp/ > Cisco's protocol for sharing VLAN config across switches in the same VTP domain. Powerful, dangerous, and the reason every CCNA engineer learns the value of `vtp mode transparent`. ## Mental model If you have 50 switches and need to add VLAN 100 to all of them, you have two options: 1. SSH to each one and type `vlan 100; name USERS`. Tedious. 2. Configure VLAN 100 on one switch and have it auto-propagate to the others. **That's VTP.** The convenience comes with risk: if a switch joining the network has a higher VTP **revision number**, its VLAN database overwrites everyone else's. A misplaced switch from a lab → entire production VLAN database wiped → every access port reverts to VLAN 1. Big outage. For CCNA: know VTP exists, how it works, and why most production networks run **`vtp mode transparent`** (each switch maintains its own VLAN database, no auto-sync) instead. ## The roles | Mode | Can create / modify VLANs? | Receives updates? | Forwards updates? | |---|---|---|---| | **Server** | Yes | Yes | Yes | | **Client** | No | Yes | Yes | | **Transparent** | Yes (locally) | No | Forwards (but doesn't apply) | | **Off** | Yes (locally) | No | No | **Server** is the source-of-truth. **Client** receives. **Transparent** does its own thing but passes VTP through to others. **Off** is total isolation. ## The dangerous revision number Every change to the VLAN database on a Server (or Transparent) switch increments its **revision number**. When a Client receives a VTP update, it compares the revision number with its own. **Higher number wins** — the Client's database gets overwritten. The disaster scenario: 1. Engineer powers up a lab switch that was previously in production, with revision number 47. 2. Connects it to a trunk in production. Production VTP is at revision 35. 3. Production switches see the higher number, accept the lab switch's (empty) VLAN database. 4. Every access port in the production network suddenly thinks its VLAN doesn't exist → no traffic forwards. This has happened many times. The fix: always set `vtp mode transparent` on any switch before plugging it in. Or reset its VTP revision to 0 by changing the domain name briefly. ## VTP versions | Version | Notes | |---|---| | **v1** | Original. Limited features. Avoid. | | **v2** | Adds Token Ring + some bug fixes. CCNA default-tested. | | **v3** | Major improvement. Adds primary/secondary server, supports VLANs 1-4094, MST, password protection. Safer. | **VTPv3 is what you'd actually deploy in 2026.** It has a "primary server" concept — only one switch is authoritative, others can't accidentally override. Still many environments run v1/v2 from inertia. ## Commands ``` ! Set the VTP domain (must match on all switches) SW1(config)# vtp domain CORP ! Set mode SW1(config)# vtp mode server ! default SW1(config)# vtp mode client SW1(config)# vtp mode transparent SW1(config)# vtp mode off ! Set version (v2 or v3 — affects feature support) SW1(config)# vtp version 2 ! Optional — password SW1(config)# vtp password supersecret ! VTPv3 primary server (only this switch can change VLANs in the domain) SW1# vtp primary ``` ### Verify ``` SW1# show vtp status SW1# show vtp counters SW1# show vtp password ``` Key fields in `show vtp status`: - **VTP Operating Mode**: Server / Client / Transparent / Off - **VTP Domain Name**: must match neighbors - **Configuration Revision**: the number that determines who wins - **Number of existing VLANs**: how many VLANs this switch knows about ## Resetting the revision number If you need to safely add a switch to an existing VTP domain, **reset its revision number to 0 first**. Three ways: ``` ! Method 1 — change the domain name briefly (revision resets) SW1(config)# vtp domain TEMPORARY SW1(config)# vtp domain CORP-REAL ! Method 2 — change to transparent and back SW1(config)# vtp mode transparent SW1(config)# vtp mode client ! Method 3 — wipe vlan.dat (requires reload) SW1# delete flash:vlan.dat SW1# reload ``` Always do this **before** connecting the switch to a production trunk. ## Why production often runs transparent The "convenience vs blast radius" calculation. Pros of running everything in transparent mode: - No risk of revision-number-based wipeout - Each switch's VLAN database is local — explicit and auditable - Forced to update VLANs via config-management automation (Ansible, etc.) — generally healthier than relying on auto-propagation Cons: - Have to add VLANs on every switch separately (or via automation) In modern networks with config management, transparent is the safer default. Auto-propagation of critical config across switches is a 2005-era convenience that doesn't fit current best practices. ## VTP Pruning A different VTP feature: **pruning** removes VLAN broadcast / unknown-unicast traffic from trunks that don't carry any access ports for that VLAN. Saves bandwidth. ``` SW1(config)# vtp pruning ``` Pruning is generally safer than VLAN propagation — manage allowed VLAN lists on trunks explicitly instead. ## Common mistakes 1. **Adding a lab switch to production without resetting revision.** Wipes the production VLAN database. Has burned every CCNA learner at some point. 2. **VTP domain name mismatch.** Two switches with different domain names won't exchange VTP info. Common after a config copy-paste mistake. 3. **Running VTP servers everywhere.** Defeats the point — any one of them can become the canonical source by being changed. Run one or two servers max; the rest as clients (or transparent in modern setups). 4. **Forgetting password mismatch.** Two switches in the same domain but with different VTP passwords → updates ignored. `show vtp password` to verify. 5. **Confusing VTP with DTP.** **VTP** synchronizes VLAN databases. **DTP** (Dynamic Trunking Protocol) negotiates trunk vs access mode between switches. Different things — both Cisco-proprietary, both can be disabled. 6. **Trusting VTP to never break things.** Mistakes happen. Always have a recent backup of running-configs and the VLAN database (`show vlan brief` saved somewhere). ## Lab to try tonight 1. Three switches connected via trunks. Same VTP domain `CORP`. 2. Configure SW1 as server, SW2 and SW3 as clients. 3. On SW1, create VLAN 10, 20, 30. Verify with `show vlan brief`. 4. On SW2 and SW3, run `show vlan brief` — the same VLANs appear automatically. 5. On SW2 (client), try `vlan 99`. Should fail — clients can't create VLANs. 6. **The dangerous experiment:** disconnect SW3, configure a totally different VLAN list on it locally, manually set a high revision (or change & change back the domain to bump it up), then reconnect to the trunk. Watch the production VLANs disappear. Restore from backup. 7. Bonus: convert everything to `vtp mode transparent`. Note each switch now maintains its own DB. Add a VLAN on each individually. ## Cheat strip | Concept | Plain English | |---|---| | **VTP** | Auto-share VLAN database between switches | | **Server** | Source of truth — can add/modify VLANs | | **Client** | Receives. Can't make changes. | | **Transparent** | Local DB only. Forwards VTP for others but ignores it. | | **Revision number** | Higher wins. Cause of catastrophic accidents. | | **VTPv3** | Adds primary-server safety net. Use over v1/v2 if you must run VTP. | | **Pruning** | Different VTP feature — removes unnecessary VLAN traffic from trunks | | **Production default** | `vtp mode transparent` is the safest choice in 2026 | --- ## Layer-3 Switch & SVI Routing — https://packetmentor.com/topics/layer3-switch-svi/ > How a Layer-3 switch routes between VLANs at line rate using SVIs (Switched Virtual Interfaces) — the modern replacement for router-on-a-stick in any campus network. ## Mental model Router-on-a-stick (covered in [Inter-VLAN Routing](/topics/inter-vlan-routing/)) routes between VLANs by trunking every VLAN over a single physical link to an external router. It works — until you have 50 VLANs and 10 Gbps of inter-VLAN traffic. Then the router CPU melts. A **Layer-3 switch** solves this. It's a switch chassis with both: - a normal Layer-2 forwarding plane (MAC table, VLAN tagging, STP), and - a Layer-3 forwarding plane (route table, IP forwarding) implemented in the **ASIC** — at line rate. The Layer-3 switch *is* the router for every VLAN it carries. Hosts use the switch itself as their default gateway. The L3 interface for each VLAN is called an **SVI** — Switched Virtual Interface. It's a logical interface (not tied to a physical port) created with `interface Vlan`. Once you give it an IP and the VLAN exists, the switch can route packets out of that VLAN. ## SVI vs routed port — know the difference | Type | Created by | Used for | Example | |---|---|---|---| | **SVI** (`interface VlanX`) | `interface Vlan10` | Gateway for hosts in VLAN 10 | Campus access-layer to distribution | | **Routed port** (`no switchport`) | `interface Gi1/0/24` + `no switchport` | Point-to-point L3 link to another router/L3 switch | Uplink to core, OSPF/EIGRP neighbor | A routed port is a physical port acting like a router interface (no VLAN, no switching, just routing). You use routed ports for L3-to-L3 links between distribution and core switches. ## Commands — configure an L3 switch ``` ! 1. Enable IP routing globally (CRITICAL — switch is L2-only until this) SW1(config)# ip routing ! 2. Create VLANs SW1(config)# vlan 10 SW1(config-vlan)# name USERS SW1(config)# vlan 20 SW1(config-vlan)# name SERVERS ! 3. Create SVIs (one per VLAN — hosts use these as gateway) SW1(config)# interface Vlan10 SW1(config-if)# description USERS gateway SW1(config-if)# ip address 192.168.10.1 255.255.255.0 SW1(config-if)# no shutdown SW1(config)# interface Vlan20 SW1(config-if)# description SERVERS gateway SW1(config-if)# ip address 192.168.20.1 255.255.255.0 SW1(config-if)# no shutdown ! 4. Assign access ports to VLANs (as on any switch) SW1(config)# interface range Gi1/0/1 - 12 SW1(config-if-range)# switchport mode access SW1(config-if-range)# switchport access vlan 10 SW1(config)# interface range Gi1/0/13 - 23 SW1(config-if-range)# switchport mode access SW1(config-if-range)# switchport access vlan 20 ! 5. (Optional) Convert uplink to a routed port SW1(config)# interface Gi1/0/24 SW1(config-if)# no switchport SW1(config-if)# ip address 10.0.0.1 255.255.255.252 SW1(config-if)# description Uplink to CORE1 ``` ## Default gateway behavior Hosts in VLAN 10 use `192.168.10.1` (the SVI IP) as their default gateway. The switch handles inter-VLAN routing entirely in its ASIC — no external router. For a host in VLAN 10 to reach a host in VLAN 20: 1. Host sends frame to switch with destination MAC = SVI10 MAC (gateway). 2. Switch sees: destination MAC = me → strip Ethernet header, route at L3. 3. Route table says VLAN 20 = SVI20 → re-encapsulate with SVI20 MAC and forward into VLAN 20. All at line rate. No CPU involvement after the first packet (CEF caches the rewrite). ## SVI "line protocol up" — the hidden gotcha An SVI's line protocol is **up** only when **at least one access port in that VLAN is up**. ``` SW1# show interface Vlan10 Vlan10 is up, line protocol is down ← no active ports in VLAN 10 ``` If you create VLAN 10, configure SVI Vlan10, but every port in VLAN 10 is shut down → the SVI is `up/down` and won't route. This trips up most CCNA labs the first time. Workaround: `no autostate` on the SVI keeps it up regardless of physical port status — useful in lab setups where you don't have hosts plugged in. ## Verification ``` SW1# show ip interface brief SW1# show ip route SW1# show ip route connected ! Should show one /24 per SVI SW1# show vlan brief SW1# show interfaces Vlan10 SW1# ping 192.168.10.50 source vlan10 ``` ## Common mistakes 1. **Forgetting `ip routing`.** Without it, the switch is L2-only — SVIs answer pings on their own subnet but cannot forward packets between VLANs. 2. **SVI down because no port in VLAN is active.** Plug in a host or `no autostate` if labbing. 3. **IP address on a port that's still `switchport`.** You can't assign an IP to a port that's in switch mode. `no switchport` first → then `ip address`. 4. **Forgetting trunk allowed VLAN list.** If the SVI lives on this switch but VLANs come in over a trunk, make sure that VLAN is in the trunk's allowed list. 5. **VLAN exists in CLI but not in the VLAN database.** `interface Vlan10` doesn't create VLAN 10 — `vlan 10` does. Both must exist. 6. **Stacking and the wrong stack-master.** On stacked 3850/9300 switches, SVIs are owned by the stack master. A master failover takes ~30 seconds during which SVIs briefly bounce. ## Lab to try tonight 1. Build in CML or Packet Tracer: one L3 switch (multilayer), two access switches, two hosts per VLAN. 2. Create VLAN 10 (USERS) and VLAN 20 (SERVERS) across all three switches. 3. Trunk between switches; access ports for hosts. 4. On the L3 switch only: `ip routing` + SVIs `Vlan10` and `Vlan20`. 5. Configure hosts to use the SVI IPs as gateways. 6. Test: host in VLAN 10 pings host in VLAN 20 → success. 7. Now shut down `interface Vlan10` → ping fails. `show ip route` shows the connected /24 disappears. 8. Bonus: convert the L3 switch's uplink to a routed port to a router. Verify with `show ip interface brief` that the port is no longer "Vlan" / access. ## Cheat strip | Concept | Plain English | |---|---| | **L3 Switch** | Switch + router in one box; routes between VLANs in ASIC | | **SVI** | `interface VlanX` — logical L3 interface, gateway for the VLAN | | **Routed port** | `no switchport` on a physical port — point-to-point L3 link | | **`ip routing`** | Globally enables L3 forwarding — without this, switch is L2-only | | **SVI line-protocol** | Up only if ≥1 access port in that VLAN is up (or `no autostate`) | | **Why use over R-on-stick** | Hardware-rate forwarding, no router CPU bottleneck, simpler topology | | **Where it sits in design** | Distribution layer or collapsed-core in campus networks | --- ## HSRP vs VRRP vs GLBP — FHRP Compared — https://packetmentor.com/topics/fhrp-comparison/ > Side-by-side of the three First Hop Redundancy Protocols on Cisco gear. When HSRP wins, why VRRP is the open standard, how GLBP load-balances across multiple actives, and which to pick in 2026. ## Mental model Hosts on a LAN have **one default gateway**. If that gateway dies, the LAN is islanded — even if there's a perfectly good second router on the same VLAN. FHRPs (First Hop Redundancy Protocols) solve this by giving the **gateway role** a virtual IP that any of two or more physical routers can claim. Hosts only ever see the virtual IP; the protocol handles the failover under the hood. If you haven't already, read [FHRP & HSRP basics](/topics/fhrp-hsrp/) first — this topic compares the three FHRPs at a deeper level. ## At a glance | | **HSRP** | **VRRP** | **GLBP** | |---|---|---|---| | **Standard** | Cisco proprietary | IETF (RFC 5798) | Cisco proprietary | | **Mode** | Active / Standby | Active (Master) / Backup | **Active / Active** (load-shared) | | **Default version** | v1 (IPv4), v2 (IPv4+IPv6) | v3 (covers IPv4 + IPv6) | v1 | | **Virtual MAC** | `0000.0c07.acXX` (v1) / `0000.0c9f.fXXX` (v2) | `0000.5e00.01XX` | `0007.b400.XXYY` | | **Hellos sent to** | 224.0.0.2 (v1), 224.0.0.102 (v2) | 224.0.0.18 | 224.0.0.102 | | **Timer defaults** | Hello 3s, hold 10s | Advertisement 1s, hold 3s | Hello 3s, hold 10s | | **Election tiebreak** | Highest priority (default 100), then highest IP | Highest priority (default 100), then highest IP | Highest priority | | **Preemption** | Disabled by default | **Enabled** by default | Disabled by default | | **Load-sharing** | No (manual per-VLAN tricks) | No (manual per-VLAN tricks) | Yes — multiple AVFs simultaneously forward | | **Authentication** | Plain text or MD5 | Plain text or HMAC-SHA256 | MD5 | | **Tracking** | Interface and object | Object | Interface and object | | **CCNA depth** | Configure + verify | Recognize + describe | Recognize + describe | ## HSRP — Cisco's everyday workhorse ``` SW1(config)# interface Vlan10 SW1(config-if)# ip address 192.168.10.2 255.255.255.0 SW1(config-if)# standby version 2 SW1(config-if)# standby 10 ip 192.168.10.1 SW1(config-if)# standby 10 priority 110 SW1(config-if)# standby 10 preempt SW1(config-if)# standby 10 authentication md5 key-string SecretKey! SW1(config-if)# standby 10 track Gi0/1 ``` Three things to memorize: 1. **`standby ip `** — the virtual IP. 2. **`priority`** — default 100. Higher wins. Without explicit priority, the router with the highest IP becomes Active. 3. **`preempt`** — without this, a recovered higher-priority router does NOT take back the Active role. Most ops engineers forget this. States: Init → Listen → Speak → Standby → Active. ## VRRP — same idea, open standard ``` SW1(config)# interface Vlan10 SW1(config-if)# ip address 192.168.10.2 255.255.255.0 SW1(config-if)# vrrp 10 ip 192.168.10.1 SW1(config-if)# vrrp 10 priority 110 SW1(config-if)# vrrp 10 authentication md5 key-string SecretKey! ``` Differences vs HSRP that you should remember: - **Preempt is on by default** (you don't need to type `preempt`). - **The Master can use a real interface IP** as the virtual IP. So priority 255 (= "I own this IP") means I'm always master, no failover. - Standard means **a Juniper or Arista box can run VRRP with the Cisco gear**. Use it any time you have mixed vendors. VRRPv3 (RFC 5798) covers both IPv4 and IPv6 with one protocol. ## GLBP — the only active-active FHRP HSRP and VRRP have one Active and N standbys. Standbys carry zero traffic. Wasteful if you spent money on two equally capable routers. GLBP fixes this by **load-sharing** across multiple Active Virtual Forwarders (AVFs): 1. One router elected as **AVG** (Active Virtual Gateway) — handles the ARP responses. 2. Multiple routers register as **AVFs** (Active Virtual Forwarders) — each owns a different virtual MAC. 3. When a host ARPs for the virtual IP, the AVG responds with **a different virtual MAC each time** — round-robin or weighted. 4. Different hosts get pointed at different physical routers. Both routers actively forward. ``` SW1(config)# interface Vlan10 SW1(config-if)# glbp 10 ip 192.168.10.1 SW1(config-if)# glbp 10 priority 110 SW1(config-if)# glbp 10 preempt SW1(config-if)# glbp 10 load-balancing weighted SW1(config-if)# glbp 10 weighting 100 lower 80 upper 95 SW1(config-if)# glbp 10 weighting track 1 decrement 30 ``` GLBP load-balancing methods: - **round-robin** — alternates virtual MACs per ARP response. - **weighted** — proportional to each AVF's weight value. - **host-dependent** — same host always gets same AVF (stickiness). Multiple AVFs means **multiple paths used simultaneously**, but it does NOT mean per-flow load-balance across routers — each flow still sticks to one AVF for its lifetime (the host's MAC table never changes mid-flow). ## Object tracking — same on all three You don't want to remain Active if your *upstream* link died. Track the upstream interface: ``` ! Define a tracked object SW1(config)# track 1 interface Gi0/1 line-protocol ! Tie HSRP priority to it SW1(config-if)# standby 10 track 1 decrement 30 ! Or VRRP SW1(config-if)# vrrp 10 track 1 decrement 30 ! Or GLBP weighting SW1(config-if)# glbp 10 weighting track 1 decrement 30 ``` If Gi0/1 goes down, priority drops by 30. If the other router has higher effective priority, it takes over. You can also track: - IP route presence (`track 2 ip route 10.0.0.0/8 reachability`) - IP SLA probe state (`track 3 ip sla 1 reachability`) - Other object boolean combinations ## Authentication — don't skip it All three protocols accept hellos by default from anyone on the segment. A malicious host can pretend to be a high-priority router and hijack the gateway. - **HSRP MD5:** `standby 10 authentication md5 key-string MyKey` - **VRRP MD5 (v2 only):** `vrrp 10 authentication md5 key-string MyKey` - **GLBP MD5:** `glbp 10 authentication md5 key-string MyKey` **VRRPv3 caveat:** RFC 5798 explicitly **removed authentication** from VRRPv3 — the IETF concluded that VRRP's threat model is better solved with IPsec or link-layer protections than with the weak shared-secret auth in v2. Cisco IOS still accepts `authentication` on VRRPv2 configurations; on VRRPv3 there is no native auth knob. Treat HSRP MD5/SHA and GLBP MD5 as the "default-on" production controls; for VRRP, rely on the L2/L3 fabric being trusted. Always enable HSRP/GLBP authentication in production. ## Which to pick — 2026 guidance | Scenario | Choose | |---|---| | Cisco-only environment, single-active gateway is fine | **HSRP** | | Mixed-vendor environment (Cisco + Arista, Juniper, etc.) | **VRRP** | | You genuinely have spare upstream bandwidth and want both routers forwarding | **GLBP** | | IPv6 only | HSRPv2 or VRRPv3 | | You need sub-second failover | Look beyond FHRP — switch to BFD-driven dynamic routing, or use stack/StackWise Virtual to eliminate the gateway-redundancy problem entirely | In real life, **HSRP is the default in Cisco shops** because it's simple, well-understood, and the load-sharing benefit of GLBP is usually overrated — most enterprise traffic is asymmetric anyway (uplink saturated, downlink less so). ## Verification ``` ! HSRP SW1# show standby brief SW1# show standby Vlan10 detail ! VRRP SW1# show vrrp brief SW1# show vrrp Vlan10 detail ! GLBP SW1# show glbp brief SW1# show glbp Vlan10 detail ``` `brief` is your default — shows group, virtual IP, state, priority, preemption, active/standby routers in one line per group. ## Common mistakes 1. **Forgetting preempt on HSRP/GLBP.** Configured priority 110, expected this router to be Active — but original Active never gave the role back after recovery. 2. **VRRP virtual IP same as a real interface IP.** Some platforms allow it, some don't. Either commit to "virtual IP is its own address" or commit to "virtual IP is the master's real address with priority 255" — don't mix. 3. **Missing `version 2` on HSRP for IPv6.** HSRPv1 only carries IPv4. HSRPv2 carries both. 4. **GLBP load-balance method = round-robin in DHCP environments.** Pairs of ARP-from-same-MAC requests can end up with different AVFs — works fine, but stateful flows can get confused if combined with NAT or PBR. 5. **Tracking the wrong thing.** Tracking `interface line-protocol` doesn't catch a routing-protocol failure or a downstream IP SLA. Use the right track type per dependency. 6. **Authentication mismatch.** Different key on the two routers → both think they're Active. Same VIP responds twice; hosts get inconsistent MACs. Always verify keys match. 7. **No FHRP at all.** A surprising number of campus networks rely on a single Layer-3 switch for VLAN gateways. One reload = one outage. Always at least HSRP, even between two stack members. ## Lab to try tonight 1. Two L3 switches (or two routers), one VLAN with a host. Each switch has a real IP in VLAN 10 (`.2` and `.3`), virtual gateway `.1`. 2. Configure HSRP group 10: priority 110 on SW1, default 100 on SW2. Verify with `show standby brief` — SW1 is Active. 3. From the host, ARP for `.1` — note the virtual MAC starts with `0000.0c`. 4. Shut down SW1's interface. Verify SW2 becomes Active. Host keeps pinging (a couple of dropped packets at most). 5. Reload SW1. Without preempt, SW1 stays Standby. Add `standby 10 preempt` and watch it reclaim Active. 6. Convert the same VLAN to VRRP. Notice `preempt` is now on by default and the virtual MAC starts with `0000.5e`. 7. Bonus: convert to GLBP. Add a second host. `show glbp brief` should show TWO AVFs forwarding. ARP from each host — see different virtual MACs. 8. Bonus: add interface tracking (`track 1 interface Gi0/1 line-protocol`) — shut the uplink, watch the active role flip even though the LAN-side interface is still up. ## Cheat strip | Concept | Plain English | |---|---| | **FHRP** | First Hop Redundancy Protocol — gives the LAN a virtual gateway | | **HSRP** | Cisco. Active/Standby. Default 100. Preempt OFF by default | | **VRRP** | IETF standard. Master/Backup. Default 100. **Preempt ON by default** | | **GLBP** | Cisco. Active/Active. AVG hands out multiple virtual MACs | | **AVG / AVF** | (GLBP) Active Virtual Gateway / Active Virtual Forwarder | | **Priority** | Higher wins. Default 100 (HSRP/VRRP/GLBP) | | **Preempt** | Recovered higher-priority router takes Active back | | **Virtual IP** | Single gateway IP that survives router failure | | **Virtual MAC** | Vendor-allocated — `0000.0c.07.acXX` (HSRP), `0000.5e.00.01XX` (VRRP), `0007.b4...` (GLBP) | | **Object tracking** | Decrement priority when an uplink / route / SLA fails | | **Authentication** | Always enable. MD5 minimum, SHA-256 if VRRPv3 | | **In 2026** | HSRP for Cisco-only, VRRP for mixed-vendor, GLBP rare | --- ## Power over Ethernet (PoE) — https://packetmentor.com/topics/power-over-ethernet/ > How a switch port also powers a phone, AP, or camera over the same Ethernet cable. PoE standards (802.3af / at / bt), power classes, detection sequence, budgets, and the troubleshooting questions you'll actually ask. ## Mental model A Cat5e/6 cable has 4 twisted pairs (8 wires). Standard 10/100 Ethernet only uses 2 of those pairs for data. Gigabit uses all 4 but only at a fraction of their voltage capacity. PoE uses the same cable to carry **48 V DC** to the connected device on top of the data. The receiving device (an IP phone, AP, camera) extracts the power and runs from it. Why this matters in practice: - **One cable, no power adapter** — IP phones, APs, badge readers, cameras all install without an electrician. - **One power budget at the switch** — back up the wiring closet with one UPS, all PoE devices stay up during a power outage. - **Centralized control** — switch can power-cycle a stuck AP or phone from a CLI. If you've never wondered how the AP in your office ceiling gets power, the answer is: PoE from the switch. ## The IEEE standards | Standard | Marketing name | Year | Max watts (at the PD) | Cable use | |---|---|---|---|---| | **802.3af** | PoE | 2003 | 12.95 W (delivered), 15.4 W (sourced) | 2 pairs | | **802.3at** | PoE+ | 2009 | 25.5 W (delivered), 30 W (sourced) | 2 pairs | | **802.3bt Type 3** | PoE++ / 4PPoE | 2018 | 51 W (delivered), 60 W (sourced) | All 4 pairs | | **802.3bt Type 4** | PoE++ / UPOE+ | 2018 | 71.3 W (delivered), 90 W (sourced) | All 4 pairs | Each standard supersedes but is **backwards compatible** with the older ones. An 802.3bt switch can power an 802.3af phone without issue. There are also **proprietary pre-standards** — Cisco UPOE (60W), Cisco UPOE+ (90W). Same delivered power as 802.3bt but pre-dated the standard. Modern switches use the standard. **Watts to know:** - A typical Wi-Fi 6 AP needs ~25 W → PoE+ minimum. - A high-end Wi-Fi 6E AP with multi-gig uplink can need 30–60 W → 802.3bt. - A standard IP phone needs ~6 W → plain PoE is fine. - A pan/tilt camera with IR + heater needs ~25–60 W → PoE+ or bt. ## Roles — PSE and PD | Term | What it means | |---|---| | **PSE** | Power Sourcing Equipment — the device delivering power. Usually a switch port; can be a "PoE injector" mid-span. | | **PD** | Powered Device — the device receiving power. Phone, AP, camera. | A **PoE injector** is a small box that adds PoE to a non-PoE switch's port — useful for one-off retrofits. A **PoE splitter** does the reverse on the PD side (delivers power and data separately to a device that doesn't natively support PoE). ## The negotiation — why you can plug your laptop into a PoE port safely A PSE doesn't just blast 48 V down the cable. It runs a **detection and classification** sequence first: 1. **Detection** — PSE applies a small voltage (2.7–10 V) and measures resistance. A real PD has a specific 25 kΩ signature resistor across the right pins. A laptop or random Ethernet device doesn't → PSE sees no signature → never delivers power. 2. **Classification** — PD signals its class (0–8) by drawing a specific current under low voltage. Class maps to power range. PSE allocates from its budget accordingly. | Class | Sourced power | Common PDs | |---|---|---| | 0 | 15.4 W (af legacy default) | Old VoIP phones | | 1 | 4.0 W | Sensors | | 2 | 7.0 W | Basic phones | | 3 | 15.4 W | Most APs, fancy phones | | 4 | 30 W | Wi-Fi 6 APs | | 5 | 45 W | High-power APs, cameras | | 6 | 60 W | Type-3 802.3bt | | 7 | 75 W | Higher-power Type-4 | | 8 | 90 W | High-density APs, video kiosks | 3. **Power delivery** — once class is known and budget exists, PSE engages 48 V on the chosen pairs. 4. **Continuous monitoring** — PSE keeps detecting the PD's "MPS" (Maintain Power Signature). If the PD goes away (cable unplugged), PSE shuts power within 300–400 ms. 5. **LLDP-based negotiation** (Cisco UPOE / 802.3bt). After the basic class, PD and PSE can negotiate a more precise wattage over LLDP — useful for class-4+ devices that want more than 30 W but only sometimes. ## Power budgets — the gotcha that kills branch offices A switch has a finite total PoE budget. Common values: | Switch | Total PoE budget | |---|---| | Catalyst 9300-24P | 445 W | | Catalyst 9300-24UPOE | 715 W | | Catalyst 9300-48P | 822 W | | Catalyst 9300-48UPOE | 1100 W | | Catalyst 9200-24P | 370 W | If you have a 24-port switch with 445 W budget and 24 Wi-Fi 6 APs at 25.5 W each → 612 W demanded → switch refuses to power all of them. Some ports stay dark. Standard practice: when sizing a switch, calculate `(number of PDs × max watt per PD) × 1.2 safety margin` and pick a switch with that total budget. ## Configuration — Cisco IOS PoE is usually on by default on every PoE-capable port. Commands you actually use: ``` ! Per-port — set PoE behavior SW1(config)# interface Gi1/0/1 SW1(config-if)# power inline auto ! default — detect/classify/deliver SW1(config-if)# power inline never ! disable PoE on this port SW1(config-if)# power inline static ! reserve full af/at budget regardless ! Limit per-port wattage (handy if you don't trust a third-party PD) SW1(config-if)# power inline auto max 15400 ! cap at 15.4 W ``` Global tools: ``` SW1# show power inline ! all ports, all classes SW1# show power inline Gi1/0/1 SW1# show power inline police ! ports configured with budget cap SW1# show platform software ilpower system 1 ! deep diagnostics ``` `show power inline` is the troubleshooting workhorse: ``` SW1# show power inline Module Available Used Remaining ------ --------- ---- --------- 1 445.0 186.2 258.8 Interface Admin Oper Power Device Class --------- ----- -------- ----- --------------- ----- Gi1/0/1 auto on 15.4 IP Phone 8841 3 Gi1/0/2 auto on 30.0 AIR-CAP3702 4 Gi1/0/3 auto off 0.0 n/a n/a Gi1/0/4 auto on 25.5 AIR-CAP9120 4 ``` ## Cable considerations - **Cat5e minimum** for 802.3af / at. Cat6 minimum recommended for 802.3bt to keep heat manageable. - Long runs (close to 100 m) lose ~3–5 W to cable resistance. Plan with that. - PoE doesn't care about cable shielding (STP vs UTP) electrically, but high-density bt installs prefer shielded cables to reduce alien crosstalk. - **Never** use untwisted "flat" Ethernet cables for PoE — heat buildup is real and they can melt. ## Common mistakes 1. **Over-budgeting the switch.** 24-port PoE+ switch with 30 W per port = 720 W theoretical, but the budget is usually ~450 W. Read the spec sheet. 2. **Forgetting that AP/camera spec is "peak power."** A camera says 30 W max but sits at 8 W average. Size for peak when sizing budget; size for average when sizing UPS. 3. **Assuming UPS is automatic.** Putting the switch on a UPS gives you 5–30 minutes of "branch survives a power blip." You probably need this. Datacenter switches usually have dual power supplies + dual UPSes. 4. **Plugging a PoE-injected cable into a PoE switch port.** Two PSEs on the same line. Usually fine (each detects no PD and shuts off), but flaky. Pick one. 5. **Cable runs longer than 100 m.** PoE inherits Ethernet's 100 m spec. Long cables = voltage drop = device randomly browns out. Use a mid-span injector or PoE extender for runs longer than 100 m. 6. **Mixing PoE+ devices on a plain PoE (af) switch.** Switch can only deliver 15.4 W; PoE+ device boots in low-power mode (or fails). Always match PD requirement to switch standard. 7. **Forgetting LLDP for high-class PDs.** 802.3bt Class 5+ devices negotiate exact wattage over LLDP after link-up. If LLDP is disabled on the switch, the PD may not get the extra wattage it asked for. ## Real-world troubleshooting User says: *"my new conference-room AP isn't coming up."* Step through: 1. `show power inline Gi1/0/24` — what does the switch see? Class detected? Power delivered? 2. If `Oper off` and `Device n/a` — switch never saw a PD signature. Bad cable, bad patch, bad AP. 3. If `Oper power-deny` — switch ran out of budget. Move AP to a different switch, or upgrade switch power supply. 4. If `Oper fault` — AP is drawing more than it negotiated, switch shut it off. Mismatched cable category, run too long, or AP is bt-class on an af-only switch. 5. `show cdp neighbor Gi1/0/24` or `show lldp neighbors detail` — sanity check that the device is actually there. ## Lab to try tonight 1. Plug a PoE phone (or AP, camera) into a PoE switch port. 2. `show power inline brief` — note the class, wattage, device name. 3. Run `power inline never` on that port. Phone goes dead. Run `power inline auto` again — phone boots. 4. Cap the port: `power inline auto max 7000`. If you connect a higher-class device (e.g., AP), the switch refuses with `power-deny`. 5. Inspect cabling — if you have a spare patch lead and a cable tester, measure pair connectivity. Identify which pairs carry power on your equipment (varies by Mode A vs Mode B for older af). 6. Bonus: connect a non-PoE laptop to a PoE port. Confirm via `show power inline` that detection fails and no power is delivered. (No, your laptop won't fry.) 7. Bonus: if you have an 802.3bt-capable AP, enable LLDP power negotiation (`lldp run` and `cdp run` globally), reboot the AP, then check the AP's CLI for actual negotiated wattage. ## Cheat strip | Concept | Plain English | |---|---| | **PSE** | Power Sourcing Equipment — the switch port | | **PD** | Powered Device — phone, AP, camera | | **802.3af** | Original PoE — 15.4 W sourced | | **802.3at** | PoE+ — 30 W sourced | | **802.3bt Type 3 / 4** | PoE++ — 60 W / 90 W sourced | | **Detection** | Switch checks for the 25 kΩ signature before delivering power | | **Classification** | PD declares its power class (0–8) | | **Power budget** | Total watts a switch can deliver across all PoE ports | | **MPS** | Maintain Power Signature — PSE drops power if PD vanishes | | **`power inline auto`** | Default — detect, classify, deliver | | **`power inline never`** | Disable PoE on this port | | **`show power inline`** | Per-port wattage, class, device — your main troubleshooting view | | **Cable** | Cat5e minimum for af/at; Cat6 recommended for bt | | **100 m limit** | Same as Ethernet. Beyond that → injector / extender | ## Troubleshooting PoE — the common patterns **PD doesn\'t power up at all** - `show power inline` — is the port even attempting to deliver? If Admin=auto but Oper=off, look at detection. - Cable failure — pair damage often kills PoE first (needs all 4 pairs for 802.3bt; 2 pairs for af/at). - Wrong port — some switches deliver PoE only on a subset of ports (edge SKUs). - Budget exhausted — `show power inline` shows total Available vs Used at the top. If Used ≈ Available, new PDs get "power denied." **PD flaps under load** - Cable heat — Cat5e on a 100 m PoE+ run can hit spec-limit temperatures. Cat6 fixes it. - Wrong power class — the PD advertised class 3 (13 W) but actually needs class 4 (25 W). Enable LLDP power negotiation and let the PD ask for its true budget. - Switch\'s power supply sized too small — pulling the transceiver stats, sum the current PoE draw. Compare to PSU capacity. **Wi-Fi AP boots but loses client-serving radio randomly** - Under-powered AP is the classic symptom. A Wi-Fi 6E AP hitting 802.3at (30 W) instead of 802.3bt (60 W) will disable its 6 GHz radio to save budget. Verify with `show cdp neighbors detail` (AP reports required power) and `show power inline` on the switch. **PD works on one port, not another** - Not all ports are PoE (check hardware). Also check `power inline auto` vs `never` per interface — someone may have disabled PoE on a specific port. ## Frequently asked questions **Q: If I plug my laptop into a PoE switch port, will PoE fry it?** A: No. PoE uses a resistive signature check (25 kΩ) BEFORE delivering power. Ordinary non-PoE devices don\'t present that signature, so the switch withholds power. Your laptop just gets regular Ethernet. **Q: Cat5e for PoE+ — safe or not?** A: For short runs (under ~50 m), fine. For 90+ m runs with sustained PoE+ draw (like a Wi-Fi AP under full load), heat buildup is real. Cat6 is the modern safe choice. Cat6A for PoE++ (802.3bt). **Q: How is 802.3bt different from Cisco UPOE?** A: Cisco UPOE (60 W) and UPOE+ (90 W) predated the 802.3bt standard. Same power classes, similar behavior. Modern Catalyst switches implement true 802.3bt so they work with any PD, not just Cisco. **Q: How do the switch and PD agree on wattage?** A: Two-tier: first the class check at power-on (rough — 4 classes for 802.3af/at, 8 classes for 802.3bt). Then LLDP-MED power negotiation refines it. Enabling `lldp run` globally lets a Wi-Fi AP request its exact budget instead of getting a class-based approximation. **Q: Can PoE run over fiber?** A: No — PoE is inherently a copper-only technology because power needs conductors. If your uplink is fiber, use a media converter with a PoE-out port, or place the PD close enough that a copper drop works. **Q: What\'s "Perpetual PoE"?** A: Cisco Catalyst feature (also called "Fast PoE" on some SKUs) that keeps PoE flowing through a brief switch reload. Prevents PoE devices (IP phones, APs) from rebooting when the switch does. Useful in mission-critical environments. **Q: Do all 8 ports on a PoE switch always run at max power together?** A: No — that\'s what "power budget" is about. An 8-port switch with a 250 W budget can power six APs at 30 W each (180 W) but only four at 60 W (240 W). Anything beyond the budget is refused. **Q: PoE ↔ MPS ↔ what does the switch drop power when the device is unplugged?** A: MPS (Maintain Power Signature) is a low-level continuous check. If the PD disappears, MPS timeout expires and the switch cuts power. Prevents the port from constantly reheating with no device attached. **Q: What\'s the max distance for PoE?** A: Same as Ethernet — 100 m over Cat5e/6/6A. Beyond that you need a PoE injector, midspan, or a switch acting as a repeater. Some vendors sell "PoE Extenders" that go 200–400 m at reduced bandwidth. --- ## Wi-Fi 6, 6E, and 7 Features — https://packetmentor.com/topics/wifi-6-7-features/ > What changed in 802.11ax (Wi-Fi 6), 6 GHz extension (6E), and 802.11be (Wi-Fi 7) — OFDMA, MU-MIMO, target wake time, 6 GHz spectrum, MLO, and what each one actually means for users. ## Mental model Each Wi-Fi generation either adds **speed**, **efficiency**, or **spectrum** — or all three. Up through Wi-Fi 5 (802.11ac, 2013), the story was "more streams + wider channels = faster." Past 1 Gbps, that approach hit diminishing returns — in dense environments, the bottleneck isn't raw speed but **airtime contention** between many clients on the same channel. Wi-Fi 6 changed the focus: **share the channel more efficiently**, not just bigger pipes. Wi-Fi 6E added clean spectrum. Wi-Fi 7 pushed both further. | Gen | Standard | Year | Max raw rate | Key idea | |---|---|---|---|---| | Wi-Fi 4 | 802.11n | 2009 | 600 Mbps | MIMO | | Wi-Fi 5 | 802.11ac | 2013 | 6.9 Gbps | Wider channels (80/160 MHz) | | **Wi-Fi 6** | 802.11ax | 2019 | 9.6 Gbps | Efficiency: OFDMA, UL MU-MIMO, TWT | | **Wi-Fi 6E** | 802.11ax @ 6 GHz | 2020 | 9.6 Gbps | Same features, new band (6 GHz) | | **Wi-Fi 7** | 802.11be | 2024 | 46 Gbps | 320 MHz, 4K-QAM, MLO | ## Wi-Fi 6 — five features that matter ### 1. OFDMA (Orthogonal Frequency-Division Multiple Access) Before Wi-Fi 6: one client at a time on the channel. A laptop wanting to send 100 bytes still holds the full channel for the duration of its transmission. Wasteful — like one car using a 12-lane highway alone. With **OFDMA**, the channel is divided into smaller sub-channels (Resource Units, RUs) of 26 / 52 / 106 / 242 sub-carriers. Multiple clients can transmit *simultaneously* in different RUs. A 20 MHz channel can carry up to 9 clients in parallel. A 40 MHz channel can carry 18. The AP coordinates who gets which RU and when. **Effect:** lower latency, higher throughput in busy networks. Voice/video gets a small RU on schedule; bulk downloads get larger RUs when free. ### 2. UL MU-MIMO Wi-Fi 5 had downlink MU-MIMO — AP could transmit to multiple clients simultaneously using spatial streams. Wi-Fi 6 adds **uplink MU-MIMO** — multiple clients can transmit to the AP simultaneously. Important because clients are increasingly chatty (cloud backup, video upload, IoT telemetry). ### 3. BSS Coloring When two APs on the same channel (overlapping coverage areas) hear each other, both back off — even if they're far enough apart that their clients wouldn't interfere. This is the "co-channel interference" problem that limits density. **BSS Coloring** assigns each AP a color (1–63). A station ignores frames from a different color if signal is below a threshold — treats them as background noise. Result: APs can transmit simultaneously when they're geographically far enough apart even on the same channel. This is the single biggest density improvement in 6. ### 4. Target Wake Time (TWT) IoT devices wake every 30 s to send a temperature reading, then go to sleep for another 30 s. Before Wi-Fi 6, they had to wake up regularly to check for buffered packets at the AP. **TWT** lets the client and AP negotiate exact wake-up slots. The device sleeps deeply between slots, the AP buffers anything for it. Massive battery-life improvement (2–10×) for IoT and wearables. ### 5. 1024-QAM Constellation density bumped from 256-QAM (Wi-Fi 5) to 1024-QAM. Each symbol carries 10 bits instead of 8, ~25% more data per slot — but only when signal-to-noise is excellent. In real-world conditions, the 1024-QAM modes only kick in for clients very close to the AP. ## Wi-Fi 6E — the 6 GHz band Wi-Fi 6E is Wi-Fi 6 **plus the 6 GHz band** opened by the FCC (and most other regulators) in 2020–2022. **Why this matters:** the 6 GHz band has **14 non-overlapping 80 MHz channels** or **7 × 160 MHz channels** — vs the crowded 5 GHz band which has only 5–6 clean 80 MHz channels after avoiding DFS/radar. Three big consequences: - **High-density deployments** can finally use wide channels without overlap. - **Latency-sensitive apps** (VR, AR, telemedicine) get clean spectrum. - **Only Wi-Fi 6E+ clients are allowed** in 6 GHz — no legacy 11g/n/ac contention. The "only modern clients allowed" rule is enforced because 6 GHz mandates WPA3 — no WPA2, no Open, no PSK-without-SAE. ## Wi-Fi 7 — the next leap **802.11be**, formally branded Wi-Fi 7. Three big features: ### 1. 320 MHz channels 5 / 6 GHz spectrum supports doubled channel width — 320 MHz vs Wi-Fi 6's 160 MHz max. Twice the bandwidth → twice the raw rate per stream. ### 2. 4K-QAM (4096-QAM) Each symbol carries 12 bits — 20% more data per slot when SNR is high enough. Like 1024-QAM, this only kicks in at very high signal strength. ### 3. Multi-Link Operation (MLO) This is the breakthrough. A single client can **simultaneously use multiple bands** — typically 5 GHz **and** 6 GHz at the same time. Three MLO modes: - **Aggregation** — sum the throughput across bands. - **Failover** — if one band degrades, traffic shifts seamlessly to the other. - **Steering** — different traffic types on different bands (latency-sensitive on 6 GHz, bulk on 5 GHz). For the user, MLO means a connected client doesn't have to "roam between bands" — it uses both at once. ### 4. Other goodies - **Multi-RU** — a client can be assigned more than one RU per OFDMA slot. - **Preamble Puncturing** — work around interference on a sub-portion of a wide channel rather than dropping the whole channel. - **Better Wi-Fi calling** — lower latency and more deterministic scheduling. Wi-Fi 7 client adoption is early in 2026 — flagship phones, premium laptops, gaming gear. Mass-market client devices will lag the AP rollout by 2-3 years (typical Wi-Fi pattern). ## What Wi-Fi 6 / 6E / 7 don't fix Reality check — what's marketing vs what's real: - **Range** — same physics. Higher frequency = worse penetration. Wi-Fi 7 on 6 GHz has *worse* range than Wi-Fi 5 on 2.4 GHz at the same power. - **Backhaul** — if your AP's uplink is 1 Gbps, that's your ceiling regardless of how fast the air is. Modern APs need **multi-gig uplinks** (2.5G or 5G) to actually deliver Wi-Fi 6E throughput. - **Bad cabling** — Cat5e is fine for 1 Gbps but choppy at 2.5 Gbps. Cat6 minimum for multi-gig. - **WAN bottlenecks** — Wi-Fi 6E to a 100 Mbps DSL is still 100 Mbps. The throughput gains are real **in benchmarks** with all-new clients and short distance. In a real office, the wins are mostly density + IoT battery + lower latency — not headline gigabits. ## What it means for a CCNA engineer You'll buy and deploy Wi-Fi 6 / 6E APs. You'll see them in spec sheets and customer requirements. Things to actually know: 1. **Wi-Fi 6** doesn't need new clients to start showing benefits (BSS coloring is AP-side; legacy clients still get OFDMA-friendly behavior). 2. **Wi-Fi 6E** requires both AP and client to support 6 GHz. Audit the client fleet. 3. **WPA3 mandatory on 6 GHz.** Plan your authentication stack. 4. **Multi-gig switches** — modern Wi-Fi 6E APs want 2.5G or 5G uplinks. PoE+ minimum, often 802.3bt for higher-end APs. 5. **DFS still exists in 5 GHz** — switching to 6 GHz avoids it entirely. ## Verification on Cisco controllers Catalyst 9800-CL / 9800-L: ``` WLC# show wireless client mac-address aabb.cc11.2233 detail | include 802.11 Capability: 802.11ax ! Wi-Fi 6 client Channel: 36, 80 MHz width Data Rates: 1024-QAM rate set WLC# show ap dot11 6ghz summary ! 6 GHz radio status WLC# show wireless wlan summary ``` If a client connects on 2.4 GHz when 6 GHz is available, band steering / 802.11k/v/r may need tuning. Some old clients are sticky to 2.4 GHz despite stronger 5 / 6 GHz signal. ## Common mistakes 1. **Assuming Wi-Fi 6 = faster always.** In an empty room with one client, 6 is barely faster than 5. The win shows up in dense, multi-client scenarios. 2. **Wi-Fi 6E without WPA3 client support.** 6 GHz mandates WPA3. Many older corporate laptops only do WPA2-Enterprise and can't reach 6 GHz at all. 3. **Wi-Fi 6E AP on a 1 Gbps uplink.** Backhaul-bound. You paid for 6 GHz and get 1 Gbps. Upgrade the access switch port. 4. **Cabling neglect.** Cat5e to a Wi-Fi 6E AP might work for 1G but won't sustain 2.5G/5G negotiated rates. Recable — and while you're planning, size the [Power over Ethernet](/topics/power-over-ethernet/) budget: Wi-Fi 6E APs commonly draw 30–45 W under load, and multi-gig transceivers make it worse. Set the AP to the right [operating mode](/topics/ap-operating-modes/) at the same time — Local for HQ, FlexConnect for branch. 5. **Treating MLO as "multiple SSIDs."** It's not — MLO is one association across multiple bands. You don't need to publish separate SSIDs to use it. 6. **Forgetting clients don't all upgrade together.** Wi-Fi 7 AP + 90% Wi-Fi 5 clients = mostly Wi-Fi 5 performance. The AP upgrade is the *enabler*; the client fleet sets the *floor*. 7. **Disabling 802.11b/g rates on a network with legacy IoT.** Some old IoT (printers, scanners, vintage smart plugs) only does 11b/g. Disabling 11b improves performance for everyone else but bricks those devices. Audit first. ## Lab to try (mostly observational) 1. On your phone, install a Wi-Fi info app (Wi-Fi Analyzer on Android, AirPort Utility on iPhone). Connect to a known Wi-Fi 6 / 6E AP. Verify the standard reported. 2. From your laptop CLI: `netsh wlan show interfaces` (Windows) or `airport -I` (macOS) — note Radio type, Bandwidth, Channel. 3. If you have a Wi-Fi 6E client + AP, force a 6 GHz channel. Compare throughput vs 5 GHz at the same physical position. 4. Enable BSS Coloring on the controller (it's default on most). Inspect `show ap dot11 5ghz summary` for the assigned colors. 5. Use `iperf3` to measure achievable rates. Compare full-laden network vs lab-empty network — feel the OFDMA efficiency wins. 6. If you have Wi-Fi 7 hardware (rare in 2026 still), enable MLO on the AP. Watch a single client use multiple bands simultaneously. ## Cheat strip | Feature | One-line meaning | |---|---| | **OFDMA** | Multiple clients transmit simultaneously on the same channel | | **UL MU-MIMO** | Multiple clients upload simultaneously | | **BSS Coloring** | Color tag per AP — ignore overlapping APs to reuse channel space | | **TWT** | Scheduled sleep/wake — saves IoT battery | | **1024-QAM / 4K-QAM** | Denser modulation — only at high SNR (very close to AP) | | **6 GHz band** | Clean fresh spectrum opened 2020. 14 × 80 MHz channels | | **WPA3 mandatory on 6 GHz** | Legacy clients literally can't join 6 GHz | | **320 MHz channels** | Wi-Fi 7. Doubled width vs Wi-Fi 6 | | **MLO** | Client uses 5 GHz + 6 GHz simultaneously | | **Multi-gig uplink** | Wi-Fi 6E / 7 APs deserve 2.5G+ switch ports | | **PoE+** | Minimum for most Wi-Fi 6 APs; 802.3bt for high-end | | **Density win** | Real benefit of Wi-Fi 6 is dense networks — not lab speedtests | ## Frequently asked questions **Q: Do I need Wi-Fi 6E or Wi-Fi 7 hardware to benefit from these features?** A: Some benefits (BSS Coloring, OFDMA, TWT, WPA3) work with Wi-Fi 6 (802.11ax on 2.4/5 GHz) and don't require the 6 GHz radios. The 6 GHz band, MLO, and 320 MHz channels need Wi-Fi 6E or Wi-Fi 7 hardware on BOTH the AP AND the client. **Q: What is OFDMA in one sentence?** A: Instead of one client transmitting on the full channel at a time, OFDMA splits the channel into subchannels (resource units) so multiple clients transmit simultaneously — dramatically improving multi-user density. **Q: What is BSS Coloring for?** A: It assigns each AP a color (1–63). Nearby APs on the same channel can identify whether a frame is "theirs" or a neighbor's — if it's from a colored differently AP and signal is weak, they treat it as background noise and transmit anyway. Big density win. **Q: What is Target Wake Time (TWT)?** A: A scheduled sleep/wake mechanism between the AP and IoT clients. Instead of the client polling every few seconds, the AP tells it "wake at this exact time." Result: 2–10× battery life for wearables and low-bandwidth IoT. **Q: Does Wi-Fi 7 make my old Wi-Fi 5 client faster?** A: No — but it makes the AP more efficient at serving both new and old clients simultaneously. A Wi-Fi 7 AP + 90% Wi-Fi 5 clients gets you slightly better throughput per client than a Wi-Fi 5 AP would, mostly because the newer AP has better MU-MIMO and interference handling. **Q: What does MLO (Multi-Link Operation) do?** A: A single Wi-Fi 7 client can associate over multiple bands simultaneously (say, 5 GHz + 6 GHz). Frames can flow over whichever link has less congestion. Not the same as advertising multiple SSIDs — it's one association over multiple radios. **Q: Is WPA3 required for Wi-Fi 6E and 7?** A: 6 GHz mandates WPA3 for enterprise auth. Legacy WPA2-only clients literally cannot join a 6 GHz SSID. This is a real deployment blocker in enterprises with old corporate laptops. **Q: How much power does a Wi-Fi 7 AP need?** A: Wi-Fi 7 with 6 GHz + 5 GHz + 2.4 GHz radios + multi-gig uplink often draws 45–60 W, meaning 802.3bt (60W) at the switch. Don't try to power a Wi-Fi 7 AP with PoE+ (30W) — one or more radios will disable. ## What to learn next - **Foundation**: [Wireless LAN Basics](/topics/wireless-lan-basics/) — before deep-diving Wi-Fi 6/7 features. - **Architecture**: [WLAN Architectures](/topics/wlan-architectures/) — WLC-based vs autonomous vs cloud-managed deployment models. - **AP behavior**: [Access Point Operating Modes](/topics/ap-operating-modes/) — Local, FlexConnect, Bridge, Monitor, and when to use each. - **Security context**: [Wi-Fi Security](/topics/wifi-security/) — WEP, WPA, WPA2, WPA3 and the enterprise auth flow (802.1X). - **Cabling context**: [Power over Ethernet (PoE)](/topics/power-over-ethernet/) — because a Wi-Fi 7 AP that isn't getting PoE++ won't run at full capacity. --- ## Rapid STP & MSTP — https://packetmentor.com/topics/rstp-mstp/ > Why classic 802.1D STP's 50-second convergence is unacceptable in 2026, and how RSTP and MSTP fix it — port roles, port states, sync mechanism, MST regions and instances. ## Mental model Classic 802.1D Spanning Tree (covered in [Spanning Tree](/topics/spanning-tree/)) prevents Layer-2 loops by blocking redundant links. It works — but it converges slowly: ``` Blocking → Listening → Learning → Forwarding ↑ 20 s ↑ 15 s ↑ 15 s ``` Topology change → 30 seconds at minimum, often 50 seconds, before traffic flows. VoIP drops calls. Video stutters. Cloud apps reconnect. Unacceptable for modern networks. **RSTP** (802.1w, 2001) keeps the loop-prevention math but reorganizes the state machine for **fast convergence — typically 1-2 seconds**, sub-second in trim topologies. **MSTP** (802.1s, 2002) layers on top: it adds multi-instance support so you can have many VLANs share a small number of STP instances instead of running PVST+ (one STP per VLAN — which doesn't scale beyond ~250 VLANs on most platforms). Cisco gear runs **PVST+** and **Rapid-PVST+** (Cisco-flavored Per-VLAN STP) and **MSTP** (standards). In modern Cisco shops, **Rapid-PVST+** is the default for small/mid deployments; **MSTP** is used in service-provider and very large enterprise. ## RSTP — what changed ### Port roles Classic STP had four roles: Root, Designated, Blocking, Disabled. RSTP keeps Root and Designated and replaces the "blocking" idea with two more precise roles: | Role | What it means | |---|---| | **Root** | Best path to the Root Bridge. Same as in STP. | | **Designated** | Best path to a segment, owned by this bridge. Forwarding. | | **Alternate** | Has a fallback path to the Root. Not forwarding. Knows of a better Root port — ready to take over instantly. | | **Backup** | Backup for the *designated* port on the same segment (only happens with bridges that have two ports in the same segment, e.g., a hub). Rare. | The key innovation is **Alternate**. RSTP has already pre-computed the next-best path; failover is just "promote Alternate → Root." No timers, no recalculation. ### Port states — only three Classic STP had Blocking, Listening, Learning, Forwarding, Disabled (5 states). RSTP collapses them: | RSTP state | Forwards data? | Learns MAC? | |---|---|---| | **Discarding** | No | No | | **Learning** | No | Yes | | **Forwarding** | Yes | Yes | Blocking + Listening + Disabled all merged into **Discarding**. ### Edge ports (PortFast) RSTP formalizes the concept of an "edge port" — a port that connects to a host, not another switch. Edge ports skip the STP state machine entirely and go straight to Forwarding. In Cisco IOS: ``` SW1(config-if)# spanning-tree portfast ! single-port edge SW1(config)# spanning-tree portfast default ! all access ports are edge by default ``` If a switch BPDU arrives on an edge port, RSTP demotes it back to a normal port — protecting against loops if you accidentally cable two switches at an "edge" port. (Pair with BPDU Guard for hard error-disable — see [BPDU Guard / Root Guard](/topics/bpdu-guard-root-guard/).) ### Proposal / Agreement — the sync mechanism When a new link comes up between two RSTP bridges, both could potentially carry traffic — but the bridge doesn't know which side is closer to the root. Instead of waiting for timers, RSTP uses a **proposal/agreement handshake**: 1. Bridge A sends a Proposal BPDU on the new link: *"I want this to be my designated port."* 2. Bridge B receives it, checks: am I better positioned? If A is closer to root, B agrees — but first **syncs** by temporarily Discarding on its other non-edge ports (to prevent a transient loop) — then sends Agreement. 3. Bridge A puts the link into Forwarding. 4. B then propagates the same sync down its tree — fast, hop-by-hop. Total convergence on a new link: hundreds of milliseconds to a couple of seconds, vs 30-50 seconds for legacy STP. ### Configuration on Cisco Cisco's PVST+ runs one STP instance per VLAN. **Rapid-PVST+** is the same but uses RSTP per VLAN: ``` SW1(config)# spanning-tree mode rapid-pvst ``` That's it. No per-port changes needed for basic RSTP. All the role/state benefits kick in immediately. ## MSTP — STP for many VLANs PVST+ becomes painful at 100+ VLANs — one STP instance per VLAN means 100 separate calculations, 100 BPDU streams on every trunk. CPU and memory hit becomes real. **MSTP** (802.1s) groups VLANs into a small number of **instances**. Instead of 100 STP processes, you might run 4 — one per "VLAN class." Each instance has its own root, port states, etc. ### MST regions All switches that share **the same region name + revision + VLAN-to-instance mapping** are in the same **MST region**. Inside the region, MSTP runs its full multi-instance logic. Between regions, MSTP looks like a single instance to legacy STP — so multi-vendor and legacy switches see one consistent STP world. ``` SW1(config)# spanning-tree mode mst SW1(config)# spanning-tree mst configuration SW1(config-mst)# name CAMPUS-A SW1(config-mst)# revision 1 SW1(config-mst)# instance 1 vlan 10-99 SW1(config-mst)# instance 2 vlan 100-199 SW1(config-mst)# instance 3 vlan 200-299 SW1(config-mst)# end ``` Every switch in the region must have **identical** config (name + revision + mapping). One wrong character and the switch falls out of the region. ### Why use MSTP Two big wins: 1. **Scale.** 1000 VLANs → 4 instances instead of 1000 STP processes. 2. **Traffic engineering.** Make instance 1 use one set of trunks as primary, instance 2 use a different set. Both run active simultaneously. Real link-load balancing across redundant uplinks. Cisco-only shops often stick with Rapid-PVST+ — simpler. MSTP is mandatory in multi-vendor environments and in very dense enterprise with 200+ VLANs. ## Quick comparison | Aspect | STP (802.1D) | RSTP (802.1w) | MSTP (802.1s) | |---|---|---|---| | Convergence | 30-50 s | 1-2 s (sub-second possible) | Same as RSTP | | Port roles | Root, Designated, Blocking, Disabled | Root, Designated, **Alternate, Backup** | Same as RSTP | | Port states | 5 (Blocking, Listening, Learning, Forwarding, Disabled) | 3 (Discarding, Learning, Forwarding) | Same as RSTP | | Per-VLAN | No (one tree for all) | No (or per-VLAN in Cisco PVST+) | **Many VLANs share one instance** | | Multi-vendor friendly | Yes | Yes | Yes (the standard) | | Cisco default | n/a | **rapid-pvst** is the modern default | Used at scale / multi-vendor | ## RSTP-specific Cisco features These are commonly tested as a layer on top of RSTP: - **PortFast** — edge port, skip the state machine on link-up. - **BPDU Guard** — if a PortFast port ever receives a BPDU, err-disable it. Hard loop prevention. (See [BPDU Guard / Root Guard](/topics/bpdu-guard-root-guard/).) - **BPDU Filter** — silently drop BPDUs on a port (rare, use with extreme caution). - **Root Guard** — prevent an unexpected switch from claiming Root. - **Loop Guard** — prevent unidirectional link failures from incorrectly transitioning a port to Forwarding. - **UDLD** — unidirectional link detection at L1/L2 — pairs with Loop Guard. ## Verification ``` SW1# show spanning-tree summary Switch is in rapid-pvst mode ... SW1# show spanning-tree vlan 10 VLAN0010 Spanning tree enabled protocol rstp Root ID Priority 32778 Address 001a.2b3c.4d5e This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Interface Role Sts Cost Prio.Nbr Type --------------- ---- --- --------- -------- -------------------- Gi1/0/1 Desg FWD 4 128.1 P2p Gi1/0/2 Desg FWD 4 128.2 P2p Edge Gi1/0/24 Root FWD 4 128.24 P2p SW1# show spanning-tree mst SW1# show spanning-tree mst configuration SW1# show spanning-tree mst 1 detail ``` The `Type` column tells you the link is **P2p** (point-to-point — full duplex switch-switch — RSTP can use fast handshake) vs **Shared** (half-duplex hub-style — must use the slow path). ## Common mistakes 1. **Leaving the default `pvst` mode.** You're running classic 802.1D per VLAN — slow convergence. Change to `rapid-pvst` immediately. 2. **PortFast on a switch-to-switch link.** If anything other than a host plugs in, you've created a 1-second loop window. Pair with BPDU Guard always. 3. **Mismatched MST configuration across the region.** A typo in name, mismatched revision, or different VLAN-to-instance mapping → the switch falls out of the region, all its VLANs go to instance 0. Diagnose with `show spanning-tree mst configuration digest`. 4. **Manual port priority instead of using bridge priority.** New engineers tweak per-port priority to "fix" STP. Almost always wrong — the right tool is bridge priority on the right bridges (root and secondary root). 5. **No backup root.** Root bridge fails → tree rebuilds, but a secondary root that wasn't pre-elected means slow re-election. Set `spanning-tree vlan X root primary` and `root secondary` on two bridges. 6. **Mixing PVST+ and Rapid-PVST+ across switches.** Mostly works (they fall back to common STP) but loses Rapid benefits. Standardize. 7. **Forgetting half-duplex links revert to "Shared" type.** RSTP can't use proposal/agreement on a shared link → slow convergence on that segment. Always run full-duplex. ## Lab to try tonight 1. Three switches in a triangle. All RPVST+: `spanning-tree mode rapid-pvst`. 2. Identify the Root — usually the one with the lowest MAC unless you've set priority. 3. Make SW1 root with `spanning-tree vlan 1 priority 4096`. Make SW2 secondary with `priority 8192`. 4. `show spanning-tree vlan 1` — observe port roles (Root, Designated, Alternate). 5. Shut down the link between SW2 and SW3. Time the convergence — ping should drop 1-2 packets, not 30+. 6. Unshut. Watch traffic shift back almost instantly. 7. Set up an end host on a switch port. `spanning-tree portfast` on that port — interface comes up to forwarding instantly. 8. Bonus: convert all switches to MST. Region `LAB`, revision `1`, map VLANs 10-19 to instance 1 and VLANs 20-29 to instance 2. Set SW1 as root for instance 1 and SW2 as root for instance 2 → independent active paths simultaneously. ## Cheat strip | Concept | Plain English | |---|---| | **STP (802.1D)** | Original. 30-50 s convergence. Obsolete | | **RSTP (802.1w)** | Rapid. 1-2 s convergence. **Default in any modern Cisco shop** | | **MSTP (802.1s)** | Groups VLANs into a few STP instances. Scales to 1000s of VLANs | | **Rapid-PVST+** | Cisco's RSTP-per-VLAN. `spanning-tree mode rapid-pvst` | | **Alternate port** | RSTP's "pre-computed backup root path" — instant failover | | **Discarding** | RSTP's merger of Blocking + Listening + Disabled | | **Edge port (PortFast)** | Skip state machine for host-facing ports | | **Proposal / Agreement** | The handshake that achieves fast convergence on new links | | **MST region** | Switches sharing name + revision + VLAN mapping. Identical config required | | **MST instance** | An independent STP topology covering a group of VLANs | | **Bridge priority** | Tune this to deliberately elect a Root and Secondary — never leave to chance | | **Pair with BPDU Guard** | PortFast without BPDU Guard is a loop waiting to happen | --- ## OSPF Single-Area — https://packetmentor.com/topics/ospf-single-area/ > Definitive CCNA-level OSPF guide — link-state mental model, seven neighbor states, LSA types, DR/BDR election, cost tuning, authentication, route summarization, common debug patterns, and 8 worked scenarios. ## Mental model OSPF doesn't work like RIP. RIP routers gossip — "hey, I can reach 10.1.1.0/24 in 3 hops" — and trust each other without context. That's why RIP converges slowly and routing loops can form. OSPF is the opposite. Every router builds a complete map of the network in memory (the **link-state database**, or **LSDB**). Then each router independently runs Dijkstra's **shortest-path-first** (SPF) algorithm on its copy of the map and figures out the best path to every destination on its own. Three consequences: 1. **All routers agree** on what the network looks like (after convergence). No more inconsistency. 2. **Convergence is fast** — something changes, the change gets flooded, every router runs SPF, done. Seconds, not minutes. 3. **Memory and CPU heavier** than distance-vector. Big networks split into areas to keep SPF cheap. Single-area OSPF is the simple case: one area (almost always area 0), every router in it. ## The four things every OSPF router does 1. **Find neighbors** — Send Hello packets on every OSPF-enabled interface. Other routers respond. If the four matching criteria align (see below), become neighbors. 2. **Build the LSDB** — Exchange Link-State Advertisements (LSAs) with neighbors until both have identical databases of every router, every link, and every cost in the area. 3. **Run SPF** — Locally, compute the shortest path tree from this router as root to every destination. Output: routing table entries. 4. **Re-flood and re-run on change** — When any link changes, the router that owns the change floods a new LSA, every router updates its LSDB, every router re-runs SPF. New routing table in seconds. That's the entire protocol. Everything below is detail. ## The four neighbor-matching criteria For two OSPF routers to form an adjacency, all four must match: 1. **Area ID** — both interfaces must be in the same area. 2. **Hello timer + Dead timer** — must be identical (defaults: 10s hello / 40s dead on broadcast; 30s/120s on NBMA). 3. **Subnet mask on the connected interface** — `/24` on one side and `/30` on the other will never adjacent. 4. **Authentication** — if used, type + key must match. (Plain text or MD5 or HMAC-SHA.) Additional gotcha: **MTU must match** for full adjacency. If MTUs differ, neighbors get stuck in `EXSTART`/`EXCHANGE` forever — Hellos succeed but DBD (Database Descriptor) packets fail. Memorize these five. ~95% of OSPF debug calls boil down to one of them. ## The seven neighbor states ``` Down → Init → 2-Way → ExStart → Exchange → Loading → FULL ``` | State | What's happening | |---|---| | **Down** | No Hellos seen yet | | **Init** | Heard a Hello but the neighbor doesn't list us yet | | **2-Way** | Bidirectional Hellos. Election of DR/BDR happens here (broadcast only). Non-DR/non-BDR pairs stay at 2-Way forever — this is normal. | | **ExStart** | Master/slave election for DBD exchange. Stuck here = MTU mismatch. | | **Exchange** | DBD packets summarizing the LSDB are exchanged | | **Loading** | Requesting individual LSAs the other side has that we don't | | **FULL** | LSDB synchronized. Routes appear. ✓ | For CCNA: recognize 2-Way as "normal between non-DR/BDR pairs on Ethernet" and recognize FULL as the goal. Recognize ExStart/Exchange stuck = MTU. (There's also an **Attempt** state used only on NBMA networks where neighbors are statically configured — the router has tried to send a Hello but hasn't heard one back yet. You won't see it on Ethernet, and the CCNA blueprint focuses on the seven above.) ## OSPF packet types (the five) Hello is the famous one. There are actually five: | # | Type | Purpose | |---|---|---| | 1 | **Hello** | Discover + maintain neighbors. Every 10s on broadcast. | | 2 | **DBD** (Database Descriptor) | Summary of LSDB during sync | | 3 | **LSR** (Link-State Request) | "Give me this specific LSA" | | 4 | **LSU** (Link-State Update) | The actual LSA payload | | 5 | **LSAck** | "Got it" — reliable LSA delivery | OSPF runs directly over IP (protocol number 89), not TCP/UDP. It implements its own reliability via LSAck. ## LSA types — what's in the LSDB The LSDB is a collection of **LSAs** (Link-State Advertisements). Different LSA types describe different things: | Type | Name | What it describes | Scope | |---|---|---|---| | 1 | Router LSA | This router + its links + costs | Area | | 2 | Network LSA | A broadcast segment (e.g., Ethernet with DR) + attached routers | Area | | 3 | Summary LSA | A prefix from another area | Inter-area (multi-area only) | | 4 | ASBR Summary | Location of an ASBR | Inter-area (multi-area only) | | 5 | External LSA | A prefix redistributed from another routing protocol | Domain-wide | | 7 | NSSA External | External LSA inside an NSSA area | NSSA only | For single-area OSPF, you'll see types 1, 2, and 5 (if redistribution exists). Types 3, 4, 7 are multi-area concerns covered in [OSPF Multi-Area](/topics/ospf-multi-area/). ## Router ID — the OSPF identity Every OSPF router has a 32-bit **Router ID** (RID) that identifies it in the protocol. By default: 1. The highest IP on any active **loopback** interface, or 2. If no loopback, the highest IP on any active interface. **Always set it explicitly:** ``` R1(config)# router ospf 1 R1(config-router)# router-id 1.1.1.1 ``` The number after `router ospf` is the **process ID** — locally significant only, doesn't have to match across routers. The Router ID **does** need to be unique across the OSPF domain. If you don't set RID and let it auto-pick, then later add a loopback with a higher IP, the RID changes — which restarts every adjacency, briefly black-holing traffic. Don't leave RID to chance. ## DR and BDR — only matter on broadcast networks On a multi-access broadcast segment (Ethernet with 5 OSPF routers attached), having every router fully adjacent with every other router = O(N²) adjacencies, which doesn't scale. OSPF's solution: elect a **Designated Router** (DR) and **Backup DR** (BDR) per segment. Every other router only forms a full adjacency with the DR/BDR. The DR floods LSAs to everyone on the segment. ### Election rules 1. Highest **OSPF priority** wins (default 1; setting `priority 0` removes the router from election entirely). 2. Tiebreaker: highest **Router ID** wins. 3. **No preemption** — once a DR is elected, a new router showing up does not unseat it. To force a new election, restart OSPF on the segment. ``` R1(config-if)# ip ospf priority 100 ! make this router a strong DR candidate R1(config-if)# ip ospf priority 0 ! remove from election entirely ``` DR/BDR matters less in modern designs because most inter-router OSPF links are point-to-point (no election needed — both routers are simply adjacent). On point-to-point links there's **no DR**. ## Cost — how OSPF picks the best path OSPF's metric is **cost**, derived from interface bandwidth: ``` cost = reference-bandwidth / interface-bandwidth ``` The defaults are bad in 2026: | Reference (Mbps) | 100 Mbps link | 1 Gbps link | 10 Gbps link | 100 Gbps link | |---:|---:|---:|---:|---:| | 100 (default) | 1 | 1 (truncated) | 1 (truncated) | 1 (truncated) | | 100,000 (recommended) | 1,000 | 100 | 10 | 1 | Default reference of 100 Mbps was a 1990s choice. With every interface ≥1 Gbps in modern networks, they all get cost 1 — and OSPF can't distinguish them. **Fix:** raise the reference-bandwidth on every router in the OSPF domain. ``` R1(config-router)# auto-cost reference-bandwidth 100000 ``` (Units: Mbps. 100,000 Mbps = 100 Gbps reference.) Do this on every OSPF router consistently. You can also override per-interface: ``` R1(config-if)# ip ospf cost 50 ``` Useful for traffic engineering when you want to discourage a specific path without lowering the bandwidth. ## Configuration — the two ways ### Network statement (classic) ``` R1(config)# router ospf 1 R1(config-router)# router-id 1.1.1.1 R1(config-router)# network 10.0.12.0 0.0.0.3 area 0 R1(config-router)# network 192.168.1.0 0.0.0.255 area 0 R1(config-router)# passive-interface default R1(config-router)# no passive-interface GigabitEthernet0/0 R1(config-router)# auto-cost reference-bandwidth 100000 ``` - **Wildcard mask** in `network` is the inverse of subnet mask. `0.0.0.3` = /30. `0.0.0.255` = /24. - **`passive-interface default`** is the magic command. By default OSPF tries to form neighbors on every interface where a `network` matches — including user-facing ports. That's a security risk: an attacker on the LAN can send OSPF Hellos and inject routes. `passive-interface default` makes everything passive, then you explicitly un-passive the ones that should peer. ### Per-interface configuration (modern) ``` R1(config)# router ospf 1 R1(config-router)# router-id 1.1.1.1 R1(config-router)# passive-interface default R1(config-router)# auto-cost reference-bandwidth 100000 R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip ospf 1 area 0 R1(config)# interface Loopback0 R1(config-if)# ip ospf 1 area 0 ``` No `network` statements at all. Just enable OSPF on the interfaces you want included, with the area baked in. Cleaner and harder to misconfigure. Both styles work. Modern operational discipline tends toward per-interface. ## Authentication — keep rogue routers out By default OSPF accepts Hellos from anyone speaking the protocol. An attacker on your network can inject Hellos with crafted LSAs that redirect traffic. Three flavors of authentication (in increasing strength): ``` ! Plain text (avoid in production) R1(config-if)# ip ospf authentication R1(config-if)# ip ospf authentication-key MyKey ! MD5 (acceptable on internal networks) R1(config-if)# ip ospf authentication message-digest R1(config-if)# ip ospf message-digest-key 1 md5 MyKey ! HMAC-SHA256 (best, modern IOS-XE) R1(config-if)# ip ospf authentication key-chain OSPF-CHAIN R1(config)# key chain OSPF-CHAIN R1(config-keychain)# key 1 R1(config-keychain-key)# key-string MySecret R1(config-keychain-key)# cryptographic-algorithm hmac-sha-256 ``` In 2026 production: **HMAC-SHA256** on every OSPF-enabled inter-router link. MD5 only if your platform doesn't support SHA. ## Route summarization in single-area In single-area OSPF, summarization is limited — you can only summarize at the boundary between OSPF and another routing source (i.e., on an ASBR): ``` R1(config-router)# summary-address 10.1.0.0 255.255.240.0 ``` This is rare in single-area deployments. The big summarization wins come from **multi-area** OSPF where ABRs summarize between areas. See [Route Summarization](/topics/route-summarization/) and [OSPF Multi-Area](/topics/ospf-multi-area/). ## Verification — the four commands ``` R1# show ip ospf neighbor R1# show ip ospf interface brief R1# show ip route ospf R1# show ip protocols ``` | Command | What it tells you | |---|---| | `show ip ospf neighbor` | Adjacencies + their state. Daily-driver. Want FULL on every neighbor. | | `show ip ospf interface brief` | Which interfaces participate, area, cost, neighbors | | `show ip route ospf` | OSPF-learned routes in the RIB | | `show ip protocols` | Process summary — passive interfaces, networks, reference bandwidth, RID | Deeper diagnostics: ``` R1# show ip ospf database R1# show ip ospf neighbor detail R1# show ip ospf interface Gi0/0 R1# debug ip ospf adj ! careful in production — high volume R1# debug ip ospf events ``` ## Hello + Dead timer interaction — the rare exam trap Default values: - **Broadcast networks (Ethernet):** Hello 10s, Dead 40s (= 4× Hello) - **NBMA networks (Frame Relay, ATM):** Hello 30s, Dead 120s These must match on both ends. If you change Hello on one router, change Dead too — the 4× ratio is convention, not a rule, but mismatched timers between routers prevent adjacency. ``` R1(config-if)# ip ospf hello-interval 5 R1(config-if)# ip ospf dead-interval 20 ``` You won't typically tune these in CCNA-scope networks. They appear on the exam to test whether you know that mismatched timers = no adjacency. ## Network types in OSPF OSPF assigns each interface a **network type**, which affects DR election and timers: | Network type | DR/BDR? | Default Hello/Dead | Default on | |---|---|---|---| | **Broadcast** | Yes | 10s / 40s | Ethernet | | **Point-to-Point** | No | 10s / 40s | Serial (HDLC/PPP), GRE tunnels | | **Point-to-Multipoint** | No | 30s / 120s | Multipoint over NBMA | | **NBMA** | Yes | 30s / 120s | Frame Relay multipoint | You can override: ``` R1(config-if)# ip ospf network point-to-point ``` Useful when you have an Ethernet between exactly two OSPF routers — there's no benefit to DR election. Setting both ends to point-to-point skips election and gets adjacency faster. ## The single-area scaling ceiling Why do networks eventually split into multiple areas? - **LSDB size** — every router holds every LSA in the area. Past ~50 routers the LSDB becomes large enough to slow SPF and consume RAM. - **SPF cost** — Dijkstra is roughly O(N log N) on N nodes. Doubles routers = roughly double SPF time on each. - **Flood scope** — a single link flap floods an LSA to every router in the area. The bigger the area, the more CPU spent on each flap. Multi-area OSPF solves this by limiting LSDB scope to the area and only sharing summarized info across area boundaries. See [OSPF Multi-Area](/topics/ospf-multi-area/) (CCNP-level topic). For single-area: you're good up to ~50 routers in practice. Beyond that, plan multi-area. ## Common mistakes 1. **Mismatched Hello/Dead timers** — most common cause of "no neighbor" calls. Run `show ip ospf interface` on both ends; compare the values. 2. **Mismatched MTU** — stuck in ExStart/Exchange. `show ip ospf interface | i MTU` on both sides. 3. **Wildcard mask in `network` statements** — `0.0.0.255` matches /24, not `255.255.255.0`. Inverse of subnet mask. Get this wrong and OSPF silently doesn't enable on the interface you expected. 4. **Forgetting `passive-interface default`** — OSPF tries to form neighbors on every LAN interface, including user-facing ones. Security risk. Always default to passive and opt-in. 5. **Letting Router ID auto-pick** — adding a loopback later changes RID, which restarts every adjacency. Always hardcode RID. 6. **Default reference-bandwidth = 100 Mbps** — every modern interface gets cost 1. OSPF can't distinguish gigabit from 100 Mbps. Always bump to 100,000 (= 100 Gbps reference) on every router in the domain. 7. **Mixing process IDs and forgetting they're locally significant** — `router ospf 1` on R1 and `router ospf 99` on R2 work fine as long as their interfaces match on the other four criteria. Process ID does NOT need to match across routers. 8. **Forgetting that DR/BDR has no preemption** — adding a new "preferred" router doesn't displace the current DR. Either configure priority before connecting, or accept the existing election. 9. **Authentication mismatch** — one side has it, the other doesn't, or wrong key. Silent failure. 10. **Trying to summarize in single-area without an ASBR** — `area X range` only works on an ABR. In single-area, you only have one area; no ABRs exist. ## Worked scenarios --- **Scenario 1.** R1 and R2 are directly connected via Ethernet. R1 has Hello 10s/Dead 40s. R2 has Hello 5s/Dead 20s. Both in area 0. Both have unique RIDs. Do they form an adjacency? **Answer:** No. Timers must match. They'll exchange Hellos but never reach 2-Way. Fix: align timers on both sides. --- **Scenario 2.** R1 (Gi0/0 = 10.0.0.1/30, area 0) is connected to R2 (Gi0/0 = 10.0.0.2/30, area 1). Will they form an adjacency? **Answer:** No. Different areas. Even though same subnet/mask/timers, area mismatch fails the four-criteria test. --- **Scenario 3.** R1, R2, R3 share an Ethernet segment. All in area 0. All have priority 0. What happens? **Answer:** All three are priority 0 → none eligible for DR election → no DR/BDR is elected → adjacencies stuck in 2-Way → routes never appear. Fix: set at least one router to priority > 0. --- **Scenario 4.** R1 has a Loopback `1.1.1.1/32` you want to advertise in OSPF. You configure `network 1.1.1.1 0.0.0.0 area 0`. Will it advertise the /32? **Answer:** Yes — but it advertises as a /32 host route by default. To advertise the actual loopback's mask (still /32 here), change the OSPF network type on the loopback to `point-to-point`: ``` R1(config-if)# ip ospf network point-to-point ``` (For loopbacks of mask /24 or larger this matters more — without `point-to-point`, OSPF advertises the loopback as /32 regardless of configured mask.) --- **Scenario 5.** Two routers are stuck in ExStart. RID, area, timers, mask all match. What's the most likely cause? **Answer:** MTU mismatch. Run `show ip ospf interface | i MTU` on both sides. The DBD packet's MTU field has to match. --- **Scenario 6.** R1 sees a route via OSPF cost 3. R2 advertises the same route via EIGRP. Which wins? **Answer:** EIGRP. Administrative Distance (AD) ranks routing sources before metric. EIGRP AD = 90; OSPF AD = 110. Lower AD wins → EIGRP is preferred regardless of metric values. See [Routing Decision Process](/topics/routing-decision-process/). --- **Scenario 7.** You want to make sure OSPF Hellos never reach the user-facing VLAN gateway interface. How? **Answer:** ``` R1(config-router)# passive-interface Vlan10 ``` Or set passive-default and explicitly un-passive only the interfaces you trust: ``` R1(config-router)# passive-interface default R1(config-router)# no passive-interface Gi0/0 ! only inter-router link ``` The interface is still advertised in OSPF but doesn't send Hellos. --- **Scenario 8.** You raised reference-bandwidth to 100,000 on R1 but not R2. Symptoms? **Answer:** Both routers continue forming adjacencies (reference-bandwidth doesn't affect Hello matching). But they disagree on costs. Each computes SPF locally with its own cost view — so R1 picks one path, R2 picks another. Asymmetric routing results. Fix: align reference-bandwidth on every router in the domain. ## Lab to try tonight 1. **Triangle topology** — three routers (R1, R2, R3) connected in a full triangle. Each has a loopback (1.1.1.1, 2.2.2.2, 3.3.3.3). 2. **Enable OSPF** on all three with area 0. Hardcode router IDs to the loopbacks. Enable `passive-interface default`, then un-passive the inter-router interfaces. 3. **Bump reference-bandwidth** to 100,000 on all three. 4. **Verify neighbors** — `show ip ospf neighbor` on each. You should see two FULL neighbors per router. 5. **Verify routes** — `show ip route ospf` — you should see the loopbacks of the other two routers learned via OSPF. 6. **Test convergence** — `shutdown` one inter-router link. Time how long until traffic re-routes (should be 1–5 seconds). `no shutdown` and verify reconvergence. 7. **Cost tuning** — `ip ospf cost 50` on one link. Verify the path selection changes with `show ip route ospf`. 8. **Authentication** — enable HMAC-SHA-256 on R1↔R2 only. Watch the adjacency drop until R2 also has it. Restore. 9. **MTU trap** — change MTU on one interface (`mtu 1400`). Watch neighbors stick in ExStart. Restore. 10. **Bonus: priority tuning** — convert R1↔R2 to a broadcast Ethernet segment with a 3rd router on the same segment. Force R1 to be DR via `ip ospf priority 200`. Verify with `show ip ospf interface`. ## Cheat strip | Concept | Plain English | |---|---| | **Link-state** | Every router learns the whole map, then runs SPF locally | | **LSDB** | The map — collection of LSAs | | **SPF / Dijkstra** | The algorithm each router runs on its LSDB to compute paths | | **Area 0** | The backbone. Single-area = everyone is here. | | **Router ID** | Unique 32-bit ID per router. Always hardcode it. | | **Process ID** | Locally significant only — does NOT need to match across routers | | **Hello / Dead timers** | 10/40 broadcast, 30/120 NBMA. Must match between neighbors. | | **Wildcard mask** | Inverse of subnet mask. Used in `network` statements | | **`passive-interface default`** | Security best practice — opt-in to OSPF peering per interface | | **Four matching criteria** | Area · timers · mask · authentication. MTU also for FULL adjacency | | **Seven states** | Down → Init → 2-Way → ExStart → Exchange → Loading → FULL | | **2-Way is normal** | Between non-DR/non-BDR pairs on Ethernet | | **Stuck in ExStart** | MTU mismatch — fix on both sides | | **DR / BDR** | Only on broadcast networks. Priority 0 = ineligible. No preemption. | | **Cost = bw_ref / bw_iface** | Default ref = 100 Mbps (bad). Bump to 100,000 on every router | | **AD** | OSPF AD = 110. Lower AD wins against other sources | | **LSA types in single-area** | Type 1 (Router), Type 2 (Network), Type 5 (External if redistribution) | | **Authentication** | HMAC-SHA-256 in 2026 production; MD5 acceptable on internal; never plaintext | | **Scaling ceiling** | ~50 routers per area before SPF cost forces multi-area design | ## Frequently asked questions **Q: What's an area 0 backbone?** A: OSPF's central area — every other area must connect to it (physically or via a virtual link). All inter-area traffic transits area 0. In a single-area design, everything is in area 0 by convention. Multi-area design puts area 0 in the core/distribution layer with branch or campus areas attached. Splitting into areas reduces LSA flooding and SPF calculation load. **Q: How does OSPF elect a DR and BDR?** A: On multi-access networks (Ethernet), OSPF elects a Designated Router to reduce adjacency count — all other routers form full adjacency only with the DR (and BDR). Election: highest OSPF priority wins (default 1); tiebreak on highest router-ID. Priority 0 means "never be DR." DR is sticky — once elected, it stays until it fails, even if a "better" router shows up. On point-to-point links there's no DR/BDR. **Q: What OSPF LSA types should I know for CCNA?** A: Type 1 (Router LSA) — describes a router's interfaces, flooded within an area. Type 2 (Network LSA) — describes a multi-access segment, generated by the DR. Type 3 (Summary LSA) — inter-area routes, generated by ABRs. Type 5 (External LSA) — redistributed external routes, generated by ASBRs. Types 4, 6, 7, 8+ exist but are outside CCNA scope. **Q: Why isn't OSPF forming adjacency?** A: Ranked by frequency: (1) Area mismatch — both interfaces must be in the same area. (2) MTU mismatch — routers stall in EXSTART/EXCHANGE state. (3) Hello/dead timer mismatch. (4) Authentication mismatch. (5) Network-type mismatch (point-to-point on one side, broadcast on the other). (6) Subnet mask mismatch on the neighbouring interfaces. `debug ip ospf adj` shows exactly where it fails. **Q: What's the OSPF router-ID and how is it chosen?** A: A 32-bit number that uniquely identifies each OSPF router. Selection order: (1) manually configured via `router-id X.X.X.X` — always wins. (2) Highest IP on any active loopback interface. (3) Highest IP on any other active interface. Best practice: always manually set the router-ID at OSPF config time — never leave it to auto-selection, which changes when interfaces come and go. --- ## EIGRP — https://packetmentor.com/topics/eigrp/ > Cisco's hybrid routing protocol — distance-vector smarts with link-state speed. Covers the DUAL algorithm, successor vs feasible successor, the metric formula, and why EIGRP recovers from failures in milliseconds. ## Mental model EIGRP is the protocol that takes the best of both routing-protocol families and avoids their worst sins. - From **distance-vector** (RIP-style): simple, no link-state database, just trust your neighbors' summaries. - From **link-state** (OSPF-style): fast convergence, no routing loops, smart algorithm. The killer feature: **DUAL** (Diffusing Update Algorithm) keeps a backup path ready in the routing table. When the primary fails, EIGRP doesn't have to flood updates and re-compute — it instantly switches to the backup. Sub-second convergence is normal. EIGRP was Cisco-only for two decades. Cisco opened it in 2013 (RFC 7868). It's still mostly seen in Cisco-only environments — multi-vendor networks default to OSPF. ## The metric EIGRP's metric is a formula combining up to five values weighted by K-constants. In practice only two matter: ``` metric ≈ (10^7 / minimum-bandwidth + total-delay) × 256 ``` - **Bandwidth** — the slowest link in the path, in Kbps - **Delay** — sum of interface delays, in tens of microseconds **Don't touch the K-values.** The K1–K5 constants control which factors are weighted. Defaults are K1=K3=1, everything else 0 — bandwidth + delay. Mismatched K-values between neighbors prevents adjacency formation. Just leave them alone. ## Successor vs Feasible Successor (THE concept) EIGRP terms that confuse everyone: - **Successor** — the *primary* next-hop for a destination. The route that goes in the routing table. - **Feasible Successor (FS)** — a *backup* next-hop, pre-validated as loop-free. For a backup path to qualify as a Feasible Successor, it must satisfy the **Feasibility Condition (FC)**: > The neighbor's reported distance to the destination must be LESS than my distance to the destination via the successor. In English: the backup neighbor must already be closer to the destination than I am (via my primary path). If yes, taking that route can't cause a loop, so it's safe to pre-install as backup. When the successor dies, EIGRP doesn't have to ask anyone — it knows the FS is loop-free and starts using it immediately. ## Commands ### Basic config (classic, with `network` statements) ``` R1(config)# router eigrp 100 R1(config-router)# eigrp router-id 1.1.1.1 R1(config-router)# network 10.0.12.0 0.0.0.3 R1(config-router)# network 10.0.13.0 0.0.0.3 R1(config-router)# network 192.168.1.0 0.0.0.255 R1(config-router)# passive-interface default R1(config-router)# no passive-interface GigabitEthernet0/0 ``` **AS number `100`** must match on every router for them to form neighbors. Unlike OSPF process IDs, this matters. ### Named-mode config (the modern way) ``` R1(config)# router eigrp CORP R1(config-router)# address-family ipv4 unicast autonomous-system 100 R1(config-router-af)# eigrp router-id 1.1.1.1 R1(config-router-af)# network 10.0.0.0 0.255.255.255 R1(config-router-af)# af-interface default R1(config-router-af-interface)# passive-interface R1(config-router-af)# af-interface GigabitEthernet0/0 R1(config-router-af-interface)# no passive-interface ``` Named mode is more readable and required for some advanced features. Either form works for CCNA. ## Verification ``` R1# show ip eigrp neighbors R1# show ip eigrp topology R1# show ip eigrp interfaces R1# show ip route eigrp ``` - `show ip eigrp neighbors` — your bidirectional partners. Should show your peers in `up` state. - `show ip eigrp topology` — successors and feasible successors. If you see `FD/RD` columns, you're looking at the heart of DUAL. - `show ip route eigrp` — routes EIGRP installed in the routing table. ## Common mistakes 1. **Mismatched AS numbers.** Two routers running EIGRP on the same wire with different AS numbers won't form a neighborship. Easy mistake, silent failure. Check `show ip eigrp neighbors`. 2. **Wildcard mask backwards.** Same trap as ACLs and OSPF — wildcard is the inverse of subnet mask. For a /24 it's `0.0.0.255`, not `255.255.255.0`. 3. **Touching K-values.** Don't. They must match between neighbors. The defaults are correct for 99% of cases. 4. **Forgetting `passive-interface default`.** Like OSPF, EIGRP tries to form neighbors on every interface. A user-facing port is a security risk. Always default to passive, then explicitly enable peering. 5. **Using `auto-summary` on classless networks.** EIGRP used to auto-summarize at classful boundaries (10.0.0.0/8 etc.). This is wrong on modern networks. `no auto-summary` is the default on IOS 15+, but verify on older gear. 6. **Setting feasible successor expectations too high.** Not every destination has an FS — it depends on the topology. Without an FS, EIGRP falls back to the slower diffusing-update process (called "going active") when the successor fails. ## Lab to try tonight 1. Three routers in a triangle. Each with a loopback (1.1.1.1, 2.2.2.2, 3.3.3.3) and /30 links between them. 2. Configure EIGRP AS 100 on all three. Hardcode router IDs. Set `passive-interface default`, then enable only the WAN-facing interfaces. 3. Run `show ip eigrp neighbors` on each. Two neighbors per router. 4. Run `show ip eigrp topology` for the loopback of one router. Identify successor and feasible successor (if any). 5. Bring down a link between two routers. Watch `show ip route eigrp` re-converge — typically sub-second. 6. Bonus: increase a link's delay with `delay ` on the interface. Watch the metric change and the path selection adjust. ## Cheat strip | Concept | Plain English | |---|---| | **DUAL** | Diffusing Update Algorithm — pre-computes backup paths | | **AS number** | Must match on all routers for neighborship | | **Successor** | Primary next-hop, in the routing table | | **Feasible Successor (FS)** | Pre-validated backup, available for instant failover | | **Feasibility Condition** | Backup's reported distance < my distance via primary | | **Hello / Hold timers** | Default 5s / 15s on LAN, 60s / 180s on slow WAN | | **Metric** | Bandwidth + delay (default K-values). Leave K-values alone. | | **AD** | 90 (internal EIGRP), beats OSPF (110), RIP (120), but loses to static (1) | ## Frequently asked questions **Q: Is EIGRP still Cisco-only?** A: No — Cisco released EIGRP as an informational RFC (RFC 7868) in 2013, so other vendors *can* implement it. In practice, adoption outside Cisco is minimal — you'll see EIGRP in Cisco-heavy shops, OSPF or BGP everywhere else. If you're multi-vendor, use OSPF. **Q: How does EIGRP compute the metric?** A: A composite of bandwidth and delay by default (with K-values K1=K3=1, K2=K4=K5=0). Bandwidth: uses the slowest link along the path. Delay: sum of all interface delays. Formula: `metric = (10^7 / min bandwidth + sum delays) * 256`. Complicated on paper, but the practical rule is: EIGRP prefers higher bandwidth, then lower delay. K-values can be tuned, but never change them without full understanding — mismatched K-values break neighbour formation. **Q: What's a feasible successor?** A: EIGRP's backup path. The *successor* is the best path (installed in the routing table). A *feasible successor* is a backup — a path whose reported distance (the neighbour's cost) is less than the successor's total distance (the feasibility condition). If the successor fails, EIGRP switches to the feasible successor instantly, no recomputation. This is why EIGRP claims sub-second convergence. **Q: When would I use EIGRP over OSPF?** A: All-Cisco environment where you want simpler config (EIGRP is easier to configure than OSPF's area design), unequal-cost load balancing (EIGRP supports it natively; OSPF doesn't), or better convergence on flapping links. Use OSPF for multi-vendor, larger scale (10+ routers where area design matters), or when hiring — most job postings list OSPF, few list EIGRP. **Q: Why won't my EIGRP neighbours form?** A: Common causes in order of frequency: (1) AS numbers don't match — both routers must be in the same EIGRP AS. (2) K-values differ. (3) Authentication mismatch. (4) Layer 2 issue — routers can't reach each other's multicast (224.0.0.10). (5) MTU mismatch. `debug eigrp packets` shows what's happening; `show ip eigrp neighbors` should list the neighbour if they're up. --- ## Route Summarization — https://packetmentor.com/topics/route-summarization/ > Why aggregating many specific routes into one shorter prefix shrinks route tables, speeds convergence, and limits the blast radius of a flapping link. Covers manual, OSPF, and EIGRP summarization. ## Mental model You have 16 sites. Each is `10.1.X.0/24` where X = 0 through 15. Without summarization, every router in your network learns 16 separate routes. With summarization, the router that owns those 16 sites advertises just one route: `10.1.0.0/20`. Why does this matter? - **Route table memory.** A backbone router carrying 100k routes uses real CPU/RAM. Cutting that to 10k makes a tangible difference. - **Convergence speed.** When a link flaps, every affected router runs SPF (OSPF) or diffusing-update (EIGRP). Fewer route entries = faster recompute. - **Blast radius.** Without summarization, a flap of site 7's link injects a withdrawal/readvertisement update across the entire network. With summarization, the flap stays local — the summary stays advertised as long as *any* child is up. ## How to find the summary prefix The mechanic is the reverse of subnetting. Find the longest prefix that covers all your specific routes. For `10.1.0.0/24` through `10.1.15.0/24`: 1. Look at the third octet (the changing one): `0, 1, 2, … 15`. 2. In binary: `00000000` to `00001111`. The first 4 bits are constant (`0000`); the last 4 change. 3. The constant bits + the constant first two octets = `8 + 8 + 4 = 20` bits. 4. Summary = `10.1.0.0/20`. Quick check: a `/20` covers `2^(32-20) = 4096` addresses = `16` subnets of `/24`. ✓ ## Manual summarization on a static route ``` ! Instead of 16 static routes... R1(config)# ip route 10.1.0.0 255.255.255.0 10.0.0.2 R1(config)# ip route 10.1.1.0 255.255.255.0 10.0.0.2 ! ... R1(config)# ip route 10.1.15.0 255.255.255.0 10.0.0.2 ! ...use one summary R1(config)# ip route 10.1.0.0 255.255.240.0 10.0.0.2 ``` ## OSPF summarization OSPF summarizes only at area boundaries — at an ABR (between areas) or ASBR (redistribution into OSPF). **At an ABR (inter-area summarization)** — summarize a chunk of Area 1's prefixes before they leak into Area 0: ``` R1(config)# router ospf 1 R1(config-router)# area 1 range 10.1.0.0 255.255.240.0 ``` **At an ASBR (external summarization)** — summarize redistributed routes: ``` R1(config-router)# summary-address 10.1.0.0 255.255.240.0 ``` Note: OSPF intentionally does **not** summarize at arbitrary routers inside an area — all routers in an area must see the same intra-area LSDB. ## EIGRP summarization EIGRP can summarize **anywhere** — at any interface, on any router — which makes it more flexible than OSPF. ``` R1(config)# interface Gi0/1 R1(config-if)# ip summary-address eigrp 100 10.1.0.0 255.255.240.0 ``` EIGRP automatically inserts a **summary discard route** (route to Null0) on the summarizing router. This prevents loops if a packet for `10.1.99.0/24` (which doesn't exist) arrives — it hits Null0 and drops, instead of being forwarded back upstream. ## The black-hole gotcha This is the cost of summarization. Suppose `R1` advertises `10.1.0.0/20` covering child sites 0-15. Site 7's link goes down — `R1` no longer has a path to `10.1.7.0/24`. But **`R1` still advertises the summary `10.1.0.0/20`** as long as any child is up. Result: a packet for `10.1.7.0/24` travels across the network to `R1`, then `R1` has no specific route → it hits the summary discard route (Null0) and drops. This is **better than a routing loop** but still a black hole. Acceptable trade-off — but be aware. ## Auto-summarization (EIGRP/RIP) Historically, EIGRP and RIP auto-summarized at classful boundaries (`/8`, `/16`, `/24`) — usually wrong in modern networks. Always disable: ``` R1(config-router)# no auto-summary ``` In recent IOS this is the default. CCNA still tests the concept. ## Verification ``` R1# show ip route ospf ! Look for "is a summary, 00:01:23, Null0" R1# show ip route 10.1.0.0 R1# show ip eigrp topology summary R1# show ip route 10.1.0.0 longer-prefixes ! See all child routes ``` ## Common mistakes 1. **Overlapping summaries.** Two routers each summarize half of the same range, but their summaries overlap or one covers the other. Longest-prefix-match wins, which may not be what you wanted. 2. **Summarizing a non-contiguous range.** `10.1.0.0/24` and `10.1.15.0/24` (with 1-14 belonging to a different site) cannot be cleanly summarized — a `/20` would steal traffic for the in-between subnets. 3. **Forgetting `no auto-summary`** on EIGRP/RIP in older lab IOS — auto-summary collapses your `10.1.x.x` advertisements down to `10.0.0.0/8`, causing havoc. 4. **OSPF summarization at non-boundary routers.** OSPF only summarizes at ABRs/ASBRs. Trying it on an internal router silently does nothing. 5. **Math error on the mask.** `/22` covers 4 subnets, `/21` covers 8, `/20` covers 16, `/19` covers 32. Double-check by counting. 6. **Forgetting that the summary is null-routed.** The Null0 discard route is a feature, not a bug — but if you wonder why pings for a non-existent child fail silently instead of returning ICMP unreachable, that's it. ## Lab to try tonight 1. Build a 3-router topology in CML. R1 owns six `/24`s: `10.1.0.0/24` through `10.1.5.0/24`. 2. Run OSPF area 1 between R1 and R2 (the ABR). Run area 0 between R2 and R3. 3. Without summarization: on R3, `show ip route` shows 6 separate `O IA` entries. 4. Add `area 1 range 10.1.0.0 255.255.248.0` on R2. 5. On R3: `show ip route` shows just one `O IA 10.1.0.0/21`. Memory savings × scale = real impact. 6. Shut down R1's `Lo1` (`10.1.1.0/24`). Verify R3 still sees the summary; packets for `10.1.1.5` reach R1 and hit Null0. 7. Bonus: redo on EIGRP using `ip summary-address eigrp 100 ...` on an interface. Compare behavior. ## Cheat strip | Concept | Plain English | |---|---| | **Summarization** | Replace many specific routes with one shorter prefix | | **Why bother** | Smaller route tables, faster convergence, smaller blast radius | | **Static summary** | One `ip route` with a shorter mask covering all children | | **OSPF where** | At ABR (`area X range`) or ASBR (`summary-address`) — boundary routers only | | **EIGRP where** | Anywhere (`ip summary-address eigrp` on an interface) | | **Discard route** | EIGRP auto-installs a Null0 route to catch summary-but-no-child packets | | **Auto-summary** | Always `no auto-summary` on EIGRP/RIP — classful summary is rarely what you want | | **Trade-off** | Summarized prefix stays advertised even when some children are down → black-holing | --- ## Cisco IOS File System — https://packetmentor.com/topics/ios-file-system/ > Where Cisco IOS stores configs, images, and logs — flash:, nvram:, system:, tftp:. Covers copy syntax, image management, boot variables, and the file-system commands you actually use day-to-day. > **Scope note:** this page covers the **Cisco-side** file-system model — `flash:` / `nvram:` / `system:`, `copy` syntax, `boot system`, `config-register`, image management. For the TFTP / FTP protocols themselves (how they work on the wire, when to pick each), see the companion topic → [TFTP & FTP: Network File Transfer Basics](/topics/tftp-ftp-basics/). ## Mental model Cisco IOS treats every storage location as a **named file system**, the way Unix treats `/`, `/proc`, `/dev`, etc. as mount points. You move data between them using `copy`. The four you'll use 95% of the time: | Device | What lives there | Volatile? | |---|---|---| | `system:` | running-config — the live config in RAM | Yes — gone on reload | | `nvram:` | startup-config — what's loaded next boot | No | | `flash:` | IOS image (.bin), license files, sometimes archived configs | No | | `tftp:` / `ftp:` / `scp:` / `http:` | Remote servers — for image transfers, backups | n/a | Modern devices (3850/9300/9500/ISR4xxx) add `bootflash:`, `usbflash0:`, `harddisk:`, but the mental model is identical. ## The four-line summary ``` Router# show file systems Router# dir flash: Router# copy running-config startup-config Router# copy tftp: flash: ``` If you understand those four commands, you understand 80% of IOS file-system work. ## `show file systems` — the directory of devices ``` Router# show file systems File Systems: Size(b) Free(b) Type Flags Prefixes - - opaque rw system: - - opaque rw tmpsys: - - network rw tftp: * 256487424 192385024 disk rw flash: 4096 4055 nvram rw nvram: - - opaque rw bs: - - network rw ftp: - - network rw http: - - network rw scp: ``` The `*` marks the **default file system** — commands like `dir`, `cd`, `delete` use this if no device is specified. Usually `flash:`. ## `dir` — list files ``` Router# dir flash: Directory of flash:/ 1 -rw- 67541040 Mar 12 2026 09:14:00 +00:00 c2900-universalk9-mz.SPA.157-3.M5.bin 2 -rw- 492 Apr 02 2026 11:22:30 +00:00 startup-config.backup 3 -rw- 1242 May 18 2026 14:55:01 +00:00 vlan.dat 256487424 bytes total (192385024 bytes free) ``` You see the IOS `.bin` image, occasional backups, and `vlan.dat` (the VLAN database — stored separately from running-config). ## `copy` — the universal move command ``` copy : : ``` **The day-one one you must know:** ``` Router# copy running-config startup-config ``` This saves your live config to NVRAM so it persists across reboots. Short forms: `write memory`, `wr`. **Other essential copies:** ``` ! Back up running-config to a TFTP server Router# copy running-config tftp: Address or name of remote host []? 10.0.99.5 Destination filename [running-config]? R1-2026-05-25.cfg ! Restore startup-config from TFTP Router# copy tftp: startup-config ! Upload new IOS image Router# copy tftp: flash: Address or name of remote host []? 10.0.99.5 Source filename []? c2900-universalk9-mz.SPA.158-3.M2.bin ``` `copy` prompts interactively. If you've ever scripted Cisco devices, you'll learn to script the answers. ## Image management — upgrading IOS ``` ! 1. Download new image to flash R1# copy tftp: flash: ! ...answer prompts... ! 2. Verify integrity (checksum vs Cisco's published MD5) R1# verify /md5 flash:c2900-universalk9-mz.SPA.158-3.M2.bin ! 3. Tell the router which image to boot R1(config)# no boot system ! remove any old boot statements R1(config)# boot system flash:c2900-universalk9-mz.SPA.158-3.M2.bin ! 4. Save and reload R1# write memory R1# reload ``` **`boot system` order matters.** Multiple `boot system` statements act as a fallback list — first found, first booted. Newest image typically goes first. **Free up flash before downloading** — if disk is full, the transfer fails: ``` R1# delete flash:c2900-universalk9-mz.SPA.156-3.M0.bin R1# squeeze flash: ! reclaim deleted blocks on older devices ``` ## Boot-time decision tree What happens at power-on: 1. **Power-on Self Test (POST)** — basic hardware check. 2. **Bootstrap** loads from ROM, reads the **config register**. 3. Config register tells the bootstrap where to look for IOS: - `0x2102` (default) — boot IOS as specified by `boot system` commands in startup-config. - `0x2120` / `0x0000` — boot to ROMMON instead. - `0x2142` — boot IOS but **skip startup-config** (used in password recovery — see [Password Recovery](/topics/password-recovery/)). 4. IOS loads. If `boot system` exists in startup-config, that image. If not, first valid `.bin` in flash. 5. **Startup-config** copied from `nvram:` into `system:` (running-config in RAM) — unless register said skip. 6. Prompt appears. See also [Catalyst Boot Process](/topics/catalyst-boot-process/) for the switch-specific flow. ## Archiving configs — built-in IOS feature For audit logs / change tracking, IOS can auto-archive each `write memory`: ``` R1(config)# archive R1(config-archive)# path flash:/configs/R1-config R1(config-archive)# maximum 14 R1(config-archive)# write-memory R1# show archive ! shows the archive history R1# show archive config differences flash:/configs/R1-config-1 flash:/configs/R1-config-2 ``` Per-version diffs straight from the CLI. Very handy when troubleshooting "what changed." ## SCP vs TFTP — security upgrade TFTP is unauthenticated, plain text, UDP 69. Fine for a closed lab; never use across the internet. **SCP** uses SSH for transport (TCP 22, encrypted, authenticated): ``` R1(config)# ip scp server enable ! From another device or laptop scp R1-2026-05-25.cfg admin@10.0.0.1:flash: ``` Always prefer SCP in 2026 production environments. ## Verification ``` Router# show version ! shows running image, boot variable Router# show flash: ! flash contents Router# show file systems Router# show boot ! current boot variable Router# show archive ! config archive history ``` ## Common mistakes 1. **`copy startup-config running-config` vs `copy running-config startup-config`** — easy to swap. Source comes first. Running → startup saves. Startup → running merges (does NOT overwrite — it **adds**). 2. **Flash full during upgrade.** Always check `dir flash:` for free space *before* downloading. A failed mid-transfer can leave a corrupt image. 3. **Forgetting to verify MD5.** Corrupted image installs → device boots into ROMMON loop. Always run `verify /md5` against the value published on cisco.com. 4. **Missing `boot system`.** No boot statement → router boots the first `.bin` it finds in flash, alphabetically. Could be an ancient backup image. Always set it explicitly. 5. **Treating `vlan.dat` like running-config.** VLAN database lives in `flash:vlan.dat`, separate from startup-config. Restoring a config without VLAN.dat means VLANs vanish. Backup both. 6. **TFTP across the internet.** Plain-text config including passwords flying over public links. Career-ending if it sniffs. Use SCP. 7. **Naming images stuff like `image.bin`.** Keep the original Cisco filename — it encodes platform, feature set, and version. Renaming hides info from `show version`. ## Lab to try tonight 1. In Packet Tracer / CML / real router, run `show file systems`. Identify each device. 2. `dir flash:` — note the IOS filename. 3. Make a small config change (e.g., `interface Lo99` with description). `do show running-config | section Loopback99`. 4. `copy running-config startup-config`. Reload. Verify the loopback survived. 5. Set up a TFTP server on your laptop (tftpd64 on Windows, `tftp-hpa` on Linux). `copy running-config tftp:` to back up the device. 6. Edit the backup file in a text editor. Change a description. `copy tftp: running-config` to re-apply. 7. Bonus: enable IOS archive (`archive` + `path flash:/configs/$h-config` + `write-memory`). Do three `write memory` calls. `show archive config differences` between two versions. 8. Bonus: enable SCP server, transfer a file from your laptop using `scp`. ## Cheat strip | Concept | Plain English | |---|---| | **`system:`** | Running-config in RAM — volatile | | **`nvram:`** | Startup-config — persists across reboots | | **`flash:`** | IOS image and other persistent storage | | **`copy A B`** | Move/duplicate file from A to B (interactive prompts) | | **`write memory`** | Shorthand for `copy running-config startup-config` | | **`boot system flash:...`** | Tells router which IOS image to load on boot | | **Config register `0x2102`** | Default — load startup-config on boot | | **`verify /md5`** | Check downloaded image integrity vs Cisco's published hash | | **`archive`** | Built-in auto-archive of configs at each save | | **`vlan.dat`** | VLAN database in flash — separate from startup-config | | **SCP > TFTP** | Use SCP in production — TFTP is plain text | --- ## IPv6 SLAAC & DHCPv6 — https://packetmentor.com/topics/ipv6-slaac/ > Two ways an IPv6 host gets an address. SLAAC has hosts auto-generate from a router-advertised prefix. DHCPv6 mirrors IPv4 DHCP. Covers RA/RS messages, EUI-64, privacy addresses, and stateful vs stateless DHCPv6. ## Mental model IPv4 hosts get addresses from DHCP almost universally. IPv6 has the same option (DHCPv6), but it also has a built-in alternative: hosts can derive their own address from information broadcast by the local router. That alternative is **SLAAC** — Stateless Address Autoconfiguration. The router doesn't need to track who has which address. It just advertises *"the prefix on this link is `2001:db8:1::/64`"* and hosts handle the rest: 1. Host generates a 64-bit interface ID (either EUI-64 from its MAC, or random for privacy). 2. Host combines `2001:db8:1::` + interface ID = its full IPv6 address. 3. Host runs **DAD** (Duplicate Address Detection) to check no one else has the same address. 4. If unique, host starts using it. If duplicate, regenerate. That's the entire SLAAC flow. No state on the router, no DHCP server required. ## The four message types — Router Advertisement & Solicitation SLAAC uses ICMPv6 (not a separate protocol): | Type | Direction | Purpose | |---|---|---| | **RS** (Router Solicitation, type 133) | host → routers (multicast ff02::2) | "Anyone listening? I need an RA now, don't make me wait." | | **RA** (Router Advertisement, type 134) | router → hosts (multicast ff02::1) | "I'm the router. Here's the prefix, default gateway info, M/O flags." | | **NS** (Neighbor Solicitation, type 135) | host → multicast | DAD: "Is anyone already using this address?" | | **NA** (Neighbor Advertisement, type 136) | host → host | "Yes I have that address" (DAD reply) | Routers send RAs unsolicited at regular intervals (default every 200 seconds on Cisco). Hosts that boot in between can multicast an RS to get one immediately. ## The M and O flags The Router Advertisement carries two key flags that tell hosts how to behave: | M flag | O flag | Meaning | |---|---|---| | 0 | 0 | **Pure SLAAC** — host gets address from prefix only. No DNS info. | | 0 | 1 | **SLAAC + stateless DHCPv6** — host gets address from prefix, but asks DHCPv6 for DNS / domain info | | 1 | 0/1 | **Stateful DHCPv6** — host asks a DHCPv6 server for everything (address + DNS). Like IPv4. | For CCNA: know these flag combinations. M=0 O=1 is the most common "real network" setup — addresses via SLAAC, DNS info via DHCPv6. ## EUI-64 — the deprecated way to generate interface IDs The original SLAAC method derives the interface ID from the host's MAC address: ``` MAC: 00:11:22:33:44:55 Split: 00:11:22 : 33:44:55 Insert FFFE: 00:11:22:FF:FE:33:44:55 Flip U/L bit: 02:11:22:FF:FE:33:44:55 Final addr: ::0211:22FF:FE33:4455 (combined with /64 prefix) ``` The first byte's 7th bit gets flipped. Why? Don't worry about it for the exam — just know: - EUI-64 IDs are derived from the MAC - They're stable (same MAC → same interface ID forever) - That means **trackable across networks**, which is a privacy concern - Modern OSes (Windows 10+, macOS, Linux with NetworkManager) generate random interface IDs by default instead — **privacy addresses (RFC 4941)** ## Privacy addresses Because EUI-64 makes you trackable, modern hosts generate a random interface ID: ``` Prefix: 2001:db8:1::/64 Random suffix: ::abcd:1234:5678:9abc Full address: 2001:db8:1:0:abcd:1234:5678:9abc ``` Rotates daily by default. The original EUI-64 address still exists for incoming connections; the random one is used for outbound. Hosts may have multiple IPv6 addresses simultaneously — totally normal. ## Stateful DHCPv6 — when you need IPv4-like behavior If you need to track which device got which address (for audit logs, IP-pinning, etc.), SLAAC isn't enough. **DHCPv6** in stateful mode handles this — and is the only option for some Windows scenarios that don't fully support SLAAC. Trigger it by setting the **M flag = 1** in the router advertisement: ``` R1(config-if)# ipv6 nd managed-config-flag ! set M flag R1(config-if)# ipv6 nd other-config-flag ! set O flag (optional) ``` Then point hosts at a DHCPv6 server, configured similarly to IPv4 DHCP but with `ipv6` keywords. ## Commands — typical SLAAC setup ``` ! Enable IPv6 routing globally R1(config)# ipv6 unicast-routing ! Assign a global address to the LAN interface R1(config)# interface GigabitEthernet0/0 R1(config-if)# ipv6 address 2001:db8:acad:1::1/64 R1(config-if)# no shutdown ! Configure RA settings (optional — defaults work for pure SLAAC) R1(config-if)# ipv6 nd ra interval 200 ! RA every 200s (default) R1(config-if)# ipv6 nd prefix 2001:db8:acad:1::/64 valid-lifetime 86400 preferred-lifetime 43200 ``` That's it. Hosts on the link will pick up `2001:db8:acad:1::xxxx` automatically. ## Stateless DHCPv6 — SLAAC + DNS info ``` R1(config)# ipv6 unicast-routing ! Enable DHCPv6 server with DNS info only R1(config)# ipv6 dhcp pool DHCP-STATELESS R1(config-dhcpv6)# dns-server 2001:4860:4860::8888 R1(config-dhcpv6)# domain-name corp.local R1(config)# interface GigabitEthernet0/0 R1(config-if)# ipv6 address 2001:db8:acad:1::1/64 R1(config-if)# ipv6 dhcp server DHCP-STATELESS R1(config-if)# ipv6 nd other-config-flag ! O flag = "use DHCPv6 for DNS" ``` ## Verification ``` R1# show ipv6 interface GigabitEthernet0/0 R1# show ipv6 neighbors R1# show ipv6 dhcp pool R1# debug ipv6 nd ! while troubleshooting RAs ``` On a host: `ipconfig /all` (Windows) or `ip -6 addr` (Linux) shows the addresses received. ## Common mistakes 1. **Forgetting `ipv6 unicast-routing`.** Without it, the router accepts an IPv6 address on an interface but won't route between subnets or send RAs. 2. **Configuring a non-/64 prefix.** SLAAC requires /64. A /48 or /56 prefix doesn't work for SLAAC. The exception: /127 for point-to-point links (RFC 6164) — but SLAAC isn't used there anyway. 3. **M and O flag confusion.** M=1 means "address via DHCPv6" (turn off SLAAC). O=1 alongside M=0 means "address via SLAAC, but ask DHCPv6 for DNS." Mix them up and hosts behave unexpectedly. 4. **Expecting the router to learn hosts' addresses automatically.** It doesn't track stateless SLAAC addresses. To know who's on the network, you need DHCPv6 logs (stateful only) or scan via NDP. 5. **Filtering RAs at the wrong place.** A rogue RA from a misconfigured host can poison all SLAAC clients. **RA Guard** is the switch-level defense — like DHCP Snooping but for RAs. 6. **Forgetting hosts can have multiple IPv6 addresses.** It's normal. A laptop on a /64 has: link-local (fe80::...), SLAAC EUI-64, SLAAC privacy address, possibly a DHCPv6 address too. Don't be alarmed. ## Lab to try tonight 1. Two routers, one PC. Both routers on a shared LAN with a /64. 2. Enable `ipv6 unicast-routing` on both. Configure `ipv6 address 2001:db8:1::1/64` on R1 and `::2/64` on R2. 3. Connect a Windows / Linux PC to the LAN. Set IPv6 to "Automatic." 4. On the PC: `ipconfig /all` (or `ip -6 addr`). Observe the global address picked up via SLAAC. 5. Ping R1's address from the PC. Verify reachability. 6. Run Wireshark on the PC. Reload it. Watch the RS → RA → DAD exchange. 7. Enable `ipv6 nd managed-config-flag` on R1's interface. Configure a DHCPv6 pool. Restart the PC. Verify it now gets its address from DHCPv6. ## Cheat strip | Concept | Plain English | |---|---| | **SLAAC** | Host generates its own IPv6 from a router-advertised /64 prefix | | **RA** | Router Advertisement — sent every 200s by default | | **RS** | Router Solicitation — host says "I need an RA now" | | **DAD** | Duplicate Address Detection — host checks no one else has the addr | | **EUI-64** | Old way to generate interface ID from MAC (privacy issue) | | **Privacy addresses** | RFC 4941 — random interface ID, rotates daily | | **M flag** | "Managed" — get address from DHCPv6 | | **O flag** | "Other" — get DNS info from DHCPv6 | | **RA Guard** | Switch-level defense against rogue Router Advertisements | | **/64** | Required prefix length for SLAAC | --- ## OSPF Multi-Area — https://packetmentor.com/topics/ospf-multi-area/ > Why a single OSPF area stops working past ~50 routers, and how multi-area design fixes it. Covers ABRs, ASBRs, area 0 backbone rules, LSA types, and the area design decisions that scale OSPF to thousands of routers. ## Mental model Single-area OSPF (covered in [OSPF Single-Area](/topics/ospf-single-area/)) works beautifully for small networks. Every router knows about every link. SPF runs on the full topology. For 5 routers, that's trivial. For 500 routers, it's painful: - **Memory**: every router stores every link-state advertisement (LSA) for the whole network. - **CPU**: any topology change anywhere triggers SPF recalculation everywhere. - **Convergence**: a single flap somewhere causes a global re-SPF. **Multi-area OSPF fixes this by splitting the network into areas.** Each area maintains its own link-state database. Routes between areas are summarized at the boundaries. A flap in Area 3 only triggers SPF inside Area 3 — Area 0 and other areas just see the summary update. That's the whole concept. The rest is the rules. ## The rules of multi-area design ### Rule 1 — Every non-backbone area must touch Area 0 Area 0 is the **backbone**. Every other area (1, 2, 3, ...) must have at least one router (ABR) directly connected to area 0. No exceptions. If two areas need to communicate, they do so **through area 0**. There's no shortcut between Area 1 and Area 2 — packets go Area 1 → ABR → Area 0 → ABR → Area 2. ### Rule 2 — Area 0 must be contiguous You can't split area 0 into disconnected pieces. If a router fails and disconnects part of area 0, the network has a backbone partition — a serious problem. **Virtual link** is the (last-resort) workaround: a logical tunnel through a non-backbone area that lets two area-0 chunks talk. Use only to fix a temporary backbone gap; never as a design choice. ### Rule 3 — Router roles Every OSPF router has a role: | Role | What it is | |---|---| | **Internal** | All interfaces in one area | | **ABR** (Area Border Router) | Interfaces in area 0 + at least one other area | | **Backbone** | Has at least one interface in area 0 | | **ASBR** (Autonomous System Boundary Router) | Redistributes routes from another protocol (OSPF ↔ BGP, OSPF ↔ static, etc.) | A single router can be both ABR and ASBR (touches area 0, touches non-area-0, and redistributes from another protocol). ## LSA types — what each router sees OSPF traffic between areas is summarized using different LSA types. For CCNP, know these: | LSA Type | Name | Origin | Scope | |---|---|---|---| | **1** | Router LSA | Every router | Within its own area | | **2** | Network LSA | DR on multi-access network | Within the area | | **3** | Summary LSA | ABR | Floods between areas (summary of another area's routes) | | **4** | Summary ASBR LSA | ABR | Locates an ASBR in another area | | **5** | External LSA | ASBR | Routes redistributed from outside OSPF | The big-picture concept: inside an area, you see Types 1 + 2 (the actual topology). Between areas, ABRs translate that to Type 3 summaries — so internal routers in your area learn *"prefix X is reachable, AD distance Y, exit via ABR Z"* without seeing the actual topology of the other area. ## Area types — choosing the right one OSPF supports several special area types, each restricting which LSAs flow in. Less LSA = less memory + CPU on the area's routers. | Area type | Allowed LSAs | |---|---| | **Normal area** | Types 1, 2, 3, 4, 5 | | **Stub area** | Types 1, 2, 3 (blocks 4, 5 — no external routes; ABR injects a default) | | **Totally Stubby** | Types 1, 2 + a single default route (blocks 3, 4, 5) — Cisco-proprietary | | **NSSA** (Not-So-Stubby) | Stub + allows redistribution via Type 7 LSAs inside the area | | **Totally NSSA** | NSSA + blocks Type 3 (Cisco-proprietary) | For CCNP: know Normal, Stub, Totally Stubby, and NSSA exist. Memorize the LSA types each blocks. ## Commands ### Add a second area ``` ! On the ABR — interfaces in area 0 + area 1 R-ABR(config)# router ospf 1 R-ABR(config-router)# router-id 1.1.1.1 R-ABR(config-router)# network 10.0.0.0 0.0.0.255 area 0 ! backbone-side R-ABR(config-router)# network 192.168.1.0 0.0.0.255 area 1 ! area 1 side ``` ### Configure a stub area ``` ! On EVERY router in the stub area (including the ABR) R-ABR(config-router)# area 1 stub ! Totally stubby — only on the ABR R-ABR(config-router)# area 1 stub no-summary ``` ### Verify ``` R1# show ip ospf neighbor R1# show ip ospf database R1# show ip ospf database summary ! Type 3 LSAs R1# show ip ospf border-routers ! ABRs / ASBRs in the network R1# show ip route ospf ! routes learned via OSPF (with O, O IA, O E1, O E2 markers) ``` The route-table markers tell you how a route was learned: - **O** — Intra-area (same area) - **O IA** — Inter-area (different area, learned via Type 3) - **O E1 / O E2** — External (Type 5, redistributed) - **O N1 / O N2** — NSSA external (Type 7) ## Common mistakes 1. **Forgetting area 0.** A two-area design where the second area is "just connected somewhere" → traffic doesn't flow between areas because area 0 isn't between them. 2. **Disconnected area 0.** Don't design this on purpose. If you find yourself there, virtual link is the patch — but redesign. 3. **Stub area with a redistributing ASBR.** Stub blocks external routes (Type 5). If you need to redistribute from BGP inside that area, use NSSA instead. 4. **Mismatched stub config.** Every router in a stub area must agree it's stub. If R1 thinks area 1 is stub and R2 thinks area 1 is normal, they won't form an adjacency. 5. **Treating area number = priority.** Area numbers are identifiers, not priorities. Area 5 isn't worse than Area 1. The only special area is 0. 6. **Using area 0 as a non-backbone area.** Area 0 must be the backbone. You can't "rename" it. If you've grown beyond your original area design, restructure rather than redefining area 0. 7. **Forgetting Type 7 → Type 5 conversion at the ABR.** NSSA Type 7 LSAs only live inside the NSSA area. The ABR converts them to Type 5 when sending into area 0. Misunderstand this and you wonder where the routes went. ## Lab to try tonight 1. Three areas: area 0 (R1, R2), area 1 (R1, R3), area 2 (R2, R4). 2. R1 and R2 are ABRs (each in area 0 + a non-backbone area). 3. Configure OSPF, verify all routers form adjacencies and reach FULL state with their neighbors. 4. From R3 (area 1), traceroute to a loopback on R4 (area 2). The path should go R3 → R1 → R2 → R4 (through area 0). 5. Run `show ip ospf database summary` on R3 — see the Type 3 LSAs for area 2's networks. 6. Make area 1 a stub: `area 1 stub` on R1 and R3. Verify R3 now has a default route (O*IA) instead of external routes. 7. Bonus: redistribute a static route on R5 (in area 2) into OSPF. Verify O E2 appears in R3's table. ## Cheat strip | Concept | Plain English | |---|---| | **Area 0** | Backbone. Every area must touch it. | | **ABR** | Router with interfaces in 2+ areas. Translates between them. | | **ASBR** | Router that redistributes from another routing source | | **LSA Type 1** | Router LSA (within area) | | **LSA Type 3** | Summary LSA from ABR (between areas) | | **LSA Type 5** | External LSA from ASBR | | **Stub area** | Blocks external LSAs (4, 5). Default route from ABR. | | **Totally Stubby** | Stub + blocks inter-area too. Just a default. Cisco-only. | | **NSSA** | Stub + allows redistribution via Type 7 inside it | | **Virtual link** | Tunnel through non-backbone to fix area-0 partition. Last resort. | --- ## IPv6 Routing — Static & OSPFv3 — https://packetmentor.com/topics/ipv6-routing/ > How routing works in an IPv6-only or dual-stack network. Covers IPv6 static routes, OSPFv3 (OSPF for IPv6), default routes, and the differences from IPv4 routing you need to know. ## Mental model IPv6 routing works like IPv4 routing. Same decision process (longest prefix match → administrative distance → metric, see [Routing Decision Process](/topics/routing-decision-process/)). Same routing protocols (OSPF, EIGRP, BGP — each has an IPv6 variant). Same forwarding behavior at L3. Three things to know that differ from IPv4: 1. **Routing protocols use link-local addresses** for peering, not the global ones you configured. 2. **`ipv6 unicast-routing`** must be enabled globally to forward IPv6. 3. **The default route is `::/0`** (not `0.0.0.0/0`). Everything else is just longer hex addresses. ## Enable IPv6 routing Step zero on every IPv6-routing router: ``` R1(config)# ipv6 unicast-routing ``` Without this, the router accepts IPv6 addresses on interfaces but doesn't actually route IPv6 between them. Easy to forget. ## IPv6 static routing Syntax mirrors IPv4 — different commands, same shape. ``` ! Specific subnet via next-hop R1(config)# ipv6 route 2001:db8:2::/64 2001:db8:12::2 ! Same, with explicit exit interface (point-to-point recommended) R1(config)# ipv6 route 2001:db8:2::/64 GigabitEthernet0/1 ! Default route R1(config)# ipv6 route ::/0 2001:db8:99::1 ! Floating static — higher AD makes it a backup R1(config)# ipv6 route 2001:db8:2::/64 2001:db8:99::2 200 ``` ### Verify ``` R1# show ipv6 route R1# show ipv6 route static R1# show ipv6 route 2001:db8:2::1 ``` `show ipv6 route 2001:db8:2::1` (with a specific destination) returns the exact route the router would use — same as `show ip route X` for IPv4. ## OSPFv3 — OSPF for IPv6 OSPFv3 is OSPF rewritten for IPv6. Same algorithm (link-state, Dijkstra/SPF), same area concept, same LSA-based propagation. Differences worth knowing: | | OSPFv2 (IPv4) | OSPFv3 (IPv6) | |---|---|---| | Network statement | `network X.X.X.X 0.0.0.X area N` | `ipv6 ospf N area M` on the interface | | Neighbor adjacency | Uses configured IPv4 | **Uses link-local (fe80::)** | | Router ID | 32-bit (looks like IPv4) | 32-bit (still looks like IPv4 — even though there's no IPv4 in OSPFv3) | | Authentication | MD5, SHA-256 | Uses IPsec | | LSA types | Same as OSPFv2 conceptually | Renamed (Type 8 Link LSA, Type 9 Intra-Area Prefix LSA) | ### Minimal OSPFv3 config ``` ! Enable IPv6 routing globally R1(config)# ipv6 unicast-routing ! Configure router ID — required in OSPFv3 even if no IPv4 exists R1(config)# ipv6 router ospf 1 R1(config-rtr)# router-id 1.1.1.1 ! Enable OSPFv3 per-interface R1(config)# interface GigabitEthernet0/0 R1(config-if)# ipv6 address 2001:db8:12::1/64 R1(config-if)# ipv6 ospf 1 area 0 R1(config)# interface GigabitEthernet0/1 R1(config-if)# ipv6 address 2001:db8:13::1/64 R1(config-if)# ipv6 ospf 1 area 0 ``` The big difference: no `network` statement under the OSPF process. Per-interface enablement only. Cleaner. ### Verify OSPFv3 ``` R1# show ipv6 ospf neighbor R1# show ipv6 ospf interface brief R1# show ipv6 route ospf R1# show ipv6 protocols ``` `show ipv6 ospf neighbor` confirms the peering. **Neighbor addresses shown will be link-local (fe80::...)** — not the global addresses you configured. This is expected. ## Default route ::/0 The IPv4 default route is `0.0.0.0/0`. The IPv6 equivalent: ``` R1(config)# ipv6 route ::/0 2001:db8:99::1 ``` When OSPFv3 has a default to share: ``` R1(config)# ipv6 router ospf 1 R1(config-rtr)# default-information originate ``` (Same command as OSPFv2.) ## Dual-stack — running IPv4 and IPv6 together Most production networks run **both** IPv4 and IPv6 simultaneously. Each protocol runs independently — separate routing tables, separate routing protocols, separate ACLs. ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 10.0.0.1 255.255.255.0 R1(config-if)# ipv6 address 2001:db8:1::1/64 ``` Both protocols active on the same interface. Hosts decide per-application (or per-connection) which one to use. IPv6 is generally preferred when available (Happy Eyeballs algorithm in modern OSes). ## Common mistakes 1. **Forgetting `ipv6 unicast-routing`.** Configured IPv6 addresses look fine but the router won't route between them. The most common day-1 IPv6 mistake. 2. **Wondering why OSPFv3 neighbors show fe80:: addresses.** That's correct — OSPFv3 peers via link-local. Not a bug. 3. **Trying to use `network ::/0 area 0`-style statements.** OSPFv3 enables per-interface. Different config style from OSPFv2. 4. **Not hard-coding router ID.** OSPFv3 picks the router ID from an interface IP if you don't set one — and if there's no IPv4 anywhere, it refuses to start. Always `router-id X.X.X.X`. 5. **Mixing OSPFv2 and OSPFv3 expectations.** They're separate processes, separate configs, separate tables. Don't expect `show ip ospf` to show OSPFv3 info. Use `show ipv6 ospf`. 6. **Forgetting separate ACLs for IPv6.** ACLs are protocol-specific. An IPv4 ACL doesn't affect IPv6 traffic. Configure both: `ip access-list ...` and `ipv6 access-list ...`. ## Lab to try tonight 1. Three routers in a triangle. Each with one loopback (1::1, 2::2, 3::3) and /64 links between them. 2. Enable `ipv6 unicast-routing` on all three. 3. Configure OSPFv3 area 0 on all routers, per-interface. 4. Set router IDs to 1.1.1.1, 2.2.2.2, 3.3.3.3. 5. Verify neighbor relationships form: `show ipv6 ospf neighbor`. Note the fe80:: addresses. 6. Verify routes: `show ipv6 route ospf`. Should see loopbacks of other routers. 7. Break a link. Watch OSPFv3 re-converge. 8. Bonus: add a static IPv6 route on one router as a backup with higher AD. Test failover. ## Cheat strip | Concept | Plain English | |---|---| | **`ipv6 unicast-routing`** | Required globally to forward IPv6 | | **`::/0`** | IPv6 default route | | **`ipv6 route X via Y`** | Static IPv6 route | | **OSPFv3** | OSPF for IPv6. Per-interface enablement. | | **Link-local peering** | OSPFv3 neighbors are at fe80:: addresses | | **Router ID** | Hardcode it. Looks like IPv4 (32-bit). | | **Dual stack** | IPv4 and IPv6 side-by-side, independent | | **Separate ACLs** | `ip access-list` vs `ipv6 access-list` — different things | --- ## BGP Basics — https://packetmentor.com/topics/bgp-basics/ > Definitive CCNP-level BGP guide — autonomous systems, eBGP vs iBGP, path-vector routing, neighbor states, full best-path selection process, attributes deep dive (AS_PATH, LOCAL_PREF, MED, communities), route reflectors, RPKI, 8 worked scenarios, and the BGP debug workflow. ## Mental model Inside one organization's network, internal protocols (OSPF, EIGRP) handle routing. They share full topology and react fast. They're trust-everyone protocols — every router in OSPF area 0 knows every link. Between organizations, that breaks down. Verizon shouldn't see Comcast's internal topology. Cloudflare shouldn't trust everything its peering partners advertise. You need a routing protocol that: - **Treats networks as autonomous units** — don't peek inside the other network's topology. - **Lets each unit set policy** — prefer this neighbor over that, refuse to accept certain prefixes. - **Doesn't share full topology** — just "I can reach prefix X via this AS path." - **Scales to a million prefixes** — the global BGP table is around 950,000 IPv4 prefixes in 2026. **BGP** — Border Gateway Protocol — is that protocol. It's what makes the internet *one* network rather than thousands of disconnected ones. It's a routing mesh of Autonomous Systems each making policy decisions about which prefixes to accept, prefer, and advertise. Three things to internalize: 1. **BGP is policy, not optimality.** Unlike OSPF, BGP doesn't pick the shortest path automatically — it picks the path your policy prefers. "Shortest" is just one option. 2. **BGP runs on TCP** (port 179). Not UDP, not raw IP — actual TCP for reliability + session management. 3. **BGP is the only routing protocol that runs the internet.** There is no alternative at the inter-AS layer. Everything else (OSPF, EIGRP, IS-IS) is intra-AS. ## Autonomous System (AS) An **AS** is a network under one administrative control with a unique AS number. | AS number range | Type | Used for | |---|---|---| | 1–64,511 | Public (16-bit) | Internet-facing — assigned by RIRs (ARIN, RIPE, APNIC) | | 64,512–65,534 | Private | Inside large enterprises, MPLS providers, sub-AS designs | | 65,535 | Reserved | — | | 4,200,000,000–4,294,967,294 | Private (32-bit) | Modern private range | | All other 32-bit | Public | New global ASNs since 2007 | Known examples: - **Cloudflare**: AS 13335 - **Google**: AS 15169 - **Hurricane Electric**: AS 6939 (top transit by reach) - **AT&T**: AS 7018 - **Comcast**: AS 7922 - **Microsoft**: AS 8075 Two ASes that exchange BGP routes are **BGP peers** or **neighbors**. ## eBGP vs iBGP | Aspect | eBGP | iBGP | |---|---|---| | Between | Different ASes | Routers in the same AS | | Purpose | Exchange routes across organization boundaries | Distribute externally-learned routes internally | | TTL on packets | 1 by default (direct neighbors only) | 255 (multi-hop within AS) | | Loop prevention | AS_PATH check | Split-horizon — iBGP routes aren't re-advertised to other iBGP peers | | Most common topology | Direct neighbor between border routers | Full mesh (or route reflectors) within the AS | | AD | 20 | 200 | **The classic enterprise pattern:** - eBGP between your edge routers and your ISPs. - iBGP between your internal routers so internally-routed traffic uses BGP-learned next-hops correctly. ### The iBGP split-horizon rule When an iBGP router learns a route from one iBGP peer, it **does NOT re-advertise** that route to another iBGP peer. Why? Loop prevention — there's no AS_PATH increment within an AS (the same AS appears throughout), so you can't detect loops with AS_PATH. Consequence: every iBGP router needs a direct iBGP session with every other iBGP router. That's a **full mesh**: `N × (N-1) / 2` sessions. 10 routers = 45 iBGP sessions. 100 routers = 4,950 sessions. Doesn't scale. **Solution: Route Reflectors (RR).** One designated router (the RR) is allowed to re-advertise iBGP routes to its clients. Each client peers only with the RR(s), not with every other iBGP router. Full mesh of 100 routers → 100 sessions to the RR. Standard pattern in any large AS. ## BGP is path-vector — what that means Each route in BGP carries an **AS_PATH** — the list of ASes the route traversed: ``` 10.0.0.0/24 → AS_PATH: 65002 65010 64500 ``` Read: *"This prefix originated in AS 64500, was sent through AS 65010, then through AS 65002, and is now here."* The first AS in the path is the most recent hop; the last is the originator. ### Loop prevention via AS_PATH If a route arrives with your own AS number already in the AS_PATH, you **drop it**. You can't import your own routes back. Simple, effective loop prevention without computing topology. ### AS_PATH prepending — a key traffic-engineering trick You can artificially make a path *longer* by prepending your own AS multiple times: ``` R1(config-router)# route-map LONG-PATH out R1(config-route-map)# set as-path prepend 65001 65001 65001 ``` If you have two ISPs and want traffic to prefer the other one (without disabling this one), prepend your AS several times on the outbound side. Neighbors see this prefix as having a longer AS_PATH and prefer the shorter alternative. ## BGP attributes — the full menu BGP carries many attributes alongside each route. Some matter for path selection; others are informational. | Attribute | Type | Used for | |---|---|---| | **AS_PATH** | Well-known mandatory | Loop prevention + path-length comparison | | **NEXT_HOP** | Well-known mandatory | Where to send packets for this prefix | | **ORIGIN** | Well-known mandatory | How was the prefix originated: IGP, EGP, Incomplete | | **LOCAL_PREF** | Well-known discretionary | Prefer this path within the AS (iBGP attribute) | | **MED (Metric)** | Optional non-transitive | Suggest preferred entry to a neighbor | | **COMMUNITY** | Optional transitive | Tag routes for policy purposes | | **WEIGHT** | Cisco-only, local | Override BGP path selection on a single router | | **Atomic Aggregate** | Discretionary | Indicates summarization happened | | **Aggregator** | Optional transitive | Identifies which router did the aggregation | The four you'll actually tune in real life: **WEIGHT, LOCAL_PREF, AS_PATH (via prepending), MED.** ## Best-path selection — the full 13-step process When BGP has multiple paths for the same prefix, it picks one as best. The selection runs in this order; first tie-breaker wins: 1. **Weight** — highest wins (Cisco-only, local to the router) 2. **LOCAL_PREF** — highest wins (within the AS) 3. **Locally originated** — prefer routes this router originated (via `network` or aggregation) 4. **AS_PATH length** — shortest wins (after AS_SET / AS_CONFED removed) 5. **ORIGIN** — IGP > EGP > Incomplete (lower is better) 6. **MED** — lowest wins (only compared across same neighbor AS by default) 7. **eBGP over iBGP** — prefer eBGP-learned 8. **IGP metric to next-hop** — lowest cost back to the BGP next-hop wins 9. **Multipath check** — if `maximum-paths` is configured and several paths are equal up to here, install them all and stop 10. **Oldest route** (eBGP only) — for stability, the longer-established eBGP route wins 11. **Lowest Router ID** of the advertising peer 12. **Lowest Cluster List length** (route reflectors) 13. **Lowest neighbor IP address** of the BGP session For CCNP / CCNA-level interview prep: memorize at least steps 1, 2, 4, 5, 6, 7. Those handle most real-world tuning. ### Why so many tie-breakers BGP must produce one and only one best path for each prefix, deterministically. With millions of paths in flux globally, you need a strict ordering to converge. ## BGP neighbor states — the lifecycle ``` Idle → Connect → Active → OpenSent → OpenConfirm → Established ``` | State | What's happening | |---|---| | **Idle** | Initial. Waiting to try a TCP connection. | | **Connect** | TCP SYN sent, waiting for SYN-ACK | | **Active** | TCP failed; retrying. Don't confuse "Active" with "actively working" — it's actually trying repeatedly to connect | | **OpenSent** | TCP up. BGP OPEN message sent. | | **OpenConfirm** | OPEN exchanged. Waiting for KEEPALIVE to confirm. | | **Established** | Session up. Routes flow. ✓ | The state to watch for: **Established**. Anything else = not yet exchanging routes. The trap state: **Active**. Sounds good; means "still trying." Usually indicates one of: - TCP 179 blocked by firewall - Neighbor IP unreachable - AS number mismatch (OPEN messages rejected) - Source-interface IP wrong ## Configuration — minimal eBGP setup ``` ! Edge router R1 in AS 65001, peering with ISP at 198.51.100.1 (AS 65002) R1(config)# router bgp 65001 R1(config-router)# bgp router-id 1.1.1.1 R1(config-router)# neighbor 198.51.100.1 remote-as 65002 R1(config-router)# neighbor 198.51.100.1 description ISP-A R1(config-router)# neighbor 198.51.100.1 password $tr0ngK3y R1(config-router)# network 203.0.113.0 mask 255.255.255.0 ``` Required minimum: `neighbor IP remote-as ASN` + `network PREFIX mask MASK` to advertise. Everything else is best practice (router ID, description, password). **The `network` statement gotcha:** unlike OSPF where `network` *enables* the protocol on an interface, BGP's `network` command only takes effect if the prefix exists *exactly* in the routing table (same mask). If you write: ``` R1(config-router)# network 203.0.113.0 mask 255.255.255.0 ``` But your routing table has `203.0.113.0/26` from a connected interface, BGP won't advertise. You need either a `/24` static or `/24` actually in the table. ## iBGP configuration with route reflector ``` ! Route Reflector R1 in AS 65001 R1(config)# router bgp 65001 R1(config-router)# bgp router-id 1.1.1.1 R1(config-router)# neighbor 10.0.0.2 remote-as 65001 R1(config-router)# neighbor 10.0.0.2 route-reflector-client R1(config-router)# neighbor 10.0.0.3 remote-as 65001 R1(config-router)# neighbor 10.0.0.3 route-reflector-client ! RR Client R2 R2(config)# router bgp 65001 R2(config-router)# neighbor 10.0.0.1 remote-as 65001 R2(config-router)# neighbor 10.0.0.1 update-source Loopback0 ``` The client only peers with the RR; the RR peers with all clients. The RR re-advertises routes between clients, breaking the strict iBGP split-horizon rule safely. ## Multi-hop eBGP Default eBGP uses TTL=1 — packets only reach directly-connected neighbors. If you want to peer between loopback IPs (more resilient — survives one of multiple physical links failing), you need to extend the TTL: ``` R1(config-router)# neighbor 10.255.255.2 remote-as 65002 R1(config-router)# neighbor 10.255.255.2 update-source Loopback0 R1(config-router)# neighbor 10.255.255.2 ebgp-multihop 2 ``` `ebgp-multihop 2` sets TTL = 2 (allows one intermediate router between peers). ## Communities — the policy-tagging system BGP **communities** are arbitrary 32-bit tags you attach to routes. They mean nothing on their own — but you and your peers can agree to treat them as policy signals. ``` ! Tag a route with communities R1(config-router)# neighbor 10.0.0.2 send-community R1(config)# route-map TAG-CUSTOMER out R1(config-route-map)# set community 65001:100 65001:200 ``` Common community conventions (industry de-facto): | Community | Meaning | |---|---| | `no-export` | Don't advertise to eBGP peers (well-known) | | `no-advertise` | Don't advertise to any peer (well-known) | | `local-AS` | Don't advertise outside the local AS / confederation (well-known) | | `:100` | "Customer route" (provider-specific) | | `:200` | "Peer route" | | `:666` | "Black-hole this — used in DDoS mitigation" | The first three are IETF well-known communities — Cisco refers to them by name (`set community no-export`), not as numeric pairs. The `:value` pairs are normal communities you and your peers agree on. Pre-arrange with your ISP what their communities mean. Then upstream tags routes to communicate "this is a customer," "this is a peer," etc. ## Why BGP misconfigurations make news BGP **trusts what peers tell you**. There's no central truth. Without route filters or RPKI validation, anyone can claim to own any prefix and propagate that claim globally in seconds. Examples that made global news: - **2008 — Pakistan vs YouTube**: Pakistan's PCCW tried to block YouTube domestically by advertising a more-specific YouTube prefix. PCCW's upstream propagated it globally. The entire internet's YouTube traffic routed to Pakistan for hours. - **2017 — Google routes via Russia**: Russian ISPs accidentally announced Google prefixes, redirecting global Google traffic for a few hours. - **2019 — Cloudflare via Verizon**: A small ISP's BGP optimizer leaked routes; Verizon propagated them; Cloudflare and Amazon traffic disrupted globally. - **2021 — Facebook outage**: A BGP configuration error withdrew Facebook's prefixes globally — including the ones used by Facebook engineers to access the network. Five-hour outage. - **2023 / 2024 — multiple ISP leaks**: BGP leaks remain the #1 cause of internet outages affecting non-customer-related traffic. In 2026, the defense layers are: - **Route filters / prefix lists** — only accept what neighbors are entitled to advertise - **AS-path filters** — match on origin AS to prevent obvious hijacks - **RPKI (Resource Public Key Infrastructure)** — cryptographic signing of who owns what prefix - **MANRS** (Mutually Agreed Norms for Routing Security) — industry framework - **BGP communities + community-based filters** — agreed conventions for what can/can't be re-advertised For CCNP/CCNA: know that BGP misconfiguration is high-consequence and that RPKI + filters are the modern defense. ## RPKI in 60 seconds **Resource Public Key Infrastructure** lets prefix owners cryptographically sign "AS X is authorized to originate prefix Y." Routers receive these **ROAs** (Route Origin Authorizations) from RPKI validators and can mark or reject BGP routes that don't have valid origin authorization. ``` R1(config)# router bgp 65001 R1(config-router)# bgp rpki server tcp 10.99.99.10 port 3323 ``` ROA states: **Valid · Invalid · NotFound**. Most networks tag invalids but don't yet drop — adoption is growing. Cloudflare, Google, NTT, AT&T all drop invalids. ## Verification commands ``` R1# show ip bgp summary R1# show ip bgp neighbors R1# show ip bgp neighbors 10.0.0.2 advertised-routes R1# show ip bgp neighbors 10.0.0.2 received-routes R1# show ip bgp R1# show ip bgp 8.8.8.0/24 R1# show ip route bgp R1# show ip bgp regexp _15169_ ! search by AS number in path ``` `show ip bgp summary` is the daily driver. The key column: **State/PfxRcd**: - A number = peer is Established and you're receiving that many prefixes. - "Idle" / "Active" / "Connect" = peering not working. `show ip bgp 8.8.8.0/24` shows all paths known for a specific prefix with attributes — the debug command for "why isn't this route preferred." ## The 6-step BGP debug When a peering "isn't working": 1. **TCP reachability?** `ping ` from the router (with appropriate source). If ping fails, BGP can't form. 2. **Port 179 reachable?** `telnet 179`. If telnet doesn't connect, a firewall is blocking BGP. 3. **AS numbers match?** Your `remote-as` and the neighbor's `remote-as` for you must match. AS mismatch = OPEN rejected = neighbor stuck in OpenSent. 4. **Source interface configured?** If using loopbacks, both sides need `neighbor X update-source Loopback0` AND the loopback IP must be reachable from the other side. 5. **eBGP TTL right?** Direct neighbors don't need `ebgp-multihop`. Loopback peering does. 6. **Password / authentication match?** If MD5 password set on one side but not the other (or different keys), session fails silently. Check `show ip bgp neighbors | include password`. ## Worked scenarios --- **Scenario 1.** R1 (AS 65001) configures `neighbor 198.51.100.1 remote-as 65002`. The neighbor configures `neighbor 198.51.100.5 remote-as 65003`. Will the session form? **Answer:** No. AS mismatch — R1 expects AS 65002 from the neighbor, but the neighbor identifies itself as AS 65003. OPEN message validation fails. Both routers will show the neighbor in "Active" state, repeatedly retrying. --- **Scenario 2.** Two paths to `10.5.0.0/24`. Path A: AS_PATH `65002 65010`, LOCAL_PREF 100. Path B: AS_PATH `65003`, LOCAL_PREF 200. Which wins? **Answer:** Path B. LOCAL_PREF is checked before AS_PATH length. 200 > 100 → Path B preferred, even though it goes through a different path. --- **Scenario 3.** You have two ISPs and want primary egress via ISP-A. How do you express "prefer ISP-A for outbound" using BGP? **Answer:** Set LOCAL_PREF higher on routes received from ISP-A: ``` route-map ISP-A-IN permit 10 set local-preference 200 router bgp 65001 neighbor route-map ISP-A-IN in ``` ISP-B's routes default to LOCAL_PREF 100 → ISP-A's 200 wins for outbound. --- **Scenario 4.** You're multi-homed with ISP-A and ISP-B. You want ISP-B to be only for backup — only used if ISP-A is down. The inbound direction is the issue (you can't directly control which ISP sends you traffic). Best approach? **Answer:** AS_PATH prepending on the ISP-B side. Announce your prefix to ISP-B with multiple prepends of your own AS: ``` route-map PREPEND-B out set as-path prepend 65001 65001 65001 65001 router bgp 65001 neighbor route-map PREPEND-B out ``` External ASes see a longer AS_PATH via ISP-B and prefer ISP-A naturally. Backup behavior emerges from preference. --- **Scenario 5.** Why does iBGP need a full mesh? **Answer:** iBGP's loop-prevention rule is split-horizon: routes learned from one iBGP peer are NOT re-advertised to other iBGP peers. So every internal router must hear external routes directly from a router that has them. With N routers, that's N×(N-1)/2 sessions. Route Reflectors break the rule safely and let you use hub-and-spoke instead. --- **Scenario 6.** A BGP session is stuck in "Active" state. What are the top three causes? **Answer:** 1. TCP 179 blocked by a firewall on the path 2. Neighbor IP unreachable (no route, interface down) 3. Source-interface mismatch (you're sourcing from one IP, neighbor expects another) --- **Scenario 7.** Your `network 203.0.113.0 mask 255.255.255.0` statement isn't advertising. Routing table has only the connected `/26`. What's wrong? **Answer:** BGP's `network` command requires the prefix to exist *exactly* in the routing table. A `/26` doesn't match a `/24` advertisement. Fix: add a static `ip route 203.0.113.0 255.255.255.0 Null0` (a "summary" static that ensures the `/24` exists in the routing table for BGP to find). --- **Scenario 8.** You receive a BGP route with AS_PATH `65003 65004 65001 65005`. You're in AS 65001. What happens? **Answer:** Ignored. AS 65001 (yours) appears in the AS_PATH → loop detected → route rejected. This is BGP's primary loop-prevention mechanism for eBGP. ## Common mistakes 1. **Forgetting `network` statement.** Configured peering but no prefixes advertised → neighbor doesn't get any routes from you. 2. **Mismatched AS numbers.** Your `remote-as` and the neighbor's identity don't match → OPEN rejected → session stuck in Active. 3. **TCP 179 blocked.** Especially common when routing through a firewall. Test with `telnet 179`. 4. **iBGP without full mesh (or RR).** Internal routers don't learn external routes → they default-route blindly or black-hole. Use RR. 5. **eBGP TTL = 1 with non-directly-connected neighbors.** For loopback-to-loopback peering use `ebgp-multihop 2`. 6. **Trusting upstream blindly.** Always filter what you accept from peers. RPKI + prefix lists + max-prefix limits are the minimum. 7. **No `update-source` with loopback peering.** TCP connection uses the wrong source IP, neighbor doesn't recognize. 8. **No MD5/TCP-AO authentication on production peerings.** Cheap protection against spoofing. 9. **Default route in BGP without filter.** Accepting `0.0.0.0/0` from an unintended source can hijack all your egress traffic. 10. **`network` command without exact prefix match in routing table.** BGP won't advertise unless the prefix exists exactly. Use a static-to-Null0 if needed. 11. **No `bgp router-id` set.** Auto-pick may pick a different IP each restart, causing session flaps. 12. **Forgetting `address-family` blocks** on modern IOS-XE — IPv4 unicast advertisements live inside an explicit `address-family ipv4` block. ## Lab to try tonight 1. **Basic eBGP** — Two routers (R1 in AS 65001, R2 in AS 65002). One link between them. Configure eBGP. Each advertises a loopback. Verify Established state and 1 PfxRcd. 2. **AS_PATH inspection** — `show ip bgp` on each router. See the prefix learned from the neighbor with the neighbor's AS in the AS_PATH. 3. **Add iBGP** — Add R3 in the same AS as R1 (AS 65001). Configure iBGP between R1↔R3. Verify R3 learns external prefixes (R2's loopback) via iBGP. 4. **Route reflector** — Add R4 and R5 in AS 65001. Make R1 the RR; R3, R4, R5 are clients. Verify R3↔R4↔R5 learn each other's routes via the RR without direct iBGP. 5. **Multi-hop loopback peering** — Convert R1↔R2 eBGP to peer between loopbacks. Add `update-source Loopback0` and `ebgp-multihop 2`. Verify session survives a physical link replacement. 6. **LOCAL_PREF tuning** — Bring up a second eBGP peering to a new AS. Set LOCAL_PREF higher on one side. Verify outbound traffic prefers that path. 7. **AS_PATH prepending** — Prepend your AS on outbound advertisements to one neighbor. Verify the other neighbor sees a longer AS_PATH and shifts inbound traffic. 8. **MED tuning** — Set MED on outbound routes to influence which peer the neighbor AS prefers as entry. 9. **Communities** — Tag routes with `set community 65001:100`. Verify with `show ip bgp 10.0.0.0/24` — community column populated. 10. **Bonus: simulate a peering failure** — `clear ip bgp `. Watch session transition Idle → Active → Established. Time the route reconvergence. ## Cheat strip | Concept | Plain English | |---|---| | **BGP** | Routing between Autonomous Systems. Runs the internet. | | **AS** | One administrative network. Unique AS number. | | **eBGP** | Between different ASes. Default TTL 1. AD 20. | | **iBGP** | Within one AS. Distributes external routes internally. AD 200. | | **TCP 179** | BGP's transport port | | **AS_PATH** | List of ASes a route traversed — loop prevention + path-length metric | | **AS_PATH prepending** | Trick: prepend your own AS to artificially lengthen a path | | **LOCAL_PREF** | Within the AS, prefer this path. Highest wins. | | **MED** | Hint to neighbor AS — lowest wins | | **WEIGHT** | Cisco-only, local — highest wins. Overrides everything below it | | **Communities** | Tags for policy. `no-export`, `no-advertise`, custom | | **Established** | Session up, routes flowing | | **Active** | Trying to connect; usually means it's NOT connecting | | **`network` cmd** | Tell BGP to advertise this prefix (must exist exactly in routing table) | | **Private AS** | 64,512–65,534 (16-bit) · 4,200,000,000+ (32-bit) | | **RPKI** | Cryptographic origin authorization. Modern BGP security | | **Route Reflector** | Workaround for iBGP full-mesh — RR re-advertises iBGP routes to clients | | **Multi-hop eBGP** | `ebgp-multihop` to peer loopback-to-loopback with TTL > 1 | | **Best-path selection** | 13 steps. Memorize: Weight → LP → AS_PATH → MED → eBGP > iBGP | | **BGP misconfigurations** | Globally consequential. Defense = filters + RPKI + MANRS | | **Global table size** | ~950k IPv4 prefixes (2026) — full table requires substantial RAM/FIB | | **CCNA depth** | Recognize. CCNP/CCIE: deploy and tune. This page is CCNP-level. | --- ## Wireless RF Fundamentals — https://packetmentor.com/topics/wireless-rf-fundamentals/ > How Wi-Fi actually moves bits through the air — channels, bands, SNR, RSSI, free-space path loss, antenna patterns, and why your laptop disconnects in the conference room corner. ## Mental model Wired Ethernet is a private hallway — your bits travel down a cable that no one else can touch. Wi-Fi is a **shared public square** — everyone's bits ride invisible radio waves on the same channel, and only one device can broadcast at a time without collision. That single sentence explains 80% of Wi-Fi behavior: - Why Wi-Fi is half-duplex (CSMA/CA — listen before talking). - Why throughput drops as more clients join (sharing airtime). - Why a microwave kills your Wi-Fi (2.4 GHz oven, 2.4 GHz Wi-Fi, same band). - Why moving from a phone-jam coffee shop to an empty office triples your speed. Wi-Fi performance is mostly **radio physics**, then a thin layer of 802.11 protocol logic on top. ## Bands — three Wi-Fi worlds | Band | Channels | Range | Congestion | Use | |---|---|---|---|---| | **2.4 GHz** | 1, 6, 11 (only non-overlapping in N. America) | Long (penetrates walls) | High — Bluetooth, microwaves, IoT | IoT, legacy clients, when range matters | | **5 GHz** | ~25 non-overlapping (UNII-1/2/2e/3) | Shorter, more loss through walls | Lower | Default for modern enterprise Wi-Fi | | **6 GHz** (Wi-Fi 6E / 7) | 14 × 80 MHz non-overlapping | Similar to 5 GHz | Empty (only Wi-Fi 6E+ clients allowed) | New high-density deployments | **2.4 GHz** has only 3 non-overlapping channels (1, 6, 11) in North America. APs nearby on channels 2-5 *interfere* with channels 1 and 6 even though they have different numbers — channels in 2.4 GHz overlap. **5 GHz** has many non-overlapping 20 MHz channels, making it the default for enterprise. Some channels (DFS — Dynamic Frequency Selection) must yield to radar; expect occasional channel changes. **6 GHz** (Wi-Fi 6E and Wi-Fi 7) opened in 2020-2022. Massive clean spectrum — but only the newest clients can use it. ## Channel width — speed vs density trade-off 802.11 lets you bond channels together for more throughput: - **20 MHz** — basic. ~150 Mbps per stream on 802.11ac. - **40 MHz** — 2 adjacent channels. ~300 Mbps. - **80 MHz** — 4 channels. ~600 Mbps. Default for ac/ax in residential. - **160 MHz** — 8 channels. ~1.2 Gbps. Great for one AP, terrible for dense deployments (uses half the 5 GHz spectrum). Rule of thumb: in a high-density office or apartment, **smaller channels = more APs that don't step on each other = higher aggregate capacity**. In a single-AP home, wider is fine. ## RSSI vs SNR — the two numbers that matter Wi-Fi signal strength is measured in **dBm** (decibel-milliwatts) — a logarithmic scale where bigger negative number = weaker. **RSSI** (Received Signal Strength Indicator) — how loud the AP sounds at the client: | RSSI (dBm) | Quality | Realistic use | |---|---|---| | −30 to −50 | Excellent | Right next to the AP | | −50 to −65 | Good | Same room as AP | | −65 to −75 | Fair | Voice/video struggles | | −75 to −85 | Poor | Connected but unusable | | −85 and below | Disconnect | Below sensitivity floor | **Noise floor** — how loud all the random RF noise is at the same location. Usually around `−90 dBm` in clean environments, `−85` in noisy ones. **SNR** (Signal-to-Noise Ratio) = RSSI − noise floor. In dB. | SNR (dB) | Quality | |---|---| | > 40 | Excellent | | 25 - 40 | Good | | 15 - 25 | Fair (data only) | | < 15 | Unreliable | **High RSSI but low SNR** = strong signal in a noisy room → still poor. SNR is the better single number to chase. ## Free-space path loss Radio signal weakens with distance. The formula (free-space, ignoring obstacles): ``` Loss (dB) = 20 × log10(distance) + 20 × log10(frequency) + 32.44 ``` The practical takeaway: **doubling distance loses 6 dB**. Going from 5m to 10m, signal drops by 6 dB. Going from 10m to 20m, another 6 dB. 5 GHz suffers more path loss than 2.4 GHz at the same distance — about 7 dB more. That's why 2.4 GHz "reaches further" even though it's worse spectrum. Walls add their own loss: | Obstacle | Loss (approx) | |---|---| | Drywall | 3 dB | | Wood door | 4 dB | | Brick wall | 8 dB | | Concrete wall | 12 dB | | Glass with metal coating | 8-15 dB | | Elevator shaft / metal cabinet | 20-30 dB | Two concrete walls = 24 dB loss = signal cut to 1/250 of original. ## Antenna patterns APs don't radiate evenly in all directions. Three common patterns: - **Omnidirectional** — donut-shape, radiates outward equally in all horizontal directions. Default for ceiling-mount APs. - **Directional / patch** — focuses energy in one direction. Used for long corridors, warehouse aisles, point-to-point outdoor links. - **Sector / yagi** — narrow beam, used for outdoor bridge links or for covering one specific area without leaking. **Mounting matters.** A ceiling-mount AP designed for ceilings, placed on a wall, broadcasts most of its energy into the wall behind it. Match the AP's intended mount. ## CSMA/CA — why Wi-Fi is "slow" Wired Ethernet uses CSMA/CD (Collision Detection). Wi-Fi uses CSMA/CA (Collision **Avoidance**) — because wireless radios can't transmit and receive simultaneously, so they can't detect collisions while transmitting. Steps: 1. **Listen** — is the channel idle? 2. If busy → back off random time, then listen again. 3. If idle → transmit, expect ACK. 4. No ACK = collision assumed → retry. Effects: - Maximum throughput is ~50-60% of raw rate (overhead from ACKs, contention, inter-frame spacing). - More clients = more contention = lower per-client speed. - One slow client (legacy 802.11g) drags everyone down — it holds airtime longer. ## Real-world troubleshooting User says *"Wi-Fi is slow in the conference room."* The questions in order: 1. **What's the RSSI / SNR?** (`wlan show interfaces` on Windows, `airport -I` on macOS). Anything worse than -70 dBm → coverage gap. 2. **What's the band?** Stuck on 2.4 GHz when 5 GHz is available → push the client to dual-band. 3. **How many clients on this AP?** High-density = shared airtime. 4. **Any DFS channel-switch events?** Look at controller logs — sudden 30s blackouts. 5. **Interference?** Walk in with a Wi-Fi scanner (NetSpot, WiFi Explorer, inSSIDer). Look for non-Wi-Fi noise. ## Common mistakes 1. **Treating dBm as percentage.** −60 dBm isn't "60% strength." It's logarithmic — −60 is 1000× stronger than −90. 2. **Over-powering APs.** Cranking AP transmit power doesn't help; clients can hear the AP but the AP can't hear the client back. Power must match the weakest direction (uplink from client). 3. **2.4 GHz channel 3.** Non-overlapping in 2.4 are 1, 6, 11. Any other channel overlaps and creates interference. 4. **Wider channels = always better.** 80 MHz on every AP in an office = constant overlap. Smaller channels with channel reuse beats wider channels in dense areas. 5. **Ignoring sticky clients.** Devices that connect to one AP and stay there even when a better one is closer. Solved with band steering, 802.11k/v assistance, sometimes a forced disassociation policy. 6. **Mixing 802.11b clients with modern.** A single 11b client downshifts the AP to 11b protection mode and tanks throughput for everyone. Turn off 802.11b data rates in 2026. ## Lab to try tonight 1. Install a free Wi-Fi scanner (NetSpot home, inSSIDer, or `iw dev wlan0 scan` on Linux). 2. Walk through your home/office. Note RSSI in each room. 3. Identify your noise sources — count APs on each 2.4 GHz channel. 4. Try switching to a less-congested 5 GHz channel via your AP/router admin GUI. 5. Compare before/after with a speed test from the conference-room corner. 6. Bonus: if you have a spectrum analyzer (Wi-Spy or even Ubiquiti's built-in tools), look for non-Wi-Fi noise — microwaves, Bluetooth, baby monitors. They don't show in normal Wi-Fi scans but they wreck your channel. ## Cheat strip | Concept | Plain English | |---|---| | **2.4 / 5 / 6 GHz** | Bands. 2.4 = range/congested. 5 = default. 6 = new and clean. | | **2.4 GHz non-overlapping** | Only channels 1, 6, 11 (N. America) | | **Channel width** | 20/40/80/160 MHz. Wider = faster per AP, worse for density | | **RSSI** | Signal strength at receiver in dBm. −50 great, −75 poor | | **SNR** | RSSI minus noise. >25 dB = good. The number that actually predicts throughput | | **dBm scale** | Logarithmic. Each −3 dB = half the signal | | **Path loss** | Doubling distance = 6 dB drop. 5 GHz loses more than 2.4 | | **CSMA/CA** | Listen before talk. Why Wi-Fi maxes ~50-60% of raw rate | | **DFS channels** | Must yield to radar — occasional 30s outages | | **Omni vs directional** | Donut radiation vs focused beam — pick to match the area | --- ## Access Point Operating Modes — https://packetmentor.com/topics/ap-operating-modes/ > Cisco AP modes explained — Local, FlexConnect, Bridge / Mesh, Monitor, Sniffer, SE-Connect, Rogue Detector. When each is the right choice in real enterprise Wi-Fi deployments. ## Mental model In a controller-based Wi-Fi deployment (WLC + lightweight APs), every AP joins a wireless LAN controller and runs the **mode** you assigned. The mode determines: - Where client data flows (tunneled to WLC vs switched locally). - Whether the AP serves clients at all (or just listens / sniffs). - What happens when the WAN to the WLC dies. You're not picking a model — you're picking a behavior. The same physical AP can run any of these modes; you just change the mode in the controller. ## The seven modes — what each does ### 1. Local mode (default) Default for in-building corporate deployments. - **Data path:** Client traffic tunneled over CAPWAP to the WLC, decapsulated, then routed/switched. - **Control:** Centralized at the WLC. - **Use when:** APs and WLC are on the same LAN — fast, low-latency tunnel. - **Downside:** All client traffic crosses the WLC. A branch AP with the WLC at HQ means every Wi-Fi packet round-trips through HQ. ### 2. FlexConnect (formerly H-REAP) Built for **branch offices** with the WLC at HQ over WAN. - **Data path:** Client traffic is **switched locally** at the AP — never traverses the WAN to the WLC. - **Control:** Still managed by the WLC, but the AP keeps a local copy of the auth/config so it can keep clients connected if the WAN dies (Standalone state). - **Use when:** Branch with a local internet break-out, or branches where WAN failure must not kill Wi-Fi. - **Two sub-states:** - **Connected** — talking to WLC normally. - **Standalone** — WAN down. AP authenticates clients itself using cached PSK/802.1X creds. Limited features (no new VLAN changes, no central RADIUS unless the AP can still reach it). ### 3. Bridge mode / Mesh The AP becomes a wireless **infrastructure node** rather than serving clients directly. - **Data path:** AP bridges Ethernet to a wireless backhaul radio. Used for outdoor mesh, point-to-point links between buildings, or extending coverage to areas without Ethernet drops. - **Roles:** - **Root AP (RAP)** — has wired uplink, acts as the gateway for the mesh. - **Mesh AP (MAP)** — wireless-only backhaul to a RAP. - **Use when:** Outdoor parking lots, warehouse high-bays, port/yard coverage, or temporary event Wi-Fi. ### 4. Monitor mode AP serves **no clients**. Pure RF monitor. - **Behavior:** Scans all channels on both 2.4/5/6 GHz bands. Detects rogue APs, interference, performs location services, runs CleanAir. - **Use when:** High-density deployment that needs continuous monitoring without giving up client-serving APs. - **Downside:** AP can't serve clients while in this mode — it's a dedicated sensor. ### 5. Sniffer mode AP becomes a **wireless packet sniffer**, streaming 802.11 frames to Wireshark. - **Behavior:** AP listens on one channel and forwards all 802.11 traffic to a remote sniffer host (Wireshark, OmniPeek) via Ethernet. - **Use when:** Troubleshooting roaming, association, or auth issues — you need to see the actual wireless frames, which a normal NIC doesn't capture. - **Downside:** No client service. Single-channel only. ### 6. SE-Connect mode Connects the AP's CleanAir radio to **Spectrum Expert** for deep RF analysis. - **Behavior:** AP becomes a spectrum-analyzer probe streaming raw RF data. - **Use when:** Investigating non-Wi-Fi interference (microwaves, Bluetooth, jammers, faulty radios) — these don't appear on regular Wi-Fi captures. - **Downside:** No client service. ### 7. Rogue Detector Connects via Ethernet to a trunk port; listens for unknown MACs that match wireless clients to detect rogue APs on the wired network. - **Behavior:** Wired-side detection of devices originating wireless traffic. - **Use when:** Compliance environments where you must guarantee no unauthorized AP is bridging wireless onto the wired LAN. - **Mostly legacy** — modern WLCs do rogue detection from local-mode APs that scan briefly between client serving frames. ## Quick comparison | Mode | Serves clients? | Data path | WAN-tolerant? | Typical use | |---|---|---|---|---| | **Local** | Yes | Tunnel to WLC | No (LAN deployment) | HQ campus | | **FlexConnect** | Yes | Switched at AP | Yes — Standalone state | Branch | | **Bridge / Mesh** | RAP/MAP roles | Wireless backhaul | Within mesh | Outdoor, warehouse, P2P | | **Monitor** | No | n/a | n/a | RF intel, rogue detection | | **Sniffer** | No | Forward to Wireshark | n/a | Troubleshooting | | **SE-Connect** | No | Spectrum data | n/a | Non-Wi-Fi interference hunt | | **Rogue Detector** | No | Wired listen | n/a | Compliance / legacy | ## Configuration — set the mode From the WLC GUI (Catalyst 9800 example): > **Configuration > Wireless > Access Points > [AP name] > General tab > AP Mode** CLI (Catalyst 9800): ``` WLC(config)# ap name AP-LOBBY mode flex-connect WLC(config)# ap name AP-LOBBY mode monitor WLC(config)# ap name AP-LOBBY mode sniffer ``` Mode change usually causes the AP to reboot or re-register. ## FlexConnect deep dive — the most CCNA-relevant non-local mode FlexConnect ACL / VLAN mapping is configured per-WLAN at the WLC: ``` WLAN: BRANCH-CORP FlexConnect: Enable FlexConnect Local Switching: Enable VLAN Mapping: SSID → VLAN 20 at branch ``` When a client associates, the AP **tags the traffic into VLAN 20 on the local trunk** rather than encapsulating to the WLC. The WLC still handles auth (via cached creds in Standalone, or live RADIUS in Connected). States to know: - **Authentication Central / Switching Central** — Local mode behavior over FlexConnect — rare. - **Authentication Central / Switching Local** — Standard FlexConnect — auth at WLC, data switched at AP. - **Authentication Local / Switching Local** — Standalone — WAN down, AP using cached creds. ## Common mistakes 1. **Putting branch APs in Local mode.** Every Wi-Fi packet hairpins to HQ. Saturates the WAN. Always FlexConnect for branches. 2. **Forgetting the trunk on a FlexConnect AP's switch port.** Local switching means the AP needs a trunk to deliver client traffic into the right VLAN. An access port on VLAN 1 → all clients land on VLAN 1. 3. **Using Monitor mode on every AP.** You give up half your client-serving capacity. Modern WLCs scan opportunistically — dedicated monitor APs are only needed in critical environments. 4. **Confusing Sniffer mode with packet capture on a switch.** Switch port mirroring captures *wired* frames. Sniffer mode captures *over-the-air* 802.11 frames including beacons, probes, retries — invisible at the switch. 5. **Mesh without good RF planning.** A 3-hop mesh chain loses about half its throughput per hop. Always cable as many APs as you can; mesh is a last resort. 6. **Treating SE-Connect as a normal sniffer.** SE-Connect is for non-Wi-Fi interference. For 802.11 packets, use Sniffer mode. ## Real-world deployments - **Bank HQ + 30 branches** — HQ APs in **Local**, branch APs in **FlexConnect** so a leased-line failure doesn't kill teller Wi-Fi. - **Warehouse** — root AP cabled at the door, **Mesh APs** on poles inside the high-bay aisles. - **Hospital** — most APs in **Local**, two per floor permanently in **Monitor** for rogue detection in HIPAA-sensitive areas. - **Trade-show venue** — temporary deployment, every AP in **FlexConnect** because the controller is over a VPN. - **Engineer chasing a microwave** — pick one AP, switch it to **SE-Connect**, point it at the suspect area, look for the 2.4 GHz noise spike. ## Lab to try tonight 1. In a Cisco Catalyst 9800 (or 9800-CL virtual on your laptop), join one AP. 2. By default it'll be Local. Verify: `show ap summary`. 3. From the GUI, change the AP to **FlexConnect**. Wait for the reload. 4. Verify it reassociates as FlexConnect: `show ap name AP-1 config general | include AP Mode`. 5. Disconnect the WLC (`shut` its uplink). The AP should enter **Standalone**. A pre-associated client should keep working (try ping). 6. Reconnect. AP returns to **Connected**. Verify. 7. Bonus: switch the AP to **Monitor** mode. Verify it no longer broadcasts an SSID (`show wireless wlan summary` from client view). 8. Bonus: switch to **Sniffer**, point it at your laptop running Wireshark on the same management VLAN. Capture an association exchange. ## Cheat strip | Mode | One-line purpose | |---|---| | **Local** | Default. Centralized control + data plane to WLC | | **FlexConnect** | Switches data locally at AP. Survives WAN outage (Standalone state) | | **Bridge / Mesh** | RAPs and MAPs — wireless backhaul instead of Ethernet | | **Monitor** | RF sensor only — no client serving | | **Sniffer** | Streams 802.11 frames to remote Wireshark | | **SE-Connect** | Spectrum analyzer probe — find non-Wi-Fi interference | | **Rogue Detector** | Wired-side rogue AP detection. Mostly legacy | | **Branch deployment** | FlexConnect, always | | **Standalone state** | FlexConnect AP authenticating clients itself when WAN to WLC is down | | **CAPWAP** | Tunnel protocol between AP and WLC — UDP 5246 (control) / 5247 (data) | ## Choosing a mode — quick decision guide 1. **Is the WLC on the same LAN as the AP?** → **Local** (default, and it just works). 2. **Is the AP in a branch office with the WLC over WAN?** → **FlexConnect** (local switching, survives WAN outage). 3. **Is the AP outdoors, in a warehouse aisle, or between two buildings with no Ethernet?** → **Bridge / Mesh** (Root AP + Mesh APs on wireless backhaul). 4. **Do you need dedicated RF monitoring for compliance or high-density optimization?** → **Monitor** (no client serving, pure sensor). 5. **Are you troubleshooting an association / roaming / auth failure?** → **Sniffer** (temporarily, then flip back). 6. **Chasing non-Wi-Fi RF noise (microwave, radar, Bluetooth flood)?** → **SE-Connect** (spectrum probe). 7. **Legacy compliance environment with wired-rogue-AP detection requirement?** → **Rogue Detector** (rare; modern WLCs handle rogue detection from Local APs). ## Troubleshooting the AP join process When an AP won't join the WLC, walk this checklist top-to-bottom. It maps to the CAPWAP state machine. - **Interface up?** `show interface status` on the switch. Look for `notconnect` or `err-disabled`. - **PoE delivered?** `show power inline`. Wi-Fi 6 APs need PoE+; Wi-Fi 6E/7 often need 802.3bt. - **Correct VLAN + DHCP?** The AP\'s access port should be in the AP-management VLAN. AP boots with DHCP-assigned IP, gateway, DNS. - **Option 43 in the DHCP scope?** The AP looks for DHCP option 43 to learn the WLC IP. Format is hex-encoded — a common gotcha. - **DNS record `CISCO-CAPWAP-CONTROLLER.`?** Alternate discovery path when option 43 isn\'t set. - **CAPWAP UDP 5246/5247 permitted end-to-end?** Firewalls in the middle block this often. - **AP image compatible with WLC version?** Mismatched Cisco AP OS and WLC IOS-XE cause the join to fail after CAPWAP starts. `show ap join stats detailed ` on the WLC gives you the exact CAPWAP stage that failed. ## Frequently asked questions **Q: If a FlexConnect AP is in Standalone mode, can it still authenticate new clients?** A: Yes for cached PSK and 802.1X users the AP has seen before. Not for brand-new users unless the local RADIUS is reachable. Cache size and behavior are configured under WLAN → FlexConnect → Local Auth. **Q: What is CAPWAP and why do lightweight APs need it?** A: CAPWAP (Control And Provisioning of Wireless Access Points, RFC 5415) is the standardized tunnel between a lightweight AP and its WLC. Control plane runs on UDP 5246 (DTLS-encrypted); data plane on UDP 5247. Because it tunnels, AP and WLC don\'t need to sit on the same L2 segment. **Q: Can one physical AP run more than one mode at a time?** A: No — mode is a global setting per AP. A single AP is Local OR FlexConnect OR Monitor at any moment. However, on multi-radio APs (6 GHz + 5 GHz + 2.4 GHz), the WLC can independently disable radios for client-serving while the AP still scans other channels. **Q: How do I convert a Local-mode AP into a FlexConnect AP without a reboot?** A: You can\'t; mode change triggers a reload. Schedule the change during a maintenance window. **Q: Does Monitor mode work with WPA3?** A: Yes — Monitor mode is passive listening. It doesn\'t need the same encryption context because it\'s reading beacons, probes, and management frames only. **Q: How does an autonomous AP differ from a lightweight AP?** A: Autonomous APs have their own local config for SSID, security, VLAN. Lightweight APs are effectively "radio heads" — all config lives on the WLC. Enterprises overwhelmingly use lightweight; autonomous survives in tiny 1–3 AP deployments. **Q: Do the CCNA 200-301 and CCNP Enterprise exams cover the same AP modes?** A: The CCNA scope covers Local, FlexConnect, and (lightly) the concept of Bridge / Monitor. CCNP goes deeper into Monitor / Sniffer / SE-Connect operational details and adds Cisco DNA Assurance-driven mode-switching automation. **Q: What happens to a FlexConnect AP\'s clients when the WAN comes back?** A: Sessions stay up. The AP transitions from Standalone → Connected and resumes reporting stats to the WLC. Any new WLAN-config changes queued during the outage are then applied. --- ## DHCP — Dynamic Host Configuration Protocol — https://packetmentor.com/topics/dhcp/ > Definitive CCNA-level DHCP guide — the DORA exchange step-by-step, packet anatomy, DHCP options table, lease renewal timing (T1/T2), Cisco IOS server + relay config, DHCPv6 brief, DHCP Snooping security, 8 worked scenarios, and the DHCP debug workflow. ## Mental model A device that just plugged in has no IP. It can't send unicast traffic — there's no source IP to put in the packet. So it broadcasts: > *"Hello? Anyone? I need an IP."* If a DHCP server is on the same broadcast domain (same VLAN / subnet), it hears the request and answers. If the server is on a different subnet, the router between them needs to be told to forward the broadcast — that's the `ip helper-address` command (covered in [DHCP Relay](/topics/dhcp-relay/)). That's the whole story. The rest is detail — what's in each message, what gets configured where, and how attackers exploit it. ## Why DHCP exists Before DHCP (which came from BOOTP in the early 1990s), every network host needed its IP, mask, gateway, and DNS **statically configured by a human**. A typo on one host = no connectivity for that host. Moving a host to a new subnet = full reconfiguration. DHCP automates all of that. Today's PCs, phones, IoT devices, virtual machines — billions of them — all use DHCP. Without it, modern networks would be unmanageable. ## The DORA exchange — what each message does ``` Step 1 — DISCOVER (client → broadcast): "Hi. I have MAC AA:BB:CC:11:22:33. I need an IP." Step 2 — OFFER (server → broadcast): "Hi MAC AA:BB... here's 10.0.0.45/24, gateway 10.0.0.1, DNS 8.8.8.8, lease 1 day." Step 3 — REQUEST (client → broadcast): "I accept 10.0.0.45 offered by server 10.0.0.1." (Other servers see this and withdraw their offers.) Step 4 — ACK (server → broadcast): "Confirmed. 10.0.0.45 is yours until lease expires." ``` | # | Letter | From | To | UDP port | Carries | |---|---|---|---|---|---| | 1 | **D**iscover | Client (`0.0.0.0`) | Broadcast (`255.255.255.255`) | 68 → 67 | Client MAC + request hints | | 2 | **O**ffer | Server | Broadcast (`255.255.255.255`) | 67 → 68 | Offered IP + mask + lease + options | | 3 | **R**equest | Client | Broadcast (`255.255.255.255`) | 68 → 67 | Selected offer (named server) | | 4 | **A**ck | Server | Broadcast | 67 → 68 | Lease confirmed | **Why all four are broadcasts:** the client has no IP yet (Discover, Request) or is committing publicly so other DHCP servers can withdraw competing offers. The Offer and Ack are broadcasts because the client doesn't yet have its IP bound to its interface, so a unicast back would be invisible to the OS. ### The race when multiple servers exist If two DHCP servers see the Discover, both send Offers. The client picks one (usually the first one received) and references the chosen server's ID in the Request. The losing server sees the Request, recognizes it didn't win, and frees up the address it had tentatively reserved. This is why DHCP failover designs need careful planning — naively running two servers with the same scope causes IP conflicts. ## Packet anatomy — what's in a DHCP message A DHCP packet is a BOOTP message with extensions. The fields you'll care about: ``` op — 1 = request (Discover/Request), 2 = reply (Offer/Ack) htype — Hardware type (1 = Ethernet) chaddr — Client hardware (MAC) address ciaddr — Client IP (filled in only on renewal) yiaddr — "Your" IP — the address being offered to the client siaddr — Server IP giaddr — Gateway IP (set by DHCP relay agent — see Relay section) options — Variable-length list of typed values (covered below) ``` The **`giaddr`** field is critical for DHCP relay. When a router relays a Discover, it stamps `giaddr` with its own interface IP. The server uses `giaddr` to pick the right scope (the one whose subnet contains `giaddr`) and sends the Offer back to `giaddr` for relay back to the client. ## DHCP options — the parts that confuse everyone DHCP carries the IP + mask in fixed fields. Everything else (gateway, DNS, lease time, domain name, NTP server, TFTP server, vendor-specific stuff) lives in **options** — numbered TLV (type-length-value) entries. | Option # | Name | Purpose | |---|---|---| | **1** | Subnet mask | Network mask for the client (often inferred from scope, but explicit is OK) | | **3** | Router | Default gateway IP | | **6** | Domain Name Server | DNS server IPs (one or more) | | **15** | Domain Name | DNS search suffix (e.g., `corp.example.com`) | | **42** | NTP Server | NTP server IPs | | **43** | Vendor Specific | Used heavily for Cisco APs (controller discovery), Avaya phones, etc. | | **51** | Lease Time | In seconds. Default ~86400 (1 day) | | **53** | DHCP Message Type | 1=Discover, 2=Offer, 3=Request, 4=Decline, 5=Ack, 6=Nak, 7=Release, 8=Inform | | **66** | TFTP Server Name | Used for IP phone boot | | **67** | Bootfile Name | Used for PXE boot | | **82** | Relay Agent Information | Inserted by DHCP relay agents — origin context for the server | | **150** | Cisco TFTP Server | Cisco-specific TFTP option for IP phones | **CCNA exam loves option numbers.** Memorize at least: 3 (router), 6 (DNS), 51 (lease), 53 (msg type), 82 (relay info), 150 (Cisco TFTP for phones). ## Lease timing — T1 and T2 DHCP doesn't just hand out IPs forever. Each lease has a duration. The client renews before it expires. - **T1 = 50% of lease** — client tries to renew with the **same server** via unicast Request. If Ack received, lease extends. (No DORA — this is a 2-message renewal.) - **T2 = 87.5% of lease** — if no renewal yet, client broadcasts a Rebind Request to any server. (Still 2-message.) - **Lease expiration** — if still no response, client gives up, releases IP, starts a full DORA. Default lease times vary: - Cisco IOS server default: **1 day**. - Windows Server / Linux ISC DHCP default: **8 days**. - Home routers: typically **1 day**. Trade-off: - **Short leases** (hours) — more accurate IP turnover, more DHCP traffic, server CPU higher. - **Long leases** (a week+) — quiet DHCP server, but if you change scope settings (new DNS, new gateway) clients don't pick up the change until renewal. For a typical office: 8 hours to 1 day is the sweet spot. ## Cisco IOS DHCP server — config The router (or L3 switch) itself can run DHCP. Common for branch offices. ``` ! Exclude addresses the server should NOT hand out R1(config)# ip dhcp excluded-address 10.0.0.1 10.0.0.10 R1(config)# ip dhcp excluded-address 10.0.0.250 10.0.0.254 ! Define the pool R1(config)# ip dhcp pool USERS R1(dhcp-config)# network 10.0.0.0 255.255.255.0 R1(dhcp-config)# default-router 10.0.0.1 R1(dhcp-config)# dns-server 8.8.8.8 1.1.1.1 R1(dhcp-config)# domain-name corp.example.com R1(dhcp-config)# lease 1 ! 1 day R1(dhcp-config)# option 150 ip 10.1.1.5 ! Cisco IP phone TFTP ``` **Always** exclude: - The router's own IP (`.1` here). - Any static-assigned servers, printers, APs, switches with management IPs in this subnet. - A reserved chunk at the end for future static assignments (e.g., `.250–.254`). Verify with: ``` R1# show ip dhcp binding R1# show ip dhcp pool R1# show ip dhcp conflict R1# show ip dhcp server statistics ``` `show ip dhcp binding` lists every active lease — IP + MAC + lease expiration. Daily-driver debug command. ### Multiple pools on one router You can serve DHCP for many subnets from one router. Each subnet needs its own pool. The router picks the right pool by matching the `giaddr` (or the receiving interface's subnet for directly-connected clients). ``` R1(config)# ip dhcp pool USERS R1(dhcp-config)# network 10.0.0.0 255.255.255.0 R1(dhcp-config)# default-router 10.0.0.1 R1(dhcp-config)# dns-server 8.8.8.8 R1(config)# ip dhcp pool SERVERS R1(dhcp-config)# network 10.0.10.0 255.255.255.0 R1(dhcp-config)# default-router 10.0.10.1 R1(dhcp-config)# dns-server 8.8.8.8 R1(config)# ip dhcp pool VOICE R1(dhcp-config)# network 10.0.20.0 255.255.255.0 R1(dhcp-config)# default-router 10.0.20.1 R1(dhcp-config)# option 150 ip 10.1.1.5 ``` ### Static (manual) bindings Some hosts should always get the same IP — printers, IP phones with extension-based dialing, license-bound servers. Two options: **Option 1 — exclude + static configure on the host.** Simpler. Doesn't scale. **Option 2 — DHCP manual binding** (also called DHCP reservation): ``` R1(config)# ip dhcp pool PRINTER-OFFICE R1(dhcp-config)# host 10.0.0.50 255.255.255.0 R1(dhcp-config)# client-identifier 0100.5056.b322.45 ! MAC with type prefix R1(dhcp-config)# default-router 10.0.0.1 ``` `client-identifier` is the MAC address with a leading `01` (Ethernet hardware type) and dots. The printer always gets `10.0.0.50`. Multiple manual bindings → multiple `ip dhcp pool` blocks, one per device. ## DHCP Relay — bridging broadcasts across subnets Routers don't forward broadcasts. So if your DHCP server is on a different subnet (often the case in enterprise), the router needs explicit instructions to relay DHCP broadcasts to specific servers: ``` ! On the interface facing the clients R1(config)# interface Vlan10 R1(config-if)# ip helper-address 10.99.0.5 R1(config-if)# ip helper-address 10.99.0.6 ! optional second server ``` `ip helper-address` forwards eight specific UDP services by default (including DHCP). The router: 1. Receives the broadcast Discover. 2. Converts it to a unicast to the helper IP, stamping `giaddr` = the receiving SVI's IP. 3. Server uses `giaddr` to pick the right scope, sends Offer back to `giaddr`. 4. Router broadcasts the Offer on the client's subnet. See [DHCP Relay](/topics/dhcp-relay/) for full Option-82 + multi-relay coverage. ### What else `ip helper-address` forwards By default it forwards eight UDP ports: 37 (Time), 49 (TACACS), 53 (DNS), 67 (DHCP), 68 (DHCP), 69 (TFTP), 137 (NetBIOS), 138 (NetBIOS). To restrict: ``` R1(config)# no ip forward-protocol udp 137 R1(config)# no ip forward-protocol udp 138 ``` Or whitelist: ``` R1(config)# no ip forward-protocol udp 37 R1(config)# no ip forward-protocol udp 49 R1(config)# no ip forward-protocol udp 53 R1(config)# no ip forward-protocol udp 69 R1(config)# no ip forward-protocol udp 137 R1(config)# no ip forward-protocol udp 138 ! Keep only DHCP 67/68 ``` ## DHCP Snooping — the must-have security feature **Rogue DHCP server** is the classic LAN attack: attacker plugs in a tiny DHCP server, hands out a malicious gateway IP, becomes a MITM for everyone on the VLAN. **DHCP Snooping** is the switch's defense. You designate "trusted" ports where legitimate DHCP servers live (uplinks, sometimes the SVI). All other ports are untrusted — the switch silently drops any DHCP server-side messages (Offer, Ack, Nak) arriving on them. ``` SW1(config)# ip dhcp snooping SW1(config)# ip dhcp snooping vlan 10,20,30 ! Mark uplinks / trusted ports SW1(config)# interface Gi1/0/24 SW1(config-if)# ip dhcp snooping trust ! Optional: rate-limit DHCP messages on untrusted ports (anti-starvation) SW1(config)# interface range Gi1/0/1 - 23 SW1(config-if-range)# ip dhcp snooping limit rate 100 ``` Snooping also builds a **binding table** of IP-to-MAC-to-port mappings — used by Dynamic ARP Inspection and IP Source Guard to enforce identity. See [DHCP Snooping](/topics/dhcp-snooping/) for the deep dive. ## DHCPv6 — the IPv6 cousin DHCPv6 (RFC 8415) is a different protocol despite the name. Three notable differences: 1. **Two modes:** Stateful (assigns full IPv6 addresses) and Stateless (only assigns DNS/etc., leaves addressing to SLAAC). 2. **No broadcast in IPv6.** DHCPv6 uses link-local multicast (`ff02::1:2`). 3. **DUIDs replace MACs.** Client identifier is a DHCP Unique Identifier, not a MAC directly. For CCNA-level coverage of IPv6 addressing see [IPv6 Basics](/topics/ipv6-basics/) and [IPv6 SLAAC](/topics/ipv6-slaac/). DHCPv6 stateless mode often pairs with SLAAC. ## Verification — the five commands ``` R1# show ip dhcp binding R1# show ip dhcp pool R1# show ip dhcp conflict R1# show ip dhcp server statistics R1# debug ip dhcp server packet ! high volume — use sparingly ``` | Command | Tells you | |---|---| | `show ip dhcp binding` | Every active lease — IP, MAC, lease time | | `show ip dhcp pool` | Pool stats — IPs in pool, allocated, free | | `show ip dhcp conflict` | Pool entries the server detected as duplicates (someone else using the IP) | | `show ip dhcp server statistics` | Message counts (Discovers, Offers, Acks) — useful for spotting flapping clients | | `debug ip dhcp server packet` | Live message trace. Watch DORA in action. | ## The 6-step DHCP debug workflow When a client says "I'm not getting an IP": 1. **Same subnet as the server?** If yes, broadcasts reach the server directly. If no, you need `ip helper-address` on the client-facing interface. Verify with `show running-config interface ...`. 2. **Server side seeing the Discover?** `debug ip dhcp server packet` with filtering. If no Discover arrives, the broadcast isn't reaching the server (routing, ACL, helper issue). 3. **Pool has free addresses?** `show ip dhcp pool`. If full or exhausted, no Offer comes back. 4. **Wrong pool matching?** With multiple pools on one server, the `giaddr` (or interface) determines which pool. If `giaddr` doesn't fall within any pool's network, no Offer. 5. **Conflict detected?** `show ip dhcp conflict`. The server may have detected the IP it tried to offer is already in use (someone configured statically). Server skips and tries next. 6. **Client behaving correctly?** From client: re-trigger DHCP. Windows: `ipconfig /release` + `ipconfig /renew`. macOS: System Settings → Network → Make Service Inactive → Reactivate. Linux: `dhclient -v eth0`. ## Worked scenarios --- **Scenario 1.** A user complains their PC is getting `169.254.42.10`. What does that tell you? **Answer:** APIPA (Automatic Private IP Addressing) — the `169.254.0.0/16` range. The PC tried DHCP, got no response, fell back to self-assigning. Means DHCP server is unreachable. Check: switch port state, VLAN, `ip helper-address` on the gateway, DHCP server availability. --- **Scenario 2.** A new VLAN was added. Hosts in it can't get DHCP. The DHCP server is on a different VLAN. The other VLANs work fine. **Answer:** New VLAN's SVI is missing `ip helper-address`. Add it: ``` R1(config)# interface Vlan50 R1(config-if)# ip helper-address 10.99.0.5 ``` --- **Scenario 3.** Pool gives out IPs but every client also gets `10.0.0.1` as gateway. That's the router's IP. Now both router and a client have `10.0.0.1`. Why? **Answer:** The router's IP wasn't excluded from the pool. Add: ``` R1(config)# ip dhcp excluded-address 10.0.0.1 ``` And remove the conflict via `clear ip dhcp conflict *`. --- **Scenario 4.** A user reports their PC's IP keeps changing. New IP every day. What's wrong? **Answer:** Lease is too short, OR DHCP server is rebooting and forgetting the binding (no persistent lease database). Check `show ip dhcp pool` lease time. Default 1 day with proper persistence should give the same IP back to the same MAC on each renewal. --- **Scenario 5.** Two DHCP servers exist in the same broadcast domain offering the same scope. What happens? **Answer:** Race condition. Both Offer; client picks one (typically the first Offer received). Other server frees the address it offered. In the long run, IPs from both servers get handed out — risk of IP conflicts if scopes overlap. Fix: ONE DHCP authority per subnet (use DHCP failover or just pick one). --- **Scenario 6.** An attacker plugs in a rogue DHCP server handing out gateway `10.0.0.99` (attacker's MITM box). Some clients get the attacker's gateway and route through them. How do you prevent this in the future? **Answer:** Enable DHCP Snooping on all access switches: ``` SW1(config)# ip dhcp snooping SW1(config)# ip dhcp snooping vlan 10,20,30,40 SW1(config-if)# ip dhcp snooping trust ! ONLY on uplinks to legitimate DHCP servers ``` Everything else is untrusted by default — switch silently drops rogue Offers/Acks. --- **Scenario 7.** An IP phone shows "no TFTP server" error during boot. **Answer:** Missing **Option 150** in the voice VLAN's DHCP pool. Add: ``` R1(config)# ip dhcp pool VOICE R1(dhcp-config)# option 150 ip 10.1.1.5 ! TFTP server IP ``` Reboot the phone to re-request DHCP. (Option 66 is the standards-based alternative; Option 150 is Cisco-specific. Many phones support either or both.) --- **Scenario 8.** You want host `aa:bb:cc:11:22:33` to always receive IP `10.0.0.50`. How? **Answer:** Either exclude `10.0.0.50` and set it statically on the host, or create a manual binding: ``` R1(config)# ip dhcp pool PRINTER R1(dhcp-config)# host 10.0.0.50 255.255.255.0 R1(dhcp-config)# client-identifier 01aa.bbcc.1122.33 R1(dhcp-config)# default-router 10.0.0.1 ``` The `01` prefix indicates Ethernet hardware type. The host's MAC follows. ## Common mistakes 1. **Forgetting `ip helper-address` in routed networks.** Symptom: APIPA addresses (`169.254.x.x`). Fix: helper-address on every client-facing SVI pointing to the DHCP server(s). 2. **Not excluding the gateway IP.** Pool happily hands out the router's IP → conflict. Always `ip dhcp excluded-address` for router, static servers, reserved range. 3. **Lease too short.** 1 hour lease = renewals every 30 min = noisy logs + server CPU. Default 1 day is usually fine. 4. **Two DHCP servers on same broadcast domain with same scope.** Race; possible conflicts. Pick one authority. 5. **Trusting any DHCP server.** Rogue server attacks. Enable DHCP Snooping with `trust` only on legitimate uplinks. 6. **Wrong DHCP option numbers.** Option 3 = router, 6 = DNS, 51 = lease, 150 = Cisco TFTP. Memorize. 7. **Manual binding without `client-identifier` prefix.** Cisco IOS requires the `01` (Ethernet) prefix before the MAC. `client-identifier aa.bbcc.1122.33` (missing prefix) silently fails to bind. 8. **DHCP for static infrastructure.** Routers, switches, AP controllers should have static IPs — never DHCP. Server reboot during a DHCP outage = infrastructure outage compounded. 9. **No DHCP failover plan.** Enterprise DHCP needs failover. Cisco IOS server is not great for this; Windows or ISC DHCP with proper failover config is the enterprise standard. 10. **Forgetting that DHCP runs at L2.** DHCP traffic is broadcast at the link layer, even though it carries L3 information. Routes don't help DHCP reach a server on a different subnet — only helper-address does. ## Lab to try tonight 1. **Single-router DHCP** — one router, one switch, two PCs. Router has `10.0.0.1/24` on its LAN interface. 2. **Configure DHCP server** on the router. Exclude `10.0.0.1–10.0.0.10`. Pool gives out `10.0.0.11+` with default-router `10.0.0.1`, DNS `8.8.8.8`, lease 1 day. 3. **Verify** — set both PCs to DHCP, watch them get IPs. `show ip dhcp binding` confirms both leases. 4. **DHCP relay** — add a second router with `10.1.0.0/24`. Connect a PC. Set PC to DHCP — observe APIPA failure (`169.254.x.x`). 5. **Add `ip helper-address`** on the second router's LAN interface pointing to the first router. Re-trigger DHCP on the PC. Verify it gets a `10.1.0.x` IP. 6. **Lease renewal observation** — set lease to 2 minutes for testing. Watch the PC renew at T1 (50%, so 1 min). Use `debug ip dhcp server packet` to see the unicast Renew. 7. **Manual binding** — create a manual binding for one PC's MAC. Release/renew that PC. Verify it gets the bound IP exactly. 8. **DHCP Snooping** — enable on the switches. Add a fake DHCP server on an untrusted port (use a second router temporarily). Watch the snooping table block the rogue Offers. `show ip dhcp snooping binding` shows legitimate bindings only. 9. **Option 150 test** — configure Option 150 in the voice VLAN pool. Capture a packet exchange (using Wireshark / mirror port) and inspect the Option 150 in the Offer. 10. **Bonus — DHCP starvation simulation.** Use `dhcpig` or `yersinia` against an unrestricted switch port. Watch the pool deplete. Apply DHCP Snooping rate-limit + Port Security to mitigate. ## Cheat strip | Concept | Plain English | |---|---| | **DORA** | Discover → Offer → Request → Ack | | **All broadcast** | All 4 DORA messages are L2 broadcasts | | **UDP ports** | 67 = server, 68 = client | | **Renewal** | T1 (50%) unicast Renew, T2 (87.5%) broadcast Rebind, then expiry | | **giaddr** | Gateway IP — stamped by relay agents to identify source subnet | | **Lease default** | Cisco IOS = 1 day. Windows = 8 days | | **`ip helper-address`** | Relay DHCP broadcasts across an L3 boundary | | **`excluded-address`** | IPs the pool must not hand out (gateway, statics) | | **DHCP Snooping** | Switch-side security — only trust DHCP server messages on specific ports | | **Option 1** | Subnet mask | | **Option 3** | Default gateway | | **Option 6** | DNS server | | **Option 15** | DNS search domain | | **Option 42** | NTP server | | **Option 51** | Lease time (seconds) | | **Option 53** | DHCP message type | | **Option 66** | TFTP server (standards) | | **Option 82** | Relay agent info — for ISP / DHCP server logging | | **Option 150** | Cisco-specific TFTP for IP phones | | **APIPA** | 169.254.0.0/16 — auto-self-assigned when DHCP fails | | **Static binding** | Manual reservation — `client-identifier 01...` with `01` Ethernet prefix | | **DHCPv6** | Different protocol. Uses multicast `ff02::1:2`. Often paired with SLAAC | | **Stateless mode** | DHCPv6 hands out DNS only; SLAAC handles addressing | ## Frequently asked questions **Q: What's the difference between DHCP and DHCPv6?** A: DHCPv4 (the classic) assigns IPv4 addresses plus options like default gateway and DNS. DHCPv6 comes in two flavours: stateful (assigns full IPv6 addresses like DHCPv4 does) and stateless (only hands out DNS + other options, letting the client build its own address via SLAAC). Modern IPv6 dual-stack designs typically use SLAAC + stateless DHCPv6 for DNS, not the stateful mode. **Q: What port does DHCP use?** A: UDP 67 (server) and UDP 68 (client). DHCP predates DNS-style discovery, so the client sends its initial DISCOVER to broadcast 255.255.255.255:67 — the client doesn't yet have an IP or know where the server is. Any DHCP server on the same broadcast domain (or reachable via a DHCP relay) responds. Because broadcasts don't cross routers, servers on other subnets require an `ip helper-address` on the router's interface facing the client subnet. **Q: How do I configure a router as a DHCP relay?** A: `ip helper-address ` on the interface facing the clients. The router intercepts client broadcasts and forwards them as unicast to the specified server (which responds with a unicast back through the same relay). This lets one central DHCP server serve dozens of subnets. Common gotcha: `ip helper-address` also forwards other UDP protocols (TFTP, NetBIOS, DNS) by default — use `no ip forward-protocol udp ` to trim what you don't want relayed. **Q: What's DHCP snooping and why do I need it?** A: DHCP snooping is a switch feature that trusts DHCP replies only from designated ports (the ones connected to your real DHCP servers) and drops replies from anywhere else. Without it, an attacker on the LAN can plug in a rogue DHCP server, hand out its own IP as the default gateway, and man-in-the-middle every user. Snooping also builds a binding table (MAC → IP → port) that's used by Dynamic ARP Inspection and IP Source Guard. **Q: Can a client keep its IP after the DHCP lease expires?** A: Only briefly. Clients start trying to renew at 50% of the lease (the T1 timer) and try again at 87.5% (T2). If both fail, the client keeps the address until the lease actually expires, then must release it and request a new one. In practice this rarely matters because renewals almost always succeed; where you notice it is a hard reboot of the DHCP server during an outage, where clients hold their addresses long enough for you to recover. --- ## NAT & PAT — https://packetmentor.com/topics/nat/ > Definitive CCNA-level NAT guide — static NAT, dynamic NAT, PAT/overload, the four inside/outside terms, port forwarding, CGNAT, NAT64 brief, hairpin NAT, translation table limits, 8 worked scenarios, and the NAT debug workflow. ## Mental model The public internet is running out of IPv4 addresses. NAT is the band-aid that's kept IPv4 alive for 25+ years past its expected end. The trick: organizations use **private IP ranges** (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) internally — ranges the public internet refuses to route. When a private host wants to reach the internet, the **NAT router on the edge rewrites the source IP** from private to a public address it owns. The reply comes back to the public IP; the router looks at its translation table and rewrites the destination back to the private IP before forwarding internally. The price: NAT **breaks the end-to-end principle** of the internet. A host behind NAT cannot be directly addressed from outside without an explicit forwarding rule. Many protocols (SIP, FTP active mode, IPsec, peer-to-peer) require special NAT-traversal helpers to work through it. [IPv6](/topics/ipv6-basics/) was designed to fix this by giving every device a unique routable address — but until v6 is universal, NAT stays. ## RFC 1918 — the private ranges | Range | Size | Common use | |---|---|---| | `10.0.0.0/8` | 16,777,216 addresses | Large enterprise, ISP CGN customer-facing | | `172.16.0.0/12` | 1,048,576 addresses | Mid-size enterprise, AWS VPC default range | | `192.168.0.0/16` | 65,536 addresses | Home + SMB | Plus the more recent **CGNAT range** (RFC 6598): | Range | Size | Use | |---|---|---| | `100.64.0.0/10` | 4,194,304 addresses | ISP carrier-grade NAT, not routable on the public internet | The public internet routes none of these. If you tried to send a packet from `10.0.0.5` to `8.8.8.8` directly without NAT, your ISP would drop it. (New to CIDR notation like `/8` and `/12`? See [Subnetting](/topics/subnetting/).) ## The three flavors of NAT | Flavor | Mapping | Used for | |---|---|---| | **Static NAT** | Fixed 1:1 (one inside IP always maps to one outside IP) | Inside servers reachable from internet | | **Dynamic NAT** | Pool of public IPs, handed out 1:1 as needed, returned to pool when idle | Less common in 2026 — rare to have a pool of unused public IPs | | **PAT (Port Address Translation / NAT Overload)** | Many inside IPs share one public IP, distinguished by source port | The standard. Home routers, branch offices, most enterprise edges. | PAT is what you'll deploy 99% of the time. CCNA exam tests all three. ## The four terms — inside / outside, local / global The single biggest CCNA NAT confusion. Memorize this: - **Inside** = our network's hosts. - **Outside** = hosts on someone else's network. - **Local** = the address as seen from the inside. - **Global** = the address as seen from the outside (the routable internet). Apply both axes: | Term | What it means | Example | |---|---|---| | **Inside Local** | Our host's private IP, before translation | `10.0.0.5` | | **Inside Global** | Our host's public IP, after translation | `203.0.113.7` | | **Outside Global** | The remote host's real IP on its own network | `8.8.8.8` | | **Outside Local** | The remote host's IP as seen from our inside (usually same as Outside Global, but can differ with Twice-NAT) | `8.8.8.8` | The CCNA exam loves to ask "if `10.0.0.5` becomes `203.0.113.7` talking to `8.8.8.8`, what is the Inside Global address?" Answer: `203.0.113.7`. Just remember **inside = our hosts**, **local = before translation, global = after translation**. ### Why "Outside Local" exists In simple NAT, Outside Local = Outside Global. They diverge only with **NAT64** or **double NAT** scenarios where the outside host is presented to inside clients with a *different* IP than its real one. Rare in CCNA scope but recognize it exists. ## PAT — what your home router does PAT (Port Address Translation, or NAT Overload) lets many inside hosts share one outside IP. Distinction is the **source port** of each conversation. ``` Inside: Outside: 10.0.0.5 : 50000 → 8.8.8.8 : 443 10.0.0.6 : 51000 → 8.8.8.8 : 443 (different conversations) 10.0.0.7 : 52000 → 8.8.8.8 : 443 ↓ (NAT router rewrites source IP + possibly source port) Translation table: 10.0.0.5 : 50000 ↔ 203.0.113.7 : 50000 ↔ 8.8.8.8 : 443 10.0.0.6 : 51000 ↔ 203.0.113.7 : 51000 ↔ 8.8.8.8 : 443 10.0.0.7 : 52000 ↔ 203.0.113.7 : 52000 ↔ 8.8.8.8 : 443 Packets leaving the router: 203.0.113.7 : 50000 → 8.8.8.8 : 443 203.0.113.7 : 51000 → 8.8.8.8 : 443 203.0.113.7 : 52000 → 8.8.8.8 : 443 ``` All three conversations come from the same public IP — the router tells them apart by source port. Each entry stays in the translation table until the conversation ends or times out (default ~24h for TCP, ~5min for UDP, ~60s for ICMP — these matter for troubleshooting). ### Port collision handling If two inside hosts use the same source port (`10.0.0.5:50000` and `10.0.0.6:50000`), the router rewrites one of them to a different source port to keep them unique. The translation table tracks this. ### ICMP has no ports — PAT uses the Query ID TCP and UDP carry source ports, so PAT has an obvious field to overload. **ICMP doesn't have ports.** When you `ping` from behind PAT, the router can't rewrite a source port — instead it rewrites the **ICMP Query Identifier** to keep each host's echoes unique, then matches the replies back the same way. Same idea, different field. The CCNA likes to check that you know ICMP traffic isn't port-based. Theoretical limit: ~65,000 conversations per (public IP, protocol) pair (the size of the source-port range). Practical limit on a Cisco router is lower — platform-dependent — usually thousands to tens of thousands. The CGNAT scale issue is real and is why ISPs use multiple public IPs per CGNAT node. ## Configuration — the four canonical patterns ### Pattern 1: PAT (overload) — the typical home/SMB config ``` ! Mark inside and outside interfaces R1(config)# interface GigabitEthernet0/0 R1(config-if)# description LAN — inside R1(config-if)# ip nat inside R1(config)# interface GigabitEthernet0/1 R1(config-if)# description WAN — outside R1(config-if)# ip nat outside ! Define what's eligible for translation (which inside sources) R1(config)# ip access-list standard NAT-INSIDE R1(config-std-nacl)# permit 10.0.0.0 0.0.0.255 ! Enable PAT, overloading on the outside interface R1(config)# ip nat inside source list NAT-INSIDE interface GigabitEthernet0/1 overload ``` The `overload` keyword makes it PAT. Without it, you get plain dynamic NAT (1:1) which exhausts when you run out of pool IPs. The [ACL](/topics/acls/) (`NAT-INSIDE` here) decides *which* inside sources get translated — point it at your outside public IPs by mistake and nothing will match. ### Pattern 2: Dynamic NAT (pool-based, 1:1) ``` R1(config)# ip nat pool MY-POOL 203.0.113.10 203.0.113.20 prefix-length 24 R1(config)# ip access-list standard NAT-INSIDE R1(config-std-nacl)# permit 10.0.0.0 0.0.0.255 R1(config)# ip nat inside source list NAT-INSIDE pool MY-POOL ``` Each inside host gets one outside IP from the pool. Released when the host stops sending. Useful when you genuinely have many public IPs and want 1:1 mapping. Rare in 2026. ### Pattern 3: Static NAT (for an inside server) ``` ! Inside server 10.0.0.50 is reachable as 203.0.113.50 from the internet R1(config)# ip nat inside source static 10.0.0.50 203.0.113.50 ``` The 1:1 mapping is permanent — exists in the table even when no traffic flows. The outside IP must be routable to this router (you must own it, and the upstream must route it to you). ### Pattern 4: Port forwarding (static NAT for specific ports only) ``` ! Inside server 10.0.0.50:80 is reachable on the router's public IP at port 8080 R1(config)# ip nat inside source static tcp 10.0.0.50 80 interface Gi0/1 8080 ``` Useful when you only have one public IP but want to expose multiple inside servers on different ports. ### Pattern 5: Twice-NAT (translating both source AND destination) Rare, complex. Used when two networks have overlapping private IPs and need to talk. The router rewrites both source and destination on each packet. Out of CCNA scope — recognize the term. ## Hairpin NAT — the inside-loop case A common gotcha. Inside host `10.0.0.6` wants to reach inside server `10.0.0.50` using its **public** address `203.0.113.50` (because DNS returned the public IP). Without hairpin NAT, the packet leaves the router, hits the WAN side, gets discarded because there's no return route. **Hairpin NAT** (a.k.a. NAT reflection) makes the router rewrite the destination back to the inside IP and forward locally, without leaving the WAN interface. A word of caution: on classic Cisco IOS NAT this is genuinely fiddly. The `extendable` keyword you'll see in examples is really for *multiple/overlapping static mappings* (e.g. multi-ISP) — it is **not**, by itself, the hairpin enabler. True reflection on IOS typically needs the NAT Virtual Interface (`ip nat enable`) or a carefully designed inside/outside topology. It's out of CCNA scope to configure. **The exam-safe (and real-world cleanest) fix is split DNS:** internal clients resolve the server to its internal IP, external clients to the public IP. Then a packet from `10.0.0.6` goes straight to `10.0.0.50` and hairpin NAT is never needed at all. ## CGNAT — why your home IPv4 is in `100.64.x.x` Many ISPs ran out of public IPv4 addresses. Their solution: **Carrier-Grade NAT** (CGNAT). Your home router gets a `100.64.x.x` address from the ISP (CGNAT private range from RFC 6598), and the ISP's edge router does *another* layer of NAT to translate that to a real public IP shared with many customers. Result: you're behind **two layers of NAT**. Direct inbound connections to your home network are impossible without ISP cooperation. Real symptoms: - Online gaming with strict NAT type - Self-hosted services unreachable from outside without a tunnel (Cloudflare Tunnel, Tailscale, etc.) - Some peer-to-peer apps can't form connections CGNAT is increasingly common in the US (T-Mobile home internet, some Comcast deployments, all 4G/5G mobile). IPv6 is the long-term fix — most CGNAT'd networks also offer native IPv6, which bypasses the double-NAT entirely. ## NAT and IPsec — the famous gotcha IPsec ESP doesn't have port numbers — it identifies tunnels by SPI (Security Parameter Index). PAT can't rewrite SPIs the way it rewrites ports. Result: IPsec tunnels break when they cross a PAT device. **NAT-T (NAT Traversal)** solves this: IPsec encapsulates ESP inside UDP port 4500, so PAT can translate the UDP port like any normal packet. Both endpoints must support NAT-T. Modern IPsec implementations enable it by default. For CCNA: recognize that NAT-T exists and uses UDP 4500. ## NAT64 — bridging IPv6-only clients to IPv4-only services When you have IPv6-only clients (e.g., a modern mobile carrier's network) that need to reach IPv4-only servers (most of the public internet still), you need **NAT64**. A NAT64 gateway translates IPv6 packets to IPv4 statefully: ``` IPv6 client (2001:db8::5) ↔ NAT64 gw ↔ IPv4 server (8.8.8.8) ↓ The IPv4 server is presented to the client as 64:ff9b::8.8.8.8 (IPv6 representation of 8.8.8.8 under the NAT64 prefix) ``` Pairs with **DNS64** which synthesizes IPv6 AAAA records for IPv4-only hostnames. See [IPv6 Transition Mechanisms](/topics/ipv6-transition/) for the full story. ## Translation table — the heart of NAT The NAT translation table is the stateful element that makes everything work. Each entry contains: - Inside Local + Inside Global + Outside Global + protocol + ports + timeouts. ``` R1# show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 203.0.113.7:50001 10.0.0.5:50001 8.8.8.8:443 8.8.8.8:443 tcp 203.0.113.7:50002 10.0.0.6:50002 52.95.110.20:443 52.95.110.20:443 udp 203.0.113.7:53 10.0.0.7:53 1.1.1.1:53 1.1.1.1:53 --- 203.0.113.50 10.0.0.50 --- --- ``` Each row is one active translation. The first three are PAT entries (note the protocol + ports). The last row — protocol `---`, no ports — is a **static NAT** mapping: it's permanent and sits in the table even with no traffic. The PAT rows time out and disappear; the static one never does. ### Default timeouts (worth knowing) | Protocol | Default timeout | |---|---| | TCP | 24 hours (or until FIN/RST) | | UDP | 5 minutes | | ICMP | 60 seconds | | DNS | 60 seconds | | HTTP/finrst | 1 minute after teardown | You can tune them: ``` R1(config)# ip nat translation tcp-timeout 3600 ! 1 hour instead of 24 R1(config)# ip nat translation udp-timeout 60 ! 1 minute instead of 5 ``` Lower timeouts free table space faster but break apps that have idle connections. ### Translation table overflow Each translation eats memory. Aggressive scanning, DDoS, or compromised hosts can blow up the table: ``` R1# show ip nat statistics Total active translations: 12,847 (3 static, 12,844 dynamic; 12,801 extended) Outside interfaces: GigabitEthernet0/1 Inside interfaces: GigabitEthernet0/0 Hits: 28,394,213 Misses: 142 CEF Translated packets: 28,394,213, CEF Punted packets: 142 Expired translations: 8,234,562 Dynamic mappings: -- Inside Source [Id: 1] access-list NAT-INSIDE interface GigabitEthernet0/1 refCount 12844 ``` If `Total active translations` is climbing toward the platform's NAT limit, you're heading for an outage. Cap with: ``` R1(config)# ip nat translation max-entries all-host 100 ! per inside host R1(config)# ip nat translation max-entries 10000 ! global cap ``` ## Verification — the four commands ``` R1# show ip nat translations R1# show ip nat statistics R1# show ip nat translations verbose R1# clear ip nat translation * ! flush table — disruptive ``` For live diagnosis: ``` R1# debug ip nat detailed R1# debug ip nat translations ``` Debug is high-volume. Use with a tight ACL filter or never in production. Match-specific: ``` R1# debug ip nat detailed list NAT-DEBUG R1(config)# ip access-list standard NAT-DEBUG R1(config-std-nacl)# permit host 10.0.0.5 ``` Now only debug output for translations involving `10.0.0.5`. ## The 6-step NAT debug When NAT "isn't working": 1. **Are inside/outside interfaces tagged?** `show ip nat statistics` — does it list the correct inside + outside interfaces? 2. **Does traffic match the ACL?** `show access-list NAT-INSIDE | include match`. Hit count rising? If zero, the ACL is wrong (source IPs don't match) or the traffic isn't transiting the router. 3. **Are translations appearing in the table?** `show ip nat translations`. If empty, the ACL doesn't match OR the inside interface isn't tagged. 4. **Is the public IP routable back?** If you're using a static NAT to `203.0.113.50` but the upstream doesn't route that IP to you, replies vanish. Check with the ISP / upstream. 5. **Did the `overload` keyword get included?** Without it, dynamic NAT exhausts your pool fast. 6. **Are timeouts too short?** TCP working but UDP DNS fails intermittently? Default UDP 5min may be eating short-lived translations under load. Tune. ## Worked scenarios --- **Scenario 1.** A home user has 4 devices on `192.168.1.0/24` and one cable-modem-provided public IP. What NAT type? **Answer:** PAT (NAT Overload). Many private hosts share one public IP, distinguished by source port. This is the default mode on every consumer router. --- **Scenario 2.** An enterprise has a /28 of public IPs (16 addresses) and ~12 internal servers that need to be reachable from outside. What's the right NAT pattern? **Answer:** **Static NAT** — one inside IP per public IP. 12 static NAT entries map each server. Inside hosts (clients) can still use PAT against a separate IP if needed. --- **Scenario 3.** You've configured PAT but inside hosts can't reach the internet. `show ip nat translations` shows nothing. What do you check first? **Answer:** 1. `ip nat inside` on the LAN interface and `ip nat outside` on the WAN interface? Both required. 2. Does the ACL match the inside source range? `show access-list NAT-INSIDE`. 3. Is `overload` in the command? Without it, the pool exhausts. --- **Scenario 4.** A user behind PAT can't establish an IPsec VPN to a corporate gateway. The IPsec tunnel completes phase 1 but fails phase 2. **Answer:** NAT-T (NAT Traversal) isn't enabled — IPsec ESP can't be PAT'd directly. Enable NAT-T on both endpoints (Cisco: enabled by default in modern IOS via UDP 4500). Ensure UDP 4500 isn't blocked anywhere on the path. --- **Scenario 5.** You configure `ip nat inside source static 10.0.0.50 203.0.113.50`. Hosts on the outside can reach `203.0.113.50` fine. But inside hosts that try to reach `203.0.113.50` (the public IP of an inside server) fail. **Answer:** Classic hairpin NAT problem. When an inside host targets the public IP, the packet leaves on the inside interface, hits the NAT process, but the source IP is also inside-local — no path back. Fix: **split DNS** so internal clients resolve the server to its internal IP (the clean, exam-safe answer), or, if you truly need reflection, hairpin NAT via the NAT Virtual Interface — finicky on IOS and out of CCNA scope. --- **Scenario 6.** PAT is configured. `show ip nat translations` shows 50,000 entries. The router CPU is at 90%. What's happening? **Answer:** Either: - Translation table is close to the platform's limit and the router is spending CPU on table operations. - A compromised inside host is scanning (huge number of short-lived translations being created/expired). Investigate: `show ip nat statistics | include misses` — high misses = a lot of failed creates. Look at top talkers via `show ip nat translations | include 10.0.0` and identify which inside IP is responsible. --- **Scenario 7.** Inside Local `10.0.0.5`, Inside Global `203.0.113.7`, Outside Global `52.10.20.30`. What does Outside Local typically equal in this scenario? **Answer:** Outside Local = Outside Global = `52.10.20.30`. They differ only in unusual scenarios (NAT64, twice-NAT, where the outside host is presented to inside clients under a different IP). --- **Scenario 8.** You want to expose your inside web server `10.0.0.80:80` to the internet, but you only have one public IP. The router's WAN interface IP is `203.0.113.7`. How? **Answer:** Port forwarding: ``` R1(config)# ip nat inside source static tcp 10.0.0.80 80 interface Gi0/1 80 ``` External users hit `203.0.113.7:80`; the router rewrites destination to `10.0.0.80:80` and forwards. If your inside server's port differs from the public-facing port, swap the numbers: ``` R1(config)# ip nat inside source static tcp 10.0.0.80 8080 interface Gi0/1 80 ``` ## Common mistakes 1. **Forgetting interface tags.** No `ip nat inside` / `ip nat outside` → ACL matches but nothing translates. Both must be set. 2. **Wrong direction on the ACL.** The ACL identifies **inside-local sources** — the private IPs you want translated. If you put outside-public IPs in the ACL, nothing matches. 3. **Forgetting `overload`.** Without it, dynamic NAT runs out after the pool size. Always `overload` for typical home/SMB. 4. **Static NAT to an IP the router doesn't own.** No traffic ever arrives because the upstream doesn't route it. Usually use the router's own outside-interface IP. 5. **Inside Local vs Inside Global mix-up.** Mnemonic: **inside = our hosts**, **local = before translation, global = after**. Draw it out. 6. **Translation table fills up.** Each port from each source = an entry. DDoS or scanner traffic can blow it up. Limit with `max-entries`. 7. **Default UDP timeout too short.** 5 minutes is too short for some apps (gaming, VoIP signaling). Symptom: connection works briefly then drops. 8. **Skipping NAT-T for IPsec through PAT.** IPsec ESP can't be PAT'd directly; needs UDP 4500 encapsulation. 9. **Hairpin issues with public-IP-from-inside.** Symptom: outside works fine but `10.0.0.X` can't reach the public IP of inside servers. Fix with split DNS or hairpin config. 10. **Assuming NAT is security.** NAT is address translation, not access control. A motivated attacker can still reach inside hosts via vulnerabilities or forwarded ports. Always pair with a real firewall. ## Lab to try tonight 1. **Topology** — Two networks. Inside: `10.0.0.0/24`. Outside: `198.51.100.0/24` (the "internet"). A router between them with one public IP, `198.51.100.1`. 2. **Two inside PCs** — `10.0.0.10` and `10.0.0.11` (set statically, or hand them out with [DHCP](/topics/dhcp/)). One outside server at `198.51.100.50`. 3. **PAT** — configure overload so both inside PCs can reach the outside server. Verify with `show ip nat translations` — two entries, same Inside Global, different source ports. 4. **Test simultaneous connections** — both PCs simultaneously HTTP to the outside server. Confirm the table has both translations and a packet capture on the outside link shows different source ports for the two flows. 5. **Static NAT** — add a static NAT so inside server `10.0.0.50` is reachable as `198.51.100.2` from outside. Test inbound reachability. 6. **Port forwarding** — expose `10.0.0.80:80` as `198.51.100.1:8080`. Verify external requests to port 8080 reach the inside server. 7. **Translation timeout drill** — set UDP timeout to 30 seconds. Send a UDP packet. Watch `show ip nat translations` to confirm the entry vanishes after the timeout. 8. **NAT debug with ACL filter** — `ip access-list standard NAT-DEBUG` + `permit host 10.0.0.10`. Then `debug ip nat detailed list NAT-DEBUG`. Send traffic from `10.0.0.10`. See per-packet translation events without flooding with other hosts' traffic. 9. **Outside capture** — packet-capture on the outside interface. Confirm packets really do show the public IP as source, not the private one. Capture inside; confirm reverse. 10. **Bonus: hairpin scenario** — try having an inside host reach the public-static-NAT'd IP of another inside server. Observe failure without hairpin. Add `extendable` keyword and verify. ## Cheat strip | Concept | Plain English | |---|---| | **NAT** | Rewrite IP addresses at a router. Inside (private) ↔ outside (public). | | **RFC 1918** | `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` — private ranges | | **CGNAT (RFC 6598)** | `100.64.0.0/10` — ISP-side carrier-grade NAT space | | **PAT / overload** | Many private hosts share one public IP, distinguished by source port | | **ICMP & PAT** | ICMP has no ports — PAT rewrites the ICMP Query ID instead | | **Static NAT** | Fixed 1:1 mapping. Used for inside servers reachable from outside | | **Dynamic NAT** | Pool-based 1:1 — rare in 2026 | | **Port forwarding** | Static NAT for a specific port only | | **Inside Local** | Our host's private IP, pre-translation | | **Inside Global** | Our host's public IP, post-translation | | **Outside Global** | Remote host's real IP | | **Outside Local** | Remote host's IP as we see it (usually = Outside Global) | | **`ip nat inside` / `ip nat outside`** | Interface tags — required for NAT to engage | | **`overload`** | Makes it PAT instead of 1:1 NAT | | **Translation table** | Stateful per-conversation. Times out per protocol. | | **NAT-T** | NAT Traversal — UDP 4500 encapsulation for IPsec to survive PAT | | **Hairpin NAT** | Lets inside hosts reach public IPs of other inside hosts | | **NAT64** | IPv6 ↔ IPv4 translation — pairs with DNS64 | | **NAT isn't security** | It's address translation. Always pair with a real firewall | | **`show ip nat translations`** | Daily-driver debug command | | **Default timeouts** | TCP 24h · UDP 5min · ICMP 60s | | **Why it exists** | IPv4 exhaustion. IPv6 makes NAT unnecessary at the end-to-end level | ## Frequently asked questions **Q: What's the difference between NAT and PAT?** A: NAT (Network Address Translation) maps one private IP to one public IP — you need one public IP per active internal host. PAT (Port Address Translation, also called NAT overload) maps *many* private IPs to *one* public IP by using unique source ports to distinguish sessions. Every home internet router does PAT. In Cisco config, `ip nat inside source list 1 interface Gi0/0 overload` — the `overload` keyword turns NAT into PAT. **Q: Can I do NAT on a Layer 3 switch?** A: On most Catalyst switches, no — NAT requires the router / ASA / firewall data path. A few high-end switches (Cat9600 with specific licenses) can, but it's not a normal design. In a typical enterprise, put NAT at the edge router or firewall where north-south traffic converges. East-west (VLAN-to-VLAN) traffic on a Layer 3 switch stays internal and doesn't need NAT. **Q: What's the difference between inside and outside NAT?** A: Cisco NAT uses two orthogonal axes: *inside vs outside* (which side of the NAT boundary the address belongs to) and *local vs global* (whether the address is what the local network sees or what the outside internet sees). Inside local = client's private IP as the client sees it. Inside global = client's translated public IP as the internet sees it. Getting this vocabulary right unlocks `show ip nat translations` output — otherwise it looks like gibberish. **Q: Does IPv6 need NAT?** A: No — IPv6 was designed with enough address space (2^128) that every device can have a globally unique routable address. NAT66 exists but is discouraged. What IPv6 does need is stateful firewalling (which NAT accidentally provided in IPv4 by breaking unsolicited inbound), so most IPv6 designs put a stateful firewall at the edge that blocks unsolicited inbound flows by default. Same security outcome, without the NAT hairball. **Q: Why do I sometimes see the same public IP from multiple internal users?** A: PAT. The NAT router shares one public IP across all internal users by rewriting source ports. External services see all your users as `203.0.113.5:port` with a different port per session. This is why some web apps that IP-rate-limit end up blocking whole offices — from the outside, everyone looks like the same "user". --- ## DNS — Domain Name System — https://packetmentor.com/topics/dns/ > How www.example.com becomes an IP address. Covers the recursive query path (root → TLD → authoritative), record types (A, AAAA, CNAME, MX, PTR), TTL caching, and the most common DNS failure modes. ## Mental model Your laptop wants to load `www.packetmentor.com`. The browser has no idea what IP that is. So it asks a **resolver** (usually your ISP's, or 8.8.8.8, or 1.1.1.1) to find out. The resolver doesn't know either — but it knows where to start asking. It walks a chain: 1. *"Hello root, who runs .com?"* Root answers: *"Ask the .com TLD servers."* 2. *"Hello .com, who runs packetmentor.com?"* TLD answers: *"Ask packetmentor.com's authoritative server."* 3. *"Hello packetmentor.com auth, what's the IP of www?"* Auth answers: *"203.0.113.42."* The resolver returns just the final answer to your laptop. It also caches the answer for the duration specified by the record's TTL (Time To Live) — so the next person asking gets the answer instantly without walking the chain again. ## Record types you need to know | Type | Purpose | Example | |---|---|---| | **A** | Name → IPv4 address | `www.example.com → 203.0.113.42` | | **AAAA** | Name → IPv6 address | `www.example.com → 2001:db8::1` | | **CNAME** | Alias to another name | `www → example.com.` | | **MX** | Mail server for the domain | `example.com → mail.example.com (priority 10)` | | **NS** | Authoritative nameserver for the zone | `example.com → ns1.example.com` | | **PTR** | IP → name (reverse DNS) | `42.113.0.203.in-addr.arpa → www.example.com` | | **TXT** | Anything text (SPF, DKIM, domain verification) | `v=spf1 ...` | | **SOA** | Start of Authority — zone metadata | refresh, retry, expire, TTL | For CCNA: A and AAAA are by far the most asked. Understand CNAME (it's a pointer, not a copy) and MX (it's what mail servers query to deliver email). ## TTL — the caching contract Every DNS record has a TTL (in seconds). When a resolver caches an answer, it holds it for that long before re-asking. | TTL | When to use | |---|---| | 300 (5 min) | Aggressive — for records you might change soon | | 3600 (1 hr) | Normal default | | 86400 (24 hr) | Stable records that rarely change | **Migration tip:** before changing an A record's IP, lower the TTL to 300 a day in advance. Wait for the old TTL to expire everywhere. Then change. New IP propagates in 5 min instead of a day. ## Commands ### Query DNS from a Cisco router ``` R1# nslookup www.packetmentor.com R1# show host ``` ### Configure DNS resolver settings ``` R1(config)# ip name-server 8.8.8.8 1.1.1.1 R1(config)# ip domain-lookup R1(config)# ip domain-name corp.local ``` `ip domain-lookup` is on by default. The annoying side-effect: if you mistype a command, the router tries to DNS-resolve it as a hostname, which times out for ~30 seconds before giving you the prompt back. Most engineers disable it: ``` R1(config)# no ip domain-lookup ``` ### Configure a Cisco IOS DNS server (rare in production, but exam-relevant) ``` R1(config)# ip dns server R1(config)# ip host www.corp.local 10.0.0.50 ``` ## DNS as a troubleshooting layer When users say *"the internet is down"*, the issue is often DNS — not the network. Ping fails by hostname but succeeds by IP? DNS problem. The classic flow: ``` $ ping www.example.com ← fails with "unknown host" $ ping 203.0.113.42 ← works ``` That's a DNS failure, not a network failure. Common culprits: ISP DNS server down, local cache poisoning, misconfigured resolver, network adapter has no DNS server assigned. ## Common mistakes 1. **No reverse DNS for an outbound mail server.** Many mail receivers reject mail from IPs without a matching PTR record. If you run a mail server, set up the PTR record at your ISP for that IP. 2. **TTL too long during migration.** A 7-day TTL means a week of half the internet seeing your old IP after a change. Lower TTLs *before* migration, not after. 3. **CNAME at the apex.** RFC says you can't have a CNAME on the apex (root domain) — only on subdomains. Most modern DNS providers offer "ALIAS" or "ANAME" pseudo-records to work around this. 4. **Forgetting `ip domain-lookup` is on by default.** Mistype a command, wait 30 seconds, curse the router. Always disable on lab/admin routers. 5. **Putting unauthorized DNS servers in your name-server list.** A typo'd IP could send queries to a malicious server logging everything you look up. Stick to well-known public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) or your own internal one. 6. **Confusing recursive and authoritative.** Recursive resolvers do the legwork. Authoritative servers answer for the zones they own. Most public servers do both, but they're conceptually distinct. ## Lab to try tonight 1. From your laptop, run `dig www.cisco.com` (or `nslookup` on Windows). Note the answer + TTL. 2. Run it again immediately — the second response is from cache, should be much faster. 3. Run `dig +trace www.cisco.com` — watch the recursive walk happen step-by-step from root to TLD to authoritative. 4. On a Cisco router, configure `ip name-server 1.1.1.1`. Then run `ping www.cisco.com` and verify DNS resolution works. 5. Disable `ip domain-lookup`. Mistype a command. Confirm you no longer wait 30s for the prompt. 6. Bonus: change the TTL on a test domain you control. Watch propagation time difference. ## Cheat strip | Concept | Plain English | |---|---| | **Resolver** | The server that walks the query chain on the client's behalf | | **Authoritative server** | The server that owns the record (the "source of truth") | | **Root → TLD → Auth** | The three steps of a recursive lookup | | **TTL** | How long answers stay cached. Lower = faster propagation, more lookups. | | **A / AAAA** | IPv4 / IPv6 address records | | **CNAME** | Alias (pointer) to another name | | **MX** | Mail server for the domain | | **PTR** | Reverse lookup — IP to name | | **`no ip domain-lookup`** | Disables DNS on the router CLI to avoid mistype delays | ## Frequently asked questions **Q: What's the difference between recursive and iterative DNS?** A: A recursive resolver does the whole lookup on the client's behalf — asking the root, then TLD, then authoritative servers until it gets an answer. An iterative resolver only tells you where to look next (e.g., "ask the .com TLD server"). Client stubs always talk to recursive resolvers (8.8.8.8, 1.1.1.1, your ISP's) — the recursive resolver does the iterative walk. **Q: What's a CNAME vs an A record?** A: An A record maps a hostname directly to an IPv4 address (`www.example.com → 93.184.216.34`). A CNAME is an alias pointing at another hostname (`www.example.com → example.com`). CNAMEs let you point multiple hostnames at a single canonical record; changing the canonical A record updates every CNAME automatically. Common gotcha: you can't CNAME the apex (`example.com` itself) — use an ALIAS or ANAME record if your DNS provider supports it. **Q: Why do I sometimes see stale DNS results?** A: Caching — every DNS record has a TTL (time-to-live). Once a resolver caches a response, it keeps returning that answer until the TTL expires. Common TTLs: 300s (5 min) for fast-changing records, 86400s (24 hr) for stable ones. When you plan a DNS migration, lower TTLs a day ahead so the switchover propagates quickly. Client OSes also cache — Windows `ipconfig /flushdns`, macOS `sudo dscacheutil -flushcache`. **Q: What is DNS over HTTPS (DoH)?** A: DNS queries wrapped in HTTPS instead of clear-text UDP 53. Prevents ISPs and network operators from seeing what domains a user visits (or from tampering with responses). Firefox, Chrome, and iOS/macOS all support it. Enterprise networks often try to block DoH because it bypasses DNS-based content filters — expect a policy debate on whether to enable it in your org. **Q: What port does DNS use?** A: UDP 53 for normal queries. TCP 53 for responses > 512 bytes and for zone transfers between authoritative servers. DoH uses TCP 443 (piggybacking on HTTPS). DoT (DNS over TLS) uses TCP 853. When you write a firewall rule allowing DNS, allow both UDP and TCP 53 — otherwise DNSSEC and large TXT records fail. --- ## NTP — Network Time Protocol — https://packetmentor.com/topics/ntp/ > How every device on the network ends up with the same clock. Covers stratum hierarchy, client and server config, authentication, and why broken NTP makes log correlation a nightmare. ## Mental model When you're investigating an incident at 3 AM, you need to correlate logs across a firewall, a switch, a server, and a load balancer. If those devices' clocks are off by even 30 seconds, you can't tell which event caused which. Worse, certificate expiry checks fail, scheduled jobs misfire, and Kerberos refuses to authenticate (it requires ≤5 minute clock skew). NTP solves this by giving every device on the network the same time, accurate to milliseconds. Set it up once, forget about it for years — until something breaks because someone disabled it. ## The stratum hierarchy NTP organizes time sources in a tree. Each level is called a **stratum**: | Stratum | What's there | Examples | |---|---|---| | **0** | Reference clock | Atomic clock, GPS receiver | | **1** | Server directly synced to stratum 0 | `time.nist.gov`, `pool.ntp.org` mirrors | | **2** | Server synced to a stratum 1 server | Your enterprise NTP server, ISP's NTP | | **3** | Synced to a stratum 2 | Your branch router | | ... | each step adds one | | | **16** | Unsynchronized | Default state until first sync | The lower the number, the closer to the reference clock and the more authoritative. Network gear typically ends up at stratum 3 or 4. ## Commands ### Configure a Cisco router as NTP client ``` R1(config)# ntp server pool.ntp.org ! use public pool R1(config)# ntp server 10.0.99.1 ! or an internal NTP server R1(config)# ntp server 10.0.99.2 prefer ! mark one as preferred ! Specify which interface NTP source IP should use R1(config)# ntp source GigabitEthernet0/0 ! Set timezone (optional, but recommended for human-readable logs) R1(config)# clock timezone EST -5 R1(config)# clock summer-time EDT recurring ``` ### Configure a router as an NTP server for downstream devices ``` R1(config)# ntp master 3 ! announce ourselves as stratum 3 ``` Use this on a central / core router that syncs externally and serves time to internal devices. Don't run `ntp master` on every router — pick a few centralized ones. ### Verify ``` R1# show ntp status R1# show ntp associations R1# show clock R1# show clock detail ``` `show ntp associations` shows every NTP server you're peering with, which one is selected, and the current stratum / offset / delay. The little asterisk in the output matters: ``` R1# show ntp associations address ref clock st when poll reach delay offset disp *~10.0.99.1 .GPS. 1 27 64 377 1.2 -0.05 0.9 ~10.0.99.2 10.0.99.1 2 35 128 377 1.4 0.12 1.1 ``` - `*` = selected (this is the one we're using right now) - `+` = candidate (eligible but not selected) - `~` = static configuration (you configured it manually) - `#` = symmetric peer ## Authentication (mostly for sensitive networks) NTP traffic isn't authenticated by default — an attacker on the path could feed you bad time. For sensitive deployments: ``` R1(config)# ntp authenticate R1(config)# ntp authentication-key 1 md5 supersecret R1(config)# ntp trusted-key 1 R1(config)# ntp server 10.0.99.1 key 1 ``` The server side needs the matching key. Use NTP authentication on internet-facing routers and security-critical servers. ## Common mistakes 1. **No NTP at all.** Devices boot to 1993 (or whatever their default is). Logs are useless. Certificates fail. This still happens in 2026 — check `show clock` on every device after setup. 2. **One NTP server only.** If it's unreachable, your clocks slowly drift. Always configure 2-3 servers. 3. **NTP source-IP doesn't match access lists.** You configure `ntp server 10.0.99.1`, but the router's outgoing IP for NTP traffic is on a different interface and gets filtered by an ACL. Set `ntp source ` explicitly. 4. **Running `ntp master` on every router.** Now every router claims to be a time source. They peer with each other. Stratum levels oscillate. Pick 2 central NTP servers, point everyone else at those. 5. **Forgetting timezone.** Router shows time in UTC by default. Operators see UTC in logs and miscorrelate with their local-time wall clock. Set `clock timezone` for sanity. 6. **Daylight saving without `clock summer-time`.** Logs jump an hour twice a year. Configure summer-time once and the router handles DST automatically. 7. **Trusting the local clock when NTP fails.** After a long power outage, a router's local clock can be wildly off. Don't trust `show clock` until `show ntp status` confirms synchronization. ## Lab to try tonight 1. On a Cisco router with internet access, run `show clock`. Note how wrong it is. 2. Configure `ntp server pool.ntp.org`. Wait 2-5 minutes. 3. Run `show ntp status` and `show ntp associations`. Look for `Clock is synchronized` and an `*` next to your server. 4. Run `show clock` again. Time should now be correct (to UTC by default). 5. Set timezone: `clock timezone EST -5` (or your zone). Verify `show clock` updates. 6. Configure a second router with `ntp server `. Confirm it picks up time from your first router (stratum +1). 7. Bonus: enable NTP authentication between the two routers and verify it still works. ## Cheat strip | Concept | Plain English | |---|---| | **NTP** | Synchronizes clocks across devices | | **Stratum** | Distance from reference clock. 0 = atomic. 16 = unsynced. | | **`ntp server X`** | Tell me to use X as a time source | | **`ntp master N`** | Announce myself as a stratum-N server | | **`*`** in associations | Currently selected upstream server | | **`clock timezone`** | Display time in local zone (sanity) | | **`clock summer-time`** | Handle DST automatically | | **Authentication** | NTP can use MD5/HMAC keys for sensitive environments | | **Port** | UDP/123 | --- ## Syslog — https://packetmentor.com/topics/syslog/ > Send every device's log messages to a central server. Covers severity levels (0-7), facilities, message format, where to send logs (local buffer / console / monitor / server), and the eternal question of how much logging is too much. ## Mental model Every switch, router, firewall, and server produces log messages — events, warnings, errors. Without centralization, those logs live on each device's tiny local buffer and disappear when the buffer wraps. When something breaks at 3 AM, you're SSHing into 12 devices reading scrollback. **Syslog** is the standard fix: every device ships its logs to a central server, where they're stored, indexed, and searched. Combined with synced clocks via [NTP](/topics/ntp/), this turns scattered log files into a single timeline you can correlate. The format is dirt-simple — a line of text per message, prefixed with severity, facility, timestamp, and host. Modern syslog servers (Splunk, ELK, Graylog, Loki, Datadog) parse and index millions of these per second. ## The 8 severity levels | Level | Name | When to use | |---|---|---| | **0** | Emergency | System unusable — usually a kernel-level panic | | **1** | Alert | Action must be taken immediately | | **2** | Critical | Critical condition — major service failure | | **3** | Error | Error condition — something didn't work | | **4** | Warning | Warning — could become a problem | | **5** | Notice | Normal but significant condition | | **6** | Informational | Routine info — link up/down, login events | | **7** | Debug | Debug-level — high volume, only on demand | **Memory aid:** "Every Awesome Cisco Engineer Will Need Ice-cream Daily" (Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug). Production rule of thumb: log level **6 (informational)** to the syslog server. Reserve **7 (debug)** for active troubleshooting only — debug-level traffic floods the syslog server and saturates the management link. ## Where Cisco devices can log A Cisco device has multiple log "destinations," each independently configurable: | Destination | Where it goes | Default level | |---|---|---| | **Console** | Anyone connected to the console port | level 6 (informational) | | **Monitor / VTY** | Anyone connected over SSH/Telnet (if `terminal monitor` enabled) | level 6 | | **Buffer** | Local RAM, viewable with `show logging` | level 6 (~ 4 KB by default) | | **Syslog server** | Remote server via UDP/514 | level 6 | | **SNMP / email** | Less common in 2026 | — | You typically log: - Console: warnings and above (level 4) — don't spam the console - Buffer: level 6 — keep recent local history - Syslog server: level 6 — the real long-term record ## Commands ### Basic syslog server config ``` R1(config)# logging host 10.0.99.5 R1(config)# logging trap informational ! level 6 and above to syslog server R1(config)# logging source-interface Loopback0 ! consistent source IP for the server ``` ### Local buffer ``` R1(config)# logging buffered 16384 ! 16 KB buffer (default is small) R1(config)# logging buffered informational ! level 6 and above R1# show logging ! view it R1# clear logging ! wipe it ``` ### Console + terminal ``` R1(config)# logging console warnings ! only level 4 and above to console R1(config)# logging monitor informational ! level 6 to vty R1# terminal monitor ! turn on log forwarding to your SSH session R1# terminal no monitor ! turn it off when you're done ``` ### Timestamps (make every log entry useful) ``` R1(config)# service timestamps log datetime msec localtime show-timezone ``` This makes every log line look like: ``` *Aug 15 14:23:01.234 PDT: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up ``` The components: timestamp · facility (LINK) · severity (3) · mnemonic (UPDOWN) · message text. ## Reading a Cisco log message ``` *Aug 15 14:23:01.234 PDT: %SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.0.0.5) ``` Breakdown: - `*Aug 15 14:23:01.234 PDT` — when (NTP-synced if you set up NTP) - `%SYS-5-CONFIG_I` — **facility-severity-mnemonic** — SYS=facility, 5=severity (Notice), CONFIG_I=specific event - The rest — human-readable description The `%FACILITY-N-MNEMONIC` pattern is consistent across all Cisco IOS messages. Useful for filtering with `grep`. ## Common mistakes 1. **Sending debug-level (7) to the syslog server.** Floods the server, fills disk, masks real signals. Always set `logging trap informational` (6) for the remote server. 2. **No NTP.** Every device timestamps logs in its own clock, which drifts. Correlation across devices becomes impossible. **Always configure NTP before relying on syslog.** 3. **Forgetting `service timestamps log datetime`.** Default timestamps are uptime-based (`*00:01:23`) instead of wall-clock. Useless for forensic work. 4. **No `logging source-interface`.** Without this, the device sources syslog from whichever interface routes to the server — potentially different each time. The server sees the same device with different IPs. Pin it to a loopback or management interface. 5. **No buffer at all.** If the syslog server is unreachable (network outage during the outage, naturally), all log info is lost. Always configure a local buffer too. 6. **Logging passwords or secrets.** Some auth failure messages can include the attempted username/password. Sanitize before storage. Avoid logging at debug level on auth subsystems. 7. **Treating syslog like a database.** It's append-only text. For metric-style data (CPU %, interface counters), use SNMP/streaming telemetry, not syslog. ## Lab to try tonight 1. Set up any syslog server (free options: Kiwi Syslog, Splunk Free, rsyslog on Linux). 2. On a Cisco router, configure: ``` ntp server pool.ntp.org service timestamps log datetime msec localtime show-timezone logging buffered 16384 informational logging host logging trap informational logging source-interface Loopback0 ``` 3. Trigger some events: `shut`/`no shut` an interface. Make a config change. Login from SSH. 4. Watch entries appear on the syslog server in real time. 5. Try `terminal monitor` from an SSH session and trigger events — watch them appear in your terminal too. 6. Test the disconnect: turn off the syslog server, generate logs, turn server back on. Logs in the local buffer survived; the ones sent to the server during the outage didn't. 7. Bonus: pipe logs into Grafana Loki + Promtail. Query / chart events over time. ## Cheat strip | Concept | Plain English | |---|---| | **Severity 0–7** | Emergency to Debug. Lower = worse. | | **Production default** | Level 6 (informational) and above | | **Facility** | Component / subsystem the message came from | | **Mnemonic** | Specific event name (e.g. `UPDOWN`, `CONFIG_I`) | | **`logging trap N`** | Send level N and above to the syslog server | | **`logging buffered`** | Keep recent log lines in RAM | | **`terminal monitor`** | Stream logs to your SSH session | | **`service timestamps log datetime`** | Wall-clock timestamps. Essential. | | **Port** | UDP/514 (some use TCP/6514 for syslog-tls) | --- ## QoS Basics — https://packetmentor.com/topics/qos-basics/ > How routers and switches handle congestion — classifying packets, marking them with DSCP, queueing by priority, and shaping/policing traffic. Why VoIP and video deserve special treatment over file downloads. ## Mental model A network link has finite bandwidth. When more traffic wants to go through than fits, **somebody has to wait**. Without QoS, packets are processed first-in-first-out — your VoIP call gets stuck behind someone's 4K Netflix stream, the call degrades, the call gets dropped. **QoS gives the network rules for who waits and who goes first.** It's traffic management for the moment when the pipe is full. QoS doesn't create bandwidth. It manages it under congestion. When the link has plenty of headroom, QoS does nothing — all packets pass freely. ## The four-stage pipeline ``` [ packet arrives ] → CLASSIFY → MARK → QUEUE → SCHEDULE → [ out the wire ] ``` | Stage | What it does | |---|---| | **Classify** | Identify what kind of traffic this is. By port (TCP/5060=SIP), by ACL match, by source, by DPI. | | **Mark** | Stamp the packet with a priority value (DSCP for IP, CoS for Ethernet). | | **Queue** | Drop into the appropriate priority queue. High-priority queues drain first. | | **Schedule** | Decide which queue to service next when the wire has room. | **Critical principle: mark once, trust elsewhere.** Mark at the edge of your network (closest to the source). Internal routers and switches just read the existing marks and act on them. Re-classifying at every hop is expensive and error-prone. ## DSCP — the IP-layer marking DSCP (Differentiated Services Code Point) is 6 bits in the IP header — 64 possible values. Common ones: | DSCP | Decimal | Name | Used for | |---|---|---|---| | **EF** | 46 | Expedited Forwarding | VoIP (low latency, low jitter) | | **AF41** | 34 | Assured Forwarding 4-1 | Interactive video | | **AF31** | 26 | Assured Forwarding 3-1 | Streaming video | | **AF21** | 18 | Assured Forwarding 2-1 | Transactional / business apps | | **CS6** | 48 | Class Selector 6 | Routing protocols (OSPF Hellos, etc.) | | **BE** | 0 | Best Effort | Default — everything unmarked | For CCNA, focus on: - **EF (46)** — VoIP. Memorize this one. - **AF classes** — Assured Forwarding, 4 levels (1-4) with 3 drop-precedences each. - **CS6 (48)** — network control plane (don't drop these or routing breaks). - **BE (0)** — default. ## Queue scheduling — the actual prioritization Once packets are marked and dropped into priority queues, the scheduler decides which queue's packet goes out next. Common algorithms: - **Priority Queue (PQ / LLQ)** — high-priority queue is ALWAYS serviced first. If it has traffic, lower queues wait. Used for VoIP because even a tiny delay degrades calls. - **Weighted Fair Queueing (WFQ)** — divide bandwidth proportionally among queues based on weight. Fair, but no strict priority. - **CBWFQ** (Class-Based WFQ) — modern hybrid: explicit bandwidth guarantees per class. The standard production config: **LLQ for VoIP** (strict priority, with a policer to prevent starving everyone else) + **CBWFQ for everything else** (guaranteed minimums for each class). ## Shaping vs policing — two ways to limit traffic Both restrict throughput. The difference is what happens to the excess: | | Shaping | Policing | |---|---|---| | **Action on excess** | Queue (delay) | Drop or remark | | **TCP behavior** | Good — TCP slows down, no drops | Aggressive — TCP retransmits | | **Where used** | Customer edge (outgoing) | Provider edge (incoming) | | **Memory** | Needs a queue | Stateless | Rule of thumb: shape what you send (be a good citizen), police what you receive (protect your network). ## Commands — modular QoS (the modern way) Cisco's MQC (Modular QoS CLI) uses three steps: define the **class-map**, build the **policy-map**, attach with **service-policy**. ### Class-map: identify the traffic ``` R1(config)# class-map match-any VOIP R1(config-cmap)# match dscp ef ! already-marked VoIP R1(config-cmap)# match protocol rtp ! or by NBAR R1(config)# class-map match-all WEB R1(config-cmap)# match access-group name PERMIT-WEB ``` ### Policy-map: decide what to do ``` R1(config)# policy-map EDGE-OUT R1(config-pmap)# class VOIP R1(config-pmap-c)# priority percent 10 ! strict priority, 10% of bandwidth max R1(config-pmap)# class WEB R1(config-pmap-c)# bandwidth percent 30 ! guaranteed 30% R1(config-pmap)# class class-default R1(config-pmap-c)# bandwidth percent 60 ! everything else R1(config-pmap-c)# fair-queue ``` ### Service-policy: attach to an interface ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# service-policy output EDGE-OUT ``` ### Verify ``` R1# show policy-map interface GigabitEthernet0/0 ``` This shows real-time hit counters per class and any drops — the most useful single QoS troubleshooting command. ## Common mistakes 1. **Marking everywhere.** Marking at every hop is wasteful and error-prone. Mark once at the trusted edge, then trust DSCP values elsewhere. 2. **Trusting markings from untrusted devices.** A user PC can mark its own outgoing packets as EF. If you trust user-side markings, the user's BitTorrent becomes "priority" and starves your VoIP. Strip / remark at the access port. 3. **Forgetting that QoS only matters under congestion.** If your WAN is at 20% utilization, QoS does nothing. Test QoS by loading the link. 4. **No policer on the priority queue.** Strict priority means VoIP gets ALL the bandwidth if it has traffic. A misbehaving app marked as EF can starve everything. Always set `priority percent N` (which adds an implicit policer) instead of unbounded `priority`. 5. **Mis-applying input vs output policies.** Classification can happen on input. Shaping/queueing happens on output (where the bottleneck is). Apply policy-maps in the right direction. 6. **Treating CS6 as "even higher than EF."** CS6 is for routing protocol traffic — don't put user traffic in it. EF is the highest level for user traffic. ## Lab to try tonight 1. Two routers connected by a slow serial / dialer link (artificially limit bandwidth to 1 Mbps if needed). 2. Generate two flows simultaneously: a UDP-echo flow simulating VoIP, and a TCP file transfer. 3. Without QoS: observe the VoIP latency / jitter increase as the file transfer saturates the link. 4. Configure MQC: classify VoIP via DSCP EF, give it priority queue, give file transfer the rest. 5. Re-run the test. VoIP latency stays low even under saturation. 6. Verify with `show policy-map interface ...` — observe the queue hit counts. 7. Bonus: try `match protocol rtp` (NBAR) instead of DSCP, to classify VoIP without trusting the source's marking. ## Cheat strip | Concept | Plain English | |---|---| | **QoS** | Manage who waits when the link is full | | **Classify** | Identify traffic type | | **Mark** | Stamp with DSCP (IP) or CoS (Ethernet) | | **Queue** | Drop into a priority bucket | | **Schedule** | Decide which queue drains next | | **DSCP EF (46)** | VoIP — low latency, low jitter | | **DSCP AF classes** | Various — bandwidth-guaranteed, can-drop tiers | | **DSCP BE (0)** | Default — everything unmarked | | **LLQ** | Low Latency Queue — strict priority + policer | | **Shape** | Queue excess (good for outgoing) | | **Police** | Drop or remark excess (good for incoming) | | **MQC** | class-map → policy-map → service-policy | --- ## SNMP — Simple Network Management Protocol — https://packetmentor.com/topics/snmp/ > How monitoring systems pull metrics and receive alerts from network devices. Covers SNMPv1/v2c/v3, community strings, traps vs informs, MIB / OID navigation, and why SNMPv3 is the only one acceptable in 2026. ## Mental model You manage 50 switches. You want to know: is each one up? CPU load? Interface utilization? Memory? Bandwidth on Gi0/24 over the last hour? SNMP is the protocol that lets your monitoring system **pull this info from every device on a schedule**, and lets devices **push critical events** to your system in real time. Two flows: - **Polling (GET)** — manager asks agent: *"what's your CPU?"* every 5 minutes. - **Traps (asynchronous)** — agent pushes: *"my interface just went down."* Immediately. For 25 years, SNMP has been the dominant network monitoring protocol. It's being replaced by streaming telemetry (gRPC / NETCONF subscriptions, see [NETCONF & YANG](/topics/netconf-yang/)), but you'll meet SNMP on every device for a long time yet. ## Three versions — only v3 is OK for production | Version | Auth | Encryption | Use? | |---|---|---|---| | **v1** | Community string (plain text) | None | Never | | **v2c** | Community string (plain text) | None | Only on isolated mgmt VLANs | | **v3** | Username + password (hashed/encrypted) | Optional AES-256 encryption | Yes — production | **Community strings** in v1/v2c are essentially passwords sent in plain text. Anyone sniffing the management network can read them. Anyone reading them can poll your devices and read all configuration. **SNMPv3** uses real authentication (HMAC-SHA) and optional encryption (AES). It's not perfect (still UDP, replay protection is finicky) but it's the only acceptable choice for production. ## SNMP messages | Message | Direction | Purpose | |---|---|---| | **GET / GET-NEXT / GET-BULK** | Manager → Agent | Read one or many values | | **SET** | Manager → Agent | Write a value (rare in practice — usually monitoring is read-only) | | **RESPONSE** | Agent → Manager | Reply to GET / SET | | **TRAP** | Agent → Manager | Async alert. Fire-and-forget. | | **INFORM** | Agent → Manager | Acknowledged alert (more reliable than trap) | For CCNA: know GET, TRAP, INFORM. TRAP vs INFORM — the difference is whether the manager acknowledges receipt. INFORM is retried if the manager doesn't ACK. TRAP is sent once and forgotten. ## Ports - **UDP 161** — agent (polled by manager) - **UDP 162** — manager (receives traps from agents) Both UDP, so neither is guaranteed delivery. SNMP traps in particular can be lost. ## MIB and OID — the data model SNMP data lives in a **MIB** (Management Information Base) — a hierarchical tree of values. Every node in the tree has a unique **OID** (Object Identifier), like `1.3.6.1.2.1.2.2.1.10.1` (which means `interface Gi0/0 inbound octet count`). Real OIDs are unreadable. You'll work with named MIBs: ``` ifInOctets.1 ← human form 1.3.6.1.2.1.2.2.1.10.1 ← OID form ``` Common MIBs you'll touch: - **IF-MIB** — interface stats (counters, errors, status) - **HOST-RESOURCES-MIB** — CPU, memory, storage - **CISCO-PROCESS-MIB** — Cisco-specific CPU details - **CISCO-MEMORY-POOL-MIB** — Cisco memory details - **BGP4-MIB, OSPF-MIB** — routing protocol state Monitoring systems (PRTG, SolarWinds, LibreNMS, Zabbix) ship with pre-built MIBs and templates — you rarely need to look up OIDs by hand. ## Commands — SNMPv3 config (recommended) ``` ! Create a view limiting what can be read (good practice) SW1(config)# snmp-server view READ-VIEW iso included SW1(config)# snmp-server view READ-VIEW 1.3.6.1.6.3 excluded ! exclude SNMP config from view ! Create an SNMPv3 group SW1(config)# snmp-server group ADMINS v3 priv read READ-VIEW ! Create an SNMPv3 user (auth + privacy) SW1(config)# snmp-server user monitor ADMINS v3 auth sha auth-password priv aes 256 priv-password ! Where to send traps SW1(config)# snmp-server host 10.0.99.5 version 3 priv monitor ! Enable trap types SW1(config)# snmp-server enable traps SW1(config)# snmp-server enable traps snmp linkdown linkup coldstart warmstart SW1(config)# snmp-server enable traps config SW1(config)# snmp-server enable traps cpu threshold ``` ## Commands — SNMPv2c (only on isolated networks) ``` ! Read-only community SW1(config)# snmp-server community public RO ! Read-write — basically gives full control. Use sparingly. SW1(config)# snmp-server community secret RW ! ACL restricting which IPs can query SW1(config)# ip access-list standard SNMP-ALLOWED SW1(config-std-nacl)# permit host 10.0.99.5 SW1(config)# snmp-server community public RO SNMP-ALLOWED ! Trap host SW1(config)# snmp-server host 10.0.99.5 version 2c public ``` ## Verification ``` SW1# show snmp SW1# show snmp user SW1# show snmp host SW1# show snmp group SW1# show snmp view ``` From your laptop (Linux/macOS), test with `snmpwalk`: ``` $ snmpwalk -v3 -l authPriv -u monitor -a SHA -A auth-password \ -x AES -X priv-password 10.0.0.1 ifDescr ``` If you get back the list of interface descriptions, SNMPv3 is working. ## Common mistakes 1. **Using v2c with default communities (`public` / `private`).** Anyone on the management VLAN can poll your devices. Always set unique community strings — or better, use v3. 2. **Read-write community enabled with default password.** An attacker who guesses the community can reconfigure everything via SNMP SET. Use RO only unless you actively need writes; if you do, use long random community strings on v3. 3. **No ACL on SNMP.** Polling can come from anyone if no ACL is set. Always restrict by source IP. 4. **Traps over UDP, no fallback.** UDP traps can be lost. For critical alerts, use INFORM (acknowledged) instead. 5. **Polling too aggressively.** 1-second polls on 500 devices = constant CPU on devices. Match polling rate to monitoring need (1-5 min is typical). 6. **Confusing community string with username.** v2c uses a community string (one "password" shared by everyone). v3 uses per-user credentials. v3 is properly authenticated; v2c is not. 7. **Forgetting `snmp-server enable traps`.** Configured a trap host but no events arriving? Probably forgot to enable specific trap types globally. ## Lab to try tonight 1. Install LibreNMS, PRTG, or any SNMP monitoring tool (free tier available for most). 2. Configure SNMPv3 on a Cisco router using the commands above. Use strong passwords. 3. Add the device to your monitoring tool with SNMPv3 credentials. 4. Verify metrics appear (CPU, interface utilization, uptime). 5. `shutdown` an interface — verify a trap arrives in the monitoring tool. 6. From CLI: `snmpwalk -v3 ...` against the device. Match the values to what the GUI shows. 7. Bonus: install a v2c community and try `snmpwalk -v2c -c public ...`. Notice the plain-text community in `tcpdump` capture. ## Cheat strip | Concept | Plain English | |---|---| | **SNMPv1 / v2c** | Community-string auth, plain text. Don't use in 2026. | | **SNMPv3** | Per-user, hashed auth, optional AES encryption. Use this. | | **Manager** | The polling / receiving system | | **Agent** | The device being polled | | **GET** | Manager reads from agent | | **TRAP** | Agent pushes event to manager (UDP, no ACK) | | **INFORM** | Agent pushes event, waits for ACK (more reliable) | | **OID** | Object Identifier — tree path like `1.3.6.1.2.1.2.2.1.10.1` | | **MIB** | Module defining a chunk of OIDs (IF-MIB, etc.) | | **UDP 161** | Polling (agent listening) | | **UDP 162** | Traps (manager listening) | | **Read-only / read-write** | RO is safe; RW = remote config. Limit RW carefully. | --- ## TCP Connection States — https://packetmentor.com/topics/tcp-connection-states/ > What every TCP socket goes through from CLOSED to ESTABLISHED to TIME_WAIT. Covers each state, why TIME_WAIT exists (and frustrates web servers), and how netstat and ss show you what's really happening. ## Mental model A TCP connection isn't a binary "open or closed" thing — it's a state machine with 11 distinct states. The OS kernel tracks the current state of every socket and moves it through the lifecycle based on packets sent/received. You don't need to memorize all 11. Five matter day-to-day: | State | What's happening | |---|---| | **LISTEN** | Server is accepting connections on a port | | **SYN_SENT** | Client has sent SYN, waiting for SYN-ACK | | **SYN_RECEIVED** | Server got the SYN, sent SYN-ACK, waiting for client's ACK | | **ESTABLISHED** | Connection is open, data flowing | | **TIME_WAIT** | Connection closed; waiting before fully releasing the port | The full set (FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, LAST_ACK, CLOSING, CLOSED) handles the orderly teardown. Worth knowing they exist; not worth memorizing every transition for CCNA. ## The states, in order of a typical connection ``` Server: CLOSED → LISTEN (listens on port 443) Client: CLOSED → SYN_SENT (sends SYN) Server: LISTEN → SYN_RECEIVED (responds SYN-ACK) Client: SYN_SENT → ESTABLISHED (sends ACK, connection open) Server: SYN_RECEIVED → ESTABLISHED (gets ACK, connection open) ... data flows ... Client: ESTABLISHED → FIN_WAIT_1 (sends FIN) Server: ESTABLISHED → CLOSE_WAIT (gets FIN, sends ACK) Client: FIN_WAIT_1 → FIN_WAIT_2 (got server's ACK) Server: CLOSE_WAIT → LAST_ACK (app calls close, sends FIN) Client: FIN_WAIT_2 → TIME_WAIT (got server's FIN, sends ACK) Server: LAST_ACK → CLOSED (got client's ACK) Client: TIME_WAIT → CLOSED (after 2 × MSL timer expires) ``` ## TIME_WAIT — the one that confuses everyone After a graceful close, the side that sent the **first FIN** enters **TIME_WAIT** and stays there for **2 × MSL** (Maximum Segment Lifetime, typically 30-60 seconds on modern systems, so 60-120s total). Why? Two reasons: 1. **Catch stragglers.** If the final ACK is lost, the other side retransmits its FIN. The TIME_WAIT side responds with another ACK. Without TIME_WAIT, the second FIN reaches a "closed" socket and gets RST. 2. **Avoid stale connection confusion.** Old packets from this connection might still be in flight. TIME_WAIT ensures they're discarded before the same (src IP, src port, dst IP, dst port) 4-tuple can be reused for a new connection. The annoying side-effect: a busy web server making lots of outbound connections (e.g. to backend services) accumulates lots of TIME_WAIT sockets on the **source side**, eating ephemeral ports. ``` $ netstat -an | grep TIME_WAIT | wc -l 12384 ``` Mitigations: - **HTTP keep-alive / connection pooling** — reuse connections instead of opening new ones. - **`SO_REUSEADDR`** / `SO_REUSEPORT` — let new sockets bind even when there's TIME_WAIT for the same 4-tuple. - **Wider ephemeral port range** — `sysctl net.ipv4.ip_local_port_range` on Linux. Almost never the right fix: **reducing TIME_WAIT duration**. It's there for a reason. ## Looking at states in practice ### Linux / macOS ``` $ ss -tan # modern (faster than netstat) State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 128 0.0.0.0:443 0.0.0.0:* ESTABLISHED 0 0 192.168.1.5:55432 8.8.8.8:443 TIME_WAIT 0 0 192.168.1.5:55400 8.8.8.8:443 ``` ``` $ netstat -an # older but ubiquitous ``` ### Windows ``` > netstat -an ``` ### Cisco IOS ``` R1# show tcp brief TCB Local Address Foreign Address (state) 0xABCD123 10.0.0.1.22 10.0.0.50.55432 ESTAB 0xABCD124 10.0.0.1.22 0.0.0.0.0 LISTEN ``` ## Common state-related symptoms | Symptom | State to investigate | |---|---| | Server keeps crashing under load | Lots of TIME_WAIT → port exhaustion on client side | | Client hangs forever | Likely SYN_SENT (server unreachable) or ESTABLISHED with nothing flowing | | Server "not listening" on the expected port | No LISTEN entry — service not actually started | | Connection refused (RST quickly) | LISTEN absent, kernel rejects with RST | | "Half-open" connections after firewall changes | One side is FIN_WAIT_*, other is CLOSE_WAIT — firewall dropped teardown packets | ## CLOSE_WAIT — the "your app forgot to close" smell CLOSE_WAIT means: the remote side closed the connection (sent FIN), but **your application hasn't called `close()`** yet. The socket sits there indefinitely. ``` $ ss -tan | grep CLOSE_WAIT CLOSE_WAIT 1 0 192.168.1.5:80 10.0.0.42:55432 CLOSE_WAIT 1 0 192.168.1.5:80 10.0.0.42:55433 CLOSE_WAIT 1 0 192.168.1.5:80 10.0.0.42:55434 ``` 100 CLOSE_WAITs → likely an application bug. The app accepted connections but never properly closed them. Fix: trace the application's connection lifecycle. ## Common mistakes 1. **Lowering TIME_WAIT to "free ports."** Defeats the purpose. The right fix is connection reuse, not shortened TIME_WAIT. 2. **Confusing TIME_WAIT count with active connections.** TIME_WAIT sockets aren't doing anything — they're memory-only. They look alarming but aren't a problem unless you're hitting port exhaustion. 3. **Restarting an app and finding the port "in use."** Likely TIME_WAIT for that port's old connections. Wait 60-120s or use `SO_REUSEADDR`. 4. **Mistaking CLOSE_WAIT for normal.** CLOSE_WAIT accumulation means application bug. Not network's fault. 5. **Thinking SYN_SENT for a long time means slow server.** It usually means the server is unreachable or filtered — packets aren't getting through. Check connectivity and firewall. 6. **Using `netstat -an` on a busy server.** Slow. Modern `ss` is much faster. `ss -tan` for TCP, `ss -uan` for UDP. ## Lab to try tonight 1. Open two terminals. In one: `nc -l 8080` (Linux/macOS netcat listener). 2. In the other: `ss -tan | grep 8080`. See the LISTEN state. 3. From the second terminal: `nc localhost 8080`. Watch ss: now ESTABLISHED on both sides. 4. In the first terminal (nc listener): press Ctrl+C to close. Watch ss again: state transitions to TIME_WAIT briefly, then disappears. 5. Open Wireshark, filter `tcp.port == 8080`. Repeat the above. Match the packet exchange to state transitions. 6. Bonus: start a Python `http.server` on port 80, run `wrk` or `ab` benchmark against it, watch your TIME_WAIT count climb on the client. ## Cheat strip | State | Meaning | |---|---| | **CLOSED** | Default. No connection. | | **LISTEN** | Server waiting for clients | | **SYN_SENT** | Client has sent SYN, waiting for SYN-ACK | | **SYN_RECEIVED** | Server got SYN, sent SYN-ACK, waiting for ACK | | **ESTABLISHED** | Open. Data flows. | | **FIN_WAIT_1** | We sent FIN, waiting for ACK | | **FIN_WAIT_2** | We got ACK, waiting for their FIN | | **TIME_WAIT** | We sent the final ACK, waiting 2 × MSL | | **CLOSE_WAIT** | They sent FIN — our app hasn't called close() yet (bug!) | | **LAST_ACK** | We sent FIN after CLOSE_WAIT, waiting for final ACK | | **CLOSING** | Both sides sent FIN simultaneously (rare) | | **`ss -tan`** | The daily-driver command | --- ## MTU & Fragmentation — https://packetmentor.com/topics/mtu-fragmentation/ > Why packets get fragmented or dropped on links with smaller MTU than expected. Covers MTU vs MSS, the Don't-Fragment bit, ICMP 'Fragmentation Needed,' Path MTU Discovery, and why blocking ICMP breaks the internet. ## Mental model Networks have a maximum frame size at Layer 2. For standard Ethernet that's **1500 bytes** of IP payload (1518 bytes including the Ethernet header and FCS, 1522 with an 802.1Q tag). A packet sent on a 1500-MTU link can be up to 1500 bytes. If a packet is larger than the next link's MTU, one of three things happens: 1. **Fragment it** — IPv4 router splits the packet into smaller pieces and forwards them. 2. **Drop it + send ICMP** — if the Don't-Fragment bit is set, router drops the packet and tells the sender "use smaller packets." 3. **Drop it silently** — broken middleboxes do this. Hardest to diagnose. The right behavior is #2 (Path MTU Discovery, or PMTUD). The wrong behavior is #3, which is why "blocking ICMP" at firewalls causes subtle failures. ## Common MTU values | Link type | MTU | |---|---| | **Ethernet (standard)** | 1500 | | **Ethernet with 802.1Q tag** | 1500 (payload) — needs 1504 raw | | **Ethernet with jumbo frames** | 9000 (or 9216) — needs explicit config end-to-end | | **PPPoE (DSL)** | 1492 | | **GRE tunnel** | 1476 (1500 − 24 GRE overhead) | | **GRE over IPsec** | ~1400 (1500 − 24 GRE − 52 IPsec) | | **WireGuard** | 1420 | | **Wi-Fi** | 2304 (theoretical) / 1500 (typical) | For CCNA: know 1500 default, 9000 jumbo, and that tunneling reduces effective MTU. ## MTU vs MSS | Term | What it is | Layer | |---|---|---| | **MTU** | Max bytes in a Layer-3 packet (IP header + payload) | L3 / interface | | **MSS** | Max bytes in a TCP segment payload (no headers) | L4 / TCP | MSS = MTU − IP header (20) − TCP header (20) = **MTU − 40** (in IPv4 without options). For default Ethernet: MSS = 1500 − 40 = **1460**. MSS is negotiated during the TCP 3-way handshake — each side advertises its desired MSS. The smaller is used. This is how endpoints avoid sending packets too big for their first hop. ## MSS clamping — fixing tunnel MTU issues When your network has a tunnel (GRE, VPN, MPLS), the effective MTU drops. Endpoints don't know — they still think 1500 works. Packets get fragmented (slow), dropped (silent failure), or PMTUD-handled (works but adds RTT). **MSS clamping** is the fix on the router carrying the tunnel: ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip tcp adjust-mss 1360 ``` This makes the router **rewrite the MSS value** in any TCP SYN passing through it. New SYNs say "1360 max" instead of "1460 max." Endpoints negotiate down to 1360. No packet ever gets too big for the tunnel. **No host reconfiguration needed.** Standard combo: set `ip mtu 1400` on the tunnel + `ip tcp adjust-mss 1360` to fix everything. ## Path MTU Discovery (PMTUD) When a packet has the **Don't-Fragment (DF) bit** set and arrives at a router that can't forward it without fragmenting: 1. Router drops the packet. 2. Router sends ICMP type 3 code 4 ("Fragmentation Needed, DF set") back to the sender, including the next-hop MTU. 3. Sender shrinks its packet size and retries. Most TCP stacks set the DF bit by default. PMTUD is how the internet "auto-tunes" to whatever the smallest MTU on a path happens to be. **The trap:** if anyone on the return path blocks ICMP type 3, the sender never gets the message. Packets keep getting dropped. Application hangs. PMTUD is *useful but fragile*. ## Fragmentation in IPv4 — how it works If the DF bit is **not** set, IPv4 fragments. Three fields in the IP header track this: - **Identification** — same for all fragments of one original packet - **Flags** — DF (Don't Fragment), MF (More Fragments) - **Fragment Offset** — where in the original packet this fragment sits Reassembly happens at the **destination** — not at intermediate routers. So fragmentation adds CPU load both at the fragmenting router and at the destination. ### IPv6 is different — no router fragmentation In IPv6, **routers don't fragment**. If a packet is too big, the router always drops it and sends ICMPv6 type 2 "Packet Too Big." Only the sender can fragment (by adding a Fragment Extension Header). In practice: IPv6 relies on PMTUD entirely. If PMTUD is broken, IPv6 connectivity breaks more visibly than IPv4 (no fragmentation safety net). ## Commands ``` ! Set L3 MTU on an interface R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip mtu 1400 ! Set Layer-2 MTU (often needed alongside) R1(config-if)# mtu 1500 ! MSS clamping for TCP traffic crossing this interface R1(config-if)# ip tcp adjust-mss 1360 ``` ### Verify ``` R1# show interfaces GigabitEthernet0/0 | include MTU R1# show ip interface GigabitEthernet0/0 | include MTU ! Test MTU end-to-end (send a max-sized ping with DF) R1# ping 8.8.8.8 size 1500 df-bit ``` If `ping 8.8.8.8 size 1500 df-bit` succeeds but `ping 8.8.8.8 size 1501 df-bit` fails, your path MTU is exactly 1500. If size 1500 already fails, MTU is smaller — keep bisecting. ## Common mistakes 1. **Blocking all ICMP at the firewall.** Breaks PMTUD silently. Symptoms: SSH connects but `git push` hangs; web pages load slowly with intermittent failures; large file transfers stall. Always allow ICMP type 3 code 4 inbound. 2. **Setting jumbo frames on only part of the network.** Jumbo MTU (9000) must be configured end-to-end — every switch port, every router interface, every host NIC. One device at 1500 → silent fragmentation / drops. 3. **Forgetting tunnel overhead.** Adding a GRE tunnel reduces effective MTU by 24 bytes. Adding IPsec adds another ~52. Don't forget MSS clamping after adding either. 4. **Confusing L2 and L3 MTU.** `mtu` (without `ip`) sets the Layer-2 frame MTU. `ip mtu` sets the Layer-3 packet MTU. Usually L3 MTU ≤ L2 MTU. Mismatched values cause confusion. 5. **Testing MTU with ping that doesn't have DF.** Without DF, the router happily fragments and ping succeeds. Always use `df-bit` to test actual end-to-end MTU. 6. **Assuming IPv4 fragments everywhere.** Many modern firewalls drop fragmented packets as a security policy (fragments are sometimes used for evasion). End-to-end fragmentation isn't reliable. PMTUD or MSS clamp instead. ## Lab to try tonight 1. Two routers connected via a serial / GRE tunnel with a known small MTU (configure `ip mtu 1400` on the tunnel). 2. From a host behind R1, ping the host behind R2 with `ping size 1500 df-bit`. Watch it fail. 3. Run `traceroute --mtu ` on Linux (or `ping size 1500` without DF) to find the path MTU. 4. Add `ip tcp adjust-mss 1360` on R1's tunnel interface. 5. Open a TCP connection through the tunnel (SSH, HTTP). Wireshark capture — note the SYN's MSS option value is rewritten to 1360. 6. Bonus: simulate a broken middlebox by blocking ICMP type 3 on the WAN. Watch HTTPS large-file transfers stall. Restore ICMP — they recover. ## Cheat strip | Concept | Plain English | |---|---| | **MTU** | Biggest frame allowed on a link | | **MSS** | Biggest TCP segment payload (MTU − 40 typically) | | **DF bit** | "Don't fragment me — bounce the packet if too big" | | **ICMP type 3 code 4** | "Fragmentation needed, here's the next-hop MTU" | | **PMTUD** | Path MTU Discovery — sender adapts based on ICMP feedback | | **Black hole** | PMTUD broken — packets dropped, no error reported back | | **MSS clamping** | Router rewrites TCP MSS as packets transit — fixes tunnel MTU issues | | **IPv6 fragmentation** | Only senders fragment, never routers | | **Default Ethernet MTU** | 1500 | | **Jumbo MTU** | 9000 — config end-to-end or don't bother | --- ## IGMP & IGMP Snooping — https://packetmentor.com/topics/igmp-snooping/ > How hosts join multicast groups (IGMP) and how a switch learns which ports actually want multicast traffic (snooping) — so it stops blasting video streams out every port. ## Mental model A teacher wants to stream a video to 30 students in the same VLAN. Three options: 1. **Unicast** — send 30 copies, one to each student. 30× the bandwidth. Wasteful. 2. **Broadcast** — send one copy to `255.255.255.255`, every host in the VLAN gets it whether it wanted it or not. Every NIC interrupts the CPU. Wasteful and noisy. 3. **Multicast** — send one copy to a group address. Only hosts that joined the group receive it. Switch fabric replicates as needed. Multicast is the right answer for one-to-many real-time data. But there's a problem: **switches by default treat multicast destinations like broadcasts** — they flood multicast frames out every port in the VLAN. Defeats the purpose. **IGMP** is how hosts signal "I want this group." **IGMP snooping** is how the switch listens to those signals and forwards multicast only where wanted. ## IGMP — the host-to-router protocol IGMP (Internet Group Management Protocol) runs between **hosts** and the **multicast router** (the L3 device — usually your default gateway). Three versions: | Version | Notable feature | |---|---| | **IGMPv1** (RFC 1112) | Join. No leave. Router polls; host responds. | | **IGMPv2** (RFC 2236) — most common | Adds explicit Leave message → faster pruning | | **IGMPv3** (RFC 3376) | Source-specific multicast (SSM) — host can say "I want group X from source Y only" | Three message types you must know: | Message | From → To | Purpose | |---|---|---| | **Membership Query** | Router → Hosts (224.0.0.1, all multicast hosts) | "Anyone still want any group?" | | **Membership Report (Join)** | Host → the group address itself (IGMPv1/v2) or 224.0.0.22 (IGMPv3) | "I want group X" | | **Leave Group** | Host → All-routers (224.0.0.2) | "I'm done with group X" — IGMPv2+ only | **Why "to the group itself"?** Reports for a group are sent to that group's multicast address (e.g., a host joining `239.1.1.10` sends the Report destined to `239.1.1.10`). The local router is listening on every multicast group it serves, so it sees the Report. IGMPv3 changed this — all v3 Reports go to a single well-known group `224.0.0.22` (IGMPv3-Routers) regardless of which group(s) you're joining. Periodic IGMP queries are sent by the multicast router every ~60 seconds. Hosts that still want the group respond with reports. If no host reports for a group, the router stops forwarding it after timeout. ## IGMP snooping — the switch's role The switch is at Layer 2 — it sees Ethernet frames, not IP. So how does it know which port wants which multicast group? **It eavesdrops on IGMP traffic.** The switch examines IGMP join messages as they cross it. It builds a table: ``` Group VLAN Ports 239.1.1.1 10 Fa0/3, Fa0/8, Fa0/15 239.2.5.7 10 Fa0/3 ``` When a multicast frame for `239.1.1.1` arrives, the switch checks the table and forwards only to ports 3, 8, 15. Not to ports 1, 2, 4–7, 9–14, 16+. The multicast router's port is treated as a "**multicast router (mrouter) port**" — all multicast traffic gets forwarded toward it regardless of join state, so the router can see and route the streams. ## Configuration — Cisco IOS IGMP snooping is on by default on most Cisco switches. Verify, don't blindly trust: ``` SW1# show ip igmp snooping Global IGMP Snooping configuration: ----------------------------------- IGMP snooping : Enabled IGMPv3 snooping (minimal) : Enabled Report suppression : Enabled TCN solicit query : Disabled TCN flood query count : 2 Robustness variable : 2 Last member query count : 2 Last member query interval : 1000 Vlan 10: IGMP snooping : Enabled Immediate leave : Disabled Multicast router learning mode : pim-dvmrp CGMP interoperability mode : IGMP_ONLY ``` Per-VLAN enable (if disabled): ``` SW1(config)# ip igmp snooping SW1(config)# ip igmp snooping vlan 10 ``` **IGMP querier** — if you're running multicast inside a VLAN that has no multicast router (e.g., L2-only segment), the switch can act as the querier itself: ``` SW1(config)# ip igmp snooping vlan 10 querier SW1(config)# ip igmp snooping vlan 10 querier address 192.168.10.250 ``` Without a querier, hosts' join state ages out and snooping starts flooding again. Always have **exactly one** querier per VLAN. ## Verification ``` SW1# show ip igmp snooping groups Vlan Group Type Version Port List ----------------------------------------------------------- 10 239.1.1.1 igmp v2 Fa0/3, Fa0/8, Fa0/15 10 239.2.5.7 igmp v2 Fa0/3 SW1# show ip igmp snooping mrouter SW1# show ip igmp snooping querier SW1# show ip igmp snooping vlan 10 ``` ## Common mistakes 1. **No querier in a router-less VLAN.** Snooping needs periodic queries to know which hosts still want which groups. No queries → state ages out → switch reverts to flooding. Configure the switch as the querier. 2. **Multiple queriers in the same VLAN.** Two routers (or a router + switch acting as querier) both sending queries. They elect one (lowest IP wins) but the loser still floods the network with redundant queries. 3. **Confusing IGMP and PIM.** IGMP is host → router. **PIM** is router ↔ router (the routing protocol that actually moves multicast across the network). They're separate; CCNA tests both names. 4. **Disabling snooping to "fix" a problem.** Slow streaming? Don't disable snooping — diagnose with `show ip igmp snooping groups`. Disabling makes the whole VLAN see all multicast traffic. 5. **mrouter port not detected.** If the switch can't auto-learn where the multicast router is, joins and reports won't reach it. Manually pin it: ``` SW1(config)# ip igmp snooping vlan 10 mrouter interface Gi1/0/1 ``` 6. **Forgetting that link-local multicast (224.0.0.0/24) is always flooded.** Snooping intentionally skips 224.0.0.x — these are control-plane addresses (OSPF hellos, IGMP queries themselves, etc.) and must reach every host. 7. **Storm-control thresholds eating multicast.** If you've set very aggressive storm control on multicast, legitimate IPTV bursts might be dropped. Tune carefully. ## Real-world use cases - **IPTV streaming** — set-top boxes join the channel's multicast group; the network delivers one stream multiplexed to thousands of boxes. - **Financial market data** — multicast feeds (`udp/239.x.x.x`) carry tick data to trading systems. Snooping is mandatory; flooding would saturate every port. - **Cluster heartbeats** — VMware, some Oracle RAC, certain HA stacks use multicast for member discovery. - **Video conferencing in classrooms** — one teacher, many viewers in the same campus. - **PIM Bootstrap, OSPF Hellos, etc.** — control-plane multicast that just works because of 224.0.0.0/24 always-flood rule. ## Lab to try tonight 1. Two switches, two PCs each, all in VLAN 10. One switch acts as querier (`ip igmp snooping vlan 10 querier`). 2. On PC1: start a multicast receiver — `vlc` listening on `udp://@239.1.1.1:5000` or `iperf3 -s -B 239.1.1.1`. 3. On a separate sender host: send a multicast stream — `vlc` → stream to `239.1.1.1:5000`. 4. `show ip igmp snooping groups` — PC1's port should appear under `239.1.1.1`. 5. From PC2 (different port, same VLAN), capture with Wireshark. You should *not* see the multicast frames — snooping is working. 6. Now `no ip igmp snooping vlan 10` and re-capture from PC2 — you'll see the stream flooded. 7. Bonus: shut down the querier and watch joins age out. Stream resumes flooding after ~5 minutes. ## Cheat strip | Concept | Plain English | |---|---| | **Multicast** | One source, many receivers, opt-in. Group destination = 224.0.0.0–239.255.255.255 | | **IGMP** | Host ↔ multicast router protocol — "I want this group" / "I'm done" | | **IGMPv2 Leave** | Faster pruning vs v1 (which had to wait for query timeout) | | **IGMP snooping** | Switch eavesdrops on IGMP and forwards multicast only to interested ports | | **mrouter port** | Switch port where the multicast router lives — always gets all multicast | | **Querier** | Sends periodic queries. Needed in every VLAN. Router by default; switch can do it | | **Link-local (224.0.0.0/24)** | Always flooded — never snooped (OSPF, IGMP queries, etc.) | | **PIM** | Multicast *routing* protocol — moves multicast across L3 boundaries. Separate from IGMP | | **`show ip igmp snooping groups`** | The one command that tells you snooping is working | --- ## Access Control Lists (ACLs) — https://packetmentor.com/topics/acls/ > Definitive CCNA-level ACL guide — first-match-wins, implicit deny, wildcard masks, standard vs extended vs named, direction (in vs out), the established keyword, time-based ACLs, named-ACL editing, 9 worked scenarios, and the ACL debug workflow. ## Mental model An ACL is a **checklist** a router runs over every packet on a configured interface. Each line is *"if the packet looks like X, permit (or deny) it."* The router walks the list top to bottom, and the **first matching line wins**. After that, no further lines are checked. The trap: if no line matches, there's an **invisible last line** that drops the packet. This is the **implicit deny**. It's the single biggest reason "my ACL isn't working" tickets exist — engineers forget to allow traffic they didn't think to call out. > **The one rule:** Every ACL ends with `deny ip any any`. You don't type it. The router adds it. If you write three `permit` lines and forget the fourth, anything that doesn't match those three is dropped silently. Always test with the traffic you *didn't* intend to block. ## What ACLs are good for (and not good for) ACLs are **stateless packet filters**. They look at one packet at a time — header fields only — and decide permit / deny. They don't track connection state, don't understand application protocols, and don't inspect payload. ### Good fits for ACLs - Coarse network-layer segmentation (block subnet A from subnet B) - Restricting management plane access (only NOC subnet may SSH the routers) - Filtering routing protocol updates (control which routes get advertised) - Marking traffic for QoS classification - Anti-spoofing (block source IPs that shouldn't appear on this interface) - NAT match lists (defining which traffic to translate) - OSPF / EIGRP route-map match conditions ### Bad fits for ACLs - Stateful inspection of TCP/UDP connections (use a firewall) - Layer-7 application awareness (use NGFW or app proxy) - Identity-aware policy (use 802.1X + ISE — see [Cisco ISE Basics](/topics/cisco-ise-basics/)) - High-volume east-west DC traffic policy (use micro-segmentation) An ACL is the right hammer when the nail is "I have IP X here and want to control whether it reaches IP Y on port Z." For everything else, look at the firewall above the router. ## Standard vs Extended vs Named — the three flavors | Aspect | Standard | Extended | Named | |---|---|---|---| | Filters on | Source IP only | Source + destination + protocol + port + more | Either type, with a name | | Numbered range | 1–99 / 1300–1999 | 100–199 / 2000–2699 | (uses name instead of number) | | Apply where | Close to **destination** | Close to **source** | Per-line editable | | Default style in 2026 | Avoid — too coarse | OK | **Best practice** | For the CCNA exam: know all three. In production: **always named**, because you can edit individual lines. ### Numbered standard ACL ``` R1(config)# access-list 10 permit 192.168.1.0 0.0.0.255 R1(config)# access-list 10 deny any R1(config)# interface Gi0/1 R1(config-if)# ip access-group 10 out ``` The router auto-adds the deny at the end, so the explicit `deny any` is technically redundant — but useful for clarity (and the explicit `deny` lets you add `log` to it). ### Numbered extended ACL ``` R1(config)# access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 80 R1(config)# access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 443 R1(config)# access-list 100 deny ip any any log R1(config)# interface Gi0/0 R1(config-if)# ip access-group 100 in ``` ### Named extended ACL (recommended) ``` R1(config)# ip access-list extended WEB-ONLY R1(config-ext-nacl)# permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 80 R1(config-ext-nacl)# permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 443 R1(config-ext-nacl)# deny ip any any log R1(config-ext-nacl)# exit R1(config)# interface Gi0/0 R1(config-if)# ip access-group WEB-ONLY in ``` ### Editing a named ACL by line number ``` R1# show access-list WEB-ONLY Extended IP access list WEB-ONLY 10 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq www (542 matches) 20 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 443 (1023 matches) 30 deny ip any any log (17 matches) ! Insert a new permit at line 15 (between 10 and 20) R1(config)# ip access-list extended WEB-ONLY R1(config-ext-nacl)# 15 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 22 ! Remove a line R1(config-ext-nacl)# no 15 ! Renumber to clean sequence R1(config)# ip access-list resequence WEB-ONLY 10 10 ``` This is impossible on numbered ACLs — you'd have to delete the whole thing and re-enter. Use named. ## Wildcard masks — the inverse trick Wildcard masks are the **bit-inverse** of subnet masks. A `0` in the wildcard means "must match"; a `1` means "don't care." Easiest conversion: **subtract each subnet-mask octet from 255**. | Subnet | Wildcard | Matches | |---|---|---| | 255.255.255.0 (/24) | 0.0.0.255 | one /24 network | | 255.255.255.128 (/25) | 0.0.0.127 | one /25 | | 255.255.255.192 (/26) | 0.0.0.63 | one /26 | | 255.255.255.224 (/27) | 0.0.0.31 | one /27 | | 255.255.255.240 (/28) | 0.0.0.15 | one /28 | | 255.255.255.248 (/29) | 0.0.0.7 | one /29 | | 255.255.255.252 (/30) | 0.0.0.3 | one /30 | | 255.255.255.255 (/32) | 0.0.0.0 | exactly one host | | 255.255.0.0 (/16) | 0.0.255.255 | one /16 | | 255.0.0.0 (/8) | 0.255.255.255 | one /8 | | 0.0.0.0 (/0) | 255.255.255.255 | everything | ### Special shortcuts ``` ! Match exactly one host permit ip host 192.168.1.5 any ! Equivalent to: permit ip 192.168.1.5 0.0.0.0 any ! Match any source / any destination permit ip any any ! Equivalent to: permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 ``` ### Wildcard masks that aren't subnet inverses Subnet masks are always contiguous (e.g., `11111111.11111111.11111111.00000000`). Wildcard masks **don't have to be** — you can use discontinuous wildcards like `0.0.0.252` (matches first 6 bits of fourth octet, ignores last 2 bits). Rare but tested on the exam. Example: match all **even** IPs in 10.1.1.0/24: ``` permit ip 10.1.1.0 0.0.0.254 any ! matches .0, .2, .4, .6, … (all evens) ``` You won't write these in real life. CCNA exam loves them. ## In vs Out — the direction trap ``` interface GigabitEthernet0/0 ip access-group MY-ACL in ← filter packets ARRIVING on this interface ip access-group MY-ACL out ← filter packets LEAVING this interface ``` **Half of all real-world ACL bugs are direction mistakes, not rule mistakes.** If your rule looks right but traffic still fails, swap direction and re-test before changing the rule. ### Rule of thumb - **Extended ACLs** → close to the **source** (drop early to save bandwidth on transit links). - **Standard ACLs** → close to the **destination** (since they only filter source IP, putting them at source would block too much). ### Visualizing direction Think of yourself standing at the interface, looking at packets. `in` is what the interface receives. `out` is what the interface sends. A common mistake: put `in` on the router's WAN interface and expect to filter LAN traffic. The LAN traffic *arrives on the LAN interface* — it's leaving the router on the WAN interface, so to filter LAN traffic on the WAN side, you'd use `out`. ## The `established` keyword — stateless return-traffic trick ACLs are stateless, but you can fake state for TCP using the `established` keyword. It matches packets that have ACK or RST flags set — i.e., packets that look like responses to an outbound connection, not new connections. ``` ! Allow outbound TCP, allow only return traffic inbound R1(config)# ip access-list extended OUTBOUND R1(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 any R1(config-ext-nacl)# deny ip any any R1(config)# interface Gi0/1 R1(config-if)# ip access-group OUTBOUND in R1(config)# ip access-list extended INBOUND R1(config-ext-nacl)# permit tcp any 192.168.1.0 0.0.0.255 established R1(config-ext-nacl)# deny ip any any R1(config)# interface Gi0/0 R1(config-if)# ip access-group INBOUND in ``` This is the cheapest possible stateless firewall. It works for TCP only (UDP has no equivalent flag). A real firewall does this and much more — see Zone-Based Policy Firewall or any NGFW. But for CCNA-level understanding, `established` is the "implement basic state with ACLs" pattern. ## Time-based ACLs You can gate ACL entries by time of day or day of week: ``` R1(config)# time-range BUSINESS-HOURS R1(config-time-range)# periodic weekdays 8:00 to 18:00 R1(config)# ip access-list extended LIMIT-STREAMING R1(config-ext-nacl)# deny tcp 10.0.0.0 0.0.0.255 any eq 1935 time-range BUSINESS-HOURS R1(config-ext-nacl)# permit ip any any ``` The deny only triggers during business hours. Outside that window, the line is ignored and the next line matches. Used for compliance, content filtering, or burstable bandwidth controls. ## ACL match counters Every ACL line has a hit counter: ``` R1# show access-list WEB-ONLY Extended IP access list WEB-ONLY 10 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq www (1,247 matches) 20 permit tcp 10.0.0.0 0.0.0.255 host 10.2.2.10 eq 443 (5,892 matches) 30 deny ip any any log (84 matches) ``` The counters are your debugging gold: - All zero = ACL isn't being hit (wrong interface? wrong direction? wrong source/dest?). - Hit count on the `deny` line = traffic you're blocking. Use `log` keyword for syslog details. - Hit count growing on a `permit` you didn't expect = something is matching that shouldn't. Reset counters: ``` R1# clear access-list counters WEB-ONLY ``` ## The `log` and `log-input` keywords Append `log` to any ACL line and matches generate syslog entries: ``` deny ip any any log ``` `log-input` is stronger — also includes the source MAC + ingress interface, useful for tracking down rogue hosts: ``` deny ip 192.0.2.0 0.0.0.255 any log-input ``` Caveat: logging is CPU-intensive. Use sparingly — adding `log` to every line on a high-traffic ACL is a great way to brown out the router's CPU. Use it on specific deny lines you actively monitor. ## Reflexive ACLs — basic statefulness `reflexive` ACLs were Cisco's pre-firewall attempt at stateful filtering. Largely obsolete now (replaced by Zone-Based Firewall + dedicated firewalls) but show up on the CCNA blueprint. ``` ip access-list extended OUTBOUND permit tcp 192.168.1.0 0.0.0.255 any reflect TCP-OUT ip access-list extended INBOUND evaluate TCP-OUT deny ip any any ``` The `reflect TCP-OUT` creates dynamic entries based on outbound traffic; `evaluate TCP-OUT` references them. The inbound side accepts return traffic without explicit permits per session. For CCNA: recognize the syntax; you'll basically never deploy it new in 2026. ## Verification — the four commands ``` R1# show access-lists R1# show access-list WEB-ONLY R1# show running-config | include access-list R1# show ip interface Gi0/0 | include access list ``` | Command | Tells you | |---|---| | `show access-lists` | All ACLs + their entries + match counters | | `show access-list ` | One ACL in detail | | `show ip interface ` | What ACLs are applied to that interface, in which direction | | `show running-config \| include access-list` | All ACL config lines in flat form | The combo of `show access-lists` (counters) + `show ip interface` (where applied + direction) covers most debug needs. ## The ACL debug workflow When an ACL "isn't working": 1. **Is it applied to the right interface?** `show ip interface `. Check both `Outgoing access list` and `Inbound access list` lines. 2. **Is it the right direction?** Swap `in` ↔ `out` and re-test if uncertain. 3. **Are hit counters incrementing?** `show access-list `. If counters are zero, the ACL is being bypassed — either applied wrong, or traffic isn't on this interface. 4. **Which line is matching?** Look at counters. Sometimes a too-general `permit` higher in the list catches traffic you thought would hit a later, more specific line. 5. **Is the implicit deny biting you?** Run `show access-list` and check the bottom line's hit count. If high, you're dropping traffic you forgot to allow. 6. **Wildcard mask correct?** Common to type subnet mask by accident. Verify by sanity-checking the binary. 7. **Did `log` reveal anything in syslog?** Add `log` to a suspect line, generate traffic, check `show logging`. ## Worked scenarios --- **Scenario 1.** You want to block subnet 192.168.50.0/24 from reaching 10.0.0.0/8. Where do you place the ACL? **Answer:** Extended ACL (because you're matching destination too) close to the **source** — on the router interface where 192.168.50.0/24 enters. Apply `in`. Drops traffic before it traverses any backbone link. --- **Scenario 2.** You write an ACL with three `permit` lines and apply it. All other traffic is dropped. Why? **Answer:** Implicit deny at the end. The router silently adds `deny ip any any` after your three permits. Fix: add an explicit `permit ip any any` at the end if you wanted only those three blocked and everything else allowed (you should rewrite the ACL with explicit denies + a final allow). --- **Scenario 3.** ACL line: `permit tcp 10.1.1.0 0.0.0.255 any eq 80`. Will this match a TCP reply *from* a web server *to* 10.1.1.5? **Answer:** No. The line specifies source `10.1.1.0/24` and destination port 80. Web server reply has source port 80 and destination 10.1.1.5 — that's the opposite direction. You'd need either: - A second line `permit tcp any eq 80 10.1.1.0 0.0.0.255` on the return-direction interface, or - The `established` keyword on the return-direction inbound ACL. --- **Scenario 4.** Your ACL has these two lines, in this order: ``` permit tcp any host 10.2.2.10 eq 80 deny tcp 192.168.1.5 0.0.0.0 host 10.2.2.10 eq 80 ``` Will `192.168.1.5` be able to reach the web server? **Answer:** Yes. First match wins. The `permit tcp any` matches `192.168.1.5` first; the explicit `deny` never gets evaluated. Fix: reorder — put the specific `deny` above the general `permit`. --- **Scenario 5.** You apply `access-list 10 deny 10.1.1.0 0.0.0.255` to an interface as `ip access-group 10 in`. No permits below it. What gets through? **Answer:** Nothing. The deny blocks 10.1.1.0/24, then the implicit `deny ip any any` blocks everything else. Always end a standard ACL with `permit any` if you want non-denied traffic through. --- **Scenario 6.** You want to deny SSH (port 22) to your router from everywhere except management VLAN 192.168.99.0/24. How? **Answer:** Apply an ACL to the VTY lines, not an interface: ``` ip access-list standard MGMT-ONLY permit 192.168.99.0 0.0.0.255 deny any log ! line vty 0 4 access-class MGMT-ONLY in transport input ssh ``` `access-class` on `line vty` is the management-plane ACL. Different from `ip access-group` (data-plane). --- **Scenario 7.** ACL says: ``` permit tcp 10.0.0.0 0.0.0.255 any eq 80 ``` A host at 10.0.0.5 tries to reach a web server on port 8080. Allowed? **Answer:** No. `eq 80` matches destination port 80 exactly. Port 8080 doesn't match. The packet falls through to the implicit deny. --- **Scenario 8.** You want to allow ICMP echo (ping) from a /27 subnet to a specific server, and block all other traffic from that subnet. Write the ACL. **Answer:** ``` ip access-list extended PING-ONLY permit icmp 10.1.1.0 0.0.0.31 host 10.2.2.10 echo deny ip any any log ``` Apply `in` on the source-side interface. Note `0.0.0.31` = /27 wildcard. --- **Scenario 9.** You have a wildcard mask of `0.0.0.252`. What does it match? **Answer:** First 30 bits exact, last 2 bits "don't care." If applied to a host `10.1.1.0` it matches `10.1.1.0` and `10.1.1.1` and `10.1.1.2` and `10.1.1.3` (last 2 bits varying). Discontinuous wildcards are tested on CCNA — recognize them, don't deploy them. ## Common mistakes 1. **Forgetting the implicit deny.** Three permits don't help if you also forgot to allow something. Always test what you *didn't* intend to block. 2. **Wrong direction (in vs out).** Number-one cause of "ACL isn't working." If unsure, swap and re-test. 3. **Wildcard mask backwards.** Typing `255.255.255.0` where you needed `0.0.0.255`. Easy mistake; common exam trap. 4. **Too-general line above a too-specific one.** First match wins. Put `host 10.1.1.5` rules above subnet rules above `any` rules. 5. **Applying to the wrong interface.** Extended ACL belongs close to source. Standard close to destination. Mixed up = wasted bandwidth or unintended blocks. 6. **Blocking return traffic.** Permitting outbound TCP but blocking inbound breaks every reply. Use `established` keyword or move to stateful filtering. 7. **Editing a numbered ACL line-by-line.** Impossible. Remove and re-enter, or use a named ACL. 8. **Forgetting `access-class` for VTY.** Using `ip access-group` on the management interface doesn't protect the VTY lines. Always pair: data-plane filter on interface, management-plane filter on VTY. 9. **Logging too aggressively.** Adding `log` to every line on a high-traffic ACL spikes CPU. Use sparingly, on specific deny lines. 10. **Resequencing without checking dependencies.** `ip access-list resequence` re-numbers lines — useful for tidying — but verify automation tools and runbooks don't reference specific line numbers. 11. **Mixing IPv4 and IPv6 ACLs.** They're separate. `ip access-list` is IPv4; `ipv6 access-list` is IPv6. Both must be applied separately to interfaces. 12. **Using a standard ACL where you needed extended.** "Block 10.1.1.5 from reaching 10.2.2.10" is impossible with standard (which only filters source). You need extended. ## Lab to try tonight 1. **Topology** — two LANs and one router between them. LAN-A = 10.1.1.0/24. LAN-B has a web server at 10.2.2.10 and an FTP server at 10.2.2.20. 2. **Web-only goal** — from LAN-A, allow only HTTP (port 80) to the web server. Block everything else. Write an extended named ACL, apply `in` on the LAN-A interface, test: - `curl http://10.2.2.10` should succeed - `ping 10.2.2.10` should fail - `curl ftp://10.2.2.20` should fail - `show access-list` — verify hit counters 3. **Add ICMP for diagnostics** — add `permit icmp 10.1.1.0 0.0.0.255 host 10.2.2.10 echo` above the deny. Ping now works. Trace flow with counters. 4. **Direction swap drill** — move the same ACL to `out` on the LAN-B interface. Observe the same end result, but `show access-list` hit counters move differently (and reverse-direction traffic hits different lines). 5. **VTY restriction** — set up `line vty 0 4` with `access-class MGMT-ONLY in` allowing only one mgmt subnet. Try SSH from an unauthorized subnet — should be denied. From the mgmt subnet — should succeed. 6. **established trick** — implement a "stateless firewall" using only ACLs. Outbound TCP from LAN-A permitted. Inbound on WAN only allowed if `established`. Verify a browser session works but unsolicited inbound (e.g., remote SSH attempt to a LAN-A host) is dropped. 7. **Wildcard practice** — use `0.0.0.7` (/29) wildcard to permit only `10.1.1.0`–`10.1.1.7`. Verify hosts `.5` and `.6` are allowed; `.10` is denied. 8. **Resequence** — after several inserts, run `ip access-list resequence WEB-ONLY 10 10` to clean up line numbering. Verify with `show access-list`. 9. **Bonus: time-based** — define a `BUSINESS-HOURS` time-range and apply to one of your rules. Verify behavior changes at the boundary. ## Cheat strip | Concept | Plain English | |---|---| | **First match wins** | Router reads top to bottom, stops on first match | | **Implicit deny** | Invisible `deny ip any any` at the end of every ACL | | **Wildcard mask** | Inverse of subnet mask. `0` = must match, `1` = don't care | | **Standard ACL** | Source IP only. 1–99 / 1300–1999. Close to destination. | | **Extended ACL** | Source + dest + protocol + port + more. 100–199 / 2000–2699. Close to source. | | **Named ACL** | Editable per line. Always prefer over numbered in production. | | **`in` vs `out`** | Direction the ACL filters relative to the interface | | **`host X`** | Shortcut for `X 0.0.0.0` (one specific IP) | | **`any`** | Shortcut for `0.0.0.0 255.255.255.255` (anywhere) | | **`eq `** | Destination/source port equals X. Other operators: `gt`, `lt`, `range` | | **`established`** | Match TCP packets with ACK/RST set (cheap stateless filter) | | **`log` / `log-input`** | Syslog the match. Use sparingly — CPU heavy | | **`access-class` (VTY)** | Apply ACL to management plane, not data plane | | **Resequence** | `ip access-list resequence NAME 10 10` cleans up line numbers | | **IPv4 ≠ IPv6** | Separate ACL types, must be applied separately | | **Time-range** | Gate lines by time of day / day of week | | **Match counters** | `show access-list` — your debug gold | | **Direction trap** | Half of all ACL bugs. If rule looks right, swap direction before changing rule. | **Looking for the longer one-page reference?** See the [ACL Cheat Sheet](/resources/acl-cheat-sheet/). ## Frequently asked questions **Q: Should I apply an ACL inbound or outbound?** A: Inbound is almost always right — traffic is dropped before the router does routing lookups, which is faster and safer. Outbound only makes sense when you want to filter based on the outgoing interface (e.g., "block this subnet from leaving out the DMZ"). Cisco's guidance since the 1990s: "extended ACLs close to the source, standard ACLs close to the destination, inbound whenever possible." **Q: What's the difference between a standard and an extended ACL?** A: Standard ACLs (numbered 1-99, 1300-1999) only match on source IP. Extended ACLs (100-199, 2000-2699, or named) match on source, destination, protocol, and port. In modern designs almost always use extended — even if you only need source filtering today, extended is more flexible tomorrow. Standard ACLs mostly appear in exams and on very old configurations. **Q: Why does my ACL block everything?** A: Almost certainly the implicit `deny ip any any` at the bottom. Every ACL has one — you don't type it, the router adds it. If your ACL is `permit tcp any any eq 80` and nothing else, HTTPS, DNS, ICMP, and every other protocol get dropped by the implicit deny. Fix: either add a final `permit ip any any` (defeats the purpose of the ACL) or add explicit permits for everything you meant to allow. **Q: When should I use a named ACL over a numbered ACL?** A: Always for new work. Named ACLs let you insert or delete individual lines by sequence number — with a numbered ACL, removing one line means re-entering the whole thing. Named ACLs also read better in `show run` (`ip access-list extended BLOCK-GUEST-WIFI` is self-documenting). Numbered ACLs only survive on old configs that predate wide named-ACL support. **Q: Do ACLs affect traffic sourced from the router itself?** A: No — an interface ACL only filters transit traffic, not packets generated by the router (SSH sessions, OSPF hellos, ARP, ICMP replies). If you need to filter what the router itself sends, use a `control-plane` policy or a route-map on the sourcing interface — not an ACL. --- ## Port Security — https://packetmentor.com/topics/port-security/ > Lock a switch port to a specific MAC address (or addresses). Covers static, dynamic, and sticky learning, violation modes (protect / restrict / shutdown), and the err-disable recovery dance. ## Mental model A switch port, by default, accepts traffic from any device that plugs in. That's flexible, but it means anyone who can physically reach a network port (visitor jack in a meeting room, a janitor's closet, a coffee shop) can plug in a laptop and join your LAN. Port security says: *"this port is locked to one specific MAC address (or N specific MAC addresses) — anything else, react."* That's the whole concept. The rest is detail: how the MAC gets registered, and what "react" means when an unauthorized device shows up. ## Three ways the switch learns the allowed MAC | Mode | How it learns | Survives reload? | |---|---|---| | **Static** | Hardcoded with `switchport port-security mac-address X` | Yes | | **Dynamic** | Learned from the first frame on the port | **No** — lost on reload | | **Sticky** | Learned dynamically, then saved to running-config | Yes (once `write memory` runs) | **Sticky is the typical production choice.** Set it up, let the legitimate device connect once (its MAC gets learned and saved), and you're protected forever. ## Three ways the switch reacts to a violation | Violation mode | What happens | Counter increments? | Log message? | |---|---|---|---| | **shutdown** (default) | Port goes to err-disable (down) | Yes | Yes | | **restrict** | Frames from bad MACs dropped, port stays up | Yes | Yes | | **protect** | Frames dropped silently | No | No | Most production deployments use **restrict** — it logs the event without killing the port (which would also kick off the legitimate user if someone else briefly plugs in). ## Commands ### Basic sticky port security (the production default) ``` SW1(config)# interface GigabitEthernet0/1 SW1(config-if)# switchport mode access SW1(config-if)# switchport access vlan 10 SW1(config-if)# switchport port-security SW1(config-if)# switchport port-security maximum 1 SW1(config-if)# switchport port-security mac-address sticky SW1(config-if)# switchport port-security violation restrict ``` Read it as: "this access port allows up to 1 MAC address; learn it dynamically and save it; on violation, drop frames but stay up." ### Allow a phone + a PC behind the phone A common scenario: a Cisco IP phone plugs into the wall, and a PC plugs into the phone. Two MACs on one port. ``` SW1(config-if)# switchport port-security maximum 2 ``` ### Statically allow a specific MAC ``` SW1(config-if)# switchport port-security mac-address aaaa.bbbb.cccc ``` ## Verification ``` SW1# show port-security SW1# show port-security interface GigabitEthernet0/1 SW1# show port-security address SW1# show interfaces status err-disabled ``` `show port-security` is the do-everything command. It shows: which ports have port-security enabled, max MACs allowed, current MACs learned, violation count, action mode. ## Recovering from err-disable When a port hits a violation in shutdown mode, it's `err-disable` — down, won't come up by itself. ### Manual recovery ``` SW1(config)# interface GigabitEthernet0/1 SW1(config-if)# shutdown SW1(config-if)# no shutdown ``` ### Auto-recovery after a timeout ``` SW1(config)# errdisable recovery cause psecure-violation SW1(config)# errdisable recovery interval 300 ``` Tells the switch: auto-recover from port-security err-disables after 300 seconds. Use cautiously — if the violation persists, the port will flap every 5 minutes. ## Common mistakes 1. **Enabling port-security on a trunk port.** Port-security is for access ports only — it doesn't understand the tagging on trunks. The switch will refuse the command on a trunk. Set the port to access first. 2. **Leaving `maximum` at default 1 when a phone is in line.** A Cisco IP phone has its own MAC, and the PC behind it has another. With max 1, the phone learns first, the PC violates. Set max to 2 (or use voice VLAN handling that exempts the voice VLAN). 3. **Using dynamic learning in production.** Learned MACs are lost on reload. Power cycles → no one can use the port → tickets. Always use sticky in production. 4. **Setting violation mode to shutdown without err-disable recovery.** Someone briefly plugs in the wrong device → port is dead until an admin SSHes in. For low-stakes deployments, use restrict + log. 5. **Forgetting to save running-config after sticky learning.** The MAC appears in `show running-config`, but if you don't `write memory`, a reload wipes it. Always save after enabling sticky. 6. **Locking a port to a MAC, then swapping the connected device.** New device → new MAC → violation. To swap devices legitimately, either: `no switchport port-security mac-address sticky` (clears learned), then re-enable; or update the static MAC. ## Lab to try tonight 1. One switch. Plug a laptop into Gi0/1. 2. Configure Gi0/1 for sticky port security with max 1, violation restrict. 3. Verify with `show port-security` — should show one MAC learned (your laptop's). 4. Unplug your laptop, plug in a different device. Verify with `show port-security`: violation counter increments, port stays up but frames are dropped. 5. Plug your laptop back in. Should work immediately. 6. Switch violation to `shutdown`. Repeat the swap — port should now err-disable. 7. Add `errdisable recovery cause psecure-violation` + `errdisable recovery interval 60`. Watch the port recover automatically after 60s. ## Cheat strip | Concept | Plain English | |---|---| | **Static / Dynamic / Sticky** | How the allowed MAC is configured. Use sticky in production. | | **Maximum N** | How many MACs are allowed on the port | | **Violation: shutdown** | Default. Port err-disables on violation. | | **Violation: restrict** | Drop frames + log, port stays up | | **Violation: protect** | Drop frames silently, no log | | **Sticky** | Dynamic + save-to-running-config. Most common production setting. | | **err-disable** | The state a port enters after a shutdown-mode violation | | **Recovery** | Manual `shut`/`no shut` or auto via `errdisable recovery` | ## Frequently asked questions **Q: What's the difference between shutdown, restrict, and protect violation modes?** A: **Shutdown** (default) — port goes to err-disabled state, drops all traffic, must be manually recovered or `errdisable recovery` timer. **Restrict** — drops offending traffic, generates SNMP trap and syslog, keeps forwarding valid traffic, counter increments. **Protect** — silently drops offending traffic, no logging, no counter. Production default: shutdown for user ports, restrict if you need continuous logging without downtime. **Q: What is sticky MAC learning?** A: `switchport port-security mac-address sticky` tells the switch to learn MACs dynamically but save them into `running-config` as if they were manually configured. First device to connect on a port gets pinned to that port. Great for asset-tracking scenarios (only this laptop can use this port). Common gotcha: sticky-learned MACs need to be saved to startup-config or they're lost at reboot. **Q: How do I recover a port from err-disabled state?** A: Manual: `shutdown` then `no shutdown` on the interface. Automatic: enable `errdisable recovery cause psecure-violation` globally and set `errdisable recovery interval ` (default 300). Automatic recovery is convenient but hides recurring problems — every 5 minutes the port comes back, gets slammed again, err-disables. Fix the root cause instead of just enabling auto-recovery. **Q: Should I use port-security on trunk ports?** A: No — trunks carry traffic for many VLANs from many devices (potentially thousands of MACs). Port-security assumes a small number of expected MACs per port. On trunks, use DAI + DHCP snooping + BPDU Guard on the far-end access ports, not port-security. Port-security is for access ports facing single devices. **Q: What's the max MAC address count I should set?** A: 1 for a bare workstation. 2 for a PC-behind-phone (phone's own MAC + PC's MAC via the phone). 3-4 for a shared workstation or lab bench. If you're setting it higher than 5-10, you probably want a different tool (802.1X). The whole point of port-security is "small number of expected MACs" — high limits defeat the purpose. --- ## DHCP Snooping — https://packetmentor.com/topics/dhcp-snooping/ > Switch security feature that blocks rogue DHCP servers. Trusts one port (where the real server lives) and drops DHCP server messages from any other port. Foundation for Dynamic ARP Inspection too. ## Mental model A user plugs a small home router into a meeting room's network jack. By default it's a DHCP server. It starts answering DHCP requests from other users in the building — handing out its own LAN's IP range and pointing them at itself as the gateway. Now every user it captures is sending traffic *through the rogue device*. The attacker has man-in-the-middle access to anyone unlucky enough to renew DHCP after the rogue came online. **DHCP Snooping** kills this attack class. The switch learns: *"DHCP server messages only ever come from this one port. Drop server messages from anywhere else."* That's the whole concept. Configuration is mostly which VLANs to enable it on and which port is trusted. ## How it works DHCP messages have two sides: - **Client → server**: DISCOVER, REQUEST (anyone can send these) - **Server → client**: OFFER, ACK, NAK (only legitimate servers should send these) DHCP Snooping classifies switch ports as: - **Trusted** — both client *and* server messages are allowed (uplink to the real DHCP server) - **Untrusted** (the default) — only client messages allowed; server messages get dropped So a rogue device on an access port can send DISCOVERs (client traffic, allowed) but its OFFERs/ACKs get filtered by the switch and never reach victims. ## The binding table While DHCP Snooping is on, the switch records every successful lease in its **binding table**: | Client MAC | IP assigned | Lease time | VLAN | Port | |---|---|---|---|---| | aaaa.bbbb.cccc | 10.0.0.50 | 86400s | 10 | Gi0/3 | | dddd.eeee.ffff | 10.0.0.51 | 86400s | 10 | Gi0/5 | This table is gold. Two related security features rely on it: - **Dynamic ARP Inspection (DAI)** — verifies ARP replies match the binding table. Stops ARP poisoning. - **IP Source Guard (IPSG)** — blocks a host from spoofing a source IP that doesn't match the binding table for its port. ## Commands ``` ! Globally enable DHCP snooping SW1(config)# ip dhcp snooping ! Enable on specific VLAN(s) SW1(config)# ip dhcp snooping vlan 10 SW1(config)# ip dhcp snooping vlan 20 ! Mark the uplink to the DHCP server as trusted SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# ip dhcp snooping trust ! All other ports stay untrusted by default — that's correct ! Optional: rate-limit DHCP requests on access ports (prevents starvation attack) SW1(config)# interface range GigabitEthernet0/1 - 23 SW1(config-if-range)# ip dhcp snooping limit rate 10 ! 10 pps max ! Optional: explicitly disable Option 82 insertion if downstream device doesn't expect it SW1(config)# no ip dhcp snooping information option ``` ## Verification ``` SW1# show ip dhcp snooping SW1# show ip dhcp snooping binding SW1# show ip dhcp snooping interfaces ``` `show ip dhcp snooping binding` shows the live binding table — the most useful single command. ## Common mistakes 1. **Forgetting to enable on specific VLANs.** `ip dhcp snooping` globally turns it on, but it only takes effect on VLANs you explicitly list with `ip dhcp snooping vlan N`. Many engineers forget this and wonder why nothing's happening. 2. **Trusting the wrong port.** If you flag an access port as trusted, you've just allowed any device on that port to be a rogue DHCP server. Trust only the uplink (or interconnect) toward the real server. 3. **Option 82 mismatch.** By default, Cisco switches insert DHCP Option 82 information when relaying. Some downstream DHCP servers reject these. Either disable Option 82 insertion or configure the server to accept it. 4. **Rate-limit set too low.** If you rate-limit DHCP to 5 pps and the DHCP server tries to renew dozens of leases simultaneously, the switch starts dropping legitimate traffic. (Default behavior is **no rate-limit** until you configure `ip dhcp snooping limit rate`; 100 pps is a sane starting point if you choose to set one.) 5. **Not pairing it with DAI / IPSG.** DHCP Snooping by itself only stops rogue servers. Real defense in depth requires Dynamic ARP Inspection (blocks ARP poisoning) and IP Source Guard (blocks IP spoofing) — both depend on the snooping binding table. 6. **Binding table lost on switch reboot.** Without persistence, the table rebuilds from new leases. To survive a reboot, configure `ip dhcp snooping database flash:dhcp-snooping.txt` so it's saved. ## Lab to try tonight 1. One switch, two PCs, one DHCP server. Enable DHCP snooping on the VLAN. 2. Mark the uplink to the DHCP server as trusted. 3. Boot the PCs, watch them get DHCP leases. Verify with `show ip dhcp snooping binding`. 4. Now connect a second device set to "share connection" or with a built-in DHCP server (any home router). Plug it into another switch port (untrusted). 5. Try to get a third PC to DHCP from the rogue server. Watch the rogue's OFFERs get dropped by the switch. 6. Bonus: enable Dynamic ARP Inspection on the same VLAN. Run a free ARP spoofing tool from one PC. Watch DAI block it using the snooping binding table. ## Cheat strip | Concept | Plain English | |---|---| | **Trusted port** | Server-side DHCP messages allowed. Usually only the uplink. | | **Untrusted port** | Default. Only client-side DHCP messages allowed. | | **Binding table** | MAC ↔ IP ↔ port ↔ VLAN — built from successful leases | | **Option 82** | Cisco-inserted relay information. Disable if server rejects it. | | **Rate limit** | Caps DHCP requests per port. Stops starvation attacks. | | **DAI / IPSG** | Both rely on the snooping binding table. Stack them for real defense. | | **Persistence** | Save the binding table to flash so it survives reboot. | --- ## AAA · RADIUS & TACACS+ — https://packetmentor.com/topics/aaa/ > Authentication, Authorization, Accounting — centralize who can log in, what they can do, and what they did. Covers RADIUS vs TACACS+, method lists, and why every network with more than 5 devices uses centralized auth. ## Mental model Managing 50 switches without AAA: every switch has its own local user database. Hire someone? Update 50 devices. Fire someone? Update 50 devices. Audit who did what? Hope each device's local log survived. With AAA: every switch points to a central **RADIUS** or **TACACS+** server. One place to add/remove users, one place to set permissions, one place to see who logged in where. Add the 51st switch? It just points at the same server. Three letters, three jobs: | | What it answers | |---|---| | **Authentication** | Who are you? (proves identity — username + password, certificate, token) | | **Authorization** | What are you allowed to do? (commands, services, privilege level) | | **Accounting** | What did you do? (logs of commands, sessions, byte counts) | You can use all three or just authentication. Most networks start with auth only, add authorization later. ## RADIUS vs TACACS+ | | RADIUS | TACACS+ | |---|---|---| | **Origin** | Open standard (IETF) | Cisco proprietary (mostly) | | **Transport** | UDP 1812 (auth) + 1813 (accounting) | TCP 49 | | **Encryption** | Only password is encrypted | Entire packet body encrypted | | **AAA separation** | Auth + authz combined in one exchange | Auth, authz, accounting are separate exchanges | | **Typical use** | 802.1X, Wi-Fi, VPN clients | Device admin (router/switch login) | | **Per-command authorization** | Limited | Full support — TACACS+ can authorize every command typed | **Rule of thumb:** - **RADIUS** for client/user-side auth (Wi-Fi, 802.1X port auth, VPN client login) - **TACACS+** for admin login to network devices (because of per-command authorization and full encryption) Many large networks run **both** — TACACS+ for engineer logins, RADIUS for end-user Wi-Fi. ## Commands — typical TACACS+ for admin login ``` ! Enable AAA R1(config)# aaa new-model ! Define the TACACS+ server R1(config)# tacacs server CORP-TAC R1(config-server-tacacs)# address ipv4 10.0.99.5 R1(config-server-tacacs)# key supersecret123 ! Build a server group (lets you reference multiple servers) R1(config)# aaa group server tacacs+ TACGROUP R1(config-sg-tacacs+)# server name CORP-TAC ! Method list: try TACACS+ first, fall back to local if server unreachable R1(config)# aaa authentication login default group TACGROUP local R1(config)# aaa authorization exec default group TACGROUP local R1(config)# aaa accounting commands 15 default start-stop group TACGROUP ! Make sure a local user exists for fallback R1(config)# username admin privilege 15 secret rescuepass ``` **Critical detail:** the `local` keyword at the end of `aaa authentication login default group TACGROUP local` is what saves you when the TACACS+ server is down. Without it, no one can log in. ## Commands — typical RADIUS for 802.1X port auth ``` R1(config)# aaa new-model R1(config)# radius server CORP-RAD R1(config-radius-server)# address ipv4 10.0.99.6 auth-port 1812 acct-port 1813 R1(config-radius-server)# key supersecret456 R1(config)# aaa group server radius RADGROUP R1(config-sg-radius)# server name CORP-RAD R1(config)# aaa authentication dot1x default group RADGROUP R1(config)# aaa authorization network default group RADGROUP R1(config)# dot1x system-auth-control ! On an access port that should enforce 802.1X R1(config)# interface GigabitEthernet0/5 R1(config-if)# switchport mode access R1(config-if)# authentication port-control auto R1(config-if)# dot1x pae authenticator ``` ## Method lists — the magic of "try this, then that" A method list says: *"try authentication via X. If X says no, deny. If X is unreachable, try Y. If Y is unreachable, try Z."* ``` aaa authentication login default group TACGROUP local enable ``` Read aloud: *"For login, first ask TACGROUP. If TACGROUP can be reached and says no, deny. If TACGROUP is unreachable, try the local user database. If that's empty, try the enable password."* Critical safety net: **always include `local` or `enable` at the end** so you can recover if the server is unreachable. ## Verification ``` R1# show aaa servers R1# show tacacs R1# show radius statistics R1# debug aaa authentication ! temporary — don't leave on ``` ## Common mistakes 1. **Forgetting the local fallback.** `aaa authentication login default group TACGROUP` (without `local`) → if the server is unreachable, you can't log in. Always add `local`. 2. **No local user account.** You added `local` to the method list, but no local users exist. Same problem. Always create at least one local admin user with `username ... privilege 15 secret ...`. 3. **Confusing RADIUS and TACACS+ ports.** RADIUS: UDP 1812 auth, 1813 accounting (sometimes legacy 1645/1646). TACACS+: TCP 49. Get them mixed up and the server seems unreachable. 4. **Pre-shared key mismatch.** The `key supersecret123` on the device must exactly match the corresponding entry on the AAA server. One typo and authentication silently fails. 5. **Skipping accounting.** Authentication tells you someone logged in. Accounting tells you what they did. For compliance / forensics, accounting is often required. 6. **TACACS+ over a slow / lossy link.** TCP means retransmits — if your management link is congested, login attempts hang. Have a fallback method (RADIUS over UDP, or local). 7. **Using `enable` as the only fallback.** `enable` password is shared by everyone who knows it. Use `local` instead — at least each rescue user has their own credential. ## Lab to try tonight 1. Install FreeRADIUS or TACACS+ server (`tacacs+` package on Ubuntu). Configure one test user. 2. On a Cisco router, enable AAA, point at the server, configure a method list with local fallback. 3. Add a local admin user as a safety net. 4. Log out, log back in via SSH. Watch the AAA server log the request and the device accept. 5. Make the server unreachable (firewall block / power off). Log in again — should fall back to the local user. 6. Bonus: configure TACACS+ command authorization. Watch each command get authorized in real time. ## Cheat strip | Concept | Plain English | |---|---| | **AAA** | Authentication, Authorization, Accounting | | **RADIUS** | Open standard. UDP 1812/1813. Encrypts only the password. | | **TACACS+** | Cisco-leaning. TCP 49. Encrypts the entire packet body. | | **Method list** | Ordered list of auth sources to try | | **`local`** in the list | Critical safety net — fall back to local users | | **`aaa new-model`** | Must come first. Enables AAA. | | **Per-command authz** | TACACS+ feature — authorize every CLI command | | **`enable` as fallback** | Shared password. Use `local` instead. | --- ## 802.1X — Port-Based Network Access Control — https://packetmentor.com/topics/dot1x/ > Lock every switch port until the connected device proves identity. Covers the supplicant / authenticator / auth server roles, EAPOL on the wire, and how 802.1X plugs into RADIUS for enterprise Wi-Fi and wired auth. ## Mental model [Port security](/topics/port-security/) locks a port by MAC address — works, but a MAC is easily spoofed. **802.1X is the proper answer**: a device must authenticate (with credentials, a certificate, or a token) before the switch port will pass any traffic. The switch port has two virtual states: - **Uncontrolled** — only 802.1X authentication traffic (EAPOL) is allowed - **Controlled** — opens once authentication succeeds. Normal traffic flows. Plug in an unauthorized device → the port stays uncontrolled → no DHCP, no anything. Plug in an authorized device → it authenticates → the port opens. That's the whole concept. The rest is the protocol mechanics. ## Three roles | Role | What it is | In a typical deployment | |---|---|---| | **Supplicant** | The device trying to connect — provides credentials | Laptop, phone, IP camera | | **Authenticator** | The network device controlling the port | Cisco switch (wired) or AP/WLC (wireless) | | **Authentication Server** | Validates the credentials, decides yes/no | RADIUS server (Cisco ISE, FreeRADIUS, Microsoft NPS) | The authenticator is just the gatekeeper — it relays messages but never sees the actual password. This is important for security: an attacker compromising a switch can't extract user credentials from it. ## The protocols at each link ``` Supplicant ←EAPOL→ Authenticator ←RADIUS→ Auth Server (laptop) (switch) (FreeRADIUS) ``` - **EAPOL** (EAP over LAN) — between the device and the switch. Layer 2 only. - **RADIUS** — between the switch and the auth server. Layer 3 (UDP). The switch acts as a translator: takes EAPOL frames from the supplicant, repackages the contents into RADIUS messages for the server, and reverses on the way back. ## EAP methods you'll see EAP is a framework that supports many authentication methods. Common ones: | Method | Auth type | Used for | |---|---|---| | **EAP-TLS** | Mutual certificates | The gold standard. Strongest auth, hardest to deploy. | | **PEAP** | Server cert + username/password inside a TLS tunnel | Most common in enterprises (especially with AD) | | **EAP-FAST** | Server cert + protected access credential | Cisco's optimization of PEAP | | **EAP-MD5** | Username + MD5-hashed password | Legacy. Don't use. | | **EAP-MSCHAPv2** | Inside PEAP/EAP-FAST | The actual credential check used inside PEAP | For a Windows / Active Directory environment, the standard combo is **PEAP-MSCHAPv2** — domain credentials authenticate, all carried over a TLS tunnel that the supplicant verifies via the server's certificate. ## Commands — wired 802.1X on a Cisco switch ``` ! Enable AAA and point to RADIUS SW1(config)# aaa new-model SW1(config)# radius server CORP-RAD SW1(config-radius-server)# address ipv4 10.0.99.5 auth-port 1812 acct-port 1813 SW1(config-radius-server)# key supersecret123 SW1(config)# aaa group server radius RADGROUP SW1(config-sg-radius)# server name CORP-RAD SW1(config)# aaa authentication dot1x default group RADGROUP SW1(config)# aaa authorization network default group RADGROUP ! Globally enable 802.1X SW1(config)# dot1x system-auth-control ! On each access port SW1(config)# interface GigabitEthernet0/5 SW1(config-if)# switchport mode access SW1(config-if)# switchport access vlan 10 ! the "authorized" VLAN SW1(config-if)# authentication port-control auto ! the magic line SW1(config-if)# dot1x pae authenticator ``` `authentication port-control auto` means: start in unauthorized state, only let the device in after successful 802.1X auth. ### Three port-control modes | Mode | Behavior | |---|---| | **auto** | Standard 802.1X — port stays closed until auth succeeds | | **force-authorized** | Port stays open regardless. Default. Same as no 802.1X. | | **force-unauthorized** | Port stays closed forever. Used to lock a port. | ## Verification ``` SW1# show authentication sessions SW1# show authentication sessions interface GigabitEthernet0/5 SW1# show dot1x interface GigabitEthernet0/5 SW1# debug dot1x events ! while troubleshooting only ``` `show authentication sessions` lists every authenticated device on every port — user, MAC, VLAN, auth method, session ID. The big picture in one command. ## Guest / failure handling What if 802.1X fails (no supplicant, wrong creds, RADIUS server down)? Three common options: ``` ! Guest VLAN — fall through to a restricted VLAN if no supplicant responds SW1(config-if)# authentication event no-response action authorize vlan 99 ! Auth-fail VLAN — different VLAN for devices that try and fail SW1(config-if)# authentication event fail action authorize vlan 100 ! Critical auth — if RADIUS server unreachable, allow the device into a fallback VLAN SW1(config-if)# authentication event server dead action authorize vlan 50 ``` Use these carefully — they're escape hatches. An attacker who knows about the guest VLAN can simply not respond and get network access. ## Common mistakes 1. **Forgetting `aaa new-model`.** Without it, none of the 802.1X commands work. 2. **No RADIUS server, then enabling 802.1X.** Devices try to authenticate, can't, get nothing. Always test RADIUS reachability before enabling on production ports. 3. **Forgetting to set the port to access mode.** 802.1X works on access ports. Trunk ports use other mechanisms. 4. **Locking yourself out of management.** Don't enable 802.1X on management VLANs without a way back in. Always keep a console / OOB management path during rollout. 5. **No fallback for non-supplicant devices.** Older printers and IoT devices can't speak 802.1X. Use **MAB** (MAC Authentication Bypass) as a fallback — the switch sends the MAC to the RADIUS server, which whitelists it. Less secure than 802.1X but works for devices that can't authenticate. 6. **Using EAP-MD5 in production.** Trivially broken. Always pick PEAP, EAP-TLS, or EAP-FAST. 7. **Skipping the certificate validation step on PEAP clients.** Without server cert validation, a man-in-the-middle attacker can spoof the RADIUS server and harvest credentials. Always deploy the correct CA cert to clients. ## Lab to try tonight 1. Set up FreeRADIUS with one test user. 2. On a Cisco switch, configure AAA + RADIUS pointing to your FreeRADIUS server. 3. Enable `dot1x system-auth-control` globally + `authentication port-control auto` on one access port. 4. On a Windows / Linux laptop, configure an 802.1X supplicant with PEAP + your test credentials. 5. Plug in. Watch `show authentication sessions` show the device move from "Authenticating" to "Authorized." 6. Try with wrong credentials → port stays unauthorized. 7. Try with no supplicant configured → port stays unauthorized. 8. Bonus: add MAB fallback for non-supplicant devices: `authentication order dot1x mab`. Verify a non-802.1X device authenticates by MAC. ## Cheat strip | Concept | Plain English | |---|---| | **802.1X** | Authenticate the device BEFORE giving it network access | | **Supplicant** | The device trying to connect | | **Authenticator** | The switch / AP that gates the port | | **Auth server** | RADIUS — actually checks credentials | | **EAPOL** | Layer-2 protocol between supplicant and authenticator | | **RADIUS** | Layer-3 protocol between authenticator and server | | **EAP-TLS** | Mutual certs. Strongest, hardest. | | **PEAP** | TLS tunnel + username/password inside. Most common. | | **MAB** | MAC-based fallback for devices that can't speak 802.1X | | **Guest VLAN** | Fallback for unauthenticated devices | | **`port-control auto`** | The magic line that turns on 802.1X enforcement | --- ## VPN Basics — IPsec & SSL — https://packetmentor.com/topics/vpn-basics/ > How two separated networks (or one user and a network) can talk privately over the public internet. Covers site-to-site IPsec, remote-access SSL/TLS VPNs, IKE phases, and what 'tunnel' actually means. ## Mental model Two offices, one in Connecticut, one in Pakistan. Both have private 10.x.x.x networks. The CT office needs to reach the PK office's file server. Options: 1. **Dedicated leased line** — works, expensive (thousands per month), takes weeks to provision. 2. **VPN over the public internet** — works, cheap (internet bandwidth you already pay for), provisioning is hours. A VPN does what the leased line does, except the bits ride through the public internet inside an **encrypted tunnel**. To the public, the packets look like opaque garbage between two specific public IPs. To the office routers, the inner traffic is private and looks like a directly connected network. That's the entire concept. The rest is protocol mechanics. ## Two flavors of VPN | | Site-to-Site IPsec | Remote-Access SSL/TLS | |---|---|---| | **What's connected** | LAN ↔ LAN | One user → LAN | | **Always-on?** | Yes — persistent tunnel | No — user dials in on demand | | **Encryption** | IPsec (IKE + ESP) | TLS (same as HTTPS) | | **Client software** | Just the router, no per-user client | VPN client app or browser portal | | **Authentication** | Pre-shared key or certificates | Username/password, MFA, certs | | **Typical use** | Connect branch offices, AWS to on-prem | Work-from-home, contractor access | | **Standard ports** | UDP 500 (IKE), UDP 4500 (NAT-T), proto 50 (ESP) | TCP 443 (looks like HTTPS) | For CCNA, focus on the conceptual difference and the high-level IPsec phases. Deep IPsec config is a CCNP / Security topic. ## Site-to-site IPsec — high-level flow ``` Phase 1 (IKE Phase 1): peers authenticate to each other and build a secure control channel Phase 2 (IKE Phase 2): peers negotiate the parameters of the actual data tunnel Data: user packets ride the tunnel, encapsulated in ESP ``` ### Phase 1 — establish trust Two routers want to build a VPN tunnel between them. First they prove they are who they say. Two methods: - **Pre-shared key (PSK)** — both routers configured with the same secret string. Simple, works for small deployments. - **Certificates** — each router has a cert signed by a trusted CA. Scales to thousands of peers. PSK is fine for 2 sites. For 50+ sites, use certs. ### Phase 2 — negotiate the data tunnel Peers agree on: - Encryption algorithm (AES-256 is the default in 2026) - Integrity / hashing (SHA-256+) - Lifetime (how long before keys rotate, often 1 hour) - Interesting traffic (which subnets get tunneled — defined by ACL) Once Phase 2 completes, the tunnel is up. Packets matching the "interesting traffic" ACL get encrypted with ESP and sent across. ### Data — ESP **ESP** (Encapsulating Security Payload, IP protocol 50) wraps each packet: ``` Original packet: [ IP hdr (10.1.0.5 → 10.2.0.10) ][ TCP payload ] After ESP encapsulation: [ outer IP (R-A pub → R-B pub) ][ ESP ][ encrypted payload ] ``` The outer IPs are the routers' public IPs. The inner private IPs are invisible to anyone watching the public internet. ESP also includes a HMAC so any tampering is detected. ## Remote-access SSL/TLS — the simpler cousin User opens a VPN client (AnyConnect, OpenVPN, WireGuard, Tailscale). Authenticates with username + password (+ MFA). Gets a virtual IP on the corporate LAN. From the OS's perspective, there's a new network interface that routes selected traffic over an encrypted TLS connection to the VPN concentrator. Because TLS rides over TCP/443, SSL VPNs work through almost any firewall — they look identical to HTTPS browsing. That's their main advantage over IPsec, which is often blocked. WireGuard and Tailscale (modern entrants) are technically not "SSL VPNs" but architecturally serve the same use case: per-user, on-demand VPN access. ## Commands — minimal IPsec site-to-site (Cisco IOS) ``` ! Phase 1 policy R1(config)# crypto isakmp policy 10 R1(config-isakmp)# encr aes R1(config-isakmp)# hash sha256 R1(config-isakmp)# authentication pre-share R1(config-isakmp)# group 14 R1(config-isakmp)# lifetime 86400 R1(config)# crypto isakmp key supersecret123 address 203.0.113.50 ! Phase 2 transform-set R1(config)# crypto ipsec transform-set TS-AES esp-aes 256 esp-sha256-hmac R1(cfg-crypto-trans)# mode tunnel ! Interesting traffic R1(config)# access-list 110 permit ip 10.1.0.0 0.0.0.255 10.2.0.0 0.0.0.255 ! Crypto map ties it all together R1(config)# crypto map MYMAP 10 ipsec-isakmp R1(config-crypto-map)# set peer 203.0.113.50 R1(config-crypto-map)# set transform-set TS-AES R1(config-crypto-map)# match address 110 ! Apply to the WAN interface R1(config)# interface GigabitEthernet0/1 R1(config-if)# crypto map MYMAP ``` Mirror the config on R2 (swap subnets and peer IP). ## Verification ``` R1# show crypto isakmp sa ! Phase 1 state R1# show crypto ipsec sa ! Phase 2 state + packet counters R1# show crypto session ``` Healthy tunnel: ISAKMP shows `QM_IDLE` (Phase 1 complete, idle waiting for traffic). IPsec SA shows packet/byte counters incrementing when traffic flows. ## Common mistakes 1. **Mismatched parameters between peers.** Phase 1 and Phase 2 parameters must match exactly — encryption, hash, DH group, lifetime, transform-set. One mismatch and the tunnel fails to form, often with vague error messages. `debug crypto isakmp` reveals the exact mismatch. 2. **Asymmetric interesting traffic ACLs.** R1's ACL says permit `10.1/24 → 10.2/24`. R2's ACL should mirror: permit `10.2/24 → 10.1/24`. If they don't mirror, Phase 2 negotiation fails. 3. **NAT between peers without NAT-T.** IPsec ESP can't survive NAT (the integrity check fails). **NAT Traversal (NAT-T)** auto-detects NAT and switches to UDP 4500 encapsulation. Modern IOS does this automatically; older configs may need explicit enable. 4. **Routing inside the tunnel.** A site-to-site tunnel passes packets but doesn't route them — you might still need static or dynamic routes pointing to the tunnel destinations. 5. **Using DES or 3DES in 2026.** Both are broken. Use AES-256 + SHA-256+ + DH group 14+. 6. **Forgetting MTU.** ESP adds ~60 bytes per packet. If your underlying MTU is 1500, the inner packet can only be ~1440. Misconfigured systems fragment, drop, or just stop working with no clear error. Set the inner MTU appropriately or enable PMTUD. ## Lab to try tonight Use two Cisco routers in CML or any IPsec-capable simulator. 1. Configure both routers with public-IP-style interfaces (use 198.51.100.x and 203.0.113.x). 2. Configure private LANs behind each (10.1.0.0/24 and 10.2.0.0/24). 3. Without a VPN, the LANs can't ping each other across the public internet. 4. Configure the IPsec site-to-site tunnel using the commands above (mirror on the other side). 5. Ping from LAN-A to LAN-B. Should work. 6. `show crypto ipsec sa` — packets should be increasing in encrypted/decrypted counts. 7. Wireshark on the WAN side: confirm packets between the public IPs are ESP (proto 50), no inner addressing visible. 8. Bonus: configure GRE-over-IPsec instead — supports multicast, so OSPF can run inside the tunnel. ## Cheat strip | Concept | Plain English | |---|---| | **VPN** | Encrypted tunnel for private traffic over public network | | **Site-to-site** | LAN ↔ LAN, persistent. IPsec. | | **Remote-access** | One user → LAN, on-demand. SSL/TLS. | | **IKE Phase 1** | Establish trust + secure control channel | | **IKE Phase 2** | Negotiate the actual data tunnel | | **ESP (proto 50)** | Encapsulated, encrypted user data | | **NAT-T** | UDP 4500 — IPsec across NAT | | **PSK** | Pre-shared key. Simple. Use for 2 sites. | | **Certs** | Scales to many sites | | **AES-256 + SHA-256** | Sane modern defaults | | **MTU** | Tunnel adds ~60 bytes — plan inner MTU accordingly | --- ## Dynamic ARP Inspection (DAI) — https://packetmentor.com/topics/dynamic-arp-inspection/ > The Layer-2 security feature that kills ARP spoofing dead. Validates every ARP packet against the DHCP Snooping binding table — bogus replies get dropped, trust your gateway again. ## Mental model [ARP](/topics/arp/) is hilariously trusting. Any host on the LAN can broadcast *"I am 10.0.0.1, my MAC is X"* and every other host updates its ARP cache. An attacker uses this to MITM the gateway: 1. Attacker broadcasts a forged ARP: *"I am 10.0.0.1 (the gateway), my MAC is bb:bb:bb:bb (the attacker's MAC)."* 2. Every victim's ARP table updates. 3. Victims now send their outbound traffic to the attacker's MAC. 4. Attacker reads / modifies / forwards the traffic to the real gateway. Profit. **DAI fixes this by giving the switch a way to know which IP-to-MAC bindings are legitimate**, and dropping ARPs that don't match. The source of truth: the **DHCP Snooping binding table**. ## How it depends on DHCP Snooping DAI doesn't have its own database. It uses **[DHCP Snooping](/topics/dhcp-snooping/)'s** binding table, which was already populated by observing DHCP exchanges: | Client MAC | IP | Port | VLAN | |---|---|---|---| | aa:aa:aa:aa | 10.0.0.5 | Gi0/1 | 10 | | bb:bb:bb:bb | 10.0.0.7 | Gi0/3 | 10 | When an ARP packet arrives on a port: 1. DAI extracts the sender IP and sender MAC from the ARP packet. 2. Looks up the (IP, MAC, port) triple in the binding table. 3. **Match → forward normally. Mismatch → drop + log + (optional) shut the port.** This means an attacker on port Gi0/3 can claim their own IP (`10.0.0.7`), but can't claim the gateway's IP (`10.0.0.1`) because `10.0.0.1` isn't in the binding table on Gi0/3. ## Trusted vs untrusted ports Like DHCP Snooping, DAI has the concept of **trusted ports** — typically uplinks where you can't verify bindings: - **Trusted port** — ARPs pass without checking. Use only for uplinks to other trusted switches. - **Untrusted port** (default) — ARPs validated against the binding table. ## Commands ``` ! Step 1 — DHCP Snooping must be enabled first SW1(config)# ip dhcp snooping SW1(config)# ip dhcp snooping vlan 10,20 SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# ip dhcp snooping trust ! uplink ! Step 2 — Enable DAI on the same VLAN(s) SW1(config)# ip arp inspection vlan 10,20 ! Step 3 — Mark uplinks as DAI-trusted SW1(config)# interface GigabitEthernet0/24 SW1(config-if)# ip arp inspection trust ! Step 4 (optional) — Rate-limit ARP on access ports SW1(config)# interface range GigabitEthernet0/1 - 23 SW1(config-if-range)# ip arp inspection limit rate 15 ! 15 packets/sec ``` ### Static hosts (no DHCP)? Use ARP ACLs DAI fails closed by default for hosts that didn't use DHCP (servers, printers with static IPs). To explicitly whitelist them: ``` SW1(config)# arp access-list STATIC-HOSTS SW1(config-arp-nacl)# permit ip host 10.0.0.50 mac host 0050.5600.aabb SW1(config-arp-nacl)# permit ip host 10.0.0.51 mac host 0050.5600.aacc SW1(config)# ip arp inspection filter STATIC-HOSTS vlan 10 ``` ## Verification ``` SW1# show ip arp inspection SW1# show ip arp inspection vlan 10 SW1# show ip arp inspection statistics SW1# show ip arp inspection interfaces ``` `show ip arp inspection statistics` shows ARP packets forwarded, dropped, and the reason for drops — invaluable for confirming DAI is doing real work. ## Layer-2 security stack — DAI is one piece DAI is one of three Layer-2 defenses that work together: | Feature | Defends against | |---|---| | **[Port Security](/topics/port-security/)** | MAC flooding, unauthorized devices on a port | | **[DHCP Snooping](/topics/dhcp-snooping/)** | Rogue DHCP servers handing out malicious gateways | | **DAI** | ARP spoofing / poisoning attacks | | **IP Source Guard (IPSG)** | IP spoofing — only allow traffic from legit (IP, MAC, port) bindings | Deploy together for proper defense in depth. Skipping any one leaves a hole the others can't cover. ## Common mistakes 1. **Enabling DAI without DHCP Snooping.** DAI has no binding table → drops everything. Always configure DHCP Snooping first, validate it works, then add DAI. 2. **Forgetting to trust uplinks.** Without `ip arp inspection trust` on the uplink, ARPs from other trusted switches get inspected — which they shouldn't be — and many get dropped. Always trust uplinks. 3. **Rate limit too aggressive.** Default is 15 pps on access ports — plenty for normal use. If you set 2 pps, a normal client doing initial ARP discovery for printers, DNS, gateway, etc. gets err-disabled. 4. **Static-IP hosts forgotten.** A server with a static IP didn't go through DHCP → no binding → DAI drops its ARPs → server unreachable. Use ARP ACLs to whitelist. 5. **Trusting an access port.** If you accidentally `ip arp inspection trust` on a user-facing port, that user can ARP-spoof anything. Trust only uplinks. 6. **Ignoring the err-disable risk.** By default, exceeding the rate limit err-disables the port. In tight environments, this can be triggered by a misbehaving client. Pair with `errdisable recovery cause arp-inspection`. ## Lab to try tonight 1. Set up one switch, two PCs in the same VLAN, with DHCP Snooping already working. 2. Enable DAI: `ip arp inspection vlan ` + trust the uplink. 3. From PC-A, run any ARP-spoofing tool (e.g. `arpspoof` from dsniff suite) claiming to be the gateway. 4. From PC-B, run `arp -a` (Windows) or `ip neigh` (Linux). Without DAI, you'd see the attacker's MAC for the gateway. With DAI, you don't — the spoofed ARPs were dropped at the switch. 5. Check `show ip arp inspection statistics` — DAI's "drop" counter shows the blocked packets. 6. Bonus: capture on the inter-switch trunk with Wireshark. Confirm the spoofed ARPs never crossed. ## Cheat strip | Concept | Plain English | |---|---| | **DAI** | Inspects ARP packets, drops fakes | | **Binding table** | Source of truth — comes from DHCP Snooping | | **Trusted port** | ARPs pass without check — uplinks only | | **Untrusted port** | Default — ARPs validated | | **Rate limit** | Cap ARPs per second per port (default 15) | | **ARP ACL** | Whitelist static-IP hosts manually | | **Layer-2 trio** | Port Security + DHCP Snooping + DAI | | **Static hosts** | Need ARP ACL or DAI will block their ARPs | --- ## IP Source Guard (IPSG) — https://packetmentor.com/topics/ip-source-guard/ > The fourth Layer-2 security feature. Validates the source IP of every IP packet against the DHCP Snooping binding table — blocking IP spoofing attacks at the access port. ## Mental model You've configured [Port Security](/topics/port-security/) (locks the port to specific MACs), [DHCP Snooping](/topics/dhcp-snooping/) (blocks rogue DHCP servers), and [DAI](/topics/dynamic-arp-inspection/) (blocks ARP spoofing). One attack vector remains: an attacker can still send packets with a **forged source IP**. **IP Source Guard (IPSG)** plugs that hole. The switch validates the source IP of every IP packet against the DHCP Snooping binding table. If the (source IP, source MAC, port) combination doesn't match, the packet is dropped. That's it. Same source-of-truth (the DHCP Snooping binding table) shared by DAI. Different validation target (source IP, not source ARP). ## What attacks IPSG defeats - **Source IP spoofing for DDoS reflection** — attacker forges source IP to be the victim, causes amplification responses to flood victim. - **Bypassing source-IP-based ACLs** — attacker on Gi0/5 forges packets with the source IP of a trusted host on Gi0/1. - **Hiding identity in logs** — every packet correctly labeled with the attacker's actual IP. With IPSG, an attacker can only ever send packets from the IPs/MACs **legitimately bound to their port** by DHCP Snooping. ## How it builds on DHCP Snooping Same dependency as DAI. IPSG uses the DHCP Snooping binding table: | Client MAC | IP | Port | VLAN | |---|---|---|---| | aa:aa:aa:aa | 10.0.0.5 | Gi0/1 | 10 | | bb:bb:bb:bb | 10.0.0.7 | Gi0/3 | 10 | When an IP packet arrives on Gi0/3, IPSG checks the source IP against the binding entry for that port. Source 10.0.0.7? Allowed. Source 10.0.0.5 (the other user's IP)? **Dropped**. ## Two validation modes | Mode | What it checks | Strictness | |---|---|---| | **IP** | Source IP must match binding | Standard | | **IP and MAC** | Source IP AND source MAC must match | Stricter | The IP-and-MAC mode prevents an attacker from forging the source IP even if they spoof their MAC to match what's in the binding table — but it requires port-security to also be in place (which it should anyway). ## Commands ``` ! Prerequisites — DHCP Snooping must be enabled SW1(config)# ip dhcp snooping SW1(config)# ip dhcp snooping vlan 10,20 ! Enable IP Source Guard on the port SW1(config)# interface GigabitEthernet0/1 SW1(config-if)# ip verify source ! Stricter — validate IP and MAC together SW1(config-if)# ip verify source port-security ! (requires port-security configured on the same interface) ``` ### Static bindings (no DHCP) If a host uses a static IP and doesn't DHCP, you need to manually bind: ``` SW1(config)# ip source binding aaaa.bbbb.cccc vlan 10 192.168.1.50 interface GigabitEthernet0/5 ``` Without this, IPSG drops the static host's traffic — same as DAI's behavior. The DHCP Snooping binding table and the IP Source Guard binding table both work from the same data; you populate it via DHCP observation OR static entries. ## Verification ``` SW1# show ip verify source ! IPSG status per interface SW1# show ip source binding ! the binding table IPSG uses SW1# show ip dhcp snooping binding ! same table from DHCP Snooping's view ``` The first one is the daily driver — shows you which ports have IPSG enabled and which validation mode they use. ## The Layer-2 security set — IPSG completes it | Feature | Defends against | Source of truth | |---|---|---| | **Port Security** | Unauthorized MAC at access port | Static config / sticky learning | | **DHCP Snooping** | Rogue DHCP servers | Tracks legitimate leases | | **DAI** | ARP spoofing (e.g. "I am the gateway") | DHCP Snooping bindings | | **IPSG** | IP source spoofing | DHCP Snooping bindings | Three of the four depend on DHCP Snooping for their binding table. Deploy them as a set — each plugs a different hole. ## Common mistakes 1. **Enabling IPSG without DHCP Snooping.** The binding table is empty → IPSG drops everything → all access ports useless. Always enable DHCP Snooping first and confirm the binding table is populated. 2. **Forgetting static IP hosts.** Servers/printers with static IPs don't appear in the snooping bindings → IPSG drops their traffic. Add manual `ip source binding` entries. 3. **Enabling on a trunk port.** IPSG is for access ports. Trunks carry traffic from many hosts (potentially across many VLANs) — no clean binding to validate against. Don't enable on trunks. 4. **`ip verify source port-security` without enabling port-security.** The IP-and-MAC mode requires Port Security to also be active. Otherwise the MAC validation has no source. 5. **Forgetting the firewall doesn't help here.** IPSG operates at L2 on the switch. A perimeter firewall sees the same forged packets at L3 and might not detect the spoof. Defense-in-depth: filter at every layer where you can. 6. **Manual bindings forgotten after a server change.** New server, new MAC — old static binding doesn't match, IPSG drops. Update the binding when hardware changes. ## Lab to try tonight 1. Set up a switch with DHCP Snooping already working. Verify the binding table is populated. 2. Enable IPSG on an access port: `ip verify source`. 3. From a client on that port (with DHCP-assigned IP), confirm normal traffic still works. 4. Try to spoof — manually set a different IP on the client. Watch traffic drop. 5. Add a host on another port with a static IP. Without manual binding, watch IPSG drop its traffic. 6. Add `ip source binding ...` for the static host. Verify traffic flows again. 7. Bonus: enable port-security AND IPSG with `port-security` flag. Verify both IP and MAC are now checked together. ## Cheat strip | Concept | Plain English | |---|---| | **IPSG** | Drop packets whose source IP doesn't match the binding table | | **Binding source** | DHCP Snooping table — shared with DAI | | **`ip verify source`** | Standard mode — IP only | | **`ip verify source port-security`** | Stricter — IP and MAC | | **Static hosts** | Need `ip source binding ...` to be allowed | | **L2 security set** | Port Security + DHCP Snooping + DAI + IPSG = full coverage | | **Trunks** | Don't enable IPSG on them — access ports only | --- ## Cisco AnyConnect / Remote Access VPN — https://packetmentor.com/topics/anyconnect-vpn/ > How a remote user's laptop gets put 'on the corporate LAN' over the internet. Covers AnyConnect client, SSL/TLS vs IKEv2, split tunneling, authentication options, and where it fits alongside ZTNA in 2026. ## Mental model [Site-to-site VPN](/topics/vpn-basics/) connects two networks. Remote-access VPN connects **one user's device** to a network. Workflow: employee at home opens VPN client → authenticates with corporate credentials + MFA → gets a virtual IP on the corporate subnet → traffic to internal apps (SharePoint, file shares, internal web apps) flows through the encrypted tunnel. **Cisco's client used to be called AnyConnect.** In 2023 Cisco renamed it to **Cisco Secure Client** as part of unifying their endpoint products. Same software underneath — most people still call it AnyConnect. The corporate-side device that terminates the tunnel is typically a Cisco ASA (older) or Firepower FTD (newer), or for cloud-first orgs, Cisco Secure Access / Umbrella. ## SSL/TLS VPN vs IKEv2 Two underlying transport options: | | SSL/TLS VPN | IKEv2 (IPsec) | |---|---|---| | **Port** | TCP 443 (looks like HTTPS) | UDP 500 + 4500 | | **Firewall friendliness** | Excellent (TLS over 443 works through almost anything) | Sometimes blocked | | **Performance** | Slightly higher overhead | Lighter on CPU | | **Re-connection on roaming** | Slower | Faster (mobile-friendly) | | **Default in AnyConnect** | Yes — SSL/TLS by default | Configurable alternative | **Default choice for AnyConnect: SSL/TLS** — because it works through almost every firewall (looks like a regular HTTPS connection on TCP 443). IKEv2 is the better choice on mobile devices that roam frequently between Wi-Fi and cellular. ## Full tunnel vs split tunnel When the VPN is connected, which traffic goes through it? | | Full tunnel | Split tunnel | |---|---|---| | **Corp traffic** | Through VPN | Through VPN | | **Internet traffic** (Google, YouTube, Netflix) | **Through VPN** (out the corp's internet pipe) | Direct (out the user's home internet) | | **Pro** | All traffic inspected by corp security; clean compliance posture | Better performance for non-corp traffic; less load on corp WAN | | **Con** | Bandwidth cost (everything routes through HQ); user's Netflix slows down | Direct internet path = no corp inspection; if user's home network is hostile, that's a problem | Modern preference is shifting toward **split tunnel + cloud-based security** (Cisco Umbrella, Zscaler, etc.) — direct internet traffic goes through a cloud security layer rather than being backhauled to corporate. For high-compliance environments (finance, healthcare, classified), full tunnel often stays. The all-traffic-via-VPN approach makes auditing easier. ## Authentication options | Method | What it is | Common | |---|---|---| | **AD password** | LDAP / RADIUS against Active Directory | Very common | | **AD + MFA** | Password + Duo / Microsoft Authenticator / hardware token | **Standard in 2026** | | **Certificate-based** | User has a machine cert; no password | High-security environments | | **SAML / SSO** | Cisco Secure Client redirects to a corporate IdP (Okta, Azure AD) | Modern preferred for cloud-integrated environments | For CCNA: know that AnyConnect authenticates via RADIUS (likely talking to AD via Network Policy Server or similar) and that MFA is the modern standard. ## Configuration — Cisco ASA side (minimal) ``` ! Tunnel group for AnyConnect users ASA(config)# tunnel-group VPN-USERS type remote-access ASA(config)# tunnel-group VPN-USERS general-attributes ASA(config-tunnel-general)# address-pool VPN-POOL ASA(config-tunnel-general)# authentication-server-group CORP-RADIUS ! Group policy — what these users can do ASA(config)# group-policy GP-VPN internal ASA(config)# group-policy GP-VPN attributes ASA(config-group-policy)# vpn-tunnel-protocol ssl-client ASA(config-group-policy)# split-tunnel-policy tunnelspecified ASA(config-group-policy)# split-tunnel-network-list SPLIT-ACL ! ACL defining what traffic the split tunnel covers ASA(config)# access-list SPLIT-ACL extended permit ip 10.0.0.0 255.255.0.0 any ! Address pool for VPN clients ASA(config)# ip local pool VPN-POOL 10.99.99.10-10.99.99.250 mask 255.255.255.0 ! Enable AnyConnect on the outside interface ASA(config)# webvpn ASA(config-webvpn)# enable outside ASA(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.10.05085-webdeploy-k9.pkg ASA(config-webvpn)# anyconnect enable ``` User opens AnyConnect, connects to the ASA's public IP, authenticates, gets an IP in the 10.99.99.0/24 pool, can reach the 10.0.0.0/16 corporate networks (per SPLIT-ACL). ## ZTNA — the trend replacing traditional VPN Traditional VPNs grant **broad network access** — once you're in, you can probe every IP on the subnet. **ZTNA (Zero Trust Network Access)** is the modern alternative: grant access only to specific applications, on a per-session basis, after continuous verification. Cisco's ZTNA play: **Cisco Secure Access** (the rebranded / unified successor product to AnyConnect + Umbrella + various other pieces). Users access apps through a cloud broker — no broad network footprint exposed. For CCNA: know ZTNA exists as the modern alternative to VPN. AnyConnect and traditional VPN are still everywhere — won't disappear quickly. ## Common mistakes 1. **No MFA.** Username + password VPN access in 2026 is irresponsible. Phishing + credential stuffing → attacker on your VPN with full network access. Always require MFA. 2. **Default address pool exposed to all VLANs.** A VPN user gets an IP from a pool that has unrestricted access to the entire LAN → if their laptop is compromised, the attacker is now inside. Restrict VPN-pool access with ACLs. 3. **Split tunnel without DNS security.** User on split tunnel resolves DNS via their home ISP — including malicious sites. Pair split-tunnel deployments with Cisco Umbrella or similar DNS-layer security. 4. **Full tunnel with insufficient HQ bandwidth.** All employees backhaul their Netflix → corp WAN saturated. Plan for it or switch to split tunnel. 5. **Long session timeouts.** A 30-day VPN session = lost laptop = 30 days of attacker access. Set reasonable session limits + idle timeouts (8-12 hours typical). 6. **No client-posture check.** Allowing any laptop to connect — out-of-date OS, no antivirus, jailbroken. AnyConnect supports posture checking (Cisco ISE integration) — use it for high-security envs. 7. **Skipping certificate validation.** Client must validate the VPN server's TLS cert against a trusted CA. Without that, attacker can MITM the connection. Always deploy proper certs. ## Lab to try tonight If you have access to a Cisco ASA or FTD: 1. Configure a basic remote-access VPN per the config above. Use a local user database for testing. 2. Download Cisco Secure Client (free trial from Cisco's site or via DevNet sandbox). 3. Connect from your laptop to the ASA's public IP. Verify authentication. 4. Verify you got an IP in the pool. Ping internal resources. 5. Test split tunnel: ping an internal IP (goes via VPN) and `traceroute google.com` (should go via your local internet). 6. Switch to full tunnel and observe `traceroute google.com` now goes via the ASA's internet. 7. Bonus: integrate with RADIUS (FreeRADIUS works for lab) and add MFA via Duo or similar. ## Cheat strip | Concept | Plain English | |---|---| | **AnyConnect / Cisco Secure Client** | The end-user VPN client | | **ASA / FTD** | The corporate-side VPN concentrator | | **SSL/TLS VPN** | TCP 443 — works through most firewalls. Default. | | **IKEv2** | UDP 500/4500 — lighter, mobile-friendly | | **Full tunnel** | All user traffic via VPN | | **Split tunnel** | Only corp traffic via VPN | | **MFA** | Mandatory in 2026 — password alone is unacceptable | | **Address pool** | The IP range VPN clients pull from | | **Group policy** | Defines what each VPN-group can do | | **ZTNA** | Modern alternative — per-app access, not network-wide | --- ## Password Recovery & Configuration Register — https://packetmentor.com/topics/password-recovery/ > How to recover access to a Cisco router or switch when you've lost the enable password. Covers the configuration register, ROMMON, the standard CCNA recovery procedure, and the security implications of physical access. ## Mental model You inherit a router. No one knows the enable password. The previous engineer left. Telnet/SSH won't help — you can't get past login. You need physical console access plus a power cycle. The trick: tell the device to **skip loading its startup-config** when it boots. The device boots with no config (no passwords either), you log in, look at the existing startup-config (still safe in NVRAM), copy it into running-config, set a new password, save. The setting that controls boot-time behavior is the **configuration register** — a 16-bit value stored in NVRAM that the bootloader (ROMMON) reads at power-on. ## The configuration register — what each value means ``` 0x2102 ← default. Normal boot. Load IOS from flash, load startup-config. 0x2142 ← password recovery. Boot but IGNORE startup-config in NVRAM. 0x2120 ← boot into ROMMON instead of IOS. 0x0000 ← boot into ROMMON (same intent, different bits). ``` The hex bits aren't random — each bit toggles a behavior (console speed, boot source, etc.) but for CCNA you memorize the two important values. ## The password-recovery procedure — Cisco router 1. **Console in.** Cable plugged into the console port, terminal at 9600/8/N/1. 2. **Power-cycle the router.** 3. **During the first 60 seconds**, hit `Ctrl-Break` (or `Ctrl-]` then `break`, terminal-specific). This drops you into ROMMON. ``` rommon 1 > ``` 4. **Set the config-register to ignore startup-config:** ``` rommon 1 > confreg 0x2142 rommon 2 > reset ``` 5. **Device reboots, comes up with empty running-config.** No passwords. You're at the user prompt. ``` Router> Router> enable ← no password asked Router# ``` 6. **Copy the saved startup-config into running-config** (NOT the other way around — don't overwrite NVRAM yet): ``` Router# copy startup-config running-config ``` You now have the previous engineer's config running — interfaces, OSPF, ACLs, everything — but with privileged access. 7. **Change the password and reset the config-register:** ``` Router# configure terminal Router(config)# enable secret NewStrongPassword! Router(config)# config-register 0x2102 Router(config)# end Router# copy running-config startup-config Router# reload ``` Device reboots normally. You now have the working config plus the password you set. ## Password recovery — Cisco switch (Catalyst) Slightly different. Switches don't use the config-register the same way: 1. Console in. Power-cycle. 2. Hold the **Mode button** on the front panel while plugging in power. 3. Switch boots into a special menu / `switch:` prompt. 4. Run: ``` switch: flash_init switch: dir flash: switch: rename flash:config.text flash:config.text.old switch: boot ``` 5. Switch boots with no config. Press `n` on initial setup wizard. 6. Restore the config: ``` Switch> enable Switch# rename flash:config.text.old flash:config.text Switch# copy flash:config.text running-config ``` 7. Change password, write to startup-config: ``` Switch# configure terminal Switch(config)# enable secret NewPassword! Switch(config)# end Switch# write memory ``` ## The security implication **If someone has physical console access, they can take over the device.** Period. Password recovery is a designed feature of Cisco IOS. Mitigations: ### 1. Disable password recovery ``` Router(config)# no service password-recovery ``` Now if someone enters ROMMON, they cannot bypass startup-config. The device boot prompt warns: ``` PASSWORD RECOVERY FUNCTIONALITY IS DISABLED. ``` If you forget the password on a device with this set, **your only option is to wipe the device and start fresh** — losing the saved config. Use this only in high-security environments where you keep the config backed up externally. ### 2. Physical security Locked racks. Camera coverage. Console cable not left plugged in. Standard datacenter discipline. ### 3. Strong console-line authentication Console login should require AAA (RADIUS/TACACS+), so even if someone gets to the console, they need real credentials. Combined with `no service password-recovery`, you've raised the bar significantly. ## Verifying current register value ``` Router# show version ... Configuration register is 0x2102 Router# show version | include register ``` After changing in config mode, the change takes effect **on next reload** — `show version` shows the live value plus "(will be 0x2142 at next reload)". ## Common mistakes 1. **Skipping the `copy startup-config running-config` step.** You set `0x2142`, rebooted, set a new password — but you skipped loading the old config. You now have a working blank device and you've lost OSPF, interfaces, ACLs, everything. (NVRAM still has the old startup-config — `copy startup-config running-config` rescues you.) 2. **Forgetting to reset `0x2142` back to `0x2102`.** Device works fine for now, but on the next reboot it skips startup-config again — the next person sees an unconfigured device. 3. **Not writing the new password to startup-config.** `enable secret` only changes running-config. `copy running-config startup-config` makes it persist across reboots. 4. **Wrong break key.** PuTTY (Windows): `Ctrl-Break`. macOS / Linux using `screen` over a serial console (`screen /dev/tty.usbserial 9600`): `Ctrl-A` then `Ctrl-B`. macOS / Linux using `picocom`: `Ctrl-A` then `Ctrl-\`. `minicom`: `Ctrl-A` then `F` (function key F). The native macOS Terminal app has no built-in BREAK shortcut — you have to use one of the serial apps above. Look up your terminal's BREAK key beforehand. 5. **Trying password recovery remotely.** You can't. Console + physical access is required. 6. **Using `no service password-recovery` without an offline config backup.** If you ever forget the password, you have to factory-reset and rebuild. Backup the config first. ## Real-world scenario You're a new hire at a hospital network team. The previous network engineer left abruptly. There's an old 2911 router in a wiring closet that no one has the password for, but it's running OSPF and the radiology VLAN is depending on it. **Wrong move:** factory-reset it. Radiology goes down. **Right move:** schedule a maintenance window, console in, password-recover. The OSPF config and interfaces stay intact because you copy startup-config → running-config before reloading. You change the enable secret to something documented in your password vault. This is exactly the scenario this procedure is designed for. ## Lab to try tonight 1. In CML or Packet Tracer, build a router with an OSPF config and an `enable secret SecretPassword!`. 2. `write memory`, then `reload`. 3. As it boots, hit Ctrl-Break to enter ROMMON. 4. `confreg 0x2142`, `reset`. 5. Verify the router comes up with empty config. Type `enable` — no password asked. 6. `show startup-config` — your old config is still there. 7. `copy startup-config running-config` — old config comes back live. 8. `configure terminal` → `enable secret NewSecret!` → `config-register 0x2102` → `end` → `write memory` → `reload`. 9. Login with the new password. Confirm OSPF + interfaces survived. 10. Bonus: enable `no service password-recovery`. Reboot. Try the ROMMON trick — see the device refuse to bypass startup-config. ## Cheat strip | Concept | Plain English | |---|---| | **Config register** | 16-bit value in NVRAM controlling boot behavior | | **`0x2102`** | Default — normal boot | | **`0x2142`** | Boot but skip startup-config (password recovery) | | **ROMMON** | The bootloader. `rommon>` prompt. Reached via Ctrl-Break during boot | | **`confreg 0x2142` in ROMMON** | Set register for password recovery | | **`config-register 0x2102` in IOS** | Set register from configure mode | | **Copy startup → running** | Critical step — restores original config before you change password | | **Switch recovery** | Mode button + power, then rename `config.text` instead of using confreg | | **`no service password-recovery`** | Disables this — but locks you out if you ever lose the password | | **Why it matters** | Physical console = root access by design. Lock your wiring closets. | --- ## NTP Authentication & Security — https://packetmentor.com/topics/ntp-authentication/ > How to harden NTP — authentication keys, peer/client/server roles done right, ACL restrictions, and why a bad clock breaks Kerberos, TLS, logs, and forensics. ## Mental model Time is the silent dependency of every modern security protocol: - **TLS certificates** are valid only between two timestamps. A wrong clock = "certificate not yet valid" or "expired" errors. - **Kerberos tickets** are valid for ~5 minutes. Domain login dies if the clock skews more than that. - **Log correlation** during incident response is impossible if device clocks disagree. - **2FA / TOTP** codes are time-based — wrong clock, wrong code. - **Forensic timelines** in a breach investigation collapse if you can't trust the timestamps. If you can spoof NTP, you can attack all of these indirectly. That's why NTP must be authenticated and access-controlled in any serious network. If you haven't already, read [NTP basics](/topics/ntp/) first — this topic assumes you know stratum, client/server/peer mode, and the `ntp server` command. ## Three layers of NTP security | Layer | What it does | |---|---| | **1. Authentication keys** | Only servers with the right key can sync me | | **2. ACL (`ntp access-group`)** | Only specific IPs can query/sync from me | | **3. Service hardening** | Disable unused NTP modes (peer, broadcast, control queries) | You typically layer all three. ## Authentication keys — the configuration Three commands work together: ``` ! 1. Define the key (number 1, hash SHA-256, value "TheSharedSecret") R1(config)# ntp authentication-key 1 md5 TheSharedSecret ! On modern IOS-XE, also: hmac-sha256 ! 2. Mark the key as trusted (Cisco's "trust list") R1(config)# ntp trusted-key 1 ! 3. Globally enable NTP authentication R1(config)# ntp authenticate ! 4. Point at a server using that key R1(config)# ntp server 10.0.0.1 key 1 ``` All four lines required. Authentication is **enabled per packet** — the client computes HMAC over the NTP message using the key, sends the digest, and the server verifies (and vice versa). If the keys don't match, the packet is silently discarded. Clock won't sync, and `show ntp associations` shows the server as untrusted. ## The trusted-key concept — why it's separate You can define many keys but only some are "trusted" to sync from. Useful when you migrate keys: ``` R1(config)# ntp authentication-key 1 md5 OldKey R1(config)# ntp authentication-key 2 md5 NewKey R1(config)# ntp trusted-key 2 ! Only key 2 is currently trusted ``` The server uses key 1 for older clients (still works) but only newer clients with key 2 can actually drive R1's clock. ## NTP access-groups — IP-level filtering You may want NTP to **query** an internet server but never **be queried by** strangers. Four access categories: | Access type | Allows | |---|---| | **peer** | Full peer relationship (this is the strongest grant) | | **serve** | Can serve time and respond to control queries | | **serve-only** | Time queries only, no control queries | | **query-only** | Control queries only, no time sync | Recommended pattern for an enterprise NTP server: ``` ! ACL 10: trusted internal devices that can sync from us R1(config)# access-list 10 permit 10.0.0.0 0.255.255.255 ! ACL 20: nobody else (deny by default through the access-list) R1(config)# access-list 20 permit any ! 11.1: internal devices can sync our time R1(config)# ntp access-group serve-only 10 ! 11.2: nobody can do mode 6 control queries R1(config)# ntp access-group query-only 20 ``` The most common attack — **NTP amplification DDoS** — uses the `monlist` control query (mode 6/7) to amplify a small spoofed request into a huge response. `query-only` blocks that. ## Service hardening — disable what you don't use ``` ! Disable broadcast NTP (we only use server/client) R1(config)# no ntp broadcast client ! Disable peer mode if you only use server-client ! (peer is rarely needed unless you run mutual sync between cores) ! Optionally disable NTP entirely on interfaces facing untrusted networks R1(config)# interface Gi0/1 R1(config-if)# ntp disable ``` ## Topology — a real-world design ``` Internet NTP servers │ │ key 7 ┌──────────────┴──────────────┐ │ Border NTP gateway │ Stratum 2 / 3 │ (peers with two extern) │ └──────────────┬──────────────┘ │ key 1, ACL 10 ┌──────────────┴──────────────┐ │ Internal NTP core │ Stratum 3 │ (serves the whole org) │ └──────┬──────────────┬───────┘ │ key 1 │ key 1 │ │ Branch routers All switches (clients only) (clients only) ``` - Border NTP gateway holds an outside relationship; nothing else internally is allowed out to internet NTP. - All internal devices point at the internal core, key 1. - ACLs limit access to internal subnets. - A different key (key 7) protects the external relationship. ## Verification ``` R1# show ntp status Clock is synchronized, stratum 4, reference is 10.0.0.1 nominal freq is 1000.0003 Hz, actual freq is 1000.0003 Hz, precision is 2**18 R1# show ntp associations address ref clock st when poll reach delay offset disp *~10.0.0.1 .GPS. 1 23 64 377 1.234 0.022 0.450 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured R1# show ntp associations detail ... authenticated, sane, valid, master... R1# show ntp packets ``` In `show ntp associations`: - `~` next to address = configured (not auto-discovered). - `*` = currently selected as time source. - If you've enabled auth, the detail view shows `authenticated`. If auth is failing, detail shows `unauthenticated` and the server doesn't get a `*`. ## Quick troubleshooting flowchart Symptom: clocks won't sync. 1. **Reachability?** `ping ` from the device. ACL or firewall blocking UDP 123? 2. **Key value matches?** `show running-config | section ntp` on both ends. Compare `authentication-key` lines exactly (case-sensitive on the value). 3. **Trusted?** `ntp trusted-key N` set on both ends? 4. **Globally enabled?** `ntp authenticate` in the config? 5. **Pointed to the right key?** `ntp server key N` — `N` matches the trusted key? 6. **Stratum sane?** Server itself synced? Stratum >= 1 and <= 15? A stratum-16 server is "unsynchronized" — won't drive others. ## Common mistakes 1. **`ntp authentication-key` configured but `ntp authenticate` missing.** The keys exist, the server references them, but the global toggle is off — auth is disabled. Common gotcha because `ntp authenticate` looks like it might be implicit. 2. **`trusted-key` missing.** Auth is enabled, keys defined, but the key isn't trusted. Sync silently fails. 3. **Different hash algorithms.** Old IOS only supports MD5. Newer IOS-XE supports SHA-1/SHA-256/HMAC. Both ends must use the same one. 4. **Case-sensitive key value mismatch.** `MyKey` vs `mykey` won't match. 5. **Wrong key number.** Server defines key 5, client points to `ntp server 10.0.0.1 key 1`. Silent failure. 6. **Open NTP on a public-facing device.** Without ACL, your border router can be amplifier for an NTP DDoS attack. Always restrict. 7. **Trusting unauthenticated public NTP for sensitive infrastructure.** `pool.ntp.org` is unauthenticated. Fine for a home lab; not OK for the Kerberos KDC of your domain. Run your own internal stratum-2 server. 8. **Forgetting that NTP is UDP 123.** Both directions. Firewall rules must allow stateful UDP/123. ## Lab to try tonight 1. Two routers. R1 = NTP server (Stratum 2, pretend), R2 = client. 2. On R1: `ntp master 2` to make R1 a stratum-2 master. 3. On R2: `ntp server `. Check `show ntp associations` — sync should occur in ~1 minute. Note `unauthenticated`. 4. Add auth on both sides per the config block above. Use key 1, value `TheSharedSecret`. 5. Verify: `show ntp associations detail` on R2 now shows `authenticated`. 6. Change R2's key value to `WrongValue`. Watch sync break — server falls off the candidate list. 7. Restore. Add `ntp access-group serve-only 10` on R1 with an ACL that excludes R2. Verify R2 is now blocked. 8. Bonus: capture NTP traffic on R1 with `monitor capture` or in CML with PCAP — observe the auth digest field. ## Cheat strip | Concept | Plain English | |---|---| | **`ntp authentication-key N md5 VALUE`** | Define key N with hash and value | | **`ntp trusted-key N`** | Mark key N as trusted for sync | | **`ntp authenticate`** | Globally enable auth (REQUIRED) | | **`ntp server key N`** | Sync from this server using key N | | **`ntp access-group serve-only `** | Restrict who can query us | | **`monlist` query** | The classic NTP DDoS amplification — block via `query-only` ACL | | **UDP 123** | NTP port. Both directions | | **Stratum** | 0 = atomic source, 1 = primary server, ..., 16 = unsynced | | **`show ntp associations`** | Star (*) = current source; tilde (~) = configured | | **Why it matters** | TLS certs, Kerberos, logs, 2FA, forensics — all depend on accurate, trusted time | --- ## Security Program Elements: Awareness, Training, and Physical Access — https://packetmentor.com/topics/security-program-elements/ > The non-technical layers of an information-security program — user awareness campaigns, formal training, and physical access controls — that a network engineer is expected to understand alongside the firewalls and ACLs. ## Mental model Firewalls and ACLs stop packets. But most breaches don't start with a packet — they start with a person who clicked a phishing link, followed a badly-worded voicemail, or held the door for someone who looked like a delivery driver. A security **program** is the organisational scaffolding around the technical controls. The CCNA blueprint (5.2) asks you to identify the elements at a conceptual level. ## The three program elements ### 1. User awareness **Behavior nudges.** Short, frequent, repetitive. Awareness campaigns aim to change what people *do without thinking* — not what they can recite. Examples: - Monthly phishing simulations (send a fake phish, measure who clicks, feed those users into remedial training). - Screensaver locks reminding to Ctrl-L before walking away. - Poster campaigns near printers reminding to shred sensitive output. - "You just plugged in an unauthorised USB" popup from your endpoint agent. - Slack bot that flags external-recipient warnings on outgoing emails. **Success metric:** phish-click rate over time, dropped incidents (locked laptops, tailgating events). ### 2. Training **Structured curriculum with graded completion.** Every employee gets base training on onboarding; higher-privilege staff get role-specific deep dives. | Audience | Content | |---|---| | **All staff** | Company acceptable-use, data classification, phishing recognition, reporting-a-security-incident procedure | | **Developers** | Secure-coding (OWASP Top 10), secret handling, code-signing | | **IT/Network admins** | Change management, access-control principles, backup + recovery, incident response | | **Executives** | Regulatory landscape (HIPAA / PCI / SOX / GDPR), fiduciary responsibility, board-level cyber risk | | **Finance/HR** | Business email compromise (BEC) patterns, wire-transfer verification protocol | **Success metric:** completion rate, quiz pass rate, time-to-remediation on findings. ### 3. Physical access control **Keeping unauthorised people out of the rooms where the equipment lives.** This is a lot broader than "lock the door". | Layer | Example | |---|---| | **Perimeter** | Fences, gates, security guards at reception, visitor sign-in | | **Building** | Badge readers on external doors, tailgating detectors (mantraps, turnstiles) | | **Sensitive rooms** | Dual-badge (two-person) access on data-center + wiring closet doors, biometric confirm | | **Rack / equipment** | Locking cabinets, cage locks, tamper-evident seals on chassis | | **Console access** | Screen-lock timeouts, cable locks on laptops, disabled unused switch ports | | **Environmental** | HVAC + power redundancy, fire suppression (FM-200, not sprinklers over racks), water/leak sensors | | **Monitoring** | CCTV covering all entry/exit + racks, retention ≥ 90 days, integrated with badge events | **The weakest-link principle:** all your ACLs, MFA, and encryption are bypassed if someone reaches the wiring closet, plugs into the fibre trunk between distribution switches, and packet-captures the entire enterprise VLAN backbone. Physical access is often what turns a laptop theft into a full-network compromise. ## The four control types (memorise these labels — they show up on the exam) | Type | Purpose | Example | |---|---|---| | **Preventive** | Stop the incident before it happens | Locked door, ACL blocking a port, disk encryption | | **Detective** | Notice an incident in progress or after | CCTV, IDS alert, SIEM correlation rule, DHCP-snooping violation log | | **Corrective** | Restore normal operations after an incident | Backup restore, patch deployment, credential rotation | | **Compensating** | An alternate control when the primary can't be applied | Enhanced monitoring on a legacy system that can't run the current agent | You'll see these categories under different names — administrative / technical / physical is the other common taxonomy — but preventive/detective/corrective is what most CCNA-era material uses. ## The classic exam scenarios *"Which control category is a security-guard posted at the data-center entrance?"* → **Physical, preventive**. *"Which control type is a syslog server that receives all failed-login events?"* → **Detective** (technical, if the taxonomy asks). *"An employee holds the door open for someone carrying boxes. What attack pattern is this?"* → **Tailgating** (mitigated by mantraps + awareness training). *"Which program element is a monthly poster about phishing?"* → **Awareness**. *"Which is a two-hour classroom course on incident response for the SOC team?"* → **Training**. ## The #1 mistake **Treating security as a technology problem.** The most sophisticated NGFW cluster in the world doesn't stop someone from plugging a rogue AP into an unused port in the lobby, or from social-engineering the helpdesk into a password reset. The people-and-process elements — awareness, training, physical controls — are what convert your technical stack from a checkbox into an actual defense. ## Related deep-dives - [Common network attacks](/topics/common-network-attacks/) — the attack side that awareness training defends against - [Cybersecurity threats](/topics/cybersecurity-threats/) — landscape overview - [AAA](/topics/aaa/) — the technical enforcement layer for role-based access - [Port security](/topics/port-security/) — the L2 answer to "someone plugged into a port they shouldn't" --- ## Encryption Fundamentals — https://packetmentor.com/topics/encryption-fundamentals/ > The cryptography networking engineers must understand — symmetric vs asymmetric, hashing, digital signatures, certificates, and where each is used in IPsec, TLS, SSH, and 802.1X. ## Mental model Cryptography in networking solves three problems: 1. **Confidentiality** — no one in the middle can read the data. 2. **Integrity** — no one in the middle can change the data without being detected. 3. **Authentication** — the other party is who they claim to be. Each problem maps to a different cryptographic primitive: | Problem | Primitive | Example | |---|---|---| | Confidentiality | Symmetric encryption | AES | | Integrity | Hashing | SHA-256 | | Integrity + Authentication | HMAC, Digital signature | HMAC-SHA256, RSA-PSS | | Authentication at scale | Public key + PKI | TLS certificate | You won't implement these as a network engineer, but you'll configure them constantly — IPsec, TLS, SSH, 802.1X, MACsec, SNMPv3 — and you'll be the person debugging why they fail. ## Symmetric encryption **One shared secret key.** Same key encrypts and decrypts. ``` Alice + Key = Ciphertext (encrypt) Ciphertext + Key = Alice (decrypt) ``` Properties: - **Fast.** AES on modern CPUs is gigabits-per-second per core. - **Compact.** Output ≈ input size (plus a small IV/nonce). - **Problem:** how do both sides get the same key without an eavesdropper learning it? Algorithms you'll see: | Algorithm | Key sizes | Status | |---|---|---| | **AES** (Advanced Encryption Standard) | 128, 192, 256 bit | Default in 2026 | | **3DES** | 168 bit (effective 112) | Legacy — avoid | | **DES** | 56 bit | Broken — never use | | **ChaCha20** | 256 bit | Modern alternative (TLS 1.3, mobile) | For CCNA: **AES-256** is the answer to "which symmetric algorithm" in 2026. ## Asymmetric (public-key) encryption **Two mathematically linked keys.** What one encrypts, only the other decrypts. Each user has: - **Public key** — given to anyone. Used to encrypt to you, or verify your signatures. - **Private key** — kept secret. Used to decrypt to you, or sign on your behalf. ``` Alice's plaintext + Bob's public key = ciphertext (Bob is the only one who can decrypt) ciphertext + Bob's private key = Alice's plaintext ``` Properties: - **Slow.** Roughly 1000× slower than symmetric per byte. - **Big keys / signatures.** RSA-2048 = 256-byte signatures vs HMAC-SHA256 = 32 bytes. - **Solves the key-exchange problem.** No shared secret needed up front. Algorithms: | Algorithm | Typical key size | Use | |---|---|---| | **RSA** | 2048-4096 bit | Most widely deployed | | **ECDSA** (Elliptic Curve DSA) | 256-384 bit | Smaller / faster than RSA, same security | | **Ed25519** | 256 bit | Modern, very fast, used in SSH/WireGuard | | **DH / ECDH** | 2048+ / 256+ | Key **exchange** (not encryption) | ## The hybrid pattern — used by every protocol Asymmetric is too slow for bulk data. Symmetric needs a shared key. The compromise: 1. Asymmetric is used to **agree on a fresh symmetric key** (DH key exchange, or RSA wrap). 2. Symmetric (AES) is used for the actual data transfer. TLS, IPsec IKE, SSH — all do this. **First handshake = asymmetric. Then everything = symmetric.** That's why TLS is fast: only the first few packets pay the asymmetric cost. ## Diffie-Hellman — key exchange without trust Two parties agree on a shared secret over an insecure channel **without ever transmitting it**. Conceptually: 1. Public parameters: `g`, `p` (big prime). 2. Alice picks secret `a`. Sends `g^a mod p` to Bob. 3. Bob picks secret `b`. Sends `g^b mod p` to Alice. 4. Alice computes `(g^b)^a mod p`. Bob computes `(g^a)^b mod p`. Both arrive at `g^(ab) mod p` — the shared secret. An eavesdropper sees `g`, `p`, `g^a`, `g^b` — but computing `a` or `b` from these requires solving the discrete-log problem, which is computationally hard for large enough `p`. **ECDH** does the same thing with elliptic curves — same idea, smaller keys. DH groups in IPsec — bigger group number = bigger prime = stronger: - **Group 2** (1024-bit) — legacy, weak - **Group 14** (2048-bit) — minimum acceptable in 2026 - **Group 19/20/21** — elliptic curve, modern - **Group 24** (2048-bit MODP) — fine ## Hashing — integrity A **hash** maps any input to a fixed-size output deterministically and one-way: ``` SHA-256("the quick brown fox") = 9ECB36561341D18EB65484E833EFEA61EDC74B84CF5E6AE1B81C63533E25FC8F SHA-256("the quick brown fix") = E83F62C8... (totally different) ``` Properties: - **Deterministic** — same input always produces same hash. - **One-way** — can't reverse to recover input. - **Collision-resistant** — extremely hard to find two inputs with the same hash. - **Avalanche effect** — change one bit of input, ~half the output bits change. Hashes you'll see: | Hash | Output size | Status | |---|---|---| | **MD5** | 128 bit | Broken — only use for non-security checksums | | **SHA-1** | 160 bit | Deprecated since 2017 | | **SHA-256** | 256 bit | Default in 2026 | | **SHA-384 / SHA-512** | 384 / 512 bit | Higher-security variants | **HMAC** (Hash-based Message Authentication Code) combines a hash with a secret key — `HMAC-SHA256(key, message)`. Used for message integrity + authentication in IPsec, TLS, and pretty much every modern protocol. ## Digital signatures A signature proves **you wrote this**, by combining a hash with your private key: ``` Sign: signature = encrypt(hash(message), private_key) Verify: decrypted_hash = decrypt(signature, public_key) if decrypted_hash == hash(message) → valid ``` Anyone with your public key can verify. Only you (with the private key) can sign. This is how SSH host keys, TLS server certs, and code signing work. ## PKI and certificates — trust at scale If everyone has a public key, how do you know **whose** public key is whose? You can't ship them all by hand to every device. **Public Key Infrastructure (PKI)** solves this with a trust chain: 1. A **Certificate Authority (CA)** has its own keypair. Its public key is built into operating systems and browsers (the **root trust store**). 2. When you generate a keypair, you ask the CA to **sign a certificate** that says: *"This public key belongs to packetmentor.com."* 3. Anyone with the CA's public key can verify the signature → trust the binding. A certificate (X.509) contains: - Subject name (e.g., `CN=packetmentor.com`) - Public key - Issuer (the CA that signed it) - Validity dates - Extensions (allowed uses, SAN names, etc.) - The CA's signature over all of the above **Chain of trust:** ``` Root CA → Intermediate CA → packetmentor.com cert (your OS trusts root → root signed intermediate → intermediate signed leaf) ``` If any link is missing, invalid, or expired, the browser/device throws a certificate error. ## Where it shows up in networking | Protocol | What's used | |---|---| | **SSH** | Asymmetric for auth + key exchange → AES for session | | **TLS / HTTPS** | Cert (asymmetric + CA signature) → ECDHE → AES-GCM | | **IPsec (IKEv2)** | DH/ECDH key exchange → AES-256 for ESP payload, HMAC-SHA256 for ESP integrity | | **WPA2/3 (Enterprise)** | EAP-TLS uses certs; 4-way handshake derives session keys | | **SNMPv3** | HMAC-SHA for auth, AES for privacy | | **OSPFv2 auth** | HMAC-SHA | | **BGP TCP-AO / MD5** | HMAC over TCP session | | **MACsec** | AES-128-GCM at Layer 2 | For CCNA you don't need to implement these — but you should recognize each acronym and know what it provides. ## Common mistakes 1. **Calling encryption "secure" without thinking about authentication.** Encrypted but unauthenticated channels are vulnerable to MITM. You always need both (TLS gives you both; vanilla AES alone does not). 2. **Mixing MD5 / SHA-1 with security in 2026.** Both are deprecated. Use SHA-256 minimum. MD5 is fine as a non-security checksum (image integrity vs published Cisco MD5 is OK — but for crypto, no). 3. **Self-signed cert == "encrypted but not trusted".** Encryption works; identity is unverifiable. Browsers warn for a reason. 4. **Confusing key length with security level.** RSA-2048 ≈ ECDSA-256 ≈ AES-128 in actual security. Asymmetric needs bigger keys than symmetric to achieve the same level. 5. **Weak DH groups in IPsec.** Group 2 (1024-bit) is breakable by nation-state actors. Use Group 14 (2048) at minimum, or ECDH Group 19+ (modern). 6. **Encrypting then signing vs signing then encrypting** — there are subtle replay/identity attacks if you do it wrong. Stick with audited protocols (TLS, IPsec) and don't roll your own. 7. **Storing private keys in plain text.** Network device private keys (SSH host key, TLS cert) live on flash. If someone gets `copy flash: tftp:`, they get the keys. Use encrypted storage and access controls. ## Lab to try tonight 1. Generate an RSA keypair on your laptop: `ssh-keygen -t rsa -b 4096`. Look at the public/private key files — note the size difference. 2. On a Cisco router: `crypto key generate rsa modulus 2048`. Verify with `show crypto key mypubkey rsa`. 3. SSH to the router. Note the key fingerprint warning the first time. Investigate where SSH stores the host-key fingerprint (`~/.ssh/known_hosts`). 4. On your laptop: `openssl s_client -connect google.com:443 -showcerts`. Walk the cert chain (leaf → intermediate → root) and find each issuer. 5. `openssl dgst -sha256 some-file` — compute a hash. Change one byte of the file, hash again, observe avalanche effect. 6. Bonus: configure IPsec site-to-site between two routers using both pre-shared key and certificate-based authentication. Compare configs. 7. Bonus: try `nmap --script ssl-enum-ciphers -p 443 example.com` to see what crypto a real server negotiates. ## Cheat strip | Concept | Plain English | |---|---| | **Confidentiality** | No one can read = encryption (AES) | | **Integrity** | No one can tamper undetected = hashing (SHA-256) + HMAC | | **Authentication** | Other side is who they claim = signatures / certs / PSK | | **Symmetric** | One shared key. Fast. Bulk data. AES | | **Asymmetric** | Public + private keypair. Slow. Bootstrap trust. RSA, ECDSA | | **DH / ECDH** | Key *exchange* — derive shared secret over an open channel | | **HMAC** | Hash + secret key = authenticated integrity | | **Digital signature** | Hash + private key. Verify with public key | | **Certificate** | Public key + identity, signed by a CA | | **PKI** | The whole trust infrastructure: CAs, certs, revocation, validation | | **AES-256** | Default in 2026 for symmetric | | **SHA-256** | Default in 2026 for hashing | | **MD5 / SHA-1** | Legacy. Avoid for security. | | **TLS / IPsec / SSH** | All use the hybrid pattern — asymmetric to bootstrap, symmetric to bulk | --- ## DHCP Relay & IP Helper — https://packetmentor.com/topics/dhcp-relay/ > How the ip helper-address command forwards DHCP DISCOVER broadcasts across Layer 3 boundaries so one DHCP server can serve many VLANs. Includes Option 82, the GIADDR field, and the relay troubleshooting flow. ## Mental model The DHCP DORA exchange (DISCOVER → OFFER → REQUEST → ACK — see [DHCP](/topics/dhcp/)) starts with the client knowing nothing — no IP, no gateway, no DNS. It sends a **broadcast** to `255.255.255.255` saying *"any DHCP server out there, please give me an address."* Broadcasts don't cross routers. So if your client is in VLAN 10 (`192.168.10.0/24`) and your DHCP server lives in VLAN 99 (`192.168.99.0/24`), the broadcast dies at the first router/L3-switch boundary. You have two options: 1. **Run a DHCP server in every VLAN.** Awful — 50 servers to manage for 50 VLANs. 2. **Configure the router/L3-switch to relay DHCP broadcasts to a central server.** Option 2 is what every real network does. The configuration command is `ip helper-address` — a single line per interface. ## The relay flow ``` VLAN 99 (192.168.99.0/24) DHCP Server 10.99.99.5 ▲ │ Unicast OFFER/ACK to 192.168.10.1 (GIADDR) │ ┌──────┴──────┐ │ L3 Switch │ "ip helper-address 10.99.99.5" on Vlan10 │ SVI Vlan10 = 192.168.10.1 │ └──────┬──────┘ │ │ Broadcast DISCOVER from VLAN 10 ▼ ┌──────────┐ │ Client │ PC in VLAN 10, no IP yet └──────────┘ ``` Step-by-step: 1. **Client broadcasts DISCOVER** to `255.255.255.255`. 2. **L3 switch / router receives** on the VLAN 10 SVI. Because of `ip helper-address`, it doesn't drop the broadcast. 3. **Relay stamps GIADDR** = `192.168.10.1` (its own SVI IP for that VLAN). Unicasts the (now slightly modified) DHCP DISCOVER to `10.99.99.5`. 4. **DHCP server uses GIADDR** to find the right scope (the `192.168.10.0/24` pool). Allocates an IP. Builds an OFFER. Unicasts it back to `192.168.10.1` (the GIADDR). 5. **Relay receives the OFFER** and broadcasts it into VLAN 10 (or unicasts, depending on the BROADCAST flag in the request). 6. **Client sends REQUEST** (also broadcast) → relay forwards as before. 7. **Server sends ACK** → relay forwards. The client never knows it's been relayed. To it, everything looks like a normal DORA — just with the gateway helping it find the server. ## The config — one line ``` SW1(config)# interface Vlan10 SW1(config-if)# ip helper-address 10.99.99.5 ``` That's the whole feature. You can have **multiple helper addresses** per interface: ``` SW1(config-if)# ip helper-address 10.99.99.5 SW1(config-if)# ip helper-address 10.99.99.6 ``` The relay sends the DISCOVER to both. Whichever DHCP server answers first wins the race. Useful for DHCP redundancy. ## What else `ip helper-address` forwards Surprise — `ip helper-address` doesn't only forward DHCP. It forwards a list of UDP broadcasts: | Port | Protocol | |---|---| | 37 | Time | | 49 | TACACS | | 53 | DNS | | **67** | **DHCP / BOOTP server** | | **68** | **DHCP / BOOTP client** | | 69 | TFTP | | 137 | NetBIOS Name | | 138 | NetBIOS Datagram | You can tune the list with `ip forward-protocol udp ` (add) or `no ip forward-protocol udp ` (remove). Most engineers leave defaults and forget about it — until they wonder why TFTP boot requests are being relayed unexpectedly. To **disable** all UDP forwarding except DHCP: ``` SW1(config)# no ip forward-protocol udp 37 SW1(config)# no ip forward-protocol udp 49 SW1(config)# no ip forward-protocol udp 53 SW1(config)# no ip forward-protocol udp 69 SW1(config)# no ip forward-protocol udp 137 SW1(config)# no ip forward-protocol udp 138 ``` DHCP (67/68) is always forwarded when `ip helper-address` is set. ## GIADDR — the field that makes it work The DHCP server is single-armed (one IP, in VLAN 99). How does it know to allocate from the VLAN 10 scope rather than VLAN 99? The relay stamps **GIADDR** (Gateway IP Address) in the BOOTP header before forwarding. The server reads GIADDR, finds the matching scope (the pool whose subnet contains GIADDR), allocates an IP from there. This is why **the relay's IP on the client-side interface matters** — it must be inside the scope subnet on the DHCP server. If you have multiple IPs (HSRP virtual + real), you can tell the relay which to stamp: ``` SW1(config-if)# ip dhcp relay information option vpn SW1(config-if)# ip dhcp relay source-interface Loopback0 ``` Usually unnecessary; defaults work for 95% of deployments. ## Option 82 — DHCP relay information The relay can also insert **Option 82** into the relayed DISCOVER — extra metadata like: - The relay's interface name (which switch port the client came in on) - The relay's MAC / IP - A "Remote ID" identifying the client circuit DHCP servers can use Option 82 for: - Per-port IP assignment (every client on a given switch port gets the same IP) - Audit / abuse tracking - Securing against rogue DHCP servers ``` SW1(config)# ip dhcp relay information trust-all ! trust upstream Option 82 SW1(config-if)# ip dhcp relay information option ! insert Option 82 ``` Pairs nicely with [DHCP Snooping](/topics/dhcp-snooping/). ## Verification ``` SW1# show ip interface Vlan10 | include Helper Helper address is 10.99.99.5 SW1# show ip dhcp relay statistics DHCP Relay Statistics: Relay Messages: 142 ... SW1# show ip dhcp server statistics ! if server is on a Cisco device SW1# debug ip dhcp server packet ! debug-level — careful in production ``` From the client side (Windows): ``` ipconfig /release ipconfig /renew ipconfig /all ! check the obtained values + scope ``` From a captured packet — open Wireshark, filter `bootp` or `dhcp`, look at the BOOTP header GIADDR field. If it's `0.0.0.0`, no relay happened. If it's `192.168.10.1`, relay worked. ## Common mistakes 1. **No `ip helper-address` configured.** Clients in remote VLANs sit in APIPA range (169.254.x.x). The most common cause of "DHCP doesn't work for that VLAN." 2. **Helper points at the wrong server IP.** Pointing at the wrong machine = silent failure. Verify the server has a working scope for the relay's subnet. 3. **Server has no scope for the relayed subnet.** Server receives the relayed DISCOVER but has no pool matching GIADDR's subnet → silently drops. Common after VLAN renumbering. 4. **Routing missing between relay and server.** The OFFER unicast from server to relay must be routable. A firewall between VLAN 99 and VLAN 10's gateway must permit UDP 67/68. 5. **Forgetting both directions.** DHCP needs round-trip — server's UDP 67 traffic must reach the relay too. 6. **`ip helper-address` on the wrong interface.** It must be on the **client-facing** SVI/interface, not the server-facing one. 7. **Multiple servers with overlapping scopes.** Both servers offer; client takes the fastest. If scopes overlap or contradict, you get inconsistent assignments. Configure split scopes or HA properly. 8. **Forgetting Option 82 + DHCP Snooping interaction.** If you enable DHCP Snooping on the switch and the upstream switch is the relay, Option 82 insertion can cause the server to reject — needs `trust-all` or matching configs. ## Lab to try tonight 1. Build: client in VLAN 10, L3 switch as gateway, DHCP server in VLAN 99 (could be a Cisco router with `ip dhcp pool`, a Windows server, or `dnsmasq` on a Linux VM). 2. Without `ip helper-address`: client gets APIPA. Verify with `ipconfig`. 3. Add `ip helper-address ` to the VLAN 10 SVI. Client `ipconfig /renew` → gets IP from VLAN 10 scope. 4. Capture with `monitor capture` on the L3 switch (or Wireshark on a SPAN port). Verify GIADDR is the SVI IP. 5. Stop the DHCP server. `show ip dhcp relay statistics` — relay messages still increment (it tries) but no replies. Client falls back to APIPA after lease times out. 6. Add a second helper-address pointing at a second server. Both should appear in `show ip interface Vlan10 | section Helper`. 7. Bonus: enable Option 82 (`ip dhcp relay information option`). Capture again — Option 82 sub-options visible in the DISCOVER frame. 8. Bonus: enable DHCP Snooping. Observe how snooping cooperates with the relay (or doesn't, if Option 82 trust isn't configured). ## Cheat strip | Concept | Plain English | |---|---| | **DHCP DISCOVER is broadcast** | Stops at routers. Need a relay agent on the other side. | | **`ip helper-address `** | The single command that enables DHCP relay | | **GIADDR** | Gateway IP Address field — relay stamps this for server to pick scope | | **Where to put it** | On the **client-facing** gateway interface (SVI for L3 switch) | | **Multiple helpers allowed** | Yes — first server to respond wins | | **Default forwards** | DHCP + DNS + TFTP + TACACS + NTP — tune with `ip forward-protocol udp` | | **Option 82** | Relay-inserted metadata for fine-grained policy | | **Round-trip routing required** | Server-to-relay path must work too | | **Where it fits** | Every multi-VLAN network with a central DHCP server (which is most of them) | --- ## Password Policy: Management, Complexity, MFA, Certificates, Biometrics — https://packetmentor.com/topics/password-policy/ > Modern authentication has moved past 'strong passwords'. The elements of a real-world password policy — length + complexity, rotation, MFA, certificate-based auth, and biometrics — and where Cisco IOS supports each. ## Mental model Password strength alone stopped mattering years ago. Attackers dump hash databases, rent GPUs, and brute-force at billions of hashes per second. Real security comes from layering: something you know (password), plus something you have (phone / token / certificate), plus something you are (biometric). For the CCNA, you'll be asked to identify the layers of a "modern" policy — not to memorise a specific vendor's product. ## The layers of a modern password policy | Layer | What it does | Cisco IOS support | |---|---|---| | **Length + complexity** | Longest single factor; a 16-char passphrase is ~2^80 harder than 8-char complex | `security passwords min-length 12` | | **Rotation** | Force change on cadence (30/60/90 days) — NIST 800-63B (2017) actually *discourages* mandatory rotation unless there's evidence of compromise | `username X secret 5 ` per user; TACACS/RADIUS backend handles cadence | | **History / no-reuse** | Don't accept the last N passwords | Backend AAA (TACACS+/RADIUS) — IOS doesn't store history natively | | **Lockout on failure** | Freeze the account after N wrong tries | `login block-for attempts within ` | | **Encryption at rest** | Passwords never stored in plaintext | `service password-encryption` (weak, Type 7) or `enable secret` (Type 5/8/9 hashed) | | **MFA / 2FA** | Add "something you have" | RADIUS to a backend that speaks TOTP / push (Duo, Cisco ISE, Okta) | | **Certificates** | Public/private keypair replaces password | `crypto pki` for VPN + SSH pubkey auth | | **Biometrics** | Fingerprint / face — usually paired with a certificate | Endpoint (laptop / phone), not the network device | | **Passwordless (FIDO2/WebAuthn)** | Hardware-backed keypair per site | Endpoint OS + IdP; not a device-CLI concern | ## What NIST 800-63B says today (2017 revision) - **Length ≥ 8** (12+ recommended for admin accounts). - **No mandatory periodic rotation** unless compromise is suspected. - **No enforced complexity rules** (e.g., "must have a symbol") — they push users to predictable substitutions. - **Block common passwords** — check against known-breached lists (Have I Been Pwned, RockYou). - **Enable MFA** for anything privileged or remote-accessible. Older policies you'll still see on the exam (rotate every 90 days, require symbol/upper/number) exist in Cisco's blueprint for historical continuity but the NIST modern guidance is the direction the industry is moving. ## Real Cisco IOS knobs ``` ! Minimum length on all newly-configured passwords R1(config)# security passwords min-length 12 ! Lockout: 3 wrong tries within 60 seconds → block logins for 300 seconds R1(config)# login block-for 300 attempts 3 within 60 ! Log every failed login (populates syslog for SIEM correlation) R1(config)# login on-failure log ! Log every successful login (audit trail) R1(config)# login on-success log ! Store enable password as a Type-5 MD5 hash (not the weak Type-7) R1(config)# enable secret NeverT3llMe ! User accounts — always use `secret` (hashed), not `password` (Type-7-reversible) R1(config)# username admin privilege 15 secret Sup3rL0ngPassphrase ! Encrypt Type-7 passwords already stored in config R1(config)# service password-encryption ! SSH pubkey auth for a user (certificate-adjacent — no password needed) R1(config)# ip ssh pubkey-chain R1(config-ssh-pubkey)# username admin R1(conf-ssh-pubkey-user)# key-string R1(conf-ssh-pubkey-data)# AAAAB3NzaC1yc2EAAA... R1(conf-ssh-pubkey-data)# exit ``` ## MFA on Cisco: the RADIUS / TACACS+ handoff Cisco IOS itself doesn't do TOTP or push-approval. The pattern is: 1. IOS uses `aaa authentication login default group RADGROUP local`. 2. Login attempts hit a RADIUS server (Cisco ISE, Duo Auth Proxy, Aruba ClearPass). 3. That server does the MFA challenge — TOTP code, phone push, hardware key. 4. Only if MFA passes does RADIUS respond `Access-Accept` and IOS lets you in. The relevant CCNA topic page is [AAA](/topics/aaa/) — it covers TACACS+ / RADIUS server config in depth. ## Password vs `secret` vs Type-5 vs Type-7 vs Type-8/9 | Type | Command | Storage | Strength | Notes | |---|---|---|---|---| | Type-0 (plaintext) | `enable password` | Cleartext | None | Never use | | Type-7 (Vigenere) | `password 7 ...` (after `service password-encryption`) | Reversible with online tools | None | Obfuscation only | | Type-4 (SHA-256, no salt) | `enable secret 4` (deprecated by Cisco 2013) | Hashed | Weak | Deprecated | | Type-5 (MD5 + salt) | `enable secret X` (default older IOS) | Hashed + salt | Medium | Legacy default | | Type-8 (PBKDF2 SHA-256) | `enable secret 8 ...` (IOS 15.3+) | Hashed + salt + iterations | Strong | Prefer this | | Type-9 (scrypt) | `enable secret 9 ...` (IOS 15.3+) | Hashed + memory-hard | Strong | Prefer this | Rule: use Type-8 or Type-9 on any modern IOS device. If you must fall back, Type-5 is the last acceptable choice. ## The #1 mistake **"Complexity = security."** `Password1!` satisfies the classic Cisco default template — uppercase, digit, symbol — but is guessable in seconds. A 20-character passphrase like `correct-horse-battery-staple-42` has vastly more entropy and is easier for a human to remember. Length beats symbols; length + MFA beats everything. ## Quick verification ``` R1# show login Login state and configuration information: Secure Login is enabled Quiet-Mode is enabled Block-for state is enabled Login-attempts allowed: 3 Login-quiet-time: 300 seconds Ongoing login-time is 60 seconds R1# show running-config | include enable|secret|username|login security passwords min-length 12 enable secret 8 $8$Fkkw3ISPRQEmiE$/PqxlP... login block-for 300 attempts 3 within 60 login on-failure log login on-success log username admin privilege 15 secret 8 $8$Ax... ``` --- ## WAN Connection Types — https://packetmentor.com/topics/wan-connection-types/ > The connection types you'll actually meet at branch sites — leased lines, Metro Ethernet, MPLS L3VPN, broadband (cable / DSL / FTTH), wireless (LTE/5G), and how SD-WAN ties them together. ## Mental model A WAN is anything that connects sites farther apart than you can run your own cable. You rent from a carrier — and the rental terms shape everything else: bandwidth, SLA, predictability, cost, security. Every WAN choice trades off three things: 1. **Bandwidth + symmetry** — how many Mbps each way, and is upload as fast as download? 2. **SLA + jitter** — guaranteed latency / packet loss / uptime, or best-effort? 3. **Cost per Mbps** — leased lines bill by dedicated capacity; broadband bills by tier; LTE bills by data usage. CCNA blueprint covers the major categories at a recognition level — you should know which is which and when each fits. ## The six categories ### 1. Dedicated leased lines (T1 / E1 / SONET / DS3) **The old guard.** Point-to-point copper or fiber from carrier between two of your sites. Dedicated bandwidth, end-to-end SLA. | Type | Bandwidth | Region | |---|---|---| | T1 | 1.544 Mbps | N. America | | E1 | 2.048 Mbps | Europe / RoW | | T3 / DS3 | 44.736 Mbps | N. America | | OC-3 | 155 Mbps | SONET | | OC-12 | 622 Mbps | SONET | | OC-48 | 2.5 Gbps | SONET | - **Pros:** Hard SLA, predictable latency, fully private. - **Cons:** Expensive, fixed bandwidth, slow to provision (weeks). - **2026 reality:** Mostly being retired in favor of Metro Ethernet. You'll still find T1/E1 at small branches, remote sites, and in legacy industries. ### 2. Metro Ethernet (MetroE) Ethernet handoff from a carrier. Looks like a regular RJ45/SFP port, but the other end is hundreds of km away. Three flavors (MEF specifications): | Service | What it provides | |---|---| | **E-Line** | Point-to-point. Like a wire between two sites. | | **E-LAN** | Multipoint-to-multipoint. Like a bridged LAN across cities. | | **E-Tree** | Hub-and-spoke (root + leaves). | - **Pros:** Easy — your edge switch just plugs in. SLA from carrier. Faster to provision than T1. - **Cons:** More expensive than broadband, requires single carrier across your footprint. - **2026 reality:** Default WAN choice for mid-sized enterprises that want SLA but don't want MPLS complexity. ### 3. MPLS L3VPN Covered fully in [MPLS Basics](/topics/mpls-basics/). The carrier runs MPLS internally; you peer with their PE routers from each of your sites. Carrier provides VRF-isolated routing across all your sites. - **Pros:** Multi-site any-to-any without you running BGP. SLA. QoS. Mature. - **Cons:** Expensive ($/Mbps), single-carrier lock-in, slow to add new sites. - **2026 reality:** Still common in large enterprises, but losing share to SD-WAN-over-broadband. ### 4. Broadband (Cable / DSL / FTTH) Consumer-style internet. You buy a connection like a residential user, but you're sharing infrastructure with neighbors. | Type | Typical speeds | How it works | |---|---|---| | **Cable** (DOCSIS) | 100 Mbps – 2 Gbps down / 20-200 Mbps up | Coax shared in neighborhood | | **DSL** (ADSL / VDSL) | 5-100 Mbps / 1-20 Mbps | Copper telephone pair | | **FTTH** (fiber to home) | 100 Mbps – 10 Gbps symmetric | Fiber to your premises | - **Pros:** Cheap, fast to install, often symmetric (fiber) at high speeds. - **Cons:** Best-effort — no SLA. Asymmetric on cable/DSL (download fast, upload slow). Shared bandwidth. - **2026 reality:** The hidden backbone of SD-WAN deployments. Two cable modems + LTE backup = cheaper and faster than one MPLS at most branches. ### 5. Wireless WAN (LTE / 5G / fixed wireless) Carrier cellular as the transport. | Type | Typical speeds | Latency | |---|---|---| | **LTE / 4G** | 20-150 Mbps down / 10-50 Mbps up | 40-80 ms | | **5G** (sub-6) | 100 Mbps – 1 Gbps | 20-40 ms | | **5G** (mmWave) | 1-3 Gbps | 5-20 ms | | **Fixed Wireless** | 50 Mbps – 1 Gbps | 20-40 ms | - **Pros:** No cabling. Fast to deploy (just bring up a SIM). Geographic flexibility. - **Cons:** Data caps. Coverage variability. Often expensive per GB. - **2026 reality:** Used as backup links, pop-up sites, temporary deployments, vehicle fleets, and where wired isn't feasible. ### 6. Satellite The last-resort tier — Starlink (LEO), Viasat / HughesNet (GEO). | Type | Typical speeds | Latency | |---|---|---| | **LEO** (Starlink) | 100-300 Mbps | 30-60 ms | | **GEO** | 25-100 Mbps | 600+ ms | - **Pros:** Works literally anywhere. - **Cons:** GEO latency is brutal. LEO (Starlink) much better but still subject to weather and limited capacity. - **2026 reality:** Maritime, offshore oil/gas, polar research, disaster recovery — anywhere wired isn't an option. ## PPP and PPPoE — link-layer for some of these Several WAN technologies use **PPP** (Point-to-Point Protocol) at Layer 2: - **Leased lines** (T1/E1) commonly use PPP or HDLC. - **DSL** uses **PPPoE** (PPP over Ethernet) — wraps PPP inside Ethernet so the DSL modem can authenticate to the ISP. A typical PPPoE setup on Cisco IOS: ``` R1(config)# interface Dialer0 R1(config-if)# encapsulation ppp R1(config-if)# ip address negotiated R1(config-if)# dialer pool 1 R1(config-if)# ppp authentication chap callin R1(config-if)# ppp chap hostname acme123@isp.com R1(config-if)# ppp chap password 7 SecretPwd R1(config)# interface Gi0/1 R1(config-if)# pppoe-client dial-pool-number 1 ``` For CCNA, you should recognize the PPPoE concept and the basic config — full PPP tuning is beyond CCNA scope. ## SD-WAN — making the choice flexible If you read [SD-WAN Concepts](/topics/sd-wan-concepts/), you'll recognize the pattern: instead of picking *one* WAN type, you pick *several* and let SD-WAN do app-aware path selection. Common 2026 branch pattern: - **One MPLS** (for SLA-bound voice/video) - **One broadband** (cheap bulk, SaaS direct break-out) - **One LTE** (backup, never-down) SD-WAN treats all three as fungible transports for the overlay tunnels. Voice goes over MPLS. SaaS goes direct over broadband. If MPLS dies, voice falls over to broadband (with QoS degradation but no outage). If broadband dies too, everything fails over to LTE. This is the **why** of modern SD-WAN — diverse WAN transports become a feature, not a complication. ## Quick comparison | Type | Bandwidth range | SLA | Cost/Mbps | Provisioning time | Use case | |---|---|---|---|---|---| | Leased line | 1.5 Mbps – 2.5 Gbps | Yes | Highest | Weeks | Legacy, regulated, small branches | | Metro Ethernet | 10 Mbps – 100 Gbps | Yes | High | Days-weeks | Default enterprise mid-tier | | MPLS L3VPN | 1 Mbps – 100 Gbps+ | Yes | High | Weeks | Large enterprise multi-site | | Broadband | 5 Mbps – 10 Gbps | No (best effort) | Low | Days | SD-WAN underlay, SaaS direct | | Wireless (LTE/5G) | 10 Mbps – 1 Gbps | Limited | Medium | Hours | Backup, pop-up, mobility | | Satellite (LEO) | 50-300 Mbps | Limited | Medium-high | Days | Remote / maritime | ## Selecting a WAN — questions to ask 1. **How much bandwidth do I need?** Real measurement, not vendor wishful thinking. 2. **What apps run on this link?** Latency-sensitive (voice, real-time trading) needs an SLA-backed link. 3. **What's my tolerance for downtime?** Need 99.99%? Get two transports from two different carriers. 4. **What's the budget?** MPLS is 5-15× more expensive per Mbps than broadband. 5. **How fast must I deploy?** New site opening in 2 weeks → broadband + LTE backup, not MPLS. 6. **Will I use SD-WAN?** If yes, pick diverse cheaper transports. If no, pick one premium link. ## Common mistakes 1. **Single transport, no backup.** One link, no failover. Eventually it goes down for hours. Always have a second path — even if it's an LTE modem. 2. **Assuming broadband upload = broadband download.** Cable / DSL are asymmetric. A "1 Gbps cable" might only upload at 30 Mbps. Matters a lot for backups, video calls, cloud uploads. 3. **Buying "MPLS" thinking it's encrypted.** It's not. MPLS provides traffic separation, not confidentiality. If you need encryption, layer IPsec on top. 4. **Ignoring jitter when picking broadband for voice.** Bandwidth might be fine, but if your cable modem occasionally has 50ms jitter spikes, voice quality tanks. Test before deploying. 5. **Putting LTE on a billable data plan with no monitoring.** A misbehaving WAN backup chewing through 50 GB/day will produce surprise bills. Configure SD-WAN to use LTE only on failover. 6. **Single carrier across all sites.** That carrier has one regional outage and every site is down at once. Diversify. 7. **Forgetting cabling at the new site.** Telco hands you a 100 Mbps Metro-E. Your IDF doesn't have a fiber patch. Bring a real installer to survey. ## Lab to try tonight This is a hard topic to lab directly — most folks don't have leased lines in their garage. But you can: 1. Look up your own internet connection in `traceroute` and note the first 3-4 hops — that's your ISP's edge network. 2. Compare `mtr` results between cable, LTE-tethered phone, and Wi-Fi. Note jitter differences. 3. In GNS3/CML, build a PPPoE client/server pair — practice the config until it's muscle memory. 4. Configure two routers as if they were a small enterprise + branch: one router speaks PPP/HDLC to the other. Bring up the link, watch CHAP authentication. 5. Use a public looking glass (e.g., `lg.he.net`) to traceroute between cities — see real-world carrier paths. 6. Compare cost per Mbps of your home internet vs a public quote for MPLS in your area — eye-opening. ## Cheat strip | Type | One-line characterization | |---|---| | **Leased line (T1/E1/SONET)** | Dedicated copper/fiber, fixed bandwidth, SLA. Legacy default. | | **Metro Ethernet** | Carrier hands you Ethernet across cities. E-Line / E-LAN / E-Tree | | **MPLS L3VPN** | Carrier-managed VRF mesh. SLA + any-to-any. | | **Broadband** | Cable / DSL / FTTH. Cheap, no SLA. SD-WAN's favorite. | | **Wireless (LTE/5G)** | No cabling. Backup or pop-up. Watch data caps. | | **Satellite (LEO/GEO)** | Anywhere on Earth. LEO finally usable; GEO has 600ms latency. | | **PPP / PPPoE** | Layer 2 framing for leased lines and DSL respectively | | **SD-WAN's value** | Combine multiple cheap transports into one resilient logical WAN | | **CCNA depth** | Recognize each, know SLA vs best-effort, know when each fits | --- ## Hierarchical Network Design — https://packetmentor.com/topics/hierarchical-network-design/ > Cisco's three-tier model — Access, Distribution, Core — and the design principles that have built every campus network for 25 years. When to collapse the core, where to put redundancy, and why hierarchical design beats flat networks every time. ## Mental model A flat network — every switch is the same, every link is the same — works fine for 10 hosts. At 100 it's painful. At 1000 it's a disaster: broadcast storms, unpredictable performance, no clear failure domain, every change touches everything. Cisco's answer is **hierarchical design** — split the network into layers, each with one job: ``` Internet / Data Center │ ┌───────┴───────┐ │ CORE │ High-speed transit only └───┬───────┬───┘ │ │ ┌───────┴───┐ ┌─┴───────┐ │ DIST │ │ DIST │ Aggregation + L3 boundary + policy └───┬──┬───┘ └───┬──┬───┘ │ │ │ │ ┌─────┴┐┌┴────┐┌──┴┐┌┴────┐ │ ACC ││ ACC ││ ACC ││ ACC│ User-facing — switchports for clients └─────┘└─────┘└─────┘└─────┘ │ │ │ │ └──┴──hosts──┴──┘ ``` This three-tier (or "campus") model is what 95% of enterprise networks use. The CCNA exam tests it directly — knowing the layer responsibilities and design choices is required. ## The three layers — one job each ### Access Layer **Job:** connect end-users (and IoT, APs, phones, cameras) to the network. Characteristics: - One switch per ~24–48 user ports. - Layer-2 only (most designs). VLANs live here; the SVI/gateway is on Distribution. - Lots of features: PortFast + BPDU Guard, PoE, Voice VLAN, port security, 802.1X, DHCP Snooping. - Failure of one access switch isolates 24–48 users — bounded blast radius. What you do NOT do at access: - Route. (Mostly. Some recent designs push routing down — see "Routed access" below.) - Connect users directly to multiple distributions (single uplink is fine if redundancy is at the dist+core layer). ### Distribution Layer **Job:** aggregate access switches, handle inter-VLAN routing, apply policy. Characteristics: - Layer-3 boundary. SVIs for each VLAN live here. - FHRP (HSRP / VRRP / GLBP) for gateway redundancy — see [FHRP comparison](/topics/fhrp-comparison/). - ACLs, QoS marking, route filtering. - Two per "distribution block" — paired for redundancy. Each access switch dual-homed to both. - Routing protocols summarize prefixes northbound (one /20 instead of 16 /24s — see [Route Summarization](/topics/route-summarization/)). - ~100 Gbps aggregate capacity per pair is typical in 2026. ### Core Layer **Job:** move traffic between distribution blocks at line rate. Nothing else. Characteristics: - Highest-speed switches in the building. 40 / 100 / 400 Gbps interfaces. - **No user ports.** No policy. No filtering. Just forwarding. - Two switches, fully meshed with each distribution pair → no single point of failure. - Often runs OSPF or EIGRP between cores and distribution; sometimes BGP if connecting to a WAN/DC fabric. - Reachable from every distribution pair via diverse paths. The core is intentionally **simple** — keep it stable, keep it fast, don't touch it. ## Two-tier ("collapsed core") For small/medium sites — say, ≤200 access ports, single building, single floor or two — you may not need a dedicated core. Distribution and core merge into one layer: ``` Internet / WAN │ ┌────────┴────────┐ │ COLLAPSED CORE │ Aggregation + routing + transit in one layer └───┬────┬────┬───┘ │ │ │ ┌───┴┐ ┌─┴┐ ┌─┴───┐ │ACC │ │ACC│ │ ACC │ └────┘ └──┘ └─────┘ │ │ │ hosts hosts hosts ``` Same design principles, fewer boxes. Move to three-tier when: - You're outgrowing the box's capacity. - You have multiple buildings or floors. - You need to keep core stability separate from distribution policy churn. Don't add a core just to look enterprise-grade. ## The redundancy pattern The canonical campus design pattern at each layer: | Layer | Redundancy | |---|---| | **Access** | Single switch is fine; redundancy is at the dist+core layer. Optional: dual-home access switches to two distribution switches (uplinks). | | **Distribution** | Always pair. Two distribution switches per block. Cross-connected. Both run FHRP for VLAN gateways. | | **Core** | Always pair. Two core switches. Fully meshed to every distribution pair (4 links between cores + dists). | This is the **"redundant L3 distribution + redundant core"** pattern. It survives any single failure (link, switch, line card, power supply) with no user impact. ## Loop-free designs — modern best practices Classic distribution uses STP (or RSTP) between access and distribution, with active/standby uplinks. RSTP convergence in 1–2 seconds is OK but not great. Two newer approaches: ### 1. StackWise Virtual / VSS (Virtual Switching System) Pair the two distribution switches into **one logical switch** with two chassis. From access switches' perspective there's only one upstream — they EtherChannel to both physical chassis, both links forward simultaneously. No STP blocking. Failure of one chassis = the other keeps forwarding. Failover ≤1 second. ### 2. Routed Access Push Layer 3 all the way down to access switches. Each access switch is a tiny routed device with its own subnet. STP only lives within the access switch itself. Distribution still aggregates but no longer terminates VLANs. - **Pros:** Faster convergence (IP routing > STP). Smaller failure domain. - **Cons:** Each access switch is L3 — every device needs OSPF/EIGRP knowledge. Mobile clients require some workaround (VXLAN, LISP, or stickiness). CCNA tests this at recognition level — both VSS and routed access are above the certification depth. ## What lives where — quick reference | Feature / Function | Layer | |---|---| | End-user / IoT / AP ports | Access | | PortFast + BPDU Guard | Access | | Port security, 802.1X | Access | | PoE | Access (and APs/phones) | | Voice VLAN | Access | | DHCP Snooping | Access | | Dynamic ARP Inspection | Access | | VLAN gateway SVI | Distribution | | FHRP (HSRP/VRRP) | Distribution | | ACLs (user → server policy) | Distribution | | Route summarization | Distribution → Core | | QoS marking | Access (set), Distribution (trust + remark) | | WAN/DC connections | Distribution or Core | | BGP / OSPF area boundary | Distribution or Core | | High-speed transit only | Core | ## A complete tiny campus example 50 users across one building. Two-tier collapsed-core design: ``` Internet │ ┌────────┴────────┐ │ CORE-1 ←──→ CORE-2 │ Catalyst 9500. EtherChannel between them. └───┬────┬────┬───────┘ HSRP virtual IP for each VLAN. │ │ │ OSPF to internet edge router. ┌───┴┐ ┌─┴┐ ┌─┴───┐ │ACC1│ │ACC2│ │ACC3 │ Catalyst 9200. PoE+. └────┘ └──┘ └─────┘ PortFast + BPDU Guard on user ports. │ │ │ Trunk uplinks to both cores. users phones APs ``` - VLAN 10 USERS / VLAN 20 PHONES / VLAN 30 GUEST / VLAN 99 MGMT. - SVIs on the cores. HSRP between them. - Each access switch trunks to both cores (LACP EtherChannel + RPVST+). - One core could fail and everything keeps working. ## When to break the rules The pure three-tier model is a starting point, not gospel. Real reasons to deviate: - **Small enough that 2-tier is sufficient.** Don't pay for boxes you don't need. - **Data center spine-leaf** is a different paradigm (Clos topology) — not three-tier. Used in DCs because east-west traffic dominates. - **SD-Access fabric** flattens it — leaf switches form a fabric and DNAC handles intent. Same physical layers, very different control plane. - **Modern campus with VSS / StackWise Virtual** essentially collapses dist+access into a logical pair, removing STP entirely. ## Common mistakes 1. **Running user ports off the core.** Putting ten users on core ports turns the core into an access switch. Failures and config changes now risk the whole network. 2. **No FHRP at distribution.** One distribution switch reload = one outage. Always run HSRP / VRRP between the pair. 3. **Trunking all VLANs everywhere.** Each VLAN should only be trunked where it's needed. Permit-all on the trunk allowed list = broadcast amplification. 4. **Single access uplink.** Cheap to dual-home access switches. Don't skimp here — single-link failure isolates 24–48 users. 5. **Skipping route summarization at distribution.** Every access subnet floods into the core's RIB. Wasteful. Summarize. 6. **Multiple roles in one box.** "Core/distribution/access combo switch" is a price-driven design for SMB — fine if you know what you're trading off. Not fine as an enterprise default. 7. **Designing for current size only.** Build for 3× current host count. Refit costs more than overprovisioning. 8. **Mixing campus design and DC design.** A campus is hierarchical because most traffic is north-south. A DC is spine-leaf because most traffic is east-west. Don't apply one's pattern to the other. ## Lab to try tonight 1. In CML/EVE-NG, build a 2-tier campus: 2 core switches, 3 access switches, 2 hosts each. 2. Cores are L3 switches with SVIs Vlan10 and Vlan20. HSRP between them. 3. Access switches are L2 only. Dual-homed to both cores via EtherChannel + RPVST+. 4. PortFast + BPDU Guard on user ports. 5. Test failures: shut one core's interface. Watch traffic continue via the surviving core. 6. Reload an access switch. Observe affected ports go down but neighbor switches unaffected. 7. Now expand to a 3-tier: add 2 dedicated core switches that the existing "core" (now distribution) connect into. 8. Bonus: enable route summarization between distribution and core — `area 0 range 192.168.0.0 255.255.252.0`. 9. Bonus: convert to StackWise Virtual (if your simulated switches support it). Compare convergence on a failure. ## Cheat strip | Layer | One-line job | |---|---| | **Access** | User ports. L2. PortFast + BPDU Guard. PoE. 802.1X. | | **Distribution** | Aggregation + L3 boundary + policy. SVIs + FHRP. Always pair. | | **Core** | Highest-speed transit. No users, no policy. Always pair. | | **Two-tier (collapsed core)** | Acceptable for small/mid sites. Distribution + core merged. | | **Three-tier** | Default for large enterprises. Each layer = one job. | | **Dual-home pattern** | Access → both dists; dist pair → both cores; cores fully meshed | | **Routed access** | Push L3 to access — modern alternative, faster convergence | | **StackWise Virtual / VSS** | Pair of physical switches behaving as one logical box — removes STP between layers | | **Where SVIs live** | Distribution (default) or access (routed access designs) | | **Where features live** | Memorize the table above — comes up on CCNA constantly | --- ## Cisco ISE Basics — https://packetmentor.com/topics/cisco-ise-basics/ > Cisco Identity Services Engine — the RADIUS/TACACS+ + posture + profiling brain behind enterprise wired/wireless network access. What ISE does, where it sits, and the deployment model behind 802.1X-everywhere. ## Mental model A switch port or AP needs to make a decision when a device shows up: who is this, what VLAN do they belong to, what policy applies. The switch itself doesn't know — it asks an external policy engine. That engine is the **RADIUS / AAA server**. In a Cisco enterprise, it's almost always **Cisco ISE** — Identity Services Engine. ``` 802.1X / MAB / WebAuth (from user / device) │ ▼ ┌──────────────────┐ │ Switch / WLC │ "Network Access Device" (NAD) └──────┬────────────┘ │ RADIUS Access-Request ▼ ┌──────────────────┐ │ ISE │ Policy Service Node (PSN) │ Auth + Posture │ │ Profiling + GBAC │ └──┬──────┬──────┬──┘ │ │ │ Active AD CA / external sources Directory ``` ISE evaluates: - **Authentication** — is this user/device known? (Active Directory, internal users, certificates) - **Authorization** — what should they get? (VLAN, dACL, SGT, time-of-day, location) - **Profiling** — what KIND of device is this? (IP phone? printer? laptop? IoT?) - **Posture** — is the device compliant? (AV up to date, disk encrypted, patches current) - **Guest** — sponsored vs self-registration vs hotspot for visitors - **BYOD** — onboarding personal devices with limited rights …and answers the NAD: *"permit this client, put them in VLAN 20, with this dACL, with SGT EMPLOYEE-CONTRACTOR."* If you haven't already, read [AAA](/topics/aaa/) and [802.1X](/topics/dot1x/) — this topic builds on both. ## What ISE provides ### 1. RADIUS authentication The day-one feature. Every wired switchport and every Wi-Fi SSID does **802.1X** against ISE. Devices that don't speak 802.1X (printers, IoT) fall back to **MAB** (MAC Authentication Bypass — see [802.1X](/topics/dot1x/)). ISE policy rules look like: ``` IF user-group = "Domain Admins" THEN permit, VLAN ADMIN, dACL ADMIN-FULL, SGT 100 (Admin) ELSE IF user-group = "Employees" AND posture = "Compliant" THEN permit, VLAN EMPLOYEE, dACL EMPLOYEE, SGT 10 (Employee) ELSE IF user-group = "Employees" AND posture = "Non-Compliant" THEN permit, VLAN QUARANTINE, dACL REMEDIATE-ONLY, SGT 999 (Quarantine) ELSE deny ``` ISE pushes this back as RADIUS attributes the switch/AP enforces. ### 2. TACACS+ for device administration Separate from RADIUS-for-users. **TACACS+** controls who can SSH into the switches and what commands they can run: ``` Network admins → full enable access Helpdesk → show commands only Auditors → show running-config only ``` Per-command authorization with audit trail. Standard in any environment with more than ~5 network engineers. ### 3. Profiling ISE listens to passive signals (DHCP, CDP, LLDP, MAC OUI, HTTP user-agent, SNMP) and **identifies** what's behind each MAC. The profile says: *"this MAC is a Cisco IP Phone 8861."* Why it matters: you can write policy by **device type** rather than by MAC list: - Printers → printer VLAN, deny everything outbound. - IP phones → voice VLAN, limited dACL. - Random IoT → quarantine VLAN. Maintains itself — no manual MAC tables. Re-profiles in real-time. ### 4. Posture assessment For corporate laptops: ISE deploys a lightweight **AnyConnect Posture Module** that reports back disk encryption status, AV signatures, OS patches, firewall state. If non-compliant, ISE quarantines the device (limited dACL, no production network) until remediation runs. Then re-grants normal access. ### 5. Guest portals Three flavors: - **Hotspot** — connect, accept terms, go. - **Self-registration** — guest fills a form, gets a temporary login. - **Sponsored** — guest's host approves access in a couple of clicks. ISE handles the captive portal, ties the guest to an SSID + VLAN, expires the access automatically. ### 6. BYOD onboarding Personal device shows up. ISE redirects to a portal. User logs in with corporate credentials. ISE issues a per-device cert tied to the user. Device authenticates via cert from then on — limited rights, no posture, no full corporate access. ### 7. SGT / TrustSec (with SD-Access) ISE assigns a **Scalable Group Tag** to each authenticated session. Switches and routers enforce **Group-Based Access Control (GBAC)** — "Employees can talk to Servers" is a single matrix entry, not 200 per-VLAN ACLs. This is the integration point with [Cisco DNA / Catalyst Center](/topics/dna-center/) for SD-Access deployments. ## The deployment model ISE deploys as a cluster of **nodes** running specific personas: | Persona | Role | |---|---| | **PAN** | Policy Administration Node — GUI, config repository. One active + one standby (HA). | | **MnT** | Monitoring & Troubleshooting Node — log storage, reports. One active + one standby. | | **PSN** | Policy Service Node — actually handles RADIUS/TACACS requests. Scale-out — add more for more throughput. | | **pxGrid** | Inter-product integration plane (sends ISE events to firewalls, SIEM, NAC partners). | A small deployment uses two appliances with all personas combined. A large deployment scales out PSNs (one or two per region) while keeping PAN + MnT central. ## Where ISE sits architecturally ``` Active Directory (users + groups) Microsoft CA (certificates) MDM (Intune/JAMF) (device compliance) │ external integrations ▼ ┌────────────────────┐ │ ISE │ │ PAN + MnT + PSN │ policy + identity └─────────┬──────────┘ │ RADIUS / TACACS+ / pxGrid ▼ ┌─────────────────────────────────┐ │ Switches, WLCs, FW, VPN, etc. │ NADs enforcing policy └─────────────────────────────────┘ ▼ Users, devices ``` ISE sits **between identity sources and the network enforcement points**. It speaks RADIUS to enforcers and LDAP/Kerberos to identity providers. ## Configuration — a tiny taste ISE itself is configured through its web GUI (Policy → Policy Sets, Identity Stores, etc.) — there is no CLI policy language in the way you'd write `access-list`. On the switch (NAD) side, you point at ISE as a RADIUS server: ``` SW1(config)# aaa new-model SW1(config)# radius server ISE-PSN-1 SW1(config-radius-server)# address ipv4 10.99.99.10 auth-port 1812 acct-port 1813 SW1(config-radius-server)# key SecretSharedWithISE SW1(config)# aaa group server radius ISE-GROUP SW1(config-sg-radius)# server name ISE-PSN-1 SW1(config)# aaa authentication dot1x default group ISE-GROUP SW1(config)# aaa authorization network default group ISE-GROUP SW1(config)# aaa accounting dot1x default start-stop group ISE-GROUP SW1(config)# dot1x system-auth-control SW1(config)# interface Gi1/0/1 SW1(config-if)# authentication host-mode multi-domain SW1(config-if)# authentication open ! optional: monitor mode SW1(config-if)# authentication port-control auto SW1(config-if)# mab SW1(config-if)# dot1x pae authenticator ``` ISE handles the rest via its policy GUI. ## CCNA depth For the CCNA 200-301 exam, you should be able to: - **Identify ISE** as Cisco's enterprise AAA / NAC platform. - **Describe** the difference between RADIUS and TACACS+ (see [AAA](/topics/aaa/)) and how ISE provides both. - **Recognize the deployment model** — PAN, MnT, PSN nodes. - **Connect ISE to 802.1X / MAB** — it's the back-end policy engine. - **Connect ISE to SD-Access / DNAC** — ISE assigns SGTs that SD-Access uses for GBAC. You won't configure ISE on the CCNA. Configuration is CCNP / specialist exam territory. ## Common mistakes 1. **Treating ISE as just a RADIUS server.** It does much more — profiling, posture, BYOD, guest. If you only use it for 802.1X, you're paying for capabilities you're not getting. 2. **Missing pre-auth ACLs.** When a port is doing 802.1X and the device hasn't authenticated yet, you need a small pre-auth ACL allowing DHCP, DNS, and the path to ISE. Without it, authentication itself can't complete. 3. **Confusing "authentication open" with "no security."** Open mode lets traffic flow before auth completes — useful during 802.1X rollout for monitoring. It still applies the post-auth policy once auth completes. Don't leave open forever. 4. **PSN sizing.** One PSN handles on the order of hundreds to a few thousand sustained authentications per second depending on the SNS appliance (SNS-3700 small/medium/large all sit in this range). Plan against real traffic patterns — the worst case is a "boot storm" where every laptop in a building authenticates at 8am within a couple of minutes. Cisco publishes per-appliance auth-throughput numbers; check those before sizing. 5. **No HA.** Single-PAN deployment + a failed appliance = ISE GUI gone. Authentications still work (PSNs are cached) but you can't change policy. Always have a standby PAN. 6. **Skipping certificate hygiene.** ISE uses certs everywhere — admin GUI, EAP, portals, pxGrid. Expired certs = mysterious failures. Track them. 7. **Active Directory tight coupling.** ISE depends on AD for user/group lookups. Plan for AD outages (caching helps, but design with the assumption that AD can be unavailable briefly). 8. **Skipping a "monitor mode" rollout.** Going straight from "no NAC" to "strict 802.1X" causes mass auth failures and a help-desk meltdown. Start in open mode, audit failures for weeks, then tighten. ## Lab to try (sandbox) 1. Cisco DevNet has free ISE sandboxes — reserve one. 2. Log into the GUI. Tour: Identities (users), Policy → Policy Sets, Policy Elements (Conditions / Results), Operations (live logs). 3. Look at the included sample policy set — see how rules match conditions and return authorization profiles. 4. From a simulated switch, send a test RADIUS request: `test aaa group ISE-GROUP new-code`. Watch ISE's Live Logs. 5. Add an identity (user → group). Create an authorization profile (VLAN + dACL). Wire them together in a new rule. Re-test. 6. Bonus: enable profiling. Connect a simulated client and watch ISE classify it based on DHCP fingerprints. ## Cheat strip | Concept | Plain English | |---|---| | **ISE** | Cisco's enterprise AAA / NAC platform | | **RADIUS vs TACACS+** | RADIUS = network access (user auth + authz); TACACS+ = device admin (who can SSH + what commands) | | **NAD** | Network Access Device — the switch/AP/firewall asking ISE | | **PAN / MnT / PSN** | Admin node / Monitoring node / Policy Service node | | **Profiling** | Identify what kind of device is behind a MAC | | **Posture** | Check the device is compliant before granting access | | **BYOD** | Onboard personal devices with per-user cert | | **Guest** | Captive portal for visitors | | **SGT** | Scalable Group Tag — identity-based segmentation. ISE assigns; switches enforce | | **pxGrid** | Integration plane to send ISE info to other security products | | **Open mode** | 802.1X in monitor — allow + log — useful during rollout | | **CCNA depth** | Know what ISE is. Know where it sits. Know it powers 802.1X and SD-Access. | --- ## Network Troubleshooting Methodology — https://packetmentor.com/topics/troubleshooting-methodology/ > How seasoned engineers actually approach unknown problems — OSI bottom-up vs top-down vs divide-and-conquer, the questions that come before commands, and the seven-step Cisco methodology. ## Mental model A junior engineer hears "the internet is broken" and starts typing `show` commands at random — pings, traceroutes, interface stats — hoping one of them surfaces the cause. A senior engineer asks two questions first: 1. **What changed?** Nothing breaks itself spontaneously. If it worked yesterday and doesn't today, something changed. Find that change first; the rest may be unnecessary. 2. **What's the scope?** One user, one VLAN, one site, or everyone? Scope tells you which layer to start at and which path to investigate. Only after those two answers do you reach for a CLI. The CLI is for confirming a hypothesis, not for generating one. This topic is the discipline behind that. ## The seven-step Cisco methodology Cisco's official troubleshooting model. Memorize for the exam; use a streamlined version in practice. 1. **Define the problem** — Be specific. "Internet broken" is useless. "User X cannot reach `gmail.com` from VLAN 10 since 9:00am today" is actionable. 2. **Gather information** — Logs, recent changes, scope, error messages, user observations. 3. **Analyze information** — Form a hypothesis. *"DNS is failing. Or default route is gone. Or the upstream firewall dropped the policy."* 4. **Eliminate possible causes** — Run tests that distinguish between hypotheses. Bottom-up, top-down, or divide-and-conquer. 5. **Propose a hypothesis** — Pick the most likely cause based on tests so far. 6. **Test the hypothesis** — Apply a fix or further test. If it works → confirmed. If not → back to step 3 with new information. 7. **Solve the problem and document** — Apply the permanent fix. Document so the next outage with the same symptoms is solved in 5 minutes. In real life this collapses into something like: *"Define + Gather + Hypothesize + Test."* But knowing the long version helps when an outage gets messy. ## Three approaches — pick by symptom ### Bottom-up — start at Layer 1 Walk the OSI stack from the bottom: cable → port → MAC → IP → TCP → app. Use when: - Hardware failures suspected. - "It worked yesterday" + no recent config change. - New install where physical didn't get verified. Typical Layer-1 questions: cable plugged in? LEDs lit? Duplex/speed match? Port not err-disabled? Patch correct? ``` SW1# show interfaces Gi1/0/1 SW1# show interfaces Gi1/0/1 status SW1# show interfaces Gi1/0/1 counters errors ``` ### Top-down — start at the application Walk the OSI stack from the top: app → presentation → session → transport → network → data link → physical. Use when: - Single user / single application failure. - "Browser shows certificate error" — start with the browser, not the cable. - Application teams have already verified server-side health. Typical top-down: browser → DNS lookup → TCP connect → TLS handshake → HTTP response → server. Each step gives you a stop-and-isolate point. ### Divide-and-conquer — split the path in half Pick a midpoint along the path and test reachability from both ends. Use when: - Symptom is "can't reach X from Y" and you have a long path. - You can ping/SSH into devices along the way. Example: user at branch can't reach server at HQ. - Test 1: ping HQ firewall from branch — works? Problem is HQ-side, not branch-WAN. - Test 2: ping HQ firewall from HQ access switch — works? Problem is the firewall itself or further inside. Each test halves the search space. Binary search applied to networks. ## Information gathering — what to ask first Before any command, get answers from the user / requester: 1. **What's the exact symptom?** Error message verbatim. Screenshot. 2. **When did it start?** Tied to a change? 3. **Who's affected?** One user, one VLAN, one site, everyone? 4. **What changed?** Maintenance, deployment, patch, weather, power blip. 5. **Does it always fail or intermittently?** Intermittent = different toolkit. 6. **Has anyone tried fixes?** Often a non-engineer "fixed" something that made it worse. For a hostile incident (large outage, public-facing), the first 5 minutes is **only** information gathering. Resist the urge to dive into CLI. ## The show-command toolkit These cover 80% of CCNA-level troubleshooting: | Layer | Command | Tells you | |---|---|---| | L1 | `show interfaces` / `... status` | Port up/down, errors, speed/duplex | | L1 | `show interfaces description` | Quick port purpose | | L1 | `show power inline` | PoE issues | | L2 | `show mac address-table` | Where a MAC was learned | | L2 | `show vlan brief` | VLANs configured + which ports | | L2 | `show spanning-tree` | STP state, root bridge | | L2 | `show interfaces trunk` | Allowed VLANs, native VLAN | | L2 | `show cdp neighbors` / `show lldp neighbors` | What's plugged into where | | L3 | `show ip interface brief` | IP per interface, line state | | L3 | `show ip route` | Routing table | | L3 | `show arp` | IP↔MAC mappings learned | | L3 | `ping` / `traceroute` | End-to-end reachability | | L4 | `telnet host 80` / `nc -zv host 443` | TCP port reachability | | L3 | `show ip ospf neighbor` | OSPF adjacencies | | L3 | `show ip bgp summary` | BGP peering state | | Misc | `show log` | Recent syslog events | | Misc | `show running-config | section X` | Config of a feature | `debug` commands are powerful but **dangerous in production** — they can overwhelm CPU. Use `debug ip packet detail` with caution, always with a tight ACL. ## Real-world flow User reports: *"I can't reach `internal-app.example.com` from my laptop."* You ask: *"How long? Anyone else affected? What error?"* — Answer: *"30 minutes. Yes, my whole team. Browser says 'site can't be reached.'"* Now scope = team-wide (probably one VLAN or one switch's users). Recent change? Helpdesk says: *"Power outage 1 hour ago at the branch."* You skip top-down and go to divide-and-conquer: 1. From your laptop (different site): can YOU resolve `internal-app.example.com`? Yes → DNS is fine globally. 2. From a router at the affected branch: ping the branch's gateway → works → L1/L2 are fine. 3. Ping the HQ application server's IP → fails. Now bisect: ping HQ firewall → works. Ping the server's L3-switch → fails. 4. The server's L3 switch is unreachable. SSH from another HQ switch → CDP says it's down. 5. Walk to the rack. Power outage took out the switch's UPS. UPS dead. Reboot. 15 minutes from ticket to fix. Method beat luck. ## When to stop and escalate Sometimes the right next step is "ask for help" — not because you can't continue but because you're wasting time: - You've spent 30 minutes and have no working hypothesis. - The symptom contradicts everything you know about the stack. - The fix would require a change with audit trail (firewall rule, BGP route). - You're outside business hours and the system isn't critical — wait for the right people. Senior engineers escalate often. Junior engineers escalate too late. ## Common mistakes 1. **Changing things before understanding them.** "Let me just bounce that interface and see." Now you've added a variable. Always understand first, change second. 2. **Multiple changes at once.** Fixed it? Was it the ACL change, the route adjustment, or the routing-protocol restart? You don't know — and next time, you won't know what to try. 3. **Forgetting to capture data before reload.** Show outputs first, then `reload`. Logs are gone after restart. 4. **Treating symptoms instead of causes.** Restarting the AP every hour because users complain isn't a fix. Find why it's locking up. 5. **Ignoring user observations.** "It only happens when I'm on the call" is data. Don't dismiss because it sounds non-technical. 6. **Trusting one diagnostic without confirmation.** A single ping success doesn't mean the problem is fixed. Try the actual workflow. 7. **Skipping documentation after the fix.** Same outage in 6 months, by a different engineer, takes 4 hours again because no one wrote it down. 8. **Confusing correlation with causation.** "It started after I deployed X." Maybe. Or maybe X is a coincidence. Test. ## A pre-built mental checklist For your first 60 seconds when paged: 1. **Scope.** Who's affected? One / some / all? 2. **Recent change.** Anything deployed in last 24h? 3. **External vs internal.** Cloud / WAN dependency? 4. **Multiple symptoms or one.** Single fault or compound? 5. **Severity escalation rule.** If 10+ users / mission-critical, page the team. For your first 5 minutes: 1. **L1 sanity.** Lights on the affected port/switch? 2. **L3 sanity.** Default gateway reachable? DNS responding? 3. **Logs.** Any syslog spam from devices around the path? For your first 30 minutes: 1. **Hypothesis + test loop.** Pick a likely cause, design a test, run it, refine. 2. **Documentation as you go.** Output captured, timeline noted. 3. **Communication.** Stakeholders know status. Don't go silent. ## Lab to try tonight This topic is best practiced on a real lab with intentional breakage: 1. Build any small topology in CML — say, 3 switches + 1 router + 2 hosts. 2. Verify everything works (ping host-to-host). 3. Ask a colleague to **break one thing** in your absence — shut a port, change a native VLAN, remove a route, mistype a password. 4. Come back. The host can't reach. Now troubleshoot using the methodology — define scope, hypothesize, narrow down. 5. Time yourself. Beat your previous time. 6. Bonus: instead of one breakage, ask for **two compound** failures — that's where method really shines vs guessing. Real network engineers learn this skill from years of being paged at 3 AM. Lab practice cuts that learning curve. ## Cheat strip | Concept | Plain English | |---|---| | **Define the problem** | Specific, measurable. "Internet broken" is not a problem statement | | **Gather information** | Scope + recent changes + symptoms first, commands second | | **Bottom-up** | Layer 1 → up. Use for hardware-suspect issues | | **Top-down** | App → down. Use for single-app failures | | **Divide-and-conquer** | Split the path. Use for long paths with intermediate access | | **Two openers** | "What changed?" and "Who's affected?" | | **Show, not debug** | `show` for normal triage; `debug` only when needed, with caution | | **One change at a time** | If you fix it, you know what fixed it | | **Document the fix** | Future you (or your replacement) will thank you | | **Escalate when stuck** | After 30 min with no hypothesis, get a second pair of eyes | | **CCNA depth** | Recognize the methodology, name the approaches, know the seven steps | --- ## NetFlow & Flow-Based Monitoring — https://packetmentor.com/topics/netflow/ > How NetFlow / IPFIX / sFlow turn raw traffic into queryable records — flow definition, exports, collectors, and the operational use cases (capacity, security, billing) that SNMP can't answer. ## Mental model SNMP tells you *"interface Gi0/1 sent 4.2 TB this month."* True but useless — you don't know *who* sent what, *which app*, or *what direction*. NetFlow answers: *"of that 4.2 TB, 1.8 TB was YouTube to user X, 900 GB was backup traffic to the DC, 300 GB was Microsoft 365…"* The difference: SNMP counts at the interface; NetFlow tracks **flows** — unique conversations defined by a tuple of: ``` ( src IP, dst IP, src port, dst port, protocol, ingress interface, ToS ) ``` (7-tuple in v5; configurable in v9/IPFIX.) Every packet matching the same 7-tuple is one flow. The router maintains a flow table in memory, increments byte/packet counters per flow, and **exports** the flow record to a collector when the flow ends (or periodically). A single device exports millions of flows per day. The collector stores them. You query them. ## Three NetFlow variants worth knowing | Standard | Vendor | Sampling | Notable | |---|---|---|---| | **NetFlow v5** | Cisco | None (1:1 in software) | Legacy fixed format, IPv4 only | | **NetFlow v9** | Cisco | None (or 1:N) | Template-based, IPv6 + custom fields | | **IPFIX** (NetFlow v10) | IETF standard | None or sampled | v9 cleaned up + standardized — multi-vendor | | **sFlow** | Foundry/InMon | **Always sampled (e.g., 1:1000)** | Lower CPU, less precise per-flow | | **Cisco Flexible NetFlow** | Cisco | Configurable | Define your own flow keys — modern Cisco default | In 2026: **IPFIX** is the multi-vendor target. **Flexible NetFlow** is the Cisco-native way. **sFlow** is common on Arista, HP, Juniper. ## Sampled vs unsampled **Unsampled** — every packet hits the flow table. Most accurate. But on high-speed interfaces (10G+), the table updates per packet can overwhelm CPU. **Sampled** — every Nth packet is examined; the rest are ignored. Lower CPU, less precise per-flow but statistically OK for aggregate. Common sample rates: - 1:1 — every packet (small / mid network). - 1:1000 — high-speed enterprise. - 1:5000 — service-provider backbones. sFlow always samples. NetFlow v5 is unsampled. v9/IPFIX can be either. ## The export and collection model ``` ┌──────────────┐ │ Router / │ maintains flow cache (RAM table) │ Switch │ counts bytes/packets per flow └──────┬───────┘ │ │ UDP export every "active timeout" / "inactive timeout" │ destination = NetFlow collector ▼ ┌──────────────┐ │ Collector │ stores in time-series DB (often InfluxDB/Elastic) │ (PRTG, ELK, │ indexes for queries │ Splunk, │ exposes dashboards / SIEM │ Plixer, …) │ └──────────────┘ ``` The collector is where the value is. NetFlow without a good collector is just CPU overhead — you need queryable storage + visualization to actually use the data. ## Flow timeouts — when does export happen? A flow gets exported on **any of these events**: - **TCP FIN/RST** — explicit end-of-flow. - **Inactive timeout** — no new packets for N seconds (default 15s). Long flows split into shorter chunks. - **Active timeout** — flow has lasted N seconds total (default 1800s/30min). Even if active, force an export to keep records current. - **Cache full** — least-recently-used flow gets evicted and exported. Effect: a long download might appear as multiple flow records (one per active-timeout boundary) but the collector reconstructs them by 5-tuple matching. ## Configuration — Cisco Flexible NetFlow The modern Cisco way uses Flexible NetFlow with three building blocks: **flow record**, **flow exporter**, **flow monitor**. ``` ! 1. Flow record — what fields to track R1(config)# flow record FLOW-REC R1(config-flow-record)# match ipv4 source address R1(config-flow-record)# match ipv4 destination address R1(config-flow-record)# match transport source-port R1(config-flow-record)# match transport destination-port R1(config-flow-record)# match ipv4 protocol R1(config-flow-record)# collect counter bytes R1(config-flow-record)# collect counter packets R1(config-flow-record)# collect timestamp absolute first R1(config-flow-record)# collect timestamp absolute last ! 2. Flow exporter — where to send records R1(config)# flow exporter FLOW-EXP R1(config-flow-exporter)# destination 10.99.99.20 R1(config-flow-exporter)# transport udp 2055 R1(config-flow-exporter)# template data timeout 60 ! 3. Flow monitor — combines record + exporter R1(config)# flow monitor FLOW-MON R1(config-flow-monitor)# record FLOW-REC R1(config-flow-monitor)# exporter FLOW-EXP ! 4. Apply to interface (ingress / egress) R1(config)# interface Gi0/1 R1(config-if)# ip flow monitor FLOW-MON input R1(config-if)# ip flow monitor FLOW-MON output ``` Default port for the exporter is UDP 2055 (some collectors use 9995, 9996, or 4739 for IPFIX — check your collector's docs). ## Use cases — why bother ### 1. Capacity planning "WAN link looks 60% utilized — what's eating it?" NetFlow answers in 30 seconds: - 40% YouTube (call your security team about acceptable-use policy) - 25% Microsoft 365 (real productivity traffic) - 20% generic HTTPS (unattributed) - 15% backup to DR site (could be QoS-deprioritized) ### 2. Anomaly / security detection Unusual flow patterns flag attacks: - 10,000 short flows from one internal host to many external IPs → likely scanning (compromised host). - One internal IP suddenly sending 50 GB/hour to an unfamiliar Russia IP → potential exfiltration. - A normally-quiet IoT device now talking to an unknown C2 server → compromise. NetFlow is the standard data source for many SIEM correlation rules. ### 3. Forensics Six weeks after an incident, the security team asks: *"Who did this server talk to on June 12 between 03:00 and 03:20?"* NetFlow has the answer if collection includes that time range. Packet capture would be impossibly large; NetFlow records take 1/100 the space. ### 4. Billing / chargeback Multi-tenant network bills departments by traffic. NetFlow per-source-IP × time × bytes = a usable bill. ### 5. Application visibility "What apps do we even run on this network?" Sort flows by destination port + protocol. Quickly find unauthorized apps (P2P, file sharing, unauthorized SaaS). ## Verification ``` R1# show flow exporter FLOW-EXP R1# show flow monitor FLOW-MON R1# show flow monitor FLOW-MON cache ! current flows in memory R1# show flow record FLOW-REC R1# show flow exporter statistics R1# show flow monitor FLOW-MON statistics ``` `cache` is the most useful — gives you live current flows. Filter by destination IP or protocol to confirm a specific session is being tracked. ## NetFlow vs sFlow — when to pick which | | **NetFlow** | **sFlow** | |---|---|---| | **Sampling** | Optional (often unsampled at lower speeds) | Always sampled | | **Precision** | Higher (per-flow exact bytes) | Statistical | | **CPU cost** | Higher | Lower | | **High-speed (40G+) suitable** | Sampled mode | Yes (natively designed for it) | | **Vendor** | Cisco-led; IPFIX standardizes | Multi-vendor | | **Use case** | Forensics, billing, fine-grained | Capacity, anomaly, high-speed | For most CCNA-level enterprises: Flexible NetFlow on Cisco switches, sFlow on non-Cisco. Modern collectors (Plixer, Kentik, ntopng, Elastiflow) handle both. ## Storage realities NetFlow records average ~50–100 bytes per record. A typical mid-enterprise gateway might export 50k flows/sec → ~5 MB/s → ~430 GB/day. Plan storage accordingly: - **Active queries** — 7-14 days hot in fast storage. - **Forensics** — 30-90 days in compressed warm storage. - **Compliance** — 1 year+ in cold (cloud) storage. Aggregation tools shrink this significantly — group flows by app/host/time, store the rollup, drop the raw. ## Common mistakes 1. **NetFlow without a collector.** Configured the exporter, no one's receiving it. Records vanish into UDP void. Always verify reception on the collector side. 2. **Sample rate too aggressive.** 1:10000 sampling on a low-throughput link = you miss most of the traffic. Match sample rate to expected flow volume. 3. **Forgetting both directions.** Apply NetFlow `input` and `output` on the same interface to capture both directions, or apply once and let the collector infer bidirectionality from 5-tuple. 4. **No timestamps in the flow record.** Forensics is useless without time. Always include `timestamp absolute first / last`. 5. **CPU surprise on high-volume routers.** Enabling NetFlow on a busy edge router can spike CPU 20-40%. Test on a maintenance window; consider sampling. 6. **Trusting NetFlow for "encryption analysis."** NetFlow sees IPs and ports, not content. A TLS-encrypted session looks the same as plaintext at the flow level. 7. **Using NetFlow on a switch where it requires hardware.** Some lower-end switches process NetFlow in CPU instead of ASIC — adds latency. Verify your platform. 8. **Confusing IPFIX with packet capture.** IPFIX is metadata about flows. Packet capture is the raw bytes. They serve different forensic purposes. ## Lab to try tonight 1. Install **ntopng** (free) on a Linux VM, or use Plixer's free trial collector. 2. In CML/EVE-NG, set up Flexible NetFlow on a router's WAN interface with the config above. Exporter → collector's IP. 3. Generate some traffic — `ping`, `iperf3`, browse to YouTube from a host through the router. 4. In the collector, observe flows appearing in real time. Look at top talkers, top apps, top destinations. 5. Adjust active/inactive timeouts; observe how long flows split. 6. Try sFlow on a non-Cisco emulator (if available). Compare data fidelity at 1:100 vs 1:1000 sample rates. 7. Bonus: deliberately cause an anomaly — generate a port scan from one of your hosts. Watch the collector's anomaly dashboard light up. ## Cheat strip | Concept | Plain English | |---|---| | **NetFlow** | Per-flow traffic accounting — far richer than SNMP byte counters | | **Flow** | A unique conversation: 5-7 tuple of src IP/port + dst IP/port + protocol | | **NetFlow v5** | Legacy fixed format, IPv4 only | | **NetFlow v9 / IPFIX** | Template-based, IPv6 + custom fields. IPFIX = standardized v9 | | **sFlow** | Multi-vendor, always sampled, lower CPU | | **Flexible NetFlow** | Modern Cisco — define your own flow keys | | **Flow record / exporter / monitor** | What to collect / where to send / glue them together | | **Default exporter port** | UDP 2055 (or 9995/9996/4739) | | **Sample rate** | 1:N. Higher N = less precise but lower CPU | | **Use cases** | Capacity, security forensics, billing, app visibility | | **Storage cost** | 50-100 bytes per record. Plan retention tiers | | **CCNA depth** | Recognize NetFlow + IPFIX + sFlow + the use case categories | --- ## IPv6 Transition Mechanisms — https://packetmentor.com/topics/ipv6-transition/ > How networks bridge the IPv4 → IPv6 gap — dual-stack, tunneling (6to4, 6in4, GRE), NAT64 / DNS64, and the realistic 2026 migration patterns. ## Mental model The textbook says *"IPv6 will replace IPv4."* That's been the textbook for 25 years. Reality: - Mobile carriers and large hyperscalers are heavily IPv6 (T-Mobile US, Comcast, AWS, Google). - Enterprise LAN is still mostly IPv4 (95%+) with creeping IPv6. - Legacy industrial / SCADA / financial systems may never go to IPv6. - The internet runs both — most public sites are dual-stack. So the transition isn't "throw the switch." It's a multi-decade overlap where **every protocol must work** during the migration. That's what transition mechanisms are for. ## The three approaches | Approach | What it does | When to use | |---|---|---| | **Dual-stack** | Run IPv4 and IPv6 simultaneously on the same device / link | The default. Use everywhere you can. | | **Tunneling** | Encapsulate one protocol inside the other to cross a non-supporting transit | When the path between two endpoints doesn't support the protocol you need | | **Translation** | Rewrite headers between IPv4 and IPv6 (NAT64) | When an endpoint only speaks one and must reach the other | You'll see all three in real networks. None replaces the others — they complement. ## 1. Dual-stack Every device runs both IPv4 and IPv6 stacks. Each interface has both an IPv4 address and an IPv6 address. DNS returns AAAA (IPv6) and A (IPv4) records; the client picks (usually IPv6 first via "Happy Eyeballs"). ``` R1(config)# ipv6 unicast-routing ! enable IPv6 globally R1(config)# interface Gi0/1 R1(config-if)# ip address 10.0.0.1 255.255.255.0 R1(config-if)# ipv6 address 2001:db8:1::1/64 R1(config-if)# ipv6 enable ``` That's literally it — every IPv4 routing protocol has an IPv6 cousin (OSPFv2 → OSPFv3, EIGRP for IPv6, etc.) and each runs independently. **Pros:** Cleanest. Each protocol works natively. No encapsulation overhead. **Cons:** Both stacks consume resources. Double the policy work — every ACL written twice. This is the **default strategy** for any new deployment in 2026. Tunnel/translate only when dual-stack isn't possible. ## 2. Tunneling — IPv6 over IPv4 (or vice versa) When your sites speak IPv6 but the transit between them only routes IPv4, you wrap IPv6 packets inside IPv4 packets for the journey. ### Manual IPv6-in-IPv4 (6in4) ``` R1(config)# interface Tunnel0 R1(config-if)# tunnel mode ipv6ip ! IPv6 over IPv4 R1(config-if)# tunnel source Gi0/1 ! local IPv4 R1(config-if)# tunnel destination 198.51.100.5 ! remote IPv4 R1(config-if)# ipv6 address 2001:db8:99::1/64 ``` Predictable, simple. Manual configuration for each tunnel — doesn't scale to thousands. ### GRE for IPv6 GRE can carry IPv6 too — see [GRE Tunnels](/topics/gre-tunnels/). Use when you also want to carry multicast or other non-IP protocols. ``` R1(config)# interface Tunnel0 R1(config-if)# tunnel mode gre ip R1(config-if)# ipv6 address 2001:db8:99::1/64 ``` ### 6to4 (deprecated) A historical "auto" mechanism that mapped IPv4 to a special `2002::/16` block. Largely deprecated due to reliability issues with the public relay infrastructure. Recognize the name; don't deploy. ### Teredo (deprecated) NAT-traversing UDP-encapsulated IPv6. Microsoft pushed it for home users a decade ago. Now disabled by default in modern Windows. Don't use. ### ISATAP Intra-Site Automatic Tunnel Addressing Protocol. Used inside a single site to give IPv4-only hosts IPv6 connectivity via a router. Edge case; rarely seen. ### DMVPN / FlexVPN Modern alternative to manual tunnels — Dynamic Multipoint VPN can carry IPv6 over IPv4 underlay (and the reverse). The standard for scaled deployments. ## 3. Translation — NAT64 / DNS64 When you have IPv6-only clients that need to reach IPv4-only services (the case at every IPv6-only mobile carrier today), translation is the answer. ### NAT64 A NAT64 gateway statefully translates between IPv6 and IPv4 packets — like classic NAT (see [NAT](/topics/nat/)) but across address families. The well-known prefix for NAT64 is `64:ff9b::/96`. IPv4 addresses are embedded in the last 32 bits: ``` IPv4: 198.51.100.10 IPv6: 64:ff9b::198.51.100.10 = 64:ff9b::c633:640a ``` The NAT64 gateway sees `64:ff9b::c633:640a` come in, extracts the embedded IPv4 (`198.51.100.10`), opens an IPv4 socket, and forwards. Return traffic gets reassembled into IPv6 toward the client. ``` Gateway(config)# nat64 prefix stateful 64:ff9b::/96 Gateway(config)# interface Gi0/0 Gateway(config-if)# nat64 enable Gateway(config)# nat64 v4 pool MY-POOL 198.51.100.100 198.51.100.110 Gateway(config)# nat64 v6v4 list NAT64-ACL pool MY-POOL ``` ### DNS64 NAT64 alone doesn't help if the client doesn't know the synthesized IPv6 address. **DNS64** is the trick: 1. IPv6-only client asks DNS for `legacy-server.example.com` AAAA record. 2. No AAAA exists. DNS64 server checks for an A record. 3. A record found (`198.51.100.10`). 4. DNS64 synthesizes a fake AAAA: `64:ff9b::c633:640a` and returns it. 5. Client connects to the synthesized IPv6. 6. Path leads to NAT64 gateway. Gateway extracts the embedded IPv4 and forwards. The client thinks the world is IPv6. The legacy service thinks it's getting IPv4. Both are right. This is **how T-Mobile US works** for the millions of phones it gives only IPv6 — they reach the IPv4 internet via carrier-grade NAT64+DNS64. ## Which to pick — 2026 reality ``` Scenario Best choice ───────────────────────────────────────────────────── New green-field LAN Dual-stack Mature IPv4 LAN, gradual IPv6 rollout Dual-stack (start internal) IPv6 islands over IPv4 transit Tunnel (GRE or DMVPN) IPv6-only carrier serving mixed internet NAT64 + DNS64 Legacy app that only speaks IPv4 Stay dual-stack until app is upgraded ``` **The non-decision:** Don't pick a transition mechanism in isolation. They layer: - LAN is dual-stack. - WAN may tunnel IPv6 inside MPLS underlay. - Mobile users come in as IPv6-only, NAT64 handles their IPv4 needs. All three can coexist in one network. ## Verification ``` R1# show ipv6 interface brief R1# show ipv6 route R1# show ipv6 neighbors R1# show interface Tunnel0 R1# show nat64 statistics R1# show nat64 translations ``` DNS64 testing from the client: query an A-record-only domain via the DNS64 server, expect a synthesized AAAA back. ## Common mistakes 1. **IPv6 enabled but no `ipv6 unicast-routing`.** Interfaces are configured, neighbors form, but the router won't actually forward IPv6 between them. Easy to miss. 2. **MTU surprise with tunnels.** IPv6 in IPv4 has 40 bytes of overhead vs 20 for plain IPv4 — combined with GRE/IPsec you can blow past 1500 MTU. Configure `tunnel mtu 1400` or `ipv6 tcp adjust-mss 1360` to avoid black-holing. 3. **Treating link-local as a routable address.** Link-locals (`fe80::/10`) only work within a single link. Use globals or ULAs for end-to-end. 4. **Dual-stack without dual-stack DNS.** Server has AAAA but client gets only A → uses IPv4. Make sure recursive resolvers serve AAAA records correctly. 5. **NAT64 without DNS64.** Without DNS synthesis, IPv6 clients don't know to send to the NAT64 prefix. Must deploy them together. 6. **Forgetting policy for both protocols.** New ACL? Write the IPv6 version too. New QoS classification? Both. New firewall rule? Both. Every "I forgot the IPv6 side" is a future incident. 7. **Deprecated mechanisms still around.** 6to4 and Teredo are unreliable. If you find them in old configs, plan to retire — they're more trouble than they're worth. 8. **Privacy extensions surprises.** IPv6 hosts often generate randomized addresses (RFC 4941). ACLs that pin policy to a specific IPv6 address break on rotation. Use DHCPv6 with reserved addresses or rely on link-local + MAC. ## Lab to try tonight 1. Build two routers connected via a router-on-stick or simple link. Enable dual-stack on both. 2. Configure IPv4 and IPv6 addresses on the interconnect. Run OSPFv2 for IPv4 and OSPFv3 for IPv6. Verify both reachabilities. 3. Add a GRE tunnel between two hosts using only IPv4 transport. Configure IPv6 addresses on the tunnel. Run IPv6 routing across it. 4. Add a third host that's IPv6-only. Add a NAT64 gateway. Configure DNS64 (`dnsmasq` on Linux has a `--dns64-prefix` option). 5. From the IPv6-only host, browse to an IPv4-only website. Watch the gateway translate. 6. Bonus: capture with Wireshark and verify the IPv4 ↔ IPv6 packet rewrite. 7. Bonus: configure `tunnel mtu` carefully to avoid fragmentation. Test with `ping` of varying sizes. ## Cheat strip | Mechanism | What it does | |---|---| | **Dual-stack** | Run IPv4 + IPv6 simultaneously. Default for new deployments. | | **Manual 6in4 tunnel** | IPv6 inside IPv4 packet — fixed endpoints | | **GRE for IPv6** | Generic tunnel that can carry IPv6 + multicast + other | | **6to4** | Auto-tunnel using `2002::/16` — **deprecated** | | **Teredo** | UDP-encapsulated IPv6 through NAT — **deprecated** | | **ISATAP** | Intra-site IPv6 over IPv4 — rare in 2026 | | **NAT64** | Stateful header translation IPv6 ↔ IPv4 | | **DNS64** | Synthesize fake AAAA from real A records so IPv6 client knows where to go | | **`64:ff9b::/96`** | Well-known NAT64 prefix | | **MTU gotcha** | Tunnels add overhead — adjust MTU/MSS | | **CCNA depth** | Know names, recognize patterns, understand dual-stack as the default | --- ## Private VLANs (PVLAN) — https://packetmentor.com/topics/private-vlans/ > How Private VLANs add a second layer of isolation inside one Layer-3 subnet — primary + secondary VLANs, isolated vs community vs promiscuous ports, and real-world use cases (hotels, MDU, hosting). ## Mental model Standard VLANs solve one isolation problem: separate broadcast domains, separate IP subnets. If you want 100 isolated networks, you need 100 VLANs + 100 subnets + 100 gateways. Expensive. **Private VLANs** solve a different isolation problem: many hosts in **the same VLAN** (and the same subnet), but **isolated from each other** at Layer 2. They can all talk to a gateway/firewall, but they can't talk to each other. This sounds esoteric until you see the use cases: - **Hotel room Wi-Fi** — 200 rooms × 200 guests, all in one big `10.10.0.0/22` subnet. Guest A's laptop should NOT be reachable from Guest B's laptop (no AirDrop hijinks, no malware spread). All guests reach the internet gateway. - **MDU (Multi-Dwelling Unit) broadband** — apartment building. Same scenario as hotel but with permanent residents. - **Multi-tenant hosting** — many customer servers in one rack/subnet, isolated from each other. - **Manufacturing IoT** — many sensors in one subnet, none should talk to another sensor. - **Hospital wards** — patient devices isolated for compliance. Without PVLAN, you'd have to give every guest/tenant their own VLAN (impractical at scale) or rely on host-level firewalls (unreliable). PVLAN is the right tool. ## The three port types | Port type | Can talk to | Cannot talk to | |---|---|---| | **Promiscuous (P)** | Everyone (all isolated + all community + other promiscuous) | — | | **Isolated (I)** | Only promiscuous ports | Other isolated, other community | | **Community (C)** | Other ports in same community + promiscuous | Other isolated, ports in different communities | **Promiscuous** is for the gateway, the firewall, the file server — anything that everyone needs to reach. **Isolated** is the strictest. Used for hotel guests, untrusted tenants. An isolated port can't reach any other isolated port, even another isolated port in the same secondary VLAN. **Community** allows a defined group to talk among themselves. Used for a department or a customer that has multiple boxes that need to talk to each other but not to other customers. ## Primary and secondary VLANs PVLAN uses a layered VLAN structure: - **Primary VLAN** — the visible VLAN ID. All promiscuous ports live here. Has the L3 SVI (gateway IP). - **Secondary VLANs** — sub-VLANs **within** the primary. Each is either an **isolated** secondary or a **community** secondary. ``` Primary VLAN 100 10.10.0.0/24 Gateway 10.10.0.1 │ ┌──────────────┼──────────────────┐ │ │ │ ┌────┴──────┐ ┌────┴──────┐ ┌─────┴──────┐ │ Isolated │ │ Community │ │ Community │ │ Secondary │ │ Secondary │ │ Secondary │ │ VLAN 101 │ │ VLAN 102 │ │ VLAN 103 │ │ Guests │ │ Customer A│ │ Customer B │ └───────────┘ └───────────┘ └────────────┘ ``` To the upstream router, this is all VLAN 100, subnet `10.10.0.0/24`. The secondary VLANs are how the switch enforces isolation internally. ## Configuration — Cisco IOS ``` ! 1. Create the secondary VLANs first SW1(config)# vlan 101 SW1(config-vlan)# private-vlan isolated SW1(config)# vlan 102 SW1(config-vlan)# private-vlan community SW1(config)# vlan 103 SW1(config-vlan)# private-vlan community ! 2. Create the primary VLAN and associate SW1(config)# vlan 100 SW1(config-vlan)# private-vlan primary SW1(config-vlan)# private-vlan association 101,102,103 ! 3. SVI on primary VLAN (gateway) SW1(config)# interface Vlan100 SW1(config-if)# ip address 10.10.0.1 255.255.255.0 SW1(config-if)# private-vlan mapping 101,102,103 ! 4. Promiscuous port (e.g., uplink to firewall) SW1(config)# interface Gi1/0/24 SW1(config-if)# switchport mode private-vlan promiscuous SW1(config-if)# switchport private-vlan mapping 100 101,102,103 ! 5. Isolated port (e.g., guest port) SW1(config)# interface Gi1/0/1 SW1(config-if)# switchport mode private-vlan host SW1(config-if)# switchport private-vlan host-association 100 101 ! 6. Community port (e.g., Customer A) SW1(config)# interface Gi1/0/5 SW1(config-if)# switchport mode private-vlan host SW1(config-if)# switchport private-vlan host-association 100 102 ``` The promiscuous port "maps" the primary VLAN to all secondaries it should reach. The host ports "associate" with one primary + one secondary pair. ## How frames flow ### Isolated host → another isolated host (same secondary 101) 1. Host A sends a frame to Host B's MAC. 2. Switch checks: source port is isolated (sec 101), destination port is also isolated. 3. **Block.** Frame dropped. Even though they're in the same IP subnet, the switch refuses to forward between two isolated ports. ### Isolated host → gateway (promiscuous) 1. Host A sends to gateway MAC. 2. Source isolated, destination promiscuous → **forward**. 3. Gateway can route the packet onward (to internet, to other subnets, etc.). ### Community host A → community host B (same secondary 102) 1. Same community → **forward**. They talk freely. ### Community host A (sec 102) → community host C (sec 103) 1. Different secondaries (different communities) → **block**. ## What PVLAN doesn't do - **Doesn't replace ACLs.** PVLAN isolates at Layer 2 — but if traffic reaches the gateway and the gateway routes it back into the same primary VLAN, it can land in another isolated port. Combine PVLAN with a **PACL** (private VLAN ACL) on the gateway interface to drop intra-primary traffic. - **Doesn't span all switches by default.** Trunks need PVLAN-aware mode. Cross-switch deployments are complicated; most deployments are single-switch or stacked-switch. - **Doesn't work on all platforms equally.** Catalyst supports it well. Some access switches don't support PVLAN at all. Check the data sheet. ## Verification ``` SW1# show vlan private-vlan Primary Secondary Type Ports ------- --------- ------------- ------------------- 100 101 isolated Gi1/0/1, Gi1/0/2 100 102 community Gi1/0/5, Gi1/0/6 100 103 community Gi1/0/10 100 Gi1/0/24 (promiscuous) SW1# show interfaces Gi1/0/1 switchport Name: Gi1/0/1 Switchport: Enabled Administrative Mode: private-vlan host Operational Mode: private-vlan host Administrative private-vlan host-association: 100 (PRIMARY) 101 (ISOLATED) ``` Functional test: from an isolated host, ping another isolated host's IP — should fail. Ping the gateway — should succeed. ## Alternative tools — when not to use PVLAN | Need | Tool | |---|---| | Per-port isolation, many hosts, one subnet | **PVLAN** | | Per-port isolation, want a separate broadcast domain per host | Per-host VLAN (works at small scale) | | Mac-based access policy | Port security, dot1x | | Identity-based segmentation | 802.1X + dynamic VLAN (or SGT — see [Cisco ISE](/topics/cisco-ise-basics/)) | | WAN-segmented multi-tenancy | MPLS L3VPN with VRFs | | Cloud-style fine-grained micro-segmentation | NSX / ACI / Calico / similar | PVLAN's sweet spot is "many endpoints, same subnet, must be isolated, on the same switch / stack." ## Common mistakes 1. **Forgetting the promiscuous mapping.** Promiscuous port needs the `switchport private-vlan mapping` line listing the secondaries it talks to. Without it, isolated/community hosts can't reach the gateway. 2. **No PACL on the gateway interface.** The router/firewall sees an isolated host's packet, routes it back into the same primary VLAN. Now isolated hosts can reach each other via the gateway. Add a PACL: `permit ip from 10.10.0.0/24 to 0.0.0.0/0; deny ip from 10.10.0.0/24 to 10.10.0.0/24`. 3. **Trying to span PVLAN across non-aware trunks.** Trunk between switches must understand PVLAN. Cisco's `private-vlan trunk` modes are tricky; many deployments avoid spanning at all. 4. **Using PVLAN when you actually need separate subnets.** If the customers need different DHCP scopes, different IP ranges, different routing policies — they need separate VLANs. PVLAN is for the "same subnet but isolated" case. 5. **Confusing isolated with community.** Isolated = "alone with the gateway." Community = "with my group + gateway." Choose deliberately. 6. **Mixing PVLAN with PortFast.** PortFast is fine, but BPDU Guard can err-disable a PVLAN host port if STP misbehaves. Test carefully. 7. **Not auditing what happens if traffic loops back via L3.** Layer 2 isolation can be bypassed by Layer 3 — the gateway can route between two of its own interfaces. PACL or appropriate firewall rules must catch this. ## Real-world hotel example A hotel has 200 rooms. The previous design: 200 VLANs (one per room), 200 /29 subnets — exhausting the IPv4 space and ten different VLAN trunks to configure. New design with PVLAN: - **Primary VLAN 200** — `10.50.0.0/22`, gateway `10.50.0.1`. - **Isolated secondary VLAN 201** — every guest port. - Promiscuous port on the gateway uplink. Every room jack is an isolated host in VLAN 201. Guests get DHCP from the gateway, browse the internet through the gateway. Two guests in the same hotel cannot reach each other. Total config = a handful of lines, not 200 VLANs. For staff who need to access an in-room thermostat over the network, put their devices in a **community** secondary that includes the thermostats. ## Lab to try tonight 1. One switch, one gateway router. 2. Create primary VLAN 100, secondary isolated 101, community 102. 3. SVI on the router/gateway: `10.10.0.1/24`. Promiscuous port = uplink. 4. Two host ports: Host A in isolated 101, Host B in isolated 101. 5. Verify: Host A ↔ Host B ping fails. Host A → gateway works. Host B → gateway works. 6. Move Host B to community 102. Add Host C also to community 102. Verify Host B ↔ Host C works. But Host A ↔ Host B still fails. 7. Now configure a PACL on the gateway to also block intra-subnet routing. Verify Host A can no longer reach Host B even via the gateway. 8. Bonus: enable port security on each host port. Bind to the host's MAC. Now if a guest swaps an unauthorized device, the port shuts down. ## Cheat strip | Concept | Plain English | |---|---| | **Private VLAN** | L2 isolation inside one subnet — many hosts, no inter-host traffic | | **Primary VLAN** | The visible VLAN ID. Holds promiscuous ports + SVI gateway | | **Secondary VLAN — Isolated** | Each port alone; talks only to promiscuous | | **Secondary VLAN — Community** | Group can talk to itself + promiscuous | | **Promiscuous port** | Talks to everyone. Used for gateway / shared services | | **Host port** | Either isolated or community. Where the endpoint plugs in | | **`private-vlan association`** | Primary VLAN lists its secondaries | | **`private-vlan mapping`** | Promiscuous port + SVI map to which secondaries they serve | | **PACL** | Apply on SVI to prevent Layer-3 leakage between isolated ports | | **Use cases** | Hotels, MDU, hosting, IoT, hospitals — same subnet, must not see each other | | **Trunking** | Spanning PVLAN across switches needs PVLAN-aware trunks. Often avoided | --- ## REST APIs for Network Engineers — https://packetmentor.com/topics/rest-apis/ > Modern Cisco devices expose REST APIs so you can configure them with HTTP requests and JSON instead of SSH and screen-scraping. Covers verbs (GET/POST/PUT/DELETE), authentication, data formats, and where REST fits in network automation. ## Mental model Old way: SSH into a router, type `show ip interface brief`, parse the text output with regex, hope the format doesn't change between IOS versions. New way: send `GET /restconf/data/ietf-interfaces:interfaces` to the router's HTTPS endpoint, get back structured JSON. Parse with one line of Python. No regex. No surprises when IOS updates. That's the elevator pitch for REST APIs. They turn network gear into something a normal application can talk to. ## The four verbs | Verb | What it does | Example | |---|---|---| | **GET** | Read state — no changes | `GET /interfaces` → list all interfaces | | **POST** | Create something new | `POST /vlans` with body `{"id": 10, "name": "USERS"}` | | **PUT** | Replace something entirely | `PUT /interfaces/Gi0/1` with full new config | | **DELETE** | Remove something | `DELETE /vlans/10` | There's also **PATCH** (partial update) but it's less common. For CCNA-level, know the big four. ## Status codes you'll actually see | Code | Meaning | Cause | |---|---|---| | 200 OK | Success, response body has data | GET worked | | 201 Created | Success, new resource made | POST worked | | 204 No Content | Success, nothing to return | DELETE worked | | 400 Bad Request | Your request was malformed | Bad JSON, missing field | | 401 Unauthorized | Credentials missing or wrong | Auth issue | | 403 Forbidden | You're authenticated but can't do this | Permissions | | 404 Not Found | The URL / resource doesn't exist | Wrong path | | 500 Internal Server Error | The device blew up | Device bug | The rule of thumb: **2xx = good. 4xx = your fault. 5xx = the device's fault.** ## A working example — get all interfaces from an IOS-XE device ### With `curl` ``` $ curl -k -u admin:cisco123 \ -H "Accept: application/yang-data+json" \ https://10.0.0.1/restconf/data/ietf-interfaces:interfaces ``` ### With Python ``` import requests from requests.auth import HTTPBasicAuth resp = requests.get( "https://10.0.0.1/restconf/data/ietf-interfaces:interfaces", auth=HTTPBasicAuth("admin", "cisco123"), headers={"Accept": "application/yang-data+json"}, verify=False, # ! test only — use proper certs in production ) print(resp.status_code) print(resp.json()) ``` ### What the response looks like (JSON) ``` { "ietf-interfaces:interfaces": { "interface": [ { "name": "GigabitEthernet0/0", "type": "iana-if-type:ethernetCsmacd", "enabled": true }, { "name": "GigabitEthernet0/1", "type": "iana-if-type:ethernetCsmacd", "enabled": false } ] } } ``` Parse with `resp.json()["ietf-interfaces:interfaces"]["interface"]` — done. No regex. ## Configure a device with POST Add a VLAN to a Catalyst running RESTCONF: ``` import requests requests.post( "https://10.0.0.1/restconf/data/Cisco-IOS-XE-vlan:vlan", auth=("admin", "cisco123"), headers={ "Accept": "application/yang-data+json", "Content-Type": "application/yang-data+json", }, json={"vlan-list": [{"id": 10, "name": "USERS"}]}, verify=False, ) ``` If the response code is 201, the VLAN now exists on the switch. Verify with a `show vlan brief` over SSH or another GET. ## Authentication Three flavors you'll meet: - **Basic auth** — username + password in every request. Simple. Used by most Cisco platforms for CCNA-level demos. - **API tokens** — generate a token once, send it as a header on every request. Used by Meraki, DNA Center, most modern Cisco platforms. - **OAuth 2.0** — token-with-refresh dance, common in big platforms. For CCNA-level prep, focus on basic auth and API tokens. ## Common mistakes 1. **Sending Content-Type wrong.** Posting JSON but forgetting `Content-Type: application/json` (or `application/yang-data+json` for RESTCONF). Device responds with 400 Bad Request. 2. **Reading the request body when the response code is non-2xx.** Always check `resp.status_code` first. The body of a 4xx response often has the actual error message. 3. **`verify=False` in production.** Disables HTTPS certificate validation. Fine in a lab; dangerous in production (man-in-the-middle attacks). Use proper certs. 4. **Hardcoding passwords in scripts.** Use environment variables or a secrets manager. Hardcoded creds in a Git repo is a career-limiting move. 5. **Not handling 401/403 errors.** Token expired? Permissions changed? Catch the error, refresh the token or log the issue. 6. **Polling instead of using webhooks.** Cisco DNA Center and Meraki support webhooks — the device pushes you events instead of you polling every minute. Use them when available. ## Lab to try tonight 1. Spin up an IOS-XE device in CML or use a sandbox at [devnetsandbox.cisco.com](https://devnetsandbox.cisco.com). 2. Enable RESTCONF: `(config)# restconf` + `ip http secure-server`. 3. From your laptop, send a GET to `/restconf/data/ietf-interfaces:interfaces`. Confirm you get JSON back. 4. Send a POST to create a new loopback interface. 5. GET again — verify the new interface appears. 6. DELETE the loopback. GET again — verify it's gone. 7. Bonus: write a Python script that bulk-shuts every interface that hasn't seen traffic in 30 days (real ops automation). ## Cheat strip | Concept | Plain English | |---|---| | **REST** | An architectural style for HTTP APIs | | **GET / POST / PUT / DELETE** | Read / create / replace / remove | | **2xx / 4xx / 5xx** | Success / your fault / server fault | | **JSON / XML** | The two body formats. Prefer JSON. | | **RESTCONF** | The Cisco-flavored REST API standard for network gear | | **NETCONF** | An older, XML-based API still widely used. Mentioned in CCNA exam topics. | | **API token** | An auth credential sent as a header — more secure than basic auth | | **`verify=False`** | Disables HTTPS cert validation. Lab use only. | --- ## Ansible for Network Engineers — https://packetmentor.com/topics/ansible/ > Push configuration to dozens of Cisco devices from one YAML playbook. Covers inventory, modules, idempotency, and why Ansible became the default automation tool for network teams who don't want to write a custom Python script for every change. ## Mental model You manage 30 Cisco switches. You need to add VLAN 50 to every one of them. Two options: 1. **SSH into each manually** — type the same 4 lines, 30 times, hope you don't fat-finger anything. 2. **Run an Ansible playbook** — describe the change once in YAML, push to all 30 in parallel, get a report. Ansible is option 2. It's **agentless** (you don't install anything on the switches), **declarative** (you describe the end state, not the steps), and **idempotent** (running it twice doesn't break anything — if VLAN 50 already exists, it just confirms and moves on). For network engineers in 2026, Ansible is the most common starting point for automation. More approachable than writing custom Python; more powerful than scripting SSH commands. ## The four core concepts 1. **Inventory** — a file listing all your devices, grouped however you want (by region, by role, etc.) 2. **Playbook** — a YAML file describing what you want done 3. **Module** — pre-built code that knows how to talk to a specific platform (Cisco IOS, NX-OS, Junos, etc.) 4. **Task** — one step in a playbook, calling one module with specific parameters ## Inventory — list of devices ``` # inventory.yml all: children: switches: hosts: sw1: ansible_host: 10.0.0.10 sw2: ansible_host: 10.0.0.11 sw3: ansible_host: 10.0.0.12 vars: ansible_network_os: ios ansible_user: admin ansible_password: cisco123 ansible_connection: network_cli ``` Anything you'd repeat (credentials, OS) goes in `vars` — applied to every host in the group. ## Playbook — describe the change ``` # add-vlan-50.yml - name: Add VLAN 50 to all switches hosts: switches gather_facts: no tasks: - name: Ensure VLAN 50 exists cisco.ios.ios_vlans: config: - vlan_id: 50 name: GUEST state: active state: merged ``` Read aloud: *"On every host in the 'switches' group, ensure VLAN 50 with name GUEST exists in 'active' state."* Run with: ``` $ ansible-playbook -i inventory.yml add-vlan-50.yml ``` Ansible connects to all switches in parallel, checks if VLAN 50 already exists, adds it if not, reports back. Output looks like: ``` PLAY [Add VLAN 50 to all switches] ****** TASK [Ensure VLAN 50 exists] ************ changed: [sw1] changed: [sw2] ok: [sw3] ← already had it, no change made PLAY RECAP ***** sw1 : ok=1 changed=1 unreachable=0 failed=0 sw2 : ok=1 changed=1 unreachable=0 failed=0 sw3 : ok=1 changed=0 unreachable=0 failed=0 ``` ## Idempotency — the killer feature Running the playbook a second time: ``` PLAY RECAP ***** sw1 : ok=1 changed=0 sw2 : ok=1 changed=0 sw3 : ok=1 changed=0 ``` No changes made. The playbook checked, found the state already matched the desired state, and did nothing. **This is what makes Ansible safe to re-run** — and what makes "drift detection" trivial: run your playbook in `--check` mode and any `changed` line tells you the device drifted from intended config. ## Common modules for Cisco gear | Module | What it does | |---|---| | `cisco.ios.ios_config` | Push raw config lines (universal but less idempotent) | | `cisco.ios.ios_vlans` | Manage VLANs declaratively | | `cisco.ios.ios_interfaces` | Interface basics (description, enabled, mtu) | | `cisco.ios.ios_l3_interfaces` | Layer-3 settings (IP addresses) | | `cisco.ios.ios_static_routes` | Static routes | | `cisco.ios.ios_command` | Run any show command, capture output | | `cisco.ios.ios_facts` | Gather device info (OS version, hostname, interfaces, etc.) | Prefer the **declarative resource modules** (`ios_vlans`, `ios_interfaces`) over raw `ios_config` when possible — they're more idempotent and produce cleaner diffs. ## Common mistakes 1. **Hardcoding credentials in the playbook.** Use Ansible Vault (`ansible-vault encrypt`) or environment variables. Never commit `ansible_password: secretvalue` to Git. 2. **Forgetting `gather_facts: no` on network playbooks.** Default Ansible tries to run a Python module on the target to gather facts. Network devices can't run Python. Skip facts unless you explicitly need them via `ios_facts`. 3. **Using `ios_config` for everything.** It works but generates messy diffs and can lose idempotency. Use resource modules where they exist. 4. **Running playbooks without `--check` first.** `--check` (also called dry-run) shows what *would* change without making changes. Always preview before applying to production. 5. **Not version-controlling playbooks.** Playbooks are infrastructure-as-code. Store them in Git, review changes in PRs. The whole point of automation is removing one-off manual operations. 6. **Misreading the OK count.** `ok=5 changed=0` means everything matched intended state. `ok=5 changed=3` means 3 things were modified. `failed=1` means stop and investigate. ## Lab to try tonight 1. Install Ansible on your laptop: `pip install ansible` (or use the official package for your OS). Also: `ansible-galaxy collection install cisco.ios`. 2. Spin up two Cisco IOS devices in CML or grab a DevNet sandbox. Enable SSH + a local user. 3. Write a minimal `inventory.yml` listing both devices. 4. Write a playbook that creates VLAN 100 with name TEST on both. Run with `--check` first, then for real. 5. Run the playbook a second time. Verify both hosts report `changed=0`. 6. Modify the playbook to also configure an SVI for VLAN 100 with an IP. Re-run. 7. Bonus: write a playbook that uses `ios_facts` to gather IOS version from each device and writes a report to a file. ## Cheat strip | Concept | Plain English | |---|---| | **Inventory** | List of devices, grouped | | **Playbook** | YAML file describing desired state | | **Module** | Pre-built code for a specific task | | **Task** | One step calling one module | | **Idempotent** | Re-running doesn't change unchanged things | | **--check** | Dry-run mode — show changes without applying | | **ansible-vault** | Encrypts sensitive values in playbooks | | **`changed`** | Task modified the device | | **`ok`** | Task succeeded (may or may not have changed) | | **`failed`** | Task hit an error — stop and investigate | --- ## JSON, YAML & XML for Network Engineers — https://packetmentor.com/topics/data-formats/ > The three data formats you'll meet doing network automation. JSON for APIs, YAML for configs/playbooks, XML for legacy and NETCONF. Same data, three syntaxes, different ergonomics. ## Mental model When two systems exchange data, they need a shared way to serialize structured information into text. The three formats you'll see in network automation: - **JSON** — JavaScript Object Notation. The de facto standard for REST APIs. - **YAML** — YAML Ain't Markup Language. Indentation-based. Reads almost like prose. - **XML** — eXtensible Markup Language. Verbose, tag-based. Legacy but still very much alive in NETCONF and SOAP APIs. All three describe the same kinds of things: - **Scalars** — strings, numbers, booleans, null - **Lists / arrays** — ordered sequence - **Maps / objects** — key-value pairs (also called dictionaries / hashes) The structure of your data is the same regardless of which format you serialize it as. Only the punctuation changes. ## Same data, three syntaxes ### JSON ``` { "hostname": "R1", "interfaces": [ { "name": "GigabitEthernet0/0", "ip": "10.0.0.1", "mask": "255.255.255.0", "enabled": true }, { "name": "GigabitEthernet0/1", "ip": null, "enabled": false } ] } ``` Properties of JSON: - Curly braces `{}` for objects, square brackets `[]` for arrays - String values must use double quotes - No comments allowed - No trailing commas allowed (until JSON5, but pure JSON forbids them) - Strict spec — easy for machines, slightly annoying for humans ### YAML ``` hostname: R1 interfaces: - name: GigabitEthernet0/0 ip: 10.0.0.1 mask: 255.255.255.0 enabled: true - name: GigabitEthernet0/1 ip: null enabled: false ``` Properties of YAML: - Indentation defines structure (spaces, not tabs) - Quotes mostly optional — `R1` and `"R1"` mean the same thing - Lists start with `- ` - Comments allowed with `#` - Designed for humans to read and write **YAML is a strict superset of JSON.** Every valid JSON document is also valid YAML. Lots of tools use this for flexibility — accept either. ### XML ``` R1 GigabitEthernet0/0 10.0.0.1 255.255.255.0 true GigabitEthernet0/1 false ``` Properties of XML: - Opening and closing tags for everything (`...`) - Attributes on tags (``) - Comments via `` - Verbose — every value has a paired closing tag - Schemas (XSD) provide strict validation ## Where you'll meet each one | Format | Where it's used | |---|---| | **JSON** | REST APIs (RESTCONF, Meraki, DNA Center, Webex, any modern Cisco API), JavaScript apps, NoSQL databases, config files for some tools | | **YAML** | Ansible playbooks + inventory, Kubernetes manifests, GitHub Actions / GitLab CI, Docker Compose, lots of static-site generators | | **XML** | NETCONF (RFC 6241), SOAP APIs, older Cisco automation, Microsoft AD ecosystem | For network engineers in 2026, the order of importance is roughly: **JSON > YAML > XML**. But you'll touch all three. ## Pitfalls per format ### JSON ``` { "hostname": "R1", // ← BAD: comments not allowed "interfaces": [ { "name": "Gi0/0", }, // ← BAD: trailing comma ], // ← BAD: trailing comma } ``` Either of these breaks JSON parsing. If you need comments or trailing commas, use YAML. ### YAML ``` hostname:R1 # ← BAD: missing space after colon interfaces: - name: Gi0/0 # ← BAD: tab used for indentation - name: Gi0/1 # ← BAD: 2-space indent vs 4-space mixed ``` Indentation is part of the language. Always use spaces (most editors auto-convert tabs to spaces in `.yml` files). Stay consistent — 2 or 4 spaces, pick one and never mix. **YAML's worst trap: implicit type coercion.** `version: 1.0` parses as a number `1.0`. `version: 1.10` also parses as `1.10` (a number) and stringifies as `1.1` — silently losing the `.10`. If you mean a string, quote it: `version: "1.10"`. ### XML ``` ``` Less ambiguous than YAML, but the verbosity makes it tedious to write by hand. In practice you generate XML programmatically from a template. ## Quick conversion tools When you need to translate between formats: | From → To | Tool | |---|---| | JSON ↔ YAML | `yq` (CLI tool, works like jq for YAML) | | JSON ↔ XML | Online converters, or Python: `xmltodict` | | Python dict ↔ any | `json.dumps()`, `yaml.dump()`, `xml.etree.ElementTree` | Example with Python: ``` import yaml, json # Read YAML, dump JSON with open("playbook.yml") as f: data = yaml.safe_load(f) print(json.dumps(data, indent=2)) ``` ## Common mistakes 1. **Mixing tabs and spaces in YAML.** Some lines use tabs, others spaces. YAML parsers silently misinterpret. Configure your editor to always use spaces for `.yml`. 2. **Forgetting to quote strings that look like numbers / booleans.** `version: 010` parses as octal in some YAML parsers. `key: yes` parses as boolean `true`. Quote ambiguous values. 3. **Trailing commas in JSON.** A constant source of `JSON parse error` issues. Use a linter (like `jq -e .` in CI) to catch them. 4. **XML namespace confusion.** XML has namespaces (`xmlns:abc="..."`) that change the meaning of tags. Easy to miss when writing by hand. Generate XML from templates rather than typing it. 5. **Treating all three as interchangeable.** Tools usually accept exactly one. RESTCONF expects JSON (or XML, depending on Accept header). Ansible expects YAML. NETCONF expects XML. Match what the consumer wants. 6. **Putting secrets in plaintext.** None of these formats encrypt anything. Use Ansible Vault (for YAML), encrypted Kubernetes secrets (for K8s YAML), or a separate secrets manager. Don't commit `password: cisco123` to Git. ## Lab to try tonight 1. Take the example JSON above. Convert it by hand to YAML and XML. Compare the line counts. 2. Use `yq` (or Python) to round-trip a file: YAML → JSON → YAML. Verify the structure survived. 3. Write a Python script that: - Reads an Ansible inventory in YAML - Adds a new host - Writes it back out 4. Send a `curl` request to a REST API (e.g. a Cisco DevNet sandbox) with `Accept: application/json` and again with `Accept: application/xml`. Compare the responses. 5. Open a Kubernetes YAML manifest. Find the YAML scalars, lists, and maps. Identify any quoted strings — what would happen if they weren't quoted? ## Cheat strip | Concept | Plain English | |---|---| | **JSON** | `{}`, `[]`, strict, REST APIs | | **YAML** | Indentation, comments allowed, Ansible / Kubernetes | | **XML** | `...`, verbose, NETCONF / legacy | | **Scalars** | strings, numbers, booleans, null | | **Lists / arrays** | ordered sequence | | **Maps / objects** | key-value pairs | | **JSON ⊂ YAML** | All valid JSON is valid YAML | | **Tabs vs spaces** | YAML wants spaces. Always. | | **`yq` and `jq`** | CLI tools for YAML and JSON manipulation | | **Secrets** | None of these encrypt — use Vault / secrets manager separately | --- ## NETCONF & YANG — https://packetmentor.com/topics/netconf-yang/ > The structured-data alternative to SSH-and-screen-scrape. Covers how NETCONF moves XML configs over SSH, what YANG models are, and where they fit alongside REST APIs in modern network automation. ## Mental model Imagine telling 50 devices "add VLAN 100" by SSHing into each and typing the commands. Painful. Modern alternative: send each device a structured XML document describing the change. The device parses it, validates against its schema, applies it transactionally, and reports back. No screen-scraping, no regex parsing, no surprises when IOS adds a column. Two pieces are involved: - **NETCONF** — the protocol. Carries the XML between client and device. Runs over SSH (TCP 830). - **YANG** — the schema language. Describes the structure of the data being moved. Vendor-neutral models like `ietf-interfaces` mean the same data shape works across Cisco IOS-XE, Juniper, and Arista. **RESTCONF** is the same concept exposed as a REST API (HTTP + JSON or XML, port 443). Same YANG models, different transport. For CCNA: know that NETCONF and YANG exist, what each does, and how they compare to REST APIs. You won't write them yet, but you need to recognize them. ## What a NETCONF exchange looks like Step 1 — client opens an SSH connection to TCP 830 on the device. Step 2 — both sides send `` messages advertising capabilities. Step 3 — client sends an `` (remote procedure call): ``` 100 USERS ``` Step 4 — device parses, validates, applies, replies: ``` ``` That's the full exchange. Verbose, but it's machine-to-machine — no human is meant to type it. ## YANG — the schema, in 90 seconds YANG is a modeling language. A YANG module describes the structure of configuration / operational data: what keys exist, what their types are, what's required vs optional, what constraints apply. Snippet of a YANG model for interfaces: ``` module ietf-interfaces { container interfaces { list interface { key "name"; leaf name { type string; } leaf type { type identityref { base interface-type; } mandatory true; } leaf enabled { type boolean; default true; } } } } ``` You don't write YANG models — vendors and standards bodies (IETF, OpenConfig) write them. You **consume** them: tools auto-generate API clients, the NETCONF / RESTCONF endpoints expose the corresponding data, and you write code against the model rather than against device-specific text. ## NETCONF vs REST API — which to use Both are valid in 2026. They overlap. | | NETCONF | RESTCONF / REST | |---|---|---| | **Transport** | SSH (TCP 830) | HTTPS (TCP 443) | | **Data format** | XML | JSON or XML | | **Operations** | get, get-config, edit-config, copy-config, delete-config | GET, POST, PUT, PATCH, DELETE | | **Transactions** | Yes — multi-step changes commit atomically | Limited — single resource per request | | **Streaming subscriptions** | Yes (RFC 5277, RFC 8639) | No (need a separate gNMI / webhooks) | | **Standard library support** | `ncclient` for Python | Any HTTP library | | **Best for** | Bulk transactional changes | Single reads/writes, simpler clients | Rule of thumb: **REST/RESTCONF for simple per-resource operations**, **NETCONF for atomic bulk changes** (e.g. "configure 100 interfaces or none"). ## Common Python tooling ### Talking NETCONF — `ncclient` ``` from ncclient import manager with manager.connect( host="10.0.0.1", port=830, username="admin", password="cisco123", hostkey_verify=False, ) as m: config = """ 200 GUEST """ response = m.edit_config(target="running", config=config) print(response) ``` ### Talking RESTCONF — `requests` ``` import requests requests.post( "https://10.0.0.1/restconf/data/Cisco-IOS-XE-native:native/vlan", auth=("admin", "cisco123"), headers={ "Accept": "application/yang-data+json", "Content-Type": "application/yang-data+json", }, json={"vlan-list": [{"id": 200, "name": "GUEST"}]}, verify=False, ) ``` Same change, two different transports. ## Enabling NETCONF / RESTCONF on Cisco IOS-XE ``` R1(config)# netconf-yang R1(config)# restconf ! Required for the REST endpoint to work R1(config)# ip http secure-server ``` Verify NETCONF is listening: ``` R1# show platform software yang-management process ``` ## Datastores — running vs candidate vs startup NETCONF distinguishes between several config datastores: - **running** — the live, active config on the device - **candidate** — a staging area for proposed changes (must explicitly `commit` to make them live) - **startup** — what reloads after a power cycle The candidate datastore is the killer feature for risky changes: ``` 1. edit-config target=candidate (propose changes) 2. validate (check syntax/semantics) 3. commit (apply atomically) 4. (if anything breaks) → discard-changes or rollback ``` Compare to traditional CLI: every command is immediately live, every typo is a production change. ## Common mistakes 1. **Confusing NETCONF and REST APIs.** They're both "automation APIs" but use different transports and message formats. NETCONF = SSH + XML. RESTCONF = HTTPS + JSON/XML. Pick the right one for the tool you're using. 2. **Trying to write YANG modules.** You consume vendor / standards models. You don't author them unless you're at a vendor or contributing to IETF working groups. 3. **Editing `running` directly without a backup.** Use `candidate` + commit when available. Cisco IOS-XE's `running` config edits are immediate — no candidate datastore by default (some platforms add one). 4. **Skipping certificate / host-key verification in production.** `hostkey_verify=False` and `verify=False` are fine in a lab. In production they're dangerous — a man-in-the-middle attacker could intercept config. 5. **Treating it like CLI just over a different transport.** NETCONF is transactional and structured. Edit a list of interfaces in one RPC, commit in one shot. Don't loop "edit-config one interface, commit, edit-config next interface" — defeats the point. 6. **Not validating before commit.** NETCONF's `` operation catches syntax/semantic errors before they hit `running`. Free safety net — use it. ## Lab to try tonight Use a Cisco DevNet sandbox (free IOS-XE sandbox available 24/7). 1. SSH to the sandbox. Verify NETCONF is enabled: `show platform software yang-management process`. 2. From your laptop, install `ncclient`: `pip install ncclient`. 3. Write a Python script that: - Connects via NETCONF - Issues `` - Prints the running config as XML 4. Try a small change: add a loopback interface via ``. Verify via SSH that it appeared. 5. Now do the same change via RESTCONF using `curl` or `requests`. Compare the two approaches. 6. Bonus: use `pyang` to download a Cisco YANG model and explore the schema. ## Cheat strip | Concept | Plain English | |---|---| | **NETCONF** | Protocol for getting / setting config via XML over SSH (TCP 830) | | **YANG** | Schema language describing the shape of the data | | **RESTCONF** | Same idea as NETCONF, exposed as a REST API over HTTPS | | **`edit-config`** | The "make a change" RPC | | **`get` / `get-config`** | Read operational state / read config | | **Datastores** | running / candidate / startup — different config states | | **`commit`** | Atomically apply candidate → running | | **`validate`** | Pre-commit syntax check | | **`ncclient`** | Python library for NETCONF | | **OpenConfig** | Vendor-neutral YANG models (Google-led) | | **IETF YANG** | Standards-body YANG models (e.g. ietf-interfaces) | --- ## Python for Network Engineers — https://packetmentor.com/topics/python-for-network-engineers/ > Why Python is the de-facto language for network automation, plus the four libraries you'll actually use — Netmiko (SSH), NAPALM (vendor-agnostic), Nornir (parallel runner), and requests (REST APIs). ## Mental model Network engineering used to be SSH, command, screen-scrape, repeat. That doesn't scale past a handful of devices. Python is the language of choice for replacing that workflow with code: - Easy syntax — closer to English than other languages - Massive ecosystem of network libraries - Runs on Windows, macOS, Linux, your laptop, a server, in CI - Same skills transfer to other automation (servers, cloud, security) You don't need to be a software engineer. You need to write small, useful scripts. 50 lines that update a thousand switches' SNMP community string in 30 seconds is real Python value. ## The four libraries you'll actually use | Library | Job | When to use | |---|---|---| | **Netmiko** | SSH to network devices, send commands | Quick scripts, multi-vendor SSH | | **NAPALM** | Vendor-agnostic operations (get facts, push config, rollback) | When you need cross-vendor compatibility | | **Nornir** | Parallel runner with built-in inventory | Running anything against many devices fast | | **requests** | HTTP / REST APIs | Modern APIs (Meraki, DNA Center, RESTCONF) | Plus `paramiko` (lower-level SSH — Netmiko uses it under the hood) and `ncclient` (NETCONF — see [NETCONF & YANG topic](/topics/netconf-yang/)). ## Hello world — read interface status from one device ``` from netmiko import ConnectHandler device = { "device_type": "cisco_ios", "host": "10.0.0.1", "username": "admin", "password": "cisco123", } with ConnectHandler(**device) as conn: output = conn.send_command("show ip interface brief") print(output) ``` That's a working network-automation script. Eight lines. Replace with `send_config_set(["interface gi0/0", "description WAN-link"])` to push config. ## Loop over many devices ``` from netmiko import ConnectHandler devices = [ {"device_type": "cisco_ios", "host": "10.0.0.1", "username": "admin", "password": "x"}, {"device_type": "cisco_ios", "host": "10.0.0.2", "username": "admin", "password": "x"}, {"device_type": "cisco_ios", "host": "10.0.0.3", "username": "admin", "password": "x"}, ] for dev in devices: with ConnectHandler(**dev) as conn: print(f"--- {dev['host']} ---") print(conn.send_command("show version | i Cisco IOS")) ``` Run it: takes ~30 seconds for 100 devices in serial. Use Nornir or `concurrent.futures` to parallelize down to ~3 seconds. ## NAPALM — vendor-agnostic NAPALM gives you a consistent API across Cisco IOS, NX-OS, Juniper, Arista, and others. Same code, different platform: ``` from napalm import get_network_driver driver = get_network_driver("ios") device = driver(hostname="10.0.0.1", username="admin", password="x") device.open() facts = device.get_facts() print(facts["model"], facts["os_version"]) interfaces = device.get_interfaces() for name, data in interfaces.items(): print(f"{name}: up={data['is_up']}") device.close() ``` Switch `"ios"` to `"junos"` and the script works against a Juniper router. NAPALM normalizes the differences. ## REST API — Cisco Meraki example ``` import requests api_key = "your-api-key" org_id = "your-org-id" resp = requests.get( f"https://api.meraki.com/api/v1/organizations/{org_id}/networks", headers={"X-Cisco-Meraki-API-Key": api_key}, ) networks = resp.json() for net in networks: print(net["id"], net["name"]) ``` Modern Cisco platforms (Meraki, DNA Center, ISE, Webex) all expose REST APIs. See [REST APIs for Network Engineers](/topics/rest-apis/) for the deeper dive. ## Parallel execution with Nornir Nornir is Python-native parallelism + inventory + plugin system. Same idea as Ansible but feels native (no YAML files for tasks). ``` from nornir import InitNornir from nornir_netmiko import netmiko_send_command nr = InitNornir(config_file="config.yaml") result = nr.run(task=netmiko_send_command, command_string="show ip int brief") for host, output in result.items(): print(f"--- {host} ---") print(output[0].result) ``` `InitNornir` reads `hosts.yaml` and `groups.yaml` (Ansible-style inventory). The `.run()` call executes in parallel — default 20 workers, configurable. ## Practical patterns you'll use ### 1. Bulk config audit ``` for dev in inventory: output = ssh.send_command("show running-config | i ^username") if "admin" not in output: print(f"ALERT: {dev['host']} missing admin user") ``` ### 2. Backup all configs to git ``` for dev in inventory: config = ssh.send_command("show running-config") open(f"backups/{dev['host']}.cfg", "w").write(config) # then: git add . && git commit -m "Daily backup" ``` ### 3. Templated config push ``` from jinja2 import Template template = Template(""" interface {{ interface }} description {{ description }} ip address {{ ip }} {{ mask }} no shutdown """) config = template.render( interface="Gi0/0", description="WAN to ISP-A", ip="203.0.113.1", mask="255.255.255.252", ).splitlines() ssh.send_config_set(config) ``` Jinja2 for templates is universal — Ansible uses the same templating engine. ## Common mistakes 1. **Hardcoding credentials.** Use environment variables or a secrets file you exclude from git: ``` import os password = os.environ["NETWORK_PASSWORD"] ``` 2. **No error handling.** SSH connections fail constantly (timeouts, wrong creds, device down). Wrap in `try/except`: ``` from netmiko.exceptions import NetMikoTimeoutException try: with ConnectHandler(**dev) as conn: ... except NetMikoTimeoutException: print(f"Could not reach {dev['host']}") ``` 3. **Pushing config without a backup or rollback plan.** Backup the running config first, push the change, verify the result, restore from backup if needed. 4. **Running on all 500 devices on the first try.** Start with one. Then ten. Then all of them. Mistakes at scale are expensive. 5. **Mixing Python 2 and Python 3.** Python 2 is end-of-life since 2020. Use Python 3.10+ for modern syntax, type hints, and library compatibility. 6. **Not using virtual environments.** `pip install` system-wide pollutes your machine. Always: ``` python3 -m venv venv source venv/bin/activate pip install netmiko napalm nornir requests ``` 7. **Treating output as freeform text forever.** Plain `send_command()` returns text you have to regex. Use NAPALM's `get_interfaces()` or device APIs that return structured JSON when possible. ## Lab to try tonight 1. Spin up a Cisco DevNet sandbox or two Cisco devices in CML. 2. `pip install netmiko` in a virtualenv. 3. Write a script that SSHes to one device and prints `show version`. Get it working with one device. 4. Add a second device. Loop over both. 5. Send a config change (e.g. `description test` on a loopback). Verify it stuck via SSH. 6. Add `try/except` for connection failures. 7. Switch to NAPALM and use `get_facts()`. Compare vs the raw text output. 8. Bonus: use Jinja2 to template a multi-line config from a dictionary of variables. Push it. ## Cheat strip | Library | What it does | |---|---| | **Netmiko** | SSH wrapper for multi-vendor — start here | | **NAPALM** | Vendor-agnostic ops — same code, different platforms | | **Nornir** | Inventory + parallel runner — pure Python alternative to Ansible | | **requests** | HTTP / REST APIs | | **ncclient** | NETCONF (XML over SSH) | | **paramiko** | Low-level SSH (used by Netmiko under the hood) | | **Jinja2** | Config templating | | **Virtualenv** | Isolated Python environment — always use one | | **Environment vars** | For secrets — never hardcode passwords | | **`try/except`** | Network operations fail. Wrap them. | --- ## SDN & Controller-Based Networking — https://packetmentor.com/topics/sdn-controllers/ > Software-Defined Networking explained. Why control plane and data plane were separated, what a network controller actually does, and where Cisco DNA Center, ACI, and Meraki fit in the landscape. ## Mental model Traditional networks: every switch and router contains both the **control plane** (the brain making routing decisions, running OSPF, building forwarding tables) and the **data plane** (the hardware that moves packets in nanoseconds). Each device decides for itself. This works but doesn't scale into the "I want to change everything everywhere at once" world. Pushing a single policy change across 200 devices means logging into each. **Software-Defined Networking (SDN)** moves the brains to a central **controller**. Devices keep their fast forwarding hardware but become "dumber" — they ask the controller (or are told by it) what to do. The controller has full visibility, applies policy from one place, and exposes APIs to applications and humans. ``` Apps & UI ← REST API (northbound) ↓ SDN Controller ← centralized brain ↓ Network Devices ← NETCONF / OpenFlow / gRPC / CLI (southbound) ``` That's it conceptually. The rest is variations on this separation. ## Northbound vs Southbound APIs | | What it is | Examples | |---|---|---| | **Northbound API** | How applications + humans talk **to** the controller | REST/JSON ("create a new VLAN everywhere") | | **Southbound API** | How the controller talks **to** the devices | NETCONF, OpenFlow, gRPC, RESTCONF, sometimes CLI | For CCNA: know the directions (north = up to apps, south = down to devices) and at least one example of each. ## Three Cisco SDN platforms you should recognize ### Cisco DNA Center (campus / enterprise) For campus networks — managing wired + wireless across an enterprise. Replaces the "log into each switch" workflow. - **Northbound**: REST API - **Southbound**: NETCONF, RESTCONF, SSH/CLI for legacy - **Use cases**: SD-Access (segmentation), policy automation, assurance/analytics - **Replaces**: APIC-EM (its predecessor) ### Cisco ACI / APIC (data center) For data centers. Different from DNA Center — uses Nexus 9000 switches and a different architecture (intent-based policy + ACI fabric). - **APIC** is the controller. Multiple APICs for HA. - **Application-centric** policy — describe what apps need, ACI figures out the network config. - **Southbound**: OpFlex protocol to leaf/spine switches. ### Cisco Meraki (cloud-managed) The controller lives in Meraki's cloud — you manage everything through a web dashboard, with the controller hosted as SaaS. - **No on-premises controller** to manage. - **Easy** for small/distributed orgs. - **Subscription model** — controller is a service you pay for. - **Limitations**: less flexible than DNA Center / ACI for complex requirements. For CCNA, recognize these names and the categories. Deep mastery isn't expected at CCNA-level. ## How SDN actually changes day-to-day work Old way (per-device CLI): ``` ssh sw1 configure terminal vlan 50 name USERS exit end write memory # repeat for sw2, sw3, sw4, ... ``` SDN way (push via controller): ``` POST /api/v1/networks/abc/vlans { "id": 50, "name": "USERS" } ``` One call, controller pushes to every relevant device, returns success/failure per device. Auditable, scriptable, idempotent (replay safe). ## Intent vs imperative Two styles of SDN configuration: | Style | What you say | Example | |---|---|---| | **Imperative** | "Configure interface Gi0/1 with these exact commands" | Traditional CLI / Ansible | | **Intent-based** | "Users in HR should be able to reach the file server" | DNA Center / ACI | Intent-based is the long-term direction. You describe the desired outcome ("HR should reach file server, finance should not"). The controller figures out which ACLs, VLANs, and policies need to land on which devices to make that true. Continuously enforced. ## OpenFlow — the original SDN southbound You'll hear about OpenFlow in textbooks. It was the protocol Stanford / ONF designed in the mid-2000s for **pure SDN**: the controller programs every flow-table entry on every switch. Vendor reality: most enterprise SDN today uses NETCONF/gRPC instead. OpenFlow lingers in some research / academic contexts and a few specific products. Know the name and history; don't expect to deploy it in production. ## Common mistakes 1. **Thinking SDN = automation.** They overlap but aren't the same. You can automate without SDN (Ansible + traditional devices). You can have SDN without it being fully automated. SDN is about *where the control plane lives*; automation is about *how config gets applied*. 2. **Assuming SDN means OpenFlow.** OpenFlow is one southbound protocol. Most enterprise SDN uses NETCONF, RESTCONF, gRPC, or hybrid CLI. "SDN" the concept is broader than "OpenFlow" the protocol. 3. **Expecting SDN to replace traditional skills.** A senior network engineer still needs to understand BGP, OSPF, switching. SDN abstracts the work but doesn't eliminate the need to understand what's underneath when it breaks. 4. **Underestimating the controller as a single point of failure.** A dead controller takes down policy management. Most platforms support HA controllers. Always check the controller's failure mode in production planning. 5. **Treating Meraki as identical to DNA Center.** Both are Cisco SDN, but their philosophies differ. Meraki = simple, cloud-managed, less flexible. DNA Center = on-prem, more powerful, steeper learning curve. Match to the use case. 6. **Skipping APIs because "I'm a network engineer, not a programmer."** Modern SDN demands API literacy. Curl + JSON + basic Python is the new RJ45 + console cable. Learn it — it's not optional anymore. ## Lab to try tonight Use a Cisco DevNet Always-On DNA Center sandbox (no reservation required): 1. Visit [devnetsandbox.cisco.com](https://devnetsandbox.cisco.com), find the DNA Center Always-On sandbox. Note the URL and credentials. 2. Open Postman or use curl. Authenticate to get a token: ``` curl -X POST https://sandboxdnac.cisco.com/dna/system/api/v1/auth/token \ -u devnetuser:Cisco123! \ -H "Content-Type: application/json" ``` 3. Use the token to list network devices: ``` curl -H "X-Auth-Token: " \ https://sandboxdnac.cisco.com/dna/intent/api/v1/network-device ``` 4. Get a JSON response listing every device DNA Center manages — model, serial, IOS version, uptime. 5. Explore the API docs at [developer.cisco.com/dnacenter](https://developer.cisco.com/dnacenter) — list interfaces, VLANs, etc. 6. Bonus: write a Python script that pulls all device hostnames + IPs and prints a CSV report. ## Cheat strip | Concept | Plain English | |---|---| | **SDN** | Software-Defined Networking — separate control from data plane | | **Controller** | The brain — makes decisions, exposes APIs | | **Northbound API** | App/UI → controller — usually REST | | **Southbound API** | Controller → devices — NETCONF, OpenFlow, gRPC, CLI | | **DNA Center** | Cisco's campus / enterprise SDN platform | | **ACI / APIC** | Cisco's data center SDN platform (Nexus + APIC) | | **Meraki** | Cisco's cloud-managed SDN — no on-prem controller | | **Intent-based** | Describe outcome, controller figures out config | | **OpenFlow** | Original SDN southbound — academic now | | **Single point of failure** | Controller HA matters in production | --- ## gRPC & gNMI — Streaming Telemetry — https://packetmentor.com/topics/grpc-gnmi-telemetry/ > The modern alternative to SNMP polling. Devices stream structured data continuously to a collector over gRPC. Covers gNMI for config and monitoring, why streaming beats polling, and what's replacing SNMP in real networks. ## Mental model [SNMP](/topics/snmp/) is poll-based: every few minutes, the management station asks each device "what's your CPU? interface octets? memory?" Each round of polls floods devices with queries and produces metrics with 1-5 minute resolution. **Streaming telemetry** turns this around. The device opens a persistent connection to a collector and **pushes** structured data continuously — sometimes every second, sometimes on-change. The collector just receives. Benefits over SNMP: - **Sub-second resolution** (vs SNMP's minute-scale polling) - **Lower load on devices** — push once, instead of answering hundreds of polls - **Structured payloads** — protobuf instead of OIDs you have to look up - **Modern tooling** — works with Kafka, InfluxDB, Splunk, Grafana out of the box The cost: more bandwidth to the collector, more state to manage. For real-time analytics, observability, capacity planning — streaming is the right answer in 2026. ## The technology stack | Layer | Component | |---|---| | Transport | TCP, usually TLS-encrypted | | Protocol | HTTP/2 | | RPC framework | **gRPC** (Google's high-performance RPC) | | Payload format | **Protocol Buffers (protobuf)** — compact, schema-driven binary | | Network mgmt API | **gNMI** (gRPC Network Management Interface) | | Data model | **YANG** (same as NETCONF) | So when you see "gNMI/gRPC streaming telemetry" — that's gNMI on top of gRPC on top of HTTP/2 on top of TLS/TCP, with YANG-modeled protobuf payloads. ## gNMI operations gNMI defines four core RPCs: | RPC | Purpose | Like NETCONF's | |---|---|---| | **Get** | One-shot read | `` or `` | | **Set** | Modify config | `` | | **Capabilities** | What does this device support? | `` | | **Subscribe** | Streaming telemetry | (new — NETCONF didn't have this until RFC 8639) | The **Subscribe** RPC is the killer feature. It establishes a long-running stream where the device pushes data as it changes (or on a schedule). Three subscription modes: | Mode | Behavior | |---|---| | **SAMPLE** | Push every N milliseconds (regular interval) | | **ON_CHANGE** | Push only when the value changes | | **TARGET_DEFINED** | Device picks the optimal mode per path | For interface counters: SAMPLE every 1s. For interface state (up/down): ON_CHANGE — most efficient. ## Why protobuf instead of JSON gRPC payloads use Protocol Buffers — Google's binary serialization format. Compared to JSON: - **Smaller wire size** — typically 30-50% the bytes of equivalent JSON - **Faster to parse** — compiled schema, no string-to-type conversion - **Schema-driven** — `.proto` files define the structure; both sides know what they're sending Trade-off: you can't `tail -f` a protobuf stream the way you can a JSON log. You need a decoder. Tools like `grpcurl` handle this. ## A working example — gNMI Subscribe with gnmic `gnmic` is the open-source CLI for gNMI (developed by Cisco/Nokia). ``` $ gnmic -a 10.0.0.1:6030 \ -u admin -p cisco123 \ --insecure \ subscribe \ --path "/interfaces/interface[name=Ethernet1]/state/counters/in-octets" \ --sample-interval 5s ``` Output: every 5 seconds, the current `in-octets` counter for Ethernet1, streamed in real time. Pipe to InfluxDB / Prometheus / a Python script. The exact same path syntax (XPath-style over YANG models) you'd use in NETCONF, but with streaming. ## Cisco platform support | Platform | gNMI / Streaming Telemetry | |---|---| | **IOS-XR** | First-class support since 6.0 | | **IOS-XE** | Supported since 16.6 (Catalyst 9000, ISR4000) | | **NX-OS** | Supported since 7.0(3)I7 | | **Older IOS classic** | No — stuck with SNMP | If you're running modern Catalyst 9300/9500, ISR4400, ASR9000, Nexus 9300 — streaming telemetry is available. Enable it. ### Enable on Cisco IOS-XE ``` R1(config)# grpc port 50051 R1(config)# telemetry ietf subscription 100 R1(config-mdt-subs)# encoding encode-kvgpb R1(config-mdt-subs)# filter xpath /interfaces-ios-xe-oper:interfaces/interface/statistics R1(config-mdt-subs)# stream yang-push R1(config-mdt-subs)# update-policy periodic 1000 ! 10 seconds (in centiseconds) R1(config-mdt-subs)# receiver ip address 10.0.99.5 57500 protocol grpc-tcp ``` Now the device pushes interface statistics to the collector every 10 seconds. The collector (a gRPC server listening on 10.0.99.5:57500) ingests. ## Tools to know | Tool | Use | |---|---| | **gnmic** | CLI for gNMI Get/Set/Subscribe operations | | **grpcurl** | Generic gRPC CLI — like curl but for gRPC | | **gNMI Python client** | Native Python bindings for scripting | | **InfluxDB / Telegraf** | Time-series storage + ingester | | **Grafana** | Dashboard tool, reads from InfluxDB / Prometheus | | **Cisco Crosswork** | Cisco's commercial telemetry collector + analyzer | | **Telegraf + cisco_telemetry_mdt plugin** | Open-source collector for Cisco MDT | ## Common mistakes 1. **Trying to subscribe to too many paths at once.** Each subscription consumes resources. Start with a few key metrics; expand as you confirm device + collector can handle it. 2. **Mismatched encoding.** Cisco supports several payload encodings (JSON, kvGPB, GPB). Subscriber and collector must agree. `kvgpb` is the most common for IOS-XE. 3. **No collector listening.** Subscriptions are established on the device side; if no collector is reachable, the device silently fails. Always verify the collector socket first. 4. **Reading data and not aggregating.** Streaming gives you raw points every second. Without aggregation (a time-series database like InfluxDB), you'll drown in data. Plan storage and aggregation. 5. **Treating it as a drop-in for SNMP.** Streaming is fundamentally different — push vs pull, structured vs OID. Your monitoring tool may need rework, not just a config change. 6. **Skipping TLS.** Streaming telemetry can flow plain or TLS. In production: TLS always. Plain only for lab. ## Lab to try tonight Use Cisco DevNet sandbox with IOS-XE (Catalyst 9300 sandbox available). 1. Install `gnmic` on your laptop: `brew install gnmic` (macOS) or download the binary. 2. Verify the device supports gNMI: `gnmic -a :50052 --insecure capabilities`. 3. Try a simple Get: `gnmic -a :50052 --insecure get --path "/interfaces"`. 4. Subscribe: `gnmic ... subscribe --path "/interfaces/interface[name=GigabitEthernet0/0]/state/counters" --sample-interval 5s`. 5. Watch counters stream in real time. 6. Configure a Telegraf collector with the cisco_telemetry_mdt input plugin. Point the device at it. 7. Visualize the data in Grafana. ## Cheat strip | Concept | Plain English | |---|---| | **gRPC** | Google's high-performance RPC framework over HTTP/2 | | **gNMI** | gRPC Network Management Interface — config + telemetry | | **Streaming telemetry** | Device pushes data continuously to collector | | **Subscribe modes** | SAMPLE (interval) · ON_CHANGE · TARGET_DEFINED | | **protobuf** | Compact binary serialization — faster + smaller than JSON | | **YANG** | Same data model as NETCONF | | **gnmic** | CLI tool for gNMI | | **Replaces** | Mostly SNMP polling, eventually | | **Cisco support** | IOS-XR (full), IOS-XE 16.6+, NX-OS 7.0(3)I7+ | | **Default port** | TCP 50051 (gNMI) — also 57500 for some collectors | --- ## SD-WAN Concepts — https://packetmentor.com/topics/sd-wan-concepts/ > Software-Defined WAN explained — separating control plane from data plane, overlay tunnels across any underlay (MPLS, internet, LTE), centralized policy via vManage/vSmart, and why the WAN is finally getting the SDN treatment. ## Mental model Traditional WAN: each branch has a router. Each router runs OSPF/BGP. Each router has hand-built IPsec tunnels to the DC. To add a new site, an engineer configures 20+ lines on every existing site, plus the new site. To change a routing policy, repeat across every device. Expensive, slow, error-prone. **SD-WAN's pitch:** treat the WAN as one logical fabric controlled by software. Each branch router (`cEdge`) only needs to know: *"reach a controller, accept policy, build tunnels as instructed."* The controllers (`vSmart`) push routing and policy from one central GUI. It's SDN, applied to the WAN. Same separation of planes as [SDN Controllers](/topics/sdn-controllers/), but tuned for branch WAN problems: cost, transport diversity, application-aware routing, central management. ## The Cisco SD-WAN architecture (Viptela-based) Four planes, four products: | Plane | Component | Role | |---|---|---| | **Management** | **vManage** | GUI + REST API. Where humans + automation configure everything. | | **Control** | **vSmart** | Routing brain. Builds OMP (Overlay Management Protocol) routes. Pushes policy. | | **Orchestration** | **vBond** | Onboarding. New devices reach vBond first; vBond points them at vSmart + vManage. | | **Data** | **cEdge** / **vEdge** | Branch routers / DC routers. Build IPsec tunnels and forward packets. | ``` ┌─────────┐ ┌─────────┐ ┌─────────┐ │ vManage │ │ vSmart │ │ vBond │ (controllers — VMs or SaaS) └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ ╔════════╧═════════════╧══════════════╧════════╗ ║ DTLS/TLS control tunnels ║ ╚═══╤══════════════╤══════════════╤═════════════╝ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ cEdge HQ│ │cEdge BR1│ │cEdge BR2│ (data plane) └────┬────┘ └────┬────┘ └────┬────┘ └──IPsec────────┴───IPsec──────┘ (overlay tunnels between sites) over MPLS, internet, LTE… (underlay = any transport) ``` ## Underlay vs overlay — the key concept **Underlay** = the physical/IP network you bought from carriers. MPLS from Provider A, internet broadband from Provider B, LTE backup from Provider C. Each branch may have multiple. **Overlay** = the IPsec tunnels SD-WAN builds **across** the underlay. From the apps' perspective, there's one flat network. The underlay is invisible. This decoupling means: - Branch can use **any combination** of transports. - SD-WAN picks the best path **per application** (voice → MPLS, web → internet, backup → LTE). - Adding a new MPLS provider doesn't change app routing — just adds a path. ## OMP — the SD-WAN routing protocol Branch routers don't run BGP/OSPF with each other across the WAN. They each peer with **vSmart** over a DTLS tunnel and exchange routes via **OMP** (Overlay Management Protocol). vSmart acts like a route reflector. cEdge A says: *"I can reach 10.10.0.0/16 via tunnel TLOC-A1."* vSmart redistributes that to all other cEdges that policy says should see it. **TLOC** = Transport Locator. Tuple of `(system-ip, transport-color, encapsulation)`. It identifies a specific transport endpoint on a specific router. Think "site router has 3 internet uplinks → 3 TLOCs." ## Application-aware routing You define a policy like: ``` Application class: VOICE Preferred path: MPLS Fallback: Internet if MPLS jitter > 30ms or loss > 1% Application class: BACKUP Preferred path: Internet Fallback: never use MPLS (cost) Application class: SAAS (M365, Salesforce) Direct internet break-out at branch (DIA) ``` vSmart pushes this to every cEdge. Each cEdge measures **per-path SLA** continuously and switches actively if MPLS quality drops. This is the killer feature: traditional WAN routes by destination prefix; SD-WAN routes by **application and SLA**. ## Zero-touch provisioning (ZTP) How a new branch site comes up: 1. Engineer ships an SD-WAN router to the branch with no config. Local IT just plugs in WAN + LAN. 2. Router boots, gets DHCP from the ISP. 3. Router calls home to **vBond** (a well-known cloud address — Cisco PnP Connect for SD-WAN). 4. vBond authenticates the router via certificate, gives it the address of **vSmart** and **vManage**. 5. Router establishes DTLS to vManage. vManage pushes the site's config template (variables filled in from the device serial number). 6. Router establishes DTLS to vSmart. Routes flow. Overlay tunnels build. 7. Branch is online — typically in minutes, with no engineer on-site. This is the major operational win over traditional WAN. ## Where SD-WAN intersects with security - **Direct Internet Access (DIA)** at branch — SaaS traffic doesn't backhaul to HQ. Faster for users but requires branch-side security: cloud-delivered firewall (Cisco Umbrella, Zscaler, Prisma), or on-router NGFW. - **All overlay tunnels are IPsec** — no need to manually build site-to-site VPNs. - **Segmentation** — cEdges support VRFs / service VPNs. Guest Wi-Fi, IoT, corporate traffic can be isolated end-to-end. This is the SD-WAN → SASE evolution: pulling cloud-delivered security into the SD-WAN fabric. ## Cisco SD-WAN variants - **Viptela / vManage** — the dedicated SD-WAN stack (cEdge or vEdge devices). Most enterprise deployments. - **Meraki SD-WAN** — Meraki MX appliances with cloud-managed SD-WAN. Simpler, more "SMB-friendly." - **Catalyst SD-WAN** — Cisco's 2024+ rebrand of Viptela. Same products, new name. CCNA blueprint touches SD-WAN at a "describe" level — you need to know: - It exists, separates control from data. - It uses overlay tunnels over any underlay. - It enables centralized policy + zero-touch. - The vManage / vSmart / vBond / cEdge role split (Cisco-specific, but widely tested). ## Traditional WAN vs SD-WAN — side-by-side | Aspect | Traditional WAN | SD-WAN | |---|---|---| | **Config** | Per-device CLI | Central GUI + templates | | **New site** | Days / weeks | Minutes (ZTP) | | **Transport** | MPLS only (typically) | MPLS + internet + LTE — any combo | | **Policy change** | Touch every device | Click in vManage | | **App routing** | By destination | By app + SLA | | **Cost** | MPLS-heavy | Mix of cheap broadband + MPLS | | **Monitoring** | SNMP, syslog, per-device | Centralized real-time dashboard | | **Security** | Hub-spoke through HQ firewall | DIA + cloud security (SASE) | ## Common mistakes 1. **Treating SD-WAN as "IPsec automation."** It does that, but the value is centralized policy + app-aware routing. Replacing manual IPsec with automated IPsec is the *least* important benefit. 2. **Skimping on underlay diversity.** SD-WAN's resilience comes from having more than one underlay. If every branch is single-homed MPLS, you've gained zero failover capacity. 3. **Forgetting WAN insertion of cloud security.** DIA without a cloud firewall = branches with direct, unfiltered internet. Always pair DIA with Umbrella/Zscaler/equivalent. 4. **Underestimating bandwidth needs for low-latency apps.** App-aware routing helps, but if both paths are saturated, no amount of SD-WAN cleverness fixes a sized-too-small link. 5. **Skipping the certificate/PKI step.** Every controller and edge has its own cert. PKI breakage = whole overlay goes down. Plan cert rotation early. 6. **Assuming vendor lock-in is free.** SD-WAN appliances are tied to their controller stack. Switching from Cisco SD-WAN to VMware VeloCloud is a full forklift. ## Lab to try (longer than tonight) 1. Cisco DevNet Sandbox has free reservable Cisco SD-WAN labs (Catalyst SD-WAN / Viptela). Spin one up. 2. Log into vManage. Find the topology view — see your simulated cEdges and the overlay between them. 3. Open one cEdge's CLI. `show sdwan control connections` — observe the DTLS tunnels to vSmart, vBond, vManage. 4. Run `show sdwan omp routes` — OMP-learned routes, much like a BGP table but for the SD-WAN fabric. 5. Run `show sdwan bfd sessions` — bidirectional forwarding detection sessions per TLOC pair. This is what powers per-path SLA detection. 6. In vManage, define an application-aware routing policy: prefer MPLS for voice, internet for SaaS. Push it. Watch a cEdge's per-app stats change. 7. Bonus: shutdown one transport on a cEdge. Watch traffic re-pin to the surviving path in seconds. ## Cheat strip | Term | Plain English | |---|---| | **Underlay** | The physical IP transports (MPLS, internet, LTE) | | **Overlay** | The IPsec tunnels SD-WAN builds across the underlay | | **vManage** | GUI + REST API. Where you configure everything | | **vSmart** | Control plane. Distributes routes and policy via OMP | | **vBond** | Orchestrator. New devices call here first | | **cEdge / vEdge** | The branch / DC router itself. Data plane | | **OMP** | Overlay Management Protocol — SD-WAN's routing protocol | | **TLOC** | Transport Locator — identifies a specific transport endpoint | | **ZTP** | Zero-Touch Provisioning — ship the box, plug it in, it auto-onboards | | **DIA** | Direct Internet Access at the branch — SaaS doesn't hairpin | | **App-aware routing** | Per-application path selection based on live SLA | | **SASE** | SD-WAN + cloud security — the natural next step | | **Where it fits in CCNA** | "Describe" level — know the controllers, the planes, the value prop | --- ## MPLS Basics — https://packetmentor.com/topics/mpls-basics/ > Multi-Protocol Label Switching demystified — labels instead of IP lookups, label distribution (LDP), the P/PE/CE model, MPLS L3VPN, and why MPLS still dominates the WAN backbone. ## Mental model Traditional IP routing makes a forwarding decision **at every hop**. Each router looks up the destination IP in its routing table, finds the longest-prefix match, picks an outgoing interface, and forwards. This works but has limits: - Longest-prefix match is expensive at internet scale (millions of routes). - You can't easily steer traffic — routing follows the IGP, period. - Mixing customers' overlapping IP space on one network is hard. **MPLS** solves all three by adding a short label between Layer 2 and Layer 3. Once a packet is **labeled** at the edge, every core router just **looks at the label, swaps it, forwards** — no IP lookup at all. The label can also carry information about *which* customer, *which* path, *which* QoS class. That's the whole idea: **lookup IP once at the edge, label-swap through the core**. ## The label A 32-bit (4-byte) header inserted between the Layer 2 frame header and the Layer 3 packet: ``` [ Ethernet ] [ MPLS Label ] [ IP Header ] [ Payload ] ^^^^^^^^^^^^ 20-bit label + 3-bit Exp (QoS) + 1-bit S (stack-bottom) + 8-bit TTL ``` EtherType `0x8847` (unicast) or `0x8848` (multicast) on the frame tells receivers this is MPLS. Multiple labels can stack — used for L3VPN (outer label = transport, inner label = VRF), Traffic Engineering, and FRR. The S bit marks the bottom of the stack. ## The three roles — CE / PE / P ``` ┌── Provider MPLS Core ──┐ │ │ Customer1 ──[CE1]──[PE1]──[P1]──[P2]──[PE2]──[CE2]── Customer1 (same customer, different site) Customer2 ──[CE3]──[PE1]──┘ └──[PE2]──[CE4]── Customer2 ``` - **CE (Customer Edge)** — the customer's router. Knows nothing about MPLS. Speaks IGP/BGP to its PE as normal. - **PE (Provider Edge)** — the provider's edge router. Does the heavy lifting: VRFs per customer, MP-BGP to other PEs, label imposition at ingress / disposition at egress. - **P (Provider Core)** — the provider's transit router. Label-swap only. No customer-specific knowledge. Doesn't run BGP. Fast. This is the **PE/P separation** — provider edge handles complexity, provider core stays simple and fast. ## Label distribution — LDP How do routers learn what label to use for what destination? Two main protocols: | Protocol | What it does | |---|---| | **LDP** (Label Distribution Protocol) | Distributes labels for IGP routes. Most common. | | **RSVP-TE** (Resource Reservation Protocol with TE) | Distributes labels along *engineered* paths. Used for Traffic Engineering. | | **MP-BGP** | Distributes VPN labels (inner label of the stack). | LDP forms adjacencies between directly-connected LSRs (Label Switch Routers — basically every MPLS-enabled router) and advertises: *"To reach 10.1.1.0/24, use label 17 when sending to me."* A device builds a **LFIB** (Label Forwarding Information Base) — like a routing table but indexed by incoming label rather than destination IP. ## The forwarding action — label swap The core operation: 1. Packet arrives at P1 with incoming label = 17. 2. P1 looks up label 17 in LFIB → outgoing label = 23, outgoing interface = Gi0/2. 3. P1 **swaps** 17 → 23 and forwards. No IP lookup. No longest-prefix match. Just a hash-table lookup by label. Implemented in ASIC at line rate. ## Penultimate hop popping (PHP) A small optimization. The router **one hop before** the egress PE pops the label entirely, so the egress PE receives a plain IP packet — saves it one lookup. The egress PE signals this by advertising **label 3 (implicit-null)** to the penultimate hop: *"don't bother labeling — I'll do the IP lookup anyway."* ## MPLS L3VPN — the killer use case **The problem:** Customer A and Customer B both use `10.0.0.0/8` internally. They both connect to your provider network. Without VPNs, routes would overlap chaotically. **The solution — VRF + MP-BGP:** 1. On each PE, create a **VRF** (Virtual Routing and Forwarding instance) per customer. Each VRF has its own private routing table. 2. CE-PE exchanges routes normally (OSPF, BGP, static — depends on customer). 3. PE-PE exchanges routes via **MP-BGP** with a special address family `VPNv4` — routes carry a **Route Distinguisher (RD)** that makes them globally unique (e.g., `65000:1:10.0.0.0/24` instead of just `10.0.0.0/24`). 4. PEs use **Route Targets (RTs)** to control which routes leak into which VRFs. 5. Forwarding uses two labels: - **Outer label** = transport label (LDP-learned), tells the core how to reach the egress PE. - **Inner label** = VPN label (BGP-learned), tells the egress PE which VRF to deliver into. A customer's CE doesn't know it's running on MPLS. It just sees a private routing exchange with its PE. ``` [Eth][outer label][inner label][IP packet (customer VRF)][payload] └─ identifies VRF on egress PE └─ steers across the provider backbone via LDP/RSVP-TE ``` ## Traffic Engineering (RSVP-TE) Vanilla MPLS follows the IGP — same path as IP would take. **MPLS-TE** lets you override that. Use case: You have two paths between PE1 and PE2 — one short (low capacity), one long (high capacity). IGP picks the short one. With TE, you signal an **explicit LSP** (Label Switched Path) over the long route — useful for bandwidth, latency, or fast-reroute purposes. CCNA doesn't drill on this — just know it exists. ## L2VPN — point-to-point and VPLS MPLS can also transport **Layer 2** frames end-to-end: - **EoMPLS / Pseudowire** — point-to-point Ethernet tunnel. Two sites think they're on the same Ethernet cable. - **VPLS** (Virtual Private LAN Service) — multipoint L2. Many sites feel like one bridged LAN. Customers like this for use cases that need Layer 2 adjacency (mainframe legacy, broadcast-dependent apps). ## Configuration — a tiny PE example (Cisco IOS-XR/XE) ``` ! Enable LDP PE1(config)# mpls ldp PE1(config-mpls-ldp)# router-id 10.255.255.1 ! Enable MPLS on the core-facing interfaces PE1(config)# interface Gi0/1 PE1(config-if)# mpls ip PE1(config-if)# mpls label protocol ldp ! Create a customer VRF PE1(config)# vrf definition CUSTOMER-A PE1(config-vrf)# rd 65000:1 PE1(config-vrf)# address-family ipv4 PE1(config-vrf-af)# route-target export 65000:1 PE1(config-vrf-af)# route-target import 65000:1 ! Bind the customer-facing interface to the VRF PE1(config)# interface Gi0/2 PE1(config-if)# vrf forwarding CUSTOMER-A PE1(config-if)# ip address 192.168.10.1 255.255.255.0 ! MP-BGP to the other PE PE1(config)# router bgp 65000 PE1(config-router)# neighbor 10.255.255.2 remote-as 65000 PE1(config-router)# neighbor 10.255.255.2 update-source Loopback0 PE1(config-router)# address-family vpnv4 PE1(config-router-af)# neighbor 10.255.255.2 activate ``` ## Verification ``` PE1# show mpls interfaces PE1# show mpls ldp neighbor PE1# show mpls forwarding-table PE1# show ip route vrf CUSTOMER-A PE1# show bgp vpnv4 unicast all summary PE1# show bgp vpnv4 unicast all ! see VPNv4 routes with RD prefixes PE1# ping vrf CUSTOMER-A 192.168.20.1 PE1# traceroute mpls ipv4 10.255.255.2/32 ! end-to-end label trace ``` ## MPLS vs SD-WAN — the modern context For 20 years MPLS dominated enterprise WAN: SLA-backed, low-latency, QoS-guaranteed. The downside: expensive ($/Mbps) and slow to add new sites. SD-WAN ([SD-WAN Concepts](/topics/sd-wan-concepts/)) eats into the use case by using **internet + IPsec overlay** to deliver "good enough" WAN at a fraction of the cost. Modern designs mix both: MPLS for SLA-bound voice/transactional traffic, internet for SaaS and bulk. MPLS isn't going away — service-provider cores and large enterprise WANs still run on it — but for branch-to-cloud connectivity, SD-WAN is winning. ## Common mistakes 1. **Confusing MPLS L3VPN with a customer's own VPN.** L3VPN is *the provider's* fabric — the customer just gets a private routing service. Customer-side IPsec is something else entirely. 2. **Running BGP on the P routers.** Provider core (`P`) should never carry BGP — keep it lean with only IGP + LDP. BGP belongs at the PE. 3. **VRF without the corresponding interface.** A `vrf forwarding` line under the interface is what binds the link to that VRF. Forgetting it leaves the interface in the global table. 4. **Mismatching Route Targets.** Importing the wrong RT means the customer doesn't see remote-site routes. Always document export/import pairs. 5. **Not advertising loopbacks into LDP.** LDP needs the BGP next-hop (typically the remote PE's loopback) to be reachable via an LDP-labeled path. If the loopback isn't in the IGP, LDP has nothing to label. 6. **Penultimate-hop popping gotchas.** PHP changes the TTL accounting — `traceroute` across MPLS sometimes hides hops. Use `traceroute mpls` for accurate visibility. 7. **Treating MPLS as encrypted.** It's not. MPLS is a forwarding plane, not a security plane. If you need confidentiality, you still need IPsec on top. ## Lab to try tonight 1. Cisco DevNet Sandbox has free MPLS L3VPN labs. Spin one up — or build it in CML/EVE-NG with 4 routers (2 PE, 2 P, plus 2 CE). 2. Run OSPF in the provider core (P + PE loopbacks). 3. Enable `mpls ip` on every core link. Verify LDP neighbors with `show mpls ldp neighbor`. 4. Create one VRF on each PE for CUSTOMER-A. Configure CE-PE static or BGP routing. 5. Configure MP-BGP between the two PE loopbacks with VPNv4 address-family. 6. From CE1, ping CE2 — packets traverse the labeled path. Verify with `show mpls forwarding-table` along the way. 7. Bonus: `traceroute mpls` end-to-end and watch the label stack progression. 8. Bonus: shut a core link → routing reconverges, LDP relearns, but with TE you could pre-signal a backup LSP for sub-second failover. ## Cheat strip | Concept | Plain English | |---|---| | **MPLS** | Multi-Protocol Label Switching. Lookup once at edge, label-swap in core | | **Label** | 4-byte header inserted between L2 and L3 | | **CE / PE / P** | Customer Edge / Provider Edge / Provider Core | | **LDP** | Distributes transport labels (paired with IGP) | | **MP-BGP VPNv4** | Distributes VPN (inner) labels for L3VPN | | **VRF** | Per-customer routing table on the PE | | **RD / RT** | Route Distinguisher (uniqueness) / Route Target (import-export control) | | **PHP** | Penultimate-hop popping — strip the label one hop before egress | | **MPLS-TE** | Traffic Engineering — explicit LSPs that deviate from IGP | | **L3VPN vs L2VPN** | L3 = routed customer service. L2 = transparent Ethernet (pseudowire / VPLS) | | **Not encrypted** | MPLS provides separation, not confidentiality | | **CCNA depth** | Recognize labels, roles, and L3VPN concept — no deep config required | --- ## Cisco DNA Center / Catalyst Center — https://packetmentor.com/topics/dna-center/ > Cisco's centralized network controller for enterprise campus + branch. What it does (assurance, automation, SD-Access), how it sits relative to traditional CLI, and what a CCNA candidate needs to recognize. ## Mental model Traditional campus operations: every switch, router, AP, and ISE node is configured individually via CLI. Adding a new site? Forty CLI sessions. Pushing a new VLAN to 200 access switches? A scripted CLI loop you hope works. Cisco's bet with DNA Center (and the broader Cisco Catalyst Center brand from 2024) is that a single appliance can: - **Discover and inventory** every device on the network. - **Push intent** (templates + policies) to all of them centrally. - **Continuously collect telemetry** (streaming, not SNMP) and reason about it with built-in AI. - **Onboard new devices** with zero-touch via Plug-and-Play. - **Define network behavior as policy** instead of per-port commands (SD-Access). It's the same SDN pattern as in [SDN Controllers](/topics/sdn-controllers/), targeted at the campus/branch instead of the WAN. ## What runs DNA Center A physical or virtual appliance running on Cisco hardware (DN2 series — basically a beefy UCS server preinstalled). Several SKUs based on scale: - DN2-HW-APL — small (small campus) - DN2-HW-APL-L — medium - DN2-HW-APL-XL — large - Cluster of 3 for HA and scale The appliance hosts a containerized stack — microservices for inventory, telemetry ingestion, policy engine, assurance correlation, GUI, REST API. You don't manage the containers; you just use the GUI and APIs. ## The three pillars ### 1. Automation Day-1 / day-2 config push from a central place: - **Discovery** — find every device by IP range, CDP, LLDP. Build an inventory. - **Templates** — Jinja2-style config templates with variables. Push to many devices at once. - **Plug-and-Play** — ship a switch unconfigured. It boots, calls home to DNAC, gets its config and IOS image, joins the fabric. - **Software Image Management (SWIM)** — schedule IOS upgrades across the fleet. Pre-checks, post-checks, rollback if something fails. - **Compliance** — defines a "golden config." Continuously checks every device against it; flags drift. - **Workflows** — orchestrated multi-step changes (e.g., "decommission this switch" = drain traffic + reroute + power-down). ### 2. Assurance Continuous telemetry plus AI-driven correlation. Where traditional NMS shows you SNMP graphs, Assurance answers questions like: - *"Why did user X's Wi-Fi performance drop at 14:32?"* → root cause: AP firmware bug + 5 GHz channel interference. - *"Which clients have intermittent connectivity?"* → list with auto-grouping by symptom. - *"Health of the network right now?"* → composite health score 0-10 per category. Behind it: - **Streaming telemetry** (gRPC, NETCONF subscriptions — see [NETCONF & YANG](/topics/netconf-yang/)) from devices every few seconds. - **AI/ML correlation** — pattern detection across thousands of metrics, looking for anomalies and known signatures. - **Path trace** — visualize the actual path traffic takes between two endpoints, with per-hop stats. - **Sensor data** — APs and Catalyst 9000 switches can act as wireless/wired test probes (synthetic transactions). ### 3. SD-Access The "intent-based networking" piece. Instead of configuring VLANs, ACLs, and trunks per switch, you define: - **Virtual Networks (VNs)** — analogous to VRFs. - **Scalable Group Tags (SGTs)** — security groups assigned per user/device at login. - **Group-Based Access Control (GBAC)** policy — "Employees can talk to Servers; Contractors cannot." DNAC translates that intent into LISP/VXLAN/BGP-EVPN config on the underlying fabric and pushes it. End users never see the underlying complexity. The fabric uses **VXLAN** for encapsulation, **LISP** for endpoint mapping, **CTS / TrustSec / SGT** for identity-based security. CCNA scope is "recognize and describe" — full SD-Access implementation is CCNP / CCIE territory. ## CCNA-level depth For the CCNA 200-301 exam, you should know: - **What DNA Center is** — controller for campus / branch. - **The three pillars** — automation, assurance, SD-Access. - **Where it sits in the architecture diagram** — north of the network (between admins and devices). Talks south to devices via NETCONF/RESTCONF/SSH; talks north to humans and external systems via REST API. - **Compared to traditional management** — replaces per-device CLI with centralized intent + automation. - **Compared to SD-WAN's vManage** — different product, same SDN architecture pattern. DNAC = campus. vManage = WAN. You won't be configuring SD-Access fabrics on the CCNA exam. ## The northbound API Everything DNAC's GUI does, you can do via REST: ``` # Get inventory GET https://dnac.example.com/dna/intent/api/v1/network-device # Push a config template POST https://dnac.example.com/dna/intent/api/v1/template-programmer/template/version/deploy # Run a path trace POST https://dnac.example.com/dna/intent/api/v1/flow-analysis ``` The auth flow is token-based — login once, get a token, attach it to every subsequent call. Standard REST patterns (see [REST APIs](/topics/rest-apis/)). DevNet has a sandbox at `sandboxdnac.cisco.com` (free) — you can play with the API without buying hardware. ## DNA Center vs Catalyst Center — the rebrand In 2024, Cisco rebranded **Cisco DNA Center → Cisco Catalyst Center**. Same product, same APIs, new badge. Catalyst Center is part of the broader Catalyst portfolio (Catalyst switches, Catalyst APs, Catalyst Center, Catalyst SD-WAN). For CCNA: know both names. Older study materials say DNA Center; new ones say Catalyst Center. ## When DNAC is the right tool | Scenario | DNAC fit | |---|---| | Single small campus, 5 switches | Overkill. Stick with CLI. | | 50+ branches, lots of churn | Strong fit — automation pays for itself fast. | | Compliance-heavy environment | Strong fit — continuous compliance + audit reports. | | You want SD-Access (intent-based segmentation) | DNAC is the only way to deploy it. | | Multi-vendor environment (Cisco + Juniper + Arista) | Limited — DNAC manages Cisco well, others poorly. Look at multi-vendor tools. | | Just want a faster NMS | DNAC isn't a drop-in NMS replacement — it's a controller. Heavier than PRTG. | ## Common mistakes 1. **Assuming DNAC manages SD-WAN.** It doesn't. SD-WAN is a separate product (vManage / Catalyst SD-WAN). They integrate but they're not the same controller. 2. **Bypassing DNAC by CLI.** If you SSH into a switch DNAC manages and change config, DNAC sees the drift on next scan and either restores intent or alerts. Either way, it's the wrong way to work — use DNAC's interface or accept the drift cost. 3. **Underestimating discovery sizing.** Inventory of a large network = lots of streaming telemetry. Spec the appliance for what you actually have, not what you wish you had. 4. **Buying SD-Access without ISE.** SD-Access policy enforcement requires ISE (Identity Services Engine) for SGT assignment. They're sold together for a reason. 5. **Confusing Catalyst Center with Meraki Dashboard.** Meraki is a separate cloud-managed product line — different controller, different hardware, different SKU. Cisco sells both; pick one, don't try to mix. 6. **Mistaking telemetry for monitoring.** Assurance gives you *insights*, not raw graphs. If your team only wants "is the switch up?" SNMP polling, DNAC is overkill — buy a simpler NMS. ## Lab to try tonight 1. Reserve a DNAC sandbox on Cisco DevNet (`developer.cisco.com → Sandboxes → DNA Center Always-On`). Free, no Cisco account needed. 2. Log into the GUI. Look at the inventory page — see the pre-loaded sample devices. 3. Open the topology view. Note how DNAC discovers physical connections via CDP/LLDP. 4. Try a path trace from one client to another. Inspect the per-hop stats. 5. Hit the REST API: ``` POST /dna/system/api/v1/auth/token (with HTTP basic auth) GET /dna/intent/api/v1/network-device (with X-Auth-Token header) ``` 6. Compare the JSON response to what you saw in the GUI — same data, different surface. 7. Bonus: explore the Assurance dashboards. Click into a "client health issue" and walk the AI-suggested root cause. ## Cheat strip | Concept | Plain English | |---|---| | **DNA Center / Catalyst Center** | Cisco's central controller for campus + branch networks | | **Three pillars** | Automation, Assurance, SD-Access | | **Automation** | Templates, PnP, SWIM, compliance — push config from one place | | **Assurance** | Streaming telemetry + AI = root-cause analysis | | **SD-Access** | Intent-based segmentation using VXLAN + LISP + SGT | | **Virtual Network (VN)** | Like a VRF — isolated routing instance | | **SGT** | Scalable Group Tag — identity-based segmentation. Pairs with ISE | | **Northbound API** | REST — call DNAC from outside | | **Southbound** | NETCONF / RESTCONF / SSH — DNAC to devices | | **vManage** | DNAC's WAN cousin — separate product for SD-WAN | | **CCNA depth** | Recognize the product, three pillars, where it sits. No config. | | **DevNet sandbox** | Free, always-on DNAC for practice | ## Frequently asked questions **Q: Is Cisco DNA Center on the CCNA 200-301 exam?** A: Recognition-level only. You should know the three pillars (Automation, Assurance, SD-Access), that it uses NETCONF/RESTCONF southbound and REST northbound, and that it's a controller for the campus (SD-WAN is a separate product, vManage). No hands-on config is required at CCNA. **Q: What's the difference between DNA Center and Catalyst Center?** A: Same product. Cisco rebranded DNA Center as Catalyst Center in 2024 as part of consolidating their networking platform naming. The interface, APIs, and features are the same — only the box logo changed. **Q: Do I need real Cisco hardware to try DNA Center?** A: No — Cisco's free DevNet sandbox has an always-on DNA Center you can log in and click around. The sandbox URL and credentials rotate; check `developer.cisco.com/sandbox`. **Q: How is DNA Center different from Ansible or Python + Netmiko?** A: DNA Center is a full-stack controller with a UI, a policy engine, and streaming telemetry. Ansible / Netmiko are lower-level tools that push config from your laptop. DNA Center replaces both, plus adds AI-driven assurance. But you can still use Ansible playbooks THROUGH DNA Center's API — they complement, not compete. **Q: What is SD-Access at a technical level?** A: Fabric of switches + APs running VXLAN as the data plane, LISP as the control plane, and SGT-based segmentation via ISE. Underneath: an IS-IS underlay. DNA Center provisions the whole thing from templates so you don't touch VXLAN CLI directly. **Q: Do enterprise customers actually deploy DNA Center in production?** A: Yes — heavily in Fortune 500 and government. It's most common in Cisco-heavy shops running Catalyst 9000-series switches. Smaller shops or non-Cisco environments typically don't. ## What to learn next - **Deep dive**: [SDN Controllers](/topics/sdn-controllers/) — how DNA Center compares to APIC (data center) and vManage (SD-WAN). - **Related**: [SD-WAN Concepts](/topics/sd-wan-concepts/) — the WAN cousin of SD-Access. - **Hands-on**: [REST APIs for Network Engineers](/topics/rest-apis/) — the northbound API you'd call to automate DNA Center itself. - **Broader context**: [NETCONF & YANG](/topics/netconf-yang/) — the southbound protocol DNA Center uses to talk to devices. --- ## VRF Basics — Virtual Routing and Forwarding — https://packetmentor.com/topics/vrf-basics/ > How a router can pretend to be multiple separate routers with isolated routing tables — VRF-lite vs MPLS-VPN VRFs, RDs/RTs, and the use cases (multi-tenant, management plane, lab isolation). ## Mental model Default routers have **one routing table** (the global RIB). Every interface, every route, every routing-protocol neighbor lives in it. If two customers both use `10.0.0.0/24` internally, they can't share that router — the routes would collide. A **VRF** (Virtual Routing and Forwarding instance) gives the router multiple **parallel routing tables**, each completely isolated. Interfaces are bound to a specific VRF. Routes from one VRF aren't visible to another. Two customers' overlapping `10.0.0.0/24` can both exist on the same physical router — different VRFs, different tables. ``` Physical Router ┌───────────────────┐ │ │ │ global RIB │ (management, traditional routes) │ ├─ default │ │ ├─ 10.255.0.0/16 │ │ │ │ VRF CUSTOMER-A │ (isolated) │ ├─ 10.0.0.0/24 │ ← these two 10.0.0.0/24 don't conflict │ └─ 192.168.1.0 │ │ │ │ VRF CUSTOMER-B │ (isolated) │ ├─ 10.0.0.0/24 │ ← same prefix in different VRF, fine │ └─ 172.16.5.0 │ │ │ └───────────────────┘ ``` Conceptually like Linux network namespaces, BSD jails, or virtual routers in a hypervisor — same idea applied to a physical router/switch. ## Two flavors — VRF-lite vs MPLS L3VPN | | **VRF-lite** | **MPLS L3VPN** | |---|---|---| | Standalone or networked? | Single device or hop-by-hop across devices that each understand the VRF | Across a provider MPLS backbone | | Scope | One organization, a few VRFs | Service provider, thousands of customers | | Underlying transport | Plain IP routing | MPLS labels (covered in [MPLS Basics](/topics/mpls-basics/)) | | Routing protocol between sites | Each VRF runs its own per-VRF instance | MP-BGP VPNv4 across PE routers | | Complexity | Low — works on any L3 device | Higher — needs full MPLS knowledge | | CCNA depth | **Recognize and configure basic** | Recognize concept | For CCNA, focus on **VRF-lite** — it's testable and concrete. MPLS L3VPN is the more powerful big-brother version covered separately. ## Use cases ### 1. Multi-tenant isolation Two customers share one Layer-3 switch in your data center. You don't want a misconfigured ACL on Customer A's side to leak into Customer B's. VRF gives you a hard wall. ### 2. Management plane separation Production traffic in the global table. Management traffic (SSH to all your devices, SNMP, syslog, NTP, AAA, NetFlow) in a dedicated `MGMT` VRF. Even if production is broken, you can still reach devices via management — a different routing path entirely. This is the most common enterprise VRF use case in 2026. ### 3. Overlapping IP space Two acquired companies both use `192.168.1.0/24` internally. They join your network. You don't want to renumber 5000 hosts. Put each in its own VRF, and translate between them only where they need to talk. ### 4. Lab / shared hardware One physical switch hosts multiple lab environments. Each lab in its own VRF — they can't accidentally route between each other. ### 5. PCI / compliance isolation Card-data network must be isolated from corporate network. VRF + per-VRF firewalls = a hard policy boundary that auditors understand. ## VRF-lite configuration ``` ! 1. Create the VRF R1(config)# vrf definition CUSTOMER-A R1(config-vrf)# rd 65000:1 R1(config-vrf)# address-family ipv4 R1(config-vrf-af)# exit-address-family R1(config)# vrf definition CUSTOMER-B R1(config-vrf)# rd 65000:2 R1(config-vrf)# address-family ipv4 R1(config-vrf-af)# exit-address-family ! 2. Bind interfaces R1(config)# interface Gi0/1 R1(config-if)# vrf forwarding CUSTOMER-A ! puts this interface in VRF A R1(config-if)# ip address 10.0.0.1 255.255.255.0 R1(config)# interface Gi0/2 R1(config-if)# vrf forwarding CUSTOMER-B ! puts this interface in VRF B R1(config-if)# ip address 10.0.0.1 255.255.255.0 ← same IP, different VRF — no conflict ! 3. Per-VRF routing R1(config)# ip route vrf CUSTOMER-A 0.0.0.0 0.0.0.0 10.0.0.2 R1(config)# ip route vrf CUSTOMER-B 0.0.0.0 0.0.0.0 10.0.0.2 ! 4. OSPF per VRF (if dynamic routing) R1(config)# router ospf 100 vrf CUSTOMER-A R1(config-router)# network 10.0.0.0 0.0.0.255 area 0 R1(config)# router ospf 200 vrf CUSTOMER-B R1(config-router)# network 10.0.0.0 0.0.0.255 area 0 ``` Two key things to note: - **`vrf forwarding`** under the interface is what binds it to a VRF. - **Same IP address, different VRF, different gateway** — both work simultaneously without conflict. ## The RD — Route Distinguisher Each VRF has an RD: an 8-byte identifier prepended to routes to make them globally unique. Format `ASN:nn` or `IP:nn`. Example: `65000:1`. In VRF-lite, the RD is **only locally meaningful** — it doesn't actually appear in routing protocol messages between VRF-lite devices. But you still need to define it for the platform. In MPLS L3VPN, the RD travels with the route in MP-BGP — `65000:1:10.0.0.0/24` is the actual NLRI advertised between PEs. ## Verification ``` R1# show vrf Name Default RD Protocols Interfaces CUSTOMER-A 65000:1 ipv4 Gi0/1 CUSTOMER-B 65000:2 ipv4 Gi0/2 R1# show ip route vrf CUSTOMER-A R1# show ip route vrf CUSTOMER-B R1# show ip interface brief ... global RIB only — VRF interfaces don't show ... R1# show ip interface brief | section CUSTOMER-A ! some IOS versions R1# ping vrf CUSTOMER-A 10.0.0.2 R1# traceroute vrf CUSTOMER-A 10.0.0.2 R1# ssh -vrf CUSTOMER-A 10.0.0.2 ! SSH from inside a VRF ``` Commands that operate "globally" by default need a `vrf` keyword when you want them inside a specific VRF. ## Inter-VRF route leaking Sometimes two VRFs DO need to talk — usually one-way, e.g., the MGMT VRF needs to reach all production VRFs for monitoring. In VRF-lite, this is done with **static routes** that explicitly cross the VRF boundary: ``` R1(config)# ip route vrf CUSTOMER-A 192.168.99.0 255.255.255.0 Gi0/3 10.99.99.1 global ``` The `global` keyword (or the trailing VRF name) tells the router: *"this next-hop is in a different table."* In MPLS L3VPN, route leaking is done via **Route Target import/export** — far more elegant, but requires MP-BGP. ## VRF-aware services When you put interfaces in a VRF, many services don't automatically follow. You must tell them which VRF to use: ``` ! AAA / RADIUS in MGMT VRF R1(config)# aaa group server radius MGMT-RADIUS R1(config-sg-radius)# server name ISE-PSN-1 R1(config-sg-radius)# ip vrf forwarding MGMT R1(config-sg-radius)# ip radius source-interface Loopback0 vrf MGMT ! SSH from MGMT VRF R1(config)# ip ssh source-interface Loopback0 vrf MGMT ! NTP in MGMT VRF R1(config)# ntp server vrf MGMT 10.99.99.5 ! Syslog in MGMT VRF R1(config)# logging host 10.99.99.6 vrf MGMT ! DNS lookup in MGMT VRF R1(config)# ip name-server vrf MGMT 10.99.99.7 ! TACACS+ in MGMT VRF R1(config)# tacacs-server host 10.99.99.8 vrf MGMT ``` Forgetting any of these means the service silently uses the global table. Common gotcha during VRF rollouts. ## Common mistakes 1. **Configuring an interface without `vrf forwarding`.** It stays in the global table. Easy to do during a migration. 2. **Pre-VRF IPs disappear.** When you change `vrf forwarding` on an interface, all its previous IP addresses are wiped. Re-apply with the new VRF binding. 3. **Routing protocol "address-family" confusion.** Recent IOS versions require `address-family ipv4 vrf X` blocks inside the routing process. Older syntax `router ospf 100 vrf X` still works on many platforms. 4. **Forgetting `global` keyword for leak routes.** Without it, the route points at a next-hop that doesn't exist in the source VRF. 5. **Management services in wrong VRF.** Configured `radius-server` globally but production interface is in VRF A → AAA never works. 6. **Same OSPF process across multiple VRFs.** Common to use `router ospf 100 vrf A`, `router ospf 100 vrf B` — actually creates separate process instances, despite the same number. Some platforms enforce different numbers. Check your platform's syntax. 7. **VRF count limits.** A switch might support 8, 32, 256 VRFs depending on platform. Don't overcommit. 8. **Forgetting that a packet's VRF context is determined by ingress interface.** If a packet hits Gi0/1 (in VRF A), it gets looked up in VRF A's RIB, period. You cannot mix VRF context within a packet's path on the same router without explicit leaking. ## VRFs vs PVLANs vs VLANs — when to use which | Need | Tool | |---|---| | Separate broadcast domains, separate IP subnets | **VLAN** | | Same subnet, isolated L2 (hotels, MDU) | **PVLAN** (see [Private VLANs](/topics/private-vlans/)) | | Separate L3 routing tables, possibly overlapping IP | **VRF** | | Per-tenant isolation across a provider backbone | **MPLS L3VPN** (VRF + MP-BGP + MPLS) | | Mgmt plane separated from data plane | **VRF for mgmt** | VLAN, PVLAN, VRF are layered tools. You can use all three in the same network for different problems. ## Lab to try tonight 1. One router, three interfaces. Create VRF CUSTOMER-A and VRF CUSTOMER-B (RDs `65000:1` and `65000:2`). 2. Put Gi0/1 in VRF A (`10.0.0.1/24`), Gi0/2 in VRF B (`10.0.0.1/24` — same IP). Connect a host to each. 3. From the router: `ping vrf CUSTOMER-A 10.0.0.2` → reaches Host A. `ping vrf CUSTOMER-B 10.0.0.2` → reaches Host B. Two same-IP hosts, no conflict. 4. From Host A, try to reach Host B's IP. Won't work — different VRFs. 5. Add a static route on the router to leak VRF A → VRF B for one specific destination. Verify connectivity now works. 6. Configure OSPF inside each VRF (different process numbers). Add a second router. Verify OSPF adjacency forms per-VRF. 7. Bonus: configure a MGMT VRF with a Loopback0. Move SSH, NTP, syslog, AAA to use that loopback / VRF. Verify production traffic doesn't pollute MGMT and vice versa. 8. Bonus: try a real-world overlay — VRFs A and B both run RIPv2 or OSPF, but you need a "shared services" VRF that A and B both reach. Implement with leak routes. ## Cheat strip | Concept | Plain English | |---|---| | **VRF** | Isolated routing table inside one router | | **VRF-lite** | Standalone VRFs without MPLS — your CCNA-level focus | | **MPLS L3VPN** | VRFs extended across a provider backbone via MP-BGP | | **`vrf definition X`** | Create a VRF | | **`rd X:Y`** | Route Distinguisher — required even if locally meaningful | | **`vrf forwarding X`** | Bind an interface to VRF X (interface mode) | | **Per-VRF commands** | `show ip route vrf X`, `ping vrf X`, `ssh -vrf X`, etc. | | **MGMT VRF** | Most common enterprise use case — separate management plane | | **Overlapping IPs** | Two VRFs can have the same subnet — no conflict | | **Inter-VRF leak** | Use `ip route vrf X ... global` or route-target import/export | | **VRF-aware services** | RADIUS, NTP, syslog, SSH, DNS — all need explicit VRF binding | | **Layered with VLAN / PVLAN** | VLAN = L2 / PVLAN = L2 isolation in one subnet / VRF = L3 isolation | --- ## Network Virtualization & Containers — https://packetmentor.com/topics/network-virtualization/ > Hypervisors, virtual machines, virtual switches, containers, container networking — how server virtualization changed networking and what a CCNA candidate must understand. ## Mental model For decades, "one server = one set of NICs = one set of IPs." Then VMware (and later KVM, Hyper-V, Xen) broke that — a single physical server can now host dozens of independent guest operating systems, each with its own network identity. For the network engineer this means: - **Far more endpoints per switch port** — one physical port might handle traffic for 50 VMs. - **Virtual switches inside the server** — packets get switched in software before they ever reach your physical switch. - **VLANs and trunks now end inside the hypervisor**, not at the physical NIC. - **Live migration** (VMs moving across hosts) requires MAC and IP mobility — which forces design decisions about subnet stretching, overlay networks, and ARP behavior. Container networking (Docker, Kubernetes) raised the count again — instead of dozens of VMs per host, hundreds of containers. The networking model is different (shared kernel, namespaces, CNI plugins) but the engineer's job is the same: make traffic flow, scale, and stay secure. This is one of the CCNA 200-301 blueprint topics that grew from "describe" to "describe + apply" in v1.1. ## Server virtualization — the building blocks ``` Physical Server ┌──────────────────────────────┐ │ Guest VM 1 (Linux) │ │ Guest VM 2 (Windows) │ │ Guest VM 3 (Ubuntu) │ ├──────────────────────────────┤ │ Hypervisor (ESXi) │ │ ┌──────────────────────┐ │ │ │ Virtual Switch │ │ │ └─────────┬────────────┘ │ ├─────────────┼─────────────────┤ │ Physical NICs (eth0/eth1) │ └─────────────┴─────────────────┘ │ ▼ Physical switch (yours) ``` Three components matter: | Component | What it does | |---|---| | **Hypervisor** | Software layer (Type 1 = bare metal, Type 2 = on top of OS) that runs the guests | | **Virtual NIC (vNIC)** | Software NIC presented to the guest — guest thinks it's a real network card | | **Virtual switch (vSwitch)** | L2 switch inside the hypervisor — forwards between VMs and out to physical | ### Type 1 vs Type 2 hypervisors | Type | Examples | Where | |---|---|---| | **Type 1** (bare-metal) | VMware ESXi, KVM, Hyper-V, Xen, Proxmox | Production servers | | **Type 2** (hosted) | VMware Workstation, VirtualBox, Parallels | Dev/laptop | Production server farms run Type 1. CCNA tests recognition of both. ### Virtual switches (vSwitch / DVS / OVS) A vSwitch is a software Layer-2 switch inside the hypervisor. It learns MAC addresses, forwards traffic between VMs, handles VLAN tagging, and connects up to the physical NIC. Three common forms: | vSwitch | Vendor / Project | Notes | |---|---|---| | **Standard vSwitch** | VMware | Per-host. Simple but no centralized config. | | **Distributed vSwitch (DVS / VDS)** | VMware | Spans many hosts, configured centrally from vCenter. | | **Open vSwitch (OVS)** | Open source | Used by KVM, OpenStack, many Kubernetes setups. Programmable. | ### VLANs and trunks at the hypervisor edge The physical switch port connecting to a virtualized host is almost always a **trunk** (rarely access). The hypervisor sees the dot1Q tags and delivers each VLAN to the right vSwitch port-group. ``` SW1(config)# interface Gi1/0/24 SW1(config-if)# description ESX-01 uplink SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk allowed vlan 10,20,30,99 SW1(config-if)# spanning-tree portfast trunk ! virtualization hosts are not switches ``` In vCenter / vSphere: - Create port-groups (VLAN 10 = USERS, VLAN 20 = SERVERS, VLAN 99 = MGMT). - Assign each VM's vNIC to the appropriate port-group. - The vSwitch tags outgoing frames with the right VLAN ID. ### Live migration — vMotion VMware vMotion (and Hyper-V Live Migration, KVM live migration) moves a running VM from one physical host to another with no downtime. Network implication: the VM keeps its IP and MAC. ARP tables across the network briefly update via gratuitous ARP. Both source and destination hosts need access to the VM's VLANs, which usually means: - **Stretched VLANs** (same VLAN trunked to many hosts) — simple but limits failure domain. - **VXLAN overlays** (VLANs encapsulated and tunneled across L3 boundaries) — modern datacenter answer; supports L2 mobility across racks and sites. ## Containers — the second wave Containers (Docker, Podman, containerd) are lighter than VMs. Instead of running a full guest OS, containers share the host kernel and isolate processes using Linux namespaces and cgroups. ``` Physical Server ┌──────────────────────────────┐ │ Container 1 │ Container 2 │ Container 3 │ (Linux ns) │ (Linux ns) │ (Linux ns) ├──────────────────────────────┤ │ Container runtime (containerd, Docker engine) ├──────────────────────────────┤ │ Host OS (Linux kernel) ├──────────────────────────────┤ │ Physical hardware └──────────────────────────────┘ ``` ### Container networking — three main modes | Mode | What it does | |---|---| | **Bridge** | Container gets a virtual interface attached to a host-side Linux bridge. NATted to host's IP for outbound. Default Docker mode. | | **Host** | Container shares the host's network namespace. No isolation; container binds directly to host ports. | | **None** | No network. Container is fully isolated. | | **Overlay** | Multi-host networking — containers across many hosts can talk as if on the same L2. Uses VXLAN. Standard in Kubernetes / Docker Swarm. | ### Kubernetes networking Kubernetes adds its own abstractions on top: - **Pod** — one or more containers sharing a network namespace (same IP, same ports). - **Service** — virtual IP and DNS name fronting a group of pods. Uses iptables/IPVS for load balancing. - **CNI** (Container Network Interface) plugin — provides the actual networking: Calico, Cilium, Flannel, Weave, AWS VPC CNI. A Kubernetes cluster of 100 nodes might have 10,000+ pods, each with its own IP. Networking has to scale to that without falling over. For CCNA depth: recognize the terms and that pod networking exists; full Kubernetes networking is CCNP / specialist scope. ### VMs vs containers — the comparison | Aspect | VMs | Containers | |---|---|---| | **Isolation** | Full OS isolation (stronger) | Process + namespace isolation (weaker) | | **Startup time** | 30s – minutes | <1 second | | **Density** | 10s per host | 100s per host | | **Image size** | 10s of GB | 10s of MB to GB | | **Networking** | vSwitch + VLAN | Bridge + overlay + CNI | | **OS flexibility** | Any guest OS | Same kernel as host (Linux ↔ Linux, Windows ↔ Windows) | | **Use case** | Traditional workloads, multi-OS environments | Microservices, stateless apps, dev environments | In 2026 real datacenters: both coexist. VMs for stateful / legacy / Windows. Containers for microservices and modern apps. ## Where networking-engineer skills apply You're still the network engineer for virtualized environments — the surfaces just changed: - **VLAN trunking design** — same skills as ever, but ending at the hypervisor's vSwitch. - **VRF isolation** — many vendors map VRFs to vSwitch port-groups for multi-tenant clouds. - **Overlay design** — VXLAN, NVGRE, Geneve for inter-host L2 mobility. Cisco SD-Access and VMware NSX both rest on VXLAN. - **Anycast gateways** — fabric-wide gateway address so VMs/pods can move without re-ARP'ing. - **Underlay routing** — OSPF or BGP between the physical switches carrying the overlays. - **Microsegmentation** — per-pod or per-VM firewall policy, enforced at the hypervisor or by Cilium-style eBPF. ## Common mistakes 1. **Access-port to a virtualization host.** Most environments need a trunk. Access port means all VMs land on one VLAN, defeating multi-tier design. 2. **PortFast off on host trunks.** Hypervisor uplinks bounce occasionally (firmware updates, link flaps). Without `portfast trunk`, every bounce triggers STP recompute. Enable it on host-facing ports. 3. **STP between hypervisors.** vSwitches do NOT participate in STP. Connecting two physical switch ports to one vSwitch as redundancy needs an EtherChannel (LACP) — not two independent ports. 4. **Live migration across L3 boundaries** without an overlay. VMs lose their IP when crossing subnets. Either stretch the VLAN (limited) or build a VXLAN overlay. 5. **Confusing VM and container networking.** A container is not a tiny VM. Bridge mode, host mode, overlay mode — different semantics from vSwitch port-groups. 6. **Defaulting to Docker bridge mode in production.** Bridge mode NATs containers behind the host IP. Inbound connections need port mappings. Plan for overlay or host mode at production scale. 7. **Forgetting MAC-table size on physical switches.** A virtualized rack with 200 VMs × 4 vNICs each = 800+ MACs visible on the trunk. Older switches' MAC tables overflow. 8. **No vCenter / hypervisor visibility for the network team.** If you don't have read access to vSphere / the hypervisor, you'll spend hours debugging issues that are obvious from inside the host. ## Lab to try tonight 1. Install VirtualBox or VMware Workstation. Build 2-3 small Linux VMs. 2. Configure the VMware/VirtualBox virtual network in different modes (NAT, Bridged, Host-only). Note IP behavior. 3. Boot a Cisco IOS-XR or IOS-XE virtual image (via CML or EVE-NG). Notice it runs *as* a VM on your host. 4. Install Docker on a Linux VM. Run `docker network ls` and `docker network inspect bridge`. See the default Linux bridge `docker0`. 5. Run two containers. Verify they can reach each other on the bridge. 6. Try Docker overlay: `docker swarm init` + `docker service create --network overlay-name ...`. See VXLAN packets in the underlay if you have access. 7. Bonus: spin up a single-node Kubernetes (`kind` or `minikube`). Watch the CNI assign per-pod IPs. Use `kubectl exec` to ping between pods. ## Cheat strip | Concept | Plain English | |---|---| | **Hypervisor** | Software that runs guest VMs. Type 1 = bare metal, Type 2 = hosted | | **VM** | Full guest OS running on a hypervisor | | **Virtual NIC (vNIC)** | Software NIC presented to a VM | | **Virtual switch (vSwitch)** | L2 switch inside the hypervisor. Forwards between VMs and to physical NICs | | **Distributed vSwitch (DVS)** | vSwitch spanning many hosts, central config | | **Open vSwitch (OVS)** | Open-source programmable vSwitch — Linux/KVM/OpenStack | | **Container** | Process-level isolation using kernel namespaces. Lighter than VM | | **Docker / containerd** | Most common container runtime | | **CNI** | Container Network Interface — plugin model for pod networking in Kubernetes | | **Pod** | One or more containers sharing a network namespace (Kubernetes) | | **Overlay (VXLAN)** | L2 over L3 tunnel. Enables container/VM mobility across rack and site boundaries | | **vMotion / live migration** | Move a running VM to another host with no downtime | | **Trunk to hypervisor** | Standard pattern — multiple VLANs reach the vSwitch | | **No STP from vSwitches** | They don't participate. Use EtherChannel for redundancy | | **CCNA depth** | Recognize the model, understand VLAN-to-port-group mapping, know VXLAN exists for mobility | --- ## Cybersecurity Threats & Mitigation — https://packetmentor.com/topics/cybersecurity-threats/ > The threat landscape every network engineer must recognize — phishing, ransomware, MITM, DDoS, supply-chain attacks, insider threats — and the mitigation controls that actually move the needle. ## Mental model Real breaches in 2026 rarely look like the movies. The dominant pattern is mundane: 1. An employee receives a phishing email. 2. They click and enter their corporate credentials on a fake login page. 3. The attacker logs in with valid credentials from somewhere overseas. 4. Because MFA wasn't enforced or was push-fatigued, they get in. 5. They sit in the network for weeks, slowly mapping it. 6. They escalate privileges, exfiltrate data, then drop ransomware to monetize. No zero-day exploit. No Hollywood "hacking." Just identity compromise + lateral movement + monetization. This is why modern security thinking has shifted: **assume compromise, design for blast-radius reduction.** A network engineer's job isn't to make breaches impossible (you can't) — it's to ensure that one compromised endpoint can't reach the crown-jewel systems without crossing several authorization boundaries. ## The six categories of attack Cisco's blueprint groups threats into broad categories. Memorize these. ### 1. Phishing & social engineering Tricking a human into giving up credentials, clicking malware, or wiring money. **Variants:** - **Phishing** — mass email impersonating a service ("Your Microsoft 365 expired"). - **Spear phishing** — targeted at one person, references real details about them. - **Whaling** — spear phishing aimed at executives. - **Smishing** — phishing via SMS. - **Vishing** — phishing via voice call (often impersonating IT support). - **Business Email Compromise (BEC)** — attacker compromises an executive's email and uses it to authorize wire transfers. **Mitigations:** user awareness training, email security gateways (Mimecast, Proofpoint), DMARC/SPF/DKIM on outbound mail, MFA on every account, "verify out-of-band" policy for money transfers. ### 2. Malware (including ransomware) Malicious code executed on endpoints or servers. **Categories:** - **Virus / worm** — self-replicating code. - **Trojan** — disguised as legitimate software. - **Ransomware** — encrypts files, demands payment. - **Spyware / keylogger** — silently exfiltrates data or keystrokes. - **Cryptojacker** — uses your CPU/GPU to mine cryptocurrency. - **Rootkit** — modifies the OS to hide itself; very hard to detect. - **Wiper** — destroys data with no payment option (nation-state). **Mitigations:** EDR (endpoint detection and response) like CrowdStrike, SentinelOne, MS Defender for Endpoint; application allowlisting; patch management; offline backups (essential for ransomware recovery); least-privilege users. ### 3. Man-in-the-Middle (MITM) Attacker sits between two parties and reads/modifies traffic. **Variants:** - **ARP spoofing** on a LAN — attacker poisons the ARP table so victim traffic flows through them. - **DHCP rogue server** — attacker hands out malicious gateways. - **Wi-Fi evil twin** — attacker sets up an open SSID matching a legitimate name. - **TLS strip / downgrade** — attacker forces HTTP instead of HTTPS. - **BGP hijacking** — attacker (often a misconfigured ISP) advertises someone else's prefix, redirecting traffic. **Mitigations:** DHCP Snooping + Dynamic ARP Inspection on access switches, IP Source Guard, HSTS on web apps, TLS everywhere, RPKI for BGP, WPA3 / 802.1X on Wi-Fi. ### 4. Denial of Service (DoS / DDoS) Overwhelm a service so legitimate users can't reach it. **Variants:** - **Volumetric** — saturate bandwidth (UDP amplification via DNS, NTP, memcached). - **Protocol** — exhaust connection tables (SYN flood, ACK flood). - **Application** — slow or recursive queries against an app (Slowloris, GET flood). - **Distributed (DDoS)** — sourced from a botnet of thousands of IPs. **Mitigations:** cloud-based scrubbing (Cloudflare, AWS Shield, Akamai), upstream blackhole / RTBH coordination with your ISP, rate limiting, CDN absorbing public traffic, NTP/DNS amplification protection at your edge (`query-only` ACLs on NTP — see [NTP Authentication](/topics/ntp-authentication/)). ### 5. Supply-chain attacks Attacker compromises a vendor or library that you depend on, gaining access to your systems indirectly. **High-profile examples:** SolarWinds (2020), Kaseya (2021), 3CX (2023), MOVEit (2023). The attacker shipped a malicious update to a trusted vendor's software, which thousands of victims auto-installed. **Mitigations:** software bill of materials (SBOM), vendor security questionnaires, network segmentation of management plane, code signing verification, egress filtering (a compromised SolarWinds agent can't beacon out if the management VLAN has no internet access). ### 6. Insider threats Authorized user goes rogue (or makes a mistake). **Variants:** - **Malicious insider** — departing employee exfiltrating data. - **Compromised insider** — legitimate account taken over by external attacker. - **Negligent insider** — well-meaning user emailing a customer DB to a personal account. **Mitigations:** principle of least privilege, separation of duties, DLP (data loss prevention) policies, monitoring for unusual access patterns, immediate offboarding processes, mandatory vacation policies. ## Defense in depth — the layers ``` Internet │ ┌──────┴──────┐ │ DDoS scrub │ Layer 1: edge volumetric protection └──────┬──────┘ │ ┌──────┴──────┐ │ Perimeter FW│ Layer 2: stateful firewall + IPS └──────┬──────┘ │ ┌─────────────┴─────────────┐ │ Segmented internal │ Layer 3: VLAN + VRF + ACL between zones │ (DMZ / PCI / corp / IoT)│ └──────┬──────────────┬─────┘ │ │ ┌───┴───┐ ┌───┴────┐ │ Servers│ │ Users │ Layer 4: identity (AAA, dot1x, MFA), └───┬────┘ └───┬────┘ EDR on every endpoint │ │ └───────┬───────┘ │ ┌───────┴────────┐ │ Logging │ Layer 5: SIEM + NetFlow + endpoint telemetry │ + monitoring │ └────────────────┘ ``` Each layer assumes the layer above fails. A compromise of one zone shouldn't auto-grant access to another. Logs everywhere mean you find compromise quickly when (not if) it happens. ## What's specifically the network engineer's job For CCNA / CCNP-level network engineers, your contribution to this stack: - **Identity at the port:** 802.1X with ISE or another RADIUS (see [Cisco ISE Basics](/topics/cisco-ise-basics/)), MAC bypass for IoT. - **Layer-2 hardening:** Port Security, DHCP Snooping, DAI, IP Source Guard, BPDU Guard. - **Network segmentation:** VLAN per role/sensitivity, ACLs at L3 boundaries, VRFs for hard isolation, micro-segmentation in DCs. - **Encrypted transit:** IPsec for site-to-site, AnyConnect for remote access, MACsec for in-DC encryption between switches. - **Logging and visibility:** Syslog every device to a SIEM, NetFlow on uplinks (see [NetFlow](/topics/netflow/)), packet capture capability. - **Patch the network gear:** Cisco / vendor IOS updates aren't optional. Old IOS has known CVEs. - **Egress filtering:** outbound rules so compromised servers can't beacon out to C2. You're not the SOC analyst. You're the foundation the SOC works on top of. ## Specific Layer-2 attacks to know (CCNA-tested) | Attack | What it does | Mitigation | |---|---|---| | **MAC flooding** | Floods CAM table → switch becomes hub → attacker sniffs everything | Port Security (`switchport port-security`) | | **ARP spoofing** | Sends fake ARP replies → MITM | Dynamic ARP Inspection (DAI) | | **DHCP starvation** | Exhausts the legitimate DHCP pool | DHCP Snooping rate-limit | | **Rogue DHCP server** | Hands out malicious gateways | DHCP Snooping `trust` only on real servers | | **VLAN hopping (double-tagging)** | Crosses into another VLAN via native VLAN | Don't use VLAN 1 as native; tag native explicitly | | **CDP / LLDP reconnaissance** | Attacker reads neighbor info | Disable CDP/LLDP on user-facing ports | | **STP attacks** | Become root bridge / divert traffic | Root Guard + BPDU Guard | | **MAC spoofing** | Bypass MAC-based access | 802.1X with identity-based auth | ## The CIA triad A core concept from CCNA: every security control aims to preserve one of three properties. | Property | What it means | Example controls | |---|---|---| | **Confidentiality** | Data is only seen by authorized parties | Encryption (AES), TLS, IPsec, ACLs | | **Integrity** | Data is not modified undetected | Hashing (SHA-256), HMAC, digital signatures | | **Availability** | Data and services are reachable when needed | Redundancy, DDoS protection, backup, capacity | Map each control to which property it protects. A WAF protects integrity + availability (not confidentiality of internal data). Encryption protects confidentiality + integrity (not availability — encrypted data still gets DDoS'd). ## Common mistakes 1. **Treating firewalls as sufficient.** A modern attack starts inside the firewall (phishing). The perimeter is necessary but far from sufficient. 2. **No segmentation between user and server VLANs.** A compromised laptop can talk to the file server, the AD controller, the database. Lateral movement is trivial. 3. **Same admin credentials everywhere.** Compromise of one device's enable secret → entire fleet. Use TACACS+ / per-device auth. 4. **No MFA on jump servers / management plane.** The bastion host is the highest-value target on your network. SSH-key + MFA minimum. 5. **NTP unencrypted and unauthenticated.** Allows time-shift attacks that break Kerberos and TLS validation. See [NTP Authentication](/topics/ntp-authentication/). 6. **Allowing CDP/LLDP everywhere.** Attacker plugs into a network drop, learns the upstream switch model and IOS version — a recon goldmine. Disable on user-facing ports. 7. **No outbound filtering.** Compromised hosts can phone home to C2. Default-allow outbound is a habit that's no longer defensible. 8. **Treating "patched" as binary.** Patching IOS once a year isn't patching. Vendor advisories every 6 weeks; track them. 9. **No tested backups.** Backups untested = no backups. Ransomware doesn't care if you have them, only if you can restore from them. 10. **Conflating security with compliance.** PCI-compliant ≠ secure. SOC 2-compliant ≠ secure. Compliance is a floor, not a ceiling. ## Lab to try tonight 1. **MAC flooding demo:** in CML / GNS3, use `macof` from a Linux host to flood a switch's CAM table. Without Port Security, the switch starts flooding all traffic. Apply `switchport port-security` and watch the attack get shut down. 2. **ARP spoofing demo:** between two hosts on the same VLAN, use `arpspoof` to poison a victim's ARP table. Then turn on DAI on the switch and confirm the attack stops. 3. **Phishing-style URL inspection:** look at a real phishing email (or test from KnowBe4 / Proofpoint demos). Note the small typos in the domain, the urgency language, the call-to-action. 4. **Configure 802.1X with ISE** (DevNet sandbox). Add a host to the network, watch it authenticate. Then connect an "unknown" host and watch it land in the quarantine VLAN. 5. **NetFlow + threat hunting:** with NetFlow data flowing into a collector, look for anomalies — one host suddenly sending to 1000 destinations (scan), or one host sending 50 GB/hour to a foreign IP (exfil). 6. **Tabletop exercise:** walk a colleague through "what do we do if our domain controller is encrypted at 3am Saturday?" Find every gap in the plan. ## Cheat strip | Concept | Plain English | |---|---| | **CIA triad** | Confidentiality, Integrity, Availability — the goal of all security controls | | **Phishing** | Tricking a human into giving credentials or clicking malware. #1 attack vector | | **Ransomware** | Malware that encrypts your data and demands payment. Mitigated by tested offline backups | | **MITM** | Attacker sits between victims. ARP spoofing, evil twin Wi-Fi, BGP hijack | | **DDoS** | Distributed traffic flood that takes services offline. Mitigated by scrubbing services + CDN | | **Supply chain attack** | Compromise a vendor to reach the vendor's customers | | **Insider threat** | Authorized user goes rogue or makes a mistake | | **Defense in depth** | Multiple security layers — assume any one will fail | | **Least privilege** | Each user/device gets the minimum access needed | | **MFA** | Multi-factor auth — required on every account that matters | | **EDR** | Endpoint detection + response — modern antivirus successor | | **SIEM** | Central log aggregation + correlation | | **L2 attacks on CCNA** | MAC flood, ARP spoof, DHCP attacks, VLAN hop, STP attacks — know each + its mitigation | | **Defender's leverage** | Identity (MFA, AAA) + segmentation (VLAN, VRF, ACL) + visibility (logs, NetFlow) — not firewalls alone | --- ## AI & ML in Network Operations — https://packetmentor.com/topics/ai-ml-in-networking/ > Where machine learning actually shows up in networks today — anomaly detection, predictive maintenance, generative AI assistants, and the difference between marketing AI and the real thing. ## Mental model For most of networking history, "intelligence" meant a human writing if/then rules and SNMP thresholds. *"Alert me when interface utilization > 80%."* That's not AI — that's a static threshold someone guessed once. AI/ML in modern networks does three things humans struggle to do at scale: 1. **Pattern detection** — learn what "normal" looks like across hundreds of metrics, alert on deviations. 2. **Root-cause correlation** — given a symptom, surface the most likely cause from thousands of possible candidates. 3. **Natural-language interface** — translate "show me which switches are running old IOS" into a query the platform can execute. This is now in the CCNA blueprint (added in v1.1) at a recognize-and-describe level — you should understand what AI/ML actually does in networks, not implement the models. ## Predictive AI — the dominant pattern in network operations Predictive AI (or "anomaly detection AI" or "AIOps") consumes streaming telemetry from your network and learns what normal looks like, then alerts on deviations. ### Where it shows up **Wireless (Cisco Meraki + Mist + Catalyst Wireless):** - "AP 5F-23 has unusual roaming failures over the last 4 hours — likely RF interference" - "Client devices on SSID-CORP are seeing higher latency than baseline — root cause: WAN link saturation" - "Today's voice-quality score: 8.3 / 10, down from 9.1 baseline" **Wired (Cisco Catalyst Center / DNA Center):** - "Switch SW-CORE-2 saw CPU spike to 80% during a normally-quiet window — investigate" - "OSPF reconvergence event detected 14:32 UTC, affecting these 5 prefixes, likely cause: link flap on Gi1/0/24" - "Health score for the Charlotte office dropped 12 points — top contributing issue is DNS resolution" **Internet path (ThousandEyes, Catchpoint, AppNeta):** - "Path from your branch to Microsoft 365 now traverses an additional 3 hops via a new ISP peering" - "Increased packet loss between us and Salesforce — issue isolated to AT&T transit" **Security (Cisco SecureX, Microsoft Defender XDR):** - "User account behavior anomalous — accessing servers it never has before" - "Suspicious volume of data leaving over normally-quiet ports" ### Inputs that feed AIOps - **Streaming telemetry** via NETCONF subscriptions, gRPC/gNMI (see [NETCONF & YANG](/topics/netconf-yang/), [gRPC & gNMI](/topics/grpc-gnmi-telemetry/)) - **NetFlow / IPFIX / sFlow** for flow-level visibility (see [NetFlow](/topics/netflow/)) - **Syslog** for events - **SNMP** as the legacy backbone (see [SNMP](/topics/snmp/)) - **Synthetic transactions** from probes - **Endpoint telemetry** for client-side metrics The platform ingests millions of data points per minute, builds a baseline over weeks, then flags deviations. The "AI" is usually a mix of statistical models (Holt-Winters, ARIMA), supervised ML (random forests, gradient boosting), and increasingly transformer-based models for sequence/anomaly tasks. ### What it's actually good at vs marketing claims **Real strengths:** - Catching slow degradation that thresholds miss ("CPU is creeping up over weeks") - Cross-correlating events across many sources ("OSPF flap + interface error + temperature warning on the same switch") - Identifying patterns no human would notice in time **Marketing-driven overclaim:** - "Self-healing networks" — auto-remediation exists for narrow cases (channel change on an AP); broad auto-remediation is risky and rare in production - "Predictive maintenance" — useful but limited; mean-time-to-failure prediction is statistical at best - "Zero-trust AI" — buzzword salad; real zero-trust is a design pattern, not an algorithm A CCNA engineer should expect AIOps platforms to **dramatically reduce mean time to detection** while **modestly reducing mean time to resolution** — you still need humans to investigate and fix. ## Generative AI — the second wave Large language models (GPT-class, Claude, Gemini) have entered network ops in 2024–2026. Three concrete forms: ### 1. Natural-language config ``` Engineer: "Add VLAN 50 named GUEST to all access switches in the Charlotte site, with DHCP relay to 10.99.99.5, and put port Gi1/0/24 on all of them in access mode VLAN 50." Cisco AI Assistant: [generates the per-device CLI, shows diff, awaits approval, executes via Catalyst Center API] ``` The win: fewer typos, faster bulk changes, the engineer reviews intent instead of typing 50 identical configs. The risk: an LLM hallucinating a wrong command. **Production-grade tools always preview before applying.** Never auto-execute LLM output blind. ### 2. Incident summarization ``` [Pages a network engineer at 3 AM] "User reports VPN failures from Charlotte branch starting 03:14 UTC. Likely root cause: ISP MPLS provider experiencing route flapping (correlated with peering session resets visible from ThousandEyes). Recommended next step: failover to backup WAN link until provider stabilizes. Affected users: ~120. Suggested customer comms attached." ``` The win: turns 30 minutes of correlation work into 60 seconds of context-loaded paging. ### 3. Documentation Q&A ``` Engineer: "How does OSPF reconvergence interact with EIGRP redistribution when a stub area is involved?" AI Assistant: [Pulls from Cisco docs + internal runbooks + RFC references, synthesizes an answer with citations] ``` Useful for senior engineers as an "instant rubber-duck colleague." Risky for juniors if used as a substitute for fundamentals. ### Where it lives in real products - **Cisco AI Assistant for Networking** — Catalyst Center add-on - **Cisco AI Assistant for ThousandEyes** — application path analysis - **Microsoft Copilot for Security** — log/incident summarization - **Palo Alto AIOps for NGFW** — firewall config recommendations - **Juniper Mist AI (Marvis)** — wireless and wired troubleshooting ## What CCNA candidates should know For the 200-301 v1.1 exam, you should be able to: 1. **Distinguish predictive vs generative AI** — anomaly detection (predictive) vs natural-language assistants (generative). 2. **Recognize that AIOps platforms exist** (Catalyst Center, Mist AI, ThousandEyes, Cisco AI Assistant, Marvis). 3. **Identify the telemetry sources** that feed them — NetFlow, gNMI, syslog, SNMP. 4. **Understand the typical outputs** — health scores, anomaly alerts, root-cause hypotheses, configuration recommendations. 5. **Know the deployment model** — usually cloud or on-prem appliance, ingesting from devices via streaming protocols. You won't implement AI/ML on the CCNA. The exam tests recognition and the ability to describe what these systems do. ## A simple mental contrast | Era | How you find a problem | |---|---| | **Pre-2000** | A user calls. You SSH in, look at `show log`, guess. | | **2000-2015** | SNMP threshold trips, you get a page. You SSH in, look at `show log`, guess. | | **2015-2022** | Centralized monitoring (Splunk, ELK) shows a graph spike. You SSH in, look at `show log`, guess faster. | | **2022-2026** | Catalyst Center / Mist AI says: "Health score dropped, root cause likely X, here's a remediation suggestion." You verify and apply. | | **2026+** | Generative assistant: "Want me to drain VLAN 20 off SW-CORE-1, push the config to standby, and bring it back?" You approve. | We're not replacing engineers. We're shifting them from typing CLI to reviewing intent. ## Limits to know - **Cold-start problem** — AIOps platforms need weeks of baseline data before useful. Day 1 = noisy. - **Concept drift** — what was normal in winter may not be normal in summer (HVAC patterns, seasonal user counts). - **Black box problem** — when a model flags something as anomalous, it may not explain *why*. Engineers still need fundamentals to investigate. - **Hallucination in generative AI** — LLMs can produce syntactically perfect but wrong Cisco config. Always preview, never auto-apply. - **Privacy & data residency** — sending telemetry to cloud AI providers raises compliance questions in regulated industries. - **Cost** — AIOps platforms scale by ingested telemetry volume. Plan budget per node + per flow. ## Common mistakes 1. **Trusting AI-generated config blind.** Always preview. Cisco's AI Assistant shows the diff before applying — use that workflow. 2. **Confusing AI with automation.** Automation (Ansible, Terraform) is rule-based. AI is pattern-based. Both useful; different. 3. **Buying AIOps without baseline telemetry.** If you don't have NetFlow, gNMI, and syslog flowing to a collector, no AI platform can help you. Foundation first. 4. **Believing "self-healing" hype.** Auto-remediation is narrow. Don't authorize broad changes by AI without human approval. 5. **Treating AI suggestions as facts.** A model is offering a probability, not a diagnosis. Verify before acting. 6. **Skipping fundamentals.** AI removes the need to memorize but not the need to understand. An engineer who relies on the AI assistant without understanding OSPF will eventually face an outage the assistant can't explain. 7. **Ignoring data residency.** Sending European customer telemetry to a US cloud AI service may violate GDPR. Check before deploying. 8. **Conflating CCNA-level recognition with implementing AI.** You need to *describe* AI in networking for the exam, not build models. ## Lab to try (mostly observational) 1. **Cisco DevNet sandbox** has free Catalyst Center reservations. Log in, navigate to Assurance, look at the AI-generated health scores and root-cause panels. 2. **ThousandEyes free tier** — set up a synthetic test from any agent to any service. Watch the path map + AI-suggested degradations. 3. **Cisco AI Assistant demo** at the Cisco Live keynote videos on YouTube — search "Cisco AI Assistant for Networking" — see the natural-language config flow. 4. **Try a public LLM on a real network question:** *"Generate Cisco IOS config to apply MAB on VLAN 20 with fallback to a guest VLAN."* Evaluate the output. Note where it's right, where it hallucinates. 5. **Mist AI / Marvis** demo — Juniper offers public demos of the Mist UI with Marvis queries. Watch how natural-language troubleshooting plays out. 6. **Open-source AIOps experiment:** ingest NetFlow into ElastiFlow or ntopng. Look for anomalous flow patterns. This is what the commercial tools' models are trained to spot — at scale. ## Cheat strip | Concept | Plain English | |---|---| | **Predictive AI / AIOps** | Watches telemetry, learns baseline, alerts on anomalies | | **Generative AI** | LLMs translating natural language → config, summaries, Q&A | | **Telemetry sources** | Streaming via gNMI/gRPC, NetFlow, syslog, SNMP | | **Anomaly detection** | "This metric deviates from baseline" — the core useful pattern | | **Root-cause hypothesis** | Correlated guess from many signals, ranked by likelihood | | **Cisco AI Assistant** | Generative AI inside Catalyst Center for config + ops | | **Mist AI (Marvis)** | Juniper's wireless + wired AI ops | | **ThousandEyes** | Internet path AI — application reachability + ISP issues | | **Self-healing network** | Real but narrow (channel change, retry). Not magic. | | **Cold-start problem** | AIOps needs weeks of data before useful | | **Hallucination** | LLM producing wrong-but-plausible Cisco syntax. Always preview | | **What replaces** | Static SNMP thresholds, manual correlation, ticket-by-ticket triage | | **What doesn't** | OSPF fundamentals, packet capture skill, network design judgment | | **CCNA depth** | Recognize the platforms, distinguish predictive vs generative, know the telemetry sources | --- ## Network Topologies — Bus, Ring, Star, Mesh, Hybrid, Hub-and-Spoke — https://packetmentor.com/topics/network-topologies/ > Every physical and logical topology CompTIA Network+ (N10-009) tests: bus, ring, star, mesh, hybrid, point-to-point, hub-and-spoke, three-tier, spine-leaf. Diagrams, trade-offs, real-world use. ## The one-sentence mental model **Topology = the shape connections make.** N10-009 splits it two ways: the *physical* shape (where the cables run) and the *logical* shape (how data actually flows). They can differ — a star-cabled network with a hub in the middle behaves logically like a bus. ## The six topologies you must know cold | Topology | Shape | What breaks when a link fails | Real-world use | |---|---|---|---| | **Bus** | One shared cable, all hosts tap in | The whole segment | Legacy 10BASE-2/5 coax. Effectively dead. | | **Ring** | Each host connected to two neighbours in a loop | The ring — unless dual-ring (FDDI, SONET) | Token Ring (dead in the enterprise). SONET/SDH in carriers. | | **Star** | Every host has its own cable to a central switch/AP | Only that one host | Every modern LAN. | | **Mesh (full)** | Every node connects to every other node | Nothing user-visible — traffic reroutes | High-availability WAN cores. | | **Mesh (partial)** | Some nodes fully connected, some only to a few | Depends on which link | Enterprise WANs balancing cost vs redundancy. | | **Hub-and-spoke** | One hub site, many branch spokes | If a spoke fails, only that branch. If the hub fails, everything. | Classic MPLS WAN, Fortinet SD-WAN dial-up VPN. | ## Physical vs logical — the gotcha question The Network+ exam loves this: - **Ethernet on a switch** is physically a **star** (every cable goes to the switch) but logically a **bus** (originally — one shared collision domain). Modern switched Ethernet is now logical star too. - **Token Ring on a MAU** is physically a star (cables to the MAU) but logically a ring (token passes host-to-host inside the MAU). If a question says "logical topology" — it's asking about the traffic path, not the cabling. ## Data-center topologies you'll see on N10-009 - **Three-tier** — Access → Distribution → Core. Classic campus. Blocking at STP. - **Collapsed-core** — Distribution + Core merged. Small enterprise. - **Spine-leaf** — Every leaf connects to every spine. No traditional Access/Dist/Core. Uses ECMP + VXLAN. The topology modern DCs use — no oversubscription, predictable latency. - **Point-to-multipoint (PMP)** — One transmitter, many receivers. Wireless bridging. - **Point-to-point (P2P)** — Just two ends. E.g., a fiber leased line between two buildings. ## The exam heuristic - "Which topology has **no single point of failure**?" → **Full mesh** (or dual ring). - "Which topology is **cheapest to cable at scale**?" → **Star**. - "**Modern data-center** fabric?" → **Spine-leaf**. - "**Classic branch WAN**?" → **Hub-and-spoke**. - "**Central management, but branch-to-branch traffic** goes direct?" → **Partial mesh** (or SD-WAN full-mesh overlay). ## Common mistakes 1. **Confusing full mesh cable count.** For N nodes, a full mesh has `N × (N − 1) / 2` links. Six nodes = 15 cables. That's why full mesh doesn't scale. 2. **Assuming Wi-Fi is star.** Wireless is logically PMP — the AP is one transmitter, all clients are receivers on the same channel. 3. **Missing that spine-leaf is not the same as three-tier.** Spine-leaf has no distribution layer. Every leaf is one hop from every other leaf. ## Cheat strip ``` Physical vs logical: cabling shape vs traffic path — can differ. Star: modern LAN. Cheap at scale. One host fails = one host. Full mesh: no SPOF, but N(N-1)/2 links. WAN core only. Hub-spoke: classic branch WAN. Hub fails = everything down. Spine-leaf: modern DC. Every leaf ↔ every spine via ECMP + VXLAN. Three-tier: Access / Distribution / Core. Classic campus. Ring: dead in the LAN. Alive in carriers (SONET dual-ring). Bus: dead. Old coax segments. ``` --- ## Common Ports and Protocols — N10-009 Reference Table — https://packetmentor.com/topics/common-ports-and-protocols/ > Every port and protocol CompTIA Network+ (N10-009) expects you to memorize. Grouped by category with TCP/UDP, the encrypted alternative where one exists, and the one thing most students forget. ## Why this matters The N10-009 blueprint calls out "common ports and protocols" as a stand-alone objective. Expect a handful of straight-recall questions: *"Which port does LDAPS use?"* and *"Which protocol runs on TCP 3389?"* — no context, no scenario. If you know the table below cold, those points are free. ## Category 1 — File transfer & remote access | Port | Protocol | TCP/UDP | Secure? | |---|---|---|---| | 20 / 21 | FTP (data / control) | TCP | No | | 22 | SSH / SCP / SFTP | TCP | Yes | | 23 | Telnet | TCP | No | | 3389 | RDP | TCP (also UDP for perf) | Yes | | 5900 | VNC | TCP | Depends | | 989 / 990 | FTPS (data / control) | TCP | Yes | ## Category 2 — Mail | Port | Protocol | TCP/UDP | Notes | |---|---|---|---| | 25 | SMTP | TCP | Server-to-server. | | 110 | POP3 | TCP | Legacy client pull. | | 143 | IMAP | TCP | Modern client pull. | | 465 | SMTPS (SSL) | TCP | Deprecated but still tested. | | 587 | SMTP submission (TLS) | TCP | The modern outbound. | | 993 | IMAPS | TCP | | | 995 | POP3S | TCP | | ## Category 3 — Web & directory | Port | Protocol | TCP/UDP | |---|---|---| | 80 | HTTP | TCP | | 443 | HTTPS | TCP | | 389 | LDAP | TCP + UDP | | 636 | LDAPS | TCP | | 88 | Kerberos | TCP + UDP | ## Category 4 — Network services | Port | Protocol | TCP/UDP | Notes | |---|---|---|---| | 53 | DNS | UDP + TCP | UDP for queries, TCP for zone transfers & big responses. | | 67 / 68 | DHCP (server / client) | UDP | Broadcast at layer 2. | | 69 | TFTP | UDP | No auth, no encryption. | | 123 | NTP | UDP | | | 162 | SNMP trap | UDP | | | 161 | SNMP get/set | UDP | | | 514 | Syslog | UDP (usually) | Some deployments use TCP 6514 for TLS-secured syslog. | | 6514 | Syslog over TLS | TCP | The secure replacement. | ## Category 5 — Auth & VPN | Port | Protocol | TCP/UDP | Notes | |---|---|---|---| | 500 | IKE (IPsec Phase 1) | UDP | | | 4500 | IPsec NAT-Traversal | UDP | Used when a NAT device is between the peers. | | 1701 | L2TP | UDP | | | 1723 | PPTP | TCP | Insecure, still shows on the exam. | | 1812 | RADIUS auth | UDP | | | 1813 | RADIUS accounting | UDP | | | 49 | TACACS+ | TCP | Encrypts the whole payload — differentiates it from RADIUS. | ## Category 6 — Databases & other | Port | Protocol | TCP/UDP | |---|---|---| | 1433 | Microsoft SQL Server | TCP | | 3306 | MySQL / MariaDB | TCP | | 5432 | PostgreSQL | TCP | | 5060 / 5061 | SIP / SIP-TLS | TCP + UDP / TCP | | 3389 | RDP | TCP | ## Common exam traps 1. **DHCP server = UDP 67, client = UDP 68.** The direction matters. A firewall question that asks "which port must you permit for clients to reach the DHCP server?" — you permit **destination UDP 67**. 2. **DNS = UDP AND TCP.** UDP for normal queries, TCP for zone transfers between servers or replies over 512 bytes (very common with DNSSEC). 3. **RADIUS encrypts the password only. TACACS+ encrypts the entire payload.** That's why TACACS+ is preferred for admin authentication. 4. **SNMPv1/v2c community strings are cleartext.** SNMPv3 adds authentication and encryption — always the "secure" answer. 5. **Syslog is UDP 514 by default.** If the exam mentions "secure syslog", think TCP 6514 with TLS. ## Cheat strip ``` FTP 20/21 TCP SFTP 22 TCP FTPS 989/990 TCP Telnet 23 TCP SSH 22 TCP HTTP 80 TCP HTTPS 443 TCP DNS 53 UDP+TCP DHCP 67/68 UDP NTP 123 UDP SNMP 161 UDP SNMPTrap 162 UDP Syslog 514 UDP SyslogTLS 6514 TCP LDAP 389 LDAPS 636 TCP RADIUS 1812/1813 UDP TACACS+ 49 TCP IKE 500 UDP IPsec NAT-T 4500 UDP RDP 3389 TCP+UDP SMB 445 TCP SMTP 25 TCP SMTPS 465 / SUB 587 POP3 110 / POP3S 995 IMAP 143 / IMAPS 993 SQL 1433 (MSSQL) / 3306 (MySQL) / 5432 (Postgres) ``` --- ## Cable Connector Types — Copper, Fiber, Coax — https://packetmentor.com/topics/cable-connectors-types/ > Every connector CompTIA Network+ (N10-009) shows in exam images: RJ45, RJ11, F-type, BNC, SC, LC, ST, MTRJ, MPO, LC-APC vs LC-UPC. What each pairs with and the one-line 'how to tell them apart' rule. ## Copper connectors | Connector | Pins | Cable | Where you'll see it | |---|---|---|---| | **RJ45** | 8 | Cat5/5e/6/6a/7/8 UTP-STP | Every Ethernet drop. | | **RJ11** | 4 or 6 | Twisted pair (2 or 3 pair) | POTS phone, DSL. | | **F-type** | Center + threaded barrel | RG-6, RG-59 coax | Cable modems, satellite TV. | | **BNC** | Center + bayonet twist | RG-58, RG-59 coax | Legacy 10BASE-2, some security cameras. | | **DB-9 / RS-232** | 9 | Serial | Cisco console (legacy). | | **USB-A / USB-C / Micro-USB** | — | — | Modern console access on switches/routers. | **How to tell RJ45 from RJ11 at a glance:** RJ45 is wider (8 conductors). RJ11 is narrower (4-6). If you can only fit two pairs, it's RJ11. ## Fiber connectors — the four the exam expects | Connector | Shape / Mount | Size | |---|---|---| | **SC** — Subscriber Connector | Square. Push-pull, "stick and click". | ~9 mm ferrule. Large. | | **LC** — Local Connector | Square with a small RJ45-style latch. Push-pull. | ~4.5 mm ferrule. Half the size of SC. | | **ST** — Straight Tip | Round with a bayonet twist-lock. "Stab and twist". | Older tech. Legacy MMF. | | **FC** — Ferrule Connector | Round with a threaded screw-on barrel. | Test equipment, precise alignment. | | **MTRJ** — Mechanical Transfer RJ | One connector body holds both TX + RX fibers. RJ-style latch. | Uncommon. | | **MPO / MTP** | Rectangular. Holds 12 or 24 fibers in a ribbon. | 40 GbE / 100 GbE, spine-leaf DC. | **How to tell SC from LC:** LC is half the size of SC. If it clicks with a latch like RJ45, it's LC. If it slides in and clicks with no lever, it's SC. ## APC vs UPC — the color code that saves cables Fiber endfaces are polished two ways: - **UPC (Ultra Physical Contact)** — flat endface. **Blue** connector body. - **APC (Angled Physical Contact)** — 8° angled endface. Lower return loss. **Green** connector body. If you plug an APC into a UPC port, the angled ferrule crashes into the flat one and physically damages both. **Blue mates blue, green mates green.** Never mix. ## Single-mode vs multi-mode (color code) You can spot cable type on the exam by the jacket color: - **Yellow jacket** → single-mode (SMF, ~9 µm core, up to ~40 km). - **Orange jacket** → OM1 or OM2 multi-mode (50–62.5 µm core). - **Aqua jacket** → OM3 or OM4 laser-optimized MMF. - **Erika violet / lime** → OM5 wideband MMF. ## Coax types the exam mentions - **RG-6** — thick, F-type connector, TV / cable modem. - **RG-59** — thinner, older CCTV. - **RG-58** — the old 10BASE-2 "thinnet" cable. BNC connectors. Dead in modern networking. ## Common exam traps 1. **APC vs UPC = green vs blue.** Miss this and you'll miss the picture-based question. 2. **MPO/MTP is what plugs into a 40G/100G port** on a spine-leaf switch. If the exam says "one connector, twelve fibers", it's MPO. 3. **RJ45 shielded (STP) uses drain wire termination** — the connector has a metal shield around it. Not visually different in a small image; if the question says "office with heavy EMI", pick shielded. 4. **BNC ≠ Ethernet in modern networks.** If you see BNC on the exam and Ethernet is the answer, it's a legacy scenario or a distractor. 5. **F-type is threaded, BNC is twist-lock.** Both are coax. Threaded barrel = F-type. ## Cheat strip ``` RJ45 8-pin Cat5+ UTP — every LAN drop RJ11 4/6-pin — POTS / DSL F-type threaded — TV / cable modem BNC bayonet — legacy coax SC square push-pull — SMF/MMF, larger LC square with latch — SMF/MMF, half-size SC (modern) ST round bayonet — legacy MMF MPO ribbon, 12+ fibers — 40G / 100G APC green angled 8° — never mate to UPC UPC blue flat — never mate to APC ``` --- ## Business Continuity Metrics — RPO, RTO, MTBF, MTTR + Site Types — https://packetmentor.com/topics/business-continuity-metrics/ > The four continuity metrics on CompTIA Network+ (N10-009) — RPO, RTO, MTBF, MTTR — plus cold/warm/hot site types and how a real change/incident/DR runbook uses them. ## Why this is on N10-009 CompTIA moved business-continuity vocabulary heavily into N10-009. Expect scenario questions like *"The CFO says the org can lose no more than 15 minutes of transactions. Which metric is she describing?"* — the answer is RPO, not RTO. You need to know the difference cold. ## The four metrics ### RPO — Recovery Point Objective **How much data are you willing to lose?** Measured in time — "15 minutes of transactions" or "24 hours of email". RPO directly drives your backup frequency. If RPO = 1 hour, you back up (or replicate) at least every hour. Mental picture: RPO is a line drawn **backwards** from the outage. Everything between that line and the outage is data lost. ``` Backup Backup Backup [OUTAGE] |----1hr---|----1hr---|----1hr---→ RPO = 1 hour ↑ up to 1hr of data lost ``` ### RTO — Recovery Time Objective **How long can you be down?** Measured in time — "4 hours to bring the payroll system back up". RTO drives the DR architecture: cold site (long RTO OK), hot site (minutes RTO required). Mental picture: RTO is a line drawn **forward** from the outage. If you're not back up by then, you missed SLA. ``` [OUTAGE] ..... service restored ↑ ↑ start RTO = time-to-recover ``` ### MTBF — Mean Time Between Failures **How often does this piece of gear fail?** Reliability metric from the manufacturer. Higher = more reliable. A router with MTBF 200,000 hours will, on average, fail every ~23 years. You use MTBF for capacity planning and spare-count decisions. ### MTTR — Mean Time To Repair (or Restore) **When it fails, how long to fix?** MTTR includes detection + travel + repair + verification. If MTTR is 4 hours and MTBF is 200,000 hours, availability ≈ MTBF / (MTBF + MTTR) → very close to 100%. ## Site types (DR) | Site type | What's there | Bring-up time | Cost | |---|---|---|---| | **Cold** | Space + power + cooling. No gear installed. | Days to weeks. | Cheapest. | | **Warm** | Some hardware, partial config, stale data. | Hours. | Middle. | | **Hot** | Fully live mirror, real-time replication. | Minutes. | Expensive. | | **Cloud DR** | Compute + storage in AWS/Azure/GCP, ready to spin up. | Minutes to hours depending on tier. | Variable — pay for compute only when failover happens. | If the exam scenario says *"tight RTO, budget-constrained, mostly-idle DR"* → **cloud DR**. If it says *"regulatory requirement for near-zero downtime"* → **hot site**. If it says *"large industrial with days-long tolerance"* → **cold site**. ## Related terms you'll see - **MTBSI** — Mean Time Between System Incidents. Similar to MTBF but for the system, not the component. - **SLA** (Service Level Agreement) — the contractual availability target. "Four nines" = 99.99% = 52 minutes downtime/year. - **BCP** (Business Continuity Plan) — the whole document that says what stays running during a disaster. - **DRP** (Disaster Recovery Plan) — the technical playbook to *restore* IT after a disaster. Subset of the BCP. ## Common exam traps 1. **Confusing RPO with RTO.** RPO = data loss tolerance (looks backward). RTO = downtime tolerance (looks forward). This is the #1 tested distinction. 2. **Assuming a hot site means zero data loss.** A hot site with async replication still has an RPO > 0. Only synchronous replication gets you RPO = 0 (and it's expensive at latency-sensitive distance). 3. **Mixing up MTBF and MTTR.** MTBF is between failures (reliability). MTTR is during a failure (recovery). Both are means / averages. 4. **Ignoring people/process cost.** DR isn't just gear. The exam expects you to know that runbooks, training, and failover drills are part of BCP. ## Real runbook shape A production DR runbook typically has: - Trigger criteria (what counts as a disaster?) - RPO / RTO targets per system - Roles + call tree - Failover steps (per system, in dependency order) - Failback steps (once primary is restored) - Post-incident: RCA + runbook update ## Cheat strip ``` RPO backward data loss tolerance drives backup freq RTO forward downtime tolerance drives DR site type MTBF between failures reliability (high=good) MTTR during a failure recovery speed (low=good) Cold space only days cheap Warm partial gear hours middle Hot live mirror minutes expensive Cloud DR pay-per-use variable flexible BCP = the whole plan | DRP = the technical subset SLA "four nines" = 99.99% = 52 min downtime/year ``` --- ## Twisted-Pair Cable Categories — Cat 5, 5e, 6, 6a, 7, 8 — https://packetmentor.com/topics/cable-categories-cat5-cat8/ > Every twisted-pair category CompTIA Network+ (N10-009) tests: max speed, max distance, PoE class, when to pick each. Plus the shielding letters (U/UTP, F/UTP, S/FTP) that trip up half the room. ## The category table | Category | Max speed | Max distance @ max speed | Frequency | Typical use | |---|---|---|---|---| | **Cat 3** | 10 Mb | 100 m | 16 MHz | Legacy voice / 10BASE-T. Dead. | | **Cat 5** | 100 Mb | 100 m | 100 MHz | Deprecated. Any surviving Cat 5 should be re-pulled. | | **Cat 5e** | 1 Gb | 100 m | 100 MHz | Minimum you'd install today. Common in older buildings. | | **Cat 6** | 1 Gb / 10 Gb | 100 m / **55 m** | 250 MHz | Common enterprise. 10 Gb only at short distance due to alien crosstalk. | | **Cat 6a** | 10 Gb | 100 m | 500 MHz | The current "safe" enterprise choice. Full 10G over full run. | | **Cat 7** | 10 Gb | 100 m | 600 MHz | Requires GG45 or TERA connector (not RJ45). Rare in the US. | | **Cat 7a** | 10 Gb (up to 40 Gb short) | 100 m / short | 1000 MHz | Same connector caveat. | | **Cat 8** | 25 / 40 Gb | **30 m** | 2000 MHz | Data-center top-of-rack to server. Not a general campus cable. | ## The shielding letters You'll see labels like `U/UTP`, `F/UTP`, `S/FTP`. The two letters mean: - **First letter (before the slash)** — overall cable shielding. - **Second letter (after the slash)** — per-pair shielding. Values: - **U** = unshielded - **F** = foil - **S** = braided screen So: | Label | Overall | Per pair | Meaning | |---|---|---|---| | **U/UTP** | none | none | Plain UTP. Cat 5/5e/6 standard. | | **F/UTP** | foil | none | Foil around all four pairs. Cat 6a option. | | **S/UTP** | braid | none | Braid around all four pairs. | | **U/FTP** | none | foil | Foil per individual pair. Cat 6a / Cat 7. | | **F/FTP** | foil | foil | Double-shielded. Cat 6a for high-EMI. | | **S/FTP** | braid | foil | Braid + foil per pair. Cat 7 / Cat 7a. | **Rule of thumb**: higher category + high-EMI environment (factory floor, hospital MRI, PoE++) → prefer shielded. Home / typical office → UTP is fine and easier to terminate. ## PoE and cable heating At 802.3bt PoE++ (up to 90 W), 4-pair copper runs get warm. Ampacity rises. For high-power PoE: - Use **Cat 6a or Cat 6** with all four pairs. - Prefer **shielded** for bundled runs (heat dissipation + crosstalk). - Don't bundle more than 24 PoE cables tightly — heat. - Check that your patch cables match category rating; a Cat 5e patch on a Cat 6a link becomes the weakest hop. ## Common exam / real-world mistakes 1. **Assuming Cat 6 does 10 Gb over 100 m.** It doesn't — capped at 55 m. If the exam says "10 Gb over 90 m", the answer is Cat 6a or better. 2. **Confusing Cat 7 with RJ45.** Cat 7 uses GG45 or TERA — NOT RJ45. Practically, most "Cat 7" installs in the US use Cat 6a electrically. Cat 8 is what you actually see terminated with RJ45 in DCs. 3. **Ignoring the patch-panel and patch-cord.** A rated Cat 6a horizontal run degrades to Cat 5e speed if the patch cords aren't the same rating. 4. **Overlooking bend radius.** Cat 6a bent tighter than 4× cable diameter loses electrical characteristics permanently. 5. **Forgetting that "shielded" needs a ground path.** F/UTP with no ground bond at the patch panel does nothing. ## Cheat strip ``` Cat 5 100 Mb 100 m 16 MHz dead Cat 5e 1 Gb 100 m 100 MHz minimum today Cat 6 1 Gb 100 m 250 MHz or 10 Gb / 55 m only Cat 6a 10 Gb 100 m 500 MHz safe enterprise choice Cat 7 10 Gb 100 m 600 MHz GG45/TERA connector, rare US Cat 8 25/40G 30 m 2000 MHz DC top-of-rack U/UTP plain UTP Cat 5/5e/6 default F/UTP foil overall Cat 6a option U/FTP foil per pair Cat 6a / Cat 7 S/FTP braid overall + foil pair Cat 7/7a — max shielding PoE++ prefer Cat 6a shielded. Don't over-bundle. Bend radius >= 4x cable diameter. ``` --- ## Common Network Attacks — On-Path, DNS Poisoning, DDoS, Deauth — https://packetmentor.com/topics/common-network-attacks/ > Every attack CompTIA Network+ (N10-009) tests by name: on-path (MITM), DNS poisoning, ARP spoofing, DHCP starvation, MAC flooding, DDoS (volumetric, protocol, application), deauth, evil twin, rogue AP, VLAN hopping. ## Layer-2 attacks (Ethernet + switch) ### ARP spoofing / ARP poisoning Attacker sends unsolicited ARP replies saying "the default gateway IP → MY MAC address." Every host on the VLAN updates its cache and now sends traffic to the attacker. **Defense**: **Dynamic ARP Inspection (DAI)** on the switch. Only ARP replies matching the DHCP-snooping binding table are allowed. ### DHCP starvation and DHCP spoofing - **Starvation** — attacker floods the DHCP server with fake DISCOVERs, exhausting the pool. Legit clients can't get addresses. - **Spoofing** — attacker runs a rogue DHCP server that answers first, handing out its own IP as the gateway (then MITM). **Defense**: **DHCP snooping**. Trust only the port toward the real DHCP server; drop server-side messages from every other port. ### MAC flooding (CAM table overflow) Attacker floods the switch with millions of source MACs. The CAM table fills. Switch fails open — every frame becomes broadcast to every port. Attacker sees traffic they shouldn't. **Defense**: **port-security** capping MAC addresses per port (`switchport port-security maximum 2`), sticky learning, err-disable on violation. ### VLAN hopping Two variants: - **Double-tagging** — attacker inserts a 802.1Q tag for VLAN A, native VLAN is A, switch strips it → the inner tag for VLAN B gets forwarded there. - **Switch spoofing** — attacker's port auto-negotiates DTP into a trunk. Now they see every VLAN. **Defense**: disable DTP (`switchport nonegotiate`), set trunks explicitly, change native VLAN to an unused/blackholed VLAN, don't allow untagged traffic on the native VLAN. ## DNS attacks ### DNS poisoning / cache poisoning Attacker injects a fake DNS response into a resolver's cache before the real one arrives. Every subsequent lookup for that FQDN returns the attacker's IP. **Defense**: **DNSSEC** (signed responses), randomize source ports, use trusted resolvers only. ### DNS hijacking / redirection Compromise the DNS server itself (or the DHCP-advertised DNS server on the LAN). **Defense**: harden resolvers, monitor for lookalike-domain queries, use DoT/DoH between clients and known resolvers. ## Man-in-the-middle (now called "on-path") CompTIA renamed MITM to **on-path attack** in the N10-009 objectives. Same concept: attacker sits in the traffic path and intercepts / modifies. Techniques used to *become* on-path include ARP spoofing (LAN), DNS poisoning (WAN), rogue Wi-Fi (WLAN), and BGP hijacking (Internet). **Defense**: end-to-end TLS with certificate pinning, HSTS, mutual auth, WPA3 SAE for Wi-Fi. ## DDoS categories Network+ splits DDoS three ways: - **Volumetric** — flood the pipe (UDP amplification via DNS/NTP/Memcached). Mitigated by upstream scrubbing + BGP flowspec. - **Protocol** — exhaust the state on firewalls / LBs (SYN flood, Slowloris). Mitigated by SYN cookies + rate limiting. - **Application** — HTTP-layer flood (large POSTs, expensive queries). Mitigated by WAF, rate limits, CAPTCHAs. ## Wireless attacks ### Rogue AP An unauthorized AP plugged into the corporate network. Provides an alternate way in. **Defense**: **WIPS** (Wireless IPS) scanning + wired-side rogue detection (matching AP MAC seen wirelessly to a wired switch port), 802.1X on Ethernet ports. ### Evil twin A rogue AP that broadcasts the same SSID as the corporate SSID, hoping clients auto-connect. **Defense**: WPA3 SAE (mutual auth), 802.1X client cert validation, WIPS. ### Deauthentication attack Attacker forges 802.11 deauth management frames as the AP. Clients disconnect, then reconnect — attacker captures the WPA2 handshake for offline cracking. **Defense**: **802.11w Protected Management Frames (PMF)** — mandatory in WPA3, optional in WPA2. ### Jamming RF-level attack. Legitimate frames drown in noise. **Defense**: spectrum analyzers, WIPS RF detection, coordinate with security to find + remove the jammer. ## Social engineering — brief but tested CompTIA lists a handful you need to name: - **Phishing / spear-phishing / whaling** — email lures. Whaling = C-suite target. - **Vishing** — voice phishing. - **Smishing** — SMS phishing. - **Pretexting** — fabricated scenario ("I'm from IT, need your password"). - **Tailgating / piggybacking** — following someone into a secure area. ## Common exam / real-world mistakes 1. **Calling it MITM.** N10-009 uses "on-path". The old terminology still gets you the right answer, but new-style questions use the new term. 2. **Confusing rogue AP and evil twin.** Rogue = unauthorized. Evil twin = unauthorized *and* impersonating an authorized SSID. 3. **Assuming HTTPS defeats ARP spoofing.** HTTPS defeats *content* interception, but the attacker can still see SNI, still block traffic, still redirect to their own captive portal. 4. **Mixing up DHCP snooping and DAI.** Both live on the switch. Snooping validates DHCP; DAI validates ARP by referencing the snooping table. Order: snooping first, DAI on top. 5. **Ignoring PMF for WPA2 networks.** Deauth is trivial without PMF. Turn it on. ## Cheat strip ``` Layer-2: ARP spoof → DAI DHCP spoof/starve → DHCP snooping MAC flood → port-security VLAN hopping → disable DTP, explicit trunks, unused native VLAN DNS: Poisoning → DNSSEC + port randomization Hijacking → hardened resolvers, DoT/DoH On-path (MITM): end-to-end TLS + pin + WPA3 + HSTS DDoS: Volumetric → upstream scrubbing Protocol → SYN cookies, rate limits Application → WAF, rate limits Wireless: Rogue AP → WIPS + wired-side detection Evil twin → WPA3 SAE + WIPS Deauth → PMF (802.11w) — mandatory in WPA3 Jamming → spectrum analyzer, physical location Social eng: phishing / vishing / smishing / whaling / pretexting / tailgating ``` --- ## FortiGate Architecture — FortiOS, VDOMs, and the Session Table — https://packetmentor.com/topics/fortigate-architecture/ > How a FortiGate is built end-to-end: FortiOS on ASIC-accelerated hardware, the packet flow, VDOMs, admin access, factory reset, and the stateful session table NSE 4 asks about. ## The one-sentence mental model **FortiOS is the OS. Every FortiGate — from a 60F desktop unit to a 7000-series chassis — runs the same FortiOS build.** The hardware differs (ASICs, port count, throughput), but the CLI, GUI, and packet-flow model are identical. Learning one FortiGate = learning them all. ## The packet flow (memorize this shape) Every packet that enters a FortiGate goes through the same steps: ``` Ingress interface ↓ DoS policy check ↓ Session table lookup ────────→ [existing session? fast path] ↓ (new session) Routing lookup ↓ Policy lookup (firewall policy) ↓ NAT (SNAT / DNAT) ↓ Security profiles (AV, web filter, app control, IPS, SSL inspection) ↓ Egress interface ``` When something is "not working" on a FortiGate, tracing where along this flow the packet died is the whole troubleshooting workflow. FortiOS gives you `diagnose debug flow` to watch it in real time. ## VDOMs — one box, many virtual firewalls VDOMs (Virtual Domains) partition a FortiGate into independent logical firewalls: - Each VDOM has its own **routing table**, **interfaces**, **firewall policies**, **admin users**. - VDOMs communicate via **inter-VDOM links** (internal virtual pairs) or via traditional external interfaces looped back. - Two modes: **NAT/Route mode** (typical Layer 3 firewall) and **Transparent mode** (Layer 2 bump-in-the-wire). - The **root VDOM** is always present and hosts global admin configuration (upgrades, HA, SNMP). Use cases: - MSP hosting many customers on one box (each customer = one VDOM). - Enterprise separating prod / dev / DMZ traffic on a single 3000-series. ## Admin access - **GUI** (HTTPS on port 443 by default — configurable). Every day operations. - **CLI over SSH** (port 22 by default). Automation and scripts. - **Console** — serial (9600 8N1, RJ45 or USB-C depending on model). Factory reset, boot break. - **REST API** — token-authenticated, JSON payloads. Used by FortiManager and CI/CD pipelines. Every admin login is against a defined **admin account** with a **profile** (super_admin, prof_admin, or a custom role). Trusted-host IPs restrict where a given admin can log in from. ## Factory reset and boot Two ways: 1. **From the CLI**: `execute factoryreset` — clears everything, reboots. 2. **From the boot menu**: interrupt during boot (`Ctrl+C` on console), pick "System reset". Used when you've locked yourself out or corrupted config. Two flash regions: **primary** (active firmware) and **secondary** (previous). `execute set-next-reboot secondary` reboots into the older image — a lifesaver during upgrades. ## The session table Every stateful connection through the FortiGate has an entry: ``` session info: proto=6 proto_state=01 duration=42 expire=3540 policy_id=17 tos=ff/ff ips_view=0 origin->src=10.10.1.5:52012 dst=8.8.8.8:443 reply->src=8.8.8.8:443 dst=203.0.113.10:52012 ``` Key fields NSE 4 tests you on: - **policy_id** — which firewall policy matched. If you're troubleshooting, this is the first thing you check. - **proto_state** — TCP state (01 = SYN, 05 = ESTABLISHED, etc.). - **expire** — how long until this session is aged out. - **origin / reply** — the two directions of the flow, with NAT already applied. CLI: `diagnose sys session list` or `diagnose sys session filter` to narrow to one flow. ## Common exam / real-world mistakes 1. **Assuming policy order doesn't matter.** FortiGate evaluates policies top-down. The **first match wins**. A permissive "any/any" rule at the top makes every specific rule below it useless. 2. **Forgetting NAT is inside the policy, not a separate table.** On FortiGate, NAT is a checkbox / IP pool on the firewall policy itself. There's no separate NAT rule set the way there is on some Cisco platforms. 3. **Mixing up transparent mode.** In transparent mode the FortiGate becomes a Layer 2 device — no routing, no NAT. Rare in exams but tested. 4. **Ignoring the session table when troubleshooting.** If a policy change isn't taking effect, existing sessions still match the *old* policy until they expire. `diagnose sys session clear` after major changes. ## Cheat strip ``` FortiOS same OS across every model. Learn once. VDOM logical firewall on shared hardware. Root VDOM = global cfg. Modes NAT/Route (L3, default) | Transparent (L2 bump). Access GUI HTTPS 443 | CLI SSH 22 | Console 9600 8N1 | REST API Reset execute factoryreset OR boot-menu system reset Flash primary + secondary. set-next-reboot secondary = rollback. Flow ingress → session lookup → route → policy → NAT → profiles → egress Session diagnose sys session list (check policy_id, proto_state, expire) ``` --- ## FortiGate Firewall Policies — Structure, Order, NAT Inline — https://packetmentor.com/topics/fortigate-firewall-policies/ > How firewall policies work on FortiOS: the 6 core fields, top-down first-match evaluation, how NAT lives inside the policy, and the diagnostic that tells you which policy matched. ## The one-sentence mental model **A FortiGate firewall policy is a row in a spreadsheet.** Each row asks: *"For this source coming from this interface going to this destination on this port — allow or deny? Apply NAT? Apply security profiles?"* The engine reads rows top-down and stops at the first match. ## The six required fields | Field | What it means | |---|---| | **Incoming Interface** | Where the packet enters (physical port, VLAN, SD-WAN member, VPN tunnel). | | **Source** | Address / group / user / device the packet is from. | | **Outgoing Interface** | Where the packet must exit — after routing decides. | | **Destination** | Address / group / FQDN / geography the packet is going to. | | **Service** | TCP/UDP ports (HTTP, HTTPS, custom-app, service groups). | | **Action** | ACCEPT · DENY · IPSEC (put in a specific tunnel). | Optional extras on the same policy: - **NAT** — Enable + choose outbound IP (interface / IP pool). - **Security Profiles** — AV, web filter, application control, IPS, SSL inspection, DLP. - **Logging** — no log / log security events / log all sessions. - **Traffic Shaping** — bandwidth limit / guarantee. - **Schedule** — always / business hours / custom. ## Policy order matters — a lot FortiGate reads policies top-down. First policy whose (interface + source + destination + service) matches the packet wins. Every subsequent policy is skipped for this flow. **Practical rule:** put specific rules on top, general rules at the bottom. ``` policy id 1 — DENY guest-VLAN → HR-server (specific) policy id 2 — ALLOW guest-VLAN → internet (broad) policy id 3 — ALLOW LAN → internet (broadest) policy id 4 — DENY any → any (catch-all — often implicit) ``` CLI to reorder: `config firewall policy` → `move before `. ## NAT lives inside the policy This is the biggest conceptual shift for engineers coming from Cisco ASA or IOS: **On FortiGate, you don't write a NAT rule separate from a firewall rule.** You write ONE firewall policy that says both "allow this traffic" AND "NAT it". ``` policy id 5: incoming = internal source = 10.0.0.0/24 outgoing = wan1 dest = all service = ALL action = ACCEPT NAT = enable (use outgoing interface IP = SNAT to wan1's IP) ``` That single policy replaces both a Cisco ACL permit + a `ip nat inside source` command. For destination NAT (port forwarding), use a **Virtual IP (VIP)** object as the destination — the VIP defines the external-IP:port → internal-IP:port mapping and the policy just references it. ## Central NAT — the other mode FortiOS has a global toggle: **central-nat enable**. - **Off (default):** NAT lives on each policy (as above). - **On:** NAT policies live in a **separate central NAT table**. Firewall policies just permit/deny; central-NAT rules translate. Closer to the Cisco / Palo Alto model. Central NAT is preferred when you have many policies sharing the same NAT pool — it deduplicates the NAT config. NSE 4 tests you on knowing the difference and when to switch modes. ## Verifying which policy matched The single most useful diagnostic in FortiOS: ``` diagnose sys session list # shows every current session with policy_id + NAT direction ``` Or a live packet-flow trace: ``` diagnose debug flow filter addr 10.10.1.5 diagnose debug flow show console enable diagnose debug enable diagnose debug flow trace start 10 ``` The `flow trace` output shows: which policy matched (`policy-id=17`), what NAT was applied, which security profile ran, and whether the packet was allowed or denied. ## Common exam / real-world mistakes 1. **Not enabling NAT on the outbound policy.** Traffic goes through, then can't return because the source IP is still the private LAN IP. Symptom: outbound TCP handshake fails. Fix: check the NAT checkbox on the policy. 2. **Wrong interface pair.** Forgetting to change "outgoing interface" from `any` when the wrong exit was picked by routing. 3. **Address object leaks.** Editing a shared address object silently changes every policy using it. 4. **Assuming policy changes affect existing sessions.** They don't — existing sessions keep matching the old policy until they age out or you clear them. 5. **Overlooking `implicit deny`.** The last policy is always an implicit deny — but it doesn't log by default. Turn on logging for the implicit-deny rule during troubleshooting to see what's actually being blocked. ## Cheat strip ``` 6 fields src-if src dst-if dst service action Extras NAT | profiles | logging | shaping | schedule Order top-down, first match wins. Move: move X before Y. NAT on the policy (default). Or global central-NAT table. DNAT use a VIP object as the destination. Trace diagnose sys session list (which policy matched) diagnose debug flow ... (live packet path) Implicit last rule = deny any. Turn on log to see drops. ``` --- ## FortiGate Security Profiles — AV, Web Filter, App Control, IPS — https://packetmentor.com/topics/fortigate-security-profiles/ > Every security profile FortiGate applies inline to firewall-policy traffic: antivirus, web filter, application control, IPS, DNS filter, DLP, and SSL/SSH deep inspection — plus how to combine them without breaking users. ## Where profiles run in the packet flow Recall the FortiGate flow: ingress → session lookup → route → policy match → NAT → **security profiles** → egress. Security profiles run *after* the policy accepts, so profile CPU is only spent on already-allowed traffic. Order they run inside the profile stage: ``` SSL/SSH inspection (decrypt encrypted flows) ↓ DNS filter (does the FQDN look malicious?) ↓ Web filter (URL category / block list) ↓ Application control (Facebook, TikTok, TeamViewer signatures) ↓ Antivirus (file scan on transfer) ↓ IPS (protocol anomaly / exploit signatures) ↓ DLP (Data Loss Prevention — outbound credit card / SSN) ↓ File filter / video filter ``` ## The seven profiles NSE 4 expects you to know ### Antivirus Scans files as they transfer through the FortiGate. Uses signature engines (FortiGuard AV) + optional cloud sandbox (FortiSandbox integration). Modes: **flow-based** (fast, streams the file) vs **proxy-based** (buffers the whole file, catches more, higher latency). ### Web filter Blocks/allows based on URL category (FortiGuard cloud lookup) or static URL lists. Categories are the actual test material — Adult, Gambling, Social Networking, etc. Actions per category: **allow · block · monitor · warning (interstitial page) · authenticate (require login)**. ### Application control Identifies apps by their protocol signature, not just port. Blocks BitTorrent even when it's on port 443. Recognizes ~5000 apps out of the box. Practical use: block TikTok and Instagram on corporate SSIDs; allow but shape Zoom. ### IPS (Intrusion Prevention) Signature-based inspection for known exploits. Signatures are pulled from FortiGuard. Each signature has a **severity** and **default action** (allow / block / monitor). You can override per signature. Modes: **detection-only** (log, don't block — useful for tuning) vs **prevention** (log + drop). ### SSL/SSH deep inspection Terminates the client's TLS session on the FortiGate using a re-signed certificate, inspects the plaintext, then re-encrypts to the destination. Without this, AV / web-filter / app-control / DLP can only see the SNI in the ClientHello, not the actual HTTP request. Requires: **a FortiGate CA cert distributed to every endpoint** (via GPO / MDM). Without that, browsers show cert warnings. Two modes: **certificate inspection** (SNI-only, no re-signing — lightweight) vs **deep inspection** (full MITM decrypt). ### DNS filter Blocks lookups for known-malicious FQDNs before the connection is even attempted. Cheap layer of defense; often the first to catch phishing links. ### DLP (Data Loss Prevention) Watches outbound traffic for defined patterns (credit-card regex, SSN, custom fingerprints, watermarked docs). Actions: log · block · quarantine sender. ## Applying profiles to a policy In the GUI: edit a firewall policy → scroll to "Security Profiles" → toggle each profile you want and pick which profile object. CLI: ``` config firewall policy edit 17 set utm-status enable set av-profile "corporate-av" set webfilter-profile "no-adult-no-gamble" set application-list "block-p2p" set ips-sensor "protect-servers" set ssl-ssh-profile "deep-inspect" set logtraffic all next end ``` ## The "will it break the user experience?" trade-off Every profile you enable adds CPU + latency + potential false positives. Practical starting point: - **Always:** AV (proxy or flow), DNS filter, IPS in detection first. - **Common:** Web filter (block Adult / Gambling / Malware categories), app control (block P2P + TOR). - **Careful:** SSL deep inspection — requires cert deployment. Start with high-risk categories only (banking, cloud storage). Add slowly. - **Advanced:** DLP — needs pattern tuning to avoid false positives that flood logs. ## Common exam / real-world mistakes 1. **Enabling every profile at once.** Users complain, everyone panics, profiles get switched off wholesale. Roll out one at a time in monitor mode first. 2. **Forgetting SSL inspection is required for real coverage.** Without it, the antivirus profile is inspecting maybe 20% of your web traffic. 3. **Mixing profile modes.** Flow-based AV can't do everything proxy-based can (like MIME identification). If you need it, use proxy mode. 4. **Not distributing the FortiGate CA cert** before enabling deep SSL inspection — every user gets cert warnings, help desk floods. 5. **Ignoring FortiGuard licenses.** Web filter / IPS / AV signatures need active licenses. Without them, the engines still run, but the signatures are stale or missing. ## Cheat strip ``` Order in flow: SSL → DNS → Web → App → AV → IPS → DLP AV modes: flow (fast) | proxy (thorough) Web filter: category-based, action per category App control: signature-based, port-independent IPS modes: detection-only | prevention SSL inspect: certificate (SNI) | deep (MITM) needs endpoint CA cert deployed DNS filter: cheap early block, catches phishing DLP: pattern-based outbound leak prevention ``` --- ## FortiGate SD-WAN with Performance SLA — https://packetmentor.com/topics/fortigate-sd-wan-with-sla/ > How Fortinet SD-WAN routes traffic across multiple WAN links based on real-time SLA measurement (latency, jitter, packet loss). Performance SLA config, SD-WAN rules, and how failover actually works. ## The one-sentence mental model **SD-WAN on a FortiGate turns "which WAN link do I send this out?" from a routing decision into an application-aware, SLA-aware policy decision.** Instead of your MPLS being preferred until it's dead, it's preferred until it stops meeting the SLA — which might be *before* it's dead. ## The three pieces ### 1. SD-WAN zone + members You group physical WAN interfaces into one logical SD-WAN zone: ``` config system sdwan set status enable config zone edit "virtual-wan" next end config members edit 1 set interface "wan1" # MPLS set gateway 203.0.113.1 set zone "virtual-wan" next edit 2 set interface "wan2" # Broadband set gateway 198.51.100.1 set zone "virtual-wan" next edit 3 set interface "wan3" # LTE set gateway 192.0.2.1 set zone "virtual-wan" next end end ``` Firewall policies now use "virtual-wan" as the outgoing interface — you never pick wan1/wan2/wan3 directly. ### 2. Performance SLA (health check) The SLA object continuously probes each member and measures **latency**, **jitter**, and **packet loss**: ``` config system sdwan config health-check edit "google-dns" set server "8.8.8.8" set protocol ping # or http/twamp/dns set members 1 2 3 set interval 500 # 500 ms probes set failtime 5 # 5 missed = down set recoverytime 10 config sla edit 1 set latency-threshold 100 set jitter-threshold 20 set packetloss-threshold 5 next end next end end ``` Result: each member is tagged **"meeting SLA"** or **"failing SLA"** at any moment, live. ### 3. SD-WAN rules Rules bind traffic (source/dest/service/app) to an SLA-aware preference: ``` config system sdwan config service edit 1 set name "voip-over-best-latency" set mode sla set health-check "google-dns" set sla 1 set src "all" set dst "voip-network" set service "SIP" set priority-members 1 2 3 # try wan1, then wan2, then wan3 next edit 2 set name "backup-traffic-on-cheapest" set mode manual set src "backup-servers" set dst "cloud-backup" set priority-members 2 # broadband only next end end ``` Rules are **top-down first-match** — same as firewall policies. ## How failover actually works The classic failover mistake is thinking SD-WAN failover = link-down failover. It's not. - Every 500 ms (or whatever probe interval), the SLA object retests each member. - If wan1's latency climbs above 100 ms, the SLA object marks it *failing SLA* — even though the link is up. - Any SD-WAN rule with `mode sla` immediately excludes wan1 from its member list. - The traffic moves to the next preferred member that is meeting SLA. - When wan1 recovers (holds SLA for `recoverytime` probes), it's re-added to the pool. This is why SD-WAN beats classic dual-WAN with floating statics: it reacts to **quality degradation**, not just **link failure**. ## Modes on the SD-WAN rule | Mode | Behavior | |---|---| | **manual** | Send to a specific member. No failover unless that member is dead. | | **best-quality** | Compare SLA metrics across members, pick the best right now. | | **lowest-cost (SLA)** | Prefer cheapest member that is still meeting SLA. Only leave cheap when it fails SLA. | | **maximize-bandwidth (load-balance)** | Load-balance across members meeting SLA. | | **priority** | Ordered member list — first meeting SLA wins. | **Lowest-cost (SLA)** is the mode you'll see most in production — "prefer broadband while it's good, fall back to MPLS only when broadband degrades." ## Combining with routing SD-WAN sits on top of the routing table. You still need routes (static defaults, BGP peers, OSPF neighbors) to know how to reach the far end via each member. SD-WAN just *picks the member* out of the equal-cost paths. For hub-and-spoke SD-WAN VPNs, an IPsec tunnel per member is standard: `wan1 ↔ hub-tunnel1`, `wan2 ↔ hub-tunnel2`. Both tunnels are equal-cost. SD-WAN rules pick the better one per flow. ## Common exam / real-world mistakes 1. **Forgetting the health-check server can itself be down.** Probing 8.8.8.8 works — until Google has a bad day. Better: probe an FQDN you control, or use twamp with a FortiGate at the hub as responder. 2. **Setting SLA thresholds too tight.** 100 ms latency threshold on a satellite backup will constantly mark it failing. Match thresholds to the app: 150 ms for voice, 300 ms for file transfer. 3. **Not using zones in firewall policies.** If a policy still references `wan1` directly, SD-WAN can't redirect it. Every outbound policy needs to use the SD-WAN zone as outgoing interface. 4. **Ignoring per-app awareness.** Modes like `best-quality` are per-flow, but you can also key rules on application signatures (e.g., "all Office 365 → best-quality"). This is the modern approach. 5. **Missing that manual mode doesn't do SLA failover.** If you set `mode manual` and the manual member fails SLA, traffic keeps hitting it. Only `mode sla` and `mode priority` react to SLA. ## Cheat strip ``` Zone group of WAN members (used as outgoing interface in policies) Members physical WANs with gateway + zone binding SLA health-check → latency + jitter + loss thresholds Rules top-down first-match. mode = sla | best-quality | manual | ... Failover triggered by SLA breach, not just link down Recovery member holds SLA for recoverytime probes → re-added Common mode: lowest-cost (SLA) — cheap link until it degrades Voice mode: best-quality — always pick the best latency/jitter Backup mode: manual — pin heavy traffic to a specific link ``` --- ## FortiGate IPsec VPN — Site-to-Site and Dial-Up — https://packetmentor.com/topics/fortigate-ipsec-vpn/ > How IPsec VPNs work on FortiOS: Phase 1 IKE, Phase 2 SA, site-to-site, dial-up, route-based vs policy-based, and the diagnostics that solve 90% of tunnel-down tickets. ## The one-sentence mental model **Phase 1 builds a locked room for the negotiators to talk in. Phase 2 builds the encrypted pipes traffic actually flows through.** Both are just Security Associations (SAs) — Phase 1 SA is for the control plane, Phase 2 SAs are for the data plane. If Phase 1 doesn't come up, nothing works; if Phase 2 doesn't come up, Phase 1 is fine but no traffic flows. ## The negotiation flow ``` Phase 1 (IKE / IKEv2) Proposals: encryption + hash + DH group + lifetime Authentication: PSK or X.509 certificate Peer identity: IP address / FQDN / user-fqdn ↓ (success) Phase 2 (IPsec) Proposals: encryption + hash + PFS DH group + lifetime Selectors: local subnet + remote subnet ↓ (success) Tunnel is up. Traffic that matches the selectors gets encrypted. ``` ## Route-based vs policy-based **Route-based** (FortiOS default): - Creates a virtual interface (e.g., `to-hq-tunnel`) that behaves like a Layer 3 interface. - You add a **static route** for the remote subnet pointing to the virtual interface. - You write a **firewall policy** allowing traffic between local LAN and the virtual interface. - Works with dynamic routing (BGP, OSPF), SD-WAN member selection, SLA-aware failover. **Policy-based** (legacy): - The firewall policy itself specifies "action: IPSEC" and picks the tunnel. - No routing table involvement. - No dynamic routing, no SD-WAN. Every real deployment today uses route-based. ## Site-to-site config sketch (route-based) **Phase 1**: ``` config vpn ipsec phase1-interface edit "hq-tunnel" set interface "wan1" set peertype any set net-device disable set proposal aes256-sha256 set dhgrp 14 set remote-gw 198.51.100.10 set psksecret "SharedSecret123" next end ``` **Phase 2**: ``` config vpn ipsec phase2-interface edit "hq-tunnel-p2" set phase1name "hq-tunnel" set proposal aes256-sha256 set dhgrp 14 set src-subnet 10.0.0.0/24 set dst-subnet 10.1.0.0/24 next end ``` **Route + firewall policy**: ``` config router static edit 10 set dst 10.1.0.0/24 set device "hq-tunnel" next end ``` Then a firewall policy: `internal → hq-tunnel`, source LAN, destination remote LAN, action ACCEPT. ## Dial-up VPN Used when the peer has a dynamic public IP (or is behind CGN NAT). FortiGate accepts inbound Phase 1 from any peer that presents a matching identity + PSK/cert: - `set remote-gw 0.0.0.0` - `set type dynamic` - `set peertype one|any|dialup` - Peer authenticates by FQDN or user-FQDN identity, not by IP. Common use: remote branch FortiGates behind ISP CGN, road-warrior FortiClients. ## NAT-Traversal If either peer sits behind NAT, IPsec ESP breaks (NAT rewrites the source IP → ESP integrity check fails). NAT-T detects this and encapsulates ESP inside UDP 4500: - IKE starts on UDP 500. - Peers exchange NAT-D payloads. If NAT detected, both switch to UDP 4500. - ESP is then wrapped in UDP 4500 for the data plane too. Firewall you're going through must permit UDP 500 + UDP 4500 outbound (and inbound if you're the concentrator). ## Diagnostics The five commands that solve 90% of IPsec tickets: ``` diagnose vpn ike gateway list # phase 1 state diagnose vpn tunnel list # phase 2 SAs, byte counters diagnose debug application ike -1 diagnose debug enable # live IKE negotiation trace diagnose debug reset ``` Common messages: - `no matching gateway found for negotiation` → wrong peer identity or proposal - `PSK auth failed` → PSK mismatch - `no proposal chosen` → Phase 1 or Phase 2 encryption/hash/DH mismatch - `NO-PROPOSAL-CHOSEN` in the responder side → check selectors on Phase 2 ## Common exam / real-world mistakes 1. **Mismatched proposals.** Both sides must list at least one identical (encryption, hash, DH group). Simplest is to standardize on aes256-sha256 + DH 14. 2. **Wrong Phase 2 selectors.** If your local Phase 2 says 10.0.0.0/24 but the remote side says 10.0.0.0/16, they don't match. Both sides' selectors must be identical. 3. **Forgetting the return-path firewall policy.** You wrote LAN → tunnel; you also need tunnel → LAN if traffic starts from the remote side. 4. **NAT-T disabled with NAT in path.** Symptom: Phase 1 succeeds but Phase 2 traffic never flows. Enable NAT-T on both sides. 5. **Using policy-based when you need SD-WAN.** SD-WAN only picks members for route-based tunnels. If you're on policy-based, switch. 6. **Not accounting for PFS.** Enabling Perfect Forward Secrecy on one side but not the other = no proposal chosen. Match both sides' PFS DH group. ## Cheat strip ``` Phases P1 = IKE (control channel) P2 = IPsec SA (data channel) Modes route-based (default) → virtual interface + static route policy-based (legacy) → action: IPSEC in firewall policy Auth PSK | X.509 cert Peer ID IP | FQDN | user-FQDN Dial-up remote-gw 0.0.0.0 + type dynamic NAT-T auto-detect. UDP 500 → 4500 if NAT in path. Firewall permit UDP 500 + UDP 4500. Debug diagnose vpn ike gateway list diagnose vpn tunnel list diagnose debug application ike -1 + diagnose debug enable ``` --- ## FortiGate SSL VPN — Web Mode and Tunnel Mode — https://packetmentor.com/topics/fortigate-ssl-vpn/ > How FortiOS SSL VPN works for remote users: web-mode portal, full-tunnel-mode client (FortiClient), authentication with LDAP/RADIUS/SAML, and the split-tunnel decision every design faces. ## The one-sentence mental model **SSL VPN turns TLS into a VPN transport.** No IPsec, no UDP 500/4500, no NAT-T headaches. Runs on TCP 443 — the same port everything already lets out. That's why it's the road-warrior standard for corporate remote access. ## Two modes, different use cases ### Web mode (clientless) - User points a browser at `https://vpn.company.com`. - Authenticates → sees a portal page. - Portal shows bookmarks: RDP, VNC, HTTP internal sites, SSH. - FortiGate proxies each session — user never gets a real IP on the corporate LAN. **Pros**: no client to install. Works from unmanaged devices (kiosk, contractor laptop). Fast to grant granular access. **Cons**: only apps FortiGate can proxy. No thick-client (SAP, custom apps). Latency higher than tunnel mode. ### Tunnel mode (full VPN client) - User launches **FortiClient** (or the free FortiClient VPN-only build). - Client authenticates, establishes TLS tunnel, receives an IP from the SSL-VPN pool. - Traffic destined for corporate subnets (or all traffic, depending on split-tunnel config) is encapsulated over TLS. **Pros**: full Layer 3 — anything IP-based works. Same experience as being on the LAN. **Cons**: needs a client. IT owns the client lifecycle. ## Design decision: split tunnel vs full tunnel **Full tunnel**: every packet the user's device sends goes through the FortiGate. - Wins: full DPI on user traffic. DLP works. Web filtering enforces the corporate policy at home. - Loses: doubles WAN traffic (user traffic + return). Streaming/Zoom quality drops. **Split tunnel**: only traffic to corporate subnets goes over the VPN. - Wins: user's Netflix / Zoom / general internet goes direct. Great UX. - Loses: security team has no visibility on that traffic. If the user's home network is compromised, the endpoint is exposed. **Current best practice** (2026): **inverse split tunnel** — full tunnel by default but exempt a small list of trusted high-bandwidth destinations (Microsoft 365, Zoom, WebEx). Best of both. ## Configuring SSL VPN (tunnel mode) **Portal**: ``` config vpn ssl web portal edit "full-access" set tunnel-mode enable set web-mode disable set ip-pools "SSLVPN-Pool" set split-tunneling disable # or "enable" for split next end ``` **Settings**: ``` config vpn ssl settings set servercert "Fortinet_CA_SSL" set port 443 set source-interface "wan1" set tunnel-ip-pools "SSLVPN-Pool" set dns-server1 10.0.0.53 config authentication-rule edit 1 set groups "SSLVPN-Users" set portal "full-access" next end end ``` **Firewall policy** — from the SSL VPN interface (`ssl.root`) into the LAN: ``` config firewall policy edit 90 set srcintf "ssl.root" set dstintf "internal" set srcaddr "SSLVPN-Pool-Range" set dstaddr "corporate-lan" set service "ALL" set action accept set schedule always set groups "SSLVPN-Users" next end ``` Notice `groups` on the policy — this is FortiOS enforcing group-based access post-authentication. ## Authentication options - **Local users** — quickest, doesn't scale. - **LDAP** — Active Directory. Most common. Group filter tells FortiGate which AD group can VPN. - **RADIUS** — often used to chain into 2FA (FortiToken, Duo, Okta). - **SAML** — modern SSO. FortiGate is the Service Provider; Azure AD / Okta / Ping is the IdP. Enables MFA / conditional access at the IdP. **Multi-factor** is not optional for real deployments. Two paths: FortiToken (Fortinet's own OTP) or an external MFA (Duo Push, Microsoft Authenticator via RADIUS or SAML). ## Host checking FortiOS can require the FortiClient endpoint to pass posture checks before completing the tunnel: - OS version - Antivirus running + up to date - Disk encryption enabled - Domain-joined Fail = deny (or grant limited "remediation" access). ## Diagnostics ``` diagnose vpn ssl statistics # tunnels up, users connected diagnose vpn ssl list # list of active sessions execute vpn sslvpn del-tunnel # kick a specific user ``` FortiClient side: check the client's VPN log for TLS handshake errors, cert warnings, DNS resolution issues. ## Common exam / real-world mistakes 1. **Wrong server certificate.** The default `Fortinet_CA_SSL` cert triggers browser warnings. Use a public cert (Let's Encrypt, DigiCert) for the SSL VPN interface. 2. **Missing DNS server config in the portal.** Users connect but can't resolve `intranet.company.local` because the tunnel doesn't push a DNS server. 3. **Forgetting group-based policy enforcement.** Everyone in AD becomes a VPN user. Restrict via `groups` on both the auth rule and the firewall policy. 4. **Blindly enabling split tunnel.** Answers UX complaints but blinds the security team. If you split-tunnel, at minimum push a DNS security service (Umbrella / FortiGuard DNS) client-side. 5. **Not testing MFA fallback.** If SAML IdP is down, VPN is down. Have a break-glass local-account path (audited). ## Cheat strip ``` Web mode clientless portal on HTTPS. FortiGate proxies apps. Bookmarks: RDP / VNC / HTTP / SSH. Tunnel mode FortiClient builds L3 tunnel. Full IP. Port TCP 443 (default). Configurable. Split corporate subnets only over VPN. Better UX, less visibility. Full everything over VPN. Full inspection, more bandwidth. Inverse full tunnel except allow-listed SaaS. Current best practice. Auth Local | LDAP | RADIUS | SAML (+ MFA) Posture OS ver | AV state | disk crypto | domain join Debug diagnose vpn ssl statistics diagnose vpn ssl list ``` --- ## FortiGate HA — FGCP Active-Passive and Active-Active — https://packetmentor.com/topics/fortigate-ha-fgcp/ > How FortiGate Clustering Protocol (FGCP) forms a redundant pair or cluster: heartbeat, session sync, election, active-passive vs active-active, override, split-brain avoidance. ## The one-sentence mental model **FGCP makes two (up to four) identical FortiGates behave as one virtual firewall.** They share the same MAC on user-facing interfaces, elect one as primary, and mirror configuration + session state so a failure is invisible to the traffic that was already flowing. ## Requirements - **Same model.** 100F pairs with 100F. No mixing. - **Same firmware.** Both boxes on the same FortiOS build. - **Same license.** FortiGuard subscriptions must align. - **Dedicated heartbeat links.** At least one; two recommended. - **Same interface types + counts.** Ports must match physically. ## Heartbeat FGCP uses a proprietary Layer-2 protocol (ethertype 0x8890, 0x8891, 0x8893) on dedicated heartbeat interfaces: - Interval: 200 ms default. Miss 6 → member declared dead. - Recommended: 2 heartbeat interfaces on different physical NICs, cross-connected between members. - Never share a heartbeat interface with data traffic. ## The election When members boot, they compare (in order): 1. **Override enable + higher priority** — if override is on, the higher-priority unit wins even if the other was primary first. 2. **Number of monitored interfaces up** — a member missing an interface can't be primary. 3. **HA uptime** — longer up wins (stability). 4. **Priority** — higher wins (default 128). 5. **Serial number** — higher wins (final tie-breaker). Watch out: **without override**, whoever booted first stays primary — even after the "preferred" unit comes back. Turn **override on** if you want a specific unit to always be primary when healthy. ## Active-Passive Traffic flows only through the primary. Secondary syncs config + sessions and stands by. Config sketch: ``` config system ha set group-name "hq-cluster" set mode a-p set password SharedSecret set hbdev "ha1" 50 "ha2" 40 set session-pickup enable set override enable set priority 200 # this box preferred end ``` **Session pickup** — must be enabled or existing sessions drop on failover. **Override + priority** — makes the box with priority 200 always the primary after a failure. ## Active-Active All members forward. The primary receives all inbound frames on the shared MAC, then distributes new sessions to secondaries by hash. Return traffic comes back through the same member (via session table). Modes: - **Hash-based (default)** — src-ip-dst-ip or src-ip only. New sessions distributed. - **UTM offload** — primary hands off IPS / AV inspection to a secondary. Rarely tuned to; A-A is mostly historical. Cons: harder troubleshooting (which member is inspecting this flow?), config drift risk during maintenance windows. ## HA MAC and the "virtual" cluster On user-facing interfaces, all members share the **same virtual MAC** (derived from the group-id). Upstream switch sees one MAC. Failover doesn't require ARP flush — the new primary just starts answering. Downside: if two clusters accidentally share the same group-id on the same L2, both use the same MACs → chaos. Change group-id if you have multiple clusters on shared VLANs. ## Split-brain avoidance **Split-brain** = both members think they're primary. Happens when all heartbeat links die but data links stay up. Both start responding to the shared MAC → duplicate frames, session sync stops, traffic breaks. Mitigations: - **Multiple heartbeat interfaces.** Always. On different NICs. - **HA reserved management interface.** Even if data + HB die, you have a separate path to reach one box. - **Monitor interfaces** so a member with dead uplinks demotes itself before winning the election. ## Verification ``` get system ha status # who's primary, sync state, HB diagnose sys ha status # detailed member info diagnose sys ha checksum show # config checksums must match diagnose sys ha reset-uptime # force re-election (careful) execute ha manage 1 # SSH into the secondary ``` `checksum show` is the single most useful command: if the config checksum doesn't match across members, config sync is broken. Common cause: someone changed config on the secondary directly (only ever change on primary). ## Common exam / real-world mistakes 1. **Sharing HB with data traffic.** Ethertypes collide, HB gets dropped under load, split brain follows. Always dedicate. 2. **Forgetting session-pickup.** Failover works but every existing TCP session drops. Users see hangs / reconnects. Turn it on unless you have a specific reason not to. 3. **Skipping override.** You expected the "primary" unit to always be primary. Without override, whoever booted first stays. 4. **Changing config on the secondary.** Config sync only flows primary → secondary. Direct edits on the secondary are silently overwritten (or worse, cause checksum mismatch until fixed). 5. **Ignoring monitor interfaces.** If the box's WAN uplink dies but no interfaces are monitored, HA doesn't fail over — traffic just black-holes. ## Cheat strip ``` Mode A-P (default, simple) | A-A (hash distribution, rare) Members 2–4 identical FortiGates Heartbeat dedicated links, 200 ms × 6 = 1.2 s detection Election override+prio → monitor state → HA uptime → priority → SN Session sync session-pickup enable (or existing flows drop) Override priority (higher wins after recovery) Monitor interfaces failing = demote self HB reserved separate mgmt interface for split-brain recovery Verify get system ha status diagnose sys ha checksum show (config drift) execute ha manage (SSH secondary) ``` --- ## FortiGate FSSO — Fortinet Single Sign-On — https://packetmentor.com/topics/fortigate-fsso/ > How FSSO gives FortiGate identity-aware policies without prompting users: collector agents on the AD DC, event-log monitoring, transparent login mapping, and RADIUS-SSO variants. ## The one-sentence mental model **FSSO answers "who is this IP right now?" so the FortiGate can enforce firewall + web-filter policies by AD group instead of just by IP subnet.** Without FSSO, the FortiGate sees `10.10.5.42`. With FSSO, it sees `10.10.5.42 = jsmith@corp = Sales`. ## The four FSSO modes ### 1. Collector Agent + DC Agent (the classic setup) - **DC Agent** — DLL installed on each Domain Controller. Hooks into the DC's authentication process directly. - **Collector Agent** — service (usually on the DC or a dedicated server). Receives login events from DC Agents, resolves usernames + IPs + AD groups, sends to FortiGate. Pros: real-time. Every AD login gets picked up instantly. Cons: DLL install on every DC. Change management pushback. ### 2. Collector Agent only (no DC Agent — "polling mode") - Just the Collector Agent, no DLLs. - Collector *polls* the DC event log (WinRM/WMI) at intervals for logon events. Pros: no DLL on the DC. Simpler to deploy. Cons: slight lag (poll interval, typically 60 s). Under heavy login rates, can miss events. ### 3. Agentless (FortiGate polls directly) - No agent anywhere. FortiGate itself polls the DC event log via WMI/WinRM. Pros: nothing to install. Cons: FortiGate must reach the DC directly, credentials for WMI, higher CPU on the FortiGate for large environments. ### 4. RADIUS-SSO - No AD-based collector at all. - Some upstream device (Cisco WLC, VPN concentrator, NAC) sends **RADIUS accounting** records to the FortiGate as users log in. - FortiGate parses the accounting, extracts username + IP, applies to policy. Pros: works even in non-AD environments. Ideal for wireless / NAC-driven identity. Cons: only sees traffic from devices that send RADIUS accounting. ## FortiAuthenticator as a bigger brain For multi-site or when you want more control: - **FortiAuthenticator** (physical or VM appliance) becomes the central FSSO collector. - Receives login events from DCs, LDAP servers, RADIUS accounting, portal captive-portal logins. - Pushes consolidated user→IP→group mappings to every FortiGate in the estate. - Also does 2FA (FortiToken push, TOTP), guest self-registration, MAC bypass. Standard architecture for MSPs and enterprises with >10 FortiGates. ## Config sketch (Collector Agent mode) **On FortiGate**: ``` config user fsso edit "hq-collector" set server 10.0.0.20 set password AgentSecret set collector-agent-type default next end config user group edit "AD-Sales" set group-type fsso-service set member "hq-collector" config match edit 1 set server-name "hq-collector" set group-name "CN=Sales,OU=Groups,DC=corp,DC=local" next end next end ``` **Then in firewall policy**: ``` config firewall policy edit 40 set srcintf "internal" set dstintf "wan1" set srcaddr "all" set dstaddr "all" set groups "AD-Sales" # only Sales users match set action accept set service "HTTP" "HTTPS" set webfilter-profile "sales-webfilter" next end ``` ## Verification ``` diagnose debug authd fsso list # current mappings diagnose debug authd fsso server-status # collector reachable? diagnose debug authd fsso refresh-logons ``` Look for entries like `10.10.5.42 jsmith groups=Sales,Everyone`. If empty → collector not reaching FortiGate. If stale → collector service died on DC. ## Common exam / real-world mistakes 1. **Firewall between DCs and Collector.** Collector receives DC agent events on TCP 8000 by default. Collector talks to FortiGate on TCP 8000 too. If a firewall blocks it, no mappings. 2. **Sharing user names across sessions.** RDP / Citrix XenApp sessions look like one IP with many users. FSSO can only report one user per IP → wrong user for policy. Fix: XenApp connector / dedicated group of TS servers with "any user" policy. 3. **Group DN casing / typos.** AD group DN in the FortiGate must match exactly. Copy-paste from Active Directory Users and Computers. Off-by-one and it silently doesn't match. 4. **DHCP lease change while logged in.** User gets new IP mid-session. FSSO mapping shows old IP. Cure: shorten DHCP leases OR use collector that watches for logoff events. 5. **Not pruning stale sessions.** If a user powers off without logging out, mapping lingers. Configure "session lifetime" on the collector. ## Cheat strip ``` Goal map "IP → AD user + groups" → identity in firewall policy Modes: Collector + DC Agent real-time, DLL on every DC Collector-only polling no DLL, minor lag Agentless no agent, FortiGate polls DC directly RADIUS-SSO consumes RADIUS accounting Ports DC-agent → Collector : TCP 8000 default Collector → FortiGate : TCP 8000 default Verify diagnose debug authd fsso list diagnose debug authd fsso server-status FortiAuth central collector + 2FA + guest portal at scale ``` --- ## VXLAN Basics — VNI, VTEP, and Why Modern DCs Use It — https://packetmentor.com/topics/vxlan-basics/ > The Layer-2-over-Layer-3 overlay every modern data center runs. VXLAN encapsulation, VNI, VTEP roles, unicast vs multicast flood-and-learn vs BGP EVPN — the CCNP ENCOR essentials. ## The one-sentence mental model **VXLAN takes an Ethernet frame, wraps it in a UDP-in-IP packet with a 24-bit "tenant ID" (VNI), and ships it across a routed underlay to a peer switch, which unwraps it back to Ethernet.** From the host's point of view, two servers on the same VNI are on the same LAN. From the network's point of view, they're just IP packets riding on a routed fabric. ## Why we needed it Classic Layer-2 data centers had three problems: 1. **STP blocks half your links.** In a Clos / spine-leaf topology with multiple uplinks, STP puts most of them in blocking state. Wasted capacity. 2. **VLANs cap at 4094.** With hundreds of tenants, containers, and micro-services, 12 bits of VLAN ID runs out. 3. **Layer 2 doesn't scale past a couple of racks** without loops or huge broadcast domains. VXLAN solves all three by running Layer 2 as a tunnel over a routed IP network. STP still exists locally at each leaf, but between leaves it's all Layer 3 — ECMP takes over, every link is active, and the "tenant space" jumps from 4K VLANs to 16M VNIs. ## The encapsulation Original Ethernet frame → gets wrapped in: ``` Outer Ethernet | Outer IP | Outer UDP (dst 4789) | VXLAN header (VNI) | Original inner Ethernet frame | Outer CRC ``` Key fields: - **Outer UDP destination port** = 4789 (IANA-assigned). - **VXLAN header** = 8 bytes, including the 24-bit VNI. - **Outer source/dest IP** = the VTEP addresses. The added overhead is ~50 bytes — plan MTU accordingly (jumbo frames highly recommended: MTU 9000 in the underlay, 1500 in the overlay). ## The two roles ### VTEP — VXLAN Tunnel Endpoint The switch (or hypervisor vSwitch) that does the encap/decap. Every leaf in a spine-leaf fabric is a VTEP. A VTEP has a **loopback IP** used as the tunnel source/destination. ### Spine Doesn't do VXLAN encap. Just routes IP packets between leaves. Spines don't even need to know VXLAN exists — they just carry underlay traffic. ## Two learning modes ### Flood-and-learn (classic, multicast-based) - BUMs (Broadcast / Unknown-unicast / Multicast) flood to a multicast group per VNI in the underlay. - Every VTEP joins the multicast group for VNIs it has interest in. - MAC addresses learned via observing traffic in the overlay. - Requires multicast in the underlay. Doesn't scale beautifully. ### BGP EVPN (modern control plane) - MP-BGP with the EVPN address family exchanges MAC → VTEP mappings **explicitly**. - No multicast in the underlay required (use ingress replication or MP-BGP-signaled multicast). - Fast, deterministic, and pairs naturally with VRFs for multi-tenant. - The Cisco default in modern DC platforms (Nexus 9K running NX-OS, Catalyst 9500 in fabric mode). CCNP ENCOR expects you to know both exist and why EVPN is preferred in new builds. ## Sample verification (Nexus / Cat 9K in EVPN mode) ``` show nve peers ← which VTEPs am I talking to show nve vni ← which VNIs are up locally show l2route evpn mac vni 10001 ← MAC table for a specific VNI show bgp l2vpn evpn summary ← BGP EVPN neighbor state ``` ## Common exam / real-world mistakes 1. **Confusing VLAN with VNI.** VLANs are still used *locally* on each leaf to bind physical ports into a bridge domain. That local VLAN maps to a global VNI. VNI is not "the new VLAN" — it's the *fabric-wide* identifier. 2. **Underlay MTU too small.** VXLAN adds ~50 bytes. If the underlay MTU is 1500 and you send a 1500-byte inner frame, the outer packet is 1550 → fragments or drops. 3. **Ignoring the VTEP loopback design.** VTEP source IP is a loopback advertised in the underlay routing protocol. If OSPF/IS-IS doesn't advertise it correctly, EVPN peerings never come up. 4. **Assuming multicast is required.** Only for flood-and-learn. Ingress replication (head-end replication) is a common alternative when the underlay doesn't have multicast. 5. **Forgetting anycast gateway.** In EVPN, every leaf shares the *same* gateway IP and MAC for a given VNI — hosts always talk to their local leaf. If you don't configure anycast gateway, all inter-VNI traffic hairpins through one leaf. ## Cheat strip ``` Underlay routed IP fabric (OSPF or IS-IS). ECMP everywhere. Overlay VXLAN tunnels between VTEPs (leaves). VNI 24-bit fabric-wide tenant ID. 16M values. VTEP the leaf that encaps/decaps. Source = loopback. UDP dst 4789 (VXLAN). Overhead ~50 bytes. Jumbo underlay MTU (9000). Learn flood-and-learn (multicast) | BGP EVPN (modern, preferred) Anycast GW same VIP/MAC on every leaf → hosts talk to local leaf Verify (NX) show nve peers | show nve vni | show bgp l2vpn evpn summary ``` --- ## BGP Best-Path Selection — The Full 13-Step Order — https://packetmentor.com/topics/bgp-path-selection/ > The complete BGP path-selection algorithm CCNP ENCOR expects you to recite. Every step in order, with the tie-breaker mnemonic and a worked example for the top three most-common decision points. ## Why this order matters BGP is a policy-based routing protocol — the "best path" is whatever the operator says it is. Cisco's implementation walks a fixed decision tree of attributes so that the operator can predict, exactly, which path a change will select. If you can't recite the order, you can't design predictable inbound/outbound policy. ## The full 13-step order Cisco IOS / IOS-XE / NX-OS BGP compares two paths in this order. Whichever step first produces a clear winner ends the comparison. | # | Step | Prefer | |---|---|---| | 0 | Next-hop reachable? | Drop paths whose next-hop is unreachable in the IGP. | | 1 | Weight | **Higher** wins. Cisco-proprietary, local to this router only. | | 2 | Local Preference | **Higher** wins. Advertised to iBGP neighbors, AS-wide. | | 3 | Locally originated? | Prefer routes originated on this router (network / redistribute / aggregate). | | 4 | AS_PATH length | **Shorter** wins. Prepending increases it. | | 5 | Origin | i (IGP) > e (EGP) > ? (incomplete). | | 6 | MED | **Lower** wins. Only compared if AS_PATH prefix is the same neighbor AS. | | 7 | eBGP over iBGP | Prefer paths learned via eBGP. | | 8 | IGP metric to next-hop | **Lower** wins. | | 9 | Multi-path? | If maximum-paths configured & candidates are equal to here, install multiple. | | 10 | Oldest eBGP route | Prefer the path that was learned first (stability). | | 11 | Router-ID | **Lower** wins. | | 12 | Neighbor address | **Lower** wins. Final tie-breaker. | ## The mnemonic Most textbooks use variants of: > **N W L L A O M E I O R N** > > *Next-hop · Weight · Local pref · Locally originated · AS-path · Origin · MED · eBGP > iBGP · IGP metric · Oldest · Router-ID · Neighbor* Or a shorter version most engineers actually remember for the top 4: > **W L A M** — Weight, Local pref, AS-path, MED. If you can order those four and remember eBGP > iBGP sits between them and the tie-breakers, the rest falls into place. ## The three attributes you'll see 80% of the time ### 1. Weight (higher wins) Cisco-only. Set per-router with a route-map inbound. Not advertised anywhere. Use it when you want *this* router to prefer a path without affecting the rest of the AS. ``` route-map PREFER-ISP1 permit 10 set weight 200 ! router bgp 65001 neighbor 203.0.113.1 route-map PREFER-ISP1 in ``` ### 2. Local Preference (higher wins) Advertised to iBGP neighbors, so the whole AS agrees on the exit. Use for **outbound** policy — "the whole company should exit via ISP1 unless ISP1 is down." ``` route-map OUT-VIA-ISP1 permit 10 set local-preference 300 ! router bgp 65001 neighbor 203.0.113.1 route-map OUT-VIA-ISP1 in ``` ### 3. AS_PATH prepending (longer loses) Add your AS number multiple times to make a path *look* worse to neighbors, so they prefer someone else. Use for **inbound** policy — "please, ISP2, don't send me traffic on this prefix." ``` route-map PREPEND-OUT permit 10 set as-path prepend 65001 65001 65001 ! router bgp 65001 neighbor 203.0.113.2 route-map PREPEND-OUT out ``` ## Worked example R1 has three eBGP paths to 10.0.0.0/24: | Path | Weight | Local pref | AS-path | MED | |---|---|---|---|---| | via ISP-A | 0 | 200 | 65100 65200 | 100 | | via ISP-B | 0 | 200 | 65300 | 100 | | via ISP-C | 100 | 100 | 65400 | 50 | Walk the algorithm: 1. **Weight** — ISP-C wins (100 vs 0). Comparison ends. **Winner: ISP-C**. If Weight had been equal, we'd have compared Local Pref (ISP-A and ISP-B tie at 200 > ISP-C at 100 → ISP-C drops). Then AS-path: ISP-B (length 1) beats ISP-A (length 2). Winner would have been ISP-B. Understand: weight is checked FIRST, so a locally-set weight overrides an AS-wide local-preference decision. This is often surprising. ## Common exam / real-world mistakes 1. **Confusing weight and local-preference direction.** Weight = local (never leaves the router). Local pref = AS-wide (advertised iBGP). MED = "hint to neighbor AS" (advertised eBGP outbound but not further). 2. **Setting MED when AS_PATH varies.** MED is only compared if the prefix is coming from the same neighbor AS. Otherwise BGP skips step 6. 3. **Assuming lower LP wins.** Higher LP wins. Trap for exam-day nerves. 4. **Forgetting the next-hop reachability check.** If the next-hop advertised in BGP isn't in your IGP, the route is invalid regardless of any attribute. Common iBGP mistake with route-reflectors. 5. **Never using `bgp bestpath as-path multipath-relax`** when you want ECMP over eBGP paths from different upstream ASes. ## Cheat strip ``` Order N W L L A O M E I O R N Next-hop reach → Weight (hi) → Local pref (hi) → Locally originated → AS-path (short) → Origin (i > e > ?) → MED (lo, same-AS only) → eBGP > iBGP → IGP metric (lo) → Oldest eBGP → Router-ID (lo) → Neighbor (lo) Top 3: Weight (local, hi wins) Local pref (AS-wide, hi wins) AS-path length (short wins) Verify: show bgp ipv4 unicast | show ip bgp show ip bgp neighbors advertised-routes ``` --- ## QoS Marking & Queuing — DSCP, Trust Boundaries, LLQ, CBWFQ — https://packetmentor.com/topics/qos-marking-queuing/ > The CCNP ENCOR QoS chapter, distilled: classification, marking with DSCP, trust boundaries, and queuing with LLQ and CBWFQ. Where to mark, where to trust, and how the router services the queues. ## The one-sentence mental model **QoS is what a router does when the outbound interface is congested.** If the pipe isn't full, QoS doesn't do anything you'd notice. Once it fills, QoS decides: which packets keep going (voice, video), which get held (bulk file transfer), which get dropped (scavenger). ## The four QoS steps ### 1. Classify Identify what kind of traffic a packet is. Techniques: - Match a Layer-2 CoS bit (802.1p priority in a trunk frame) - Match an ACL - Match a DSCP already set by an upstream device you trust - Match NBAR2 deep-packet inspection results Cisco best practice: on access switches, classify once at ingress and mark. Everywhere downstream just trusts the mark. ### 2. Mark Write a value into the packet so every downstream hop can classify quickly (a single header lookup instead of an ACL re-match). - **CoS** (802.1p): 3 bits in a trunk frame's 802.1Q tag. Values 0–7. - **DSCP** (RFC 2474): 6 bits in the IP DiffServ / ToS byte. Values 0–63. - **IP Precedence** (legacy): 3 bits, values 0–7. Superseded by DSCP but still shown by `show`. DSCP values you'll see in every design guide: | DSCP | Name | Typical use | |---|---|---| | 46 | EF (Expedited Forwarding) | Voice bearer. Absolute priority. | | 34 | AF41 | Interactive video. | | 32 | CS4 | Video streaming (live). | | 26 | AF31 | Signaling (SIP, H.323). | | 24 | CS3 | Broadcast video (some designs). | | 18 | AF21 | Transactional data. | | 10 | AF11 | Bulk data (backups, replication). | | 8 | CS1 | Scavenger (traffic you'd sacrifice first). | | 0 | BE (Best Effort) | Default. | ### 3. Queue The router maintains multiple queues on each interface. As packets arrive, classification decides which queue to drop them into. Bulk goes to one queue, voice to another, signaling to a third. **Queue depth** matters — a queue that never fills doesn't need managing. A queue that always overflows means the class is oversubscribed. ### 4. Schedule The scheduler decides which queue to service next when the outbound line is free. - **FIFO** — no QoS. One queue. - **Priority Queuing (PQ)** — strict priority. High queue always served first. High can starve low. - **Weighted Fair Queuing (WFQ)** — automatic per-flow fair-share. - **CBWFQ** (Class-Based Weighted Fair Queuing) — you define classes and bandwidth guarantees per class. - **LLQ** (Low Latency Queuing) = CBWFQ + one strict-priority queue for voice, but the priority queue is **rate-limited** so it can't monopolize the interface. This is the classic modern QoS scheduler. ## Trust boundaries If a laptop plugs into an access port and marks all its traffic DSCP 46 (voice priority), it's *stealing bandwidth*. So trust matters: - On an **IP phone**, trust the phone's own CoS marking (it knows the difference between its own voice and the PC-connected-behind-it's data). - On an **access port for a normal PC**, **don't trust** — re-mark all incoming traffic to DSCP 0. - On **switch uplinks and router WAN interfaces**, trust the DSCP already in the packet (upstream did the classification). Cisco IOS macro: `switchport priority extend cos 0` — tells an IP phone to strip the CoS on frames coming from its data port (the PC connected behind it). ## Sample LLQ + CBWFQ ``` class-map match-any VOICE match ip dscp ef ! class-map match-any SIGNALING match ip dscp af31 cs3 ! class-map match-any INTERACTIVE match ip dscp af21 ! policy-map WAN-EGRESS class VOICE priority percent 30 ! LLQ — up to 30% of link, strict priority class SIGNALING bandwidth percent 5 class INTERACTIVE bandwidth percent 25 class class-default fair-queue random-detect ! WRED — drop before full ! interface GigabitEthernet0/1 service-policy output WAN-EGRESS ``` Verify with: ``` show policy-map interface GigabitEthernet0/1 ``` Look at the "packets output" and "drops" counters per class to know if your bandwidth reservations match reality. ## Common exam / real-world mistakes 1. **Marking without a policy on the WAN egress.** Marking DSCP does nothing on its own — some interface must actually **queue and schedule** by DSCP for the mark to matter. 2. **Trusting endpoints blindly.** Users' laptops WILL mark their own traffic if you let them. Re-mark at the access edge. 3. **Setting the LLQ priority too high.** If voice takes 60% of the link, everything else stalls. Cisco's rule of thumb: don't exceed 33% of link bandwidth in LLQ. 4. **Forgetting to shape at the branch.** MPLS carriers police at their PE — the CE has to shape *below* the CIR (say, to 95%) to avoid the carrier's police drops. 5. **Confusing bandwidth (guaranteed minimum) with priority (strict).** `bandwidth 25` = 25% guaranteed under congestion, more allowed if idle. `priority 25` = capped at 25% total. ## Cheat strip ``` 4 steps Classify → Mark → Queue → Schedule Mark bits CoS 3-bit (L2) | DSCP 6-bit (L3) | IP Prec 3-bit (legacy) DSCP key EF=46 voice | AF41=34 video | AF31=26 signaling AF21=18 transactional | AF11=10 bulk | BE=0 default Trust Phone: trust CoS. PC-only port: don't trust, remark to 0. Switch uplinks / WAN: trust DSCP (upstream classified). LLQ strict-priority + rate-limited. Voice only. Cap 33% link. CBWFQ per-class bandwidth guarantee under congestion. WRED drop-before-full in the default class. Verify show policy-map interface X show mls qos interface X (on catalyst) ``` --- ## BFD — Bidirectional Forwarding Detection for Fast Failover — https://packetmentor.com/topics/bfd-bidirectional-forwarding/ > How BFD detects link and neighbor failures in under a second, why routing protocols alone can't, and how to enable BFD for OSPF, BGP, EIGRP, and HSRP on Cisco IOS. ## The one-sentence mental model **BFD is the neighbor-death detector that routing protocols wish they had.** OSPF hello is 10 s, dead 40 s. EIGRP hello 5 s, hold 15 s. BGP keepalive 60 s, hold 180 s. Way too slow for real-time apps. BFD fires 3-per-second (or faster) hellos and detects failure in under a second — then tells the routing protocol to react. ## Why not just tighten routing-protocol timers? You can. But: - **CPU cost.** Every neighbor + every protocol multiplies the hello load. - **Not consistent.** OSPF, BGP, HSRP, static routes with track — each has its own timer knobs. - **Not sub-second reliably.** Below 1s, timer-based detection gets flaky under load. BFD solves all three: one lightweight protocol, one detection engine, one config. Every routing protocol just subscribes. ## How BFD works Two neighbors negotiate a session: 1. **Discriminator exchange** — each side picks a random ID for the session and tells the peer. 2. **Timer negotiation** — TX interval + detection multiplier. Actual detection time = TX × multiplier. 3. **Steady state** — both sides fire BFD packets at the TX interval. If N in a row are missed → session down. Typical numbers: TX 50 ms × multiplier 3 = detection in 150 ms. Compare to OSPF dead-timer 40 seconds. BFD is ~250× faster. Two flavors: - **BFD Asynchronous (default)** — bidirectional constant packet stream. Detects link *and* peer aliveness. - **BFD Echo** — one side loops packets back through the other's data plane. Tests the actual forwarding hardware, not just the control plane. Best-case detection. ## Enabling BFD on Cisco IOS Enable on the interface first: ``` interface GigabitEthernet0/1 bfd interval 100 min_rx 100 multiplier 3 ``` This says: send BFD every 100 ms, expect one every 100 ms, declare dead after 3 misses (300 ms). Then attach protocols as clients. ### OSPF ``` router ospf 1 bfd all-interfaces ``` Or per-interface: `ip ospf bfd`. ### EIGRP ``` router eigrp 100 bfd all-interfaces ``` ### BGP (per neighbor) ``` router bgp 65001 neighbor 203.0.113.1 fall-over bfd ``` ### HSRP ``` interface Vlan10 standby 1 track 100 ! track 100 interface GigabitEthernet0/1 line-protocol ! ! ...with BFD enabled on Gig0/1, tracking reacts in <300ms. ``` ### Static route with BFD tracking ``` ip route 10.0.0.0 255.0.0.0 GigabitEthernet0/1 203.0.113.1 track 200 ! track 200 interface GigabitEthernet0/1 ip routing ``` ## Verifying ``` show bfd neighbors ← session state, protocols using it show bfd neighbors 203.0.113.1 details ← negotiated timers, drops ``` Look for `State = Up` and `LD/RD` (local/remote discriminator) values. If timers renegotiate to something you didn't ask for, one side's config caps the other. ## When to use BFD **Use it when:** - Real-time apps (voice, video, financial market data) traverse the link. - Dual-carrier eBGP peers — you want the "prefer ISP-A unless dead" logic to react in under a second. - Static routes that need to failover fast without a routing protocol. - HSRP tracking on WAN interfaces. **Skip it when:** - The link is a low-priority backup (a couple seconds of downtime is fine). - CPU is a hard constraint on old hardware. - The routing protocol already has sub-second timers negotiated (rare). ## Common exam / real-world mistakes 1. **Forgetting to enable BFD on the interface *and* attach the protocol.** Enabling `router ospf 1 → bfd all-interfaces` without `interface Gi0/1 → bfd interval ...` does nothing. 2. **Asymmetric timer configs.** Both sides need compatible intervals. BFD negotiates, but only within the ranges each side allows. 3. **Trusting BFD Echo without hardware support.** Some older platforms don't support echo mode. `show bfd neighbors details` will show `echo not supported`. 4. **Enabling BFD everywhere at 50/3.** That's 200+ pkts/sec per neighbor. On a scale-out core, it's real CPU. Start with 200 ms × 3 = 600 ms detection on non-critical links. 5. **Missing that BGP `fall-over bfd` still needs BFD enabled on the interface reaching the peer.** Symptom: BGP sits with default 180 s hold-timer, BFD session doesn't exist. ## Cheat strip ``` Job detect neighbor/link death. Fast. Sub-second. Numbers TX × multiplier = detection time. Typical 100×3 = 300ms. Modes Async (default) | Echo (hardware loop, best detection) Enable interface X → bfd interval T min_rx R multiplier M Attach: OSPF router ospf N → bfd all-interfaces EIGRP router eigrp N → bfd all-interfaces BGP neighbor X fall-over bfd HSRP track → interface line-protocol (with BFD on that i/f) static ip route ... track N (with BFD on the tracked interface) Verify show bfd neighbors [details] ``` --- ## WLC Deployment — Autonomous, Centralized, Cloud, and FlexConnect — https://packetmentor.com/topics/wlc-deployment/ > Every WLC / AP deployment model CCNP ENCOR expects: autonomous, centralized (CUWN), FlexConnect, Cloud (Meraki + Catalyst 9800), and embedded (EWC on a 9100 AP). Where each fits and the trade-offs. ## The four deployment models ### 1. Autonomous (standalone) APs Each AP is a mini-controller. Config lives on the AP. Common in home / SOHO or very small SMB. - Pros: no controller cost, no WAN dependency. - Cons: no roaming across APs, per-AP management, no centralized policy. CCNP mentions it exists. Nobody deploys it in the enterprise. ### 2. Centralized (CUWN / CAPWAP local mode) - APs join a central Wireless LAN Controller (WLC) via **CAPWAP tunnel** (UDP 5246 control, 5247 data). - WLC handles authentication, roaming, QoS, RRM. - Client traffic is **tunneled inside CAPWAP back to the WLC**, then breaks out onto the wired network. Pros: consistent policy everywhere. Best security. Central log / troubleshoot. Layer-3 roaming is seamless. Cons: every packet crosses the WAN to the WLC. If the WLC is at HQ, branch traffic hairpins. ### 3. FlexConnect (branch-optimized) Same WLC control plane, but the AP is smart enough to bridge client traffic locally at the branch: - **Connected mode** — WLC is reachable. AP uses WLC-configured policies but forwards user traffic straight to the local VLAN. - **Standalone mode** — WLC is unreachable. AP keeps running with the last known config, allowing users to keep working (usually with locally-authenticated SSIDs or cached AAA). Per-SSID choice: some SSIDs FlexConnect-bridge locally (guest, corporate data), some tunnel back centrally (voice, corporate high-security). ### 4. Cloud-managed - **Meraki**: APs (MR series) phone home to the Meraki cloud. Config through the Meraki dashboard. No on-prem controller. - **Catalyst 9800-CL**: virtualized WLC running in Azure/AWS. Same IOS-XE control plane as a physical 9800, deployed as a VM in the cloud. Pros: no controller sizing, elastic. Great for distributed deployments. Cons: internet reachability required for management (client data still bridges locally in FlexConnect-equivalent modes). ### 5. Embedded Wireless Controller (EWC) — worth knowing One of the 9100-series APs runs a lightweight WLC internally. Handles up to ~200 APs. Great for medium-sized single-site deployments without paying for a dedicated 9800. ## CAPWAP quick facts - **UDP 5246** — control channel. Encrypted (DTLS). - **UDP 5247** — data channel. Optionally DTLS-encrypted. - **Discovery** — AP finds WLC via DHCP option 43 (primary), DNS (secondary), broadcast (fallback), Cisco Discovery Protocol (uncommon). - **AP join** — AP downloads config + firmware from WLC. Reboots if firmware differs. ## Local mode vs FlexConnect vs Mesh vs Sniffer The AP itself has an operating mode: - **Local** — standard CAPWAP AP. - **FlexConnect** — branch mode with local data forwarding. - **Mesh** — APs form a mesh to backhaul. - **Sniffer** — AP dedicates its radio to packet capture for troubleshooting. - **Monitor** — radio only listens (no client service). Used for WIPS. - **Rogue Detector** — connects to a wired trunk to detect rogue APs by comparing wireless-heard MACs to wired-seen MACs. ## RRM — Radio Resource Management The WLC's control loop: - **DCA** (Dynamic Channel Assignment) — picks channels per AP to minimize CCI. - **TPC** (Transmit Power Control) — turns each AP's power up/down for even coverage. - **Coverage Hole Detection** — spots areas where clients see poor signal. - **CleanAir / Spectrum** — identifies non-Wi-Fi interference. Turn RRM off manually only if you have a very specific static plan; otherwise let it work. ## Common exam / real-world mistakes 1. **Local mode across a WAN.** Every packet tunnels. WAN becomes a bottleneck. Move to FlexConnect for branches. 2. **Skipping DHCP option 43.** APs at a remote site can't find the WLC → they never join. Option 43 tells them the WLC IP. 3. **Layer-3 roaming without mobility groups.** Two WLCs in different subnets: roaming client switches AP → controller-to-controller mobility tunnel must exist (mobility group configured on both). 4. **Forgetting FlexConnect ACLs.** Local traffic doesn't traverse the WLC → WLC ACLs don't apply. Configure FlexConnect ACLs pushed to the AP itself. 5. **CAPWAP MTU issue.** CAPWAP adds ~50 bytes. If WAN MTU is 1500 and clients send 1500-byte frames, fragmentation. Enable Path MTU Discovery, or lower client MTU. ## Cheat strip ``` Autonomous each AP standalone. SOHO. No roaming. Centralized APs tunnel CAPWAP back to WLC. Local mode. FlexConnect APs bridge locally at branch. Per-SSID choice. Cloud Meraki / Catalyst 9800-CL. No on-prem WLC. EWC one AP runs internal WLC. Medium site. CAPWAP UDP 5246 (ctrl, DTLS) | UDP 5247 (data, optional DTLS) Discovery DHCP opt 43 > DNS > broadcast AP modes local | flexconnect | mesh | sniffer | monitor | rogue-detector RRM DCA (channel) + TPC (power) + coverage hole + CleanAir ``` --- ## Wireless Roaming — L2, L3, 802.11r Fast Transition, and OKC — https://packetmentor.com/topics/wireless-roaming/ > How a Wi-Fi client hands off between APs without dropping the session: intra-controller (L2) roam, inter-controller (L3) roam, 802.11r Fast Transition, OKC, mobility groups. What CCNP ENCOR expects. ## Roaming basics The client — not the AP or WLC — decides when to roam. Its NIC watches signal strength, retry rates, and background scans, and jumps to a stronger AP when a threshold is hit. The **AP + WLC job** is to make that jump fast — under 50 ms if voice / real-time is on the SSID. ## Layer-2 roaming (intra-controller, same subnet) Simple case: - Client associated with AP-1, IP `10.10.5.42/24`. - Roams to AP-2 (same VLAN 5, same subnet). - WLC just updates its client entry pointing at AP-2. - Client keeps IP, keeps TCP sessions. No mobility tunnel needed. Handoff time depends on the auth method: - **Open SSID / PSK** — a few tens of ms. - **802.1X full auth** — 200-500 ms without acceleration. Too slow for voice. ## Layer-3 roaming (inter-controller / different subnet) Harder case: - Client on AP-1 (VLAN 5, `10.10.5.0/24`), WLC-1. - Roams to AP-2 (VLAN 6, `10.10.6.0/24`), WLC-2. - If we just re-DHCP, the client's `10.10.5.42` IP goes stale. Every open TCP session breaks. Solution: **mobility tunnel** between WLC-1 and WLC-2: - WLC-1 = **anchor controller** (holds the client's original subnet). - WLC-2 = **foreign controller** (where the client physically is now). - Traffic to/from the client is tunneled between WLC-2 (foreign) and WLC-1 (anchor). Client thinks it's still on VLAN 5. ## Mobility groups + domains - **Mobility group** = a set of WLCs that share security keys and can do fast, cached-context L3 roaming. Typically same physical campus. - **Mobility domain** = larger — allows roaming between groups but slower / less caching. Configure the same mobility group name + IP list on every WLC that shares a group. ## Fast roaming techniques (fixing 802.1X slowness) ### OKC — Opportunistic Key Caching (Cisco proprietary) - On first 802.1X auth, the WLC caches the PMK. - When the client roams to a different AP (on the same WLC), the WLC hands the cached PMK to the new AP. - No new 802.1X exchange — just a 4-way handshake to derive PTK. Handoff drops to ~50 ms. Works with WPA2. Not standardized. ### 802.11r — Fast Transition (FT) - IEEE standard. Client and WLC do "pre-authentication" work with target APs while still on the current AP. - New PTK is derived over the current channel, so the actual roam is just a re-association + handshake — sub-50 ms. - Two flavors: **FT over-the-air** (client talks to the new AP directly) and **FT over-the-DS** (client tunnels through its current AP to the new AP). Voice devices (Cisco 7925/8821, iPhone) support 802.11r natively. ### 802.11k — Neighbor reports - AP tells the client "here are your neighbor APs, sorted by RSSI." Client scans fewer channels → picks the right target faster. - Doesn't accelerate the handoff itself, but reduces the time spent deciding. ### 802.11v — BSS Transition Management - WLC can *request* a client to move to a specific AP. Encourages load balancing. - Modern clients honor it. Modern voice / real-time SSIDs enable **802.11r + 802.11k + 802.11v** together. ## Sample WLC configuration (Cisco 9800) ``` wireless profile policy corp-policy wpa2-fast-transition adaptive ! enable 802.11r neighbor-list-dual-band ! 802.11k bss-transition ! 802.11v fabric-mode ! (optional) wireless mobility group name campus-mobility wireless mobility group member ip 10.0.0.20 public-ip 10.0.0.20 ! peer WLC ``` ## Verifying ``` show wireless client mac detail show wireless mobility summary show wireless mobility peer-client-summary ``` Look for `Fast Transition = Enabled`, `Mobility Role = Local / Anchor / Foreign`. ## Common exam / real-world mistakes 1. **Enabling 802.11r on the same SSID as legacy clients.** Old clients that don't understand FT can't associate — they see FT-only beacons as unsupported. Use **adaptive FT** so both work. 2. **Skipping mobility groups.** Client roams between WLCs and gets a new IP → open sessions die. Configure mobility groups so anchor/foreign roaming kicks in. 3. **Different VLAN IDs across WLCs in a mobility group.** For L3 roaming to work, the client subnet must exist as an anchor on the original WLC. Mismatched VLAN plans break this. 4. **Trusting the client to roam smartly.** Some clients are terrible ("sticky"). 802.11v BSS Transition helps push them. 5. **Forgetting CoPP / firewall between WLCs.** Mobility uses CAPWAP-derived TCP + UDP (16666, 16667, EOIP GRE). Firewalls between WLCs will silently drop these. ## Cheat strip ``` L2 roam same VLAN. WLC just updates client-AP mapping. Fast. L3 roam different VLAN. Anchor + foreign WLCs tunnel client traffic. Fast roam: OKC Cisco cache PMK. Sub-50 ms. WPA2. 802.11r IEEE Fast Transition. Sub-50 ms. WPA2/3. 802.11k neighbor list. Client scans fewer channels. 802.11v BSS Transition. WLC guides client to a target AP. Roles Local | Anchor (owns subnet) | Foreign (client is here) Mobility group = same-campus + cached keys. domain = wider, slower. Verify show wireless client mac X detail show wireless mobility summary ``` --- ## LISP Basics — Locator/ID Separation Protocol — https://packetmentor.com/topics/lisp-basics/ > How LISP splits 'who you are' (EID) from 'where you are' (RLOC), enabling seamless mobility and BGP-alternative overlays. The four LISP roles CCNP ENCOR expects: ITR, ETR, MS, MR. ## The one-sentence mental model **LISP replaces "route based on the destination IP" with "look up where the destination IP lives, then tunnel to that RLOC."** The destination endpoint's IP (the EID) never has to be advertised into the underlay — the mapping system knows where it is. This decouples endpoint mobility from routing-table churn. ## The two address spaces - **EID (Endpoint Identifier)** — the address the host actually uses. `10.10.5.42/32`. - **RLOC (Routing Locator)** — the routable address of the *router* that currently reaches that EID. `203.0.113.1`. EIDs are in the overlay (host space). RLOCs are in the underlay (transit space). A single EID can appear behind different RLOCs at different times — that's mobility. ## The four roles | Role | Job | Analogy | |---|---|---| | **ITR** (Ingress Tunnel Router) | Encapsulates traffic. Looks up "which RLOC has this destination EID?" and wraps the packet in LISP. | The sender's "which post office ships to Bob today?" | | **ETR** (Egress Tunnel Router) | Decapsulates. Registers its EIDs with the mapping system so others know how to reach them. | The receiver's local post office. | | **MS** (Map-Server) | Stores mappings. ETRs register their EIDs to the MS. | Post-office HQ registry. | | **MR** (Map-Resolver) | Answers lookups. ITRs query the MR to find an EID's RLOC. | Post-office HQ query desk. | Same box can play multiple roles. A Catalyst 9500 running IOS-XE can be MS+MR+ITR+ETR simultaneously. ## The lookup flow ``` 1. Host at EID 10.10.1.5 sends packet to EID 10.10.5.42. 2. Local router acts as ITR. Doesn't know 10.10.5.42. 3. ITR queries Map-Resolver: "who has 10.10.5.42?" 4. MR returns: "RLOC 203.0.113.10, priority 10, weight 100" 5. ITR wraps original packet in LISP (UDP 4341) with outer dst 203.0.113.10. 6. Packet crosses underlay via normal IP routing. 7. ETR at 203.0.113.10 decaps → forwards to 10.10.5.42 on its local segment. ``` The mapping is cached at the ITR. Subsequent packets skip steps 3–4. ## Sample IOS-XE config (ITR + ETR combined) ``` router lisp eid-table default instance-id 4100 database-mapping 10.10.5.0/24 203.0.113.10 priority 10 weight 100 exit-eid-table ipv4 itr map-resolver 198.51.100.5 ipv4 etr map-server 198.51.100.5 key mysecret ipv4 itr ipv4 etr exit ``` ## Where you actually see LISP ### Cisco SD-Access The whole DNAC / Catalyst Center SD-Access fabric is LISP under the hood: - Fabric edge nodes are ITR/ETR. - Fabric control-plane node runs MS/MR. - Endpoint identity (EID) is separate from where the endpoint plugs in (RLOC), enabling wired + wireless roaming with consistent policy. If SD-Access is on the ENCOR blueprint, LISP is the mechanism behind every "seamless roam." ### LISP as a BGP alternative Some ISPs and CDNs use LISP for traffic engineering — advertising the same EID prefix from multiple RLOCs with priority/weight. Manipulate the reply to steer inbound traffic without touching BGP. ### Cisco IWAN legacy Older Intelligent WAN designs used LISP for path selection. Superseded by SD-WAN, but still on some blueprints. ## Priority + weight Each EID can be behind multiple RLOCs. The mapping reply carries per-RLOC priority (lower wins) and weight (load-share within same priority): ``` EID 10.10.5.0/24 RLOC 203.0.113.10 priority 10 weight 100 ← primary RLOC 203.0.113.20 priority 20 weight 100 ← backup ``` ## Common exam / real-world mistakes 1. **Confusing EID and RLOC direction.** EID is what the host uses. RLOC is what the underlay routes to. Draw the two spaces; keep them separate mentally. 2. **Forgetting to register EIDs.** ETR must send Map-Register messages to the MS. If it doesn't, no ITR can find the EID. 3. **Underlay reachability of RLOCs.** MS/MR + all RLOCs must be reachable in the underlay (typically via OSPF / BGP). If the underlay routing to the RLOC breaks, LISP breaks. 4. **Instance-id vs VRF.** LISP uses instance-id to segment overlays (multi-tenant). Maps 1:1 to the VRF concept but not identical config. 5. **UDP 4341 blocked by firewalls.** Both the LISP control (UDP 4342) and data (UDP 4341) must be permitted end-to-end. ## Cheat strip ``` EID endpoint identity (host address). Overlay. RLOC router locator on the underlay. Roles ITR = encaps, does lookup ETR = decaps, registers EIDs MS = stores mappings (registration target) MR = answers lookups (resolution target) Ports UDP 4341 data | UDP 4342 control Flow ITR asks MR → MR replies with RLOC → ITR encaps → ETR decaps Where SD-Access fabric under the hood Optional BGP alternative for TE Instance-id = per-VRF overlay segmentation ``` --- ## MACsec (IEEE 802.1AE) — Layer-2 Wire-Speed Encryption — https://packetmentor.com/topics/macsec/ > How MACsec encrypts every Ethernet frame between two neighbors at line rate. AES-GCM, MKA key agreement, MACsec vs IPsec, and the CCNP ENCOR config on a Cat 9K. ## The one-sentence mental model **MACsec is IPsec's Layer-2 sibling.** Where IPsec encrypts IP packets between endpoints across many hops, MACsec encrypts *every* Ethernet frame between exactly two directly-connected neighbors — link-by-link. Because it runs in ASIC, it doesn't cost forwarding performance. ## Where MACsec fits vs alternatives | Scope | Protects | Perf | Where you'd use it | |---|---|---|---| | **MACsec** | Layer-2 frames between two adjacent devices | Line rate (hardware) | Switch uplinks, DCI, campus core, host→switch. | | **IPsec** | IP packets end-to-end across many hops | CPU or crypto-offload | Site-to-site VPNs, remote user tunnels. | | **TLS** | TCP applications end-to-end | CPU | HTTPS, mail, most modern apps. | They compose: MACsec at each hop, IPsec end-to-end, TLS above. ## The two roles per session MACsec is between exactly two peers. On each session: - **Key Server** — generates the SAK (Secure Association Key), distributes it via MKA. - **Key Client** — receives the SAK, encrypts/decrypts using it. Election of key server is by lowest priority. Both sides must agree on cipher suite (`gcm-aes-128`, `gcm-aes-256`). ## The MKA control channel MACsec Key Agreement (MKA) rides on EAPOL frames (ethertype 0x888E) — the same frames 802.1X uses. Two ways to bootstrap: - **PSK-based MKA** — configure the same pre-shared CAK (Connectivity Association Key) on both switches. Simple. Common for switch↔switch uplinks in a data center. - **EAP-based MKA** — the switches (or the host) authenticate via 802.1X first, deriving a PMK. That PMK becomes the CAK for MKA. Ties into ISE / RADIUS naturally. Host-to-switch typical. ## Cipher suites + confidentiality offset MACsec always **authenticates** the frame (integrity + origin). Encryption is optional but usually on: - **Confidentiality offset 0** — encrypt the entire payload. - **Confidentiality offset 30 / 50** — leave the first 30 / 50 bytes of the payload in clear (for downstream L2/L3 devices that need to see IP/UDP headers before they hit the endpoint). Rare — only for specific carrier / QoS use cases. Cipher choices: `gcm-aes-128`, `gcm-aes-256`, `gcm-aes-xpn-128/256` (extended packet numbering for very high-rate links to avoid PN wrap). ## Config sketch — switch↔switch with PSK **On both switches, the uplink interface:** ``` key chain macsec-keychain macsec key 01 cryptographic-algorithm aes-256-cmac key-string 12345678901234567890123456789012 lifetime 00:00:00 Jan 1 2026 infinite ! mka policy MKA-POLICY key-server priority 200 macsec-cipher-suite gcm-aes-256 confidentiality-offset 0 ! interface TenGigabitEthernet1/0/1 macsec network-link mka policy MKA-POLICY mka pre-shared-key key-chain macsec-keychain ``` Both sides need matching cipher + matching key + reachable MKA. ## Verifying ``` show mka sessions ! sessions per interface show mka sessions detail ! CAK/SAK identifiers, timers show mka statistics interface TenGig1/0/1 show macsec interface TenGig1/0/1 ! encrypt/decrypt counters ``` Look for `Session status = SECURED`. If it's `INITIALIZING`, the far side isn't answering; if it's `PENDING`, MKA hasn't completed election yet. ## MACsec + trunks MACsec is Layer 2 — it operates below 802.1Q tagging. On a trunk, MACsec encrypts the whole tagged frame including the VLAN tag. Nothing between the two endpoints (including a MACsec-unaware intermediate switch) can inspect or forward — so **MACsec is strictly point-to-point between MACsec-capable devices.** ## Common exam / real-world mistakes 1. **Trying to run MACsec through an intermediate switch.** It's link-by-link. Every hop between must speak MACsec, or it terminates and re-originates. 2. **Cipher mismatch.** One side gcm-aes-128, the other gcm-aes-256. Session never comes up. `show mka sessions detail` shows suite mismatch. 3. **PSK-based CAK strings different length.** MKA rejects. Both sides must have a byte-identical CAK. 4. **Blocking EAPOL.** MKA rides EAPOL. If any upstream filter drops ethertype 0x888E, MKA fails. 5. **Confusing MACsec with SGT / TrustSec.** SGT is Cisco's segmentation tag (embedded in a Cisco Meta Data field). MACsec can carry it, but they're different features. CCNP tests them separately. ## Cheat strip ``` Standard IEEE 802.1AE Scope point-to-point, Layer 2, adjacent neighbors only Cipher AES-GCM 128/256, optional confidentiality offset Key MKA (EAPOL) — PSK or EAP-derived Roles Key Server (elected by priority) + Key Client Where switch↔switch uplinks (typical) host↔switch (NDAC / TrustSec) Config key chain (PSK) → mka policy → interface macsec network-link Verify show mka sessions | show macsec interface X Vs IPsec MACsec = link-by-link L2. IPsec = end-to-end L3. ``` --- ## CoPP — Control Plane Policing — https://packetmentor.com/topics/copp-control-plane-policing/ > Why routers need CoPP, how it rate-limits traffic destined to the CPU (routing protocols, SNMP, SSH, ARP), and the classify/police policy shape CCNP ENCOR tests. ## The one-sentence mental model **CoPP is a firewall for the router's own CPU.** Data-plane traffic (transit) goes through the ASIC and doesn't touch the CPU. Control-plane traffic (destined *to* the router or generated *by* it) does. A packet flood at the control plane will kill routing protocols, drop SSH sessions, and crash the box — even while transit forwarding still works. ## What lives on the control plane Every one of these hits the CPU: - **Routing protocol packets** — OSPF hellos, BGP KEEPALIVEs, EIGRP hellos, IS-IS PDUs. - **First-hop redundancy** — HSRP / VRRP / GLBP hellos. - **Management** — SSH, Telnet (please no), SNMP, syslog reply, RADIUS. - **Discovery** — CDP, LLDP. - **Address resolution** — ARP requests + replies to the router's IP. - **Punt** — packets the ASIC couldn't handle (unknown next-hop, IP option, TTL=1). - **Unicast to me** — ICMP to my IP, TCP SYN to a listening port. Any of these being flooded = CPU pegs = router unresponsive. ## The classify → police pattern CoPP uses the standard MQC (Modular QoS CLI) constructs but binds the policy to the control plane instead of an interface. ### Step 1 — ACLs to identify traffic ``` ip access-list extended COPP-ROUTING permit ospf any any permit tcp any any eq bgp permit tcp any eq bgp any permit eigrp any any ip access-list extended COPP-MGMT permit tcp any any eq 22 permit udp any any eq snmp permit udp any any eq syslog ip access-list extended COPP-UNDESIRABLE permit icmp any any redirect permit ip any host 224.0.0.9 # RIP (if not run) ``` ### Step 2 — Class-maps ``` class-map match-any COPP-CRITICAL match access-group name COPP-ROUTING class-map match-any COPP-NORMAL match access-group name COPP-MGMT class-map match-any COPP-UNDESIRABLE match access-group name COPP-UNDESIRABLE ``` ### Step 3 — Policy-map with police statements ``` policy-map COPP-POLICY class COPP-CRITICAL police cir 4000000 conform-action transmit exceed-action transmit class COPP-NORMAL police cir 1000000 conform-action transmit exceed-action drop class COPP-UNDESIRABLE police cir 32000 conform-action drop exceed-action drop class class-default police cir 500000 conform-action transmit exceed-action drop ``` Numbers are examples — sized to protect the CPU, not to shape a real service. Small `cir` values are typical. ### Step 4 — Apply to the control plane ``` control-plane service-policy input COPP-POLICY ``` ## Sizing the rates Rule of thumb: budget each class based on **legitimate steady-state × 3-5×** to absorb transient bursts. - **Routing critical**: even a busy BGP box rarely exceeds a few Mbps of control traffic. `police cir 10000000` (10 Mb) is generous. - **Management**: SSH + SNMP polls. A few hundred Kbps. - **Undesirable**: drop hard, no headroom. - **Class-default**: catch everything else. Give it enough headroom that legitimate discovery works, but low enough that a flood can't hurt. Tune with `show policy-map control-plane input` — look at the "packets dropped" counter per class. If CRITICAL is dropping, you sized too low. If UNDESIRABLE is nonzero, you have suspicious traffic. ## Verification ``` show policy-map control-plane input show policy-map control-plane input class COPP-NORMAL show platform hardware qfp active feature qos control-plane # ASR/9K ``` Look for `conformed` counters growing (normal traffic) and `exceeded` counters growing (attack traffic being policed). ## Common exam / real-world mistakes 1. **Missing a class → default catches everything.** If your default policer is too tight, legitimate ARP breaks. If too loose, an attacker can flood via the default class. Size it deliberately. 2. **Applying to an interface instead of the control plane.** CoPP MUST be `service-policy input POLICY` under `control-plane`, not under a physical interface. 3. **Forgetting broadcast / multicast to me.** ARP requests are broadcast; router responds. Need a class covering ARP explicitly on some platforms, or "match protocol arp". 4. **CoPP vs CPPr (Control Plane Protection).** CPPr is the newer, subinterface version — separates host / transit / cef-exception into sub-planes. Some Cisco docs use CPPr and the same MQC constructs. 5. **Not testing.** Configure conservative rates, deploy in monitor mode (all `transmit` actions), watch counters for a week, then tighten. Skipping this locks you out during a flood. ## Cheat strip ``` Job protect router CPU from control-plane floods Applies to control-plane (not an interface) Syntax MQC — class-map → policy-map → service-policy Class idea CRITICAL routing protocols never drop NORMAL mgmt (SSH, SNMP, syslog) rate-limit UNDESIRABLE unknown/spoofed drop hard class-default catch-all small allow, exceed drop Size legit × 3–5. Start loose. Watch counters. Tighten. Verify show policy-map control-plane input Newer CPPr adds host / transit / cef-exception sub-planes ``` --- ## EEM — Embedded Event Manager Applets and Scripts — https://packetmentor.com/topics/eem-embedded-event-manager/ > How EEM lets a Cisco router react to on-box events automatically: syslog triggers, SNMP thresholds, timers, interface state — all handled with tiny applets or Tcl scripts. The CCNP ENCOR automation you can enable without any external tool. ## The one-sentence mental model **EEM is a `while True: watch for X, do Y` loop inside every Cisco router.** No Python server, no NETCONF client — the box reacts to itself. ## Anatomy of an applet ``` event manager applet CATCH-BGP-FLAP event syslog pattern "BGP-5-ADJCHANGE.*Down" action 1.0 cli command "enable" action 2.0 cli command "show ip bgp summary" action 3.0 cli command "show ip bgp neighbors" action 4.0 syslog msg "EEM captured BGP flap" action 5.0 mail server "10.0.0.50" to "netops@corp.com" ... ``` Three parts: 1. **Applet name** — must be unique. 2. **Event** — the trigger. Choose from ~30 event types. 3. **Actions** — the response, numbered so the order is predictable. ## Common event types | Event | Fires when | |---|---| | `syslog pattern "REGEX"` | Any log line matches the regex. | | `snmp oid X.Y.Z threshold ...` | SNMP polled value crosses a threshold. | | `interface name Gi0/1 parameter input-errors ...` | Interface counter changes. | | `timer cron ...` | On a schedule ("every 5 min", "at 03:00 daily"). | | `timer countdown ...` | Once, after N seconds. | | `timer watchdog time ...` | Repeatedly, every N seconds. | | `track object X state up|down` | A tracked object flips state. | | `cli pattern "REGEX"` | An admin types a matching command. | | `none` | Manual trigger with `event manager run APPLET`. | ## Actions you have available - **cli command "..."** — run a CLI command, capture output (`$_cli_result`). - **syslog msg "..."** — log an EEM-generated message. - **mail server X to Y subject "..." body "..."** — send email (must have SMTP server reachable). - **snmp-trap** — send an SNMP trap. - **puts / info / regexp** — string manipulation. - **counter name X op set|add value N** — bump an internal counter. - **set var VALUE** — assign a variable, used later with `$var`. - **wait 5** — sleep 5 seconds. ## Classic use cases ### Auto-collect on OSPF adjacency flap ``` event manager applet OSPF-FLAP-CAPTURE event syslog pattern "OSPF.*Neighbor Down" action 1.0 cli command "enable" action 2.0 cli command "show ip ospf neighbor detail" action 3.0 cli command "show ip ospf interface" action 4.0 cli command "show logging | last 100" action 5.0 file open OUTPUT flash:/eem-ospf-flap.log w action 6.0 file puts OUTPUT "$_cli_result" action 7.0 file close OUTPUT ``` Next time OSPF flaps at 3 AM, the diagnostics are already on flash. No "please try to catch it next time". ### Config-change auto-rollback (config-replace pattern) ``` event manager applet CONFIG-CONFIRM event none action 1.0 cli command "enable" action 2.0 cli command "archive" action 3.0 cli command "path flash:pre-change" action 4.0 cli command "end" action 5.0 cli command "archive config" action 6.0 wait 600 action 7.0 cli command "configure replace flash:pre-change force" ``` Trigger it manually before a risky change with `event manager run CONFIG-CONFIRM`. If you don't cancel it in 10 minutes, the config auto-rolls back. Saves careers. ### Disable a flapping interface ``` event manager applet CRC-STORM event snmp oid 1.3.6.1.2.1.31.1.1.1.10.10101 get-type exact entry-op ge entry-val 1000 poll-interval 60 action 1.0 cli command "enable" action 2.0 cli command "configure terminal" action 3.0 cli command "interface Gi0/1" action 4.0 cli command "shutdown" action 5.0 syslog msg "EEM shut Gi0/1 after CRC storm" ``` ## Tcl scripts vs applets If your logic needs loops, conditionals more complex than a single `if`, or arithmetic, move up to Tcl scripts: ``` event manager directory user policy flash:/eem-scripts/ event manager policy check-bandwidth.tcl ``` The `.tcl` file is a full Tcl program with access to the same event / action library. 90% of real EEM use stays in applets — Tcl is there when you need it. ## Verification ``` show event manager policy registered show event manager history events show event manager statistics debug event manager action cli ! see actions live ``` `history events` is invaluable — shows every EEM trigger and its outcome for the last N days. ## Common exam / real-world mistakes 1. **Missing `event manager applet` privilege.** Applets run with the applet's configured priv (default 15). Actions like `cli command "enable"` are needed because applet default doesn't inherit enable mode. 2. **Bad regex.** Cisco's syslog patterns use POSIX regex-like syntax. Test against actual log strings — `%OSPF-5-ADJCHG:` is different from `OSPF-5-ADJCHG`. 3. **Blocking on wait/mail.** If SMTP is down, `mail server` blocks. Watch out on frequent-fire applets. 4. **Not versioning applets.** They live in config — treat them like code. Copy to a repo, apply via config management (Ansible / NetMiko). 5. **Firing recursively.** A syslog-triggered applet that itself generates syslog can re-trigger. Add a guard condition or `set` a variable to break the loop. ## Cheat strip ``` Job event-driven automation inside the router itself Trigger syslog | snmp | timer | interface | track | cli | none Actions cli / syslog / mail / snmp-trap / file / regexp / wait / set Applet short, config-embedded Tcl script larger, file on flash Classic uses: - auto-collect debug on adjacency flap - config auto-rollback if not confirmed - shut interface after error threshold - alert on config change Verify show event manager policy registered show event manager history events ``` --- ## NETCONF and RESTCONF — Model-Driven Network APIs — https://packetmentor.com/topics/netconf-restconf/ > How NETCONF (XML over SSH) and RESTCONF (JSON/XML over HTTPS) let you configure Cisco IOS-XE / NX-OS programmatically using YANG models. Config datastores, capabilities, and where each fits. ## The one-sentence mental model **Screen-scraping the CLI is fragile. Model-driven APIs are contracts.** Instead of parsing "show ip interface brief" text output, you fetch a YANG-shaped tree of interface state — same on every version, same across platforms that share the model. ## Layers stacked together ``` Your automation code (Python / Ansible / Terraform) ↓ Protocol: NETCONF (XML / SSH) or RESTCONF (JSON / HTTPS) ↓ YANG data model (structure of the config / state) ↓ Device (IOS-XE, NX-OS, IOS-XR, JunOS, Arista, etc.) ``` - **YANG** = the schema. Defines what fields exist and their types. - **NETCONF / RESTCONF** = the wire protocols that carry YANG-modeled data. - **gNMI** = a newer alternative — same YANG models but over gRPC (see the telemetry topic). ## NETCONF quick facts - **Transport**: SSH, port 830 (default). - **Encoding**: XML. - **Operations**: ``, ``, ``, ``, ``, ``, ``, ``. - **Datastores**: `running` (live), `candidate` (staging area), `startup` (saved), sometimes `intended`. - **Capabilities**: on session open, device advertises which YANG modules + features it supports. Typical flow: 1. Open SSH session on port 830. 2. Exchange `` — device sends capabilities. 3. `` the candidate datastore. 4. `` to stage changes. 5. `` (optional) — syntax check. 6. `` to apply. 7. `` → ``. Because commit is atomic across the candidate → running move, either everything applies or nothing does. That's the killer feature vs REST. ## RESTCONF quick facts - **Transport**: HTTPS. - **Encoding**: JSON (`application/yang-data+json`) or XML. - **Operations**: standard HTTP verbs — **GET**, **POST** (create), **PUT** (replace), **PATCH** (merge), **DELETE**. - **Base URL**: `https:///restconf/data/:/...` Sample GET on IOS-XE for a specific interface: ``` curl -k -u admin:pass \ -H "Accept: application/yang-data+json" \ https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 ``` Sample PUT to set an IP: ``` curl -k -u admin:pass -X PUT \ -H "Content-Type: application/yang-data+json" \ -d '{"ietf-interfaces:interface":{"name":"GigabitEthernet1","enabled":true,"ietf-ip:ipv4":{"address":[{"ip":"10.10.1.1","netmask":"255.255.255.0"}]}}}' \ https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 ``` ## Turning them on (IOS-XE) ``` netconf-yang restconf ip http secure-server ``` Then confirm: ``` show netconf-yang datastores show netconf-yang sessions show platform software yang-management process ``` ## Python quickstart **NETCONF** with `ncclient`: ```python from ncclient import manager with manager.connect(host="10.0.0.1", port=830, username="admin", password="pass", hostkey_verify=False) as m: print(m.get_config(source="running").data_xml[:2000]) ``` **RESTCONF** with `requests`: ```python import requests requests.packages.urllib3.disable_warnings() r = requests.get( "https://10.0.0.1/restconf/data/ietf-interfaces:interfaces", auth=("admin","pass"), headers={"Accept": "application/yang-data+json"}, verify=False) print(r.json()) ``` Ansible ships modules for both (`ansible.netcommon.netconf_get`, `ansible.netcommon.restconf_config`). ## When to pick which **NETCONF** when: - You need atomic multi-change transactions (candidate + commit). - You need `` to prevent parallel changes during a change window. - You're using a mature framework like NSO / OpenDaylight. **RESTCONF** when: - You want to script quick tooling with curl / Postman / vanilla `requests`. - Your team already speaks REST. - Transactional atomicity isn't required (single-request changes). **gNMI** when: - You want telemetry (streaming state changes over persistent connection). - Multi-vendor at scale — gNMI is more standardized across vendors than either. ## Common exam / real-world mistakes 1. **Confusing YANG with NETCONF.** YANG is the schema; NETCONF is the transport. Same YANG can be used over NETCONF, RESTCONF, or gNMI. 2. **Assuming RESTCONF is transactional.** It isn't. A PATCH that touches many fields may partially apply and error out. Reach for NETCONF if you need atomic. 3. **Mixing OpenConfig and Cisco-native models.** Every device supports both. Same feature, different YANG structure. Standardize on one per project or pay in translation code. 4. **Ignoring capabilities.** Two IOS-XE versions may advertise different YANG modules. Always fetch the device's capabilities before assuming a path exists. 5. **Password in the config.** Basic auth over HTTPS is convenient in the lab but painful in prod. Move to certificate-based auth or vault-managed secrets. ## Cheat strip ``` YANG the schema. Both protocols speak it. NETCONF XML over SSH port 830. Rich: locks, candidate/running/startup, commit/rollback, atomic transactions. Client: ncclient. RESTCONF JSON (or XML) over HTTPS. Standard REST verbs. curl-friendly. Client: requests / Postman / any HTTP tool. Enable IOS-XE: netconf-yang restconf ip http secure-server Operations NETCONF RESTCONF GET / POST / PUT / PATCH / DELETE Pick transactional multi-change → NETCONF quick REST scripts → RESTCONF streaming telemetry → gNMI ``` --- ## Cisco StackWise Virtual (SVL) — Two Chassis as One Logical Switch — https://packetmentor.com/topics/stackwise-virtual/ > How StackWise Virtual makes a pair of Catalyst 9500/9600 chassis behave as a single logical switch. SVL links, DAD (dual-active detection), and why SVL replaced legacy VSS. ## The one-sentence mental model **SVL is HSRP on steroids for the whole switch.** Instead of two boxes with a virtual gateway IP that fails over between them, SVL makes the *two boxes themselves* one logical unit. Downstream devices see a single switch. STP sees a single switch. Routing peers see a single switch. Failover is transparent because "failover" doesn't exist — the surviving chassis just keeps operating. ## Why it matters Classic dual-chassis campus design has ugly compromises: - **STP blocks half your uplinks.** With two dist switches and redundant uplinks, STP blocks the second path. - **HSRP/VRRP for gateway redundancy.** Works, but adds config and asymmetry. - **MC-LAG (mLAG) is proprietary and hard.** SVL solves all three: two chassis = one control plane = one gateway = MEC (Multi-chassis EtherChannel) uplinks from downstream. STP doesn't block anything because there's only one logical switch. ## The pieces ### StackWise Virtual Link (SVL) The physical link(s) between the two chassis. Carries: - Control-plane sync (routing tables, MAC tables, ARP) - Data-plane traffic that ingressed on one chassis but must egress on the other - Keepalives Typical config: 2+ interfaces bundled (LACP-like within SVL), 40G or 100G to handle worst-case cross-chassis traffic. Kept on dedicated ports away from user traffic. ### Dual-Active Detection (DAD) If the SVL dies but both chassis stay up, each thinks the other is dead → both become active → split brain → duplicate MACs, IPs, routing chaos. DAD prevents this via one of: - **DAD via a peer link** — direct L2 link separate from SVL - **DAD via ePAgP** — enhanced PAgP heartbeats over an EtherChannel uplink to a downstream switch (that switch relays "the other chassis is still alive" back to me) - **DAD via BFD over a management interface** When DAD detects both members active, one member goes into **recovery mode** — shuts all interfaces except SVL and management, waits for the SVL to come back. ### MEC — Multi-Chassis EtherChannel The killer feature. Downstream switches bundle uplinks — one to each SVL chassis — into a single Port-channel. From the downstream's point of view it's a normal EtherChannel to one switch. From SVL's point of view it's a MEC that survives either chassis failing. No STP blocking. Both uplinks forward. If a chassis fails, the surviving chassis takes over the MEC and downstream traffic doesn't even blip. ## Sample config outline ``` ! On both chassis: switch 1 provision c9500-40x stackwise-virtual domain 100 ! interface range TenGigabitEthernet1/0/1-2 stackwise-virtual link 1 ! ! Dual-active detection stackwise-virtual dual-active-detection pagp trust channel-group 10 ``` After reload, the two chassis boot as one — you SSH into the "virtual" switch, `show switch` shows Switch 1 (Active) and Switch 2 (Standby). ## Switch roles - **Active** — runs the control plane. All routing / management runs here. - **Standby** — mirrors state from Active. If Active dies, Standby takes over via SSO (Stateful Switchover). Sub-second failover for most protocols. Both chassis forward user traffic. The Active/Standby distinction is about control plane, not data plane. ## Common exam / real-world mistakes 1. **Not sizing the SVL for worst-case cross-chassis traffic.** If a downstream sends traffic to chassis A but the destination MAC is behind chassis B, the frame crosses the SVL. Underprovisioned SVL becomes the bottleneck. 2. **Skipping DAD.** SVL alone is not enough. Configure DAD via ePAgP or a dedicated link. 3. **Mixing switch models.** Both chassis must be identical model + license. 4. **Assuming SVL = HA cluster.** SVL is a single logical switch, not two switches in a cluster. Config is applied once and syncs. Upgrades are In-Service Software Upgrade (ISSU) or scheduled reload. 5. **Confusing SVL with legacy VSS.** Same concept, different platform. VSS was on Catalyst 6500/6800 with dedicated VSL cards. SVL is on Catalyst 9500/9600 using front-panel ports. Do not carry over old VSS-specific commands. ## Cheat strip ``` Purpose two chassis → one logical switch Platforms Catalyst 9500 / 9600 (SVL) ; Cat 6500/6800 (VSS legacy) SVL bundled 10/40/100G between chassis. Control + data cross-chassis. DAD Dual-Active Detection. Options: ePAgP | dedicated link | BFD. MEC Multi-chassis EtherChannel. Downstream sees one Port-channel. Roles Active (control) + Standby (mirror). SSO for sub-second failover. STP eliminated for uplinks — no blocking, both paths forward. Config stackwise-virtual domain N ; stackwise-virtual link 1 on member ifs ``` --- ## IPv6 First-Hop Security — RA Guard, DHCPv6 Guard, ND Inspection — https://packetmentor.com/topics/ipv6-first-hop-security/ > The four Layer-2 security features every enterprise needs when it enables IPv6: RA Guard blocks rogue Router Advertisements, DHCPv6 Guard blocks rogue DHCPv6 servers, ND Inspection validates Neighbor Discovery, IPv6 Source Guard binds addresses to ports. ## The one-sentence mental model **IPv6 gives an attacker four Layer-2 attack surfaces (rogue RA, rogue DHCPv6, ND spoofing, IPv6 spoofing).** First-Hop Security is Cisco's four features that mirror what you're already doing on IPv4 (RA Guard ↔ nothing on v4; DHCPv6 Guard ↔ DHCP snooping; ND Inspection ↔ DAI; IPv6 Source Guard ↔ IP Source Guard). Deploy all four together or you have gaps. ## The four features ### 1. RA Guard (Router Advertisement Guard) — the most important A malicious host sends fake Router Advertisements claiming to be the default gateway. Every host on the segment believes it, updates its default route to the attacker, and now the attacker sees all off-link traffic. **RA Guard** on the switch drops RAs on untrusted ports. Only the port toward the real router is trusted to send RAs. ``` ipv6 nd raguard policy HOST-RAGUARD device-role host ipv6 nd raguard policy ROUTER-RAGUARD device-role router interface GigabitEthernet0/1 ipv6 nd raguard attach-policy HOST-RAGUARD ! access ports ! interface GigabitEthernet0/24 ipv6 nd raguard attach-policy ROUTER-RAGUARD ! uplink to router ``` Default policy on ports without explicit config: `device-role host` (safer default). ### 2. DHCPv6 Guard A rogue DHCPv6 server hands out its own address as gateway/DNS. Same attack as DHCPv4 rogue-server, just IPv6. **DHCPv6 Guard** filters DHCPv6 server messages (ADVERTISE, REPLY) on untrusted ports. ``` ipv6 dhcp guard policy HOST-DHCPGUARD device-role client ipv6 dhcp guard policy SERVER-DHCPGUARD device-role server interface GigabitEthernet0/1 ipv6 dhcp guard attach-policy HOST-DHCPGUARD ! interface GigabitEthernet0/24 ipv6 dhcp guard attach-policy SERVER-DHCPGUARD ! uplink to DHCPv6 server ``` ### 3. ND Inspection (Neighbor Discovery Inspection) IPv6's replacement for ARP. Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages resolve IPv6 → MAC. Attacker can spoof NAs to claim any IPv6 address. **ND Inspection** validates NS/NA against a binding table (built from DHCPv6 snooping and/or SEND). Drops anything that doesn't match. Requires a **binding table** to be populated: ``` ipv6 neighbor binding vlan 10 ipv6 neighbor binding logging ipv6 nd inspection policy HOST-NDPOLICY device-role host interface GigabitEthernet0/1 ipv6 nd inspection attach-policy HOST-NDPOLICY ``` ### 4. IPv6 Source Guard Once the binding table exists, IPv6 Source Guard enforces that any packet's source IPv6 address matches the binding for the ingress port. Blocks address spoofing. ``` ipv6 source-guard policy SRC-GUARD deny global-autoconf interface GigabitEthernet0/1 ipv6 source-guard attach-policy SRC-GUARD ``` ## The binding table — where the state lives All four features (well, three of the four) depend on the **IPv6 neighbor binding table**. Populated by: - **DHCPv6 snooping** — captures DHCPv6 REPLY events, records IP↔MAC↔port - **SEND** (Secure Neighbor Discovery) — cryptographically signed NDP, populates binding table on trusted signatures - **Static entries** — for servers with fixed IPv6 Verify: ``` show ipv6 neighbor binding show ipv6 neighbor binding vlan 10 ``` ## Deployment order 1. **Turn on RA Guard first** — biggest attack surface, cheapest to deploy. 2. **Add DHCPv6 Guard** if you use DHCPv6 (many IPv6 shops use SLAAC only — then this is skipped). 3. **Build the binding table** via DHCPv6 snooping. 4. **Add ND Inspection** on the same VLANs. 5. **Add IPv6 Source Guard** as the enforcement layer. Don't deploy 3-5 without a populated binding table — legit traffic will be dropped. ## Common exam / real-world mistakes 1. **Skipping RA Guard because "we're an all-SLAAC shop"**. SLAAC is exactly why RA Guard matters — attacker can inject SLAAC RAs and steal every default gateway on the segment. 2. **Attaching a host policy to the router uplink**. Router-facing ports need `device-role router` policies. Getting this wrong drops legitimate RAs. 3. **Forgetting the binding table** — deploying ND Inspection or IPv6 Source Guard without DHCPv6 snooping or SEND means an empty binding table and everything gets dropped. 4. **Confusing DAI-thinking with ND Inspection.** They're conceptually similar (validate L2 protocol against binding) but have different message types. NS/NA replaces ARP request/reply. 5. **Ignoring link-local addresses.** Every IPv6 interface auto-generates a link-local (fe80::/10). Policies must permit link-local or basic protocols break. ## Cheat strip ``` IPv6 threats: rogue RA, rogue DHCPv6, ND spoof, source-IP spoof FHS answer: RA Guard, DHCPv6 Guard, ND Inspection, IPv6 Source Guard RA Guard blocks rogue RAs on host ports. #1 most-important. DHCPv6 Guard blocks rogue server messages on host ports. ND Inspection validates NS/NA against binding table (like DAI). IPv6 Source Guard enforces source IP matches binding (like IPSG). Binding table populated by DHCPv6 snooping + SEND + static entries. Required for ND Inspection + Source Guard. Roles device-role host (default) | router | server Config style policy X → device-role Y → attach-policy X on interface Verify show ipv6 neighbor binding show ipv6 nd raguard policy X ``` --- ## IP SLA — Cisco's Active Network Measurement + Track Object Integration — https://packetmentor.com/topics/ip-sla/ > How Cisco IP SLA sends synthetic probes (ICMP, TCP, UDP, HTTP, jitter) to measure availability, latency, and jitter — and how track objects plug those measurements into HSRP, static routes, and PBR for smart failover. ## The one-sentence mental model **IP SLA is a synthetic probe engine built into IOS.** Instead of waiting for user traffic to fail (or a routing-protocol hello to time out), the router itself sends test packets — ICMP echo, TCP connect, UDP jitter, HTTP GET, DNS query — and measures the result. Feed that into track objects and the router reacts to *measurement*, not just interface state. ## What IP SLA can probe | Operation | What it tests | |---|---| | `icmp-echo` | Basic reachability + round-trip latency. Cheap and universal. | | `tcp-connect` | Does port X on host Y accept a TCP connection? | | `udp-jitter` | Round-trip and one-way jitter for VoIP — requires responder on the other end. | | `udp-echo` | UDP round-trip. Simpler than jitter. | | `path-jitter` | Per-hop jitter along the path (like traceroute + jitter measurement combined). | | `http` | HTTP GET — validates web server reachability + response time. | | `dns` | DNS query round-trip. | | `ftp` | FTP file transfer time. | ## Basic ICMP probe ``` ip sla 10 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/1 frequency 10 timeout 500 threshold 200 ip sla schedule 10 life forever start-time now ``` - Send an ICMP echo to 8.8.8.8 every 10 seconds - Timeout after 500 ms - Consider it "over threshold" (unhealthy) at 200 ms - Run forever, start now Verify: ``` show ip sla statistics 10 show ip sla summary ``` ## UDP jitter with a responder Real jitter measurement needs both endpoints. The far-end must be a Cisco device running the IP SLA Responder: ``` ! On the responder (far end): ip sla responder ! On the source (near end): ip sla 20 udp-jitter 198.51.100.10 5000 num-packets 20 interval 10 frequency 30 request-data-size 200 ip sla schedule 20 life forever start-time now ``` Now you get one-way latency + jitter + loss (both directions) with timestamps that account for the responder-side processing delay. ## Track objects — where the value comes in Raw IP SLA data is useful but the real power is coupling it to track objects that other features consume. ### Track SLA reachability ``` track 100 ip sla 10 reachability delay down 5 up 20 ``` Track 100 is "up" while IP SLA 10 is meeting its threshold, "down" when it isn't. Delay smooths flapping. ### HSRP with tracking — WAN-aware failover ``` interface Vlan10 ip address 10.10.10.2 255.255.255.0 standby 1 ip 10.10.10.1 standby 1 priority 110 standby 1 preempt standby 1 track 100 decrement 20 ``` If track 100 goes down (WAN link failing SLA), the priority drops from 110 to 90 — the standby (which has priority 100) becomes active. Gateway follows the healthy WAN. ### Floating static + track — dual-WAN failover ``` ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 100 ! primary, active while WAN is healthy ip route 0.0.0.0 0.0.0.0 198.51.100.1 200 ! floating static, AD 200 ``` When track 100 (IP SLA 10 to the primary ISP) goes down, the primary default is removed and the AD-200 floating static becomes active. ### PBR with tracking — reroute voice ``` route-map VOICE-BEST-PATH permit 10 match ip address VOICE-ACL set ip next-hop verify-availability 10.1.1.1 10 track 100 set ip next-hop 10.2.2.1 ``` If track 100 (measuring the good WAN) is down, PBR falls back to the second next-hop. ## Reasonable thresholds - **VoIP one-way latency**: < 150 ms end-to-end, ideally < 100 ms on the WAN - **Jitter**: < 30 ms for good voice quality - **Packet loss**: < 1% - **Transactional apps**: RTT < 200 ms typically fine Match `threshold` on IP SLA to your app's real requirements — too tight = false positives; too loose = late reaction. ## Common exam / real-world mistakes 1. **Probing 8.8.8.8 and being surprised when Google has a bad minute.** Probe an FQDN you control, or use a responder at your hub. 2. **Setting probe frequency too aggressive.** 1-second probes × 50 IP SLA operations = 50 pps of extra load, and CPU cost on lower-end platforms. 3. **Track object without delay.** A flapping SLA → flapping track → HSRP flap. Use `delay down N up M` (typical: down 5, up 20-30) to smooth. 4. **Skipping the responder for jitter.** UDP jitter without a responder still runs but the timestamps aren't reliable → jitter number is garbage. 5. **Track SLA reachability vs threshold.** `reachability` = up while probes succeed. `threshold` triggers on the threshold statement in the SLA config (usually average RTT). They're not interchangeable. 6. **Not verifying with `show ip sla statistics`.** If probes aren't reporting, your track object is stuck. Check first. ## Cheat strip ``` Operations icmp-echo | tcp-connect | udp-jitter | udp-echo | http | dns | ftp Roles source (initiates) + responder (accepts, timestamps for jitter) Config shape ip sla N → operation → frequency + timeout + threshold ip sla schedule N life forever start-time now Track track N ip sla M reachability | state delay down T up T (smooth flapping) Consumers HSRP standby X track N decrement Y ip route ... track N (floating static failover) PBR: set ip next-hop verify-availability ... track N Verify show ip sla statistics N show track brief show ip sla summary ``` --- ## IP Multicast Basics — Groups, IGMP, PIM Sparse Mode, RP — https://packetmentor.com/topics/multicast-basics/ > The multicast fundamentals CCNP ENCOR expects — multicast group addresses, IGMP for host-router join, PIM Sparse Mode for router-router distribution, Rendezvous Point (RP) design, and IGMP snooping on switches. ## The one-sentence mental model **Multicast = one-to-many delivery.** Sender doesn't know or care who's listening. Anyone who wants the stream *joins the group*. The network makes copies only where needed, so N receivers on N branches only cost the source one packet at the source and copies happen at branch points. ## The address space - **Multicast group range**: `224.0.0.0/4` (`224.0.0.0` to `239.255.255.255`) - **Link-local reserved**: `224.0.0.0/24` — never forwarded off the local segment (used by OSPF `224.0.0.5/6`, HSRP `224.0.0.2`, all-hosts `224.0.0.1`) - **GLOP** / SSM: `232.0.0.0/8` — Source-Specific Multicast - **Administratively scoped**: `239.0.0.0/8` — private, don't advertise outside your admin domain Each IPv4 multicast group maps to a specific Layer-2 MAC: `01:00:5e:` + lower 23 bits of the IP group. Wide-cast: many IP groups can map to the same MAC (overlapping bit 24-25). ## The two protocols ### IGMP — Host to router IGMP (Internet Group Management Protocol) runs between hosts and their **last-hop router**. Only appears on the LAN segment where receivers live. - **IGMPv2** (most common): host sends a Report to join, Leave to leave. Router periodically sends General Queries. - **IGMPv3**: adds source-specific filtering ("I want group X, but only from source S"). Timers: router queries every 60s (default), assumes group is empty if no report for a couple of query intervals. ### PIM — Router to router PIM (Protocol Independent Multicast) builds the distribution tree between routers. "Independent" because it uses the existing unicast routing table for RPF (Reverse Path Forwarding) checks — doesn't run its own routing. Two main modes: - **PIM Dense Mode** — flood-and-prune. Assumes receivers everywhere, prunes back branches with no interest. Wasteful. Rarely used. - **PIM Sparse Mode** — assume receivers few. Explicit join required. **The default modern choice.** ### Sparse Mode + Rendezvous Point (RP) In Sparse Mode: 1. All routers pre-configured with a **Rendezvous Point (RP)** IP address. 2. Sender's first-hop router registers the source with the RP (unicast tunnel). 3. Interested last-hop routers send a *Join* toward the RP, building a shared tree (RPT / *,G tree) from RP to receivers. 4. Traffic flows from source → RP → shared tree → receivers. 5. Once traffic is flowing, last-hop routers may switch to a source-specific tree (SPT / S,G tree) — direct source-to-receiver path via SPT-switchover. ## RP configuration options - **Static RP** — every router configured with the same RP IP. Simple, no automation. `ip pim rp-address 10.0.0.1` - **Auto-RP** (Cisco proprietary) — RPs advertise themselves; a Mapping Agent elects and advertises the mapping. - **BSR** (Bootstrap Router) — IETF-standard, similar to Auto-RP but interoperable across vendors. - **Anycast RP** — same RP IP on multiple physical routers via anycast + MSDP to keep them synced. Redundant RP without failover delay. ## IGMP Snooping — the switch's job By default a switch treats multicast frames as unknown-unicast and floods them out every port in the VLAN. On a modern switch you turn on **IGMP snooping** so the switch listens to IGMP Reports and Leaves, builds a table of which ports have receivers, and forwards multicast only to those ports. ``` ! Global — on by default on modern Cat9K ip igmp snooping ! Per-VLAN ip igmp snooping vlan 10 ``` Without snooping, one IPTV stream floods to every port on the VLAN. With it, only interested clients receive. ## Sample IOS-XE config (Sparse Mode, static RP) ``` ! On every multicast router: ip multicast-routing distributed interface GigabitEthernet0/1 ip pim sparse-mode ! Same on every interface that needs to carry multicast ip pim rp-address 10.0.0.1 ``` Verify: ``` show ip mroute ! multicast routing table (*,G) and (S,G) show ip pim neighbor ! PIM adjacencies show ip pim rp mapping ! which RP is being used show ip igmp groups ! last-hop LAN joins ``` ## Common exam / real-world mistakes 1. **Forgetting `ip multicast-routing`.** Without it globally, PIM commands are accepted but nothing works. First thing to check. 2. **PIM disabled on the WAN interface between two multicast domains.** Multicast requires PIM on every hop end-to-end. 3. **Wrong RP address on some routers.** All routers must agree on RP. Static config with typos is common. 4. **Skipping IGMP snooping on the switch.** Multicast works but performance is terrible — every port floods. 5. **Blocking multicast in ACLs.** ACLs must permit the specific group addresses and the source IPs. 6. **Assuming multicast crosses NAT.** It generally doesn't — NAT devices don't handle multicast state well. Design around it. ## Common groups you'll see - `224.0.0.5` — OSPF All-SPF-Routers - `224.0.0.6` — OSPF All-DR-Routers - `224.0.0.2` — HSRP - `224.0.0.9` — RIPv2 - `224.0.0.10` — EIGRP - `224.0.0.13` — All-PIM-Routers - `239.255.255.250` — SSDP / UPnP discovery ## Cheat strip ``` Address space 224.0.0.0/4 (224-239.x) 224.0.0.0/24 = link-local, never routed 239.0.0.0/8 = admin-scoped private Host↔router IGMPv2 join/leave (or v3 with source-specific) Router↔router PIM Sparse Mode + RP RP options static | Auto-RP | BSR | Anycast RP + MSDP Trees RPT (shared, via RP) → SPT switchover (source-specific) IGMP snooping switch tracks joined ports, prevents VLAN flood Enable ip multicast-routing (global) ip pim sparse-mode (every interface) ip pim rp-address X.X.X.X (RP config) Verify show ip mroute show ip pim rp mapping show ip igmp groups ``` --- ## BGP Communities — Tags for Traffic Engineering + Well-Known Values — https://packetmentor.com/topics/bgp-communities/ > How BGP communities tag prefixes with metadata that policy uses across ASes. Standard vs extended communities, the four well-known values (no-export, no-advertise, no-export-subconfed, internet), and typical ISP tag patterns. ## The one-sentence mental model **Communities are metadata glued to prefixes.** You don't have to install a new attribute type or extend BGP — you just tag a prefix with a value that has meaning to a downstream router's policy. It's how ISPs let customers signal "prepend AS 3 times" or "don't advertise to peer X" without needing a per-customer route-map on the ISP side. ## The two flavors ### Standard community (RFC 1997) - 32 bits, usually written as `:` (e.g., `65001:100`). - Attached to any prefix in a route-map with `set community`. - Preserved across AS boundaries unless a filter strips them. ### Extended community (RFC 4360) - 64 bits, more type space, carries structured data. - **Route Target (RT)** — used in MPLS L3VPN to identify which VRF a prefix belongs in. - **Site-of-Origin (SoO)** — prevents route loops in complex multi-homed VPN sites. - Also used for encoding OSPF domain-id, link bandwidth, etc. ## The four well-known standard communities | Community | Meaning | |---|---| | **`no-export`** (0xFFFFFF01) | Do NOT advertise this prefix outside the current AS. Common when a customer says "keep this internal". | | **`no-advertise`** (0xFFFFFF02) | Do NOT advertise to ANY neighbor (iBGP or eBGP). Effectively "install locally only". | | **`no-export-subconfed`** (0xFFFFFF03) | In BGP confederations, don't advertise outside the sub-AS. Rare. | | **`internet`** (0x00000000) | Explicit "send everywhere" — the absence of a filter, formalized. | ## Setting communities By default, communities are NOT sent to iBGP peers. You must enable it per neighbor: ``` router bgp 65001 neighbor 203.0.113.1 send-community neighbor 10.10.10.2 send-community both ! send std AND extended ``` Then set a community with a route-map: ``` ip community-list 10 permit no-export ! route-map TAG-INTERNAL permit 10 set community 65001:100 no-export ! router bgp 65001 neighbor 10.10.10.2 route-map TAG-INTERNAL out ``` Prefixes advertised to `10.10.10.2` will carry community `65001:100` + `no-export`. ## Matching communities Match communities with an inbound route-map to adjust attributes: ``` ip community-list 20 permit 65001:100 ! route-map TREAT-INTERNAL permit 10 match community 20 set local-preference 200 ! route-map TREAT-INTERNAL permit 20 ! all others — normal treatment ``` Prefixes tagged with `65001:100` get elevated local-pref to 200. ## Real-world ISP community patterns Big transit providers publish community-based traffic-engineering menus. Typical patterns (each ISP has its own values, published in their community guide): | Community | Effect | |---|---| | `:100` | Don't advertise to any peer | | `:200` | Don't advertise to peer AS 1234 | | `:301` | Prepend 1x to all peers | | `:302` | Prepend 2x to all peers | | `:303` | Prepend 3x to all peers | | `:400` | Set MED = 10 to peers | | `:666` | Blackhole (RTBH) — drop this prefix at ISP edge | The blackhole community is critical for DDoS response. If your `/32` is under attack, tag it `:666` and the ISP null-routes it upstream so the pipe stays clean. ## Extended communities — Route Target for L3VPN In MPLS L3VPN, VRFs on a PE router import and export routes based on Route Targets: ``` vrf definition CUSTOMER-A rd 65001:100 address-family ipv4 route-target export 65001:100 route-target import 65001:100 ! ``` Prefixes exported from CUSTOMER-A's VRF carry `RT:65001:100`. Any PE that imports `65001:100` installs them into its matching VRF. That's how one MP-BGP session distributes routes across all customer VRFs while keeping them isolated. ## Common exam / real-world mistakes 1. **Not enabling `send-community` on the neighbor.** Default OFF. Set the community all you want — it's stripped on advertise until this is on. Bit gotcha. 2. **Forgetting `send-community both`** when the design needs extended communities (e.g., L3VPN). Standard vs extended are enabled independently. 3. **Matching by community with an ACL instead of a community-list.** Communities need `ip community-list`, not regular ACLs. 4. **Adding communities without `additive` keyword.** `set community X` REPLACES existing communities. Use `set community X additive` to append. 5. **Assuming all providers preserve communities.** Some strip customer communities at ingress. Test. ## Cheat strip ``` Standard community 32-bit tag ":" Extended community 64-bit, includes RT + SoO + more Well-known: no-export don't leave current AS no-advertise don't send to ANY peer internet explicit "send everywhere" Enable send: neighbor X send-community (standard only) neighbor X send-community both (std + ext) Set: set community X:Y [additive] (additive appends, not replaces) Match: ip community-list N permit X:Y route-map MAP → match community N ISP patterns: :100 no-peer | :301-303 prepend Nx | :666 blackhole L3VPN RT export/import in VRF config ``` --- ## BGP Route Reflectors — Scaling iBGP Beyond Full-Mesh — https://packetmentor.com/topics/bgp-route-reflectors/ > How Route Reflectors break the iBGP full-mesh requirement, letting one router re-advertise iBGP routes to clients. Cluster-id, hierarchical RRs, redundant RR design, and the loop-prevention attributes ORIGINATOR_ID and CLUSTER_LIST. ## The one-sentence mental model **iBGP is broken by default at scale.** Every internal router must talk to every other → N routers = N(N−1)/2 iBGP sessions. At 100 routers that's 4,950 sessions. **Route Reflectors** solve it: designate one (or a few) as reflectors, everyone peers only with the reflectors, RRs relay routes between clients. ## The rule that causes the pain **Split-horizon rule for iBGP:** a router that learns a route via iBGP will NOT re-advertise it to other iBGP peers. This prevents iBGP loops (there's no AS-path prepending inside an AS to detect loops via path). But it forces every iBGP router to hear every route directly from every other, which means a full mesh. ## Route Reflectors — the exception A **Route Reflector (RR)** is an iBGP router configured to violate the split-horizon rule in a controlled way. When it learns a route from an iBGP peer that is marked as a **client**, it re-advertises that route to other clients and non-client iBGP peers. Roles: - **RR (Route Reflector)** — does the re-advertisement - **Client** — an iBGP router that peers only with the RR (not with every other iBGP router) - **Non-client** — a normal iBGP router that isn't a client of this RR (typically another RR or an iBGP router in a different cluster) RR advertisement rules: - Route from **eBGP** → advertise to clients + non-clients (normal iBGP behavior) - Route from a **client** → advertise to all other clients + non-clients (this is the special reflection) - Route from a **non-client** → advertise to clients only (not to other non-clients — prevents loops) ## Config ``` router bgp 65001 neighbor 10.0.0.10 remote-as 65001 neighbor 10.0.0.10 route-reflector-client neighbor 10.0.0.11 remote-as 65001 neighbor 10.0.0.11 route-reflector-client neighbor 10.0.0.12 remote-as 65001 ! non-client (another RR) ``` Adding `route-reflector-client` under a neighbor makes that neighbor a client of this RR. Clients don't need any special config — they just peer with the RR as normal iBGP. ## Cluster-ID for redundant RRs For redundancy you deploy two RRs in the same location. Both must have the same **cluster-id** so their reflected routes are seen as coming from one logical cluster. ``` router bgp 65001 bgp cluster-id 1.1.1.1 ``` By default, cluster-id = RR's router-id. Set it explicitly when running redundant RRs so both RRs use the same cluster-id. ## Loop prevention attributes Without full-mesh's AS-path loop check, RR needs its own loop prevention: - **ORIGINATOR_ID** — the router-id of the router that first advertised the route into iBGP. If a route comes back to the originating router, it drops it. - **CLUSTER_LIST** — list of cluster-ids the route has traversed. An RR checks its own cluster-id against the list; if present, drops the route (already traversed my cluster, would loop). Both attributes are added by RRs on reflection. Non-RR routers don't touch them. ## Hierarchical RR design Big networks build **hierarchies** of RRs: - **Top-tier RRs** peer with each other in a full mesh (small set). - **Regional RRs** are clients of top-tier RRs, and have local clients under them. - **Edge routers** peer only with their regional RR. Cluster-ids are per-tier or per-region. Loop prevention still holds because CLUSTER_LIST accumulates as you go up the hierarchy. ## Alternatives to RRs - **BGP Confederations** — split the AS into sub-ASes, each running its own full-mesh iBGP, with eBGP-like peerings between sub-ASes. Less common, more complex. - **Full mesh** — still valid for < ~30 routers. ## Common exam / real-world mistakes 1. **Deploying RRs without setting cluster-id on redundant pair.** Each RR uses its own router-id as cluster-id → reflected routes look like separate clusters → loops possible during transient states. 2. **Making an RR a client of another RR.** Confusing role model — an RR should peer with other RRs as non-clients (regular iBGP), not as clients. 3. **Adding a new iBGP router but forgetting to make it a client of the RR.** New router won't get any iBGP routes; nothing looks broken until traffic patterns shift. 4. **Missing `next-hop-self` on eBGP-facing routers.** eBGP next-hops don't auto-recurse across the AS. Without `next-hop-self`, iBGP-received routes have unreachable next-hops. 5. **Confusing route-reflection direction.** Client → RR is a normal iBGP session. RR → client re-advertises reflected routes. The `route-reflector-client` command goes on the RR, not the client. ## Verifying ``` show ip bgp neighbors 10.0.0.10 ! look for "Route reflector client: Yes" show ip bgp ! look for Originator ID and Cluster list show ip bgp summary ! session count reduced vs full mesh ``` ## Cheat strip ``` Problem iBGP split-horizon → full mesh N(N-1)/2 sessions Solution Route Reflector — re-advertises routes between clients Roles RR (does reflection) | Client | Non-client Config neighbor X route-reflector-client (on the RR) Cluster bgp cluster-id X.X.X.X (same on redundant RR pair) Loop prevent ORIGINATOR_ID + CLUSTER_LIST attributes RR drops routes whose CLUSTER_LIST includes its cluster-id Design Simple: single RR pair per site Hierarchical: top-tier RRs + regional RRs + edge clients Alternative Confederations (rare) Gotcha remember next-hop-self on eBGP borders redundant RRs need same cluster-id ``` --- ## Cisco Zone-Based Firewall (ZBFW) — Zones, Zone-Pairs, Policy-Maps — https://packetmentor.com/topics/zone-based-firewall/ > How Cisco's Zone-Based Firewall models a router as a set of security zones with policy-maps controlling traffic between them. Zone-pairs, class-based policy, the self zone, and typical enterprise deployments. ## The one-sentence mental model **ZBFW turns a Cisco router into a stateful firewall by grouping interfaces into zones and writing rules for zone-to-zone traffic flows.** Instead of "ACL on interface X inbound", you say "traffic from the INSIDE zone to the OUTSIDE zone matches this class; do this action." One policy per direction per zone-pair. ## The pieces ### Zone A logical group of interfaces sharing the same security profile. Common zones: - **INSIDE** — trusted LAN interfaces - **OUTSIDE** — untrusted internet-facing interfaces - **DMZ** — semi-trusted, publicly-reachable servers - **VPN** — remote-access VPN termination - **SELF** — implicit zone that includes the router's own IP addresses. Always present. Every interface must belong to exactly one zone. An unassigned interface is treated as if in no zone, and by default, traffic to/from it is denied. ### Zone-pair A directional relationship — traffic from zone A to zone B. Policy is applied to the pair. `INSIDE → OUTSIDE` is one zone-pair; `OUTSIDE → INSIDE` is a different one. Traffic between interfaces in the *same* zone is permitted by default (no zone-pair needed). Traffic between two zones with no zone-pair is denied by default. ### Class-map Identifies traffic — `inspect` type class-maps (specific to ZBFW): ``` class-map type inspect match-any WEB-TRAFFIC match protocol http match protocol https match protocol dns ``` ### Policy-map Applies an action to matched traffic: ``` policy-map type inspect INSIDE-TO-OUTSIDE class type inspect WEB-TRAFFIC inspect class type inspect INSIDE-TO-OUTSIDE-DENY drop log class class-default drop ``` Actions: - **inspect** — stateful; automatically permits return traffic - **pass** — stateless permit; doesn't track state (used for asymmetric flows or when explicit inspection is unwanted) - **drop** — deny - **log** — modifier on drop for logging ### Zone-pair binding ``` zone-pair security IN-TO-OUT source INSIDE destination OUTSIDE service-policy type inspect INSIDE-TO-OUTSIDE ``` Traffic ingressing from an INSIDE-zone interface heading to an OUTSIDE-zone interface hits this policy. ## Interface assignment ``` zone security INSIDE zone security OUTSIDE interface GigabitEthernet0/1 zone-member security INSIDE interface GigabitEthernet0/2 zone-member security OUTSIDE ``` ## The self zone `self` is the implicit zone representing the router itself. Traffic destined to a router IP or generated by the router hits the self zone. By default, traffic from *any* zone to `self` is permitted, and `self` to any zone is permitted. This is a design choice so you don't lock yourself out during config. But it's also a security hole. For a hardened box, add explicit zone-pairs to `self`: ``` class-map type inspect match-any MGMT-ALLOWED match protocol ssh match protocol snmp policy-map type inspect FROM-INSIDE-TO-SELF class type inspect MGMT-ALLOWED inspect class class-default drop zone-pair security INSIDE-TO-SELF source INSIDE destination self service-policy type inspect FROM-INSIDE-TO-SELF ``` Now only SSH and SNMP from INSIDE reach the router itself. Everything else drops. ## Typical enterprise pattern Three zones: INSIDE, OUTSIDE, DMZ. Zone-pairs: - **INSIDE → OUTSIDE** — inspect (allow LAN to internet, stateful, return traffic auto-permitted) - **DMZ → OUTSIDE** — inspect (allow servers to update, reach out for external APIs) - **OUTSIDE → DMZ** — inspect only specific services (HTTP/HTTPS to web server, DNS to DNS server) - **INSIDE → DMZ** — inspect (users reach servers) - **DMZ → INSIDE** — usually drop (no reason for DMZ to initiate to LAN) - **OUTSIDE → INSIDE** — drop (inbound blocked by default, no zone-pair needed) ## Common exam / real-world mistakes 1. **Forgetting to assign every interface to a zone.** Unassigned interfaces can't send or receive across zones. Common cause of "why is my WAN not working after ZBFW". 2. **Missing the return-path zone-pair.** ZBFW is stateful with `inspect` — return traffic is auto-permitted. But if you `pass` instead of `inspect`, you need explicit both-direction zone-pairs. 3. **Locking yourself out via `self` zone.** If you configure a zone-pair to `self` and get the classification wrong, SSH stops working. Test out-of-band access before applying. 4. **Overlapping class-maps.** Class-maps in a policy-map are top-down, first match wins. Order matters. 5. **Assuming ZBFW replaces ACLs.** Interface ACLs still work below ZBFW. Both are evaluated. Use one or the other consistently. 6. **Turning on ZBFW without a change window.** Any misconfiguration = production outage. Always deploy with a rollback plan. ## Verifying ``` show zone security ! zones and their interfaces show zone-pair security ! zone-pairs and their policies show policy-map type inspect zone-pair ! runtime hit counters per class show policy-firewall sessions ! active stateful sessions ``` ## Cheat strip ``` Model zones (groups of interfaces) + zone-pairs (directional rules) Default same-zone traffic ALLOWED different-zone traffic DENIED (until zone-pair permits) Special self zone = the router itself (SSH/SNMP/routing) Config flow class-map inspect → policy-map inspect → zone-pair → apply Actions inspect (stateful, returns permitted) | pass | drop | log Typical zones INSIDE | OUTSIDE | DMZ | VPN | self Verify show zone security show zone-pair security show policy-firewall sessions ``` --- # Blog posts 32 blog posts, newest first. --- ## CCNA Labs on Chromebook, Mac, or iPad — No Downloads, Browser Only (2026) — https://packetmentor.com/blog/ccna-labs-chromebook-mac-ipad-browser/ > Every mainstream CCNA lab tool assumes you have a Windows PC. You don't. Here's how to run real Cisco IOS + Palo Alto + WLC labs from a Chromebook, MacBook, or iPad — no VM, no download, no Packet Tracer install. *Published 2026-09-14.* Every CCNA study guide assumes you'll install Packet Tracer, download GNS3, or spin up a Cisco Modeling Labs VM. Every one of those assumes you have a Windows PC with 16 GB of RAM and admin rights. If you're on a **Chromebook** (dominant in US education, no Windows apps), a **Mac** (Packet Tracer works but half the guides don't), or an **iPad** (no VM support at all), you've probably given up on hands-on practice and are relying on YouTube walkthroughs. That is not enough to pass the CCNA — and it is *definitely* not enough to survive the first-day-on-the-job "here's a Catalyst 9300, configure VLANs" moment. Good news: in 2026 you don't need any of that. **Every hands-on skill on the CCNA blueprint can be practiced in a browser tab, on any device.** Here's how. ## TL;DR — three tools, no downloads - **Cisco IOS CLI practice**: [packetmentor.com/exam/labs/console/](/exam/labs/console/) — full IOS CLI in a browser tab. Real command parser, real `show run`, real `configure terminal` mode. Runs on Chromebook, iPad, phone. - **Wireless LAN Controller (Cat 9800 IOS-XE)**: [packetmentor.com/exam/labs/wlc-console/](/exam/labs/wlc-console/) — same idea, WLC syntax. - **Palo Alto PAN-OS**: [packetmentor.com/exam/labs/pa-console/](/exam/labs/pa-console/) — the security-side equivalent for anyone crossing into firewall administration. That covers ~90% of the CLI work you need for CCNA hands-on preparation. For the remaining 10% (topology-building, packet visualization), the alternatives are covered below. ## Why the traditional tools don't work on non-Windows devices **Cisco Packet Tracer** — the officially-blessed CCNA lab tool, distributed via Cisco NetAcad. It has: - A Windows installer (works on Windows 10/11) - A macOS installer (works on Intel + Apple Silicon, but the last few versions have had signing issues that require security-override tricks) - A Linux .deb (works on Ubuntu; broken on Fedora / Arch until you install a compatibility library) - **No ChromeOS support at all** (won't run in the Linux-on-ChromeOS crostini VM either — GUI issues) - **No iOS / iPadOS support** (Apple doesn't allow full IOS-emulation apps in the App Store) **GNS3** — full IOS emulation via real Cisco IOS images. Requires: - A dedicated Windows/Linux machine or a VM - 16 GB RAM minimum for anything beyond a 2-router lab - Legally-obtained Cisco IOS images (you need a support contract or you're pirating) **Cisco Modeling Labs (CML)** — the modern replacement for GNS3. Requires: - A Linux server with 16-32 GB RAM - A $199/year personal license - Reasonable network to your server None of these work on a $300 Chromebook or a 5th-gen iPad. That's the entire problem this post exists to solve. ## Option 1 — Browser-based CLI (fastest, works on everything) Go to [packetmentor.com/exam/labs/console/](/exam/labs/console/) on any device. You get: - A terminal that behaves like a Cisco router or switch - Real IOS command parsing (not a script — actual multi-word parser with prefix-matching, mode transitions, sub-modes for interfaces / ACLs / OSPF / MQC / AAA / etc) - Persistent `running-config` you can view, edit, and copy to `startup-config` - Mode-aware prompt (`Router>` → `Router#` → `Router(config)#` → `Router(config-if)#`) - Every CCNA-blueprint command family: interfaces, VLANs, trunks, STP, OSPF, EIGRP, static routes, ACLs, NAT, HSRP/VRRP, DHCP, SSH/AAA, port security, DHCP snooping, and more. **What you can practice**: interface config, VLAN setup, VLAN trunking, inter-VLAN routing (SVI-based), OSPF single-area + multi-area, EIGRP, static routing, standard + extended + named ACLs, NAT/PAT, HSRP failover behavior, port-security violation modes, SPAN monitor sessions, MAC address table lookups, DHCP pool config, AAA method lists — the full CCNA CLI blueprint. **What you can't practice** (yet): multi-device physical topology visualisation. If you need to see a diagram of two routers with a link between them and packet animation, use [our simulators](/simulators/) — separate tool, browser-based, covers OSPF, STP, VLAN/trunk, NAT, HSRP, DHCP DORA, IPv6 SLAAC and more. **Runs on**: Chromebook (any generation), Mac (Safari, Chrome, Firefox), Windows, iPad, iPhone, Android tablet. The one requirement is a modern browser (anything from the last 3 years). ## Option 2 — Simulators for visual + interactive concepts Some CCNA topics are hard to grasp without watching them happen. For those, [/simulators/](/simulators/) gives you interactive click-through visualizations: - **[Subnetting drill](/simulators/subnetting/)** — random /X mask problems with instant grading. Best subnetting practice tool in the browser, period. - **[OSPF adjacency](/simulators/ospf/)** — watch DR/BDR election and LSA flooding. - **[STP root election](/simulators/spanning-tree/)** — see how priority + MAC-address tiebreakers pick a root. - **[VLAN trunk](/simulators/vlan-trunk/)** — 802.1Q tag insertion and native-VLAN handling animated. - **[NAT flow](/simulators/nat/)** — inside local / inside global address translation. - **[HSRP failover](/simulators/hsrp/)** — kill an active router, watch standby take over. - **[DHCP DORA](/simulators/dhcp-dora/)** — the 4-message DHCP handshake stepped through. - **[IPv6 SLAAC](/simulators/ipv6-slaac/)** — Router Advertisement and address auto-generation. - **[EtherChannel LACP](/simulators/etherchannel/)** — bundle negotiation. None require downloads. All work on Chromebook, iPad, phone. ## Option 3 — When you actually do need Packet Tracer Some CCNA labs (a small number) genuinely benefit from physical-topology drag-and-drop that Packet Tracer excels at. Here's the plausible-workaround stack for each device family: ### On a Chromebook (education-grade, no Linux crostini) You genuinely can't run Packet Tracer. Your options: - **Cisco NetAcad Skills Assessment** in a browser — some CCNA lab exercises are offered as web-hosted labs (no local install). Log into netacad.com to see what's available for your course cohort. - **Cisco Modeling Labs Sandbox** — if you can afford $199/yr for the personal license, CML runs in the cloud and is accessible from any browser. It's real IOS-XE, not simulation. - **Otherwise**: browser-based tools cover the practical CCNA CLI blueprint. Move on. ### On a Chromebook (with Linux crostini enabled) If your Chromebook supports Linux apps (most 2018+ models): - Install the Linux `.deb` version of Packet Tracer via `sudo dpkg -i PacketTracer_822_amd64.deb`. - Success rate: 60-70%. Graphics quirks are common. Not officially supported. ### On a Mac (Intel or Apple Silicon) - Packet Tracer works. Cisco publishes an official macOS installer. - Occasional signing issues — if you get "app can't be opened", go to System Settings → Privacy & Security → Open Anyway. - Apple Silicon (M1/M2/M3/M4) support is native as of 2024 — no Rosetta needed. ### On an iPad or iPhone - No Packet Tracer, no VM, no way around it. Apple restrictions. - Use browser-based tools (options 1 + 2 above) or SSH into a remote CML instance. ## Common mistakes 1. **Assuming you need real hardware to pass the CCNA.** You don't. Cisco's own certification blueprint is fully coverable by Packet Tracer + browser-based CLI. Real hardware is a nice-to-have for signalling to employers (see resume advice), not a requirement to pass the exam. 2. **Paying for third-party lab platforms that just wrap the free tools.** Some sites charge $30/mo for what is essentially a re-skinned Packet Tracer + a curated exercise list. The exercises are useful; you can get the same via free CCNA lab guides. 3. **Trying to run Packet Tracer in a Chromebook web browser** (there is no web version of Packet Tracer). If you searched "Packet Tracer online" and landed on a random site claiming to run it in-browser, close the tab — those are either GNS3 wrappers behind login walls or straight-up malware. 4. **Skipping hands-on practice because "my laptop can't run it".** This is the single biggest reason people fail the CCNA on the first attempt. The exam has simulation questions where you must type real IOS commands with no undo. Passing those requires reflexive CLI muscle memory, which you cannot get from YouTube. Browser-based CLI practice is enough. 5. **Practicing only in one tool.** Your interview will not be in Packet Tracer. Practice the CLI in the browser (mode transitions, prefix-match, tab-completion), practice topology + traffic flow in the simulators, and if you can, get 20 minutes on real hardware or CML before the exam. ## Frequently asked questions **Q: Can I really pass the CCNA using only browser-based labs?** A: Yes — the CCNA blueprint tests knowledge of Cisco IOS syntax and network concepts, both of which are fully covered by browser-based CLI + interactive simulators. The Cisco exam simulation questions are more forgiving than most people expect; if you know the commands, you can enter them. Every one of our students who's passed on the first try used browser-based practice as their primary lab environment. **Q: What's the difference between Packet Tracer and a browser-based CLI?** A: Packet Tracer is a full topology simulator — you drag routers and switches into a canvas, wire them up, and configure each one. Browser-based CLI focuses on the command-line experience of a single device at a time. For learning IOS syntax and mode transitions (which is 80% of CCNA hands-on), browser CLI is faster and more focused. For understanding how packets flow across a multi-device topology, simulators + Packet Tracer are complementary. **Q: Does browser-based CLI count as "real experience" on a resume?** A: Not by itself. On a resume, "built a home lab with 2 x Catalyst 2960 + ISR 2911" carries more weight than "practiced on packetmentor.com". But: browser CLI practice IS what makes you interview-ready to speak fluently about IOS commands, and that shows up in every technical screen. Combine both — use browser tools for daily reps, invest in cheap used hardware for the resume signal. **Q: Will my Chromebook / iPad / iPhone handle a full CCNA study session?** A: Yes. The browser-based tools are lightweight — they'll run on a 5-year-old Chromebook or a 3rd-gen iPad. If your device can load YouTube, it can run the CLI. Battery drain during a 2-hour lab session is negligible. **Q: What about CCNP or CCIE prep?** A: Browser tools cover CCNA blueprint depth. For CCNP concentration exams (Enterprise, Security, DevNet, etc), you'll need Cisco Modeling Labs or a real gear investment — the topology complexity and vendor feature breadth outgrow browser simulation. But for CCNA specifically, browser is genuinely enough. ## Where to go from here If you've been putting off CCNA study because you don't have a Windows machine, that objection is officially retired. Two next steps: - **Try the [Live Lab Console](/exam/labs/console/) right now** — takes 5 seconds. Configure a VLAN, set an IP on an SVI, ping between two subnets. See how far you get without a manual. - **Pair it with the [Subnetting drill](/simulators/subnetting/)** — 10 random problems a day for two weeks and subnetting stops being a bottleneck. For the bigger picture: our full [topic library](/topics/) is 129 pages of Cisco networking content, all readable on any device, all with hands-on lab pointers to the browser tools above. If you want a 1:1 mentor to walk you through your first month of CCNA study on a Chromebook, [book a free 20-minute planning call](/contact/) — the first session is a working session, not a sales pitch. Hardware access is no longer the excuse. The browser is a full lab now. --- ## NOC Engineer Resume + Interview — How to Land Your First US Networking Job in 2026 — https://packetmentor.com/blog/noc-engineer-resume-first-job/ > The exact resume format, 12 must-list skills, and the whiteboard questions US hiring managers actually ask a NOC / Tier-1 network engineer candidate. Written for CCNA-fresh, career-transitioning applicants. *Published 2026-09-14.* Passing the CCNA gets you the certificate. It does not, on its own, get you a job. Every week we talk to freshly-certified engineers who send out fifty resumes and hear back on none of them — not because they lack skills, but because the resume never reaches a human, and the ones that do read like a re-word of the CCNA blueprint. This guide is the exact template we walk our mentorship students through — the resume format that survives US ATS filters, the twelve skills to actually list, and the four whiteboard questions you will be asked in a NOC / Tier-1 network engineer interview in 2026. Written for the person applying with a CCNA and a helpdesk or lab background — not someone with 10 years of experience. ## TL;DR — the resume in one paragraph **One page, chronological, plain black-on-white PDF. Header: name + city + LinkedIn + GitHub if you have real network scripts on it. Summary: three lines naming the role you want ("Network Operations Engineer"), your cert, and one number. Then Skills (12 items, no more). Then Experience (results, not duties). Then Certifications + Education. That's the whole resume — and it works because 80% of the resumes it competes with are 2-3 pages of generic bullet lists that no one reads.** ## What actually happens to your resume in 2026 Before a human sees anything, your resume goes through an **Applicant Tracking System** (ATS) — Workday, Greenhouse, Lever, iCIMS. The ATS parses your PDF into fields, looks for keywords matching the job description, and ranks you against every other applicant. If your rank is below the top ~15, no human reads it. This is why every generic "put your objective at the top!" resume advice fails in 2026 — objectives don't contain keywords, and they push the actually-scannable content off the first screen. The rules that work in 2026: - **PDF, not DOCX.** Some ATS mangle DOCX formatting. PDF is stable. - **Plain fonts** (Arial, Calibri, Helvetica). No columns, no photos, no icons, no coloured headers, no graphics. All of those confuse ATS parsers. - **Section headers ATS knows**: "Summary", "Skills", "Experience", "Certifications", "Education". Not "About Me" or "What I Bring" or "My Journey." - **File name**: `--Network-Engineer.pdf`. Not `resume-final-v3-updated.pdf`. - **Length**: one page for < 5 years of experience. Two pages only if you have significant enterprise experience. Never three. ## The 12 skills to list (and none extra) Every job description for a NOC or junior network engineer role in 2026 lists between 8-15 required skills. Your Skills section should mirror those keywords closely — not because you're stuffing, but because the ATS is doing keyword matching. **Core (list all 8 — these appear in >90% of NOC job descriptions):** 1. Cisco IOS / IOS-XE CLI 2. Routing (OSPF, EIGRP, static) 3. Switching (VLANs, STP, trunking, EtherChannel) 4. TCP/IP + subnetting 5. ACLs + basic firewall concepts 6. DHCP, DNS, NTP, SNMP 7. Wireshark / packet capture analysis 8. Ticketing systems (ServiceNow, Jira, Remedy) **Differentiators (pick 4 that are actually true — do not list what you cannot defend):** 9. Python for network automation (mention Netmiko or Nornir if you've used them) 10. Ansible for network config (mention specific playbooks you wrote) 11. Cloud networking (AWS VPC, Azure VNet — if you've built one) 12. Palo Alto / Fortinet firewall (if you've touched one) **Skills to NOT list unless you have real experience:** - BGP (too advanced for NOC / Tier-1; listing it invites interview questions you can't answer) - Kubernetes / Docker networking (unless you know it well; recruiters filter on it and interview on it) - SD-WAN (rarely a Tier-1 responsibility) ## The experience section — results, not duties The single biggest mistake we see: bullets that describe **what the role was**, not **what you accomplished in it**. Compare: **Bad (duty-based):** ``` Helpdesk Technician — TechCorp — 2023-2026 • Provided phone and email support to end users • Escalated network issues to the network team • Reset passwords and unlocked accounts ``` **Good (results-based, same job):** ``` Helpdesk Technician — TechCorp — 2023-2026 • Resolved 800+ tier-1 tickets/quarter across 400 users; 92% first-call resolution • Reduced VPN-related tickets 40% by writing a self-service password-reset runbook • Diagnosed and escalated 60+ network-side issues (VLAN mismatches, DHCP scope exhaustion, WAN latency) with clear repro steps — network team feedback: "the tickets we actually want to receive" • Built a personal home lab: 2 x Catalyst 2960, 1 x ISR 2911, OSPF + VLANs + inter-VLAN routing across 4 subnets; documented on GitHub ``` Same job. Second version demonstrates: you actually understand networks, you produce measurable outcomes, and you took initiative to learn beyond your role. That's what hiring managers scan for. **The home-lab bullet is disproportionately powerful.** For someone with no formal network experience, a documented home lab (photos, GitHub repo, a blog post walking through your OSPF adjacency debugging) proves you can actually do the work. Two Catalyst 2960s off eBay + a used ISR 2911 = under $200. Well worth it for the resume signal. ## The four whiteboard questions US interviewers actually ask In 2026, hiring for NOC / junior network engineer roles almost always includes a live technical screen. Sometimes it's a phone screen with a shared whiteboard, sometimes it's on-site. Four questions come up in nearly every one: ### 1. "Walk me through what happens when a laptop plugs into an office network and browses to google.com." This is the classic layer-by-layer walkthrough. Interviewers want to hear: - **Layer 1/2**: link comes up, LLDP/CDP negotiation, DHCP DISCOVER, DHCP OFFER (from server via `ip helper-address` if in a different subnet), DHCP REQUEST, DHCP ACK — laptop now has IP, mask, gateway, DNS - **Layer 3**: laptop needs google.com — DNS query to configured resolver, gets back an A record (say 142.250.80.46), decides "not on my subnet" via subnet mask math → forwards to default gateway - **Layer 4/7**: TCP three-way handshake to 142.250.80.46:443, then TLS handshake, then HTTP request, then response If you can walk through all of that without prompting, you are already in the top 20% of candidates. Practice it out loud. Look at our [OSI Model + TCP/IP](/topics/osi-tcp-ip/) topic if you want the layer breakdown as a reference. ### 2. "The user's PC won't get an IP. Walk me through your troubleshooting." Structured answer: - **Layer 1**: link light on? cable seated? switchport up? `show interfaces` — errors, drops, half-duplex? - **Layer 2**: right VLAN? `show mac address-table interface Gi0/1` — is the PC's MAC learned? `show vlan brief` — does the access VLAN exist? - **Layer 3**: is the DHCP relay (`ip helper-address`) configured on the SVI? Is the scope on the DHCP server exhausted? APIPA (`169.254.x.x`) confirms DHCP is failing. - **DHCP snooping**: is the port trusted (if snooping is enabled)? The answer they want is a **methodology**, not a specific fix. "I'd start at Layer 1 and work up" is the right vocabulary. See [DHCP explained: DORA + relay](/blog/dhcp-explained-dora-and-relay/) if you want to drill this. ### 3. "What's the difference between a collision domain and a broadcast domain?" Every senior interviewer asks this because the wrong answer signals fundamental confusion. - **Collision domain**: the segment where two devices' frames can physically collide. Every switchport is its own collision domain (modern switches → each port full-duplex, no collisions). Hubs (rare now) put everyone in one big collision domain. - **Broadcast domain**: the scope of a broadcast frame. Every VLAN is a broadcast domain. A router (or SVI on a Layer-3 switch) is what separates broadcast domains. Bonus: "So how many collision domains does a 48-port switch have? 48. How many broadcast domains? One — unless VLANs are configured, in which case one per VLAN." ### 4. "Draw me a small network with two VLANs and inter-VLAN routing." They hand you a whiteboard marker. You draw: - Two access switches, each with 2 ports in VLAN 10, 2 ports in VLAN 20 - A Layer 3 switch or router in the middle - Trunk links between access switches and the L3 device (802.1Q tagged) - SVI 10 (192.168.10.1/24) and SVI 20 (192.168.20.1/24) on the L3 switch - Explain: PC in VLAN 10 sends to a PC in VLAN 20 → frame hits access switch → tagged, sent up the trunk → L3 switch strips tag, routes between SVIs, re-tags → down trunk to destination access switch → to destination PC If you can draw this in under 3 minutes with clean labels, you're in. Practice on paper until you can do it without hesitation. See [Inter-VLAN routing: SVI vs Router-on-a-Stick](/blog/inter-vlan-routing-svi-vs-router-on-a-stick/) for the diagram + IOS config. ## Common mistakes 1. **Applying to "network engineer" roles that require 5+ years experience.** Filter aggressively. Look for "Network Operations", "NOC", "Junior Network", "Network Support", "Tier 1 Network". These are the entry-level roles that hire CCNA-fresh candidates. 2. **Sending the same resume to every job.** Tailor the Skills section to match each job description's keywords. This is a 5-minute edit per application and it dramatically improves your ATS ranking. 3. **Objective statements in 2026.** Dead. Replace with a three-line Summary that names the specific role, your certification, and one credible metric ("Passed CCNA 200-301 with 890/1000, home lab with OSPF + STP + inter-VLAN routing"). 4. **Listing every network protocol you've heard of.** Interviewers ask about anything you list. If your Skills section says "BGP, MPLS, SD-WAN, Segment Routing" and you can't defend it, you look worse than if you'd left them off entirely. 5. **No home lab evidence.** If you have zero real network experience, you need PROOF that you've actually configured something. A photo of your rack + a GitHub repo with your configs + one blog post explaining a lab you built = the difference between "another CCNA holder" and "someone who actually does this." 6. **Not applying on LinkedIn AND directly on the company career page.** Half of jobs are filled through LinkedIn referrals; the other half through direct applications. Doing both doubles your reach. 7. **Ghosting the recruiter after the phone screen.** Send a thank-you email within 24 hours. Include one specific thing you discussed and one thing you looked up afterward ("I looked into VXLAN after our chat — I can see why the campus fabric team relies on it"). This alone puts you in the top 5% of candidates for cultural signal. ## Frequently asked questions **Q: How long should the resume be for an entry-level networking job?** A: One page. Every time. Even if you have multiple certs and a home lab and prior helpdesk experience — one page. Two pages is only for candidates with 5+ years of actual network engineering. Recruiters spend 6-8 seconds on the first scan; a one-page resume forces the important stuff onto that first screen. **Q: Do I need a college degree to get a NOC job?** A: Not always — depends on the employer. Cisco partners and MSPs frequently hire on certifications + demonstrated skill without a degree. Fortune 500 IT departments and federal roles typically require a bachelor's. A CCNA + associate's degree from a community college is a common winning combination for MSP + NOC roles. **Q: What's the realistic starting salary for a NOC engineer in the US in 2026?** A: $55,000–$75,000 for Tier-1 NOC in most US metros; $65,000–$85,000 in high cost-of-living metros (SF Bay, NYC, DC, Boston, Seattle). Federal roles and defence contractors run slightly higher on total comp when you include benefits + retirement. Don't accept < $55K for a full-time NOC role in the US in 2026. **Q: Should I take an unpaid internship to break in?** A: In 2026 — no. Every US employer needs Tier-1 network staff, and demand exceeds supply. There is a paid NOC job for you if you keep applying. Unpaid work is only justified for a very specific, highly desirable brand-name company where the reference alone changes your trajectory. **Q: How many jobs should I apply to before expecting an interview?** A: Realistic ratio in the current US market: 50 applications → 5 phone screens → 2 on-sites → 1 offer. If you're getting fewer than 5 phone screens per 50 apps, the resume is the problem (not the market). If you're getting phone screens but no on-sites, the interview prep is the problem. **Q: Is remote work realistic for a NOC role?** A: Some yes, most no. Fully-remote NOC roles exist (usually Tier-2+, monitoring-only positions with no hands-on work). Most Tier-1 NOC is hybrid (2-3 days on-site) because rack access, cable work, and console troubleshooting still need physical presence. Set expectations accordingly. ## Where to go from here If you're on the CCNA path and thinking about the job side already, that's the right instinct — every senior engineer says they wish they'd started the job hunt earlier. Two adjacent things worth reading: - **[CCNA for US veterans](/ccna-for-veterans/)**, **[CCNA for US help desk workers](/ccna-for-help-desk/)**, **[CCNA for US MSP engineers](/ccna-for-msp-engineers/)** — persona-specific job-transition guides. - **[US Network Engineer Interview Sprint](/training/interview-sprint/)** — our 2-week program specifically for the resume + LinkedIn + mock interview trio described above. Cheaper than one recruiter's finder's fee. The single best thing you can do this week: pick one company you want to work for, look up their NOC job description, and rewrite your Skills section to mirror its keywords. That one edit, done well, moves your ATS ranking more than any other single change. Want a mentor to critique your resume and run a mock whiteboard session before your next interview? [Book a free 20-minute planning call](/contact/) — no card upfront, first session is a real working session not a sales pitch. --- ## Cisco Router Password Recovery — 2026 Step-by-Step (ISR + Catalyst + IOS-XE) — https://packetmentor.com/blog/password-recovery-cisco-router/ > You forgot the enable password on a Cisco router or switch. Nine-step recovery using the console + ROMMON — works on ISR G2, ISR 4000, Catalyst 9200/9300, and IOS-XE. Includes the two commands most tutorials skip. *Published 2026-09-14.* You just inherited a Cisco router that nobody has the password for. Or the last engineer left the company. Or the lab kit you bought on eBay came with a config you can't get into. Whatever the reason: **the enable password is gone, and your only route in is through the console port and the ROM Monitor.** This guide walks the recovery step-by-step for the three device families you'll actually see in a US networking career: - **Cisco ISR routers** (ISR G2 like 2911, ISR 4000 like 4321) — the console + config-register method. - **Catalyst 9200 / 9300 switches** — the button-hold + `flash_init` method (different from routers because switches don't have a config-register). - **IOS-XE devices generally** — same principles, small differences noted. You need three things: physical console access, a serial cable (USB-to-RJ45 rollover for older gear, USB-to-USB-C on 9200/9300), and about 15 minutes. > **Legal + safety note:** only do this on equipment you own or are authorised to reset. Password recovery is an intentional Cisco feature but doing it on someone else's kit without permission is unauthorised access. If you're an employee and there's ANY doubt, get written authorisation first. ## TL;DR — the router recovery in nine steps 1. Console in at **9600 8-N-1**. 2. **Power-cycle** the device. 3. During boot (first ~60 seconds), press **Ctrl+Break** to drop into ROMMON. 4. At `rommon 1>`, type `confreg 0x2142` — tells the router to skip loading the saved config on next boot. 5. Type `reset` — the router reboots. 6. It boots WITHOUT the startup config (so no password). Type `no` to skip initial setup dialog. 7. `enable` — no password required, you're straight in. 8. `copy startup-config running-config` — pull the old config into memory so you keep VLANs, interface configs, etc. 9. `configure terminal`, then `enable secret `, then `config-register 0x2102` (restores normal boot), then `end`, then `write memory`. Reboot. Done. Old config is preserved, new password works. ## Step 1 — Console cable + terminal settings Every recovery starts here. If you can't see console output, nothing else works. - **Older ISR routers (2911, 3925, etc.)** — RJ45 console port, use a USB-to-RJ45 rollover cable. Any $10 Chinese clone from Amazon works. - **ISR 4000 series + Catalyst 9200/9300** — USB Mini-B or USB-C console port. Standard USB cable, no rollover needed. - **Terminal software**: PuTTY (Windows), Screen or Minicom (Linux), Terminal + `screen` (Mac). On Windows, first install the Cisco USB console driver (Silicon Labs CP210x or similar). - **Settings**: 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. That's the universal default and it hasn't changed since the 1990s. If you see gibberish, you're at the wrong baud rate. If you see nothing, either the cable is dead or you're on the wrong COM port. ## Step 2 — Break into ROMMON (routers) Power-cycle the router. Watch the boot messages. Within about 60 seconds of the initial boot messages, you need to send a Break signal: - **PuTTY**: Menu → Special Command → Break. - **Screen (Mac/Linux)**: `Ctrl+A` then `Ctrl+B`. - **Minicom**: `Ctrl+A` then `F`. If timed correctly, the router stops and shows: ``` rommon 1> ``` That's the ROM Monitor. It's a tiny bootloader with its own command set — enough to load IOS from Flash, change the config-register, and reset the box. Not enough for anything else. **If you miss the window**, power-cycle and try again. The break has to hit during a specific phase of boot. Newer devices give you a shorter window (~10–15 seconds), so be ready. ## Step 3 — Change the config-register to 0x2142 At the `rommon` prompt: ``` rommon 1> confreg 0x2142 rommon 2> reset ``` `0x2142` tells the router: on next boot, **skip loading startup-config from NVRAM**. It boots with a blank running-config — which means no `enable secret`, no `line vty` password, no console password. You're in. The router reboots and eventually shows: ``` --- System Configuration Dialog --- Would you like to enter the initial configuration dialog? [yes/no]: no Router> Router> enable Router# ``` No password. You're in privileged EXEC. ## Step 4 — Load the old config and reset the password Critical detail most tutorials skip: at this point the router is running BLANK config. If you just start typing new commands, you'll lose every VLAN, every interface config, every route the previous engineer set up. **You need to load the startup-config into memory first, then reset the password.** ``` Router# copy startup-config running-config ``` Answer `yes` to the confirmation. All the previous config loads. Interfaces might come up in shutdown state (which is fine — leave them; you'll `no shutdown` if needed). Passwords are all back to what they were — but you're already in privileged mode, so they don't lock you out. Now change the enable secret: ``` Router# configure terminal Router(config)# enable secret MyNewSecureP@ssw0rd Router(config)# service password-encryption ``` If there was also a console or VTY password, change those too: ``` Router(config)# line console 0 Router(config-line)# password MyConsoleP@ss Router(config-line)# login Router(config-line)# exit Router(config)# line vty 0 4 Router(config-line)# password MyVtyP@ss Router(config-line)# login ``` Or better, migrate VTY to SSH with local users: ``` Router(config)# username admin secret MyLocalP@ss Router(config)# line vty 0 4 Router(config-line)# login local Router(config-line)# transport input ssh ``` ## Step 5 — Restore the config-register (this step is the one people forget) If you skip this step, the router will boot bypassing startup-config every time it reboots — which means every power cycle wipes your work. ``` Router(config)# config-register 0x2102 Router(config)# end Router# write memory ``` `0x2102` is the normal boot config-register. `write memory` saves running-config to startup-config. Verify: ``` Router# show version | include register Configuration register is 0x2142 (will be 0x2102 at next reload) ``` If it says `0x2102` in both places, you're good. Reboot to confirm — after the reboot, the old configuration should be intact but with your new passwords. ## Catalyst 9200 / 9300 switch recovery — different procedure Switches don't have a config-register. The recovery uses the **MODE button** on the front panel and the switch's boot loader: 1. Power off the switch. 2. Hold the **MODE button** while powering it on. 3. Keep holding until the SYST LED starts flashing green (usually ~15 seconds after power-on). 4. Release. You'll see boot loader output on the console: ``` switch: ``` 5. Initialize flash: ``` switch: flash_init ``` 6. Rename the config file so the switch can't load it: ``` switch: rename flash:config.text flash:config.text.old switch: boot ``` 7. The switch boots without the old config. Type `no` to skip initial setup. 8. Copy the old config back and reset passwords (same as router steps above): ``` Switch> enable Switch# rename flash:config.text.old flash:config.text Switch# copy flash:config.text running-config Switch# configure terminal Switch(config)# enable secret MyNewP@ss Switch(config)# end Switch# write memory ``` No config-register restoration needed on switches — the recovery is essentially "hide the config file, boot, restore it, change password." ## Common mistakes 1. **Trying to `factory reset` a device you actually just want the password reset on.** Factory reset wipes everything (configs, users, certificates, licenses). Password recovery preserves it all. Two very different operations. 2. **Setting config-register 0x2142 and never changing it back.** The device now boots without config on every reload — including power outages. You lose reachability every time the box reboots and don't understand why. Always `config-register 0x2102` + `write memory` at the end. 3. **Skipping `copy startup-config running-config` before changing the password.** You reset the enable secret to something you know, save it, and reboot to find the router has no interface IPs, no OSPF, no VLANs. Because you saved a blank config over the previous one. The old configuration is still on the device in `startup-config` at this point — copy it into memory FIRST, then modify, THEN save. 4. **Not sending Break during the right window on ISR 4000 series.** Newer devices give you a much shorter Break window (~10 seconds). If Ctrl+Break during full boot doesn't work, try power-on and immediately hold Break — some boot loaders latch it. 5. **Wrong console cable or missing driver.** Serial ports need drivers. If nothing shows on the terminal, install the Silicon Labs CP210x driver (Windows) or check `dmesg` (Linux/Mac) for the device path. On modern Macs, USB-C hubs sometimes lose serial connections when they sleep — try a direct USB-C cable. 6. **Password recovery disabled by `no service password-recovery`.** Some hardened deployments disable this feature at the config level — if it's set, recovery blows away the entire startup config as a security measure. If you MUST recover a device that has `no service password-recovery` and you can't afford to lose the config, contact Cisco TAC — there is no user-side workaround. ## Frequently asked questions **Q: How long does Cisco password recovery take?** A: 10-15 minutes if you have the console cable and physical access. The actual technical work is under 5 minutes; the rest is boot time (each router reboot takes 60-90 seconds). **Q: Do I need a Cisco TAC contract for password recovery?** A: No — this is a documented feature of every Cisco IOS device, no contract or license required. TAC is only needed if `no service password-recovery` is set at the config level (which intentionally disables user-side recovery). **Q: Will password recovery erase my running configuration?** A: Not if you do it correctly. Config-register 0x2142 tells the router to IGNORE startup-config on boot, not delete it. The saved config is preserved on NVRAM; you just have to copy it back with `copy startup-config running-config` after gaining access. **Q: Can I do this remotely?** A: No — password recovery requires physical console access. If the device is unreachable via management and passwords are lost, someone has to physically be there with a console cable. This is intentional Cisco security design. **Q: What if the router has an encrypted password I can't decrypt?** A: Doesn't matter — password recovery bypasses the check entirely by not loading startup-config. You never need to know or decrypt the old password; you just set a new one. **Q: Does this work on Cisco ASA firewalls?** A: Similar concept but different procedure — ASAs use a service password-reset ROMMON option and a specific `config-register 0x41` value. Different enough that it warrants a separate walkthrough. ## Where to go from here If you're inheriting a rack of Cisco gear at your first NOC job and need to audit access, password recovery is one skill; the other is knowing how to lock things down so this doesn't happen again. Two follow-ups worth reading: - **[SSH + VTY access done right](/topics/aaa/)** — how to configure `login local` + `transport input ssh` so console recovery is your only fallback, not the primary access method. - **[AAA fundamentals for CCNA](/topics/aaa/)** — external authentication (TACACS+, RADIUS) so passwords don't live on the device at all. **Real-world practice:** try this on a Cisco router in your home lab or on the [free browser-based CLI console](/exam/labs/console/) — no download, works on Chromebook or iPad. If you're planning to break into networking in the US market, being fluent in ROMMON and password recovery is one of the small skills that separates "I have a CCNA" from "I actually know how to fix Cisco gear." Book a [free 20-minute planning call](/contact/) if you want a mentor to walk you through your first live recovery on real hardware. --- ## CDP vs LLDP — Cisco's Neighbor Discovery vs the Vendor-Neutral Way — https://packetmentor.com/blog/cdp-vs-lldp/ > The two Layer-2 discovery protocols on every Cisco lab: CDP (Cisco proprietary, on by default) and LLDP (IEEE 802.1AB, off by default). When to use which, security implications, and the show commands the CCNA tests. *Published 2026-08-05.* ## Why discovery protocols exist When you inherit a network, the first thing you want to know is *what's connected where*. Cable-tracing 200 ports is not the answer. Instead, every modern switch and router broadcasts small periodic frames announcing *"I am R1, connected via Gi0/0, running IOS 15.6, my mgmt IP is 10.0.0.1"* — and any listening peer records that info in a table. That's what CDP and LLDP do. They are pure Layer-2 (frames never leave the local segment) discovery protocols. They don't route packets; they don't affect data flow. They just let neighbours identify each other. ## CDP vs LLDP — the CCNA-blueprint comparison | Property | CDP | LLDP | |---|---|---| | **Standard** | Cisco proprietary (1994) | IEEE 802.1AB (2005) | | **Where it works** | Cisco-only devices | Any vendor that implements it | | **Default on Cisco IOS** | **On** (globally + per interface) | **Off** (needs `lldp run`) | | **Frame type** | SNAP-encapsulated multicast frame | Ethertype 0x88CC multicast frame | | **Multicast MAC** | 01:00:0C:CC:CC:CC | 01:80:C2:00:00:0E | | **Advertise interval** | 60s (default) | 30s (default) | | **Hold time** | 180s (3× interval) | 120s (4× interval) | | **Info in each frame** | Device ID, IP, capabilities, IOS version, platform, port ID, duplex | Same categories via **TLVs** — mandatory TLVs cover chassis+port+TTL; optional TLVs add sys-name, sys-desc, mgmt-addr, port-desc | | **Security concern** | Leaks IOS version to anyone on the wire | Same leak risk | | **On the exam** | Config + verify + show output | Same | ## Config — the four commands you actually type **Global toggles** (both protocols default to what real IOS ships with): ``` R1(config)# cdp run ! default on Cisco R1(config)# no cdp run ! turn off entire device R1(config)# lldp run ! turn on globally (default off) R1(config)# no lldp run ! turn off globally ``` **Per-interface toggles** (finer control — leave enabled on network-facing ports, disable on user access ports): ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# cdp enable ! default on (redundant) R1(config-if)# no cdp enable ! turn CDP off on this port only R1(config-if)# lldp transmit ! send LLDP frames out this port R1(config-if)# lldp receive ! process incoming LLDP frames R1(config-if)# no lldp transmit ! stop announcing on this port ``` Try any of these on our [live console](/exam/labs/console/) — the engine accepts them and reflects the state in `show running-config`. ## Show commands the exam loves ``` ! CDP — what's on the wire R1# show cdp neighbors ! one-line-per-neighbor summary R1# show cdp neighbors detail ! full detail per neighbor (IP, IOS ver, platform) R1# show cdp entry R2 ! zoom to one specific neighbor R1# show cdp interface ! which interfaces have CDP active + timers R1# show cdp ! global CDP state + timers ! LLDP — mirror set of commands R1# show lldp neighbors R1# show lldp neighbors detail R1# show lldp interface R1# show lldp ``` Sample `show cdp neighbors` from a real lab: ``` Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID SW1 Gig 0/0 156 S I WS-C2960 Gig 0/1 R2 Gig 0/1 171 R C1841 Gig 0/0 ``` ## When to use which **Use CDP** when: - Every device is Cisco. - You want the richest per-neighbor info (Cisco tags include IOS version and platform strings LLDP omits). - You're already troubleshooting a Cisco outage — CDP is on by default so it's already running. **Use LLDP** when: - Mixed vendors on the same wire (Juniper, Arista, Aruba, Fortinet — they all speak LLDP, not CDP). - Third-party network monitoring (LibreNMS, Observium, PRTG) — most parse LLDP by preference. - **802.1AB TLVs are what LLDP-MED (Media Endpoint Discovery) rides on top of** — IP phones use LLDP-MED to auto-configure their voice VLAN, PoE class, and QoS marking. If you have Cisco phones on non-Cisco switches, LLDP-MED is what makes them work. **Use both** in production — the cost of both being on is a few frames per minute, and it protects you when a new device joins the network that speaks only one. ## The security angle (and why some ops disable it) CDP and LLDP both broadcast **your device's IOS/software version, hostname, and management IP** in plaintext, unauthenticated, to any device on the local segment. An attacker who plugs a laptop into a wall port learns: - Every neighbouring device hostname - Its IOS version (map to known CVEs) - Its management IP (target for further scans) - Its uplink port (blast radius planning) **Rule of thumb for hardening:** - **Disable CDP/LLDP on user access ports** — no legitimate need for a user laptop to learn switch topology. - **Keep enabled on trunks + backbone links** — network engineers need this to troubleshoot. - If you have Cisco IP phones, keep **CDP on** on the phone port (the phones use CDP to learn the voice VLAN) — or move the phone fleet to LLDP-MED. ``` R1(config)# interface range Gi0/1 - 24 R1(config-if-range)# no cdp enable R1(config-if-range)# no lldp transmit R1(config-if-range)# no lldp receive ``` ## Common troubleshooting recipes **"Why isn't my new switch showing up as a CDP neighbour?"** 1. Is CDP enabled globally on both ends? `show cdp` on each — look for "CDP is enabled globally". 2. Is CDP enabled per-interface? `show cdp interface Gi0/0`. 3. Is the link L2? CDP frames don't cross Layer-3 boundaries. Two switches trunked together see each other; two routers with a subnet between them don't (each router is one hop away — CDP is single-hop). 4. Is the neighbour running very old software? CDPv1 vs CDPv2 mismatch can hide capability info. **"LLDP shows nothing on Cisco to Cisco"** LLDP is **off by default** on Cisco. Run `lldp run` globally on both ends. Give it 60 seconds (LLDP hello interval + first neighbour learn). ## The #1 mistake **Assuming CDP is enough because "we're all Cisco".** Cisco acquires other companies (Meraki), Cisco spins out hardware to third parties, and one contractor's Aruba AP shows up on the wire — and suddenly your neighbour discovery has a blind spot. Enable LLDP globally *in addition to CDP* on the backbone. The cost is negligible; the discovery blind spot is real. ## Related - [CDP + LLDP — the topic page](/topics/cdp-lldp/) — reference table + `show` output samples + a hands-on CLI lab - [Layer 2 hardening — Port Security, DHCP Snooping, and DAI in one lab](/blog/port-security-and-dhcp-snooping/) — the other L2 knobs that lock down user access ports --- ## HSRP vs VRRP vs GLBP — Which First-Hop Redundancy for CCNA (and Real Networks) — https://packetmentor.com/blog/hsrp-vs-vrrp-vs-glbp/ > The three FHRP options side-by-side — HSRP (Cisco, most common), VRRP (IETF, multi-vendor), GLBP (Cisco, load-balancing). Which one to configure, why, and the CCNA-blueprint corners you'll be asked about. *Published 2026-08-04.* ## Why FHRP exists at all Every host on a LAN has one default gateway configured. When that gateway dies — router reload, uplink failure, hardware fault — hosts stop reaching everything off-subnet. There's no backup, because ARP only ever resolved one MAC for the gateway IP. **FHRP (First-Hop Redundancy Protocol)** solves this by putting two or more routers behind a **virtual IP + virtual MAC**. Hosts still point at one IP; multiple routers stand ready to answer for it. When the active router dies, another one silently takes over the virtual MAC and traffic keeps flowing — usually within a couple of seconds. Three protocols do this on Cisco gear. The CCNA (200-301) expects you to compare them at a describe level; only HSRP is asked about at the config level. ## HSRP vs VRRP vs GLBP — the comparison table | Property | HSRP | VRRP | GLBP | |---|---|---|---| | **Standard** | Cisco proprietary | IETF (RFC 5798) | Cisco proprietary | | **Where it works** | Cisco-only | Any vendor | Cisco-only | | **Group ID range** | 0–255 (v1) / 0–4095 (v2) | 1–255 | 0–1023 | | **Virtual MAC** | `0000.0c07.acXX` (XX = group) | `0000.5e00.01XX` | `0007.b400.XXYY` | | **Preempt default** | **Disabled** | **Enabled** | Disabled | | **Election metric** | Highest priority wins | Highest priority wins | Highest priority becomes AVG | | **Load balancing** | ❌ (only one active at a time) | ❌ | ✅ (multiple AVFs per group) | | **Uses multicast** | 224.0.0.2 (v1) / 224.0.0.102 (v2) UDP 1985 | 224.0.0.18 (IP 112) | 224.0.0.102 UDP 3222 | | **On the exam** | Config + verify | Describe + compare | Describe + compare | ## HSRP — the CCNA default **Cisco's original**, dates from 1994. If a Cisco book says "gateway redundancy" without qualification, it's talking HSRP. Roles: - **Active** — answers ARP for the virtual IP, forwards traffic - **Standby** — monitors the Active via hellos, takes over on failure - **Listen / Speak / Init** — transient states during election Election: highest **priority** wins (default 100, higher is better). If priorities tie, highest interface IP wins the tie-break. **Preempt is OFF by default** — meaning a router that comes back up won't reclaim Active until the current Active dies. Almost always you want to turn preempt ON so your intended-active router runs the show. Interface tracking: `standby G track ` decrements priority when the tracked link goes down. Common pattern: track the WAN uplink so if you lose the upstream ISP, HSRP fails over to the peer that still has connectivity. ## VRRP — the standards-compliant sibling **IETF equivalent**. If you have Cisco talking to Juniper, Arista, or a Fortinet cluster — you can't use HSRP; use VRRP. Semantically almost identical: - **Master** = Active (VRRP-speak) - **Backup** = Standby - Preempt is **ON by default** (opposite of HSRP) - The Master can share the virtual IP with the interface's real IP (HSRP always uses a separate virtual IP) - Election: highest priority, but priority 255 has special meaning ("IP owner" — router whose real interface IP == virtual IP) Cisco IOS speaks both HSRP and VRRP simultaneously — the choice is what you write in the config, not the platform. ## GLBP — the load-balancing one Cisco's answer to HSRP's "only one active" limitation. Multiple routers in a GLBP group **all forward traffic** concurrently — hosts on the LAN get different virtual MACs when they ARP for the gateway. Roles: - **AVG (Active Virtual Gateway)** — one per group, hands out MACs when hosts ARP - **AVF (Active Virtual Forwarder)** — 1-4 per group, each owning a different virtual MAC and forwarding for the hosts assigned to them Load-balancing methods: round-robin (default), weighted (bigger routers get more traffic), host-dependent (same host always uses same forwarder — sticky). Rarely deployed in practice — most enterprises live with HSRP + link aggregation on the uplinks instead. Still on the exam because "the CCNA covers FHRPs" and GLBP is what makes Cisco's FHRP story unique. ## Real IOS config — the three side-by-side **HSRP on a Cisco L3 switch (the CCNA staple):** ``` MLS1(config)# interface Vlan10 MLS1(config-if)# ip address 192.168.10.2 255.255.255.0 MLS1(config-if)# standby version 2 MLS1(config-if)# standby 10 ip 192.168.10.1 MLS1(config-if)# standby 10 priority 110 MLS1(config-if)# standby 10 preempt MLS1(config-if)# standby 10 track GigabitEthernet0/1 decrement 20 MLS1(config-if)# standby 10 authentication md5 key-string SecretKey! ``` **VRRP — same idea, different syntax:** ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 192.168.10.2 255.255.255.0 R1(config-if)# vrrp 10 ip 192.168.10.1 R1(config-if)# vrrp 10 priority 110 R1(config-if)# vrrp 10 authentication text mysecret ``` **GLBP — with round-robin load balancing:** ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 192.168.10.2 255.255.255.0 R1(config-if)# glbp 1 ip 192.168.10.1 R1(config-if)# glbp 1 priority 150 R1(config-if)# glbp 1 preempt R1(config-if)# glbp 1 load-balancing round-robin ``` Try any of these on our [live console](/exam/labs/console/) — the engine accepts all three FHRP families. ## Verification commands ``` ! HSRP R1# show standby brief R1# show standby GigabitEthernet0/0 10 ! VRRP R1# show vrrp brief R1# show vrrp interface GigabitEthernet0/0 ! GLBP R1# show glbp brief R1# show glbp GigabitEthernet0/0 1 ``` ## Which one to pick — a decision tree 1. **Cisco-only network?** → HSRP. It's the default, most documented, easiest to troubleshoot. 2. **Mixed vendors on the same subnet?** → VRRP. Only choice. 3. **Need active/active load balancing?** → GLBP (Cisco only) or a completely different design (anycast gateway, VRRP with routed active/active via BGP). 4. **On the exam?** → Read the question. If it says "Cisco proprietary" and asks about VIP+VMAC — HSRP. If "IETF standard" — VRRP. If "load-balancing FHRP" — GLBP. ## The #1 mistake **Forgetting to enable preempt on HSRP.** Default is OFF — meaning your "primary" router (the one with priority 110) can come back after a reload and sit in Standby while the "secondary" (priority 100) keeps running as Active. The primary won't take back over until the secondary dies. Almost every real-world HSRP config wants `standby G preempt`. On VRRP this is on by default so it's less of a trap there. ## Related deep-dives - [HSRP walkthrough — how default gateway redundancy actually works](/blog/hsrp-explained/) — HSRP alone in more depth - [Inter-VLAN routing — SVIs vs Router-on-a-Stick](/blog/inter-vlan-routing-svi-vs-router-on-a-stick/) — the L3-switch side of the same problem - [FHRP comparison — the topic page](/topics/fhrp-comparison/) — reference table + lab scenarios --- ## Cisco Wildcard Masks: ACLs & OSPF Without Confusion — https://packetmentor.com/blog/wildcard-masks-explained/ > The mental model for Cisco wildcard masks. When to use them (ACLs, OSPF), how to convert from a subnet mask, and the #1 mistake that breaks half the labs. *Published 2026-08-01.* Wildcard masks are the single most confusing thing in the first month of CCNA study. Not because they're hard — they're not — but because they look almost exactly like subnet masks, do the opposite job, and show up in the two topics that everyone practices most (ACLs and OSPF). Get the mental model wrong on day one, and you'll spend a semester debugging labs that should have worked. This post fixes the model in about ten minutes. ## The one-line mental model A **subnet mask** tells the router which bits of an IP address identify the *network*. A **wildcard mask** tells the router which bits of an IP address it should *ignore when matching*. - Subnet mask bit `1` → "this bit is part of the network — copy it." - Wildcard mask bit `0` → "this bit *must match* exactly." - Wildcard mask bit `1` → "this bit is a *wildcard* — I don't care what's there." They're inverses of each other. That's the whole idea. ## Conversion: subnet mask ↔ wildcard mask For any subnet mask, the corresponding wildcard is `255.255.255.255 − subnet mask` (octet by octet, `255 − x`): | Subnet mask | Wildcard mask | Matches | |---|---|---| | 255.255.255.0 (/24) | 0.0.0.255 | one /24 (256 addresses) | | 255.255.255.128 (/25) | 0.0.0.127 | one /25 (128 addresses) | | 255.255.255.192 (/26) | 0.0.0.63 | one /26 (64 addresses) | | 255.255.255.224 (/27) | 0.0.0.31 | one /27 (32 addresses) | | 255.255.255.240 (/28) | 0.0.0.15 | one /28 (16 addresses) | | 255.255.255.252 (/30) | 0.0.0.3 | one /30 (4 addresses) | | 255.255.255.255 (/32) | 0.0.0.0 | exactly one host | | 255.255.252.0 (/22) | 0.0.3.255 | four /24s = one /22 | | 255.255.240.0 (/20) | 0.0.15.255 | sixteen /24s = one /20 | | 255.255.0.0 (/16) | 0.0.255.255 | one /16 (65,536 addresses) | Memorize the top block cold — these are what CCNA questions almost always use. ## Where wildcard masks actually show up **ACLs** (standard and extended) — the "who" and "what" match fields. **OSPF network statements** — which local interfaces belong to which OSPF area. **NAT ACLs** — same as above, feeding a source list. Nowhere else in CCNA scope. If you're not in one of these three, you want a subnet mask, not a wildcard. ## Example 1 — ACL Task: permit any host in `192.168.10.0/24` and deny everyone else. ``` R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255 ``` Read out loud: "permit any address that matches 192.168.10.0 in the first three octets and can be anything in the fourth." That's every host in the /24. Then apply it inbound on the interface facing the source: ``` R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip access-group 10 in R1# show access-lists 10 Standard IP access list 10 10 permit 192.168.10.0, wildcard bits 0.0.0.255 ``` Note that IOS echoes it back as "wildcard bits 0.0.0.255" — that phrasing is a good exam-day hint that the second value is always a wildcard, never a subnet mask, inside `access-list`. ## Example 2 — OSPF network statement Task: enable OSPF on all interfaces in the `10.0.0.0/24` range and put them in area 0. ``` R1(config)# router ospf 1 R1(config-router)# network 10.0.0.0 0.0.0.255 area 0 ``` Read: "for any local interface whose IP falls in 10.0.0.0/24, enable OSPF in area 0." To enable OSPF on a **single interface** whose IP is `10.0.0.1`: ``` R1(config-router)# network 10.0.0.1 0.0.0.0 area 0 ``` A wildcard of `0.0.0.0` means "every bit must match exactly" — i.e. only the one address `10.0.0.1`. Confirm with `show ip protocols`: ``` R1# show ip protocols Routing Protocol is "ospf 1" ... Routing for Networks: 10.0.0.1 0.0.0.0 area 0 ``` ## Example 3 — the non-contiguous trick Wildcards let you match ranges that a subnet mask *cannot* express. For example, a wildcard of `0.0.0.3` matches **any 4 addresses whose last two bits vary**: ``` R1(config)# access-list 20 permit 10.1.1.0 0.0.0.3 ``` Matches: `10.1.1.0`, `10.1.1.1`, `10.1.1.2`, `10.1.1.3`. Same as a /30. More usefully, `0.0.0.255` in a wildcard with a network like `10.1.0.0` matches the whole `10.1.0.0/24`. But `0.0.1.255` matches `10.1.0.0/23` (256 + 256 = 512 addresses). **Two-line mental rule** for the wildcard alone: - Add 1 to it to get the block size. - Block size + starting IP tells you the range end. `0.0.0.31` + 1 = 32 → this wildcard covers 32-address blocks. Same as /27. ## The subnet-mask ↔ wildcard-mask shortcut If you know the subnet mask, the wildcard is `255 − x` per octet. Fast worked example: Subnet mask `255.255.255.240` (/28). Wildcard = `0.0.0.15`. Done. Subnet mask `255.255.252.0` (/22). Wildcard = `0.0.3.255`. Done. Do this ten times and you'll never have to think about it again. ## The #1 mistake — subnet mask where a wildcard belongs The single most common CCNA-lab bug — bar none — is typing a subnet mask where the box wants a wildcard. Real IOS will *accept* it (usually) but the meaning is wrong, so the ACL or OSPF network statement matches nothing (or matches too much) and the lab silently fails. Wrong (looks right, isn't): ``` R1(config-router)# network 192.168.1.0 255.255.255.0 area 0 ``` IOS silently converts and stores `network 192.168.1.0 0.0.0.255 area 0` — you get lucky. **But on an ACL:** ``` R1(config)# access-list 5 permit 192.168.1.0 255.255.255.0 ``` This does NOT match the /24 you meant. It matches only the exact IP `192.168.1.0` (because on ACLs IOS doesn't second-guess you). Every host in the /24 fails the ACL, nothing works, and you spend an hour debugging. **How to catch yourself:** if the number after the network address has any octet that isn't 0, 1, 3, 7, 15, 31, 63, 127, or 255 — you're probably typing a subnet mask by accident. Those are the only valid wildcard-octet values. ## Cheat card Keep this open during labs until it's second nature: | Concept | Bit = 0 | Bit = 1 | |---|---|---| | **Subnet mask** | host bit | network bit | | **Wildcard mask** | must match | ignore (wild) | Places wildcards appear: **ACLs, OSPF `network` statements, NAT source lists.** Everywhere else: subnet mask. ## Where to go from here - The full [ACLs topic page](/topics/acls/) walks through standard vs extended and how the wildcard interacts with `host` and `any` shortcuts (`host 10.0.0.1` = `10.0.0.1 0.0.0.0`, `any` = `0.0.0.0 255.255.255.255`). - The [OSPF Single-Area topic](/topics/ospf-single-area/) shows how the wildcard on a network statement selects which of a router's interfaces actually run OSPF. - Drill it on real IOS in the [free-play console](/exam/labs/console/) — configure an ACL with wildcard `0.0.0.15`, then use `show access-lists` to see how the router echoes it. Nail wildcard masks in week one and half the ACL/OSPF confusion in later chapters evaporates. Get it wrong, and every subsequent chapter compounds the pain. --- ## Cisco Trunking Best Practices (Without Causing Outages) — https://packetmentor.com/blog/cisco-trunking-best-practices/ > Learn the SOPs for configuring Cisco trunk links in enterprise networks. Avoid the common switchport trunk allowed vlan typo and master DTP and Native VLANs. *Published 2026-07-26.* ## The Risk of the 2 PM Change Window If you work in a US enterprise network or Managed Service Provider (MSP), you already know that modifying a live Cisco trunk link during business hours is nerve-wracking. Trunk links are the arteries of your Local Area Network (LAN). They carry traffic for multiple VLANs across switches, routers, and firewalls. A single configuration typo on a core trunk link doesn’t just drop one user offline—it drops entire floors, VoIP systems, and server racks. In this guide, we will break down the essential Cisco trunking best practices every Network Engineer must follow to safely configure, audit, and troubleshoot 802.1Q trunks in a production environment. ## 1. Never Rely on Dynamic Trunking Protocol (DTP) By default, many older Cisco Catalyst switches leave their interfaces in a state called `dynamic desirable` or `dynamic auto`. This uses the Dynamic Trunking Protocol (DTP) to negotiate whether a link should act as an access port or a trunk. Relying on DTP in an enterprise environment is a massive security and stability risk. The Risk: If a malicious user plugs a switch into a wall jack configured for `dynamic auto`, their device can spoof DTP frames, force the port into trunk mode, and gain access to every VLAN traversing your network (a classic VLAN Hopping attack). ### The SOP for DTP Mitigation: Always hardcode your port roles. If a port connects to a workstation, lock it down as an access port. If it connects to another switch, lock it down as a trunk and disable DTP negotiation entirely. **Configuration for Access Ports:** ``` Switch(config-if)# switchport mode access Switch(config-if)# switchport nonegotiate ``` **Configuration for Trunk Ports:** ``` Switch(config-if)# switchport trunk encapsulation dot1q Switch(config-if)# switchport mode trunk Switch(config-if)# switchport nonegotiate ``` *(Note: Newer Cisco IOS XE devices default to dot1q and may not require the encapsulation command).* ## 2. The `switchport trunk allowed vlan` Typo That Causes Outages This is the single most common human error in network engineering. Imagine you are asked to add a new security camera VLAN (VLAN 50) to an existing trunk link that already carries Data (VLAN 10), Voice (VLAN 20), and Management (VLAN 99). A junior engineer often logs in and types: `Switch(config-if)# switchport trunk allowed vlan 50` The Disaster: Without the `add` keyword, Cisco IOS does not append VLAN 50. Instead, it overwrites the entire list. Instantly, VLANs 10, 20, and 99 are dropped from the trunk. Users lose connectivity, phones go dead, and you have caused a major outage. ### The SOP for Adding VLANs Safely: Step 1: Always verify the current trunk status first. Run `show interfaces trunk` and document which VLANs are currently traversing the link. Step 2: Explicitly use the `add` keyword. ``` Switch(config-if)# switchport trunk allowed vlan add 50 ``` Step 3: How to recover if you make the typo. **Do not reload the switch!** Reloading takes 10+ minutes and takes down every other working port on the box. Instead, immediately re-add the missing range on the same trunk interface: ``` Switch(config-if)# switchport trunk allowed vlan add 10,20,99 ``` Then verify with `show interfaces trunk` before you exhale. ## 3. Secure Your Native VLAN The Native VLAN (default is VLAN 1) is where 802.1Q sends untagged traffic across a trunk link. In a modern enterprise, leaving the Native VLAN set to 1 is a known security vulnerability. Furthermore, protocols like CDP, VTP, and PAgP default to using VLAN 1. ### The SOP for Native VLAN Security: Best practice dictates changing the Native VLAN to an unused, "black hole" VLAN that is strictly dedicated to trunk links and is not assigned to any user access ports. For example, if your organization designates VLAN 999 as the Native/Blackhole VLAN: ``` Switch(config-if)# switchport trunk native vlan 999 ``` *Crucial Warning:* The Native VLAN must match on both ends of the trunk link. If Switch A is set to Native VLAN 999 and Switch B is still on Native VLAN 1, Cisco Discovery Protocol (CDP) will flood your console with `%CDP-4-NATIVE_VLAN_MISMATCH` warnings, and per-VLAN spanning tree may put the native VLAN into Blocking on that trunk — partial connectivity, hard to diagnose. Always change Native VLAN on both sides in the same change window. ## 4. Use the `reload in` Safety Net for Remote Changes If you are SSH'd into a remote branch switch located in another state, changing trunk parameters is highly risky. If you accidentally remove the management VLAN from the trunk, you will instantly sever your SSH connection, locking you out of the device completely. ### The SOP for Remote Change Management: Always use the `reload in` command before executing risky trunk configurations. ``` Switch# reload in 5 System configuration has been modified. Save? [yes/no]: no ``` *This tells the switch to reboot in 5 minutes without saving the running configuration.* The Workflow: 1. Execute `reload in 5`. 2. Make your trunk changes. 3. If you make a mistake and get disconnected, wait 5 minutes. The switch will reboot and load the old, working startup-config, restoring your access. 4. If your changes are successful and you maintain your connection, immediately cancel the timer: ``` Switch# reload cancel ``` *(Always remember to write memory `copy run start` only AFTER you have confirmed the changes are stable).* ## 5. Prune Unnecessary VLANs from the Core By default, an 802.1Q trunk allows VLANs 1-4094 across the link. While this makes plug-and-play easy, it is a poor design choice for large environments. If you have 100 VLANs in your core network, but a specific access switch only houses users for VLANs 10 and 20, there is no reason for broadcast traffic (like ARP requests or DHCP discovers) from the other 98 VLANs to traverse that trunk link. Allowing all VLANs wastes bandwidth and forces the edge switch’s CPU to process unnecessary broadcast frames. ### The SOP for Manual Pruning: Only allow the VLANs that are actively required on that specific downstream switch. ``` Switch(config-if)# switchport trunk allowed vlan 10,20,99 ``` *Note: no `add` keyword here — we're setting the initial allowed list on a fresh trunk, so overwrite is the intent. Use `add` for any change to a trunk that's already carrying user VLANs (see Section 2).* ## Conclusion: Stop Guessing and Start Engineering Textbook study for the CCNA teaches you *what* a trunk link is. True operational experience teaches you *how to manage it* without causing a severity-1 outage. By disabling DTP, securing your Native VLAN, meticulously using the `add` keyword, and relying on `reload in` for remote changes, you transition from a "click-and-pray" technician into a reliable Network Engineer that IT Directors trust with the core network. ### Are You Ready to Break Into the US Network Engineering Market? Passing the CCNA is only step one. Landing a $70k–$85k+ Junior Network Engineer role requires proving you understand how to navigate live enterprise environments safely. At PacketMentor, we don't just teach you how to pass the exam—we build the hands-on engineering skills and CV-grade portfolio projects that get you hired. [👉 Click here to book your free 20-minute 1:1 mentorship discovery call today.](/contact/?source=blog-cisco-trunking-best-practices) --- ## Don't paste that config into ChatGPT — safe GenAI for netops — https://packetmentor.com/blog/dont-paste-configs-into-chatgpt/ > A senior network engineer's field guide to using LLMs for NetOps without leaking configs, keys or topology. What actually leaks in a show run, the compliance exposure, a working sanitizer script, prompt patterns that work, and enterprise + self-hosted options compared. *Published 2026-07-24.* Pasting a broken switch config into ChatGPT is the fastest way to find a syntax error. It's also the fastest way to violate your company's data policy and — depending on which regulator owns your industry — potentially end your career. That's not a scare line. AI is now a routine part of the NetOps workflow: quick triage, config template drafting, log analysis, exam-question sanity checks. It's also, in the default consumer configuration, a live data-exfiltration pipe running out of your terminal directly into somebody else's training corpus and legal jurisdiction. The good news is the workflow is fixable with an evening's work. The bad news is most teams haven't done it yet. This is the field guide I wish existed when the first engineer on my team pasted a `show run` into free ChatGPT to ask about an OSPF neighbor stuck in EXSTART. ## What actually leaks in a "harmless" show run The interesting question isn't whether a config is sensitive — every senior engineer will nod along and say "of course." The interesting question is *what specifically* leaks when you paste even a small snippet. Let's be concrete. A single-page `show run` on a mid-sized enterprise router typically exposes: - **Real routable IPs.** Public /29s and /28s that map directly to your NAT edge, VPN concentrators, SD-WAN hubs. An attacker who knows your public v4 space has a target list. - **SNMP community strings.** `snmp-server community RW` sitting in plain text. Read-write on your entire fleet. - **AAA shared secrets.** `radius-server host 10.10.10.5 key `, `tacacs-server key ` — the keys that gate every admin login. - **IPsec pre-shared keys.** `crypto isakmp key address ` — the shared secret protecting your site-to-site tunnel. Present in the same file as the peer IP. - **Routing-protocol authentication keys.** OSPF `ip ospf authentication-key`, EIGRP `authentication-key`, BGP `neighbor password `. - **Wireless PSKs and RADIUS keys.** On any switch stack that terminates a WLC or embedded AP. - **Management-plane ACLs.** Your jumphost subnet, your NMS's IP, your Splunk collector. A rough map of "kill this box and admins can't reach anything." - **Internal VLAN and subnet map.** Segmentation is a control. Publishing a `show vlan brief` + `show ip route connected` publishes your segmentation. - **BGP topology.** Peer IPs, ASNs, MD5 passwords, route-reflector clients. Anyone with your BGP topology can model your blast radius. - **Certificate and CA data.** `crypto pki trustpoint` blocks, enrollment URLs, key sizes. - **Hostnames.** `hostname DC1-AGG-SW01` tells an attacker exactly where the box sits in your data center. None of this is theoretically sensitive. It's operationally sensitive. Any one line is enough to move an adversary from "external" to "informed external," which is the pivot that turns a two-week compromise into a two-hour one. ## The threat model, precisely The vague version — "LLMs might train on your data" — is true but doesn't help you argue with anyone. Here's the precise version: **1. Consumer/free tier LLMs retain and can train on your prompts.** OpenAI's default consumer terms allow prompt data to be used for model improvement unless you opt out. Anthropic, Google, Meta — same posture on their free/consumer tiers. Your input has become part of the vendor's training corpus by the time you close the tab. **2. Enterprise tiers have zero-retention or short-retention agreements, but the prompt still crosses the internet.** ChatGPT Enterprise, Claude for Enterprise, Azure OpenAI, AWS Bedrock all offer contractual data-handling that keeps your prompts out of model training. That is a real reduction in exposure. It does not eliminate exposure — the prompt is still processed on someone else's compute, subject to their operational logs, their subpoena posture, and their breach exposure. **3. Sidecar leakage is often bigger than direct leakage.** Browser extensions with clipboard access, screen-recording tools, session-replay analytics on the LLM's own UI, IDE plugins that stream keystrokes for "AI autocomplete," clipboard-history managers, corporate DLP tools that store what you copied — all of these can persist prompt data locally in ways your security team has no visibility into. **4. Compliance frameworks treat this as a data-classification failure.** Concretely: - **HIPAA** — a config isn't PHI per se, but if any endpoint IP maps to an EHR system or a covered entity's subnet, the segmentation map itself becomes "reasonably identifiable information" under the Privacy Rule's minimum-necessary standard. HHS OCR has settled cases on much thinner grounds. - **PCI DSS 4.0** — anything that describes the cardholder data environment (CDE), including the ACLs and routing that enforce its segmentation, is in scope. Publishing your segmentation to a third-party model is a Req 7 access-control failure. - **SOC2** — auditors will fail a Confidentiality control if you can't demonstrate that operational configs are classified and handled appropriately. "We paste them into ChatGPT" is not appropriate handling. - **NIST 800-53 SC-8 / SC-13** — data in transit protection and use of validated crypto modules. Public LLMs are neither an authorized system nor a validated module. - **CJIS / FedRAMP / ITAR** — hard prohibitions on unclassified handling of anything remotely operational. If your org touches any of these, the answer is not "sanitize better," it's "self-hosted only, full stop." Every one of those frameworks accepts the enterprise-tier answer if it's contracted and documented. None accept "we told people to be careful." ## The sanitization layer — a working script The single most useful thing you can do this week: put a sanitizer between engineers and the paste buffer. Here's a working Python 3 script that scrubs the most common sensitive fields from a Cisco IOS config. Save it as `sanitize-config.py`, drop it in your `~/bin`, alias it to `sc`, and pipe. ```python #!/usr/bin/env python3 """ sanitize-config.py — scrub a Cisco IOS / NX-OS / IOS-XE config of the fields that shouldn't cross the boundary into a public LLM. Not a substitute for review — but reduces the average-case leak from "complete topology" to "generic template with a shape." Usage: cat show-run.txt | ./sanitize-config.py > safe-to-paste.txt pbpaste | ./sanitize-config.py | pbcopy # macOS clipboard round-trip """ import re import sys import ipaddress # --- IP handling ------------------------------------------------------------- # RFC 5737 documentation prefixes — the only IPv4 space that is # permanently guaranteed not to belong to anyone in production. DOC_PREFIXES = ["192.0.2.", "198.51.100.", "203.0.113."] # Stable per-run mapping so the same real IP always maps to the same # fake IP within a single sanitizer run — preserves relationships # (routes still point to the "same" next-hop) without leaking values. _ip_map = {} _next_idx = [1] # /24 host counter within the current doc prefix def _fake_ip(real: str) -> str: if real in _ip_map: return _ip_map[real] prefix = DOC_PREFIXES[len(_ip_map) % len(DOC_PREFIXES)] fake = prefix + str(_next_idx[0] % 254 + 1) _next_idx[0] += 1 _ip_map[real] = fake return fake def _replace_ip(match: re.Match) -> str: raw = match.group(0) try: addr = ipaddress.ip_address(raw) except ValueError: return raw # Keep loopback / link-local / multicast / broadcast as-is — they aren't # exfiltration risks and preserving them helps the LLM answer usefully. if addr.is_loopback or addr.is_link_local or addr.is_multicast or addr.is_reserved: return raw if raw in ("0.0.0.0", "255.255.255.255"): return raw return _fake_ip(raw) IPV4_RE = re.compile(r"\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b") # --- Sensitive-line patterns ------------------------------------------------- # Anything matching these gets the *value* portion redacted, not the whole # line — so the LLM still sees the shape of your config. REDACT_PATTERNS = [ # SNMP communities (re.compile(r"(snmp-server\s+community\s+)(\S+)", re.I), r"\1"), # RADIUS / TACACS+ keys (re.compile(r"(\bkey\s+\d?\s*)(\S+)", re.I), r"\1"), (re.compile(r"(radius-server\s+.*?\bkey\s+)(\S+)", re.I), r"\1"), (re.compile(r"(tacacs-server\s+.*?\bkey\s+)(\S+)", re.I), r"\1"), # IPsec / ISAKMP pre-shared keys (re.compile(r"(crypto\s+isakmp\s+key\s+)(\S+)", re.I), r"\1"), (re.compile(r"(pre-shared-key.*?\s)(\S+)$", re.I | re.M), r"\1"), # OSPF / EIGRP / BGP auth (re.compile(r"(ip\s+ospf\s+authentication-key\s+\d?\s*)(\S+)", re.I), r"\1"), (re.compile(r"(ip\s+ospf\s+message-digest-key\s+\d+\s+md5\s+)(\S+)", re.I), r"\1"), (re.compile(r"(neighbor\s+\S+\s+password\s+\d?\s*)(\S+)", re.I), r"\1"), # Local users, enable passwords, line passwords (re.compile(r"(username\s+\S+\s+(?:secret|password)\s+\d?\s*)(\S+)", re.I), r"\1"), (re.compile(r"(enable\s+(?:secret|password)\s+\d?\s*)(\S+)", re.I), r"\1"), (re.compile(r"^(\s*password\s+\d?\s*)(\S+)", re.I | re.M), r"\1"), # Certificate + key material — nuke the whole hex block (re.compile(r"(certificate\s+\w+\s+[\dA-Fa-f]+\n)([\dA-Fa-f\s]+?)(\s*quit)", re.M), r"\1 \n\3"), # Wireless PSKs (re.compile(r"(wpa-psk\s+(?:ascii|hex)\s+\d?\s*)(\S+)", re.I), r"\1"), ] # Hostnames — rename to something generic so device role doesn't leak _seen_hostnames = {} def _rename_hostname(match: re.Match) -> str: real = match.group(2) if real not in _seen_hostnames: _seen_hostnames[real] = f"RTR-{len(_seen_hostnames) + 1:02d}" return f"{match.group(1)}{_seen_hostnames[real]}" HOSTNAME_RE = re.compile(r"^(hostname\s+)(\S+)", re.I | re.M) # --- Main -------------------------------------------------------------------- def sanitize(text: str) -> str: # Order matters: run REDACT_PATTERNS *before* IP substitution so we # don't accidentally rewrite an IP that lives inside a redacted key. for pat, repl in REDACT_PATTERNS: text = pat.sub(repl, text) text = HOSTNAME_RE.sub(_rename_hostname, text) text = IPV4_RE.sub(_replace_ip, text) # MAC addresses — replace with the documentation OUI (00:00:5E) text = re.sub( r"\b([0-9A-Fa-f]{2}[:.-]){5}[0-9A-Fa-f]{2}\b", "00:00:5e:00:53:00", text, ) text = re.sub( r"\b([0-9A-Fa-f]{4}\.){2}[0-9A-Fa-f]{4}\b", "0000.5e00.5300", text, ) return text if __name__ == "__main__": sys.stdout.write(sanitize(sys.stdin.read())) ``` Two design choices worth calling out: - **Consistent mapping within a run.** If `10.1.10.5` appears three times in the input (once as an interface IP, once as an OSPF neighbor, once as a static route next-hop), all three get mapped to the same fake IP. This preserves *relationships*, which is what an LLM needs to give you a useful answer. Randomizing every occurrence breaks the topology and produces useless output. - **Redact the value, keep the shape.** `snmp-server community MySecret RW` becomes `snmp-server community RW`. The LLM still knows this line is a read-write SNMP community declaration — it just doesn't know the string. Ship it as a team-wide tool. Bookmark it in a shared repo. Alias it as `sc` in the standard shell profile. That single step converts your average leak from "complete topology" to "template with the shape." ## Prompt patterns that work Sanitization solves half the problem. The other half is asking better questions in the first place. The rule is: **ask for a template, not a diff.** Templates are generic by design. Diffs require your specifics. | Instead of (leaks a lot) | Try (leaks nothing) | |---|---| | "Fix this ACL: `permit tcp host 10.10.5.7 host 172.16.42.19 eq 443` ..." | "Cisco IOS extended ACL template that permits HTTPS from a management subnet to a web-tier subnet and logs all denies — with the standard 3-line comment header we should include." | | "My OSPF neighbor is stuck at EXSTART. Here's my running-config: ..." | "OSPF neighbor stuck at EXSTART on a point-to-point Ethernet link — top 5 causes ranked by frequency, the `show` command that confirms each, and the fix for each." | | "Debug this VLAN trunk config" (paste follows) | "802.1Q trunk between two Catalyst 9300s in the same VTP domain isn't passing VLAN 30 tagged traffic — walk me through the 6-step diagnostic sequence with exact `show` commands." | | "Analyze this firewall log" (paste follows) | "Give me the FortiGate log-field cheat sheet for a Deny event on a policy with `srcintf`, `dstintf`, `srcip`, `dstip`, `service`, `action=deny` — what each field means and what pattern indicates a policy mismatch vs a UTM block." | The pattern: your specifics stay on your desk; the LLM sees the *shape* of the problem. You then apply the answer against the real numbers yourself, which is the part you were being paid to do anyway. ## Enterprise and self-hosted options — the honest matrix The right answer depends on your risk tolerance, budget, and whether you have a GPU cluster. There is no universal winner. | Option | Data retention | Where it runs | Rough cost | Right for | |---|---|---|---|---| | **ChatGPT Enterprise** | Zero training, ~30-day operational logs | OpenAI cloud (US) | ~$60/user/mo min | Mid-large orgs, general use | | **Claude for Enterprise** | Zero training, similar retention | Anthropic cloud (US) | Similar tier | Mid-large orgs, prefer Claude quality | | **Azure OpenAI** | In your Azure tenant, region-pinned | Azure cloud (regional) | Az consumption | Regulated (HIPAA BAA available), Azure-centric shops | | **AWS Bedrock** | In your AWS account, region-pinned | AWS cloud (regional) | Bedrock consumption | AWS-centric, multi-model | | **Google Vertex AI (Gemini Enterprise)** | In your GCP project | GCP cloud (regional) | GCP consumption | GCP-centric | | **Self-hosted Llama 3.1 70B on Ollama** | Zero external | Your own GPU (single A100 or 2× 4090) | Hardware capex | Full sovereignty, ITAR/FedRAMP, air-gapped labs | | **vLLM + Mistral Large / Qwen2.5** | Zero external | Your own cluster (multi-GPU) | Hardware capex | High-throughput internal team use | | **Cisco AI Assistant** | Cisco cloud, contract-bound | Cisco cloud | Included with certain SKUs | Cisco-heavy shops willing to be Cisco-only | Two honest observations: **Self-hosted is more accessible than it used to be.** A single workstation with an RTX 4090 (24GB) will run Llama 3.1 8B or a 4-bit-quantized 70B at usable NetOps speeds. Two 4090s comfortably run a 70B at full precision. For a lot of teams, that's a $4–8k capex that eliminates the entire compliance question. Ollama on a single Linux box behind your firewall, exposed via a small web UI, is a two-day project. It won't match frontier-model quality for open-ended writing, but for "read this log and tell me what stands out" or "explain this OSPF LSA output," it's more than adequate. **Cloud enterprise is the pragmatic answer for most.** For a 50-person NetOps team, negotiating an enterprise ChatGPT or Azure OpenAI contract is one afternoon of paperwork and one legal review. You get a data processing agreement (DPA), zero-training commitment, audit logging, and the ability to point at a contract when the auditor asks. That is worth an order of magnitude more than "we put up a policy." ## The pitch to management If you're the engineer trying to move your team off free ChatGPT, the argument that lands is not "AI is dangerous." It's: **"We have a control gap that appears in every current compliance framework, and the fix costs less per month than one hour of an outside auditor."** Concretely, per user per month: - ChatGPT Enterprise: ~$60 - Claude for Enterprise: comparable - Azure OpenAI at typical NetOps volumes: often under $30 with pooled quota Compare to the cost of a single incident: - **HIPAA** — OCR settlements over the last five years have ranged from $50k to $16M, plus mandatory corrective action plans that consume six-figure engineering time. - **PCI DSS** — non-compliance status raises transaction rates and can trigger merchant status review; a single card-brand fine can hit $500k. - **SOC2** — audit failure typically delays or kills enterprise sales in progress. The revenue exposure often dwarfs the annual license cost by 100×. - **Reputational** — one news story about a leaked config from your company is career-defining. Not in a good way. Put it in a one-pager. Attach it to a ticket. Send it up. ## What to do this week 1. **Ship the sanitizer to the team's shared tools repo.** Alias it, document it, get one engineer to demo it in the next standup. 2. **Publish a one-page GenAI policy.** It doesn't have to be long. What's allowed, what's forbidden, which channel is approved. See any of the [SANS Institute policy templates](https://www.sans.org/information-security-policy/) as a starting shape. 3. **Do an honest audit.** Ask the team, no-blame, what they've pasted into a public LLM in the last 30 days. You'll be surprised. Change the numbers going forward, don't shame the past. 4. **Approve one enterprise-safe channel.** Pick the vendor that fits your existing cloud (Azure OpenAI for M365 shops, Bedrock for AWS shops, ChatGPT Enterprise or Claude for the multi-cloud). Get one contract signed. 5. **For the most sensitive fleets, plan self-hosted.** A single-GPU Ollama box is a two-day proof of concept. If it works for one team, it can work for the whole org. ## The question worth asking your team Does your IT department have an official policy on sanitizing data before using GenAI, or is it currently the wild west? If you don't know the answer, you have your answer. The engineers who lead on this in 2026 are going to look, in retrospect, the way the engineers who insisted on HTTPS-everywhere looked around 2015: obviously right, and a couple of years too early to get credit for it. Be one of them. --- *If you liked this and want the sanitizer script, prompt-pattern library, and a one-page GenAI policy template pre-filled with your industry's compliance framework, [drop your email in the roadmap](/) — everything ships in the next monthly note.* --- ## BPDU Guard vs Root Guard vs Loop Guard — When to Use Which (CCNA) — https://packetmentor.com/blog/bpdu-guard-vs-root-guard-vs-loop-guard/ > CCNA tutorial on Cisco STP protection: BPDU Guard, Root Guard, and Loop Guard. What each blocks, where to apply them, and the real outage each one prevents. *Published 2026-07-23.* Spanning Tree does its job. Left alone, it picks a root bridge, calculates loop-free paths, and blocks the redundant links. But STP is trusting — it believes every BPDU it receives, from any port, at face value. That's fine on a static topology and dangerous the moment humans (or hardware failures) enter the picture. Cisco ships three protection features that make STP paranoid in the right ways: **BPDU Guard**, **Root Guard**, and **Loop Guard**. They sound similar. They solve different problems. Confusing them is how you either leave a hole open or slap a feature on the wrong port and cause the outage you were trying to prevent. Prereq: this post assumes you already understand [root bridge election](/blog/stp-root-bridge-election/). If STP itself is still fuzzy, start there. ## The one-line idea - **BPDU Guard** — *"a wall jack should never receive a BPDU. If it does, err-disable the port."* - **Root Guard** — *"no switch reachable through THIS port is allowed to become root."* - **Loop Guard** — *"if a port that was blocking suddenly stops seeing BPDUs, don't unblock it — the neighbor might be broken."* Three features, three failure modes. Once you know which one attacks which failure mode, deployment is one line per port. ## The setup — why STP alone isn't enough STP's convergence math is bulletproof, but its inputs aren't. Three things break it: **1. Someone plugs a switch into an access port.** Maybe an employee bought a 5-port desk switch to add ports. Maybe an attacker plugged in a laptop running `stpd`. Either way, that new device sends BPDUs. If it advertises a lower Bridge ID than your core, STP will make **it** the root — for a network you don't control. Users route traffic through the desk switch. Everything slows. Some things break. **2. A rogue switch gets connected to a distribution uplink.** Maybe a legitimate switch, wrongly configured with priority 0. It becomes root. Every packet in the network now takes a suboptimal path through it. The blast radius scales with your topology. **3. A fiber pair loses one strand.** The port stays up (the other strand still carries some signal). But BPDUs don't arrive anymore. STP thinks its neighbor died and transitions the port from Blocking to Forwarding. Now two ports are forwarding on what used to be a loop — you get a bridging loop, MAC flapping, and a broadcast storm. Total layer-2 meltdown in under 60 seconds. Each of the three protection features prevents one of these scenarios. ## BPDU Guard — access-port protection **The rule:** an access port (one that faces a user, a printer, a phone) has no legitimate reason to ever receive a BPDU. If one arrives, someone plugged a switch where they shouldn't have. **What it does:** the port goes into `err-disabled` state the instant a BPDU is received. No forwarding, no learning — down. Requires manual `shutdown` / `no shutdown` (or auto-recovery, more below) to bring back. **Where to apply:** every access port. Typically enabled globally in combination with PortFast: ```ios Switch(config)# spanning-tree portfast default Switch(config)# spanning-tree portfast bpduguard default ``` That two-line global config says *"any access port with PortFast enabled also has BPDU Guard enabled"*. Since PortFast should be on every access port anyway (it skips the 30-second listening/learning delay for a user's laptop that isn't going to send BPDUs), pairing it with BPDU Guard is standard practice. Per-port, if you prefer explicit: ```ios Switch(config)# interface FastEthernet0/5 Switch(config-if)# switchport mode access Switch(config-if)# spanning-tree portfast Switch(config-if)# spanning-tree bpduguard enable ``` **Recovery:** when a port goes err-disable, syslog logs something like: ``` %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/5 with BPDU Guard enabled. %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/5, putting Fa0/5 in err-disable state ``` Manual recovery: ```ios Switch# configure terminal Switch(config)# interface Fa0/5 Switch(config-if)# shutdown Switch(config-if)# no shutdown ``` Or auto-recovery after 5 minutes (my recommendation for large sites so you don't have to manually reset every port): ```ios Switch(config)# errdisable recovery cause bpduguard Switch(config)# errdisable recovery interval 300 ``` The port comes back automatically. If the rogue switch is still there, it goes err-disable again 5 minutes later — you'll see a repeating pattern in syslog that's easy to hunt. ## Root Guard — root-election protection **The rule:** a specific port should never lead toward a switch that becomes root. If a superior BPDU (lower Bridge ID) arrives on this port, treat it as untrusted — put the port into `root-inconsistent` state. **Where BPDU Guard drops rogue devices at the access, Root Guard drops rogue devices at the distribution/core.** Suppose you designed your network so `CORE-1` is the intended root (priority 4096) and every other switch has default priority (32768). Now someone connects `SW-BASEMENT` with priority 0 to a distribution uplink. Priority 0 wins the election, `CORE-1` gives up root, all your carefully-planned traffic patterns invert. **What it does:** ports with Root Guard enabled block superior BPDUs. If one arrives, the port transitions to `root-inconsistent` (a special blocking state) until the offender stops. Then the port recovers automatically — no err-disable, no manual intervention. **Where to apply:** on ports facing *downward*, away from the intended root. Never on the ports facing toward root — that's where legitimate root BPDUs come from. ```ios Switch(config)# interface GigabitEthernet1/0/24 Switch(config-if)# spanning-tree guard root ``` **Verify + monitor:** ```ios Switch# show spanning-tree inconsistentports Name Interface Inconsistency -------------------- ---------------------- ------------------ VLAN0010 GigabitEthernet1/0/24 Root Inconsistent ``` If nothing shows, no port is currently blocking a rogue root — good. If something shows, the port name plus VLAN tells you exactly where to walk. ## Loop Guard — unidirectional-link protection **The rule:** if a port that was in Blocking state suddenly stops receiving BPDUs, do NOT transition it to Forwarding. Assume the neighbor is broken (silent, unidirectional, or misconfigured) and stay blocked. **What it does:** puts affected ports into `loop-inconsistent` state instead of unblocking them. Auto-recovers the moment BPDUs start arriving again. **Why it matters:** without Loop Guard, a fiber pair that loses one direction is a serious hazard. STP times out (no BPDUs = neighbor gone), unblocks the redundant port, and both paths now forward on what was a loop. Total meltdown in seconds. With Loop Guard, that same silent-failure scenario produces one blocked port and a syslog message — not an outage. **Where to apply:** on every trunk port between switches. Typically globally: ```ios Switch(config)# spanning-tree loopguard default ``` Or per-interface if you want to be selective: ```ios Switch(config)# interface GigabitEthernet1/0/1 Switch(config-if)# spanning-tree guard loop ``` **Detection:** ``` %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0020. ``` ## The 3-line summary — which one, where, what it stops | Feature | Where to apply | Triggers on | Result | |---|---|---|---| | **BPDU Guard** | Access ports (user-facing) | Any BPDU received | `err-disable` — manual (or auto) recovery | | **Root Guard** | Ports facing away from root | Superior BPDU received | `root-inconsistent` — auto-recovers when the superior BPDU stops | | **Loop Guard** | Trunk ports (switch-to-switch) | BPDUs stop being received on a blocking port | `loop-inconsistent` — auto-recovers when BPDUs return | The single most useful mental frame: **BPDU Guard reacts to unexpected BPDUs, Loop Guard reacts to missing BPDUs, Root Guard reacts to *superior* BPDUs.** Presence, absence, or too-good — one for each. ## Common mistakes **1. Enabling BPDU Guard on a trunk port.** Trunks legitimately receive BPDUs from the switch on the other side. BPDU Guard err-disables it instantly and takes down the uplink. Trunks want Loop Guard, never BPDU Guard. **2. Enabling Root Guard on ports facing toward the root.** Every legitimate root BPDU that arrives will trip the guard, blocking your uplink to root. Roots BPDUs come FROM root, so ports leading TO root are safe to trust — those are the wrong ports for Root Guard. **3. Enabling Loop Guard on a port to a non-STP device.** If the neighbor doesn't send BPDUs (an unmanaged switch, a hypervisor with STP disabled, a legacy device), Loop Guard reads "BPDU absent" and blocks the port permanently. The absence isn't a failure — it's normal for that neighbor. Solution: enable Loop Guard only on ports that face STP-speaking neighbors, or use per-interface config instead of `default`. **4. Skipping err-disable auto-recovery.** Without `errdisable recovery cause bpduguard`, every accidentally-triggered BPDU Guard event requires a truck roll (or a remote SSH session that isn't going to work if the trunk went down). Set the auto-recovery interval to 300 seconds and move on with your life. ## The lab you should build Two switches. One trunk between them. One access port on `SW1` with a laptop. Configure: - `SW1` and `SW2` — `spanning-tree loopguard default` and `spanning-tree portfast bpduguard default` - `SW1 Fa0/5` (laptop) — `spanning-tree portfast` (BPDU Guard inherits from default) - `SW2 Gi1/0/24` (uplink to `SW1`) — `spanning-tree guard root` Now break it three ways: 1. Plug an old switch into `Fa0/5`. Watch `Fa0/5` go err-disable within a second. 2. Configure `SW1` with `spanning-tree vlan 1 priority 0`. Watch `SW2 Gi1/0/24` go `root-inconsistent` and the network keep the original root. 3. Kill one direction of the trunk (unplug just one fiber, or in Packet Tracer, `shutdown` on one side without the other seeing it). Watch Loop Guard kick in. Every real switching outage you ever fix in production traces back to one of these three failure modes. ## Cheat strip - **BPDU Guard** = *"BPDUs are unexpected here"* → access ports → err-disable - **Root Guard** = *"root shouldn't be reachable through here"* → downstream ports → root-inconsistent - **Loop Guard** = *"if BPDUs stop, don't trust the port to unblock"* → trunks → loop-inconsistent - Always pair PortFast + BPDU Guard as a default on the access layer - Auto-recover err-disable (300s) so single mistakes don't need a human ## The bigger point STP protection features are what separate a switch configuration that survives real users from one that survives only the lab. Every US enterprise network you'll ever work on has these enabled — and every outage caused by a rogue switch is a network engineer who forgot one of them. Learn which does what, deploy the right one on the right port, and you'll never be the engineer who caused a Monday-morning outage because someone plugged in a home router. For the full protocol treatment of STP itself, see [Spanning Tree — root bridge election](/blog/stp-root-bridge-election/). For the hands-on lab, grab any of the [STP Packet Tracer files](/labs/). --- ### Ready to build the network engineer instincts that get you hired? Reading `show spanning-tree inconsistentports` output and immediately knowing which fix to apply — that's the difference between a CCNA on paper and an engineer employers pay for. At PacketMentor we build those instincts, one broken lab at a time. [👉 Book your free 20-minute 1:1 mentorship discovery call today.](/contact/?source=blog-bpdu-guard-vs-root-guard-vs-loop-guard) --- ## TCP 3-Way Handshake Explained — SYN, SYN-ACK, ACK (CCNA) — https://packetmentor.com/blog/tcp-three-way-handshake/ > The TCP 3-way handshake for CCNA: what SYN/SYN-ACK/ACK actually carry, why it's three packets not two or four, and the states Wireshark shows you. *Published 2026-07-21.* Every reliable connection on the internet — HTTPS to your bank, an SSH into a router, a file uploaded to Google Drive — starts with the same three packets. The **TCP 3-way handshake** is how two endpoints agree they can talk before either one sends real data. CCNA candidates memorize *SYN → SYN-ACK → ACK*. That's enough to pass a multiple-choice question. It's not enough for the interview question every senior engineer eventually asks: **"Why exactly three packets? Why not two? Why not four?"** This post answers that — and everything else you need to actually understand what Wireshark shows you when you capture a session. ## The one-line idea Both ends need to prove they can **send** and **receive** before they trust each other with real payload. Two packets prove one direction, four packets are wasteful, three is the minimum that proves both. For the full protocol picture — segments, sliding windows, flow control — see the [TCP vs UDP topic page](/topics/tcp-vs-udp/). This post is the handshake specifically. ## Why three packets — not two, not four Think of it as a phone call. **Packet 1 — SYN (client → server).** Client says *"can you hear me? I'd like to start counting from sequence number 4823."* **Packet 2 — SYN-ACK (server → client).** Server says two things at once: *"yes, I heard you (ack your seq)"* AND *"can YOU hear me? I'd like to start counting from sequence number 9174."* **Packet 3 — ACK (client → server).** Client says *"yes, I heard your number too."* Why not two? Because after two packets, the server has no confirmation that the client received the server's initial sequence number. If packet 2 got lost, the server would think the session was up while the client had no idea. Data would go into a void. Why not four? Because packet 2 does double duty — it acknowledges packet 1 AND opens the reverse direction. Splitting that into two packets adds an unnecessary round trip. **Three is the mathematical minimum that establishes bidirectional trust.** That's the interview answer. ## What each packet actually carries Every TCP segment has a header with these fields. The handshake uses a specific combination on each: | Packet | Flags set | Seq | Ack | Meaning | |---|---|---|---|---| | 1. SYN | `SYN=1` | `x` (random ISN, e.g. 4823) | 0 | *"Start me at x"* | | 2. SYN-ACK | `SYN=1, ACK=1` | `y` (random ISN, e.g. 9174) | `x+1` | *"Ack yours, start me at y"* | | 3. ACK | `ACK=1` | `x+1` | `y+1` | *"Ack yours"* | Two details that trip people up: 1. The **initial sequence numbers (ISNs) `x` and `y` are random**, chosen independently by each side. This isn't cosmetic — it prevents an attacker from guessing them and injecting fake segments (this attack still exists; TCP ISN randomization is a defense). 2. The acknowledgment number `x+1` means *"I received your byte `x`, and I'm expecting `x+1` next"*. The `+1` throws people off because SYN doesn't carry data — but the SYN flag itself consumes one sequence-space slot. ## What Wireshark actually shows Capture any TCP session and you'll see three back-to-back rows for the handshake. Here's a real capture pattern (client 10.0.0.5 → server 172.20.1.10:443): ``` No. Time Source Dest Protocol Info 1 0.000 10.0.0.5 172.20.1.10 TCP 55212 → 443 [SYN] Seq=0 Win=64240 2 0.031 172.20.1.10 10.0.0.5 TCP 443 → 55212 [SYN, ACK] Seq=0 Ack=1 3 0.031 10.0.0.5 172.20.1.10 TCP 55212 → 443 [ACK] Seq=1 Ack=1 4 0.032 10.0.0.5 172.20.1.10 TLSv1.3 Client Hello ``` Wireshark shows `Seq=0` because it defaults to **relative sequence numbers** for readability — the raw ISN is a huge random number, and displaying `Seq=3872910845` on every row is unreadable. Turn off relative mode (`Edit → Preferences → Protocols → TCP → uncheck "Relative sequence numbers"`) if you want the real values. Notice packet 4 — the TLS Client Hello — arrives 32 microseconds after packet 3. The handshake was complete, so real data started flowing immediately. ## State transitions — the connection lifecycle Each side of a TCP connection is a small state machine. During the handshake: | Side | Before | Sends/receives | After | |---|---|---|---| | Client | CLOSED | sends SYN | SYN-SENT | | Server | LISTEN | receives SYN, sends SYN-ACK | SYN-RECEIVED | | Client | SYN-SENT | receives SYN-ACK, sends ACK | ESTABLISHED | | Server | SYN-RECEIVED | receives ACK | ESTABLISHED | On a Cisco router, you can see this table live: ```ios Router# show tcp brief TCB Local Address Foreign Address (state) 647A3B10 10.0.0.5.55212 172.20.1.10.443 ESTAB 647A3D40 10.0.0.5.55213 172.20.1.10.443 SYNSENT ``` The `SYNSENT` line is a session waiting for the server's reply. If it sits there for 30 seconds, the SYN got lost or a firewall silently dropped it. ## How the handshake fails (and what you'll see) Four common failure patterns, and how to spot each: **1. SYN sent, nothing back.** Firewall dropping silently, or destination unreachable. On the client: `SYNSENT` in `show tcp brief`. Eventually a timeout. No RST from the server. **2. RST from server on the SYN.** The port is closed. The server's stack is up, but no application is listening on that port. Fix: start the service, or check you're hitting the right port. **3. SYN-ACK never seen because of asymmetric routing.** The server replied, but the return path goes through a different firewall that doesn't have state and drops the reply. Fix in the network, not the endpoint. **4. Handshake completes, then the connection idles and dies.** That's not a handshake failure — that's a firewall or NAT device aging out the session. Look at [NAT & PAT translation timeouts](/blog/nat-pat-explained/) if a stateful device is in the path. ## The #1 mistake — assuming completed handshake means healthy session A completed 3-way handshake **only** proves the two endpoints can exchange packets. It says nothing about: - Whether the application on top of TCP is actually working (a listener might accept the socket then hang) - Whether MTU is right (small packets can complete a handshake; large packets that need fragmentation might still fail — see [MTU + fragmentation](/topics/mtu-fragmentation/)) - Whether TLS will succeed (the TCP handshake is BEFORE the TLS handshake, which has its own failure modes) If a curl test hangs after "connected", the TCP handshake succeeded and the problem is above layer 4. Skip re-checking firewall rules — check the app. ## The interview question that weeds out fake engineers *"A TCP client sends SYN. Two seconds later it sends another SYN with the same source port. What can you conclude?"* The fake answer: "The first SYN was retransmitted." The real answer: **It's not a retransmission — it's a new attempt with the same 4-tuple** (source IP, source port, dest IP, dest port). Retransmissions of the same SYN use the same sequence number and reset the retransmit timer; a "new" SYN 2 seconds later means either the client's TCP stack decided the first attempt died, OR the SYN was actually retransmitted (with the same seq) and Wireshark is showing you two identical packets. If the seq numbers match → retransmission. If they don't → new attempt. Real network engineers open Wireshark and check the sequence number. Textbook answers gloss over it. ## Try it yourself (10 minutes) Fire up any of the [Packet Tracer labs](/labs/) with two hosts and a router. From one host: ``` PC1> telnet 192.168.1.1 23 Trying 192.168.1.1... ``` On the router at the exact same moment: ```ios Router# debug ip tcp transactions Router# show tcp brief ``` You'll see the connection go SYNSENT → ESTAB in real time. Kill the telnet client and watch it go through the FIN-WAIT / TIME-WAIT teardown (that's the *other* handshake — a four-packet closer — which is a topic for another post). ## Cheat strip - **Three packets** = the minimum to prove bidirectional communication - **SYN, SYN-ACK, ACK** = flag combinations on packets 1, 2, 3 - **ISNs are random** for each side — security feature, not cosmetic - **`x+1` in the Ack field** — the SYN flag itself consumes 1 seq slot even though it carries no data - Completed handshake ≠ working application — TCP just proved the pipe exists ## The bigger picture The 3-way handshake is trivial to memorize and lethal to misunderstand. Every "network isn't working" ticket you'll ever get either happens *before* the handshake (firewall/routing), *during* it (asymmetric paths, MSS mismatch), or *after* it (application, MTU, timeouts). Knowing which of the three tells you where to look — and saves you from re-checking things that aren't broken. --- ### Ready to build the operator instincts that get you hired? Passing the CCNA is one thing. Reading a Wireshark trace, spotting an asymmetric-routing dropped SYN-ACK, and calling it in 30 seconds — that's what US Junior Network Engineer interviews test. At PacketMentor we build those instincts, one lab at a time. [👉 Book your free 20-minute 1:1 mentorship discovery call today.](/contact/?source=blog-tcp-three-way-handshake) --- ## CCNA vs AWS Advanced Networking — which one, when, and why — https://packetmentor.com/blog/ccna-vs-aws-networking-specialty/ > Cisco's CCNA and AWS's Advanced Networking Specialty overlap in name only. Which one fits your US networking career trajectory, whether you should do both, and the honest 2026 salary picture for cloud-focused NetEngs. *Published 2026-07-16.* Every year more US networking students hit the same fork: **should I skip CCNA and go straight to AWS Advanced Networking?** Short answer: **no** — but the reason isn't what most people say. Here's the honest breakdown of how these certs compare, which one signals what to US employers, and whether "both" is worth it (yes, but not in the order most people assume). ## What each cert actually is ### CCNA (Cisco 200-301, v1.1) Cisco's flagship entry-level networking cert. Vendor-specific — you'll read `show ip route` output, configure OSPF and ACLs on Cisco IOS, and interpret real Cisco topology diagrams. - **Prerequisite**: none. Truly entry-level. - **Prep time**: 12–20 weeks at 4–6 hrs/week for a working IT technician. - **Exam cost**: \$300. Passing score ~825/1000 (Cisco doesn't publish exact). - **Valid**: 3 years. ### AWS Advanced Networking — Specialty (ANS-C01) AWS's specialty-level certification for cloud networking. Focused on VPC design, hybrid connectivity (Direct Connect + VPN), Transit Gateway, Route 53 DNS, CloudFront, Global Accelerator, and multi-account network architectures. - **Prerequisite** (recommended): AWS Solutions Architect Associate + 5 years of networking experience. - **Prep time**: 8–16 weeks for someone who already has AWS SAA-C03 and networking foundations. Longer if starting cold. - **Exam cost**: \$300. - **Valid**: 3 years. Notice the prerequisite line. AWS calls this a **specialty** cert. It sits **on top of** networking fundamentals, not instead of them. ## Why the "skip CCNA" logic falls apart The pitch usually goes: "The industry is going cloud. Cisco is legacy. Go straight to AWS networking." Three problems with that thinking: **1. AWS Advanced Networking assumes you already know networking.** The exam expects you to know how BGP works, how routing tables build, what an AS-path is, and how DNS resolution flows end-to-end. Nothing on the exam teaches you those. If you don't know them, you fail — and you don't have any way to build them from scratch on AWS's platform alone. **2. The US job market for "cloud network engineer" wants BOTH.** Look at cloud NetEng job descriptions at Cisco (yes, Cisco hires them), Amazon Web Services itself, Microsoft, Google, and enterprises like JPMorgan and Capital One. They read: "CCNA or equivalent networking foundation + AWS Advanced Networking + hybrid experience." The "or equivalent" almost never means self-taught — it means CCNA + hands-on lab time. **3. Cisco is not "legacy."** US enterprises run massive amounts of Cisco gear. Every AWS Direct Connect connection has a Cisco (or Juniper, or Arista) router on the customer side. Every cloud-connected enterprise IS a hybrid enterprise. Skills in on-prem networking are how you get hired to bridge that hybrid. ## What each cert lands you in the US market **CCNA** — the standard opening. Junior NetEng, MSP Tier-2, NOC L1, network technician. Base salary \$60–75k median. Solid trajectory into CCNP + senior engineering. **AWS Advanced Networking** — the specialty add-on. Cloud NetEng, SRE-lean roles, Cisco / AWS partner sales engineer. \$120–160k+ base salary, but ONLY when paired with underlying networking knowledge (i.e., CCNA-equivalent or better). The specific job title patterns you'll see in US networking postings for 2026: - "Cloud Network Engineer" — CCNA foundation + AWS ANS + 3+ years networking experience - "Sr. Cloud Network Engineer" — CCNP + AWS ANS + Azure Network Engineer + 5+ years - "Cloud Solutions Architect (Networking Focus)" — CCNP + AWS Advanced Networking + AWS SAA-P - "Network Reliability Engineer (SRE)" — CCNA + AWS ANS + Python + Terraform ## Salary reality (US medians, 2026) | Certification stack | US base salary median | |---|---| | Network+ only | \$50–62k | | CCNA only | \$60–75k | | AWS Solutions Architect Associate only | \$70–90k | | AWS Advanced Networking only (no CCNA) | Hard to place; most jobs require networking foundation | | CCNA + AWS Solutions Architect Associate | \$85–105k | | CCNA + AWS Advanced Networking | \$110–140k | | CCNP + AWS Advanced Networking | \$130–170k | | CCNP + AWS Advanced Networking + hybrid + Terraform | \$150–200k | "AWS Advanced Networking only" without CCNA-level networking foundation is genuinely harder to place. Employers see it and either assume you already have the fundamentals (and interview to check) or worry you don't. ## Suggested order If you're starting from IT technician / help-desk: 1. **CCNA first** (12–20 weeks). Foundation. Cisco IOS. Vocabulary US recruiters know. 2. **AWS Solutions Architect Associate** (SAA-C03) next (~8 weeks). Learn how AWS is put together — VPC, EC2, S3, IAM, RDS. 3. **AWS Advanced Networking Specialty** (ANS-C01) as an optional deep-dive (~8-12 weeks). This is where the salary jumps. Skipping (1) to go straight to (3) is why so many people fail AWS ANS the first time. The exam questions assume network fundamentals that only CCNA-level study builds. ## What if I already have CCNA and want cloud? Skip Solutions Architect Associate if you're eager — go straight to AWS Advanced Networking. Most CCNA holders find ANS-C01 concepts intuitive; the AWS-specific parts (VPCs, Transit Gateway, Direct Connect) are the new material. Two-cert path: **CCNA + AWS Advanced Networking Specialty**. That's a strong US market signal that you understand both worlds. ## What if I already work in AWS but no networking background? Take CCNA. Yes, even if you're already handling networking tickets. The vocabulary gap between AWS-only cloud engineers and traditional network engineers is real, and it shows up in interviews. Sitting CCNA gets you fluent in the language everyone else uses. You can plausibly parallel-track CCNA + AWS ANS if you already have SAA. Twelve weeks of focused study on both isn't insane. ## Common questions **Q: Is AWS Advanced Networking "harder" than CCNA?** A: Different kind of hard. CCNA has more raw material to learn (100+ topics, Cisco IOS commands, exam performance-based sections). AWS ANS assumes you know those and layers hybrid connectivity + AWS-specific patterns on top. The AWS exam is shorter but each question tests deeper synthesis. **Q: Do I need AWS SAA before AWS ANS?** A: AWS recommends it. Most people find that having SAA (or SAA-Professional) as the foundation makes ANS feasible. Skipping SAA is possible but reduces first-attempt pass odds significantly. **Q: What about Azure Network Engineer Associate?** A: If your target employers are Microsoft-shop (many US federal, healthcare, universities), Azure Network Engineer Associate is the equivalent of AWS Advanced Networking. Career path: CCNA → Azure Network Engineer → Azure Solutions Architect Expert. **Q: What about Google Cloud Networking Engineer?** A: Third-tier in the US market. Most cloud-networking hiring is AWS-first, Azure-second, GCP a distant third. Only relevant if you specifically want a GCP-shop role. **Q: Is there a cloud-first cert that doesn't require CCNA-level networking?** A: AWS SAA-C03 is doable without CCNA-level networking depth — it's more about services than networking. But cloud NetEng roles specifically expect networking foundation. **Q: If I only had \$300 to spend, which exam would I sit?** A: CCNA. Broader ceiling for a US networking career. ## Cheat strip | Situation | Path | |---|---| | Zero networking, entry-level IT | CCNA first (skip AWS ANS until later) | | Solid networking, want cloud NetEng | CCNA + AWS ANS (Solutions Architect optional) | | Already have AWS SAA, no networking | CCNA in parallel with ANS if possible | | Working AWS engineer, no CCNA | CCNA to close the vocabulary gap | | Fortune 500 hybrid role target | CCNP + AWS Advanced Networking | | DoD / federal contractor | Network+ (or CCNA) + AWS ANS if the org uses AWS | ## Next step If you're deciding between CCNA and AWS: **CCNA first, then decide about AWS after you have it**. Cost of "wrong choice" is much lower when CCNA is the first move — it doesn't lock you out of anything. If you want mentorship on the CCNA path with an explicit eye toward transitioning into cloud NetEng afterward, that's what we do — [book a 20-minute plan call](/contact/?source=blog-ccna-vs-aws) and we'll map your timeline. --- ## CCNA vs Network+ — which for a US networking career in 2026 — https://packetmentor.com/blog/ccna-vs-network-plus/ > Cisco's CCNA and CompTIA's Network+ overlap on paper but target different careers. Which one US employers actually want, which pays more, and which order to sit them if you're going to do both. *Published 2026-07-16.* Every entry-level US networking career question eventually collapses to this: **Should I get CCNA, Network+, or both — and in what order?** The honest answer differs by job you're targeting, employer type, and how quickly you need to earn. Here's the working version. ## The short version - **CCNA** is Cisco's flagship networking cert. Vendor-specific. Deeper. Roughly 12–20 weeks of prep for a working IT technician. Expected at Cisco partners, MSPs, and any US enterprise running Cisco (which is most of them). - **Network+** is CompTIA's vendor-neutral networking cert. Broader and shallower. Roughly 6–10 weeks of prep. Common at US federal contractors and DoD roles because of DoD 8570 compliance. - **Both are useful.** The question is order and effort. ## What each covers ### CCNA (Cisco 200-301, v1.1) Blueprint domains and rough exam weights: | Domain | Weight | |---|---| | Network Fundamentals | 20% | | Network Access (VLANs, trunks, STP, EtherChannel, wireless) | 20% | | IP Connectivity (OSPF, static routing, FHRP) | 25% | | IP Services (NAT, DHCP, NTP, SNMP, syslog) | 10% | | Security Fundamentals (ACLs, port security, DHCP snooping, DAI, 802.1X, WPA3) | 15% | | Automation & Programmability (REST, JSON, Python, Ansible) | 10% | You configure Cisco IOS. You read `show` output. You interpret routing tables. Exam has real config-scenario questions plus performance-based questions where you type commands. ### Network+ (CompTIA N10-009, 2024) Vendor-neutral domains: 1. Networking Concepts (23%) 2. Network Implementation (20%) 3. Network Operations (19%) 4. Network Security (14%) 5. Network Troubleshooting (24%) Broader coverage of concepts (fiber types, cabling standards, WAN technologies, cloud networking, VoIP) at more conceptual level. No Cisco IOS commands. More multi-vendor language. ## Where each cert lands you in the US market ### Employers that specifically want CCNA - **Cisco partners** — Presidio, WWT, ePlus, CDW, Optiv, Insight. Most have "CCNA preferred / required" on the job description. - **US enterprises running Cisco** — banks (Chase, Wells Fargo), healthcare (UnitedHealth, Kaiser), universities, most Fortune 500. These stack CCNA + CCNP over years. - **ISPs and telecom** — Verizon, AT&T, Lumen, Comcast Business. Cisco IOS + IOS-XR skills valued. - **MSPs of all sizes** — anywhere from small local (10 techs) to national (Ntiva, Dataprise). CCNA on your resume opens Tier-2/3 conversations quickly. ### Employers that specifically want Network+ - **US federal contractors under DoD 8570 requirements** — Leidos, SAIC, CACI, Booz Allen. Network+ is on the DoD 8570 IAT Level II list, which means it satisfies the compliance requirement for a broad category of DoD IT roles. CCNA is NOT on that list. - **Government IT departments** at federal, state, and county levels. - **US-based colleges / universities** teaching IT — Network+ is common in academic curricula because it's vendor-neutral. - **Positions where the employer wants "the concepts" without a Cisco commitment** — smaller SMBs running Meraki cloud, or Ubiquiti, or non-Cisco stacks. ## Salary reality — US medians 2026 | Certification | Median salary (US, entry to junior role, 2026) | |---|---| | No cert | \$42–52k | | Network+ only | \$50–62k | | CCNA only | \$60–75k | | Both (CCNA + Network+) | \$65–80k | | CCNA + Cisco DevNet Associate | \$70–85k | | CCNP (2-3 years post-CCNA) | \$85–115k | Numbers vary by state — Texas, North Carolina, and Colorado pay closer to the top of these bands; upstate NY, rural Midwest, most of Alabama/Mississippi closer to the bottom. Clearance holders add \$5–15k to any of these. ## Which order — the decision tree **Q1: Do you want to work for a federal contractor or DoD?** - Yes → **Network+ first**. It satisfies DoD 8570 IAT Level II compliance and gets you past HR gates that CCNA can't. Then add CCNA within a year. - No → skip to Q2. **Q2: Do you have zero networking background — never touched a router / switch?** - Yes → **Network+ first**. It's a friendlier ramp. Six to ten weeks of study. Sit it, then move to CCNA on the same conceptual foundation. - No → skip to Q3. **Q3: Do you have IT experience (help desk, sysadmin, some networking exposure)?** - Yes → **CCNA first**. Higher pay ceiling, more career trajectories, and Network+ becomes trivial to add later (or unnecessary depending on your path). ## Cost comparison (2026) | | Network+ | CCNA | |---|---|---| | Exam voucher | \$369 | \$300 | | Retake voucher (if needed) | \$369 | \$300 | | Recommended study time | 6–10 weeks | 12–20 weeks | | Retake window / policy | 14 days between attempts | 5 days between attempts | | Valid for | 3 years | 3 years | | Renewal cost | \$369 exam OR ~\$100 CE credits per year | Retake CCNA OR earn continuing ed credits | CCNA is cheaper per attempt AND has a shorter mandatory wait between retakes. Network+ has more flexible continuing-ed renewal options. ## Common questions **Q: Does having both certs mean I'm "double certified" and worth more?** A: Marginally in the first year. Employers reading the resume for a junior role glance at CCNA and decide. Network+ on top signals well-roundedness but doesn't dramatically move the salary conversation. **Q: If I only have time for one, which?** A: For most US career paths — CCNA. It has a higher ceiling and Cisco IOS knowledge translates faster to Junior NetEng roles. Skip Network+ unless federal-contractor / DoD is your target. **Q: How long does each actually take?** A: A working IT person with some help-desk exposure typically finishes Network+ in 6–10 weeks. CCNA in 12–20 weeks at 4–6 hours per week. Complete beginner should add 4 weeks to each. **Q: Do employers actually check which specific cert you have on the resume?** A: For CCNA and Network+, yes. Both are on standard HR keyword lists. CCNA carries slightly more weight in most non-federal networking roles because it's the industry-standard vendor cert. **Q: What about JNCIA (Juniper) or AWS Advanced Networking?** A: Both are legitimate but narrower. JNCIA is for shops running Juniper (some enterprise, some carrier). AWS Advanced Networking is for cloud engineers who already know the fundamentals. Neither is a good FIRST cert if you're starting your networking career. ## The interview reality Most US networking interviews for junior roles ask specifically about Cisco IOS commands — even if the job description says "vendor-agnostic." That's because interviewers know Cisco IOS. If you can talk about OSPF adjacency, `show ip route`, ACL direction, and DHCP snooping, you'll pass technical rounds. Network+ concepts help but they're not what interviewers ask. Bottom line: **CCNA is more directly applicable to networking interviews in the US private sector.** Network+ helps HR filters at DoD contractors. ## Cheat strip | Situation | Pick | |---|---| | Working IT person, want private sector | CCNA | | Zero background, need a friendly ramp | Network+ → CCNA | | Targeting DoD 8570 / federal contractor | Network+ first, then CCNA | | Already have Sec+ and want networking | CCNA (Sec+ + CCNA is a strong combo) | | Want the highest ceiling and can afford 12 weeks | CCNA | | Need something on the resume in 30 days | Network+ (faster prep) | | Cheapest path to a junior NetEng role | CCNA | | Cheapest path to any US federal IT role | Network+ (or Sec+) | ## Next steps If you're deciding: take an honest 20 minutes to answer the Q1/Q2/Q3 decision tree above. That tells you which cert to sit first. If you're going with **CCNA**: [our 12-week study plan](/study-plan/) matches the mentorship program's cadence. Free. If you're going with **Network+ first**: hit CompTIA's official study guide + practice tests, then come back for CCNA when you're ready. Some of our free resources — the [ACL cheat sheet](/resources/acl-cheat-sheet/) and the [OSPF simulator](/simulators/ospf/) — work well as a preview of the Cisco vocabulary you'll need after Network+. --- ## OSPF timers, DR/BDR election, and why yours is stuck in EXSTART — https://packetmentor.com/blog/ospf-timers-dr-bdr-exstart/ > The three OSPF problems that trip up every CCNA candidate: timer mismatches that never form a neighbor, DR/BDR election producing an unexpected router as DR, and the classic EXSTART/EXCHANGE stall from an MTU mismatch. With show commands, real numbers, and the fixes. *Published 2026-07-15.* Three OSPF failures account for maybe 80% of the neighbor-adjacency questions in the field and on the CCNA exam. All three show up as "the neighbor never reaches FULL." Different `show` output for each. Different fix for each. ## The OSPF neighbor state machine (fast recap) ``` DOWN → INIT → 2WAY → EXSTART → EXCHANGE → LOADING → FULL ``` - **DOWN** — no hellos received. - **INIT** — first hello received but the neighbor doesn't see us yet. - **2WAY** — both sides see each other in the hello's neighbor list. On broadcast networks, DROTHER-to-DROTHER stays here (this is fine). - **EXSTART** — master/slave negotiation for the DBD exchange. If you're stuck here, it's almost always MTU. - **EXCHANGE** — DBD packets flowing, listing what each side has. - **LOADING** — the routes each side is missing are being pulled via LSR/LSU. - **FULL** — LSDBs are synchronized. Traffic can now use the routes. Which state your `show ip ospf neighbor` output stops at tells you exactly what's broken. ## Problem 1: Hello / Dead timer mismatch — stuck at DOWN or INIT **Symptom.** `show ip ospf neighbor` on one or both routers is empty. Or worse, one side sees INIT with a partial hello, and it never advances. **Cause.** OSPF exchanges hellos every 10 s on broadcast networks (default). If the two routers disagree on hello or dead timers, they detect the mismatch and refuse to form. Any of these fields on both sides must match: **hello interval, dead interval, area ID, subnet mask, authentication, MTU**. If any differ, no adjacency. Common way this happens: - Someone tuned one side with `ip ospf hello-interval 5` and forgot the neighbor. - Two different network types (broadcast vs point-to-point) end up with different defaults. **Diagnose.** ``` R1# show ip ospf interface Gi0/0 GigabitEthernet0/0 is up, line protocol is up Internet Address 10.0.0.1/30, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 R2# show ip ospf interface Gi0/0 GigabitEthernet0/0 is up, line protocol is up Internet Address 10.0.0.2/30, Area 0 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 ``` R1 is at 10/40, R2 is at 30/120. That's why the adjacency never forms. **Fix.** ``` R2(config)# interface Gi0/0 R2(config-if)# ip ospf hello-interval 10 R2(config-if)# ip ospf dead-interval 40 ``` Or if you'd rather tune the other side. Either way, both must match. ## Problem 2: DR / BDR election picks the wrong router **Symptom.** On a shared broadcast segment (multiple routers on the same VLAN), a low-end or edge router unexpectedly wins the DR election. Traffic hairpins through it or routing is slow. **Cause.** DR/BDR is decided by: 1. **Highest OSPF priority** (default 1, range 0–255). Priority 0 = "never elect me." 2. **Tiebreaker: highest router-ID**. Which is set explicitly, or picked from the highest loopback IP, or from the highest active interface IP. If nobody manually sets priority, whoever booted first (once the network was up) tends to win. That's usually random and rarely the right router. **Diagnose.** ``` R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DR 00:00:36 10.0.0.2 Gi0/0 3.3.3.3 1 FULL/BDR 00:00:35 10.0.0.3 Gi0/0 4.4.4.4 1 FULL/DROTHER 00:00:37 10.0.0.4 Gi0/0 ``` R2 (2.2.2.2) won DR by having the highest router-ID. If R1 was supposed to be the DR (typically the highest-CPU router — the distribution or backbone one), this is wrong. **Fix.** ``` R1(config)# interface Gi0/0 R1(config-if)# ip ospf priority 100 R4(config)# interface Gi0/0 R4(config-if)# ip ospf priority 0 ``` Priority 100 pushes R1 above the default 1, guaranteeing DR. Priority 0 on R4 explicitly opts it out of election. **DR/BDR is not re-elected until adjacencies drop** — you need to `clear ip ospf process` on both R1 and R2 to force the re-election immediately. **Real-world note.** In modern designs with only two routers on a subnet, DR/BDR still elects but is meaningless. On point-to-point links (`network point-to-point` on the interface), no DR/BDR is elected at all. That's usually cleaner. ## Problem 3: Stuck in EXSTART — the classic MTU mismatch **Symptom.** `show ip ospf neighbor` shows the peer at EXSTART or EXCHANGE for minutes, then drops to DOWN, then cycles. The adjacency never reaches FULL. **Cause.** In EXSTART, routers negotiate master/slave for the DBD exchange. The first DBD packet the master sends is often slightly under 1500 bytes (all its LSA summaries). If the receiving interface has a smaller MTU, the packet is dropped silently — OSPF just times out and restarts EXSTART. The trap: one side may have MTU 1500 (default Ethernet) and the other MTU 1400 (a tunnel, GRE, IPsec, or a mistakenly configured `mtu 1400` on an interface). **Diagnose.** ``` R1# debug ip ospf adj *Jul 15 14:22:03: OSPF: Rcv DBD from 2.2.2.2 on Gi0/0 seq 0x2011 opt 0x52 flag 0x2 len 1476 mtu 1476 state EXSTART *Jul 15 14:22:03: OSPF: Nbr 2.2.2.2 has smaller interface MTU R1# show ip ospf interface Gi0/0 | include MTU Neighbor 2.2.2.2, MTU 1476 ``` The `Neighbor has smaller MTU` debug line is the smoking gun. **Fixes (pick one).** Option A — align the MTUs: ``` R2(config)# interface Gi0/0 R2(config-if)# ip mtu 1500 ``` Option B — tell OSPF to ignore the mismatch (won't fix packet loss, but forms adjacency): ``` R1(config-if)# ip ospf mtu-ignore R2(config-if)# ip ospf mtu-ignore ``` Option B is what to do if the MTU difference is deliberate (like a tunnel underlying a GRE tunnel). Option A is the fix for a real misconfig. ## Bonus: EXCHANGE stall (rare) If the peer sits at EXCHANGE for minutes, an ACL is blocking the LSU packets carrying the actual LSAs. Check for an ACL on either interface that could deny multicast to 224.0.0.5. ## Show commands you must know cold ``` show ip ospf neighbor # is it FULL? show ip ospf interface # timers, priority, DR/BDR, MTU show ip ospf interface brief # one-line-per-interface summary show ip ospf database # the LSDB (LSAs by type) show ip ospf # process-level, router-ID, area count debug ip ospf adj # neighbor state transitions (use sparingly) debug ip ospf hello # hello packets in real time ``` `show ip ospf interface brief` gives you 90% of the answer to "which of my OSPF interfaces is having a problem." Learn this one first. ## Common exam / interview traps 1. **Q: Two routers on the same subnet, same area, hellos correct — no adjacency. What one command reveals the problem?** A: `show ip ospf interface` on both, compare the timers and MTU. This is the interview question. 2. **Q: What is the default OSPF hello / dead interval on a broadcast network?** A: 10 / 40 s. On non-broadcast (frame-relay, NBMA): 30 / 120 s. 3. **Q: On a point-to-point OSPF link, are DR/BDR elected?** A: No. Only on broadcast and NBMA networks. 4. **Q: Router-ID selection order?** A: Explicitly-configured `router-id x.x.x.x` → highest loopback IP → highest active interface IP. 5. **Q: What OSPF network type does `ip ospf network point-to-point` produce?** A: Point-to-point. No DR/BDR. Fast convergence. Best for GRE tunnels, back-to-back links. ## Cheat strip | Symptom | Likely cause | Quick fix | |---|---|---| | Empty neighbor table | Hellos not exchanged | Check interface up, ACL, wrong area | | INIT state persists | One side sees hellos but not neighbor list | Timer mismatch — align hello/dead | | Stuck in EXSTART | MTU mismatch | Align MTU or `ip ospf mtu-ignore` | | Stuck in EXCHANGE | LSU packets dropped | Check ACL for 224.0.0.5 blocks | | Wrong DR elected | Priority 1 everywhere | Set higher priority on the right router; `clear ip ospf process` | | DR/BDR reelection needed | Priority changed but state stuck | `clear ip ospf process` on both routers | | Cost seems too low everywhere | Reference bandwidth = 100 Mbps default | `auto-cost reference-bandwidth 10000` | ## The 20-minute lab you should run tonight 1. Build a triangle of 3 routers, all on one shared switch (broadcast segment). 2. Configure OSPF with default settings. Watch the DR/BDR election in real time with `debug ip ospf adj`. 3. Set priority 100 on one router. Bounce OSPF (`clear ip ospf process`). Watch that router become DR. 4. Change hello timer on one to 5. Watch the adjacency go DOWN. Restore. Watch it come back. 5. Change MTU on one interface to 1400. Watch the neighbor stall at EXSTART. Add `ip ospf mtu-ignore` on both. Watch it succeed. Twenty minutes of that drill locks in what an hour of reading can't. --- ## OSPF vs EIGRP — which one for CCNA and real US networking work — https://packetmentor.com/blog/ospf-vs-eigrp/ > A candid comparison of OSPF and EIGRP: what the CCNA 200-301 exam tests on each, where each one is actually deployed in US enterprise networks, and how to answer the interview question about picking between them. *Published 2026-07-15.* The CCNA 200-301 blueprint expects you to know both OSPF and EIGRP. The interview question US recruiters ask ("if you had to pick one for a greenfield network, which and why?") expects a real opinion. Here's the honest read on when each wins and how to answer. ## The short version - **OSPF** — open standard (RFC 2328 / RFC 5340 for v3). Link-state. Runs everywhere. Slower to converge without tuning, more predictable at scale. - **EIGRP** — Cisco proprietary (now RFC 7868 informational). Advanced distance-vector using DUAL. Blazing fast convergence with Feasible Successors. Only makes sense on Cisco-only networks. If your enterprise is Cisco-only and stays that way: EIGRP is faster to converge and simpler to run. If you have any non-Cisco routers (Juniper, Arista, Palo Alto, cloud vendors): OSPF is the only option. ## The CCNA exam scope for each **OSPF (200-301)** — expect deep questions: - Single-area configuration (`router ospf 1`, `network area `) - Router-ID selection (manual → loopback → highest active interface IP) - Neighbor states (DOWN → INIT → 2WAY → EXSTART → EXCHANGE → LOADING → FULL) - DR / BDR election on broadcast networks - Cost calculation (`10^8 / bandwidth` default) - Hello / Dead timer defaults (10 / 40 on broadcast, 30 / 120 on non-broadcast) - LSA types 1, 2, 3 (basic), 5 (external) - Multi-area basics (backbone area 0, ABR, ASBR) **EIGRP (200-301)** — narrower: - Configuration (`router eigrp 100`, `network`, wildcard masks) - K-values (default: K1=1, K3=1, others 0) — must match between neighbors - Metric formula (bandwidth + delay in default) - Successor + Feasible Successor + Feasibility Condition - Neighbor formation (Hello / Hold, must match Kvalue + AS number) - AD 90 internal, 170 external Real weighting on the exam: OSPF is ~10-12 questions typically, EIGRP is ~4-6. Study OSPF deeper. ## Where each actually lives in US enterprise networks **OSPF is used at:** - ISPs (backbone routing, OSPFv3 for IPv6) - Multi-vendor enterprises — Fortune 500 with Cisco + Juniper + Arista mix - Government / DoD contractors (open standard is a requirement in many RFPs) - Any greenfield network built after ~2018 where cloud connectivity is a factor **EIGRP is used at:** - Legacy Cisco-only enterprises (banks, healthcare, universities with 20+ year Cisco relationships) - Cisco SD-WAN underlays - Cisco DMVPN networks (EIGRP over the tunnel) - Retail chains with Cisco Meraki + traditional Cisco IOS mixed In practice: any US networking role you interview for will use ONE of them for the interior gateway. Ask in the interview which — it's a smart question, and the answer tells you a lot about how the network was designed. ## Head-to-head technical comparison | Feature | OSPF | EIGRP | |---|---|---| | **Protocol type** | Link-state | Advanced distance-vector (DUAL) | | **Vendor** | Open (IETF) | Cisco-proprietary (RFC 7868 informational) | | **AD (default)** | 110 | 90 internal / 170 external | | **Metric** | Cost from bandwidth | Composite (BW + delay by default) | | **Convergence** | 5-40 s untuned; sub-second with BFD | Sub-second natively (FS installs instantly) | | **Multicast for updates** | 224.0.0.5, 224.0.0.6 | 224.0.0.10 | | **Transport** | Directly over IP (protocol 89) | Directly over IP (protocol 88) | | **Neighbor timers (default)** | Hello 10 / Dead 40 | Hello 5 / Hold 15 | | **Loop prevention** | SPF algorithm on link-state database | Feasibility Condition (RD < FD) | | **Load balancing** | Equal-cost only (up to 16 paths) | Equal AND unequal cost (variance keyword) | | **Auto-summary** | No (never had it) | Historically yes, disabled by default since IOS 15 | | **Router-ID** | Explicit — needed for adjacency + LSDB | Automatically chosen but shown in `show ip eigrp` | | **Hierarchy** | Area-based (backbone area 0) | Flat by default; can use stubs | | **IPv6** | OSPFv3 (uses link-local for neighbor comms) | EIGRP for IPv6 (address-family syntax) | ## When OSPF wins - **Multi-vendor network** — the only sensible choice. - **Very large network needing hierarchy** — areas + LSAs give you structural containment. - **Predictable, well-documented behavior** — everyone in the industry knows OSPF. - **Cloud interconnect** — AWS Direct Connect, Azure ExpressRoute, GCP Cloud VPN all support OSPF and BGP; none support EIGRP. ## When EIGRP wins - **All-Cisco environment** — simpler config, faster convergence out of the box. - **DMVPN / Cisco SD-WAN** — Cisco optimized EIGRP for their overlay technologies. - **Uneven bandwidth links** — unequal-cost load balancing via variance is genuinely useful (OSPF has no equivalent). - **Fast pre-computed backup paths** — Feasible Successor logic. When your Successor dies, DUAL installs the FS in milliseconds without recomputation. ## The interview question — how to answer "You're designing an interior routing protocol for a new enterprise network. OSPF or EIGRP — pick and defend." **Wrong answer:** "OSPF because it's the standard." **Better answer:** "Depends on the environment. For a greenfield, multi-vendor, or cloud-connected enterprise, OSPF — because it's open and integrates with everything downstream. For a well-established Cisco-only enterprise with existing DMVPN or SD-WAN, EIGRP — because it converges faster natively and I can use unequal-cost load balancing. In both cases I'd run BFD on top so my sub-second convergence numbers actually mean sub-second." That answer signals: you understand the trade-off, you know the ecosystem, and you think about convergence tuning. ## Common exam traps 1. **Confusing OSPF and EIGRP AD**. OSPF = 110. EIGRP internal = 90 (better). EIGRP external = 170 (worse than OSPF). If BOTH are running on the same router, EIGRP internal wins by default. 2. **Metric calculation on the exam**. OSPF cost = `10^8 / bandwidth`. Default reference bandwidth is 100 Mbps, so anything at or above 100 Mbps is cost 1 (bad in modern networks). Change with `auto-cost reference-bandwidth 100000` (100 Gbps ref) to distinguish 100M/1G/10G/100G as cost 1000/100/10/1. 3. **EIGRP K-values MUST match**. If two EIGRP routers have different K-values, no adjacency. Same for OSPF area IDs. 4. **DR/BDR only on broadcast networks**. OSPF on point-to-point doesn't elect a DR. The exam loves this. 5. **EIGRP uses ports? No — direct IP protocol 88**. OSPF uses direct IP protocol 89. Neither uses TCP or UDP. ## Cheat strip | Query | OSPF | EIGRP | |---|---|---| | Convergence out of the box | 5-40 s | Sub-second | | Multi-vendor | Yes | Cisco only | | Load balancing | Equal-cost | Equal + unequal (variance) | | Neighbor state to know for the exam | FULL (after EXCHANGE + LOADING) | Passive (route stable) vs Active (recomputing) | | Metric | Cost from BW | Composite (BW + delay by default) | | Cost (interior) | 110 | 90 | | Interior gateway of choice in US greenfield (2026) | OSPF | Legacy Cisco only | ## What to actually do If you're studying CCNA: **deep-dive OSPF, understand EIGRP fundamentals well enough to recognize its behavior in show output**. That matches the exam weight. If you're job hunting: **be ready to name which is running at their environment** and give a coherent one-minute answer on why you'd pick each. Recruiters trip up unprepared candidates on this. If you're setting up a lab: run BOTH. Configure the same 4-router topology first with OSPF, then flush and configure with EIGRP. Watch the neighbor states, look at the routing tables, kill a link and time the convergence. That drill is worth 10 read-throughs of a textbook. --- ## Static routing — floating routes, admin distance, and defaults — https://packetmentor.com/blog/static-routing-done-right/ > Everything you need to configure static routes with confidence: next-hop vs exit-interface, admin distance, floating statics as backup, the default route ('quad zero'), and why the wrong syntax silently drops your recursive lookup. *Published 2026-07-14.* Static routing looks like the simplest thing on the CCNA — one line, done. It's actually the topic where you find out whether you truly understand how a router decides where to send a packet. Because static routes force you to think about it explicitly. Nothing is auto-negotiated. Every choice you make is visible. Here's the working knowledge to configure static routes without shooting yourself in the foot. ## The mental model — where does the router send it? When a packet arrives at a router, it does two things: 1. **Look up the destination IP** in the routing table using longest-prefix match. 2. **Forward the packet** according to the matched route's next-hop or exit interface. That's the whole story. Everything in routing — static, dynamic, dynamic-with-redistribution, PBR — is just a different way to populate that table. Static routing means the admin writes each entry by hand. The router doesn't learn from a neighbor, doesn't run an algorithm, doesn't recompute after a failure. It just uses what you told it, forever, until you change it or remove the interface it depends on. ## The syntax — two flavors ``` Router(config)# ip route Router(config)# ip route ``` Two flavors: - **Next-hop-IP:** "to reach `192.168.20.0/24`, send it to the router at `10.0.0.2`." - **Exit-interface:** "to reach `192.168.20.0/24`, send it out my `g0/1` interface." Both work in most cases, but they behave differently under the hood. ### Next-hop IP ``` Router(config)# ip route 192.168.20.0 255.255.255.0 10.0.0.2 ``` When a packet destined for `192.168.20.x` arrives, the router: 1. Looks up `192.168.20.0/24` → finds the static route with next-hop `10.0.0.2`. 2. Now needs to know how to reach `10.0.0.2` — does a **recursive lookup** in the routing table. 3. Finds `10.0.0.0/24` is directly connected on `g0/1`. 4. ARPs for `10.0.0.2`, gets MAC, sends the frame. This is called **recursive routing.** Advantage: it works no matter which of your interfaces `10.0.0.2` sits behind. Disadvantage: if the interface goes down but there's still a route to it via another path, forwarding continues; the static won't get removed from the table just because one interface flapped. ### Exit-interface ``` Router(config)# ip route 192.168.20.0 255.255.255.0 g0/1 ``` When a packet destined for `192.168.20.x` arrives: 1. Looks up `192.168.20.0/24` → finds static route pointing to `g0/1`. 2. Sends the packet out `g0/1` — no recursion needed. 3. **On a broadcast segment (Ethernet), the router must ARP for the destination directly.** If the destination is a remote host, this doesn't work naturally — the destination isn't on this segment. Exit-interface syntax works on **point-to-point** links (WAN serial, GRE tunnels) but not on Ethernet unless you also specify the next-hop. Cisco IOS actually warns you on Ethernet. ### The best-of-both syntax ``` Router(config)# ip route 192.168.20.0 255.255.255.0 g0/1 10.0.0.2 ``` Both exit-interface *and* next-hop-IP. This is what production configs usually use. The interface tells the router where to forward without recursion. The IP tells it who to ARP for. Fast lookup, correct on Ethernet. ## Administrative distance — who wins Every route source has a default **administrative distance (AD)** — a "trust rating" from 0 to 255. Lower AD wins. | Source | AD | |---|---| | Directly connected | 0 | | Static | 1 | | eBGP | 20 | | EIGRP internal | 90 | | OSPF | 110 | | RIP | 120 | | iBGP | 200 | | Unknown / unreachable | 255 | A route with AD 255 will not be installed in the routing table. Static routes have AD 1 by default. That means a static route will beat almost any dynamic route to the same destination. Sometimes that's what you want (override OSPF for one prefix). Sometimes it's not (backup route only kicks in when the dynamic one fails). ## Floating static — the backup route You want a static route as a **backup**. If OSPF has learned a route, use OSPF (path is auto-adjusted, converges quickly). If OSPF's route disappears, fall back to the static. Give the static a higher AD than the dynamic protocol: ``` Router(config)# ip route 192.168.20.0 255.255.255.0 10.0.99.2 200 ``` The trailing `200` sets the AD to 200. OSPF (110) beats it. But if OSPF loses its route to `192.168.20.0`, the static becomes the winner and gets installed. When OSPF re-learns, the static "floats" out again. This is the **floating static** — one of the most useful patterns in real networks. Every ISP-connected router I've seen has a floating static to the backup ISP with AD ~180. ## The default route — "quad-zero" ``` Router(config)# ip route 0.0.0.0 0.0.0.0 10.0.0.1 ``` This is a "match everything" route. It says: for any destination not matched by a more-specific route, send it to `10.0.0.1`. This is the **default route** or "quad-zero" (from the four zeros in the network and mask). Used everywhere: - The router at the edge of your LAN pointing at your ISP. - A branch router pointing at the head-office router. - A default injected into OSPF or EIGRP to give all interior routers a way out. You can also use exit-interface with a default route: ``` Router(config)# ip route 0.0.0.0 0.0.0.0 g0/0 ``` Same warnings apply — on Ethernet, use the next-hop version, or combine. ## Longest-prefix match — the tiebreaker If the routing table has both: - `10.0.10.0/24` via OSPF, AD 110 - `10.0.0.0/8` static, AD 1 ...and a packet arrives for `10.0.10.5`, which route wins? **Longest prefix match wins first.** `/24` is longer than `/8`. AD isn't consulted because the two routes aren't for the same destination. `/24` wins. OSPF's route is used. AD only breaks ties when two routes have **the same destination network and prefix length**. ## Show commands ``` Router# show ip route Router# show ip route static Router# show ip route 192.168.20.5 ``` `show ip route` gives you the whole table. `show ip route static` filters to statics only. `show ip route ` performs a specific lookup and shows which route matched — perfect for verifying floating-static behavior. Read `show ip route` output like this: ``` S 192.168.20.0/24 [1/0] via 10.0.0.2 ``` - `S` = static route. - `[1/0]` = AD 1, metric 0. - `via 10.0.0.2` = next-hop. If you set the AD to 200 (floating static): ``` S 192.168.20.0/24 [200/0] via 10.0.99.2 ``` ## Common mistakes 1. **Exit-interface on Ethernet.** Gives you an ARP for a destination that isn't on this segment. Use next-hop IP for Ethernet. 2. **Missing the `no` in a mistake.** Wrote `ip route 192.168.20.0 255.255.255.0 10.0.0.99` when you meant `10.0.0.2`. Now traffic disappears. Remove the wrong entry with `no ip route ... 10.0.0.99` and re-enter. Very easy to end up with two conflicting statics loading round-robin. 3. **Floating static without a higher AD.** Default AD is 1. Same as another static, or even better than a dynamic route. It becomes the *primary* instead of the backup. 4. **Default route pointing to the wrong interface.** If your default is `ip route 0.0.0.0 0.0.0.0 g0/1` and `g0/1` is a LAN, all internet traffic tries to ARP for every destination on your LAN. Nothing works. 5. **Forgetting to save.** `write memory`. Or on reboot the static disappears and someone gets paged. 6. **Recursive lookup loop.** `ip route 10.0.0.0 255.0.0.0 10.0.0.2` — the router needs to know where `10.0.0.2` is to reach `10.0.0.0/8`, but the only route to `10.0.0.0/8` is via `10.0.0.2`. The recursion never resolves. Route is invalid; IOS usually catches this. ## When to use static vs dynamic Static wins when: - Small network (2-3 routers) with clear topology. - Backup path (floating static). - Stub network with only one exit (branch office → head office). - Default route to the ISP. Dynamic wins when: - More than a handful of routes to maintain. - Redundant paths that need automatic failover. - Multiple exit points. Real networks usually mix: dynamic for the interior, static for the edges. Static routing is where every network engineering career begins. ## Cheat strip | Concept | One-line meaning | |---|---| | **ip route dest mask next-hop** | Recursive lookup, safe on any medium | | **ip route dest mask interface** | Direct-forward, safe on point-to-point only | | **ip route dest mask int next-hop** | Combined — best-of-both, use on Ethernet | | **AD 1** | Default AD of static route | | **Floating static** | `ip route ... AD` where AD > dynamic protocol's AD | | **Default route** | `ip route 0.0.0.0 0.0.0.0 next-hop` — match everything | | **Longest prefix match** | Most-specific /prefix wins before AD is even checked | | **`show ip route static`** | Filter routing table to statics only | | **`show ip route `** | Show exactly which route matched an IP | ## The exam lens CCNA questions on static routing usually test one of three things: 1. **Syntax recognition** — spot the correct `ip route` command for a given topology. 2. **AD reasoning** — given two routes to the same destination with different ADs, which is installed? 3. **Floating static setup** — configure a backup static route that's used only when the primary fails. Practice all three. Configure a small three-router topology in Packet Tracer, set up static + floating static + default. Watch what happens when you shut interfaces. That drill takes 15 minutes and locks the concepts in permanently. Once you're comfortable with static, dynamic routing (OSPF, EIGRP) is just a smarter way of populating the same table you now understand cold. --- ## IPv6 for CCNA — SLAAC, EUI-64, and the boot sequence — https://packetmentor.com/blog/ipv6-for-ccna/ > The IPv6 subset the CCNA actually tests — address structure, EUI-64, SLAAC vs DHCPv6, link-local vs global, and the exact CLI commands to bring a host up on a fresh v6 network without needing a DHCP server. *Published 2026-07-09.* IPv6 has been "the future of networking" for so long it's practically a cliché. But the CCNA 200-301 blueprint puts real weight on it — enough that skipping v6 in your prep is a way to lose 8-12% of the exam. And in the field, dual-stack is standard for any enterprise that touches mobile clients, cloud providers, or ISP peering. The good news: the v6 scope on the CCNA is narrower than a fresh look at RFC 8200 suggests. You need to know address structure, EUI-64, link-local addresses, SLAAC, and a few configuration commands. That's it. Here's the working knowledge. ## The address — 128 bits, 8 hextets An IPv6 address is 128 bits, written as 8 groups of 4 hex characters separated by colons: ``` 2001:0db8:0000:0000:0000:0000:0000:0001 ``` Two shortening rules to memorize: 1. **Leading zeros in a hextet can be dropped.** `0db8` becomes `db8`. Not the trailing zeros. 2. **A single run of consecutive all-zero hextets can be replaced with `::`.** Only once per address. Applied to the example: ``` 2001:db8::1 ``` Same address, easier to type. ## Address types A v6 address falls into one of these categories on the CCNA: - **Global Unicast** — routable on the internet. Roughly analogous to a public IPv4 address. Starts with `2000::/3` (i.e., first hex digit is 2 or 3). - **Unique Local (ULA)** — private, non-routable on the internet. Analogous to RFC 1918. Starts with `fc00::/7` (in practice `fd00::/8`). - **Link-Local** — used only on the local segment, never routed. Starts with `fe80::/10`. Every IPv6-enabled interface has one automatically. - **Multicast** — starts with `ff00::/8`. Note: IPv6 does not have broadcast. Anywhere IPv4 would broadcast, IPv6 multicasts. - **Loopback** — `::1` (i.e., `0:0:0:0:0:0:0:1`). Same as 127.0.0.1 in v4. The one that trips up beginners: **every interface has a link-local address whether you set an IPv6 address or not**, as soon as you enable IPv6 on the device. Link-locals are how neighbor discovery and routing protocols talk. You will always see one in `show ipv6 interface`. ## EUI-64 — deriving a host portion from the MAC Every host on a subnet needs a unique interface ID (the second half of a v6 address). Instead of statically assigning it, IPv6 can derive it from the 48-bit MAC address using **EUI-64**: 1. Start with the 48-bit MAC: `AA:BB:CC:DD:EE:FF`. 2. Split it in half and insert `FF:FE` in the middle: `AA:BB:CC:FF:FE:DD:EE:FF`. 3. Flip the 7th bit of the first byte (the U/L bit). `AA` = `1010 1010` → flip bit 7 → `1010 1000` = `A8`. 4. Result: `A8:BB:CC:FF:FE:DD:EE:FF` becomes the 64-bit host portion. So if the interface has MAC `AABB.CC00.0001` and the router advertises prefix `2001:db8:1::/64`, the interface auto-configures as `2001:db8:1:a8bb:ccff:fe00:1/64`. The CCNA loves to give you a MAC and a prefix and ask for the resulting SLAAC address. Practice the seven-bit flip. `AA` → `A8`, `02` → `00`, `00` → `02` — it's always the 7th bit of the first byte. ## SLAAC — auto-config without a DHCP server **SLAAC** (Stateless Address Autoconfiguration) is IPv6's answer to "how does a host get an IP without asking a server." The dance: 1. Host boots. Enables IPv6. Auto-derives its **link-local** address from its MAC (usually via EUI-64) and self-assigns. 2. Host sends a **Router Solicitation** (RS) to `ff02::2` — the all-routers multicast — asking "any routers here?" 3. Router responds with a **Router Advertisement** (RA) containing the prefix, prefix length, default gateway (which is the router's link-local), and DNS options. 4. Host combines the prefix from the RA with its own EUI-64 interface ID and self-assigns a global address. 5. Host runs **Duplicate Address Detection** — sends a Neighbor Solicitation to the address it's about to claim. If nobody answers, the address is unique and the host uses it. No DHCP server involved. This is a big deal: it means you can bring up an IPv6 network with just a router. In IPv4, you'd need a DHCP server or manual configuration on every host. ## DHCPv6 — when SLAAC isn't enough SLAAC gives out an address and a gateway. It does not (traditionally) give DNS or other options. Two solutions: - **Stateless DHCPv6** — host gets its address via SLAAC, DNS via DHCPv6. The RA has a flag `O = 1` telling clients "SLAAC for address, DHCP for options." - **Stateful DHCPv6** — like IPv4 DHCP, hands out addresses too. The RA has `M = 1` telling clients "DHCP for everything." CCNA scope typically covers SLAAC + stateless DHCPv6. Stateful DHCPv6 gets a mention. ## Config on a Cisco router — enable v6 ``` Router(config)# ipv6 unicast-routing Router(config)# interface g0/0 Router(config-if)# ipv6 address 2001:db8:1::1/64 Router(config-if)# ipv6 address autoconfig Router(config-if)# no shutdown ``` That first line — `ipv6 unicast-routing` — is critical. Without it, the router won't route v6 or send RAs. Cisco disables v6 routing by default. To use EUI-64 on the router itself: ``` Router(config-if)# ipv6 address 2001:db8:1::/64 eui-64 ``` That tells the router "take this /64 prefix, derive the interface ID via EUI-64, use the resulting address on this interface." ## Verify — the three commands you'll live in ``` Router# show ipv6 interface brief Router# show ipv6 interface g0/0 Router# show ipv6 route ``` `show ipv6 interface brief` gives you a fast scan: ``` GigabitEthernet0/0 [up/up] FE80::AABB:CCFF:FE00:100 2001:DB8:1::AABB:CCFF:FE00:100 ``` Both a link-local (starts with FE80) and a global-unicast (starts with 2001). If you don't see the link-local, IPv6 isn't up on that interface. `show ipv6 interface g0/0` (no `brief`) gives you the full state — MTU, joined multicast groups, ND settings, RA parameters. Overwhelming at first, essential for troubleshooting. ## Common mistakes 1. **Forgetting `ipv6 unicast-routing`.** No routing, no RA. Hosts on the LAN never SLAAC. 2. **Confusing link-local with the interface address.** Link-local is `FE80::/10` and is the neighbor-discovery address. The global-unicast is what everything routes to. Both live on the interface simultaneously. 3. **Miscounting the seven-bit flip.** The U/L bit is the 7th bit (from the left) of the *first* byte. `AA` → `A8`, not `AB`. 4. **Assuming IPv6 has broadcast.** It doesn't. Any place a v4 network would use broadcast, v6 uses multicast (usually `ff02::1` for all-hosts). 5. **Overusing `::`.** The `::` shortcut is allowed only once per address. `2001::db8::1` is invalid — ambiguous — and the parser rejects it. 6. **Manually assigning link-local addresses that don't start with `FE80`.** You can override the derived link-local, but the address you assign must be in the `FE80::/10` range or the OS rejects it. ## Address types — quick recognizer | Starts with… | It's a… | |---|---| | `2000-3FFF` | Global unicast (routable, "internet address") | | `FE80` | Link-local (segment-only) | | `FC00-FDFF` | Unique Local (private, ULA) | | `FF00-FFFF` | Multicast | | `::1` | Loopback | | `::` | Unspecified (source address only) | ## Cheat strip | Concept | One-line meaning | |---|---| | **IPv6 length** | 128 bits, 8 hextets | | **Global unicast** | `2000::/3` — routable | | **Link-local** | `FE80::/10` — auto, segment-only | | **Multicast** | `FF00::/8` — replaces broadcast | | **Loopback** | `::1` | | **EUI-64** | MAC + FFFE inserted, 7th bit flipped | | **SLAAC** | Host auto-derives address from RA prefix + EUI-64 | | **RA / RS** | Router Advertisement / Router Solicitation | | **`ipv6 unicast-routing`** | Enable routing + RA generation on a Cisco router | | **DAD** | Duplicate Address Detection — NS-based unique check | | **Stateless DHCPv6** | SLAAC address + DHCP for DNS | | **Stateful DHCPv6** | DHCP for everything, like IPv4 | | **:: shortcut** | Once per address, contiguous zeros only | ## The dual-stack reality In production, you almost never see pure IPv6. You see **dual-stack**: every interface has both a v4 and a v6 address, every server has AAAA records alongside A records, applications prefer v6 when both are available. Design implication: your v4 subnet map and your v6 prefix plan should overlay. If VLAN 10 is `10.0.10.0/24` in v4, it might be `2001:db8:10::/64` in v6. Keeping them aligned makes documentation manageable and troubleshooting sane. For the CCNA, expect at least three v6-flavored questions: one on shortening rules, one on EUI-64 math, and one on the SLAAC/RA sequence. Practice the math. Read the RA flags. Do the seven-bit flip until it's reflex. That covers 90% of what you'll be asked. --- ## EtherChannel with LACP — bundling four links into one Port-channel — https://packetmentor.com/blog/etherchannel-lacp/ > How to bundle multiple switch uplinks into a single logical Port-channel so STP stops blocking your redundant cables. LACP vs PAgP vs static, mode combinations that actually form a bundle, load-balance methods, and the diagnostic commands. *Published 2026-07-03.* You've cabled two switches with four gigabit uplinks for redundancy. You look at STP and realize three of those four cables are blocking — sitting idle in case the fourth fails. Waste of copper. That's what EtherChannel fixes. It bundles multiple physical links into a **single logical interface** (a Port-channel). STP now sees one link, not four. All four cables forward simultaneously — quadrupling your uplink bandwidth from 1 Gbps to 4 Gbps. It's one of the highest-value features on the CCNA. Cheap to configure, dramatic effect, and it comes up in real production the day you graduate. ## The mental model Imagine two switches: A and B. You cable them together with links `g0/1` through `g0/4`. Without EtherChannel, STP sees four separate links between the same two switches, decides there's a loop, and blocks three of them. Traffic uses only one link. With EtherChannel, you tell both switches: "these four physical interfaces are actually **one** logical Port-channel interface." STP now sees one bundle, not four. No blocking. All four forward. Load-balanced based on a hash of source/destination. If any single physical link fails, the Port-channel keeps forwarding on the remaining three. STP doesn't reconverge. Traffic doesn't hiccup. You just lose ~25% of the bandwidth for that bundle until the physical link is repaired. ## LACP vs PAgP vs static There are three ways to form the bundle: - **LACP** (Link Aggregation Control Protocol, 802.3ad) — open IEEE standard. Works between Cisco and non-Cisco. Use this by default. - **PAgP** (Port Aggregation Protocol) — Cisco-proprietary predecessor. Still works between two Cisco switches. Legacy. - **Static / "on"** — no negotiation. Both sides just declare "we're a bundle." Fastest to bring up, but no protection: if one side accidentally goes back to single-link, the other side still thinks it's bundled and traffic goes into a loop. Modern default: **LACP.** Use PAgP only if a specific box needs it. Use static only in tightly-controlled labs where you know exactly what's on both ends. ## The mode combinations that actually form a bundle This is CCNA gold. Each side of an EtherChannel is configured with a **mode**: For **LACP**: | Mode | Behavior | |---|---| | `active` | Actively sends LACP packets to form a bundle | | `passive` | Only responds if the other side is `active` | For **PAgP**: | Mode | Behavior | |---|---| | `desirable` | Actively sends PAgP packets to form a bundle | | `auto` | Only responds if the other side is `desirable` | For **static**: | Mode | Behavior | |---|---| | `on` | Force bundle up. No negotiation. | **Which combinations form a bundle?** - LACP: `active/active` ✓, `active/passive` ✓, `passive/passive` ✗ (both waiting). - PAgP: `desirable/desirable` ✓, `desirable/auto` ✓, `auto/auto` ✗. - Static: `on/on` ✓. Everything else with `on` breaks. Mixing protocols is a hard no. `on` and `active` on opposite sides → nothing forms. `active` and `desirable` → nothing forms. Exam question you will see: "Switch A is `passive`, Switch B is `passive`. Does the channel form?" — No. Both are waiting. ## The config — LACP active on both sides On both switches: ``` S1(config)# interface range g0/1 - 4 S1(config-if-range)# channel-group 1 mode active S1(config-if-range)# switchport mode trunk S1(config-if-range)# switchport trunk allowed vlan 10,20,30 ``` That creates `Port-channel1` on S1. Do the exact same thing on S2, and the bundle forms. **Every physical interface in the bundle must have identical config:** - Same speed (all 1 Gbps, or all 10 Gbps) - Same duplex - Same switchport mode (access or trunk) - Same allowed VLAN list (if trunk) - Same STP settings If any of those differ, the bundle refuses to form. `show etherchannel summary` will report the ports as `H` (bundle-not-formed) or `s` (suspended). ## Load balancing — hash-based, not round-robin EtherChannel does not send packet-1 out link-1, packet-2 out link-2 (round robin). Instead, it hashes some fields of each frame and picks a link based on the hash. Default hash is source MAC on lower-end switches, source-dest MAC or IP on higher-end. You can change it: ``` S1(config)# port-channel load-balance src-dst-ip ``` The choice of hash matters. If your traffic pattern is "one client talking to one server," all packets hash to the same value and go over the same physical link. You get 1 Gbps of the 4 Gbps bundle. To load-balance well, use `src-dst-ip` when clients are talking to many servers, and `src-dst-port` when a client-server pair generates many different port combinations. **Load-balancing does not mean each link gets exactly 25% of traffic.** It means: over many flows, the aggregate distributes across links. A single elephant flow does *not* get split. ## Physical requirements - **2 to 8 ports per bundle.** More than 8 is unusual and requires specific hardware. - **Same speed and duplex.** You cannot mix 1G and 10G in the same bundle. - **Same media type where possible.** Copper and fiber can technically coexist but not recommended. ## The show commands ``` S1# show etherchannel summary Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port A - formed by Auto LAG Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SU) LACP Gi0/1(P) Gi0/2(P) Gi0/3(P) Gi0/4(P) ``` The critical characters: - `Po1(SU)` — Port-channel 1 is Switching (S) and Up-in-use (U). Good. - `Gi0/1(P)` — this physical port is Bundled in the Port-channel. Good. - `Gi0/1(H)` — Hot-standby (LACP), waiting to activate. - `Gi0/1(s)` — suspended. Mismatch somewhere. - `Gi0/1(I)` — stand-alone. Wasn't able to negotiate. If any port is `s` or `I`, run `show interfaces g0/1 etherchannel` — the debug output tells you exactly which parameter mismatched. ## Layer 2 vs Layer 3 EtherChannel Everything above is Layer 2. On routers or L3-switches, you can also make a Layer 3 EtherChannel — a Port-channel with an IP address instead of a switchport. ``` Router(config)# interface port-channel 1 Router(config-if)# no switchport Router(config-if)# ip address 10.0.0.1 255.255.255.252 Router(config)# interface range g0/1 - 2 Router(config-if-range)# no switchport Router(config-if-range)# channel-group 1 mode active ``` Use case: two routers with 2 × 10 Gbps between them, want 20 Gbps of routed capacity. ## Common mistakes 1. **Wrong mode combination.** `passive/passive` or `auto/auto` never forms. Draw a table if you're unsure. 2. **Mismatched physical config.** Different allowed-VLAN lists, different STP config, different speeds — bundle refuses. `show etherchannel summary` will show a suspended port. 3. **Mixing protocols.** `active` on one side, `desirable` on the other. Not compatible. Pick one and use it on both sides. 4. **Expecting round-robin load balancing.** A single elephant flow rides one link. 5. **Not configuring the physical interfaces first.** If you set up trunk allowed-VLAN differently on the physical interfaces after bundling, the physical config gets overridden by the Port-channel config. Configure Po1's trunk settings, and physical members inherit them. 6. **Using `on` in production.** Static mode gives you no protection if one side loses its config. Loops. Use LACP. ## Cheat strip | Concept | One-line meaning | |---|---| | **EtherChannel** | Bundle 2–8 links into one logical Port-channel | | **LACP** | 802.3ad — open standard. Default choice | | **PAgP** | Cisco-only legacy — still works between Cisco switches | | **`on`** | Static bundle, no negotiation. Dangerous | | **Modes (LACP)** | `active` initiates, `passive` responds | | **Modes (PAgP)** | `desirable` initiates, `auto` responds | | **Passive/passive** | Never forms | | **Auto/auto** | Never forms | | **Load balance** | Per-flow hash, NOT round-robin. One flow = one link | | **Bundle max** | 8 physical ports per Po | | **Physical requirements** | Same speed, duplex, mode, VLAN list on every member | | **`show etherchannel summary`** | (SU) = Port-channel up; (P) = physical port bundled | | **L3 EtherChannel** | `no switchport` + IP address on Po interface | ## Try it once and it clicks Two switches. Four cables between them. Configure `channel-group 1 mode active` on all eight ports (both switches). Watch `show etherchannel summary` on both — bundle should form in ~3 seconds. Verify all four are `(P)`. Ping across. Yank one cable. Ping doesn't drop (or drops for a fraction of a second). Plug it back. Bundle recovers. That five-minute exercise gives you an intuition that would take hours to build from reading. Do the lab. EtherChannel is one of those features where the second time you configure it, you feel like a network engineer for real. --- ## Layer 2 hardening — Port Security, DHCP Snooping, and DAI in one lab — https://packetmentor.com/blog/port-security-and-dhcp-snooping/ > The three access-layer defenses that stop 90% of L2 attacks: MAC flooding, rogue DHCP servers, and ARP spoofing. How they interact, the trust-port model, sticky-MAC pros and cons, and the diagnostic commands when something goes err-disabled. *Published 2026-07-01.* The access layer is where users plug in. It's also where the meanest attacks come from — someone hooks up a laptop and starts flooding the switch, spoofing the DHCP server, or poisoning ARP tables. Layer 2 has no authentication in the ordinary sense: whoever plugs in the cable is on the network. Three built-in switch features stop the majority of L2 attacks with minimal effort: 1. **Port Security** — limit the MACs allowed to send on an access port. 2. **DHCP Snooping** — designate which switch ports are allowed to be DHCP servers. 3. **Dynamic ARP Inspection (DAI)** — validate ARP replies against the DHCP snooping binding table. They're related: DAI depends on the DHCP snooping binding table. All three are worth configuring on any access switch that serves untrusted hosts (i.e., ~all of them). Here's how they work together, and how to configure them without accidentally locking out legitimate users. ## Port Security — first line Port Security tells the switch: "on this access port, only allow traffic from up to N distinct source MACs. Violation → err-disable the port." Default config after enabling: - Max MACs = 1 - Violation = shutdown (err-disable) - MAC learning = dynamic (secured in RAM only, forgotten on reboot) Basic config: ``` Switch(config)# interface g0/1 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 10 Switch(config-if)# switchport port-security Switch(config-if)# switchport port-security maximum 2 Switch(config-if)# switchport port-security violation restrict Switch(config-if)# switchport port-security mac-address sticky ``` Line by line: - `switchport mode access` — must be access, not trunk or dynamic. Port Security refuses to activate on a dynamic-mode port. - `switchport port-security` — activate the feature. - `maximum 2` — allow up to 2 MACs. Common when a laptop is behind a phone (phone MAC + laptop MAC). - `violation restrict` — drop the offending traffic and log, but keep the port up. Alternatives: `shutdown` (err-disable, requires manual bounce) and `protect` (silently drop, no log). - `mac-address sticky` — dynamically learn MACs, save them to running-config. When the running-config is copied to startup-config, they persist through reboot. ## Sticky MAC — the trade-off Sticky MAC is popular because it's low-effort: you don't have to enter each user's MAC. The switch learns and remembers. Downside: if a user replaces their laptop, the new MAC is a violation. Someone has to `clear port-security sticky interface g0/1` or `no switchport port-security mac-address ` to accept the new one. For high-security environments, prefer statically configured MACs. For general use, sticky is fine — with a policy to bounce ports on user hardware changes. ## Violation modes | Mode | Behavior | |---|---| | `shutdown` | Port goes err-disabled. Manual recovery. Default. | | `restrict` | Drop violating traffic, increment counter, log via SNMP/syslog. Port stays up. | | `protect` | Silently drop violating traffic. No log. No counter. | Choose `restrict` for most access ports — you get logging without disrupting the user's day. `shutdown` for high-security. `protect` is rarely useful because you lose visibility. ## Show commands for Port Security ``` Switch# show port-security Switch# show port-security interface g0/1 Switch# show port-security address ``` `show port-security interface g0/1` is the money command: ``` Port Security : Enabled Port Status : Secure-up Violation Mode : Restrict Aging Time : 0 mins Maximum MAC Addresses : 2 Total MAC Addresses : 2 Configured MAC Addresses : 0 Sticky MAC Addresses : 2 Last Source Address:Vlan : aabb.cc00.0001:10 Security Violation Count : 3 ``` Read this on a real port and every port-security concept snaps into place. ## Err-disable recovery When `violation shutdown` fires and the port goes err-disabled, you have to manually recover: ``` Switch(config)# interface g0/1 Switch(config-if)# shutdown Switch(config-if)# no shutdown ``` Or configure auto-recovery: ``` Switch(config)# errdisable recovery cause psecure-violation Switch(config)# errdisable recovery interval 300 ``` Now the port comes back automatically 5 minutes after being err-disabled. Useful in low-security environments; skip in high-security. ## DHCP Snooping — stop rogue DHCP servers By default, any device connected to a switch can advertise as a DHCP server. If someone plugs in a Linux laptop with dhcpd running, clients on the same VLAN might grab an IP from *that* server — with a bogus gateway that captures all their traffic. DHCP Snooping tells the switch: "only the port toward the real DHCP server is trusted to send DHCP-server-side messages. Every other port is untrusted." ``` Switch(config)# ip dhcp snooping Switch(config)# ip dhcp snooping vlan 10 Switch(config)# interface g0/24 Switch(config-if)# description Uplink to DHCP server Switch(config-if)# ip dhcp snooping trust Switch(config)# interface range g0/1 - 23 Switch(config-if-range)# ip dhcp snooping limit rate 10 ``` Line by line: - Global `ip dhcp snooping` — enable the feature. - Per-VLAN activation — DHCP snooping runs on VLAN 10. - Trust the uplink (toward the real DHCP server) — DHCP server messages are allowed on `g0/24`. - All other ports (`g0/1` through `g0/23`) are untrusted by default. Any DHCP OFFER/ACK arriving on those ports is dropped. - Rate-limit — prevent DHCP flooding attacks. ## The binding table — the linchpin of L2 security As legit clients get IPs from the trusted DHCP server, DHCP snooping records each lease in its **binding table**: ``` Switch# show ip dhcp snooping binding MacAddress IpAddress Lease(sec) Type VLAN Interface ------------------ --------------- ---------- ------------- ---- ----------- AA:BB:CC:00:00:01 10.0.10.15 86400 dhcp-snooping 10 Gi0/1 ``` This table maps: user's MAC → user's IP → the VLAN → the port they're on. That's the trusted mapping DAI uses next. ## Dynamic ARP Inspection (DAI) — stop ARP spoofing ARP spoofing: attacker sends unsolicited ARP replies claiming their MAC owns the gateway's IP. Every host on the LAN updates its ARP cache. Attacker becomes the man-in-the-middle. DAI validates every ARP reply against the DHCP snooping binding table. If the ARP reply claims `10.0.10.1` is at MAC `aabb.ccdd.eeff`, DAI looks up `10.0.10.1` in the binding — if the mapping doesn't match, the ARP reply is dropped. ``` Switch(config)# ip arp inspection vlan 10 Switch(config)# interface g0/24 Switch(config-if)# ip arp inspection trust Switch(config)# interface range g0/1 - 23 Switch(config-if-range)# ip arp inspection limit rate 15 ``` Trust the uplink (real ARP traffic from the router goes through). Rate-limit user ports to prevent flood attacks. ## The trust model — three levels Ports are typed based on trust: - **Access ports (untrusted for DHCP + DAI):** where end users plug in. Untrusted for DHCP server messages, DAI validates their ARPs. - **Uplinks to trusted infrastructure (DHCP server, gateway router):** `ip dhcp snooping trust` + `ip arp inspection trust`. Trusted for DHCP server messages, ARPs pass without validation. - **Server ports (static IPs, no DHCP lease):** need special handling. Add a static binding: `ip source binding aabb.cc00.0001 vlan 10 10.0.10.99 interface g0/5`. Get the trust model wrong and either the network's not protected or you break legitimate traffic. ## Diagnostic commands ``` Switch# show ip dhcp snooping Switch# show ip dhcp snooping binding Switch# show ip arp inspection Switch# show ip arp inspection statistics Switch# show port-security Switch# show interfaces status err-disabled ``` `show ip dhcp snooping` gives you the enable state + trust configuration. `show ip arp inspection statistics` shows how many ARPs were dropped by DAI — a spike here usually means someone's actively spoofing. ## The lab you should build One switch, one router (DHCP server), one PC, one attacker PC. On the switch: 1. Enable port security on the PC port (max 2, restrict, sticky). 2. Enable DHCP snooping on VLAN 10, trust the uplink to the router. 3. Enable DAI on VLAN 10, trust the uplink. Test: - Real PC boots, gets DHCP IP, ARPs normally. All works. - Attacker PC boots, tries to advertise DHCP OFFER — dropped, log fires. - Attacker PC sends spoofed ARP claiming to be the gateway — DAI drops, log fires. - Real PC violates port security by transmitting 3 different MACs — port goes into restrict, log fires. That drill covers the three most common L2 attacks and their exact defenses. Anyone certified to CCNA level should be able to configure this cold. ## Common mistakes 1. **Enabling DAI before DHCP snooping.** The binding table is empty. Every ARP fails validation. Nothing works. Always DHCP snooping first, let clients get IPs to populate the table, then DAI. 2. **Forgetting to trust the uplink for both DHCP snooping and DAI.** Without trust, the real DHCP server's OFFER gets dropped by the switch. Users can't get IPs. Panic ensues. 3. **Port security on a trunk port.** Doesn't work as expected. Port Security is for access ports. 4. **Sticky-MAC never saved.** Sticky MACs go to running-config; if you don't `write memory`, a reboot wipes them. 5. **Static-IP servers without a binding.** DAI sees their ARP replies, doesn't find them in the binding table, drops. Users complain the server is unreachable. Fix: add a static binding. 6. **DHCP relay on the same VLAN.** If your gateway router runs `ip helper-address`, DHCP OFFER packets come back through the router — the port they arrive on is the uplink. Make sure that's trusted. ## Cheat strip | Concept | One-line meaning | |---|---| | **Port Security** | Limit MACs per access port | | **max default** | 1 MAC | | **violation default** | shutdown (err-disable) | | **sticky MAC** | Learn dynamically, save to running-config | | **DHCP snooping** | Only trusted ports may send DHCP server messages | | **Binding table** | MAC ↔ IP ↔ port map — the linchpin | | **DAI** | Validate ARP replies against binding table | | **Trust port** | Uplink toward real DHCP/gateway — everything allowed | | **Static binding** | Manual entry for servers without DHCP leases | | **err-disable recovery** | Auto-bring-back timer for err-disabled ports | ## The bigger point These three features together are the default access-layer posture in any decent enterprise network. They stop the low-effort attacks — MAC flooding, rogue DHCP, ARP spoofing — that account for the majority of L2 incidents. They're on the CCNA blueprint because they're on the daily-work blueprint. Configure them in the lab, break them, fix them, move on. When you can rattle off the three commands from memory, you've earned that portion of the exam. Everything else in Layer 2 security — 802.1X, MAB, DHCPv6 guard, IPv6 RA guard, Storm Control, Root Guard — extends this foundation. Get the base right and the rest is incremental. --- ## Standard vs Extended ACL — which one to use when — https://packetmentor.com/blog/standard-vs-extended-acl/ > A practical breakdown of Cisco IOS ACL types. When a one-line standard ACL is the right tool, when you need extended for protocol + port filtering, where to place them, and the mistakes that make ACLs silently do nothing. *Published 2026-06-27.* ACLs (Access Control Lists) are the network engineer's Swiss army knife. Filtering traffic is the obvious use, but the same syntax also drives NAT source selection, route-map matching, VTY line locking, PBR, QoS classification, and match statements for tunneled routing protocols. If you understand ACLs, half of Cisco IOS opens up. The single most common question is "standard or extended?" The answer is fast: - **Standard ACL** — filters based on *source IP only*. - **Extended ACL** — filters based on source IP, destination IP, protocol, and port. Simple in principle. But the placement rules, the direction question, and a couple of tricky edge cases keep this a top exam topic. Here's the working knowledge. ## Standard ACL — source-only, one-line filters Numbered ranges: 1–99 and 1300–1999. Or use a named ACL (usually cleaner). ``` Router(config)# access-list 10 permit 10.0.10.0 0.0.0.255 Router(config)# access-list 10 deny any ``` This ACL permits anything from `10.0.10.0/24` and drops everything else. Note the wildcard mask `0.0.0.255` — that's the inverse of `255.255.255.0`, which is CCNA-required knowledge. **Where you apply a standard ACL matters a lot.** Because standard ACLs match on source IP only, they can't distinguish "traffic from 10.0.10.5 to Server-A" from "traffic from 10.0.10.5 to Server-B." Whichever way the source is going, it's a match. Rule of thumb: **standard ACLs go as close to the destination as possible.** If you drop them too early (near the source), you block the source from reaching everything, not just the one thing you meant to block. **Named standard ACL** is often cleaner: ``` Router(config)# ip access-list standard MGMT-ONLY Router(config-std-nacl)# permit 10.0.99.0 0.0.0.255 Router(config-std-nacl)# deny any log Router(config)# line vty 0 15 Router(config-line)# access-class MGMT-ONLY in ``` That drops SSH from anywhere except the management subnet. A perfect standard-ACL use case: source-based, one condition. ## Extended ACL — source + destination + protocol + port Numbered ranges: 100–199 and 2000–2699. Or (again, cleaner) named. ``` Router(config)# ip access-list extended WEB-ONLY Router(config-ext-nacl)# permit tcp 10.0.10.0 0.0.0.255 host 172.16.5.50 eq 443 Router(config-ext-nacl)# permit tcp 10.0.10.0 0.0.0.255 host 172.16.5.50 eq 80 Router(config-ext-nacl)# deny ip any host 172.16.5.50 log Router(config-ext-nacl)# permit ip any any ``` This lets VLAN 10 clients hit the web server on 80/443 only, but everything else on the network is unaffected. Extended ACLs let you be precise. **Where you apply extended ACLs:** as close to the source as possible. Because you can match the specific destination, you don't accidentally block anything else. Dropping the packet early saves bandwidth. The rule pair is worth writing on a sticky note next to your monitor: - **Standard → near destination.** - **Extended → near source.** ## The direction — in or out? Every ACL is applied to an interface in a **direction**, either `in` (traffic entering the router through that interface) or `out` (traffic leaving through that interface). The single mistake I see most often: ``` Router(config)# access-list 20 deny host 10.0.10.5 Router(config)# access-list 20 permit any Router(config)# interface g0/0 Router(config-if)# ip access-group 20 out ``` That admin wanted to block host `.5` from going out `g0/0`. But if `g0/0` is the LAN-side interface facing hosts, "out" means traffic *going toward* the hosts — so this ACL filters return traffic based on the source (which is the return source, i.e., the server), which is not what they meant. **Draw the direction from the router's perspective.** In = coming into the router through this interface. Out = going out of the router through this interface. Now apply your standard-vs-extended placement rule. ## Implicit deny — the invisible last line Every ACL has an **implicit `deny any`** at the end. You don't see it in the config. It's there. That means: ``` Router(config)# access-list 10 permit 10.0.10.5 ``` ...permits only that one host and drops everything else. Not what you wanted if this is applied on a routed interface for the whole subnet. Corollary: if your ACL has permit statements and traffic still isn't getting through, it's the implicit deny catching the leftover. To make debugging easier, add an explicit `deny any log` at the end: ``` Router(config-ext-nacl)# deny ip any any log ``` Now the `log` keyword generates a syslog message showing what got dropped. Golden for troubleshooting. ## Wildcards — the inverse mask Standard and extended ACLs match with a **wildcard mask**, not a subnet mask. The wildcard is the *inverse* of the subnet mask. - `/24` = subnet `255.255.255.0` = wildcard `0.0.0.255` - `/28` = subnet `255.255.255.240` = wildcard `0.0.0.15` - `/30` = subnet `255.255.255.252` = wildcard `0.0.0.3` Cisco added the keywords `host` and `any` to save you the math: - `host 10.0.10.5` = `10.0.10.5 0.0.0.0` - `any` = `0.0.0.0 255.255.255.255` Wildcards can also be discontiguous — matching odd or even IPs, matching multiple subnets in one ACE. Almost never needed in CCNA-scope. Know they exist. ## Named vs numbered — always name Numbered ACLs are the legacy syntax. Named ACLs give you three things numbered ones can't easily do: 1. **Self-documenting.** `MGMT-ONLY` beats `access-list 10` for readability. 2. **In-place editing.** You can insert or remove a specific line in a named ACL: `no 30`. In a numbered ACL you have to remove the whole thing and re-enter. 3. **Sequence numbers.** Named ACLs show sequence numbers in `show access-lists`, so you can add a rule at position 25 without disturbing anything. There is essentially no reason to use numbered ACLs in new configs. ## Show commands ``` Router# show access-lists Router# show ip access-lists MGMT-ONLY Router# show ip interface g0/0 | include access ``` `show access-lists` gives you hit counts per line. Hit counts are the primary troubleshooting tool: if a permit line has zero hits after 10 minutes of testing, either the traffic isn't reaching this router, or an earlier line is matching first. ## Common mistakes 1. **Standard ACL near the source.** Blocks the source from reaching *everything*, not just the intended destination. Standard = near destination. 2. **Extended ACL near the destination.** Wastes bandwidth carrying the packet across the network to drop it at the last hop. Extended = near source. 3. **Forgetting the implicit deny.** A single permit line drops everything else. Add `permit ip any any` if that's not what you want. 4. **Wildcard confusion.** `10.0.10.0 0.0.0.255` matches `10.0.10.0/24`. Beginners write `255.255.255.0`, which means "match only 10.0.10.0 exactly" — wrong. 5. **Direction confusion.** `in` and `out` are from the router's perspective. Draw arrows before you type `ip access-group`. 6. **Applying two ACLs on the same interface in the same direction.** IOS silently replaces the first with the second. Verify with `show ip interface`. 7. **Forgetting to save.** ACL edits are in running-config only. `write memory` — or your work vanishes on reload. ## The 30-second flowchart Ask three questions: 1. Do I need to match on destination or protocol/port? If yes → **extended**. If no → **standard**. 2. Where is the source? Where is the destination? Draw the flow. 3. If extended, apply near the source. If standard, apply near the destination. That's the whole method. ## Cheat strip | Concept | One-line meaning | |---|---| | **Standard ACL** | Source IP only. Range 1–99, 1300–1999. Near destination | | **Extended ACL** | Source + dest + protocol + port. 100–199, 2000–2699. Near source | | **Named ACL** | Always prefer this — readable and editable | | **Implicit deny** | Every ACL ends with an invisible `deny any` | | **Wildcard mask** | Inverse of subnet mask (0=match, 1=don't-care) | | **host / any** | Shortcuts for `x.x.x.x 0.0.0.0` and `0.0.0.0 255.255.255.255` | | **in vs out** | From the router's perspective — draw arrows | | **`log` keyword** | Emit syslog on match — golden for troubleshooting | | **`show access-lists`** | Hit counts per line — the first thing to check | Learn the flowchart. Practice the direction question. Once you can answer "standard or extended, in or out" without hesitation, ACLs stop being a mystery and start being the tool they were always meant to be. --- ## HSRP walkthrough — how default gateway redundancy actually works — https://packetmentor.com/blog/hsrp-explained/ > Two routers, one virtual IP, zero downtime when the primary router dies. HSRP's active/standby election, priority, preempt, tracking, and the show commands that prove it works — plus the CCNA-favorite question about virtual MAC addresses. *Published 2026-06-22.* Every device on a subnet has a default gateway. What happens when that gateway dies? Without redundancy, every host on the subnet loses its way out. Static-configured hosts don't ARP for a new gateway. DHCP-configured hosts keep the old gateway IP in their lease. Either way, the LAN goes dark until an admin either fixes the router or manually points hosts at a different one. **HSRP** (Hot Standby Router Protocol) solves this. Two (or more) routers share a **virtual IP** and **virtual MAC** that clients use as the default gateway. If the active router fails, the standby takes over the virtual IP and virtual MAC. Clients don't notice. No ARP re-learning, no DHCP renewal, no downtime. This post walks through the model, the show commands, priority and preempt, interface tracking, and the exact CCNA-favorite question about virtual MAC addresses. ## The model — one virtual, two physical Draw two routers on a diagram: R1 and R2. Both connect to the same LAN (VLAN 10, `10.0.10.0/24`). - R1's real IP: `10.0.10.1` - R2's real IP: `10.0.10.2` - HSRP virtual IP: `10.0.10.254` - HSRP virtual MAC: `0000.0c07.acXX` (XX = HSRP group number in hex) Every PC in VLAN 10 has default gateway `10.0.10.254`. When a PC needs to reach the internet, it ARPs for `10.0.10.254`. Whichever router is currently **active** answers with the virtual MAC. The PC sends its default-route traffic to that MAC. HSRP hands the frame to the active router's OS. If the active router dies, the standby detects it (via missed HSRP hellos), promotes itself to active, and starts answering ARPs and forwarding traffic under the virtual MAC. Clients see no change. ## Priority and preempt — who's boss Each router in an HSRP group has a **priority** (default 100). Highest priority wins the active-router election. Ties broken by highest configured IP address. To make R1 the preferred active: ``` R1(config)# interface g0/0 R1(config-if)# ip address 10.0.10.1 255.255.255.0 R1(config-if)# standby 1 ip 10.0.10.254 R1(config-if)# standby 1 priority 110 R1(config-if)# standby 1 preempt ``` Without `preempt`, priority only matters at the initial election. Once R2 becomes active because R1 is down, R1 comes back online but **stays as standby forever** unless it re-preempts. `standby 1 preempt` says "as soon as I have the higher priority, take over." **This is the #1 HSRP gotcha in real deployments.** Someone configures priority correctly, an outage happens, the standby takes over, the primary reboots and comes back — and traffic keeps flowing through what everyone assumes is the standby. Six months later, when the standby *actually* fails, everyone's surprised the "primary" has no traffic. Always configure `preempt`. ## Interface tracking — the WAN uplink matters, not the LAN Priorities alone only detect complete router failure. But often the router's LAN-side interface is fine while its WAN uplink is down — meaning HSRP thinks the router is healthy while it can't actually forward traffic to the internet. **Interface tracking** fixes this. Tell HSRP to decrement priority when a specific interface goes down: ``` R1(config-if)# standby 1 track 100 decrement 20 R1(config)# track 100 interface g0/1 line-protocol ``` Now if R1's WAN link (`g0/1`) drops, R1's HSRP priority drops from 110 to 90. R2 (priority 100, with preempt) takes over. When R1's WAN comes back, priority returns to 110, and R1 re-preempts. This is the mechanism that makes HSRP genuinely resilient — not just "detects a dead router" but "detects a router with no path out." ## The virtual MAC question that CCNA loves Every HSRP group uses a specific virtual MAC address format. It's not random — it's derived from the group number. - **HSRPv1** (default): virtual MAC = `0000.0c07.acXX`, where XX = group number in hex (0–255). - **HSRPv2**: virtual MAC = `0000.0c9f.fXXX`, where XXX = group number in hex (0–4095). HSRPv2 supports IPv6 and much larger group ranges. For group 1, HSRPv1 virtual MAC = `0000.0c07.ac01`. The exam loves to give you a `show standby` output and ask "what is the virtual MAC" or "which HSRP version is this." Memorize the two prefixes: `0000.0c07.ac` (v1) and `0000.0c9f.f` (v2). ## The show commands ``` R1# show standby brief P indicates configured to preempt. | Interface Grp Pri P State Active Standby Virtual IP Gi0/0 1 110 P Active local 10.0.10.2 10.0.10.254 R1# show standby g0/0 GigabitEthernet0/0 - Group 1 State is Active 12 state changes, last state change 04:23:19 Virtual IP address is 10.0.10.254 Active virtual MAC address is 0000.0c07.ac01 Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Priority 110 (configured 110) Track object 100 state Up decrement 20 Preemption enabled Active router is local Standby router is 10.0.10.2, priority 100 (expires in 8.192 sec) Priority tracking 1 objects Track object 100 (interface Gi0/1 line-protocol), Up ``` Read that output top-to-bottom on a real router and every HSRP concept is right there. ## HSRP vs VRRP vs GLBP — the family - **HSRP** is Cisco-proprietary. Simple, well-known. - **VRRP** is an IETF open standard. Almost identical behavior. Works between Cisco and non-Cisco routers. - **GLBP** is Cisco's answer to "why should only one router forward at a time?" It load-balances client ARPs across multiple gateways in the same group, so both routers forward simultaneously. Great for high-throughput LANs — but rare on the CCNA exam. CCNA scope: HSRP is the deep-dive one. VRRP shows up as a comparison. GLBP is a bullet point. ## Common mistakes 1. **Forgetting `preempt`.** Priorities without preempt only matter at election time. Standby stays standby forever after the first failover. 2. **Setting the virtual IP to a real interface IP.** The virtual IP must be *unused* by any real interface. If R1's real IP is `.1` and you set the virtual IP to `.1` too, HSRP breaks. 3. **Not tracking the WAN uplink.** Router alive, WAN dead — HSRP happily forwards traffic into a black hole. 4. **Mixing HSRPv1 and HSRPv2 in the same group.** They won't talk. Match the version explicitly if you have interop concerns. 5. **Trusting the standby to have the same config as the active.** HSRP handles gateway-IP failover only. If R2 has different NAT, ACL, or routing config than R1, failover will surprise you. HSRP is not config replication. ## Cheat strip | Concept | One-line meaning | |---|---| | **Virtual IP** | The gateway address clients use — floats between routers | | **Virtual MAC** | `0000.0c07.acXX` (v1) or `0000.0c9f.fXXX` (v2). XX = group | | **Priority default** | 100 | | **Preempt** | Take back active role when priority is highest again | | **Track / decrement** | Drop priority when a tracked interface goes down | | **Hello / hold** | 3s / 10s default. Hold = time before standby takes over | | **Group number** | Identifier — must match on both routers | | **HSRPv1** | Legacy, up to 255 groups, IPv4 only | | **HSRPv2** | Modern, up to 4095 groups, IPv6 support | | **Active / Standby / Init / Listen / Speak** | The five states — Active is forwarding | ## Try it in your head first Two routers, both up, R1 priority 110 with preempt, R2 priority 100 with preempt. What happens if R1's LAN interface goes down? - R1's HSRP hellos stop. - R2's hold timer (10 seconds) expires. - R2 promotes to Active. Clients ARP for the virtual IP, R2 answers. - R1 comes back — its priority (110) beats R2 (100). Preempt fires. R1 becomes Active again. Now: what if R1's WAN interface goes down but LAN is fine, and there's no tracking? - R1 stays Active. All clients send their traffic to R1. R1 has no path out. Traffic drops. Add `standby 1 track 100 decrement 20`, and R1's priority drops to 90 when the WAN dies. R2 (100) beats it, preempts, takes over. Correct. The whole thing takes 30 lines of config and gives you zero-downtime gateway. Under 2 seconds of failover. Worth every minute of the CCNA drill. --- ## Spanning Tree root bridge election — the mental model — https://packetmentor.com/blog/stp-root-bridge-election/ > How switches decide which one becomes the STP root bridge, what happens when priorities tie, why lowering priority is safer than lowering MAC, and how to force the root to sit where you actually want it. *Published 2026-06-17.* If you understand the root bridge election, you understand Spanning Tree Protocol. Everything else — port roles, path costs, the blocked port, PortFast, BPDU Guard — falls out of that one decision. The most common mistake I see in early CCNA students is treating the root election as random ("whichever switch boots first" or "the one in the middle"). It's neither. It's deterministic, and once you know the tiebreaker order, the entire STP topology is predictable. ## What the root actually is Spanning Tree runs on every switch. When switches come up, they compare notes with their neighbors using **BPDUs** (Bridge Protocol Data Units) sent every 2 seconds. The purpose of that comparison is to elect one switch — the **root bridge** — that will act as the reference point for the whole L2 topology. Once the root is chosen: - Every non-root switch calculates the **shortest cost path** back to the root. - The interface on the shortest path becomes that switch's **root port**. - On every segment, one switch owns the **designated port** (the one that will forward traffic on that segment) — typically the one closer to root. - Every other port that could form a loop is **blocked**. So the whole loop-prevention story hinges on that first question: which switch is the root? ## The tiebreaker order — bridge ID Each switch has a **bridge ID** (BID) that's used to compare. The BID is 8 bytes: | 2 bytes | 2 bytes (embedded in above) | 6 bytes | |---|---|---| | Bridge priority (0–65535) | System ID extension (VLAN ID) | Base MAC address | The switch with the **lowest BID wins** the root election. Comparison happens field-by-field: 1. **Lowest bridge priority** wins. Default priority is 32768. Ties go to step 2. 2. **Lowest MAC address** wins the tiebreaker. That's it. Two steps. If nobody has changed priorities, the switch with the oldest MAC address (which usually means the oldest switch you own) becomes the root — often a legacy access switch you forgot about, sitting in a closet, hairpinning traffic the long way. That's the classic "root elected in the wrong place" bug. ## Why lowering priority is the right move You can force the root election by lowering priority on the switch you want to be root: ``` S1(config)# spanning-tree vlan 1 priority 4096 ``` Priorities in Cisco IOS come in **increments of 4096** (0, 4096, 8192, … 61440). Setting a switch to 4096 basically guarantees it's the root unless another switch is set to 0. The macro `spanning-tree vlan 1 root primary` is a shortcut — IOS looks around, checks the current root's priority, and sets this switch's priority just low enough to beat it. **Don't manipulate MAC addresses.** People occasionally suggest changing the MAC to affect root election. Bad idea. MACs are a tiebreaker of last resort — they don't survive maintenance and the intent isn't visible in the config. Priority is explicit. ## Per-VLAN root — Rapid-PVST+ On modern Catalyst switches, Rapid-PVST+ runs one STP instance per VLAN. That means each VLAN has its own root election. The trick most enterprise designs use: - Distribution switch A = root for odd VLANs - Distribution switch B = root for even VLANs This gives you traffic load-sharing across the uplinks. Half the VLANs flow through DIST-A, the other half through DIST-B. Neither uplink sits idle. ``` DIST-A(config)# spanning-tree vlan 1,3,5,7,9 root primary DIST-A(config)# spanning-tree vlan 2,4,6,8,10 root secondary DIST-B(config)# spanning-tree vlan 2,4,6,8,10 root primary DIST-B(config)# spanning-tree vlan 1,3,5,7,9 root secondary ``` `root secondary` sets a priority just above the primary so if the primary fails, this switch takes over immediately. ## How to verify — the three commands you'll live in ``` show spanning-tree summary show spanning-tree vlan show spanning-tree root ``` `show spanning-tree vlan 10` on a non-root switch is the money command. It tells you: - Who the root is (Root ID) - Where the root port faces (Root port) - What port role each interface has (Root, Designated, Alternate, Blocked) - Cost to reach root On the root switch, that same command shows `This bridge is the root` and every interface is designated. ## The lab that actually teaches it Three switches in a triangle. Default config on all three. Boot them and watch: 1. `show spanning-tree vlan 1` on each — one is the root, one blocked port somewhere. 2. Force S2 to be the root: `spanning-tree vlan 1 priority 4096`. Watch the tree reconverge. 3. Break the S2-to-S3 link. Watch the previously-blocked port unblock and traffic reroute. 4. Bring the link back. Watch the port become blocked again. That drill is the difference between "I read about STP" and "I ran STP." ## Common mistakes 1. **Doing nothing.** The default is "whoever has the lowest MAC wins," which usually elects an old access switch. Explicitly setting the distribution switch as root should be a standing item on every deployment checklist. 2. **Setting priority to a non-multiple of 4096.** IOS will reject `priority 3000`. Use `root primary` or a multiple of 4096. 3. **Forgetting Rapid-PVST+ is per-VLAN.** Setting root only for VLAN 1 doesn't affect VLAN 20's root. Set explicitly for every VLAN you care about, or use a range command. 4. **Turning STP off.** Yes, some people still do it "for performance." Don't. Modern switches converge in sub-second on RSTP; turning STP off gains you nothing and risks a loop that will melt your network. 5. **Not using PortFast on edge ports.** Access ports for hosts (PCs, phones) should be PortFast + BPDU Guard. Without PortFast, every host boot waits 30 seconds for the port to go through STP states. With BPDU Guard, if anyone plugs a switch into that port, it err-disables — protecting your root election from a rogue switch. ## Cheat strip | Concept | One-line meaning | |---|---| | **Root bridge** | Switch with lowest BID. Reference point for the whole topology | | **BID** | 8 bytes = priority (2) + MAC (6). Lower wins | | **Priority default** | 32768. Increments of 4096 | | **root primary macro** | Sets priority low enough to beat current root | | **root secondary macro** | Sets priority just above primary — hot standby | | **Root port** | The port on the shortest path to root — one per non-root switch | | **Designated port** | The port that forwards on each segment — one per segment | | **Blocked port** | The one that would create a loop — one per loop | | **BPDU** | The message switches exchange to compute the tree — every 2 s | | **RSTP** | Rapid STP (802.1w). Sub-second convergence. Default on modern Catalyst | | **Rapid-PVST+** | One RSTP instance per VLAN — Cisco default | ## What to try tonight Log into a lab (Packet Tracer works). Build the three-switch triangle. Force each switch to be the root in turn. Watch which ports change role. Fail a link. Watch reconvergence. Then read `show spanning-tree vlan 1` on each switch and predict, before you look, what it will say. That's the exercise that makes STP click. Once it clicks, port security, VLANs, and inter-VLAN routing all get easier — because you finally have a mental model for how the Layer 2 topology is shaped. --- ## Inter-VLAN Routing — SVIs vs Router-on-a-Stick (CCNA) — https://packetmentor.com/blog/inter-vlan-routing-svi-vs-router-on-a-stick/ > Free CCNA-level inter-VLAN routing tutorial for US networking learners. Why VLANs can't talk by default, router-on-a-stick with dot1Q sub-interfaces, the Layer-3 switch SVI method real networks use, and the #1 mistake that leaves SVIs up but routing dead. *Published 2026-06-12.* You built your VLANs, trunked the switches, and everything inside each VLAN pings perfectly. Then VLAN 10 tries to reach VLAN 20 and... nothing. That's not a bug — that's VLANs doing exactly what they're designed to do. Making them talk to each other is **inter-VLAN routing**, and there are two ways to do it: the one you learn first, and the one production networks actually use. This tutorial makes the *why* click, then walks both methods — **router-on-a-stick** and the **Layer-3 switch SVI** — so you know which to reach for and can spot the one mistake that fakes everyone out. For the full reference (routed ports, latency trade-offs, verification deep-dive), see the [Inter-VLAN Routing library topic](/topics/inter-vlan-routing/). ## Why VLANs can't talk by default A VLAN is a **separate broadcast domain**. Two PCs in different VLANs are, as far as the switch is concerned, on two completely different switches — there is no Layer-2 path between them, by design. That's the whole point of VLANs: isolation. To move a packet *between* two broadcast domains you need a device that operates at **Layer 3** — something that can look at the destination IP, make a routing decision, and forward the packet into the other VLAN. That device is either a **router** or a **switch that can route** (a Layer-3 switch). Pick one of two wiring styles: | Method | What it is | Use it for | |---|---|---| | **Router-on-a-stick** | One router interface, one sub-interface per VLAN, all over a single trunk | Labs, small offices (≤ 4 VLANs), branch routers | | **Layer-3 switch (SVIs)** | A switch routing between VLANs in hardware, one virtual interface per VLAN | Production — every campus and data center | ## Method 1 — Router-on-a-stick One physical router interface carries every VLAN by splitting into **sub-interfaces**, each tagged with its VLAN's 802.1Q ID: ``` R1(config)# interface Gi0/0 R1(config-if)# no shutdown R1(config)# interface Gi0/0.10 R1(config-subif)# encapsulation dot1q 10 R1(config-subif)# ip address 10.0.10.1 255.255.255.0 R1(config)# interface Gi0/0.20 R1(config-subif)# encapsulation dot1q 20 R1(config-subif)# ip address 10.0.20.1 255.255.255.0 ``` The switch port facing the router must be a **trunk** carrying those VLANs: ``` SW1(config)# interface Gi0/24 SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk allowed vlan 10,20 ``` A frame from VLAN 10 rides the trunk up to `Gi0/0.10`, the router routes it, and it comes back down tagged for VLAN 20. Simple and exam-friendly. **The catch:** every inter-VLAN packet crosses that one trunk link *twice*. All inter-VLAN traffic shares that single cable's bandwidth. Fine for a small office, a bottleneck anywhere serious. (If that trunk is silently dropping a VLAN, that's its own classic ticket — see [Why your trunk isn't passing a VLAN](/blog/trunk-not-passing-vlan/).) ## Method 2 — Layer-3 switch SVIs (what production uses) Modern Catalyst switches route in hardware. Instead of hauling traffic out to a router, the switch routes between VLANs itself using **Switched Virtual Interfaces (SVIs)** — one virtual Layer-3 interface per VLAN: ``` SW1(config)# ip routing ! <-- the line everything depends on SW1(config)# interface vlan 10 SW1(config-if)# ip address 10.0.10.1 255.255.255.0 SW1(config-if)# no shutdown SW1(config)# interface vlan 20 SW1(config-if)# ip address 10.0.20.1 255.255.255.0 SW1(config-if)# no shutdown ``` That's it. The switch is now the default gateway for both VLANs, and inter-VLAN traffic switches at wire speed — no trunk to bottleneck, no separate router to buy. This is the method you'll see on virtually every real campus network. ## The #1 mistake: SVIs up, routing dead Here's the trap that catches everyone exactly once. You configure the SVIs, they show `up/up`, the IPs are right — and inter-VLAN ping still fails. You'll stare at the SVIs convinced they're broken. They're not. You forgot **`ip routing`**. A Layer-3 switch ships as a Layer-2 switch by default; without that one global command it will bring the SVIs up but flatly refuse to route between them. Turn it on and traffic flows instantly. The proof is in the routing table — after `ip routing`, each SVI shows up as a connected route: ``` SW1# show ip route C 10.0.10.0/24 is directly connected, Vlan10 C 10.0.20.0/24 is directly connected, Vlan20 ``` Two connected routes = the switch knows it can deliver to both VLANs. No connected routes for your SVIs = `ip routing` is off, or the SVI is down. ## The other two gotchas Once routing is on, two host-side mistakes account for almost every remaining failure: 1. **Wrong default gateway on the PC.** Each host must point its default gateway at *its own* VLAN's L3 interface (the SVI or sub-interface IP). Point a VLAN 10 host at the VLAN 20 gateway and it can't reach anything off-subnet. 2. **Trunk doesn't allow the VLAN** (router-on-a-stick). If `switchport trunk allowed vlan` leaves out VLAN 20, the `.20` sub-interface never sees a single frame — routing looks broken when it's really a trunk filter. Memorize the order of attack: **`ip routing` → SVIs up → host gateways → trunk allowed-list.** That sequence resolves nearly every inter-VLAN ticket you'll ever open. ## SVI or router-on-a-stick — which to pick? Short version: **use a Layer-3 switch with SVIs whenever you have one.** It routes in hardware, scales, and has no trunk bottleneck. Reach for router-on-a-stick only when you're stuck with a Layer-2-only switch and a separate router — small branches, labs, the exam's "configure inter-VLAN with a router" question. Knowing *when* to use each is exactly the kind of judgment that separates a tech who memorized commands from an engineer. ## See it move This is a topic where watching beats reading — set up both methods and watch a ping cross VLANs: - **[VLAN & trunk simulator](/simulators/vlan-trunk/)** — build VLANs, trunk the link, and watch tagged frames cross between switches so the 802.1Q part stops being abstract. - **[Inter-VLAN routing hands-on lab](/topics/inter-vlan-routing/)** — configure router-on-a-stick, then rebuild the same network with SVIs on a Layer-3 switch, and prove inter-VLAN ping works both ways. Then disable `ip routing` and watch it die — the fastest way to burn that command into memory. ## What's next - [Inter-VLAN Routing — full library topic](/topics/inter-vlan-routing/) — routed ports, latency trade-offs, and full verification. - [VLANs without the overload](/blog/vlans-without-the-overload/) — get the VLAN fundamentals solid first. - [Why your trunk isn't passing a VLAN](/blog/trunk-not-passing-vlan/) — the troubleshooting companion to this post. Inter-VLAN routing is two methods and one command you can't forget — and wiring it up until the failure modes are reflex is precisely what we drill on live gear in the [1:1 CCNA program](/training/ccna/). First session is free. --- ## DHCP — DORA, Scopes, and the ip helper-address Relay (CCNA) — https://packetmentor.com/blog/dhcp-explained-dora-and-relay/ > Free CCNA-level DHCP tutorial for US networking learners. The DORA exchange step by step, why every message is a broadcast, the Cisco IOS server config, ip helper-address relay across subnets, and the show commands that prove leases are landing. *Published 2026-06-10.* Every device you've ever plugged into a network — laptop, phone, printer, the badge reader by the door — booted up with no IP address and somehow got one within a second. That's DHCP. It runs everywhere, it's about 10% of the CCNA, and it breaks in exactly three predictable ways. So this tutorial does two things: makes the **DORA** exchange click so the theory questions are free points, then walks the config and the *one command* that trips up every routed network — `ip helper-address`. This is the CCNA-scoped version; for the full options table, lease timing (T1/T2), DHCPv6, and the debug workflow, see the complete [DHCP library topic](/topics/dhcp/). ## The one-line idea A device that just powered on has no IP, so it can't send normal (unicast) traffic — there's no source address to put in the packet. Its only move is to **shout to the whole local network**: > *"Hello? Anyone? I need an IP."* A DHCP server hears the shout and hands back an address, mask, gateway, and DNS. That's the entire job. Everything else is detail. ## DORA — the four messages The handshake has four steps, and the mnemonic *DORA* is all you need to remember the order: ``` D — DISCOVER client → broadcast: "I have MAC aa:bb:cc:11:22:33. I need an IP." O — OFFER server → broadcast: "Here's 10.0.0.45/24, gateway .1, DNS 8.8.8.8, lease 1 day." R — REQUEST client → broadcast: "I'll take 10.0.0.45, offered by server .1." A — ACK server → broadcast: "Confirmed. It's yours until the lease expires." ``` | # | Message | From | To | UDP ports | |---|---|---|---|---| | 1 | **D**iscover | Client (`0.0.0.0`) | Broadcast `255.255.255.255` | 68 → 67 | | 2 | **O**ffer | Server | Broadcast | 67 → 68 | | 3 | **R**equest | Client | Broadcast | 68 → 67 | | 4 | **A**ck | Server | Broadcast | 67 → 68 | Two exam facts hide in that table: - **All four are broadcasts.** The client has no IP yet (Discover, Request), and the Request is broadcast *on purpose* so any losing DHCP servers see it and release the address they had tentatively held. - **UDP 67 = server, UDP 68 = client.** Memorize the pair. A surprising number of questions hinge on knowing the server listens on 67. ## The config — a router as a DHCP server A branch router or Layer-3 switch can be the DHCP server itself. Three pieces: exclude the addresses you don't want handed out, define the pool, point clients at a gateway and DNS. ``` ! 1. Reserve the addresses the pool must NOT give away R1(config)# ip dhcp excluded-address 10.0.0.1 10.0.0.10 ! 2. Define the scope R1(config)# ip dhcp pool USERS R1(dhcp-config)# network 10.0.0.0 255.255.255.0 R1(dhcp-config)# default-router 10.0.0.1 R1(dhcp-config)# dns-server 8.8.8.8 1.1.1.1 R1(dhcp-config)# lease 1 ``` The single most common rookie mistake lives in line 1. **Always exclude the gateway** (and any static servers/printers). Skip it and the pool will happily lease out `10.0.0.1` — the router's own IP — and now two devices fight over the same address. If subnetting still slows you down here, read [Subnetting in your head](/blog/subnetting-magic-numbers/) first; DHCP scopes are obvious once CIDR is automatic. Prove it works with the one command you'll use every day on the job: ``` R1# show ip dhcp binding IP address Client-ID/Hardware address Lease expiration Type 10.0.0.11 0100.5056.b3.22.45 Jun 11 2026 09:14 AM Automatic 10.0.0.12 0100.5056.b3.91.07 Jun 11 2026 09:15 AM Automatic ``` If you see leases, DORA completed. If the table is empty, the client never got an Offer — and 90% of the time, that's the next section. ## The line everyone forgets: `ip helper-address` Here's the catch that defines real networks: **routers don't forward broadcasts.** DORA is all broadcasts. So the moment your DHCP server sits on a *different* subnet from the client — which is the normal enterprise setup — the Discover hits the router and dies right there. The symptom is unmistakable: the client self-assigns a **`169.254.x.x`** address (APIPA). That number means *"I asked for DHCP and got total silence."* The fix is one command on the **client-facing** interface, pointing at the server: ``` R1(config)# interface Vlan10 R1(config-if)# ip helper-address 10.99.0.5 ``` Now the router stops dropping the broadcast and instead **relays** it as a unicast to the server, stamping the request with its own interface IP (the `giaddr` field) so the server knows which scope to lease from. The Offer comes back through the router to the client. One line, and DHCP crosses the Layer-3 boundary. > **The rule:** every client subnet whose DHCP server lives elsewhere needs its own `ip helper-address`. Add a new VLAN, forget the helper, and *only that VLAN* fails to get IPs while every other VLAN works fine — the classic "new VLAN, no DHCP" ticket. For the deeper relay mechanics and Option 82, see [DHCP Relay](/topics/dhcp-relay/). ## The 3 ways DHCP actually breaks Almost every "I'm not getting an IP" ticket is one of these: 1. **`169.254.x.x` on the client** → no server reachable. Different subnet? Add `ip helper-address`. Same subnet? Check the switch port / VLAN. 2. **A duplicate-IP conflict** → you forgot `ip dhcp excluded-address` for the gateway or a static device. Exclude it, then `clear ip dhcp conflict *`. 3. **A rogue DHCP server** → someone plugged in a home router and it's handing out a bogus gateway, silently MITM-ing the VLAN. The defense is **DHCP Snooping**: trust only the uplink toward the real server, drop server-side messages everywhere else. That's its own topic — see [DHCP Snooping](/topics/dhcp-snooping/). Knowing those three failure modes cold is worth more on the exam *and* the job than memorizing every option number. ## Put it on real gear Reading about DORA gets you halfway. Watching a lease land — then breaking it on purpose and fixing it — is what makes it stick: - **[DHCP hands-on lab](/topics/dhcp/)** — build the server scope, set a PC to DHCP, watch the binding table fill, then move a client to another subnet, watch it fail with APIPA, and fix it with `ip helper-address`. The "aha" is seeing the `169.254` address flip to a real lease the instant you add the helper. Do it once and the relay command will never leave your head. ## What's next - [DHCP — full library topic](/topics/dhcp/) — the complete reference: every option number, T1/T2 lease renewal, DHCPv6, and an 8-scenario debug workflow. - [DHCP Relay](/topics/dhcp-relay/) — `ip helper-address` in depth, plus Option 82. - [NAT & PAT explained](/blog/nat-pat-explained/) — the other half of IP Services, and the other guaranteed exam points. DORA is four messages and the helper is one command — but tying them together until they're reflex is exactly the kind of "make it automatic" repetition we drill on live gear in the [1:1 CCNA program](/training/ccna/). First session is free. --- ## Layer 2 Security — DHCP Snooping, DAI, and IP Source Guard (CCNA) — https://packetmentor.com/blog/layer-2-security-explained/ > Free tutorial on Cisco access-layer security for US networking learners. How DHCP snooping, Dynamic ARP Inspection (DAI), IP Source Guard, port security and 802.1x stack together to lock down the switch port — with the config and show commands. *Published 2026-06-09.* Every routing protocol, every ACL, every firewall rule assumes one thing: that the device plugged into the switch port is who it claims to be. The **access layer** — the edge port under someone's desk — is where that assumption gets attacked. Layer 2 has almost no built-in trust, so Cisco bolts on a stack of features to add it. The trick is that these features are not independent. **DHCP snooping is the foundation the other two stand on.** Learn them in the right order and the whole stack clicks; learn them at random and they feel like five disconnected commands. This is the order. ## The one-line idea Layer 2 was designed to be plug-and-play, which means it trusts everything. Access-layer security is a set of features that replace "trust everything" with "trust only what we can prove." A switch frame carries a source MAC and (inside it) a source IP, but nothing forces those to be *real*. An attacker on an access port can: - claim to be the **default gateway** (ARP spoofing → man-in-the-middle), - hand out **rogue DHCP** leases, - **spoof a source IP** to impersonate another host, - flood the **MAC table** to turn the switch into a hub. Each feature below shuts one of those doors. ## The stack, bottom to top | Feature | Attack it stops | What it inspects | Layer | |---|---|---|---| | **[Port security](/topics/port-security/)** | MAC flooding / unknown devices | Source MAC count per port | CCNA | | **[DHCP snooping](/topics/dhcp-snooping/)** | Rogue DHCP servers | DHCP messages on untrusted ports | CCNA | | **[Dynamic ARP Inspection](/topics/dynamic-arp-inspection/)** | ARP spoofing / MITM | ARP replies vs the snooping table | CCNA | | **[IP Source Guard](/topics/ip-source-guard/)** | IP / MAC spoofing | Source IP+MAC vs the snooping table | CCNA/CCNP | | **[802.1X](/topics/dot1x/)** | Unauthorized users | Identity, before the port opens | CCNA/CCNP | Notice the middle three share one engine: the **DHCP snooping binding table**. Build that table once and DAI and IP Source Guard get their truth for free. ## 1. DHCP snooping — the foundation DHCP snooping splits every switch port into **trusted** or **untrusted**. Only trusted ports (the ones facing your real DHCP server / uplinks) may send DHCP *server* messages (OFFER, ACK). An untrusted access port that tries to answer DHCP gets its frames dropped — that kills the rogue-DHCP attack. The side effect is the valuable part. As legitimate clients lease addresses, the switch records each one in the **binding table**: ``` MAC Address IP Address Lease(sec) Type VLAN Interface 00:11:22:33:44:55 10.0.0.20 86400 dhcp-snooping 10 Gi0/3 ``` That single line — "MAC `…44:55` legitimately owns IP `10.0.0.20` on port `Gi0/3`" — is the source of truth DAI and IP Source Guard both consult. ``` SW(config)# ip dhcp snooping SW(config)# ip dhcp snooping vlan 10 SW(config)# interface Gi0/1 ! uplink toward the real DHCP server SW(config-if)# ip dhcp snooping trust ! all other access ports stay untrusted by default SW(config-if)# ip dhcp snooping limit rate 10 ! optional: cap DHCP pkts/sec ``` Verify: ``` SW# show ip dhcp snooping SW# show ip dhcp snooping binding ! the table everything else depends on ``` **The #1 mistake:** forgetting to `trust` the uplink. If the port toward your real DHCP server is left untrusted, the switch drops the server's OFFER and *legitimate* clients stop getting addresses. (See the full walkthrough in [DHCP snooping](/topics/dhcp-snooping/), and how the lease process works in [DHCP](/topics/dhcp/).) ## 2. Dynamic ARP Inspection (DAI) — stop the man in the middle ARP has no authentication. Any host can broadcast "I am `10.0.0.1`" (the gateway), poison everyone's ARP cache, and quietly relay traffic — a classic man-in-the-middle. **DAI** intercepts ARP replies on untrusted ports and checks each one against the snooping binding table. If the MAC↔IP pair doesn't match a real lease, the ARP is dropped. ``` SW(config)# ip arp inspection vlan 10 SW(config)# interface Gi0/1 SW(config-if)# ip arp inspection trust ! uplinks/trunks: trusted ``` Trusted ports skip inspection (your uplinks and inter-switch links). Untrusted access ports get every ARP reply validated. ``` SW# show ip arp inspection SW# show ip arp inspection statistics ! watch the Dropped counter ``` Two CCNA gotchas: - **Trust your DAI ports the same way you trust your snooping ports.** A trunk that's snooping-trusted but DAI-untrusted will start dropping legitimate ARPs. - **Static-IP hosts have no DHCP lease**, so they're not in the binding table and DAI will drop their ARP. Cover them with an **ARP ACL** (`ip arp inspection filter`). Full detail and a fix-it lab: [Dynamic ARP Inspection](/topics/dynamic-arp-inspection/). The underlying protocol it abuses is in [ARP](/topics/arp/). ## 3. IP Source Guard (IPSG) — stop IP spoofing DAI validates ARP; **IP Source Guard validates the data frames themselves.** Once enabled on a port, IPSG installs a per-port filter that only permits traffic whose **source IP (and optionally source MAC)** matches the snooping binding for that port. Spoof a different source IP and the frame is dropped at ingress. ``` SW(config)# interface Gi0/3 SW(config-if)# ip verify source ! filter by source IP SW(config-if)# ip verify source port-security ! also filter by source MAC ``` Verify: ``` SW# show ip verify source SW# show ip source binding ``` This is what the query *"what does IP source guard protect against?"* is really asking: **source-IP spoofing on the access port.** It needs port security enabled too if you want the MAC-level check. Walkthrough: [IP Source Guard](/topics/ip-source-guard/). ## 4. Port security — the MAC gatekeeper [Port security](/topics/port-security/) is the oldest and simplest: limit how many (and optionally *which*) source MACs a port will accept, and decide what happens on a violation. ``` SW(config-if)# switchport port-security SW(config-if)# switchport port-security maximum 2 SW(config-if)# switchport port-security mac-address sticky SW(config-if)# switchport port-security violation restrict ! shutdown | restrict | protect ``` ``` SW# show port-security interface Gi0/3 ``` Know the three violation modes cold — that's a guaranteed exam point: | Mode | Drops traffic? | Logs/counter? | Port state | |---|---|---|---| | `protect` | yes | no | stays up | | `restrict` | yes | yes | stays up | | `shutdown` (default) | yes | yes | **err-disabled** | It also feeds the source-MAC check in IP Source Guard, which is why it belongs in the stack. How the switch learns MACs in the first place: [MAC address table](/topics/mac-address-table/). ## 5. 802.1X — authenticate the user, not just the address Everything above trusts the *address*. **[802.1X / dot1x](/topics/dot1x/)** trusts the *identity*: the port stays closed until the device proves who it is to a RADIUS server. It's the access-layer front door, and it's where [AAA](/topics/aaa/) and [Cisco ISE](/topics/cisco-ise-basics/) come in. ``` SW(config)# aaa new-model SW(config)# dot1x system-auth-control SW(config-if)# authentication port-control auto SW(config-if)# dot1x pae authenticator ``` The query *"authentication port-control auto"* is exactly this line — `auto` means "run 802.1X and open the port only on success" (vs `force-authorized` = always open, `force-unauthorized` = always shut). ## How they fit together (the mental model) ``` ┌─────────────── 802.1X ───────────────┐ "Are you allowed on at all?" │ ┌─────────── Port security ──────┐ │ "How many / which MACs?" │ │ ┌─────── IP Source Guard ──┐ │ │ "Is your source IP real?" │ │ │ ┌─── DAI ────────────┐ │ │ │ "Is your ARP honest?" │ │ │ │ DHCP snooping │ │ │ │ "(builds the truth table)" Access port ───────────────────────────────────► switch fabric ``` DHCP snooping builds the binding table; DAI and IP Source Guard read it; port security counts MACs; 802.1X decides whether the conversation happens at all. **Configure them bottom-up** — snooping first, always. ## Common mistakes (memorize these) 1. **DAI or IPSG without DHCP snooping.** No binding table → everything is "untrusted" → legitimate traffic is dropped. Snooping is a prerequisite, not an option. 2. **Forgetting to trust the uplink** (for both snooping *and* DAI). The most common reason "the whole VLAN broke." 3. **Static-IP hosts under DAI/IPSG.** No lease = not in the table = dropped. Use ARP ACLs / static IP source bindings. 4. **Assuming `restrict` shuts the port.** Only `shutdown` err-disables it. Mixing these up loses easy marks. 5. **Securing the access layer but leaving trunks open.** Most of these attacks launch from an access port — that's where the controls belong. ## Try it yourself These are exactly the topics where reading isn't enough — you have to watch a frame get dropped to believe it. Each library topic has a hands-on lab: - **[DHCP snooping](/topics/dhcp-snooping/)** — build the binding table, then watch a rogue DHCP server get silenced. - **[Dynamic ARP Inspection](/topics/dynamic-arp-inspection/)** — poison an ARP cache, enable DAI, watch the attack die. - **[IP Source Guard](/topics/ip-source-guard/)** — spoof a source IP and see it dropped at the port. Do snooping first — the other two won't make sense (or work) without it. ## What's next - [Port security](/topics/port-security/) and [MAC address table](/topics/mac-address-table/) — the Layer-2 fundamentals underneath all of this. - [802.1X / dot1x](/topics/dot1x/), [AAA](/topics/aaa/), [Cisco ISE](/topics/cisco-ise-basics/) — identity-based access control, the CCNP direction. - [Spanning Tree](/topics/spanning-tree/) + [BPDU Guard / Root Guard](/topics/bpdu-guard-root-guard/) — the *other* half of access-layer hardening. The whole stack is one idea repeated five ways: **don't trust the port — prove it.** Get the order right (snooping → DAI → IPSG → port security → 802.1X) and access-layer security stops being a pile of commands and becomes a single layered defense. We drill exactly this kind of "why, in what order, and what breaks if you skip a step" on real gear in the [1:1 CCNA/CCNP program](/training/ccna/). First session is free. --- ## NAT & PAT — Inside Local, Inside Global, and Overload (CCNA) — https://packetmentor.com/blog/nat-pat-explained/ > Free CCNA-level NAT and PAT tutorial for US networking learners. Static vs dynamic vs PAT/overload, the four inside/outside local/global terms decoded, the config, and the show commands that prove it works. *Published 2026-06-06.* NAT is not a hard topic. The *concept* — a router rewriting IP addresses as packets cross it — takes about thirty seconds to understand. What trips people up is the **vocabulary**: inside local, inside global, outside local, outside global. Four terms that sound interchangeable and aren't. So this tutorial does two things: makes the concept click, then nails down the four terms so the exam questions become free points. This is the CCNA-scoped version — for carrier-grade NAT, NAT64, and the deeper edge cases, see the full [NAT & PAT library topic](/topics/nat/). ## The one-line idea The public internet ran out of IPv4 addresses years ago. NAT is the workaround that kept it running. Organizations use **private IP ranges** (RFC 1918) internally — addresses the public internet refuses to route: | Range | Typical use | |---|---| | `10.0.0.0/8` | Large enterprise | | `172.16.0.0/12` | Mid-size networks | | `192.168.0.0/16` | Home + small business | When a private host wants to reach the internet, the **NAT router on the edge rewrites the source IP** from private to a public address it owns. The reply comes back to that public address; the router checks its translation table and rewrites the destination back to the private IP before forwarding it inside. (If `/8` and `/12` still look like magic, read [Subnetting in your head](/blog/subnetting-magic-numbers/) first — NAT is much easier once CIDR is automatic.) That's the whole mechanism. Everything else is detail. ## The three flavors | Flavor | Mapping | When you use it | |---|---|---| | **Static NAT** | Fixed 1:1 — one private IP always maps to one public IP | An inside server that must be reachable from the internet | | **Dynamic NAT** | A pool of public IPs handed out 1:1, returned when idle | Rare today — you'd need a stack of spare public IPs | | **PAT (overload)** | Many private hosts share **one** public IP, told apart by source port | The default. Every home router, every branch office | PAT is what you'll deploy 99% of the time. The exam tests all three, but knowing *which one fits a scenario* is the skill that matters. ## The four terms — the part everyone gets wrong Two axes. Learn them once and every NAT question becomes mechanical. - **Inside** = a host on *our* network. - **Outside** = a host on *someone else's* network. - **Local** = the address as seen from the **inside**. - **Global** = the address as seen from the **outside** (the routable internet). Cross the two axes and you get four combinations: | Term | Plain English | Example | |---|---|---| | **Inside Local** | Our host's private IP, *before* translation | `10.0.0.5` | | **Inside Global** | Our host's public IP, *after* translation | `203.0.113.7` | | **Outside Global** | The remote host's real public IP | `8.8.8.8` | | **Outside Local** | The remote host as seen from inside (usually = Outside Global) | `8.8.8.8` | The exam loves this question: *"`10.0.0.5` becomes `203.0.113.7` while talking to `8.8.8.8`. What is the Inside Global address?"* Answer: **`203.0.113.7`**. The mnemonic that makes it automatic: > **Inside = our hosts. Local = before translation. Global = after translation.** So "Inside Local" = our host before translation = the private IP. "Inside Global" = our host after translation = the public IP. Draw the arrow `10.0.0.5 → 203.0.113.7` and label the left side Local, the right side Global. You'll never miss it again. ## PAT — what your home router actually does Right now, every device in your house is sharing one public IP. PAT (Port Address Translation, or NAT *Overload*) makes that work by adding the **source port** to the translation: ``` Inside → Inside Global (shared) → Outside 10.0.0.5 : 50000 → 203.0.113.7 : 50000 → 8.8.8.8 : 443 10.0.0.6 : 51000 → 203.0.113.7 : 51000 → 8.8.8.8 : 443 10.0.0.7 : 52000 → 203.0.113.7 : 52000 → 8.8.8.8 : 443 ``` All three conversations leave from the *same* public IP — the router tells them apart by source port. When two hosts happen to pick the same source port, the router rewrites one of them to keep the pair unique. One CCNA gotcha worth banking: **ICMP has no ports.** So when you `ping` from behind PAT, the router can't overload on a port — it rewrites the **ICMP Query ID** instead. Same idea, different field. ## The config — the two patterns to memorize ### PAT / overload (the everyday config) ``` ! 1. Tag the interfaces R1(config)# interface Gig0/0 R1(config-if)# ip nat inside R1(config)# interface Gig0/1 R1(config-if)# ip nat outside ! 2. Pick which inside sources may be translated (an ACL) R1(config)# ip access-list standard NAT-INSIDE R1(config-std-nacl)# permit 10.0.0.0 0.0.0.255 ! 3. Enable PAT, overloading the outside interface R1(config)# ip nat inside source list NAT-INSIDE interface Gig0/1 overload ``` The `overload` keyword is what makes it PAT instead of plain 1:1 NAT. The [ACL](/topics/acls/) decides *which* inside sources get translated — point it at the wrong subnet and nothing matches (a top-3 mistake). ### Static NAT (for an inside server) ``` ! Inside server 10.0.0.50 is reachable from the internet as 203.0.113.50 R1(config)# ip nat inside source static 10.0.0.50 203.0.113.50 ``` This 1:1 mapping is permanent — it sits in the translation table even when no traffic is flowing. ## Verify it — the commands that prove NAT works ``` R1# show ip nat translations R1# show ip nat statistics ``` `show ip nat translations` is the daily driver. Healthy PAT output looks like this: ``` Pro Inside global Inside local Outside local Outside global tcp 203.0.113.7:50000 10.0.0.5:50000 8.8.8.8:443 8.8.8.8:443 tcp 203.0.113.7:51000 10.0.0.6:51000 8.8.8.8:443 8.8.8.8:443 --- 203.0.113.50 10.0.0.50 --- --- ``` The first two rows are PAT (note the protocol and ports). The last row — protocol `---`, no ports — is a **static NAT** entry: it never times out. That `---` is how you spot a static mapping at a glance. ## When NAT "isn't working" — the 6-step check Nine times out of ten in a CCNA lab, it's one of these: 1. **Interfaces tagged?** `show ip nat statistics` — does it list the correct *inside* and *outside* interfaces? You need **both**. 2. **ACL matching?** `show access-lists` — is the hit counter rising? Zero hits means the ACL's source range is wrong. 3. **Translations appearing?** `show ip nat translations` — empty table means the ACL didn't match or an interface isn't tagged. 4. **`overload` present?** Without it you get 1:1 dynamic NAT, which exhausts fast. 5. **Public IP routable back?** For static NAT, the upstream must actually route that public address to you. 6. **Right subnet in the ACL?** The ACL must permit your **inside-local** (private) sources — not the public side. ## Common mistakes (memorize these) 1. **Forgetting an interface tag.** No `ip nat inside` *and* `ip nat outside` → nothing translates. 2. **ACL pointed the wrong way.** It must list the private inside sources, not the public addresses. 3. **Dropping `overload`.** Without it, dynamic NAT runs out after the pool size. 4. **Static NAT to an IP you don't own.** Replies never arrive — usually use the router's own outside-interface IP. 5. **Assuming NAT is security.** NAT is address translation, not access control. Always pair it with a real firewall. ## Try it yourself Reading about translation tables is one thing — watching one build is another. Two free, no-login tools: - **[NAT / PAT simulator](/simulators/nat/)** — send packets from inside hosts to the internet, watch R1 rewrite the source IP and port, see the translation table fill in, then watch the reply get untranslated. Flip between PAT, static, and dynamic, and break it on purpose (missing `ip nat inside`, wrong ACL) to see exactly where traffic dies. - **[NAT / PAT "fix the lab"](/topics/nat/)** — a partially-configured Packet Tracer file where NAT is broken on purpose. Diagnose it and finish the config. Do the simulator first to build the mental picture, then the lab to build the muscle memory. ## Where NAT goes next (beyond CCNA) Once the CCNA version is solid, the real-world extensions are: **CGNAT** (your ISP doing a second layer of NAT, the `100.64.x.x` addresses), **NAT-T** (UDP 4500, how IPsec VPNs survive PAT), and **NAT64** (bridging IPv6-only clients to IPv4-only servers). They all live in the full [NAT & PAT topic](/topics/nat/) — and they all matter less as [IPv6](/topics/ipv6-basics/) rolls out, since IPv6 removes the address shortage that NAT exists to patch. ## What's next - [NAT & PAT — full library topic](/topics/nat/) — the complete reference with worked scenarios, debug workflow, and the simulator built in. - [Cisco ACLs explained](/blog/acls-the-mental-model/) — because NAT leans on an ACL to choose its sources. - [DHCP](/topics/dhcp/) and [Subnetting](/topics/subnetting/) — the two topics that make NAT labs feel effortless. The four terms are the whole battle. Get *inside local vs inside global* to reflex and the rest of NAT is just two config patterns and a `show` command. We drill exactly this kind of "make it automatic" repetition — on real gear, with feedback — in the [1:1 CCNA program](/training/ccna/). First session is free. --- ## CCNA v2.0 (2027) — What's Changing in the 200-301 Exam — https://packetmentor.com/blog/ccna-v2-2027-changes/ > Cisco announced the CCNA 200-301 v2.0 blueprint. Here's what changed — a new AI section, a big shift toward configuration and troubleshooting, six domains down to five — when it goes live (Feb 3, 2027), and which version you should actually study based on your exam date. *Published 2026-05-30.* Cisco has announced **CCNA® v2.0** — the first major refresh of the 200-301 exam since 2024. If you're studying right now, the first question is the only one that matters: **does this change what I should be doing today?** Short answer: for most people, not yet. Here's the full picture. ## First, the dates — this is the part that actually matters > The current exam (**v1.1**) is the one you sit through **early 2027**. The v2.0 exam's first test date is **February 3, 2027**. Cisco published the v2.0 exam topics on **May 20, 2026** so candidates can prepare ahead of time. So sort yourself into one of two buckets: - **Testing in 2026 or January 2027?** You're taking **v1.1**. Study the current blueprint. v2.0 is *not* your exam — don't let the news distract you. - **Testing February 2027 or later?** You'll sit **v2.0** — start factoring the changes below into your plan now. There's no "expiring soon, rush to test" pressure here. v1.1 is stable and valid for a good while yet. ## The headline change: it got more hands-on The single biggest theme in v2.0 isn't a shiny new topic — it's a **bump in difficulty across the board**. Cisco moved the bar up one notch on many existing topics: - Topics you used to just **describe**, you'll now be expected to **configure**. - Topics you used to **configure**, you'll now be expected to **troubleshoot**. > Translation: memorizing definitions gets you less far than ever. v2.0 rewards the people who've actually typed the commands — and broken, then fixed, a real config. If your current study is mostly reading and watching videos, this is the wake-up call: start *doing*. ## A brand-new AI section v2.0 retires the old standalone **Automation & Programmability** domain and folds that content (Ansible, SNMP, syslog, REST/automation) into a new combined section — alongside genuinely **new AI topics**: the basics of **AI in network operations** and **prompt engineering** for generative AI. The single AI-adjacent topic from v1.1 was dropped and replaced with broader AI coverage. This is Cisco acknowledging the obvious: AI is now part of a network engineer's toolkit, and entry-level certs are starting to reflect that. It's still a *small* slice of the exam — don't over-rotate on it — but it's no longer absent. ## Fewer domains, more weight on the core | | v1.1 | v2.0 | |---|---|---| | Number of domains | 6 | **5** | | Network Fundamentals + Switching | ~40% | **~50%** | Cisco consolidated the six v1.1 domains into five and **doubled down on fundamentals** — networking basics and switching now make up roughly **half the exam**. Security Fundamentals stays around 15%, but with more *applied* security scenarios. A handful of older topics were trimmed to make room. The message is unmistakable: **master the core.** Subnetting, switching, VLANs, routing — these aren't going anywhere, and they're worth more than ever. ## What this means for how you study Whether you test on v1.1 or v2.0, the changes all point the same direction: 1. **Type the commands.** Reading about VLANs ≠ configuring a trunk. Both exams — and v2.0 especially — want the hands. 2. **Break things on purpose.** Troubleshooting is a bigger slice now. Build a router-on-a-stick, leave off the `encapsulation dot1Q` line, and watch what happens to inter-VLAN traffic. *That's* how the lesson sticks. 3. **Get the fundamentals airtight.** Half the exam is core networking. If subnetting still makes you sweat, fix that before anything else. 4. **Don't ignore automation/AI** if you're a v2.0 candidate — but keep it in proportion. Fundamentals first, always. ## Bottom line | You are… | Study… | |---|---| | Testing **before** Feb 2027 | **CCNA v1.1** — the current blueprint, unchanged | | Testing **Feb 2027 or later** | **CCNA v2.0** — same core, more hands-on, plus AI | CCNA v2.0 isn't a reinvention. It's the same foundation, raised a notch, with AI added and a heavier lean on *doing* over *describing*. If your prep already includes real configuration and troubleshooting practice, you're building exactly the skills both versions reward — so you're future-proof either way. That's the whole point of practicing on a live console instead of a slide deck. Every config topic in our [hands-on practice library](/practice/) lets you type the real commands, see what breaks, and fix it — which is precisely what CCNA v2.0 is asking for. --- ## Cisco ACLs — Implicit Deny, Wildcards, and the 10-Second Read — https://packetmentor.com/blog/acls-the-mental-model/ > Free CCNA-level tutorial on Cisco ACLs for US networking learners. Implicit deny, wildcard masks, in vs out direction, and how to read any ACL in 10 seconds. *Published 2026-05-24.* If you've ever written an ACL that "should work" but blocks everything — you've met **implicit deny**. Let's make it stop happening. ## The one rule > Every ACL has an invisible `deny ip any any` at the bottom. You don't type it. The router adds it. That single sentence resolves about 80% of "my ACL isn't doing what I expect" cases. ## How a router reads an ACL Top to bottom. First match wins. No more processing. ``` access-list 100 permit tcp any any eq 80 access-list 100 permit tcp any any eq 443 access-list 100 deny ip any any ``` A packet hits line 1. Match? Permit, done. No? Line 2. Match? Permit, done. No? Line 3. Match? Deny, done. The third line is *technically* redundant — the implicit deny would catch it anyway — but writing it explicitly makes the intent obvious to whoever reads the config six months later. ## The 10-second ACL read Train yourself to read an ACL in three passes: 1. **What's permitted explicitly?** Skim the `permit` lines. That's the only traffic this ACL will allow. 2. **What's denied explicitly?** The `deny` lines name traffic important enough to call out. 3. **Everything else is implicitly denied.** If a packet doesn't match any line above, the invisible last line drops it. Try it on this: ``` access-list 110 permit tcp 10.0.0.0 0.0.0.255 any eq 22 access-list 110 permit tcp 10.0.0.0 0.0.0.255 any eq 80 access-list 110 deny ip any 10.0.0.0 0.0.0.255 log ``` - Permitted: SSH and HTTP from the 10.0.0.0/24 subnet, to anywhere. - Denied (loud): anything trying to reach 10.0.0.0/24 (logged so you know who's knocking). - Everything else: silently dropped by the implicit deny. ## The single biggest CCNA-level trap Apply direction matters more than the rule itself. ``` interface GigabitEthernet0/0 ip access-group 100 in ``` `in` = filter packets *arriving* on this interface.
`out` = filter packets *leaving* this interface. If you apply an ACL that permits return traffic `in` on the wrong interface, you've effectively blocked the return path of your own conversation. Half the "ACL doesn't work" tickets in the real world are direction bugs, not rule bugs. **Rule of thumb:** apply extended ACLs as close to the source as possible. Apply standard ACLs (which only check source IP) as close to the destination as possible. ## Wildcard masks — the 30-second version Subnet masks say "these bits are network." Wildcard masks say "these bits I care about; the rest I don't." A wildcard of `0.0.0.255` on `10.0.0.0` means: match anything where the first three octets are `10.0.0` and the last octet is anything. Quick conversion: subtract the subnet mask from `255.255.255.255`. | Subnet | Wildcard | |----------------|----------------| | 255.255.255.0 | 0.0.0.255 | | 255.255.255.128| 0.0.0.127 | | 255.255.255.192| 0.0.0.63 | | 255.255.0.0 | 0.0.255.255 | If math isn't your favorite thing, just remember: `/24` → `0.0.0.255`. That covers most CCNA questions. ## What to lab tonight 1. Two subnets, a router, an HTTP server on one side, a client on the other. 2. Confirm the client can reach the server (no ACL yet). 3. Write a standard ACL on the router that denies the client. Apply it `in` on the client-side interface. Test. Should fail. 4. Remove it. Write an extended ACL that permits only HTTP (port 80) from the client subnet. Apply it `in` on the client-side interface. Test HTTP — works. Test ping — fails. That's implicit deny working as designed. 5. Move the ACL to `out` on the server-side interface. Notice the behavior change. If step 5 surprises you, you've just discovered why `in` vs `out` deserves its own evening. --- **Coming next:** *Subnetting at the speed of conversation — the way pros do it on whiteboards.* Grab the roadmap below to get every post by email. --- ## VLANs Explained — Trunks, Access Ports, Native VLANs (CCNA Tutorial) — https://packetmentor.com/blog/vlans-without-the-overload/ > Free CCNA-level VLAN tutorial for US networking learners. Trunks, access ports, 802.1Q tagging, and native VLAN gotchas — the mental model that makes it click in 15 minutes. *Published 2026-05-20.* If VLANs feel mushy, it's because most courses dive into the *commands* before they explain the *idea*. Let's flip that. ## The one-line definition A VLAN is a way to pretend one switch is several switches. That's it. Everything else — trunks, tagging, native VLANs — is plumbing to make that pretense work across more than one physical switch. ## The four pieces, in order You only need four concepts. Learn them in this order or you'll get lost. ### 1. Access port An access port belongs to exactly one VLAN. The device plugged in (a laptop, a printer) has no idea VLANs exist. The switch tags traffic on the way in, strips the tag on the way out. ``` interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 ``` That port is "in VLAN 10." Done. ### 2. Trunk port A trunk port carries multiple VLANs between switches. Tags stay on the frame as it crosses the link, so the next switch knows which VLAN each frame belongs to. ``` interface GigabitEthernet0/24 switchport mode trunk switchport trunk allowed vlan 10,20,30 ``` That port can carry VLANs 10, 20, and 30 to the next switch. ### 3. The 802.1Q tag The tag is just 4 bytes of header inserted into the Ethernet frame on a trunk. It says "I belong to VLAN N." Access ports don't have tags on the wire — only trunks do. ### 4. The native VLAN The native VLAN is the one VLAN on a trunk whose frames travel **untagged**. By default it's VLAN 1, and **that's the first foot-gun**. > If both ends of a trunk don't agree on the native VLAN, frames get dropped or — worse — leak between VLANs. The safe habit: set the native VLAN to something unused on both sides, and never put real devices in VLAN 1. ``` interface GigabitEthernet0/24 switchport trunk native vlan 999 ``` ## A 30-second worked example Two switches, two VLANs (10 and 20), one trunk between them: ``` PC-A (VLAN 10) ---- [SW1] ====trunk==== [SW2] ---- PC-B (VLAN 10) PC-C (VLAN 20) ---- [SW1] PC-D (VLAN 20) ---- [SW2] ``` - PC-A's frame hits SW1's access port → SW1 tags it "VLAN 10." - It crosses the trunk **with the tag intact**. - SW2 sees the tag, sends it out the port assigned to VLAN 10. - SW2 strips the tag at the access port, hands the plain frame to PC-B. PC-C → PC-D works the same way, just with VLAN 20 tags. ## Why people get tripped up Three traps, in order of frequency: 1. **Forgetting to allow the VLAN on the trunk.** The VLAN exists; the access ports exist; but the trunk doesn't carry that VLAN ID, so traffic dies at the first switch. 2. **Native VLAN mismatch.** SW1's native is VLAN 1, SW2's is VLAN 99 — silent broken state. 3. **Forgetting that VLAN ≠ subnet, but they should match.** Routers (or SVIs on Layer-3 switches) route between VLANs. Two devices in different VLANs cannot talk without a router, period — even if you put them in the same IP subnet. ## What to lab tonight In Packet Tracer or CML: 1. Two switches, four PCs, two VLANs. 2. Confirm PC-A can ping PC-B (same VLAN, different switch). 3. Confirm PC-A *cannot* ping PC-C (different VLAN). 4. Add a router-on-a-stick or an SVI; confirm PC-A can now ping PC-C. 5. Break the trunk on purpose — change the native VLAN on one side. Watch what happens to your CDP/LLDP neighbors and Spanning-Tree messages. That last step is where the concept actually moves into your bones. Don't skip it. --- **Next up:** *ACLs: The Mental Model That Makes Them Click.* If you want it the day it drops, grab the roadmap below. --- ## OSPF in 12 Minutes — The Mental Model Before the Commands (CCNA) — https://packetmentor.com/blog/ospf-in-12-minutes/ > How OSPF actually works — the LSDB, SPF, neighbors, DR/BDR — explained as a story before you write your first router ospf 1 command. *Published 2026-05-02.* OSPF is the routing protocol most CCNA candidates fight with the longest. Not because it's actually hard — it's because most courses dump 50 commands on you before they explain *what OSPF is doing internally*. Once you have the story, the commands become trivial. Here's the 12-minute version we use in the [CCNA Career Track](/training/ccna/). ## The one-line idea Every OSPF router builds a complete map of the network, runs the same shortest-path algorithm on it, and arrives at the same forwarding decisions independently. No central coordinator. No "one router tells another what to do." Just everyone sharing the same map and doing the same math. That's it. The rest is implementation detail. ## The four things every OSPF router does ### 1. Find neighbors (Hello protocol) When OSPF starts on an interface, the router sends a multicast **Hello** packet to `224.0.0.5` every 10 seconds. Other OSPF-enabled routers on the same segment receive it and reply. Hellos contain: router ID, area ID, hello/dead timers, authentication info, list of known neighbors. For two routers to become **neighbors**: - Same area ID - Matching hello + dead timers - Same subnet mask on the connected interface - Matching authentication (if configured) If any of these mismatch, neighbors never form. This is bug #1 in CCNA OSPF labs. ### 2. Build the link-state database (LSDB) Once neighbors form, they **exchange link-state advertisements (LSAs)** — small messages describing each router's links, costs, and neighbors. A router's full database is the union of every LSA from every OSPF router in its area. Eventually all routers in the same area have **identical LSDBs** — they each know about every other router and every link. This is the "map." Every router has the same map. ### 3. Run SPF (Shortest Path First / Dijkstra's algorithm) Each router, locally, runs the same shortest-path algorithm on its LSDB to compute the best path to every destination. Because the LSDB is identical across routers, the results are consistent — no loops, no disagreements. The output is the **routing table** entries for OSPF-learned prefixes. ### 4. Forward packets Each router uses its routing table to forward packets. When a link changes (goes down, cost adjusts), the router that owns the change floods a new LSA, every router updates its LSDB, every router re-runs SPF, and the routing table converges. In OSPFv2, this typically completes in 1–5 seconds. That's the "fast convergence" claim. ## Why areas When you only have 5 routers, every router holding a complete LSDB is fine. When you have 5,000 routers, the LSDB gets huge — too big for SPF to run frequently and too noisy to maintain. **Areas** are OSPF's answer. An area is a group of routers that share a complete LSDB *for that area*. Between areas, only summary information flows — the full detail of one area's topology doesn't leak into another. Three rules to internalize: 1. Every OSPF network has an **Area 0** (the backbone). 2. Every other area must connect to Area 0 — usually through a router with one foot in each (the **Area Border Router**, or ABR). 3. Routers inside an area know that area's topology in detail; they know other areas only as summaries. Result: a 5,000-router network with 10 areas of 500 routers each → each router only computes SPF for its own 500-router area, not all 5,000. Massive scale win. For CCNA, single-area OSPF (everything in area 0) covers the exam. CCNP covers multi-area, NSSAs, virtual links, etc. ## Router ID — the OSPF identity Every OSPF router has a 32-bit **Router ID** that uniquely identifies it in the protocol. By default: 1. The highest IP on any active **loopback** interface, or 2. If no loopback, the highest IP on any active interface. You should always set it explicitly to avoid surprises: ``` R1(config)# router ospf 1 R1(config-router)# router-id 1.1.1.1 ``` The number after `router ospf` is the **process ID** — locally significant only, doesn't have to match across routers. The router ID does need to be unique across the OSPF domain. ## DR and BDR — only matter on broadcast networks On a multi-access broadcast segment (Ethernet with 5 OSPF routers attached), having every router fully adjacent with every other router = O(N²) adjacencies, which doesn't scale. OSPF's solution: elect a **Designated Router (DR)** and **Backup DR (BDR)** per segment. Every other router only forms full adjacency with the DR/BDR. The DR floods LSAs to everyone on the segment. Election rules: 1. Highest **OSPF priority** wins (default 1; setting `priority 0` removes the router from election entirely). 2. Tie-breaker: highest **router ID** wins. 3. **No preemption** — once a DR is elected, a new router showing up doesn't unseat it. This matters on Ethernet LANs with multiple routers, which is uncommon in modern designs. On point-to-point links (most WAN, most modern fabric) there's no DR — both routers are adjacent directly. ## Cost — how OSPF picks the best path OSPF's metric is **cost**, derived from interface bandwidth: ``` cost = reference-bandwidth / interface-bandwidth ``` Default reference-bandwidth is 100 Mbps. A 100 Mbps interface has cost 1; a 1 Gbps interface has cost 1 (because `100/1000 = 0.1`, rounded up to 1). That's a problem in 2026 — every interface is gigabit or better, so they all have cost 1 and the metric loses meaning. **Fix:** raise the reference-bandwidth on every router in the OSPF domain. ``` R1(config-router)# auto-cost reference-bandwidth 100000 ``` Now 1G = cost 100, 10G = cost 10, 100G = cost 1. Realistic differentiation. ## The minimum config to bring up OSPF ``` R1(config)# router ospf 1 R1(config-router)# router-id 1.1.1.1 R1(config-router)# network 10.0.0.0 0.0.0.255 area 0 R1(config-router)# network 192.168.10.0 0.0.0.255 area 0 R1(config-router)# auto-cost reference-bandwidth 100000 ``` The `network` command uses a wildcard mask (inverse of subnet mask). `0.0.0.255` means "match the first 3 octets, ignore the last." This `network` statement says "any interface whose IP falls within 10.0.0.0/24 should participate in OSPF area 0." ## The four commands you'll live in ``` R1# show ip ospf neighbor R1# show ip route ospf R1# show ip ospf interface brief R1# show ip ospf database ``` `show ip ospf neighbor` is the daily driver. If you don't see the neighbor you expect, OSPF isn't working — go check the four neighbor-matching criteria. `show ip route ospf` shows the OSPF-learned routes in your routing table — the actual output of all the work. `show ip ospf interface brief` shows which interfaces are participating, in which area, and (if applicable) the DR/BDR election results. `show ip ospf database` shows the LSDB — the map. Useful for advanced troubleshooting. ## Common mistakes 1. **Mismatched timers** — hello 5 / dead 20 on one router, hello 10 / dead 40 on the other. They never form neighbors. 2. **Mismatched area** — accidentally `area 1` on one side, `area 0` on the other. Same fate. 3. **Mismatched subnet mask** — `/24` on one side, `/30` on the other. Hellos arrive but adjacency fails. 4. **Forgetting `network` for an interface** — interface looks up, but OSPF never includes it because no `network` statement matches. 5. **Asymmetric authentication** — one side has it, the other doesn't, or wrong key. ## What's next - [OSPF Single-Area library topic](/topics/ospf-single-area/) — the full reference with verification, common designs, and lab walkthroughs. - [OSPF Multi-Area](/topics/ospf-multi-area/) (CCNP) — ABRs, LSA types, virtual links. - [Routing Decision Process](/topics/routing-decision-process/) — how the router actually picks between OSPF-learned routes and other sources. If 12 minutes of reading was enough to make the *idea* click, congratulations — that's the hard part. The commands are 30 minutes of practice, the troubleshooting is 30 hours, and the design judgment is 3 years. We compress those last two in [the 1:1 program](/training/ccna/). --- ## 'My Trunk Won't Pass VLAN 20' — A 6-Step Debug Workflow (CCNA) — https://packetmentor.com/blog/trunk-not-passing-vlan/ > Step-by-step troubleshooting for the classic CCNA-lab moment when you've configured the trunk but VLAN 20 traffic isn't reaching the other switch. *Published 2026-04-15.* You configured a trunk between two switches. VLAN 10 hosts ping each other across it just fine. VLAN 20 hosts cannot. Same trunk. Same switches. What's going on? This is one of the most common debug moments in CCNA-level labs. It catches everyone the first time. Here's the systematic workflow we use in the [CCNA Career Track](/training/ccna/) — it finds the cause in under 5 minutes 95% of the time. ## Step 1 — confirm the trunk is actually a trunk Run on **both** ends: ``` SW1# show interfaces Gi1/0/24 switchport | include Mode Administrative Mode: trunk Operational Mode: trunk ``` Both must say `Mode: trunk`. If either says `static access` or `dynamic auto`, the trunk failed to negotiate. Common cause: you set one side to `mode trunk` but left the other as default (which is `dynamic auto`) on a platform where both sides need to actively initiate. **Fix:** set both ends explicitly: ``` SW1(config)# interface Gi1/0/24 SW1(config-if)# switchport trunk encapsulation dot1q SW1(config-if)# switchport mode trunk SW1(config-if)# switchport nonegotiate ``` The `nonegotiate` disables DTP — explicit beats implicit. Configure the same on SW2's matching port. ## Step 2 — check the allowed-VLAN list Even on a fully working trunk, only VLANs in the **allowed list** cross it. ``` SW1# show interfaces Gi1/0/24 trunk Port Mode Encapsulation Status Native vlan Gi1/0/24 on 802.1q trunking 1 Port Vlans allowed on trunk Gi1/0/24 1-10 ``` That's the bug right there. `1-10` does not include VLAN 20. Even though VLAN 20 exists on the switch, the trunk is silently dropping it. **Fix:** add VLAN 20 to the allowed list. ``` SW1(config-if)# switchport trunk allowed vlan add 20 ``` The word `add` is important — without it, you overwrite the list and may lose VLAN 10. Verify: ``` SW1# show interfaces Gi1/0/24 trunk Port Vlans allowed on trunk Gi1/0/24 1-10,20 ``` ## Step 3 — confirm VLAN 20 exists in the VLAN database A subtle one. The VLAN must exist as a database entry, not just be referenced on an access port. ``` SW1# show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/0/1, Gi1/0/2, ... 10 USERS active Gi1/0/3, Gi1/0/4 99 MGMT active Gi1/0/23 ``` VLAN 20 is missing. The trunk is allowing it but the switch doesn't know what VLAN 20 *is*. Frames tagged with 20 get accepted at the trunk but then dropped because there's no internal VLAN data structure. **Fix:** create VLAN 20 in the database — on **both** switches. ``` SW1(config)# vlan 20 SW1(config-vlan)# name SERVERS SW1(config-vlan)# exit ``` On SW2 too. Now `show vlan brief` shows VLAN 20. ## Step 4 — check VTP isn't pruning it If you're running VTP (older Cisco environments), the protocol can auto-prune VLANs from trunks where it thinks they're not needed. ``` SW1# show vtp status VTP Operating Mode: Server VTP Pruning Mode: Enabled ``` If pruning is enabled and VLAN 20 has no active access ports on the other end, VTP might decide to skip flooding VLAN 20 over the trunk. Strange but it happens. **Fix:** either disable VTP pruning (`no vtp pruning`) or add an access port in VLAN 20 on the receiving switch (gives VTP the signal that VLAN 20 is "wanted"). In 2026 most environments disable VTP entirely or use VTP v3 in transparent mode. See the [VTP library topic](/topics/vtp/) for the full picture. ## Step 5 — native VLAN mismatch Less common but devastating when it happens. The **native VLAN** on a trunk is the one that travels **untagged**. If SW1's native VLAN is 1 and SW2's is 99, every untagged frame gets interpreted as the wrong VLAN. ``` SW1# show interfaces Gi1/0/24 trunk | include Native Port Native vlan Gi1/0/24 1 SW2# show interfaces Gi1/0/24 trunk | include Native Port Native vlan Gi1/0/24 99 ``` CDP / DTP will log this mismatch — check `show log` for messages like: ``` %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on interface ... ``` **Fix:** make both ends agree. Best practice: don't use VLAN 1 as native (it's also the management VLAN by default in old labs — security risk). Use an explicit unused VLAN like 999. ``` SW1(config-if)# switchport trunk native vlan 999 SW2(config-if)# switchport trunk native vlan 999 ``` Make sure VLAN 999 exists in the database on both. ## Step 6 — confirm the physical layer The least sexy step but the most common cause when steps 1–5 check out: bad cable, wrong patch, or a switchport that's `err-disabled` and looks "up" in some quick views. ``` SW1# show interfaces Gi1/0/24 status Port Name Status Vlan Duplex Speed Type Gi1/0/24 connected trunk a-full 1000 10/100/1000BaseTX ``` `connected` is what you want. `notconnect`, `disabled`, or `err-disabled` mean trouble. Recheck the cable, the patch, and the port-security configuration on user-facing ports (port security can err-disable trunks if it gets misapplied). ## The 6-step workflow as a checklist When VLAN traffic mysteriously isn't crossing a trunk: 1. **Trunk mode confirmed both ends?** 2. **VLAN in allowed list?** 3. **VLAN exists in database?** 4. **VTP pruning interfering?** 5. **Native VLAN matches?** 6. **Physical layer healthy?** This catches 95% of cases. The remaining 5% are spanning-tree blocking the trunk for that VLAN (rare), a port-channel misconfiguration (more common), or the destination host actually being in the wrong VLAN to begin with (don't laugh — common with student labs). ## How to get faster at this The fastest way is doing it 50 times in [our weekly 1:1 labs](/training/ccna/) until you stop having to think about the checklist. The slower way is reading more articles like this one. Both work — but only one closes the gap from "I read about VLANs" to "I troubleshoot VLAN issues by reflex in front of a network outage." Free first session is on the house if you want to try the format. ## More from the library - [VLANs Without the Overload](/blog/vlans-without-the-overload/) — the core mental model - [Trunks and 802.1Q](/topics/trunks-and-802-1q/) — full reference - [VLANs library topic](/topics/vlans/) - [Switching Operation](/topics/switching-operation/) --- ## The Free Certificates to Earn Before Your CCNA — https://packetmentor.com/blog/free-certs-before-ccna/ > Free Cisco and cloud certificates that thicken a junior NetEng CV before you sit the paid CCNA exam — sequenced for someone starting from help-desk or community college. *Published 2026-03-28.* The CCNA exam costs $300. Before you spend that money, you can earn three or four real certificates **for free** that already start to look like a CV. US hiring managers screening junior network engineer resumes don't expect a brand-new candidate to have CCNA only — they want to see *learning velocity*. A row of free certs proves you didn't show up at the interview empty-handed. Here's the sequence we recommend in the [CCNA program](/training/ccna/) — most students complete the free certs over the first 4–6 weeks while building the foundations for the paid exam. ## 1. NetAcad: Networking Essentials **Provider:** Cisco Networking Academy **Cost:** Free **Time:** ~30 hours self-paced This is Cisco's own gentle on-ramp to the CCNA. You'll get the basics — IP addressing, switches and routers, simple Wi-Fi — plus a digital badge that says "Cisco Networking Essentials" with a verifiable URL. For someone with no networking background, this is the right first step. For someone with a community-college IT certificate, you can probably skim it in a weekend. Sign up directly at [netacad.com](https://www.netacad.com). Search "Networking Essentials." Pick the "self-paced" version. ## 2. NetAcad: Introduction to Cybersecurity **Provider:** Cisco Networking Academy **Cost:** Free **Time:** ~15 hours Same source, same shareable badge. Covers the basics every modern network engineer is expected to recognize — threats, defense in depth, identity, encryption fundamentals. This isn't a security cert (you wouldn't claim CISSP on the back of it), but it shows you understand the threat side of the work. This pairs naturally with the [Cybersecurity Threats library topic](/topics/cybersecurity-threats/). ## 3. AWS Cloud Practitioner Essentials (AWS Skill Builder) **Provider:** AWS **Cost:** Free training (the exam is $100, but the training and digital completion badge are free) You're not becoming a cloud engineer. But every modern enterprise network touches AWS / Azure / GCP somewhere, and a junior NetEng who can't describe a VPC will lose ground to one who can. AWS Skill Builder has a free "Cloud Practitioner Essentials" learning path. Complete it for the badge. The paid exam is optional but recommended once you have the CCNA — it's another $100 line item on your resume that significantly broadens your appeal beyond pure networking shops. ## 4. Google IT Support Professional Certificate (Coursera — financial aid available) **Provider:** Google / Coursera **Cost:** Free with Coursera financial aid (apply, get approved in ~15 days), or part of $49/mo Coursera Plus This is the strongest "general IT" credential for entry-level US tech roles. Six courses, ~40 hours total. Covers help-desk skills, troubleshooting, basic networking, system administration, and security. If you're transitioning from help-desk, this credential maps directly to the work you're already doing. It's recognized by US employers including Walmart, Best Buy, Target, and a long list of tech companies that hire entry-level IT. Apply for financial aid before paying — it gets approved more often than people think. ## 5. Cisco DevNet Associate Prep (sample labs only — free) **Provider:** Cisco DevNet Sandbox **Cost:** Free for the sandbox environment; the actual DevNet Associate exam is $300 You don't need to sit the DevNet Associate exam before CCNA. But spending ~10 hours in the DevNet Sandbox playing with Cisco's REST APIs, Postman collections, and Python automation shows up well on a resume. Two specific sandboxes worth time: - **Catalyst Center (DNA Center) Always-On Sandbox** — log in, browse the inventory, run an API call. Note that on your resume. - **IOS-XE Programmability Sandbox** — run a Python script against a virtual router via NETCONF. Note that too. We cover this in [REST APIs](/topics/rest-apis/), [Python for Network Engineers](/topics/python-for-network-engineers/), and [NETCONF & YANG](/topics/netconf-yang/). ## 6. A Linux+ adjacent skill — LinkedIn Learning, Codecademy, or freeCodeCamp **Provider:** Various **Cost:** Free trials available everywhere Junior network engineers absolutely need Linux basics. SSH, `grep`, `awk`, basic scripting, `ip` commands, log reading. You don't need the CompTIA Linux+ paid cert; a 20-hour freeCodeCamp or Codecademy bash course is enough to claim "Linux familiarity" credibly. ## Suggested order | Week | What you're doing | |---|---| | **1–2** | NetAcad Networking Essentials + start CCNA core study | | **3–4** | NetAcad Cybersecurity + Subnetting drills | | **5–6** | Google IT Support (or skip if you already have IT experience) | | **7–8** | AWS Cloud Practitioner Essentials | | **9–10** | DevNet Sandbox exploration + Linux basics | | **11–14** | CCNA mock exams + interview prep | | **15–16** | Sit the CCNA | That's roughly the cadence of the [CCNA Career Track program](/training/ccna/). By the time you sit the paid exam, your LinkedIn already shows: NetAcad Networking Essentials, NetAcad Cybersecurity, Google IT Support, AWS Cloud Practitioner Essentials, plus a CCNA. Recruiters notice the stack. ## What to skip Some "free certs" are not worth the time: - **Vendor-specific firewall vendor "Associate" certs** — useful only if you'll work with that specific vendor. - **"AI / ChatGPT" certificates from random course platforms** — recognized by approximately no employer. - **Bootcamp "completion certificates"** — these don't carry weight unless paired with a real outcome. The certs above all carry weight because they come from established providers (Cisco, AWS, Google) with verifiable issuer URLs that a recruiter can actually validate. ## The real point A row of free certs isn't a substitute for the CCNA — it's the prefix. It signals that you're already learning, that you're disciplined, and that the CCNA is the *next* step in an obvious trajectory, not a Hail-Mary. That's the message a US hiring manager is reading off your resume in 6 seconds. If you want this curated and sequenced for you specifically, that's exactly what week one of the [CCNA Career Track](/training/ccna/) builds. --- ## Subnetting in Your Head — The Magic-Number Trick (CCNA) — https://packetmentor.com/blog/subnetting-magic-numbers/ > The one method that turns CCNA subnetting from 'do the binary math' into 'glance at the mask, subtract, done'. Worked examples for /27, /28, /22, /21. *Published 2026-03-12.* If subnetting feels like binary-math homework every time, you're doing it the slow way. There's a trick — the **magic number** — that turns the whole thing into a 10-second mental calculation. Once you have it, you'll never go back to writing out 32-bit binary on scratch paper. ## The idea Every subnet mask "splits" one octet of the IP address. The size of each subnet's block, in that octet, is the **magic number**: `256 − the mask value of that octet`. That's the whole trick. ## Walk through `/27` A `/27` mask is `255.255.255.224`. The interesting octet is the fourth (the only one that isn't 0 or 255). Magic number = **256 − 224 = 32**. So subnets in a `/27` are 32 addresses wide. Networks land at multiples of 32: ``` 192.168.10.0 /27 → hosts .1 – .30, broadcast .31 192.168.10.32 /27 → hosts .33 – .62, broadcast .63 192.168.10.64 /27 → hosts .65 – .94, broadcast .95 192.168.10.96 /27 → hosts .97 – .126, broadcast .127 ``` Given an IP like `192.168.10.50/27` — what's its subnet? Magic number is 32. The largest multiple of 32 that's ≤ 50 is **32**. So the subnet is `192.168.10.32/27`. Broadcast is `192.168.10.63`. Usable hosts are `.33` through `.62`. Done in 5 seconds, no binary. ## Walk through `/28` Mask `255.255.255.240`. Magic number = **256 − 240 = 16**. Subnets are 16 addresses wide: `.0`, `.16`, `.32`, `.48`, `.64`, … `.240`. `192.168.10.45/28` → biggest multiple of 16 ≤ 45 is **32**. Subnet = `192.168.10.32/28`. Broadcast = `192.168.10.47`. Hosts `.33` – `.46`. ## Walk through `/22` Now the interesting octet is the **third** (because /22 borrows into octet 3). Mask `255.255.252.0`. Magic number = **256 − 252 = 4**. Subnets are 4 addresses wide in the third octet: `0.0`, `4.0`, `8.0`, `12.0`, … `172.16.10.0/22` → biggest multiple of 4 ≤ 10 is **8**. Subnet = `172.16.8.0/22`. The full range covers `172.16.8.0` through `172.16.11.255`. Broadcast = `172.16.11.255`. That's 1,024 addresses, 1,022 usable hosts. ## Walk through `/21` Mask `255.255.248.0`. Magic number = **256 − 248 = 8**. Subnets are 8 addresses wide in the third octet: `0.0`, `8.0`, `16.0`, `24.0`, … `10.50.20.5/21` → biggest multiple of 8 ≤ 20 is **16**. Subnet = `10.50.16.0/21`, range `10.50.16.0` – `10.50.23.255`. Broadcast = `10.50.23.255`. ## The whole process — 5 steps 1. Identify the **interesting octet** (the one where the mask isn't 0 or 255). 2. Compute the **magic number**: 256 − mask value of that octet. 3. Find the **biggest multiple of the magic number** that's ≤ the IP's value in that octet → that's your **subnet's network address** for that octet. 4. **Broadcast** = network address + magic number − 1. 5. **Usable hosts** = network address + 1 through broadcast − 1. That's it. The same five steps work for every mask between /9 and /30. ## Memorize the mask table Don't compute masks every time — memorize the 8 values: | Bits | Mask value | |---:|---:| | 1 | 128 | | 2 | 192 | | 3 | 224 | | 4 | 240 | | 5 | 248 | | 6 | 252 | | 7 | 254 | | 8 | 255 | A /27 mask in the fourth octet has 3 borrowed bits → look up "3" → 224. /22 mask in the third octet has 6 borrowed bits → "6" → 252. ## How many subnets / how many hosts? - **Subnets** = `2^(borrowed bits)`. /27 from a /24 = 3 borrowed bits = 8 subnets. - **Hosts per subnet** = `2^(host bits) − 2`. /27 has 5 host bits = `2^5 − 2 = 30` hosts. These are the only formulas you need. Combined with the magic-number trick, you can answer any CCNA subnetting question in under a minute. ## Verify on real IOS The router-side proof — configure the address and read it back: ``` R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 172.20.45.90 255.255.255.192 R1(config-if)# no shutdown R1# show ip route connected 172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.20.45.64/26 is directly connected, GigabitEthernet0/0 L 172.20.45.90/32 is directly connected, GigabitEthernet0/0 ``` The `C` line confirms the subnet is `172.20.45.64/26` — exactly what the magic-number trick produces (magic 64, largest multiple of 64 ≤ 90 is 64). ## Ten-question timed drill Now put it under exam-day pressure. Set a **5-minute stopwatch** — aim: all ten answered correctly in under 300 seconds. Compute in your head, no paper. For each, give the **subnet, broadcast, and usable host range**. 1. `192.168.20.85/29` 2. `10.1.1.100/26` 3. `172.16.200.5/29` 4. `192.168.10.150/28` 5. `10.10.10.10/30` 6. `172.20.5.5/23` 7. `192.168.0.200/25` 8. `10.50.100.100/22` 9. `172.16.16.99/21` 10. `192.168.5.5/28` Try before scrolling. Answers below. --- **Answers** 1. `/29` → magic 8. 85 → biggest mult of 8 ≤ 85 = 80. Subnet `192.168.20.80/29`, broadcast `.87`, hosts `.81 – .86`. 2. `/26` → magic 64 → subnet `10.1.1.64`, broadcast `10.1.1.127`, hosts `.65 – .126`. 3. `/29` → magic 8 → subnet `172.16.200.0`, broadcast `172.16.200.7`, hosts `.1 – .6`. 4. `/28` → magic 16 → subnet `192.168.10.144`, broadcast `192.168.10.159`, hosts `.145 – .158`. 5. `/30` → magic 4 → subnet `10.10.10.8`, broadcast `10.10.10.11`, hosts `.9 – .10` (point-to-point, only 2 usable). 6. `/23`, mask `255.255.254.0`, magic 2 in 3rd octet → subnet `172.20.4.0`, broadcast `172.20.5.255`, hosts `172.20.4.1 – 172.20.5.254`. 7. `/25` → magic 128 → subnet `192.168.0.128`, broadcast `192.168.0.255`, hosts `.129 – .254`. 8. `/22`, mask `255.255.252.0`, magic 4 in 3rd octet → subnet `10.50.100.0`, broadcast `10.50.103.255`, hosts `10.50.100.1 – 10.50.103.254`. 9. `/21`, mask `255.255.248.0`, magic 8 in 3rd octet → subnet `172.16.16.0`, broadcast `172.16.23.255`, hosts `172.16.16.1 – 172.16.23.254`. 10. `/28` → magic 16 → subnet `192.168.5.0`, broadcast `192.168.5.15`, hosts `.1 – .14`. ## The #1 mistake **Forgetting to identify the interesting octet first.** Students see `/22` and reflexively work in the fourth octet — but /22 splits the third octet. Every wrong answer above traces back to this. Say the interesting octet out loud before you start computing. ## Where to go from here If you want more — the [full Subnetting library topic](/topics/subnetting/) covers the binary-math version (slower but more rigorous), VLSM (variable-length masks for efficient address allocation), and the "I have a /24 — give me four equal subnets" pattern. The magic-number trick covers 95% of what you'll see on the CCNA exam. Drill the ten questions above twice this week. By exam day you'll answer any subnetting question in under 30 seconds — and free up the minutes that decide pass or fail. ---