Solved: Issue with clients roaming with WLC Code 7.4.100.0 in Flexconnect Mode

kcruickshank · ‎05-02-2013

Description of Problem:

We are seeing problems with access points running in Flexconnect mode on our 5508 series controllers running 7.4.100.0, whereby when a client roams between access points on the same controller, the client loses IP Connectivity. For example when you enable the wireless card on the client it connects to the access point and authenticates as normal. With a command prompt open I start a continuous ping to another host on the network and replies are received. Then I walk away from the connected AP with the laptop to another area in the building to force the client laptop to roam to another access point. When the client roams to another access point the ping responses stop replying and I then only receive timeouts. While on this new access point I checked the status of the client on the controller from another laptop and the status of the client that roamed shows it is associated on the new access point but is not authenticated. To enable the client that has roamed to the new access point to regain network connectivity I have to switch off the wireless on the client and then switch back on. After doing this the client reconnects to the same access point that it had roamed to and then the pings start working again.

As a test I changed the operating mode of the access points from Flexconnect to Local mode. I then carried out the same tests as above with the result being the client roamed between access points with no loss of network connectivity and status was associated and authenticated on each access point it roamed to.

Models of access points in use:

AIR-LAP1242AG-E-K9

AIR-CAP1602I-E-K9

The modes of security in use:

[WPA2] [Auth(802.1X + CCKM] EAP-TLS

[WPA2] [Auth(PSK)]

Clients used during the above tests:

Dell Latitude E6400

Windows 7 64 Bit

Intel 5300 AGN Wireless Card Driver version 14.3.2.1 Provider Intel

802.1X EAP-TLS

Apple iPhone 5

IOS 6.1.3

WPA2 PSK

Using a spare 2504 series controller I joined two AIR-CAP1602I-E-K9 access points with the controller running software version 7.4.100.0. Both access points were configured as per the 5508 controller and were running in flexconnect mode. When roaming between the two access points I had the same issue where I lost network connectivity and loss of pings during a roam. Again I changed the operating mode of the APs to be local. When doing this the client roamed ok without any loss of pings. I repeated the tests using different model of access points, a AIR-LAP1131AG-E-K9 and a AIR-CAP3602I-E-K9. Again when the APs were in Flexconnect mode I lost network connectivity and pings when roaming however it was OK when the APs were changed to local mode.

I then decided to try a different software release on the 2504 controller (AIR-CT2500-K9-7-3-112-0.aes). Because AIR-CAP1602I-E-K9 is only supported on WLC code version 7.4.100.0, I continued to use the AIR-LAP1131AG-E-K9 and the AIR-CAP3602I-E-K9 access points. Again when the APs were in Flexconnect mode I lost network connectivity and pings when roaming however it was OK when the APs were changed to local mode.

I then decided to try a different software release on the 2504 controller (AIR-CT2500-K9-7-2-115-1.aes). However this time when the APs were in Flexconnect mode the client roamed without any network connectivity issue and did not drop any pings.

So this would suggest that there is a software bug with WLC Software Release 7.4.100.0 that is causing roaming issues when the AP is in Flexconnect mode.

Has anyone else in the community noticed this issue?

David Watkins · ‎05-10-2013

Do you have the APs configured in a FlexConnect group together? For CCKM you will need them to be in the same group for seamless fast secure roaming. Can you verify the APs are properly joined/connected at the time of your testing? The EAP-TLS authentication would most likely fail if the APs are in stand-alone operation, unless you have a backup RADIUS server defined in the FlexConnect group. Also, can you verify that the APs have identitcal WLAN->VLAN mappings so there is no L3 roam performed?

Just to confirm, for the IOS device using PSK, you experience the same issue?

edit:

The IOS device only supports sticky key caching, so a full auth is going to happen during to new AP associations, with the client supporting a max of 8 pmkids. 7.2 did introduce the option to enable sticky-key caching on WPA2 WLANs, however it is not supported in flexconnect. Your "apple" device is going to perform a full auth on every roam, but this is PSK so you would not see more than a couple 100ms of connection loss during the authentication process.

View solution in original post

ericgarnel · ‎05-10-2013

It may not be a bug, but a change in the characteristcs or algorythms in the new code compared to the old.

You may have to make some adjustments after upgrading.

Break out the packet sniffer with multiple sensors or another tool like AirMagnet Wifi Analyser to accurately see when the device is roaming.

For the iPhone , useiPhone Configuration Utility, free from http://www.apple.com/iphone/business/it-center/

You can see when the device roams in the console window of the utiltiy.

Also, an excellent reference for Apple devices in a Cisco world

http://www.cisco.com/en/US/docs/wireless/technology/vowlan/bestpractices/EntBP-AppMobDevs-on-Wlans.pdf

Eric

David Watkins · ‎05-10-2013

Do you have the APs configured in a FlexConnect group together? For CCKM you will need them to be in the same group for seamless fast secure roaming. Can you verify the APs are properly joined/connected at the time of your testing? The EAP-TLS authentication would most likely fail if the APs are in stand-alone operation, unless you have a backup RADIUS server defined in the FlexConnect group. Also, can you verify that the APs have identitcal WLAN->VLAN mappings so there is no L3 roam performed?

Just to confirm, for the IOS device using PSK, you experience the same issue?

edit:

The IOS device only supports sticky key caching, so a full auth is going to happen during to new AP associations, with the client supporting a max of 8 pmkids. 7.2 did introduce the option to enable sticky-key caching on WPA2 WLANs, however it is not supported in flexconnect. Your "apple" device is going to perform a full auth on every roam, but this is PSK so you would not see more than a couple 100ms of connection loss during the authentication process.

kcruickshank · ‎05-22-2013

Yes thanks for the input spot on advice. I have finally closed this Tac call with Cisco as they have indicated that the DHCP required option is a feature and would probably not recommend turning on.

Solution DHCP Required option now set to the default for all WLANS which is unchecked. Now no roaming issues for any of the previously tested clients.

ericgarnel · ‎05-22-2013

iOS devices support FT roaming as of 6.0.1 release.

Here is the Apple KB with all the details:

http://support.apple.com/kb/HT5535

michaelkdj · ‎05-31-2013

I am having this exact same problem. I am running 7.3 on 5508 WLC. My remote site LAP's are using Flex (HREAP). The initial access point that my laptop associates to connects with no problem, as soon as I wander out of range of the initial LAP and into the area of another access point, I lose data connectivity. The was validated like the original post as I start a constant ping on the LAN and watch as the ping latency increases and then ping replies stop. The only way to correct the problem is resetting of the wireless adapter on the laptop. Side note my DroidX has no problem wandering from AP to AP.

Laptop: Windows 7 32bit

I then returned to my home site and test where I have a secondary controller and the LAP's are configured for local mode, no problems roaming from access point to access point. Validated with constant ping test. The pings drop for a second and re-

continues as the laptop reconnects.

**Edit: I am going to try the removing the DHCP Addr. Assignment required option, and report that back to the TAC engineer.

Message was edited by: Michael Dunki-Jacobs

**Edit Solved:***

The problem is in deed solved by turning the "DHCP Address Required" but why?

michaelkdj · ‎05-31-2013

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a0080810880.shtml

The DHCP Required option in WLAN settings allows you to force clients to do a DHCP address request/renew every time they associate to the WLAN before they are allowed to send or receive other traffic to the network. From a security standpoint, this allows for a more strict control of IP addresses in use, but also might have affects in the total time for roaming before traffic is allowed to pass again.

Additionally, this might affect some client implementations which do not do a DHCP renew until the lease time expires. For example, Cisco 7920 or 7921 phones might have voice problems while they roam if this option is enabled, as the controller does not allow voice or signaling traffic to pass until the DHCP phase is completed. Some third-party printer servers might also be affected. In general, it is a good idea not to use this option if the WLAN has non-Windows clients. This is because the more strict controls might induce connectivity issues, based on how the DHCP client side is implemented. This is how you verify:

ken · ‎04-07-2017

Has anyone seen this (the issue above of lost/intermittent connectivity) with:

Controller: WLC2504

Access Points: 3702

Firmware: 8.0.140

We seem to be having the issue described above of intermittent/lost WiFi connectivity. Anyone know how to fix it? Thanks