mediumMultiple Choice
Fix DHCPv6 Guard Blocking Server Advertise/Reply Messages on Untrusted Port
In IPv6 First Hop Security, what is the purpose of the 'device-role' command in a DHCP guard policy?
⚠ Common exam trap
Cisco often tests the distinction between DHCP guard and other First Hop Security features like RA guard or ND inspection, so candidates may confuse the 'device-role' command with trust settings for ND or RA messages.
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
✓
It specifies whether the interface is a server, client, or relay for DHCP filtering.
The 'device-role' command in a DHCP guard policy specifies the role of the interface as either a DHCP server, client, or relay. This allows the switch to filter DHCP messages based on the expected role, blocking unauthorized DHCP server messages on interfaces that should only have clients or relays. It is a key component of IPv6 First Hop Security to prevent rogue DHCPv6 servers.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
It specifies whether the interface is a server, client, or relay for DHCP filtering.
Why this is correct
The device-role command defines the trusted DHCP role for an interface within the DHCP guard policy, permitting server or relay messages only where expected. This satisfies the stem's requirement by enabling the switch to filter rogue DHCP advertisements, ensuring clients receive addressing solely from legitimate servers.
- ✗
It sets the trust level for ND inspection.
Why it's wrong here
ND inspection trust is configured with 'ipv6 nd inspection policy' and the 'device-role' keyword there, not inside a DHCP guard policy. The DHCP guard device-role instead labels a port as 'server' or 'client' to decide which ports may send DHCP server messages, so it is tempting because both features share the device-role syntax.
- ✗
It defines the VLAN membership for the interface.
Why it's wrong here
VLAN membership is set by the interface's switchport configuration or subinterface encapsulation, not by device-role. The command labels a port as 'server' or 'client' so DHCP guard knows which ports may legitimately relay or serve DHCPv6; it is tempting because device-role is applied per interface, which superficially resembles a per-port VLAN assignment.
- ✗
It enables IPv6 routing on the interface.
Why it's wrong here
IPv6 routing is enabled by 'ipv6 unicast-routing' globally and 'ipv6 address' on the interface, not by device-role. The command marks a port as 'server' or 'client' so DHCP guard permits or blocks DHCPv6 server messages; it is tempting because device-role is entered under interface configuration, where routing commands also live.
Visual reference
Go deeper
Related to this question
About these practice questions
This 300-410 question is part of Courseiva's 1,401-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on 300-410
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A network engineer runs the following command to troubleshoot DHCPv6 guard: R1# debug ipv6 dhcp guard *Mar 1 00:03:45.678: IPv6-DHCP-Guard: R1, Fa0/0, DHCPv6 SOLICIT from fe80::3, client DUID 00010001abcd1234 *Mar 1 00:03:45.678: IPv6-DHCP-Guard: R1, Fa0/0, DHCPv6 SOLICIT from fe80::3 is allowed by policy DHCP-POLICY *Mar 1 00:03:46.901: IPv6-DHCP-Guard: R1, Fa0/0, DHCPv6 ADVERTISE from fe80::4, server DUID 0001000156789012 *Mar 1 00:03:46.901: IPv6-DHCP-Guard: R1, Fa0/0, DHCPv6 ADVERTISE from fe80::4 is blocked by policy DHCP-POLICY What does this output indicate?
medium- ✓ A.DHCPv6 guard is allowing client messages but blocking server messages from untrusted sources, preventing rogue DHCPv6 servers.
- B.DHCPv6 guard is blocking all DHCPv6 messages, indicating a misconfiguration.
- C.DHCPv6 guard is allowing all messages but logging them for analysis.
- D.DHCPv6 guard is not configured; the debug output is from default DHCPv6 behavior.
Why A: The debug output shows that DHCPv6 SOLICIT messages from client fe80::3 are allowed by policy DHCP-POLICY, while DHCPv6 ADVERTISE messages from server fe80::4 are blocked by the same policy. This is the expected behavior of DHCPv6 guard: it permits client messages (SOLICIT, REQUEST, etc.) to reach potential servers, but it blocks server messages (ADVERTISE, REPLY, etc.) from untrusted ports to prevent rogue DHCPv6 servers from assigning malicious configurations. Option A correctly identifies this selective filtering.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 300-410 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 300-410 exam.