Client made a request to the DHCP server, but it did not respond

[MartynB1]

Hi,

I've researched this issue and so far haven't found a similar case, so I've signed up to ask for some advice

I have an MR36 running 27.7.1 connected to an MS250-48LP running in test as a PoC for a network wide roll out

I have a Guest SSID distibuting it's own DHCP, and a Production SSID configured to use the local LAN DHCP server.

In the production SSID, I'm getting the DHCP error in the subject, however, clients are getting a valid IP address from the server, with the correct gateway etc, and a lease visible in the DHCP lease list on the Windows server. However the client claims there is no internet access

The MS250 is currently configured to block rogue DHCP servers but specifically allow the DHCP server in question, it's worth noting that client devices connected to the switch via copper are getting addresses and connecting out without issue, there is no L3 configured on this network

Any suggestions of where to look would be a great help, thanks in advance

[WaseemD1]

Let us think in a different way, perhaps the issue isn't from Meraki, may be its a Windows/NICs related issues,
I have seen multiple posts regarding Intel's new AX wireless NICs that only have DHCP issue with RADIUS networks.
In my environment, we have AC8xxx / AC9xxx / AX201 / AX210
We had in hands a machine that is unable to obtain IP, we tried to connect using an external USB TP-Link adapter, it worked instantly, under the same SSID, and same AP.
Unplugging the USB and reuse the internal NIC, the machine is unable to obtain IP address.

Dears, please share your environment used NICs, are they all Intel's, what model?

[ArcenioIT]

I tried many possible solutions (checked the Meraki config, the OS versions, my firewall, etc), but realized it was only some client computers that were causing this problem, so I tried your advice. I connected a USB NIC to the computer and it worked instantly.

[mikeschriver]

Very good thought WaseemD. The only problem with my issue is it's happening with our Chromebooks which only use PSK as well as our HP and Dell laptops which do use Radius. These same devices didn't have this issue a year ago.

[WaseemD1]

Figured it out, Meraki Layer 3 firewall we use to "allow" specific IPs such as Radius servers/DNS/Gateway and "deny" any by default.
the error in configuration that the broadcast IP 255.255.255.255/32 is not allowed, nor Ports 67/68.
adding these to the allow list in the firewall policy will solve the issue.

If we go back and check Meraki's recommendation is to "Deny" any unwanted subnets, and keep the Allow as default.
But this does not work for me, as we need to also block public IPs before .1x authorization response.

Thanks

[KaylaEikenberry]

We're experiencing this issue, but it seems to be on the 9164 APs we have in our office area. I am not sure if the issue is isolated solely on those model of AP or if it's because we do not have *that* many wireless clients on the older APs. One question I have, are any of you running off NX-OS? I was looking at the interface from the IDF switch to the Nexus switches interface, and there are a noticeable amount of input and output drops as well as Giant frames on those interfaces.

Our clients can reach the SVI (nexus), but cannot ping to the firewall when the issue is happening, so I have to think there's something happening. The Nexus interface as well as 9300 interface both have the default MTU, and was thinking that maybe the MTU size needs to be increased.

[KaylaEikenberry · Accepted solution]

Well we resolved the issue. We have an ASA in our environment with basic threat detection enabled. When doing a packet tracer on the ASA the client experiencing the issue was Shunned in Phase 3. When looking at the policy we have excluded subnets from the threat detection with auto recovery after 3600 seconds (1 hour). Once we added that in the policy we have not had the issue occur again.

[MartynB1]

Hey guys, I just saw a notification for an update on this thread, and thought I ought to come back and at least share my own findings since I started it!

The network I was working in whilst encountering this issue had a very unusual IP address schema implemented by it's creator many years ago, this being 6.x.x.x

Turns out, this is the IP address schema that Meraki are using on their back end for communication protocol between AP's and switches, and therefore, can't handle it as the LAN schema.

No resolution in this case, but we are almost done migrating this network to fresh infrastructure with a corporare aligned address schema.

Not that I imagine this helps anyone else, sorry!