We are excited to announce that we have launched our new Hive Community! HiveNation will remain as an archive, but all new posts, discussions, and articles will be created on Hive Community. You can visit our new community at thehivecommunity.aerohive.com

Layer 3 Roaming Issues

I have segmented my network into multiple subnets with separate VLANs based on the different sections of the physical building. I am using classifier tags to have the AP's automatically dump the clients onto the appropriate VLAN for each section of the building. So far this is working quite well....as long as the clients don't move...at all.

I have enabled layer 3 roaming in the user profile, but I'm having trouble with it working correctly. The issue is that the client will successfully authenticate to the SSID, but then will be unable to obtain a DHCP lease after it moves around a bit.

I sniffed the AP's switch port with Wireshark and see that the client is sending a broadcast for DHCP Discover and not receiving a response.

DHCP Relay is set up on all my routers and is working correctly because wired and other wireless clients will obtain an IP just fine. It appears to happen only if the client roams away and then comes back.

At this point I'm not even sure how to troubleshoot further. Attached is a network diagram with all the IP info.

Other info:
-They are all the same Hive
-AP's can see each other via background scans, and others I manually neighbored.
-The switch port the AP's are connected to is tagged for that client VLAN
-All AP's are reachable via HMOL

* The wireless client associates correctly initially and is given a correct IP address via DHCP for the building they are in.
* If the wireless client remains in the building they initially associated in they don't have an issue?
* If the wireless client moves between buildings they lose their IP address?

Does this sound correct?

What should be happening is that the wireless client initially associates in building x and is given an IP address from the DHCP IP scope for building x. The wireless client then moves to building y and retains their IP address from building x - i.e. their IP address does not change as they move between the buildings.

Thank you for the response Tim. I did enable that option and reboot the APs, and it does appear to be working better.

I was able to take my laptop streaming a YouTube video and walk to a different section of the building while keeping my IP and video stream. I then walked to a different section and eventually ended up being disconnected.

I could see the AP's and authenticate, but again it refused to either do a 'soft' layer 3 roam or even a 'hard' roam and obtain a new IP address. Once I brought it back to my office where I originated it obtained its original IP and worked fine again.

I'll keep testing. I just noticed that the ACSP Neighbor info FINALLY populated in the AP details so I'll see if that made a difference.

It appears that I'm basically having the same issue...but since school is now back in session....there's a lot more of it going on.

I THINK it is because for some reason the AP is keeping a hold of the VLAN that the client connected to in another section of the campus, but is refusing to let it go....or kick in the roaming (probably because they are in different subnets and I can't manually neighbor EVERYTHING).

The only thing that I can think of is instead of worrying about tagging the client VLAN on the AP, is just have the AP's dump the clients on to whatever VLAN/subnet the AP is attached to (untagged). Then the APs wont have to worry about the VLANs themselves, just the layer 3 info, which...in theory a 'hard' roam should take care of. I think.

From my conversation with support (which was great btw), it appears that my configuration is correct (yay!), but due to my particular oddities of subnets, VLANs and physical layout I will need to further expand my manually added neighbors.

It appears that one of the issue is that the APs may not be able to exchange roaming information over wireless due to signal strength between each other.

I will also be trying my theory to making all the traffic (management and client) untagged from the AP thus sort of taking layer 2 VLAN assignment out of the equation and hoping that layer 3 hard and soft roams work better.

I don't remember exactly what I did. One of the things that I do remember is turning the radio power down to create smaller cells. IIRC I brought up the help page for the radio profile page and read through it step by step.

We have a school environment, most blocks are close enough to at least one other block. But I would have thought that if the client could not see the AP it originally authenticated on it would reconnect again to the closest AP.

We do want the students and teachers to roam across the entire school, do you think it would be a good idea to add all the APs as neighbours?

Sorry for bringing back an old thread...but I am having the exact same issue. I have segmented my network into multiple subnets with separate VLANs
based on the different floors of the physical building. I am using
device classification tags to have the AP's automatically dump the clients onto the
appropriate VLAN for each floor of the building. This is working as long as the clients don't move off of their floor.

I have enabled layer 3 roaming in the user profile, but it is not working correctly. The issue is that the client will
successfully authenticate to the SSID, but then when they roam they are not GRE tunneling back to their other VLAN and the client will sometimes lose it's IP address and it does not receive a new one, it ends up at 169.254.x.x.

DHCP Relay is set up on all my switches and is working correctly because
wired and other wireless clients will obtain an IP just fine. It appears
to happen only if the client roams.

I have manually set up all of the AP's in the building as neighbors to the other AP's in the building which hasn't helped. I had a case open with support but we didn't make any progress on solving the issue. I did not enable VLAN ID Sync because my HiveOS is later than 5.1r5.

It is really frustrating, somebody on the 5th floor will grab their laptop, walk down to the 4th floor. They stay connected to the SSID the entire time but when they hit the 4th floor it isn't setting up the tunnel to route traffic so first they just can not route traffic, then eventually they lose their IP Address and instead of getting a new one they end up with 169.254.x.x and still can not route. If they turn their wireless off and back on it grabs an IP address for that floor and starts working again.