This chapter covers a NEW objective in the CCNA v2 exam (200-301 v2.0, 2026 blueprint): IPv6 First-Hop Security, specifically RA Guard. Cisco added this topic to address real-world IPv6 neighbor discovery vulnerabilities that have been exploited in enterprise networks. RA Guard prevents rogue Router Advertisement (RA) messages from redirecting traffic or causing denial of service. As a CCNA candidate, you must understand how RA Guard works at the frame level, its configuration on Cisco switches, and how it fits into the broader IPv6 first-hop security framework. This chapter gives you the deep, exam-focused knowledge you need.
Jump to a section
Imagine a large apartment building with a central mailroom. Each resident has a mailbox, and only the postal carrier (authorized router) should deliver mail. However, anyone could impersonate the carrier by inserting a fake key into the mailroom door, gaining access to all mailboxes, stealing packages, or redirecting deliveries. The building manager installs a special lock on the mailroom door that only accepts keys with a specific, verifiable signature (like RA Guard validation). This lock checks every key presented: if the key doesn't match the authorized carrier's pattern, the door stays locked and an alarm logs the attempt. The lock doesn't just check the key's shape (like a simple MAC address check) but also verifies a digital signature (like the router's address and prefix). If a resident tries to use a copied key, the lock rejects it immediately. Similarly, RA Guard inspects every RA message on a switch port. It checks whether the source IPv6 address matches the authorized router's address, whether the advertised prefix is legitimate, and whether the message is properly signed (if Secure Neighbor Discovery is used). If the RA fails validation, the switch drops the frame and logs a security event. Just as the lock prevents mail theft and misdelivery, RA Guard prevents rogue routers from hijacking traffic or launching man-in-the-middle attacks. The analogy also covers the concept of trust: only ports connected to known routers are allowed to send RAs, just as only the mail carrier has the authorized key. All other ports are blocked from sending RAs, preventing any unauthorized device from acting as a router.
What is RA Guard and Why Does It Exist?
RA Guard is an IPv6 First-Hop Security feature that protects against rogue Router Advertisement (RA) attacks. In IPv6, hosts use Neighbor Discovery Protocol (NDP) to automatically discover routers and configure addresses via Stateless Address Autoconfiguration (SLAAC). A malicious device can send fake RA messages claiming to be a default router, causing hosts to send traffic to the attacker (man-in-the-middle) or to a nonexistent router (denial of service). RA Guard, defined in RFC 6105, allows a switch to filter RAs based on policy, permitting only authorized routers to send RAs on specific ports.
How RA Guard Works at the Frame Level
RA Guard operates at Layer 2 on a switch. When a switch receives an IPv6 Router Advertisement (ICMPv6 type 134) on a port, it checks the port's RA Guard policy. The policy can be one of two modes:
host: The port is connected to an end host. RAs received on this port are blocked (dropped).
router: The port is connected to a trusted router. RAs are allowed.
Additionally, RA Guard can validate the source IPv6 address and prefix information. The switch examines the RA message fields:
Source IPv6 address (must match the link-local address of the authorized router)
Prefix Information Option (must match the expected on-link prefix)
Router Lifetime (non-zero indicates a default router)
If the RA fails validation, the switch drops the frame and can generate a syslog message or SNMP trap. The feature is implemented using Cisco's IPv6 First-Hop Security framework, which includes other features like DHCPv6 Guard and IPv6 Source Guard.
Key States, Timers, and Defaults
RA Guard does not have states or timers of its own; it is a static policy applied to switch ports. However, the related NDP timers are important for context:
Router Advertisement Interval: By default, Cisco routers send RAs every 200 seconds (configurable via ipv6 nd ra-interval).
Router Lifetime: Default is 1800 seconds (30 minutes), indicating how long the router is considered a default router.
For RA Guard itself, the default policy on a switch port is to allow RAs (no filtering). You must explicitly apply RA Guard with ipv6 nd raguard in interface configuration mode.
IOS CLI Verification Commands with Example Output
To verify RA Guard configuration and operation, use the following commands:
show ipv6 snooping policy
show ipv6 nd raguard policy
show ipv6 snooping counters
show ipv6 snooping interfaceExample output for show ipv6 nd raguard policy:
Router# show ipv6 nd raguard policy HOST_POLICY
RA Guard policy: HOST_POLICY
Device role: host
Policy applied to: Gi1/0/1, Gi1/0/2Example output for show ipv6 snooping interface:
Router# show ipv6 snooping interface gi1/0/1
Interface Gi1/0/1
IPv6 snooping is enabled
RA Guard is enabled
DHCPv6 Guard is enabled
IPv6 source guard is enabled
Device role: host
Number of valid RAs received: 0
Number of invalid RAs received: 2
Number of valid DHCPv6 messages: 5
Number of invalid DHCPv6 messages: 0How RA Guard Interacts with Related Protocols
RA Guard is part of the IPv6 First-Hop Security suite, which includes:
DHCPv6 Guard: Blocks unauthorized DHCPv6 server messages.
IPv6 Source Guard: Filters traffic based on source IPv6 address and prefix, preventing spoofing.
NDP Inspection: Validates Neighbor Solicitation and Neighbor Advertisement messages.
These features can be used together to create a comprehensive security perimeter at the access layer. RA Guard specifically focuses on RA messages, while the others cover different NDP message types. On the exam, you may see questions that require you to choose which feature to apply based on the attack scenario.
Identify the attack vector
Before configuring RA Guard, you must understand the threat. A rogue device sends fake Router Advertisements with a high router lifetime, causing hosts to learn a malicious default router. This can lead to traffic interception or DoS. On the exam, you may be given a scenario where users lose connectivity or traffic is being redirected. Your first step is to recognize that RA Guard is the solution for rogue RA attacks. Remember that RA Guard only filters RAs; other attacks like rogue DHCPv6 servers require DHCPv6 Guard.
Determine device roles
Identify which switch ports connect to legitimate routers and which connect to hosts. Only router-facing ports should be allowed to send RAs. Host-facing ports must block incoming RAs. This role assignment is the core of RA Guard policy. On a typical access switch, uplink ports to a router or distribution switch are 'router' ports, while ports to end devices (PCs, printers) are 'host' ports. Trunk ports carrying multiple VLANs may require careful consideration – typically, a trunk to a router is 'router', but a trunk to another switch might need different handling.
Create a RA Guard policy
Use global configuration mode to define a policy. The policy specifies the device role (host or router) and optionally validates prefixes. Example: `ipv6 nd raguard policy HOST_POLICY` then `device-role host`. For router ports, create a policy with `device-role router`. You can also specify a trusted prefix list using `trusted-prefix` under the policy. This step is critical: without a policy, the default is to allow all RAs. The exam will test whether you know that `device-role` is mandatory.
Apply the policy to interfaces
Enter interface configuration mode for each port and apply the policy using `ipv6 nd raguard attach-policy POLICY_NAME`. For example, on a host port: `interface GigabitEthernet1/0/1` then `ipv6 nd raguard attach-policy HOST_POLICY`. On a router port: `interface GigabitEthernet1/0/24` then `ipv6 nd raguard attach-policy ROUTER_POLICY`. You can also enable IPv6 snooping globally with `ipv6 snooping` which is required for RA Guard to work. Verify with `show running-config interface`.
Verify operation
After configuration, verify that RA Guard is active. Use `show ipv6 snooping interface` to see the number of valid and invalid RAs. If a rogue RA is sent on a host port, the counter for invalid RAs should increment. Use `debug ipv6 snooping raguard` to see real-time drops (use with caution in production). On the exam, you may be given a `show` command output and asked to interpret whether RA Guard is working. Look for 'RA Guard is enabled' and 'Device role: host' to confirm.
Troubleshoot misconfiguration
If legitimate RAs are being dropped, check the device role. A common mistake is setting a host port to 'router' or vice versa. Also ensure that IPv6 snooping is enabled globally. If a router port is blocking RAs, verify that the policy has `device-role router`. Another issue: if the RA source address is not link-local (e.g., global unicast), RA Guard may drop it even on a router port. Use `show ipv6 snooping policy` to review policy details. Remember that RA Guard does not inspect RAs from authorized routers beyond the role check unless prefix validation is configured.
In a large enterprise campus network, IPv6 is often deployed alongside IPv4. One common scenario is a university with thousands of student dormitory rooms. Each room has a wall jack connected to an access switch. Students may bring their own routers (e.g., home Wi-Fi routers) that could send rogue RAs, disrupting IPv6 connectivity for other students on the same VLAN. A network engineer would configure RA Guard on all access ports with a 'host' policy, blocking any RAs from student devices. Only the uplink ports to the distribution layer routers are configured with a 'router' policy. This prevents students from accidentally or maliciously acting as IPv6 routers.
Another scenario is a branch office with a single router and a few switches. An attacker could plug a rogue device into an unused wall port and send fake RAs, causing all branch traffic to go through the attacker. RA Guard on the switch ports would block these RAs if the port is configured as 'host'. However, if the attacker gains access to a trunk port, the situation is more complex. In such cases, RA Guard combined with 802.1X and port security provides defense in depth.
Performance considerations: RA Guard is a Layer 2 feature that inspects every RA frame. On high-density switches with many ports, the CPU may be impacted if there are many RAs. Cisco switches use hardware ACLs to offload RA filtering, so performance impact is minimal. Misconfiguration can cause legitimate RAs to be dropped, leading to SLAAC failures and hosts not getting IPv6 addresses. For example, if a router port is accidentally set to 'host', the router's RAs will be dropped, and all hosts on that VLAN will lose IPv6 connectivity. This is a common pitfall. Network engineers must carefully document port roles and use consistent policy naming.
New in CCNA v2
This topic is entirely new in the CCNA v2 exam (200-301 v2.0, 2026 blueprint). In v1.1, IPv6 security was limited to basic ACLs. Cisco added RA Guard to reflect the growing importance of IPv6 in enterprise networks and the need to secure the first hop. Candidates who studied v1.1 will not have seen RA Guard, DHCPv6 Guard, or IPv6 Source Guard. The new 5-domain blueprint places RA Guard under "Network Services and Security" (20%). Expect 1-2 questions on the exam.
Exam-Specific Guidance
The 200-301 exam tests your ability to:
Identify the correct IPv6 First-Hop Security feature for a given attack (RA Guard for rogue RAs).
Interpret show ipv6 snooping interface output to determine if RA Guard is working.
Configure RA Guard on a switch port.
Understand the difference between 'host' and 'router' device roles.
Common Wrong Answers and Why Candidates Choose Them
Using DHCPv6 Guard instead of RA Guard: Candidates confuse rogue RA attacks with rogue DHCPv6 server attacks. Remember: RA Guard blocks RAs, DHCPv6 Guard blocks DHCPv6 messages.
Applying RA Guard globally instead of per interface: RA Guard is applied per interface. A global command does not exist. Candidates may incorrectly think ipv6 nd raguard is global.
Setting device-role to 'router' on host ports: This would allow RAs, defeating the purpose. Candidates might think any port sending RAs should be 'router', but the role defines whether RAs are allowed *incoming* on that port.
Forgetting to enable IPv6 snooping globally: RA Guard requires ipv6 snooping global configuration. Without it, RA Guard does not function.
Specific Values and Commands
Default RA interval on Cisco routers: 200 seconds
Default router lifetime: 1800 seconds
RA Guard policy commands: ipv6 nd raguard policy NAME, device-role {host | router}, ipv6 nd raguard attach-policy NAME
Verification: show ipv6 snooping interface, show ipv6 nd raguard policy
Decision Rule for Scenario Questions
If a scenario describes hosts receiving false default router information or traffic redirection, the answer is RA Guard. If the scenario involves rogue DHCPv6 servers, choose DHCPv6 Guard. If source address spoofing, choose IPv6 Source Guard.
RA Guard is an IPv6 First-Hop Security feature that filters rogue Router Advertisements on switch ports.
[CCNA v2 NEW] RA Guard is a new objective in the 200-301 v2.0 exam; it did not exist in v1.1.
RA Guard uses device roles: 'host' blocks incoming RAs, 'router' allows them.
RA Guard is configured per interface using `ipv6 nd raguard attach-policy`.
Global `ipv6 snooping` must be enabled for RA Guard to work.
Verify RA Guard with `show ipv6 snooping interface`; look for 'RA Guard is enabled' and 'Device role'.
RA Guard is part of the IPv6 First-Hop Security suite, which also includes DHCPv6 Guard and IPv6 Source Guard.
These come up on the exam all the time. Here's how to tell them apart.
RA Guard
Filters Router Advertisement (ICMPv6 type 134) messages
Device roles: host (block RAs) and router (allow RAs)
Prevents rogue default router attacks
Configured with `ipv6 nd raguard`
Verification: `show ipv6 snooping interface` shows RA Guard stats
DHCPv6 Guard
Filters DHCPv6 server messages (Advertise, Reply)
Device roles: host (block DHCPv6 server messages) and server (allow)
Prevents rogue DHCPv6 server attacks
Configured with `ipv6 dhcp guard`
Verification: `show ipv6 snooping interface` shows DHCPv6 Guard stats
Mistake
RA Guard blocks all IPv6 traffic on a port.
Correct
RA Guard only blocks Router Advertisement messages (ICMPv6 type 134). Other IPv6 traffic is unaffected.
Candidates may think RA Guard is a broad security feature like port security.
Mistake
RA Guard can be applied globally with a single command.
Correct
RA Guard is applied per interface using `ipv6 nd raguard attach-policy`. There is no global RA Guard command.
Many Cisco features have global enable commands, leading to this assumption.
Mistake
Setting device-role to 'router' on a host port is safe because the host is not a router.
Correct
The device role indicates the role of the device *connected* to the port. 'router' means the switch trusts that device to send RAs. A host port should be 'host' to block any RAs from the attached device.
The term 'device-role' is ambiguous; candidates may interpret it as the role of the switch port itself.
Mistake
RA Guard validates the source MAC address of the RA frame.
Correct
RA Guard validates the source IPv6 address and prefix, not the MAC address. MAC address validation is done by other features like port security.
Candidates may confuse Layer 2 and Layer 3 validation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, RA Guard can be applied to trunk ports. However, the device role should be carefully considered. If the trunk connects to another switch, the role should typically be 'router' if that switch is trusted to forward RAs. If the trunk connects to a host (unlikely), it should be 'host'. In production, trunks to distribution switches are usually 'router'.
RA Guard specifically filters Router Advertisements (RA messages). NDP Inspection (also called IPv6 Snooping) validates all Neighbor Discovery messages, including Neighbor Solicitations and Neighbor Advertisements. RA Guard is a subset of NDP Inspection. On Cisco switches, RA Guard is a separate feature but works alongside NDP Inspection.
Yes, RA Guard can complement SeND. SeND provides cryptographic protection for NDP messages, while RA Guard provides policy-based filtering. In a network using SeND, RA Guard can still block RAs from unauthorized devices that do not have valid cryptographic credentials. However, SeND is not commonly deployed due to complexity.
Best practice is to apply RA Guard on all access ports (host role) and on uplink ports (router role). However, on ports where no IPv6 devices are connected, it is optional. For security, it is recommended to apply a host policy on all unused ports to prevent rogue devices from being plugged in.
RA Guard may drop the RA even on a router port if the source address is not a link-local address. According to RFC 4861, RAs must have a link-local source address. If a router misconfiguration causes a global unicast source, RA Guard will treat it as invalid. This is a common troubleshooting scenario.
RA Guard is supported on Cisco Catalyst switches running IOS or IOS-XE that support IPv6 First-Hop Security. This includes most enterprise switches like the 9200, 9300, and 3850 series. Older switches may not support it. Always check the documentation for your specific model.
You can simulate a rogue RA by sending a crafted RA packet from a test device connected to a host port. Use tools like Scapy or a simple Python script. Then verify with `show ipv6 snooping interface` that the invalid RA counter increments. In a lab, you can also misconfigure a router to send RAs on a host port to see them dropped.
You've just covered RA Guard — IPv6 First-Hop Security — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?