Header Only - DO NOT REMOVE - Extreme Networks

Some users not receiving DHCP address via B@AP, others do ?


HI all, I have an odd problem ~ C35 controller - version 10.11 3805i APs Fresh deployment PSK SSID, Bridged@AP topology Windows DHCP server Allow/Deny filter added The vast majority of users will receive IP addresses from the DHCP server with no problem at all. Some users will not receive an IP address from the server. Upon further inspection we can narrow it down like this : 1 - A user's lease expires, they are assigned a new IP address - this is visible in the DHCP active leases - but the user did not receive this address ? We can delete the lease, release/renew the client, re-associate and still no IP address. (this user had an DHCP address in the morning then they arrived - when the lease renewed, they had an error) 2 - A user comes in the morning, tries to connect and does not receive an IP address. The user(s) has an APIPA address. The user is authenticated to the WIFI The users' PC is in the DHCP allow list The user's PC is released/renewed - no change The user's PC is dissociated and reassociated - no change I have requested the lease to be changed from 8 days, to 8 hours - the client will action this afterhours. DHCP service restarted - issue remains Has anyone seen this issue before ? Any advise on where to check as I checked through logs and setting and it all seems fine. What is interesting is that out of the 100 users, about 80 of them connect to the wifi and this only happens to a random 3-6 users. Not the same users... I appreciate any responses, thanks !

21 replies

Userlevel 7
In the bridge@AP topology L2 settings is ARP proxy enabled?
If yes disable it and check again - I had some troubles in the past with that option.
Userlevel 1
Ron wrote:

In the bridge@AP topology L2 settings is ARP proxy enabled?
If yes disable it and check again - I had some troubles in the past with that option.

Having the ARP Proxy enabled will help? "ARP Proxy" is unchecked on my controller. How do I know if I need it enabled or not?
Hi,

No, it is disabled. Will open a GTAC for this also.
In addition to this - when the same user connects to the LAN - it works immediately, hence why the wifi seems to be involved here somehow..
Userlevel 1
I don't know if this is related, but, sometimes my users will connect to our wifi and get a good address from the correct vlan. After a few seconds, the user gets kicked off and gets a 169 address. This is with a C5210 contorller and 3605/3610 APs, on Macbooks.
Userlevel 7
Laura wrote:

I don't know if this is related, but, sometimes my users will connect to our wifi and get a good address from the correct vlan. After a few seconds, the user gets kicked off and gets a 169 address. This is with a C5210 contorller and 3605/3610 APs, on Macbooks.

Could you tell me the uptime of the APs (> Reports > APs > active APs, sort by uptime) and the version of the controller.
Userlevel 1
Laura wrote:

I don't know if this is related, but, sometimes my users will connect to our wifi and get a good address from the correct vlan. After a few seconds, the user gets kicked off and gets a 169 address. This is with a C5210 contorller and 3605/3610 APs, on Macbooks.

controller is 9.21.10.5, aps are 3605


I was having a problem with AP 411_Room_12. There was a power glitch earlier, but the AP is working now and has clients attached. I walk into the room with my macbook and connect to the AP and get a good address, then my address changes to a 169 address.
Userlevel 1
Laura wrote:

I don't know if this is related, but, sometimes my users will connect to our wifi and get a good address from the correct vlan. After a few seconds, the user gets kicked off and gets a 169 address. This is with a C5210 contorller and 3605/3610 APs, on Macbooks.

Laura - I would suggest opening a case with GTAC, and we can help get the controllers, or just the APs, to 9.21.15.
The install was done 3 days ago and the APs have been up since then. Version is 10.11.01.0210 For the sake of interest, I disabled DHCP snooping on the switch and checked if there were any policies that would stop DHCP packets on the switch and could not see anything. It is a pretty basic deployement now. regards
Userlevel 7
Dewald Botha wrote:

The install was done 3 days ago and the APs have been up since then. Version is 10.11.01.0210 For the sake of interest, I disabled DHCP snooping on the switch and checked if there were any policies that would stop DHCP packets on the switch and could not see anything. It is a pretty basic deployement now. regards

Hi Dewald, have you been able to resolve these DHCP issues?
Dewald Botha wrote:

The install was done 3 days ago and the APs have been up since then. Version is 10.11.01.0210 For the sake of interest, I disabled DHCP snooping on the switch and checked if there were any policies that would stop DHCP packets on the switch and could not see anything. It is a pretty basic deployement now. regards

second this. We are having the same issues.
What does a RealCapture from the AP show? Does the DHCP 4-way handshake complete?
Userlevel 1
James A wrote:

What does a RealCapture from the AP show? Does the DHCP 4-way handshake complete?

Is there a video tutuorial on how to use RealCapture?
Userlevel 5
This probably isn't going to help that much but been having exactly the same problem, although it might not be related.

When doing a packet capture from the AP from the Ethernet port and wireless interface (Only configured for 5Ghz) you can see the DHCP request go out and an offer come back and get as far as the AP's Ethernet port but it never goes out the wireless interface and therefore never reaches the client.

Sometimes if you leave the client long enough it will eventually connect.

Working on the issue at the moment and basically created a duplicate VNS and turned various things off until it started working, then enabled each one again until it failed.

At the moment I haven't isolated it down enough to find the cause but will post if / when I do.

I'm only posting this message as the same approach might help you, as well as trying these couple of things:

* Disable WMM and Flexible Client Access
* Uncheck 'Permit Inter-WLAN Service Roaming'
Same problem here. AP uptime was bit over 30days. Rebooted APs and after that all clients did get IP address. Setups has 3935i and 3805i APs.

V2110 10.11. B@AP, PSK.
In my topology - what I did was remove the HP1920 switches and installed some C3 switches I had.

This apparently 'fixed' the problem. At this stage, I am happy to say that there is no config issue on the EWC, and most likely an error on the client's network somewhere else.
hello All,

I'm seeing the exact same thing on our wifi network. Any update on this ?
Userlevel 6
Joris Schepers wrote:

hello All,

I'm seeing the exact same thing on our wifi network. Any update on this ?

Joris

Take a look at this article which offers some guidelines on steps you can take: https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-troubleshoot-a-client-MU-that-fails-to-get-an-IP-address-or-has-an-APIPA-IP-address-169-254-0-0-16

-Gareth
Joris Schepers wrote:

hello All,

I'm seeing the exact same thing on our wifi network. Any update on this ?

Hello Gareth,

I think you have my case now. Still no solution. Thanks for looking into it again !
Userlevel 1
I noticed clients getting 169 addresses from the APs that are on the Foreign controller. Within the last year, our Primary controller filled up with 1000 3605 APs. Then I started installing more APs which would load on the Foreign controller. However, we did remove about 100 APs from the Primary controller which freed up space on the Primary controller. It seems like all the APs I am having 169 clients issues with are the APs that were added to the F-cont, when the primary was full. I found a trouble AP and factory reset it, and deleted it from the F-cont. I then added again, and it came up in the Primary controller, and works fine now.
Userlevel 7
Laura wrote:

I noticed clients getting 169 addresses from the APs that are on the Foreign controller. Within the last year, our Primary controller filled up with 1000 3605 APs. Then I started installing more APs which would load on the Foreign controller. However, we did remove about 100 APs from the Primary controller which freed up space on the Primary controller. It seems like all the APs I am having 169 clients issues with are the APs that were added to the F-cont, when the primary was full. I found a trouble AP and factory reset it, and deleted it from the F-cont. I then added again, and it came up in the Primary controller, and works fine now.

Let me guess..... the topology is bridge@EWC and the VLAN for the topology isn't configured on the switch that connects the 2nd controller 🙂

Troubleshoot: check on the LAN where/if you learn the MUs MAC.

Also check > VNS > Global > Sync Summary.... is everything in sync ?
Userlevel 1
Laura wrote:

I noticed clients getting 169 addresses from the APs that are on the Foreign controller. Within the last year, our Primary controller filled up with 1000 3605 APs. Then I started installing more APs which would load on the Foreign controller. However, we did remove about 100 APs from the Primary controller which freed up space on the Primary controller. It seems like all the APs I am having 169 clients issues with are the APs that were added to the F-cont, when the primary was full. I found a trouble AP and factory reset it, and deleted it from the F-cont. I then added again, and it came up in the Primary controller, and works fine now.

The network time was wrong on both controllers. Once I entered a different NTP server, the APs started working normally. Everything is synced. We have the "Bridged at AP" topology. I still don't understand what the topologies are and how they work with everything else.

Reply