Roaming Technologies on Meraki Access Point

Wireless deployments that that consist of more than one Access Point (AP) broadcasting a wireless network will likely include roaming clients. Since clients can only be associated to one AP at a time, roaming from AP to AP must be quick in order for the user to have a seamless experience. There are a number of technologies that can be employed in order for roaming to be transparent to the end user. 

Why does roaming occur? 

A wireless client will decide to roam when it detects a better signal from a new AP than the one it is currently associated with. This behavior is normal, especially for mobile devices such as laptops, tablets, and mobile phones.

Challenges with Roaming

When a client roams to a new AP it needs to establish an association/authentication relationship with that AP. In situations where the APs are acting independently of each other, this whole process must occur each time the client moves to a new AP. Without the inclusion of advanced roaming technologies discussed in this article, the client may experience delays when roaming from AP to AP. This results in a service affecting issues like voice drops on VoIP calls and video stuttering on real-time video streams. 

 Client Tracking

Each AP keeps track of all its connected wireless clients. This includes the client's network access information such as VLAN and group policy (either from Dashboard or RADIUS). During a roam, this information is shared the with other APs in the network so the client can maintain their level of access.

Client tracking information is shared with Access Points via broadcast messages, so ensure that port isolation and private VLAN features are not enabled upstream in a configuration that can block broadcasts between APs.

PMKsa caching 

PMKsa caching is enabled by default on all Meraki Access Points and is leveraged when using a secure SSID (WPA2-PSK & WPA2-Enterprise). PMKsa caching is also known as "fast roam back" by some vendors. This technology is used when a client device reconnects to an AP it previously had a key exchange with during association. The Session-Timeout value in RADIUS may set a custom session expiration length which would expire the keys after a certain amount of time. 

OKC

OKC is enabled by default on all Meraki Access Points and is leveraged when using a secure SSID (WPA2-PSK & WPA2-Enterprise). OKC stands for Opportunistic Key Caching and is a non-standard fast roaming technology supported by Microsoft Windows clients and some Android devices. The Meraki OKC process utilizes key information from the client's first association to generate keys for other APs in the network. 

802.11r

802.11r is disabled by default on all Meraki Access Points. 802.11r is a standards-based fast roaming technology, supported by Apple iOS devices and some Android devices, that is leveraged when using a secure SSID (WPA2-PSK & WPA2-Enterprise).

Please refer to our documentation for more information regarding 802.11r.

While many customers enable 802.11r within their network without issue, some legacy devices may not connect to an 802.11r network. 802.11r is a recommended feature due to its many benefits; however a device audit is encouraged first to ensure that mission critical devices are not affected.

Configuring 802.11r in Dashboard 

This feature can be enabled from the Configure > Access control page under Network access > 802.11r. If this option does not appear, a firmware update may be required.

Adaptive 802.11r

Adaptive 802.11r is currently available in beta. Please reach out to Cisco Meraki Support to have this feature enabled.

Cisco + Apple have co-developed an adaptive roaming technology for iOS devices to improve real-time application experience on enterprise networks. Adaptive 802.11r enables fast roaming for iOS devices detected by the Meraki Access Points while minimizing the possibility of incompatibility issues seen with full 802.11r enabled. 

Select "Adaptive" from within the 802.11r dropdown on the Wireless > Access Control page to enable this feature. 

802.11e

The 802.11e standard includes a method that allows an AP to advertise its load to wireless clients. Specifically, the QBSS element is used to advertise load via beacons.

Meraki APs will use the QBSS element to report the current channel utilization and the number of stations associated to the wireless access point. Some clients use this information in order to make roaming decisions.

802.11v

802.11v BSS Transition Management (BSS-TM) builds on 802.11k and 802.11e by advertising the client of the best AP to roam to, as determined by load. Meraki APs have 802.11v BSS-TM enabled by default, allowing devices that support the standard to query the AP for a list of recommended APs based on load.

Collecting a Wireless sniffer trace using Cisco LAP

You can use the Cisco WLC and LAPs in sniffer mode, in conjunction with a wired sniffer (feature designed for AiroPeek/Omnipeek, but can work also with Wireshark).

A single wired sniffer can collect packets from multiple APs, so this method is very useful to run multi-channel traces. For static scenarios, if it’s possible to move the sniffer AP, this can be used as an effective alternative to other sniffing options.

For roaming scenarios, the sniffer APs are usually installed in the proximity of the APs the client roams through, and this will report the “point of view” of the static APs rather than the client.

In order to see the RF from the point of view of the client while roaming, a multi-channel wireless trace should be captured using a laptop with multiple Wireless NICs that will follow the test client.

Configuration steps

1) WLC / AP side

Here are the steps in order to collect a trace using a sniffer mode LAP

• Configure the AP in Sniffer mode:

The AP will reboot and it will not be able to serve clients.

• Once the AP has re-joined the WLC, configure the radio of the AP (802.11b/g/n or 802.11a/n):           
• specify the sniffer IP address
• select the channel
• enable sniffing

• The sniffer will receive the 802.11 traffic encapsulated using the airopeek protocol, from the WLC management IP address with source port UDP/5555 and destination UDP/5000

2) Sniffer side: Wireshark

If using Wireskark to receive the traffic, (Note: Please use the most current version of Wireless due to various decoding issues of past releases, Download Latest) follow the steps below:

• Set the capture options to receive only traffic on UDP/5555:

This filter is optional but strongly recommended as it excludes all the non-wireless related traffic from the capture. Consider that the WLC sends traffic to a UDP port there’s no application listening on the sniffer side; this results in having a ICMP port-unreachable response for each packet received from the WLC.

Although this is expected, the filter above helps to exclude also this traffic which is useless and so it can only cause the trace to be bigger and more difficult to read.

• Then, start the capture:

• The captured traffic has to be “decoded as..” AIROPEEK in order to be able to see the 802.11 traffic:

Note: In Wireshark releases 1.8 and higher, AIROPEEK has been renamed to PEEKREMOTE.

• The 802.11 traffic will now be visible:

The RF info shown above (e.g. the channel, signal strength, noise.) are added by the AP. Wireshark can decode only some of these elements, whereas OmniPeek will show all of them.

 

3) Sniffer side: OmniPeek

When using OmniPeek as the receiver of the traffic stream from the WLC/AP in sniffer mode, it’s first of all necessary to create a “Cisco Remote Adapter” under the “Adapter” menu of the “Capture Options” window:

At least one adapter is required; the name is a mandatory field, whereas the “IP Address” field can be left blank if you don’t want OmniPeek to filter the incoming traffic from a specific WLC.

In this case it’s not necessary to filter out any traffic (such as the ICMP port-unreachable) as OmniPeek will listen on the UDP port to specifically capture the data stream from the Wireless LAN Controller.

Before starting the capture, confirm the settings on the main OmniPeek window:

At this point the capture can be started and the result will be a trace including the RF info reported by the AP:

NOTE: By default OmniPeek remote adapter picks up the timestamp sent by the AP itself; this info has nothing to do with the AP clock, so the resulting timestamp will be incorrect. If you use a single sniffer AP the timestamps will be wrong but at least consistent; this is no longer true if you use multiple APs as sniffers (as every AP will send its own timestamp info, causing funky time jumps on the merged capture).

• Solution

You can explicitly tell OmniPeek to use the local sniffer PC clock to set the packet timestamp.

This solves both the single and multi AP scenario, having correct and consistent timestamps as long as the PC running OmniPeek has a NTP-sync’d clock.

• How-to steps:

In OmniPeek, do the following:

1. Go to Tools>Option>Analysis Modules

2. Search for cisco remote adapter then double click to bring out the options.

3. Tick on the Timestamp option then click OK and test again the capture.

*** References: Cisco Deployment Documents