MX64 - DHCP problem extra: no_offers_received, vap: 0, vlan: 20

[Ljalabs]

I am seeing the error 'extra: no_offers_received, vap: 0, vlan: 20' followed by multiple DHCP leases to the same client.

There are plenty of addresses available in the pool to be leased, this only occurs on vlan 20 which has previously been fine. No config changes or recent firmware updates.

Has anyone seen this message before?

I've done some googling but haven't found anything pertinent to the security appliances.

[cmr]

It often happens if the client is wireless and in a low reception area or moving between APs with a slow roam.  Is it a wireless client?

[Ljalabs]

It is a wireless client that is stationary and shouldn't be roaming. The signal strength according to the AP is excellent.

[Kevin_R]

Hello Ljalabs,

The specific event log entry "extra: no_offers_received" indicates that the MX is seeing repeated DHCP Discovers from the listed client device; the MX does not have to be the DHCP server either, it just needs to see the repeated Discovers from the same client. If the DHCP Discovers are received 3 times within a 5 minute window, the MX logs the message in the event log. We have more specific information on the triggers and recommended troubleshooting steps here: https://documentation.meraki.com/MR/Monitoring_and_Reporting/DHCP_%22no_offers_received%22_Errors_in...

As for why it might be appearing, that we would need more information about the environment. I know from experience it can indicate that there is a VLAN tagging issue on the port the AP is connected to, but that is not guaranteed to always be the case (and might not be occurring here, if there were no recent config changes, as you mentioned). As the article above mentions for troubleshooting steps, it can also indicate the DHCP server is not responding. Taking packet captures at various points in the network between DHCP server and client, and analyzing the captures for DHCP traffic could help determine where the breakdown is occurring.

[Ljalabs]

Thank you for pointing me in the right direction.

I have noticed in the logs that two clients in particular keep having conflicting IP address event logs. I've done some monitoring on the network and cannot find a rogue DHCP server as only the Meraki (which is configured as a DHCP server) is responding to DHCPDISCOVER messages.

Also it seems to be 2 clients specifically that keep claiming each other has the same IP address.

[Kevin_R]

Hello Ljalabs,

I thought that a Meraki device was the DHCP server just based on the log message, but did not want to assume, so that makes sense too.

As for what the shared event log messages indicate, that is a bit trickier. Just from experience, it could mean that those one of those 2 devices are actively taking extra leases that they're not supposed to. Does a packet capture show both devices replying to DHCP Offers from the MX when it is sent out? Also, are any other client devices having issues on VLAN 20, or is it just a singular device (which I assume is one of the 2 pictured in the event log)? Also, does the DHCP tab on the MX (Security & SD-WAN > Appliance status page) provide any clues to the amount of leases in use/consumed for VLAN 20? The DHCP tab on the MX shows what device has a DHCP lease assigned, so wondering if it shows one of those devices consuming more leases.

[Ljalabs · Accepted solution]

Thanks again for another helpful reply, looking into DHCP messages sent me down the right path.

It looks like the IP conflict issue is caused by a wireless mesh range extender that somebody has connected to the network. It looks like some clients (probably connected to the mesh extender) are going through the DHCP DORA process, ARP requesting to check their leased IP address is not in use, then receiving an ARP response from the mesh extender which would cause them to DHCPDECLINE and restart the process.

At least that is what the packet capture has led me to believe. I have since blocked the range extenders MAC address from the APs and haven't seen any of the problem events in the logs.