Dynamic ARP Inspection — Validation Checks
Harden Dynamic ARP Inspection (DAI) on an access switch by enabling additional packet validation checks: source MAC, destination MAC, and IP sanity. The uplink toward the DHCP server/gateway is trusted, access ports are untrusted. DHCP Snooping and baseline DAI are already enabled for VLAN 10; your task is to add the global DAI validation knobs and verify the change deterministically via show commands.
L2 Security Troubleshooting Capstone: Trust Boundary
Advanced CCNP Layer-2 security troubleshooting on a single access switch. Diagnose and correct an inverted trust boundary that breaks DHCP and ARP validation: DHCP Snooping and Dynamic ARP Inspection (DAI) are enabled for VLAN 10, but the uplink is not trusted for DHCP and a host port is incorrectly trusted for ARP. Use show commands to find the issues, fix the trust boundary, and restore client connectivity without changing router/host configs.
Defense in Depth: DHCP Snooping + DAI
Harden the Layer-2 access edge by deploying a unified trust boundary for DHCP Snooping and Dynamic ARP Inspection (DAI) on a single access switch. R1 is both the default gateway and DHCP server for VLAN 10. You will enable DHCP Snooping and DAI globally for VLAN 10 and set the same uplink interface as trusted for both features, leaving host-facing access ports untrusted. This lab emphasizes the dependency and synergy between DHCP Snooping and DAI for blocking rogue DHCP/ARP activity. Grade scope: SW1 config only.
Errdisable Recovery for L2 Security
CCNP Layer 2 Security Hardening, Lab 9/10. You will enable automatic errdisable recovery on a campus access switch so ports shut down by Layer-2 security (Dynamic ARP Inspection, DHCP rate-limit, or storm control) can return to service automatically after a safe interval. The switch already enforces DHCP snooping with a correct trust boundary, DAI validation, and broadcast/multicast/unicast storm-control with shutdown actions. Your job: turn on errdisable auto-recovery for arp-inspection, dhcp-rate-limit, and storm-control, and set the interval to 60 seconds. Verify with show errdisable recovery.
Discovery & Monitoring Troubleshooting Capstone
Troubleshoot a pre-broken monitoring deployment on a single shared management LAN. R1 is already configured for discovery and monitoring, but the NMS receives no syslog or SNMP traps from R1. Diagnose with show commands and correct the two seeded faults: wrong syslog target and missing SNMP trap generation. Deterministic, no-routing, single-subnet design for CML Free (5 nodes).
SNMPv3 AuthPriv Monitoring
Harden the monitoring plane by replacing cleartext SNMPv2c with authenticated and encrypted SNMPv3 (authPriv) on R1. You will create a v3 group that requires privacy and a user with SHA authentication and AES-128 encryption, then verify the configuration. The flat management LAN avoids routing complexity so you can focus on the security mechanics of SNMPv3.
IP Addressing Troubleshooting Capstone
Advanced CCNP lab focused on diagnosing and correcting IPv4 interface addressing issues on Cisco IOS routers. The lab ships pre-broken with two independently failing faults that the learner must find and fix using show commands and directed pings. No routing protocols or static routes are used — verification is limited to directly-connected neighbor and gateway reachability.
Secondary IP on a LAN Interface
Configure a Cisco IOS router to host two IPv4 /24 subnets on a single physical LAN interface using a secondary address. Verify directly-connected reachability only (no routing protocols, no static routes). This simulates a readdressing coexistence period where both old and new subnets must operate concurrently on the same segment.
IPv6 Addressing with EUI-64
Configure IPv6 global unicast on a router-to-router link using EUI-64-derived interface IDs. Enable IPv6 unicast routing, set explicit link-local addresses, and verify that each router auto-forms its 64-bit interface ID from the MAC (FFFE insertion with U/L bit flip). Validate directly-connected reachability only. No routing protocols or static routes.
IPv6 Link-Local Addressing
Advanced IPv6 interface addressing on Cisco IOS routers. Configure explicit, predictable IPv6 link-local addresses alongside global unicast addresses on a point-to-point router-to-router link. Validate with show commands and neighbor pings using the link-local as the destination, and confirm host-to-gateway reachability on local LANs. No routing protocols or static routes are used; focus is strictly on interface IPv6 addressing mechanics.
Lab 9: Dual-Stack IPv4/IPv6 Addressing on IOS
Configure and verify dual-stack IPv4 and IPv6 addressing on Cisco IOS router interfaces. R1-R2 share a /30 IPv4 and /64 IPv6 point-to-point transit, while R1 provides a dual-stack user LAN gateway. No routing protocols or router static routes are permitted; verify only directly connected reachability.
Point-to-Point Links with /30 and /31
Build confidence addressing IPv4 point-to-point WAN links on Cisco IOS using /30 and /31 masks. Two routers are connected by two parallel links: one classic /30 and one RFC 3021 /31. No routing protocols or static routes are configured — the goal is deterministic, correct interface addressing and verification of directly connected reachability. A small LAN off R1 with two hosts allows additional verification (host-to-gateway only).
IPv6 Global Unicast Addressing
Enable IPv6 forwarding and configure IPv6 global unicast addresses on directly connected links only. No routing protocols or static routes. Verify that each device can reach only its directly connected neighbors using IPv6.
Local Time with Timezones over NTP
Two-router /30 point-to-point lab. R1 is an authoritative UTC NTP master (stratum 3). Configure R2 as an NTP client to R1 and display local time in MST/MDT while remaining synchronized to UTC. Reinforces that NTP distributes UTC and the router applies timezone/daylight-saving only to presentation.
Restricting NTP with an access-group
Configure a Cisco IOS router as an authoritative NTP master and restrict which clients it will serve using an NTP access-group with a standard ACL. One shared LAN (no routing) connects three routers through a Layer-2 switch. Only R2 is authorized to receive time from R1; R3 is denied. Learners deploy, verify, and troubleshoot the access-group behavior.
Securing NTP with MD5 Authentication
Configure NTP MD5 authentication so a client (R2) synchronizes only to a trusted, authenticated master (R1). R1 is already an authoritative clock (ntp master 3). You will enable NTP authentication on both routers, define and trust key 1, and bind the key on R2's ntp server statement. Verification focuses on authenticated associations and status; actual time lock may take minutes and is not graded.
Broadcast Time on a Shared LAN
Configure a deterministic NTP broadcast design on a single shared LAN. R1 acts as an authoritative clock (ntp master 3) and broadcasts time on its LAN interface. R2 and R3 act as broadcast clients to scale time distribution without per-client server statements. Verify broadcast associations on the clients and understand the tradeoffs vs. unicast client/server.
Redundant Time Sources with prefer
Build a small LAN with two IOS routers acting as NTP masters at different strata and a client that lists both as time sources, preferring one using the prefer keyword. All routers share a single broadcast domain via a Layer-2 switch, with no routing configured. You will deploy deterministic NTP, verify associations, and understand redundancy selection behavior.
Building a Multi-Level NTP Hierarchy
Create a deterministic three-tier NTP hierarchy on a single shared LAN. R1 is the authoritative clock (ntp master 2), R2 syncs to R1, and R3 syncs to R2. No routing or additional subnets — all devices share 10.0.0.0/24 via one L2 switch. Verify with show ntp status and show ntp associations.
NTP Troubleshooting Capstone
Advanced NTP troubleshooting on a two-router /30. R2 never synchronizes its clock. Use show commands to diagnose, then correct the design intent so R2 deterministically references R1, and R1 is an authoritative time source at the agreed stratum. The starter ships with a pre-broken NTP configuration already applied; your job is to find and fix two independent faults.
Blocking Brute-Force Logins and Adding a Banner on R1
Harden the management plane of a single IOS router by throttling brute-force login attempts and presenting a legal-warning banner. You will enable SSH-based management, configure login block-for and delay to resist password-guessing, and verify behavior from an ADMIN Linux workstation.
SSH Hardening to Version 2
Harden the management-plane SSH service on a single Cisco IOS router so only SSHv2 is permitted and session limits are tightened. The baseline lab already has working SSH. You will enforce SSH version 2, set a 60-second authentication timeout, and limit authentication retries to 2. You will also regenerate a 2048-bit RSA key (an exec-only step) and validate with show commands.
AAA Named Method Lists with Fallback (VTY vs Console)
Harden a single Cisco IOS router’s management plane using AAA named method lists applied per-line. Create VTY-AUTH (local then enable) to protect remote SSH access without lockout risk, and CONSOLE-AUTH (local only) to secure the console independently. Verify using show/run sections and test SSH from the ADMIN workstation.
AAA Authentication with a Local User Database
Harden R1’s management plane by moving SSH login authentication and exec authorization under the IOS AAA framework using the local user database. You will start from a secure SSH-only baseline that still uses login local, enable aaa new-model, define default AAA methods that point at local, and bind VTY lines to AAA. Success is proven by authenticating from the ADMIN host over SSH and landing at the user’s privilege level.