Home > Switches > Monitoring and Reporting > MS DHCP Servers

MS DHCP Servers

Overview

The Switch > Monitor > DHCP Servers page displays information about any DHCP Servers seen by Meraki Switches on the LAN. From this page Administrators can configure Email Alerts to be sent when a new DHCP server is detected on the network, block specific devices from being allowed to pass DHCP traffic through the switches, and see information about any currently active or allowed DHCP servers on the network. 

Email Alerts 

The Email Alerts dropdown menu can be used to enable Email Alerts to be sent to Administrators when a switch detects a new DHCP server on the network. This can also be configured from the Network-wide > Configure > Alerts page, under the Switch heading. Additionally, the Network-wide > Configure > Alerts page can be used to specify which Administrators receive these alerts.

Default DHCP Server Policy 

The Default DHCP Server Policy can be set to either Allow or Block new DHCP servers. The default setting is to Allow all DHCP Servers on the network for easy installation into an existing environment. If the Default DHCP Server Policy is set to Block DHCP Servers, the only DHCP servers that will be allowed to pass traffic must be explicitly whitelisted from the DHCP Servers list or the Allowed DHCP Servers box.

Blocked DHCP Servers 

By default DHCP Servers can be explicitly blocked by entering the MAC address of the server in question into the Blocked DHCP Servers box. This will prevent DHCP traffic sourced from that MAC from traversing the switches. The MAC address of the server to be blocked can either be entered manually or it will be automatically entered by Blocking a detected server from the DHCP Servers list.

Note: Meraki Switches configured as DHCP servers are always allowed to pass DHCP traffic.

Warning: Blocking a DHCP server will block that server for all VLANs and Subnets. 

Allowed DHCP Servers 

If the Default DHCP Server Policy is set to 'Deny DHCP Servers' the Blocked DHCP Servers box will change to the Allowed DHCP Servers box. When this change is made only DHCP Servers with a MAC Address matching one of the entries in the Allowed DHCP Servers box will be allowed to pass DHCP traffic, all other detected DHCP Servers will not be allowed to pass DHCP traffic.

Detected DHCP Servers 

The DHCP Servers list displays any clients on the network that have been observed sending DHCP responses. The table can display servers that have been detected in the the Last 2 Hours, Last Day, Last Week, and Last 30 Days by selecting the appropriate time period from the dropdown menu. DHCP Servers will only be listed here if a Meraki Switch on the network has seen DHCP response traffic sourced from that client. The table displays information such as the server MAC, VLANs and Subnets of operation, time last seen, and a copy of the most recent DHCP packet to be seen from that client. The screenshot below shows two different devices acting as DHCP Servers for 3 different VLANs across 4 different Subnets. 

DHCP List2.png

Description 

The Description field lists the description of the Client from the Network-wide > Monitor > Clients list. Clicking on the Description will take you to the Client Details page for that client, if available. If the client is another Meraki device in the Network, such as the 'Main MX' in the image above you will be taken to the Appliance Status or Details page for that device.

MAC 

The MAC field lists the MAC address that was seen as the Source of a DHCP packet coming from the DHCP server, such as a DHCP Offer. 

VLAN 

The VLAN field shows what VLAN the DHCP server was detected on. If a single DHCP Server is responding on multiple VLANs one entry for each VLAN will be created. For example, in the screenshot above the 'Main MX' is acting as a DHCP server for both VLAN 100 and VLAN 99.

Subnet 

The Subnet field shows what Subnet the DHCP server was detected on. If a single DHCP server is responding on multiple subnets one entry for each subnet will be created. For example, in the screenshot above the unidentified Gateway is acting as a DHCP server for two different subnets that are both seen on VLAN 999. 

IP 

The IP field lists the IP address that the server was last seen responding with for a specific entry. In the example image above, we can see that the 'Main MX' DHCP server responds from two different IPs, depending on which subnet the DHCP request originated from while the unidentified Gateway responds on both of its subnets from the same IP.

Last Seen 

The Last Seen field displays the amount of time since a DHCP packet was seen from that server. Depending on the length of time it may be displayed in Minutes, Hours, or Days.

Recent Packet 

The Recent Packet field displays a link that when clicked will bring up a pop-up window displaying the most recent DHCP packet to come from the server. Below is an image of an example packet as displayed after clicking the Recent Packet link.

Recent Packet2.png

Policy 

The Policy field displays the policy applied to a specific DHCP Server, either 'allowed' or 'blocked.' 

Seen By

The Seen By field lists which switches in the Network have detected a specific DHCP server. Clicking on the name of one of the switches will bring you to the Switch Details page for that switch.

Last ACK IP

The Last ACK IP field displays the IP of the client that was last sent a DHCP ACK by the DHCP Server.

Last ACK Seen

The Last ACK Seen field displays the amount of time since the last DHCP ACK was seen for a specific server. Like the Last Seen field, the length of time may be displayed in Minutes, Hours, or Days. 

NOTE: The Seen By, Last ACK IP, and Last ACK Seen fields are not shown by default and must be added by clicking the '+' icon on the right side of the table headers.

Tracking Down 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 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).

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.

You must to post a comment.
Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 6422

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community