How to Stop a Rogue DHCP Server After DHCP Snooping Is Configured?

350-701 By islever Editorial Last updated

Configure network infrastructure security methods (network segmentation using VLANs or SGTs Layer 2 and port security DHCP snooping Dynamic ARP inspection storm control and defenses against MAC, ARP, VLAN hopping, STP, and DHCP rogue attacks)

Short answer

C Configure an ACL that permits DHCP server replies only from the trusted DHCP server, blocking offers from the unauthorized server.

Question

A network administrator has configured DHCP snooping on a Cisco switch to prevent unauthorized DHCP servers from assigning IP addresses. During configuration, a device with MAC address 04:66:96:79:0:AB received an IP address from an unauthorized DHCP server. Which configuration step must the network administrator take to accomplish the requirement?
  1. Apply DHCP option 82 to identify the trusted DHCP server.
  2. Configure each device on the network to use authorize DHCP server manually.
  3. Configure an access control list to only allow DHCP traffic from trusted DHCP server. Correct Answer
  4. Implement DHCP option 82 to relay DHCP requests to the trusted DHCP server.

Key Takeaways

The exam tests whether you can separate DHCP snooping trust from Option 82 relay metadata; the trap is assuming Option 82 blocks rogue DHCP servers.

This question tests how DHCP snooping and DHCP Option 82 interact when a rogue server has already leased an address to MAC 04:66:96:79:0:AB. It establishes that the listed fix is to restrict DHCP server traffic so only the trusted DHCP server can respond.

Common mistake: The common mistake is choosing Option 82 in A or D because it sounds DHCP-related, but Option 82 carries relay/circuit information and does not enforce which DHCP server is trusted.

Expert Analysis

Why the Answer Is Correct

The requirement is to stop an unauthorized DHCP server from handing out leases, and DHCP snooping only enforces that when server replies are accepted solely from trusted sources. Option C is the only choice that explicitly restricts DHCP server traffic to the known trusted server, so a rogue DHCPOFFER or DHCPACK from the unauthorized server cannot be delivered to clients. In a real Cisco deployment the first check would be ip dhcp snooping trust on the legitimate server or uplink port while every user port remains untrusted; the ACL is the listed compensating control that narrows DHCP server traffic. It also addresses the scenario where a port was mistakenly trusted or where an additional Layer 2/Layer 3 filter is needed.

Why the Other Options Are Wrong

Option A is wrong because DHCP Option 82 is relay-agent information inserted into client requests to identify the circuit or port; it does not designate or authenticate a trusted DHCP server. Option B is operationally impractical and does not stop the rogue server from answering other clients. Option D confuses Option 82 with DHCP relay (ip helper-address); Option 82 does not relay requests or prevent a rogue server on the local VLAN from replying. None of A, B, or D enforces the 'only trusted DHCP server' requirement.

Community Comment Notes

Most learners in the thread, including madboy2 and NETeng01, selected C and argued that the ACL should permit DHCP traffic only from the trusted server. Premium_Pils and XBfoundX correctly questioned how Option 82 could stop an already-sent rogue offer, noting that Option 82 is about relay/client information rather than server trust. luismg objected that "an ACL will not do anything on the same VLAN," but that is true only for a routed ACL that cannot filter local VLAN traffic; a VLAN ACL or port ACL applied in the correct direction can filter DHCP replies. The consensus still supports C as the only listed step that directly limits which DHCP server may respond.

Official Reference

https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken_guide/snoodhcp.html#wp1109594

This link opens the official vendor documentation in a new tab.

Exam Strategy

In DHCP snooping questions, separate the trust concept from Option 82 metadata. If the listed choices lack a trust-port command, choose the option that explicitly restricts DHCP server replies to the authorized server, and remember ACLs must be applied in the right direction and at the right VLAN scope.

Frequently Asked Questions

Why is DHCP Option 82 not enough to block a rogue DHCP server?

Option 82 adds relay-agent and circuit information to client requests; it does not authenticate the DHCP server or drop offers from an unauthorized server on the VLAN.

Does an ACL work if the rogue DHCP server is on the same VLAN?

A routed ACL cannot filter same-VLAN broadcast replies, but a VLAN ACL or port ACL applied in the right direction can; DHCP snooping trust remains the primary control.

More 350-701 FAQ →

Discussion 11 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 11

  1. luismg 👍 6 Answered D
    D is correct an ACL will not do anything on the same VLAN
  2. madboy2 👍 3 Answered C
    Since a rogue DHCP server has assigned an IP address to a device (MAC: 04:66:96:79:0:AB), the administrator must block DHCP replies from unauthorized sources using an ACL to only allow traffic from the trusted DHCP server. ❌ A. Apply DHCP option 82 to identify the trusted DHCP server. Option 82 (DHCP Relay Agent Information) is used for tracking clients, not blocking rogue DHCP servers. ❌ B. Configure each device manually to use the authorized DHCP server. Manually assigning DHCP servers on all clients is not scalable and defeats the purpose of automated DHCP. ❌ D. Implement DHCP option 82 to relay DHCP requests to the trusted server. Option 82 does not block rogue servers, it only helps track DHCP request origins.
  3. Premium_Pils 👍 3 Answered C
    An access list is not the right tool for this purpose, but it is closer to it than option 82. Setting the DHCP server manually is not really practical. The purpose of dynamic IP assignment is to avoid cumbersome manual IP settings on each client.
  4. NETeng01 👍 2 Answered C
    A. Apply DHCP option 82 to identify the trusted DHCP server: Option 82 is used in DHCP relay scenarios to insert metadata about the client’s location. It does not prevent rogue DHCP servers and is not a substitute for trust configuration. B. Configure each device on the network to use authorized DHCP server manually: This is impractical and not scalable in enterprise environments. DHCP is meant to automate IP assignment. D. Implement DHCP option 82 to relay DHCP requests to the trusted DHCP server: Again, this applies to DHCP relay scenarios and does not block rogue DHCP servers.
  5. Premium_Pils 👍 2
    I think this is about a rouge DHCP server sending a DHCP reply to a DHCP client. Could someone explain to me please, how would the option 82 prevent that? I think that option 82 is rather for verifying if the client is legitimate for receiving a reply, and can also be used for assigning an IP based on the client information (provided by the switch).
Show 6 more comments
  1. kloug 👍 2
    Answer c
  2. XBfoundX 👍 1 Answered C
    Cannot be D because if the DHCP offer is already sent to the host, you cannot just relay the information and understand where the malicious dhcp server is. To identity the malicious DHCP rogue host is necessary to get the IP addr of the rogue DHCP, verify the ARP table and then find it physically and shutdown the port or in this case use the no trust command in that port. But in case of this question what we can do is blocking the rogue DHCP using ACLs. We are going to create a Mac ACL in order to identity the mac address to block, and then we need to apply the Mac ACL using Vlan ACL.
  3. Silexis 👍 1
    Option 82 is inserted by the Relay Agent before sending the request towards the DHCP server. I am not sure how are you going to do this in the same VLAN where the DHCP Snooping trust will do the job by being enbled only on the real DHCP Server port, making impossible for a rogue DHCP server to send DHCP responses. The Relay Agent configuration is done at L3 to make possible for the DHCP Server to understand from where the DHCP Discover originates. So, an ACL - which can be a L2 ACL or physical port ACL, will do the job.
  4. houhou12322 👍 1
    It can be that DHCP Option 82 allows the DHCP server to receive additional information about the requesting device, such as its MAC address, VLAN ID, and other relevant attributes. And it make it easy to find the rouge DHCP server if the scenario is looking for the rouge
  5. dfb0b7d 👍 1 Answered D
    With the DHCP option-82 on untrusted port feature enabled, the switch does not drop DHCP packets that include option-82 information that are received on untrusted ports. https://www.cisco.com/en/US/docs/general/Test/dwerblo/broken_guide/snoodhcp.html#wp1109594
  6. Premium_Pils 👍 1
    DHCP snooping is the appropriate tool to prevent rouge servers replying the requests, however, access-lists could be a temporary work around until DHCP snooping implementation is not finished.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

What Is a Feature of an Endpoint Detection and Response Solution?

S-grade

Which Two Methods Belong in an AAA Authentication Method List?

S-grade

Preventing Unauthorized DHCP Servers on Cisco Switches

S-grade

What Is Considered a Cloud Data Breach in Cisco 350-701?

S-grade

← Back to 350-701 Study Guide