cancel
Showing results for 
Search instead for 
Did you mean: 

After Moving to Aerohive NG management platform we are having clients keeping their old IP address from other locations. This is causing the clients to stay connected but not access anything internal or external.

After Moving to Aerohive NG management platform we are having clients keeping their old IP address from other locations. This is causing the clients to stay connected but not access anything internal or external.

wendland_jm
New Contributor

We are running 10.0r7a on 98% of our AP250 and AP230. Some Background info, we have most of our building segmented on different subnets but using the same SSID for all buildings and are using an external radius server for authentication. All APs in a building are issuing the same subnet scope and VLAN. We have already tried GRE Tunneling (this made the issue worse). We have done a VLAN Probe test and the AP successfully passes the test for its Building VLAN. 

 

The issue is when a client is connected in building A on VLAN-A and IP address int subnet A and the client moves to building B the clients stays connected but has no access to anything due to the client keeping their IP address form building A. This is happening on all devices (apple,android,windows,chrome) but it does not happen all the time. A client can move from building A to B (no issue) then to building C and have the issue. Suggestions would be a great help.

 

Thank you.

14 REPLIES 14

wendland_jm
New Contributor

For may reasons, 1) to segment network traffic between our 30+ buildings and not have a huge subnet scope, 2) to limit casting between buildings, 3) better security, 4) help prevent virus spread and many more reasons. This question is more why is only NG doing this. The buildings that were previously still on classic did not have any problem moving between those building.

dparsons
Contributor

As to why it worked before I have a few guesses but not knowing all the details I am only guessing. First is that you happened to make your move around the same time Windows changed the way it connects. Prior to this spring Windows did a DHCP request each time it "connected" to a network. When I use the term connected I am saying where it has lost the connection and has a red X on the tray and then connects to the next AP and the X goes away as opposed to connecting to another AP as a simple roam. When a client roams the connection never goes red. As your user leaves one building and enters another is there a time that the signal is so weak the client disconnects completely?

 

Did you replace your APs during the change? Better APs mean better signal and user may no longer disconnect as discussed above.

 

In the new Hive Manager you will have a new radio profile and a renegotiation of channels and signal strength. This could have reduce the disconnects when changing buildings. If prior to the change you got disconnected and after you do not then that could have been what made the difference.

 

Regardless you are faced with a no win battle on Windows clients now as they hold on even through reboots. Our two sites were a 30 minute drive apart. We use client classification and it also was affected. When two different users logged onto the same device if they were placed in different VLANs then the second user would not have connectivity because it would hang onto the prior IP as you are experiencing. We had to implement a procedure for the helpdesk to walk them through a ipconfig /release and ipconfig /renew to force a DHCP request.

 

 

dparsons
Contributor

Why are your users in a different VLAN in each building? Why not have them in the same VLAN regardless of the building? Are your APs and users in the same VLAN?

wendland_jm
New Contributor

When we were using Aerohive Classic we had the same vlan and subnet setup as we do now and never had this problem. This summer we moved all of our APs to NG and this issue started and has only gotten worse.

"I have to ask why you did this?" Why we did what?

 

Thank you for your response.

dparsons
Contributor

And unfortunately you will continue to have issues. The device cannot tell that it has moved to a new VLAN since from what it can tell it is on the same network. The only option is to set you DHCP life time to a few seconds (Windows minimum is one minute) but that is going to flood your network. In short this is not a good design. I have to ask why you did this?

 

We ran into the same issue with two separate sites using the same SSID but different VLANs due to the site being on the end of a VPN and no means to retain the same VLAN. In the end we had to change the SSID at the remote site so the devices could determine that it was a different network and ask for a new IP. Recent updates to windows has made it even worse.

 

On Windoze when the device connect to a wireless network that it has connected before it will use the IP address that was issued to it during the prior session unless it has expired. It speeds up the connection process. Just think if every time a device changed APs (same building or not) that it had to do a DHCP request. The device has no means to detect what VLAN is behind the SSID it is connecting to (yeah I said it again).

 

 

GTM-P2G8KFN