Rogue DHCP servers can cause headaches on any network. This article will briefly cover what a rogue DHCP is and some feature of Cisco Meraki devices that will assist in finding and tracking down the rogue device.
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 operatically loosing 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 it's 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.
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.
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" beside the reason 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.
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 Merak switches track DHCP servers and provide a network wide view of this information. This page is available on Dashboard by navigating to Monitor > DHCP. 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.
For more information on the DHCP page, refer to this entry about the feature from the Cisco Meraki blog.
Every Cisco Meraki product provides 2 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 more with device(s) the rogue DHCP server are connected to and potentially the physical port which the device is connecting to the Meraki network through. Below is an image depicting a search for the example rogue DHCP server. Because this example is with a switch, it also provides the device, port, and VLAN where the client 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.
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.
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):
If a rogue DHCP server is impacting that network segment, multiple servers will be seen responding to the DHCP discovery 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 another DHCP server (MAC address 00:18:0a:10:8b:e0).
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.