cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
657
Views
11
Helpful
10
Replies

802.11r roaming and re-auth on roam

trondaker
Level 3
Level 3

Hallo,

We have been running 8540 in HA/SSO for a long time, and 802.11r has been working very well after the clients started supporting it. Now suddenly, without have done any changes, a lot of clients are starting to experience a full re-auth on roam. This obviously is annoying, as they have to go through a auth and dhcp-process, which takes a few seconds.

What i dont understand is, why does the controller force the client into re-auth?

*Dot1x_NW_MsgTask_4: Jan 29 12:13:30.220: [PA] 94:e6:f7:1f:90:8c dot1xProcessInitiate1XtoMobile to mobile station 94:e6:f7:1f:90:8c (mscb 157, msg 157)
*Dot1x_NW_MsgTask_4: Jan 29 12:13:30.220: [PA] 94:e6:f7:1f:90:8c reauth_sm state transition 0 ---> 0 for mobile 94:e6:f7:1f:90:8c at 1x_reauth_sm.c:53
*Dot1x_NW_MsgTask_4: Jan 29 12:13:30.220: [PA] 94:e6:f7:1f:90:8c Finishing FT roaming for mobile 94:e6:f7:1f:90:8c
*Dot1x_NW_MsgTask_4: Jan 29 12:13:30.220: [PA] 94:e6:f7:1f:90:8c EAP-PARAM Debug - eap-params for Wlan-Id :7 is enabled - applying Wlan specific eap timers and retries
*Dot1x_NW_MsgTask_4: Jan 29 12:13:30.220: [PA] 94:e6:f7:1f:90:8c Disable re-auth, use PMK lifetime.
*Dot1x_NW_MsgTask_4: Jan 29 12:13:30.220: [PA] 94:e6:f7:1f:90:8c dot1x - moving mobile 94:e6:f7:1f:90:8c into Force Auth state

 

After this a full auth to ISE is done, and then a new dhcp-req/offer. Am i missing something obvious here? WLC running 8.10.185, APs are 9115.

10 Replies 10

@trondaker 

 The logs only show what you are already seeing on the network. Client is being forced to re-auth. If I were you I would focus on the client as clients constantly receive updates from their vendor and something can be different now. If you are sure the WLC side is the same, that´s my line of troubleshooting.

If you identify some similarity on the problematic clients, like vendor, for example. It would be easier to track down the problem.

marce1000
Hall of Fame
Hall of Fame

 

 - Also go for  https://software.cisco.com/download/home/286284728/type/280926587/release/8.10.196.0
   on the controller to have the latest bugfixes , the aireos models are EOL , using last available software is always
   recommended.

 M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Leo Laohoo
Hall of Fame
Hall of Fame

Reboot the APs.

trondaker
Level 3
Level 3

Thanks, i will upgrade the controller tonight, and check if devices have a new versions recently installed. But is there any reason the controller would force a re-auth when running 802.11r?

Hard to say exactly but the process of fast transition (802.11r) starts on client side. If you did not change anything on the WLC side, and knowing that clients constantly gets update from vendor, my first though would be on the client.

But, as you are going to upgrade the WLC,  its better wait the behavior after the upgrade.

 

FlavioMiranda_0-1738238173380.png

 

trondaker
Level 3
Level 3

Thanks, will let you know!

Scott Fella
Hall of Fame
Hall of Fame

That is a tricky one, but everyone has been through, "nothing has changed" scenarios.  I would assume that the end devices gets patched or upgraded, even maybe newer devices gets implemented.  Some things I have tried in the past was to perform a failover to the other controller to verify is something was going on with the primary.  Then just reboot the primary and make that the primary again.  Switching to one controller to another can also help with isolating an issue with the controller itself.  The risk is, that the secondary controller has an issue and when you failover to that, things break.  Might be better to reboot the secondary and wait for that to come back up and fully sync.  Then proceed with the failover.

-Scott
*** Please rate helpful posts ***

trondaker
Level 3
Level 3

It seems one issue was related to Mac Os 15.3 and private-mac. Something strange happens there that causes full auth much more frequently then before. Disabling private mac and disable the ip tracking thing seems to have solved most of the issues for Macs. Doesnt seem to be fully resolved for all devices yet though, so still on the search.

There are a lot of things on the client side that can cause these issues like what you have found.  We use dot.1 and I deny any using random mac address in the secured SSID's, but allow that on the guest.   Its difficult because users might complain they no longer can connect of have connection issues after they upgrade their device, but the decision to have users configure their devices a certain way also makes it difficult.  That is what makes wireless the service line that folks complain about all the time, they just want their device to work just like how it works at home.

If you are using radius, you would need to identify a few devices and debug their mac and look at the auth on both the controller and the radius server, you should see something that doesn't look right, but you are on the right track.

-Scott
*** Please rate helpful posts ***

Can I see l2 and l3 secuirty of this SSID 

MHM

Review Cisco Networking for a $25 gift card