Skip to main content
Cisco Meraki Documentation

Tracking Down Rogue DHCP Servers

Rogue DHCP servers can cause headaches on any network. This article will briefly cover what a rogue DHCP is and some features of Cisco Meraki devices that will assist in finding and tracking down the rogue device.

Rogue DHCP

DHCP is used to auto-configure the connection information for devices that do not have static IP assignments set. Unless specifically configured to work together, multiple DHCP servers can cause clients and network devices to receive IP addresses, subnet masks, gateway IP addresses, and other information that can conflict with how the network should be working. This usually presents itself as groups of clients sporadically losing connection to the Internet and other network resources. This issue arises most often when users incorrectly attach a device to the network that provides this service, such as connecting a consumer router via a LAN port.

 

DHCP is a layer 2 technology and because of that, it is limited to a single subnet for most cases. The most effective way to track down a rogue server is via its MAC address. Meraki devices provide mechanisms that will assist in discovering and tracking down the location of a MAC address of a rogue DHCP server.


Finding Rogues with Cisco Meraki Products

Each Cisco Meraki product can assist along the way by establishing the MAC address of a rogue DHCP server and/or tracking down the location of the server.

Cisco Meraki Security Appliance (MX)

Cisco Meraki Security Appliances can log and detect rogue DHCP server. This can be seen under the event log (Network-Wide > Event Log). The event log will indicate the previous DHCP server's IP and MAC address as well as the newly seen DHCP server's IP and MAC address combination.

Cisco Meraki Access Points (MR)

If a Cisco Meraki access point is being used in the network being effected by a rogue DHCP server and the AP is not configured to use a static IP address, the event log will provide indication if it receives responses from more than one DHCP server. The event log will indicate the previous DHCP server's IP and MAC address as well as the newly seen DHCP server's IP and MAC address. Remember to select more >> under the Details column for that event.

 

The screenshot below depicts the events that can be seen that may indicate a rogue DHCP server. In this example, the MAC address CC:22:BB:11:AA:00 appears to be an unwanted DHCP server.

c0738491-be25-42b1-b7d1-70c61e5a1e56

Cisco Meraki Switches (MS)

Switches provide a feature that can be used to monitor DHCP servers on your infrastructure as well as a great means to track down a rogue server.

Cisco Meraki switches track DHCP servers and provide a network-wide view of this information. This page is available on Dashboard by navigating to Switch > Monitor > DHCP servers & ARP. As seen in the example below, this will display all DHCP servers that are seen on the network. It will also give more detailed information about the most recent DHCP acknowledgement. In this example both the corporate DHCP server and a rogue DHCP server can be seen.

7d7ac873-07e6-4783-b847-77f3298ed276

 

For more information on the DHCP servers & ARP page, refer to MS DHCP Servers.

All Cisco Meraki Products

Every Cisco Meraki product provides two features that help greatly when tracking down rogue DHCP servers. The first feature is the ability to search for clients by MAC address and IP. This can be used to find which device(s) the rogue DHCP server is connected to and potentially the physical switch port that the rogue server is connected to. Below is an image depicting a search for the example rogue DHCP server on the Network-wide > Monitor > Clients page. Because this example is with a switch, it also provides the device and port where the device is being seen. If the device attached to this port is an end node, this is most likely the culprit for the rogue DHCP issues. Otherwise the source is isolated to that branch of the network and the investigation can continue.

5a031909-593b-45c6-a9ee-ed66102ed4e1

The second feature is the ability to do packet captures. How captures assist will be discussed below. More information on how to use the packet capture tool in Dashboard can be found on this page.

Using a Packet Capture to Find Rogue DHCP Servers

Packet captures provide the hard proof of the negative effect from a rogue DHCP server. When a packet capture is taken, the bootp filter can be used to sort out DHCP packets. Below is an example Wireshark output for a typical DHCP handshake between a client (MAC Address f0:de:f1:a3:5d:d6) and the correct DHCP server (MAC address 00:18:0a:40:05:34):
590e7faa-ee1b-42a6-969d-94227f59faf1

If a rogue DHCP server is impacting that network segment, multiple servers will be seen responding to the DHCP Discover packet from the client. Below is an example of the same client attempting to get an address from DHCP when there is a rogue DCHP server in the broadcast domain. In this output, we can see the same client and server as the above output, but now with another DHCP server (MAC address 00:18:0a:10:8b:e0).

b53ed54c-d204-41df-83b2-feda46b816eb

This packet capture shows that the device with MAC address 00:18:0a:10:8b:e0 is acting as a rogue DHCP server. If the expected MAC address of the good DHCP server is unknown, it can be taken from the interface of the DHCP server or the interface of the DHCP relay (if the DHCP server is located on a separate broadcast domain). The next step in the process is to use the MAC address of the rogue DHCP server to locate the switch and port that it is connected to, then address that device.

  • Was this article helpful?