hardMultiple Choice
350-401 Practice Question: Is configuring IPv6 First Hop Security on a Cisco…
A network engineer is configuring IPv6 First Hop Security on a Cisco switch to mitigate rogue RA attacks. The engineer enables RA guard on the switch and applies a policy that allows only the default gateway to send RAs. After configuration, hosts are unable to obtain IPv6 addresses via SLAAC. The engineer checks the switch and sees that RA guard is dropping all RAs. What is the most likely cause?
⚠ Common exam trap
Cisco often tests the misconception that RA Guard has a 'block' mode or that it blocks RS messages, when in reality the issue is almost always a missing or incorrect trusted device entry in the RA guard policy.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The RA guard policy does not include the IPv6 address or MAC address of the legitimate default gateway.
RA Guard drops Router Advertisements (RAs) based on a policy that defines which devices are authorized to send them. If the policy does not include the IPv6 address or MAC address of the legitimate default gateway, the switch will treat all RAs as unauthorized and drop them, preventing hosts from performing SLAAC. This is the most likely cause because the engineer enabled RA guard with a policy but failed to specify the trusted gateway's identity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The RA guard policy does not include the IPv6 address or MAC address of the legitimate default gateway.
Why this is correct
RA guard is a policy-based IPv6 first-hop security feature that forwards Router Advertisements only from devices explicitly authorized by the policy. If the legitimate default gateway's IPv6 address or MAC address is not listed in that policy, the switch treats those RAs as rogue and silently drops them. Consequently, hosts never receive the gateway's prefix information or default route, breaking SLAAC and causing the reported connectivity loss. The fix is to add the actual gateway to the RA guard policy as a trusted device.
- ✗
The switch has DHCPv6 snooping enabled, which conflicts with RA guard.
Why it's wrong here
DHCPv6 snooping and RA guard are complementary IPv6 security mechanisms that do not conflict when enabled together. DHCPv6 snooping inspects DHCPv6 messages to build a binding table and prevents rogue DHCPv6 servers, whereas RA guard inspects ICMPv6 Router Advertisements to block unauthorized routers. These features operate on different protocols and layers of the IPv6 stack, so enabling both is a recommended defense-in-depth approach rather than a source of failure. The issue described would still occur even if DHCPv6 snooping were absent, indicating RA guard itself is the culprit.
- ✗
SLAAC requires the host to send a router solicitation first, which is being blocked by RA guard.
Why it's wrong here
RA guard is designed to filter Router Advertisements (RAs), not Router Solicitations (RSs). In normal SLAAC operation, a host first sends an RS to the all-routers multicast address to elicit an RA from a legitimate router; RA guard does not inspect or block RS traffic. Even if RA guard were aggressively filtering, it would not prevent the host from sending RSs — it only drops the unsolicited or matching RAs. Thus, the problem is not that RSs are blocked, but that the router's RA is discarded by the RA guard policy.
- ✗
RA guard is configured in 'block' mode, which drops all RAs regardless of the policy.
Why it's wrong here
RA guard is a policy-based mechanism that permits or denies RAs based on configured criteria such as trusted ports, device roles, or explicit addresses; there is no standard 'block' mode that indiscriminately drops every RA while keeping RA guard enabled. If the switch were dropping all RAs regardless of policy, it would more likely be an ACL or a disabled RA forwarding setting, not RA guard itself. Even in 'block' or 'protect' style implementations, the action is applied per-policy and still relies on matching the configured authorized source addresses. Therefore, the answer lies in the policy's missing gateway entry, not a global block mode.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
One of 1,923 original 350-401 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.