4.0 Network Services and Security

DHCP Snooping Practice Questions

Trusted/untrusted ports and rogue DHCP server mitigation.

CCNA v2.0 objectives 4.7, 4.7.a · objective map

Author-reviewed by LabFabric · 7 September 2026 · Report a content issue

One solved question, so you can see how these are marked

A switch has DHCP snooping enabled globally and for the access VLAN, but no ports are trusted yet. What happens to DHCP server-side messages, such as DHCPOFFER, arriving on an access port?

They are dropped, because only trusted ports are allowed to forward DHCP server replies

DHCP snooping treats every port as untrusted by default once enabled, and untrusted ports are not permitted to send server-originated messages like DHCPOFFER or DHCPACK, which blocks rogue DHCP servers from responding to clients.

Every question in the set below is marked like this. The answers stay hidden until you pick one.

Find related practice in the CCNA path

All 7 DHCP Snooping questions in this set

Answers and explanations appear when you work through the set above.

Which command marks the uplink port connecting a switch to the legitimate DHCP server as trusted?
- ip dhcp snooping trust
- ip dhcp snooping vlan trust
- ip dhcp trust snooping
- switchport dhcp trust
After enabling ip dhcp snooping globally, a client on an untrusted port fails to renew its address and the switch logs option 82 being present on an untrusted port. What is the most likely fix?
- Permit pre-existing option 82 information on untrusted ports with ip dhcp snooping information option allow-untrusted
- Trust the port connected to the client instead of the DHCP server
- Disable DHCP snooping on that VLAN entirely
- Increase the DHCP snooping rate limit on the port
Which command is required, in addition to enabling ip dhcp snooping globally, before the switch actually starts enforcing snooping on a given VLAN?
- ip dhcp snooping vlan <vlan-id>
- ip dhcp snooping database flash:
- ip dhcp snooping information option
- ip dhcp snooping verify mac-address
What information does show ip dhcp snooping binding display?
- The MAC address, leased IP address, lease time, VLAN, and interface learned from snooped DHCP transactions on untrusted ports
- A list of all DHCP servers reachable from the switch
- The configured DHCP excluded-address ranges
- The trust state of every switchport regardless of DHCP activity
SW2's clients reach the legitimate DHCP server through an inter-switch trunk to upstream SW1. No legitimate server exists behind SW2. How should the two receiving interfaces normally be treated for DHCP snooping?
- Trust SW2's interface facing upstream SW1; leave SW1's interface facing downstream SW2 untrusted
- Untrusted on both ends, trunk links should never be trusted
- Trust SW1's interface facing downstream SW2; leave SW2's interface facing upstream SW1 untrusted
- DHCP snooping cannot span multiple switches, it must be configured only on the switch with the DHCP server
Users on an access switch receive addresses from 192.168.0.0/24, but the correct scope is 10.10.20.0/24. A small home router was found plugged into a user port. Which configuration prevents this from happening again?
- Enable DHCP snooping for the VLAN and trust only the uplink toward the legitimate DHCP server
- Configure ip helper-address on the user port so that requests reach the real server first
- Enable PortFast on every user port so that the real server answers before the rogue one
- Trust every user port so that DHCP snooping can record the rogue server's bindings
An engineer enables DHCP snooping on VLAN 30 but forgets to trust the uplink toward the DHCP server. What do clients in VLAN 30 experience?
- They keep getting addresses, because the uplink is a trunk and trunks are always trusted
- They get addresses, but the binding table stays empty
- They stop getting addresses, because the server's replies arrive on an untrusted port and are dropped
- They get addresses only after the switch reloads and rebuilds the binding table