Devices do not to Roam correctly.

  • 2
  • Question
  • Updated 3 years ago
  • Answered
When I look at the configuration of an AP, I can see under the Roaming Configuration 2 sections one called "Included Neighbors" and the other "Excluded Neighbors" There are no AP's in either "Selected Neighbors" selections. Am I meant to manually configure these for roaming to work correctly?

I am in the middle of tracking and mapping where our AP's currently reside and how
much interference is being generated between them.

I want to make sure that each unit is located where we think it is.

In the dashboard there is a section called ASCP Neighbor Information - Can I make it show names rather than MAC addresses?

I am trying to identify location based on the neighbour information. Unfortunately the ASCP information only shows the MAC addresses of the neighbours, and I am unable to find the MAC address in the main list of All Devices as only the UTP MAC address is shown.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 2
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
Hi Michael

what sort of roaming are you looking at?

vlan for a whole floor would be layer 2 roam

2 vlans on one floor would be a layer 3 roam.

If the APs in different vlans can hear each other via the air, then you can statically assign the neighbor info.

my understanding of the Aerohive Layer 3 roam

is that the APs on different subnets need to hear each other in the air, if not you have to add the neighbor info.

assuming same floor different vlans
a gre tunnel will be established, but the APs will tear this down if client sessions end then client will associate to the new subnet. so you are on a phone call and you walk a to b then hang up. tunnel torn down and you associate to new subnet

A layer 2 roam would be different, Key Caching

User associates and authenticates and keys are distributed
AP predictively pushes keys and session state to one hop neighbors

this speeds up the reassociation process.

this is the new stuff, but clients have to support it

Fast BSS Transition info

In general you have to have somewhere to roam to, so there can not be a break in the network.
your radio must be in an active session.
We have folks that go into clam shell and expect to roam, or they enter a stairway with no signal and expect to roam.

Forgot the most important part.

The client is responsible for making roaming decisions, this proprietary

Hope this helps
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
Thanks Andrew,

We have a very simple network. All AP's in default VLAN 1.

All wireless clients get assigned VLAN 16, and will be re-assigned/keep the same VLAN when roaming. My understanding from what you have said is that would be layer 2 roam.
Is that correct?

We do not have the Voice Enterprise options enabled.
Does that mean we are not using fast roaming?

From the article above I cannot expect to see 8ms roam. What sort of expected roam time would I be looking at? Of course when I go and test roaming for myself there does not appear to be an issue.
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
Hi Michael

If all users are in same vlan, then it would be a layer 2 roam.

vlan 16 would be 1 broadcast domain.

This has info about all the roams you can do.

The CWSP Official Study Guide has a chapter on Fast Secure Roaming as well as sage advice.

And Devin Akin's Robust Security Network (RSN)
Fast BSS Transition (FT) whitepaper reviewed by David Coleman has lot's of great info.

Define roaming or find out what the user thinks roaming is. Look for dead spots ie no wireless coverage, stairwells, elevators. Some users will close the lid [Clam Shell],and some devices put everything to sleep when this happens.

Hope this helps.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
From each AP the ASCP Neighbor Information has at least 8 AP's. Yes we have a very dense AP network.

I'm thinking that if I add some selected neighbours (maybe upto 4) to the list of selected neighbours then clients will only roam to the selected neighbour AP's.

And If I put AP's that I do not want to be able to roam to in the excluded list then clients should only be able to roam by hopping between selected neighbours.

Are these lists inclusive or exclusive?

My thought behind this is I want the neighbours to be in order for the path that clients will take to walk between AP's. For example I do not want AP's on different floors to be neighbours, unless they are close to the stairs to get between floors.

This way while a client walks between AP's on the same floor they get handed between AP's that are closest to them as they walk.

My problem is how do I identify the neighbours via the ASCP Neighbor Information?
Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
Hey Mike

If you are flat layer 2, I don't think you need to add or exclude neighbors

just go to the 802.1X ssid and advance features and check the caching options

Roaming Cache Settings: When using 802.1X authentication, the RADIUS authentication server sends the wireless client (or supplicant) a master key from which the client derives a PMK (pairwise master key). Using the same computations as the client, the RADIUS server derives an identical PMK and sends that to the access point (authenticator). When using WPA/WPA2 PSK (Personal) for access security, the preshared key acts as the PMK.

The client and access point then perform a four-way handshake, using the PMK to establish a PTK (pairwise transient key). Next, they use that PTK to encrypt unicast traffic between themselves. The access point also makes a GMK (group master key) from which it derives a GTK (group temporal key) for encrypting and decrypting broadcast and multicast traffic. Using the secure connection established for unicast traffic, the access point sends the GTK to the client.

Every time a wireless client using 802.1X authentication sends an association request to an access point, it includes a PMK (pairwise master key) ID list. When a client associates with an access point initially, the list is empty. When the client roams and sends a reassociation request to a new access point, the PMK ID list can contain the PMK ID from the first association, a new PMK ID based in part on the MAC address of the new access point (which the client learned from its beacon), or another empty list. The new access point then searches its PMK ID list for a match with the PMK ID that the client sends. If it finds a match, it uses that PMK when performing another four-way handshake to establish a new PTK. If it does not find a match, then the client, access point, and authentication server must go through the entire 802.1X authentication sequence again.

APs keep PMKs that their neighbors send them in their roaming cache. The following settings control how often Aerohive devices send roaming cache updates to their neighbors and when to age out and remove old entries from the roaming cache.

Roaming Cache Update Interval: By default, an Aerohive AP sends updates to its neighbors about the clients currently associated with it every 60 seconds. The neighboring APs use this information to update their roaming caches—if necessary—with the most up-to-date client information from their neighboring APs. You can change the frequency for sending roaming cache updates to neighbors from 10 and 36,000 seconds (10 hours).

Roaming Cache Ageout: By default, an Aerohive device removes an entry from its roaming cache if it is absent from 60 consecutive updates from a neighbor. You can change how many times an entry must be absent from a neighbor's updates before removing it from the roaming cache from just once to 1000 consecutive times.

To calculate the length of time required for a PMK to age out, multiply the update interval by the ageout value. Using the default settings 60 seconds (interval) x 60 (absences), a PMK ages out after 60 minutes.

You can modify the roaming cache settings here for an SSID, where they apply to clients that use this SSID, or at the hive level, where they apply to all clients. The following rules govern when one setting overrides the other:

If you leave the SSID-level roaming cache settings at their default values but change them for the hive, then the AP applies the hive-level settings.

If you change the roaming cache settings for an SSID, then the AP applies those settings to clients using that SSID whether or not you change the hive-level settings.
Photo of Haydn St

Haydn St

  • 17 Posts
  • 1 Reply Like
We also have a dense AP environment, I am finding that moving between buildings (which also happens to be VLANs) does not work so well.

Would it be a good idea to add neighbours, only if they are in the same Block ie. APs using the same VLAN?

We dont necessarily have to be able to roam to a new block, what I hope would happen that once moving from one block to the other it would re-associate and gain a IP assigned by the new VLAN in the new block.

What we find is that they remain connected to the SSID but dont pick up an IP in the new building according to the new VLAN they just entered into, they will get a fallback 169 address.

Temporarily changing to another SSID and then back fixes the issue but seems like there is minute detail we are missing.