9130 odd behavior forwarding DHCP packets

[Vasco Costa]

Hi,

We've installed some 9115/9120/9130 at a customer beginning last week. They are still managed by a pair of 5520 with 8.10.142.This Friday they reported issues with DHCP. Some clients couldn't get DHCP addresses

After some troubleshooting, we narrowed the problem to a 9130 AP. We also noticed that there weren't any DHCP Offers passing from the AP to the clients. 

The AP was working with dual 5Ghz radio and one 2,4Ghz. Instead of rebooting the AP, we first disabled both 5Ghz radio interfaces and watch how the clients worked in 2,4Ghz. Now we saw the DHCP working fine and we could see DHCP Offers getting forwarded to the clients.
Tried to enable just one of the 5Ghz radios; again, everything working fine.
Tried to enable the other 5Ghz radio while shutting the previous one; and again everything worked fine
Tried enabling both 5Ghz radios; All good now

Anyone with a similar issue with 9130?
The only workaround we did was to disable/enable the dot1 interfaces of the 9130.

[marce1000]

 - For the problematic devices and or particular situations you may try full client debugging for the particular mac on the 5520 which you can then have analyzed with :                 https://cway.cisco.com/tools/WirelessDebugAnalyzer/

 M.

[Leo Laohoo]

Reboot the AP and it should come good.

[Scott Fella]

For situations like that, I would open a TAC case and or look at the bug tool to see if an existing issue is present.  I have had no issues like that, and if resetting the radio or ap fixes it, then it can happen again.  Just a suggestion to prevent this from happening again and you having a mad customer.

[patoberli]

What the others have said, plus there is a new software version out which fixes some bugs specific to the 9130 (although none sound like your problem, besides maybe the M1 forwarding one):

https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn810mr5.html

[JPavonM]

I had similar issue on last September and after many investigations along with TAC a bug was filled CSCvw18047 due to a regression from CSCvo91525.

The issue was due to DHCP response packets been queued on the AP and not forwarded. After 3 minutes clients were receiving a cascade of outdated DHCP responses until the good one.

The workaround was to modify the session timeout to either 0 (not recommmended) or to a full working day (54000 secs) to avoid clients re-associating and sending new DHCP packets. but also increasing the lease time on the DHCP pool to avoid DHCP renewing from client after 50% of the time from the total lease time.

The issue is solved in CSCvw30043 which is included in AireOS 8.10.151.0 and IOS-XE 17.4, but also in some 17.3.1 and 17.3.2 escalation releases I'm working with.

HTH

-Jesus
*** Please Rate Helpful Responses ***