CCNA lab 17 of 46
Rogue IPv6 routers: RA guard and storm control
A device on the LAN is advertising itself as an IPv6 router. Watch hosts take its prefix, trace it to a switch port from a link-local address, contain it, and build the RA guard policies and storm-control settings a Catalyst access switch would use.
Run this lab
It needs Lite: its 5 nodes are set to 5 vCPU and 4,608 MB in total. That fits the free demo too.
In your workspace: Shared, then CCNA 200-301 guided labs, then 17 - Rogue IPv6 routers - RA guard and storm control
- Level
- Advanced
- Time
- About 45 minutes
- Nodes need
- 5 vCPU, 4,608 MB
- Smallest plan
- Lite
The scenario
Larkspur Labs runs IPv6 on its office LAN: the router R1 advertises 2001:db8:17:10::/64 and hosts configure themselves with SLAAC. This morning, laptops started using a strange prefix, 2001:db8:bad:1::/64. A test router left on the lab bench (ROGUE) is plugged into S1 Gi0/3 and is sending router advertisements (RAs). You'll prove what's happening, find the rogue from the hosts' point of view, contain it, and prepare the RA guard and storm-control settings for the office's Catalyst switches.
| Device | Port on S1 | IPv6 |
|---|---|---|
| R1 (real router) | Gi0/0 | 2001:db8:17:10::1/64, fe80::1 |
| PC1 | Gi0/1 | SLAAC |
| H1 | Gi0/2 | SLAAC |
| ROGUE | Gi0/3 | 2001:db8:bad:1::1/64, RAs every 10 s |
About this switch. The virtual switch (IOSvL2) accepts RA guard policies but attaches them only per VLAN, and its software data plane doesn't filter RAs; it has no storm control at all. On a physical Catalyst access switch both features are enforced in hardware. This lab therefore has you contain the rogue with what works here, configure the RA guard policies, and write the per-port and storm-control configuration the way you would for a Catalyst. The exam asks you to know that configuration.
What you’ll practise
- Explain why router advertisements are a first-hop security risk
- Trace a rogue router from a host's routing table to a switch port
- Configure RA guard policies with host and router roles, and know how they are attached
- Make the real router preferred with router preference
- Explain and write storm-control configuration with thresholds and actions
The tasks
- Watch hosts trust the wrong router
- Trace the rogue to a port
- Contain the rogue now
- Prefer the real router
- Configure RA guard policies
- Plan storm control
- Know the rest of IPv6 first-hop security
The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.
Topology and devices
The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.
Every link, as text
- R1
Gi0/0to S1Gi0/0 - S1
Gi0/1to PC1eth0 - S1
Gi0/2to H1eth0 - S1
Gi0/3to ROGUEGi0/0
| Node | Device | Image in Add Node | Set to |
|---|---|---|---|
| R1 | Cisco IOSv | vios-adventerprisek9-m.SPA.159-3.M6 | 1 vCPU, 1,024 MB |
| ROGUE | Cisco IOSv | vios-adventerprisek9-m.SPA.159-3.M6 | 1 vCPU, 1,024 MB |
| S1 | Cisco IOSvL2 | viosl2-adventerprisek9-m.ssa.high_iron_20200929 | 1 vCPU, 1,024 MB |
| PC1 | VPCS host | Built in to EVE-NG | Counted as 1 vCPU, 1,024 MB |
| H1 | Alpine Linux | clbalpinebase-alpine-base-3-20-3 | 1 vCPU, 512 MB |
How to open this lab
Sign in to your workspace at
lab.cloudlabbox.com.In File Manager, open Shared, then the folder
CCNA 200-301 guided labs.Open
17 - Rogue IPv6 routers - RA guard and storm controland start its nodes, then open Lab Tasks for the scenario and the steps.
The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.
More CCNA labs
Related labs in other courses
CloudLabBox is independent of Cisco. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.