Our Foriegn WLC -188.8.131.52 and Anchor WLC code 184.108.40.206. Mobility is up and while testing HA (SSO), when Primary is hard rebooted, the client is asked for re-authentication.
Actually it should not ask for reauth as the client database must be synced.
We have build the redundancy and the standby state is STANDBY HOT .
We are able to see that the APs are not getting disassociated .
We are facing the issue only with the client reauthentication .
In my setup i have a SSID where webauth configured and the trafic is send to a Anchor controller in my DC
When i do a restart of the primary controller all my clients are forced to reauthenticate .
Venky, did you get this resolved ? I am having similar issue with customer who has 2 WLCs on code 220.127.116.11 in HA . the WLC/AP -SSO works fine but the newer: (7.5 released first) > Client-SSO, when guest-tunneling the traffic to an Anchor Controller in DMZ, on a different code than internal WLCs, fails to pick up all the clients fromthe WLAN. We go from 100 connections to 10 connections. They eventually pick back up, but it is some 30 minutes later.
Is this the same thing you are experiencing ? Thanks
Why not use the same code if that is the know fix? Typically the matrix does show compatibility for anchor on different code versions and that holds true for being able to bring up the mobility tunnel. Is the issue when the primary is working and just normal guests traffic or when you fail over the controller to the HA and client SSO breaks things?
Good Morning- Scott- that was what I advised the customer to do upgrade to see if it changes things. I like same code on all WLCs. The problem lies in the mobility tunnel with guest anchoring sessions drop astronomically. We made sure all clients were in a RUN state, meaning had an IP address. A lot of devices just connect and pass no traffic from a report I ran in Prime.
BTW one of the anchors is a WiSM-1 and is EOL they can't upgrade it past that< hence an issue! Darn it
v7.5 was the worse...... yes, they should upgrade to v18.104.22.168:)
Well eventually they will need to replace that due to the newer code version that will no longer support that mobility tunnel. My customers that run the Chromebooks have both the foreign and anchor on the same code and are both 5508's. One client was just on v7.0 and I just upgraded them to v22.214.171.124 with no issues. Now this is with N+1 not AP SSO. I'm actually going to enable AP SSO next week to see how it works for them.... not really a fan, due to issues with AP SSO.
In your case, it seems like the issue can be with the anchoring to the WiSM1. I would at least make sure they are on the latest code on that v126.96.36.199.
Cool! AP SSO, on 188.8.131.52 "should" be smooth, as long as they plug a known good Ethernet cable (straight thru does work ) to both Redundancy Ports on both WLC, if they are back to back/physically, plus make sure the HA Licensing on the Secondary is SKUed right. You already know that but others that read this may face some of the issues we encountered- doing this remote.
-BTW: there is no way to verify via CLI or GUI, that the link light it up. There is a bug CSCud54312 that highlights this and it still persistent in 7.6. Make sure they "SEE" the link light is operational on the WLCs for L2.
- It is the mobility and Client SSO that is sketchy- waiting on TAC to chime in however , this is the "July the 4th:> hence the priority is lowered internationally, for the World Cup as well.
It should be smooth:) v184.108.40.206 has been stable so far in many of my customer environments, but v220.127.116.11 i think is really stable for AP SSO. I have used v18.104.22.168 due to customer requirements that are not in v22.214.171.124 or for hardware support, but v126.96.36.199, I must say is pretty stable.... of course, not 100%.
I always look for that light to verify the RP ports are connected just fine.
If the customer still has issues after the upgrade, then try to disable AP SSO for testing and see if using just one WLC or setting up N+1 fixes the issue.
The customer insists on AP and client SSO working fully no if, and's, or buts
We know that N+1 works, but it is too slow of a failover for this customer.
Close to 300 APs on this WLC and they are a 24 X 7 operation. They are expanding and having this work right is what sales wants and so do I as a NCE (not commissioned for my work).NCO ? :-)
As I have been taught from early on > The customer is right even if there is a bug in the house, we need to exterminate and fix it fast. Revenues depends on quick, efficient support. It is my job to set expectations and to mitigate risk as well. They are patient and we do have a great SAT report with them - which speaks volumes.
Be careful with AP-SSO . When doing a manual fail-over by shutting down the interface to the WLC from the WLC, the APs did not fail-over to HA WLC. The "graceful" failover with the cli of redundancy force switchover worked well. < hmmm
Just to add...
After a switchover, if a peer controller has a controller software release that is prior to Release 7.5, all the mobility clients are deauthenticated.
Sent from Cisco Technical Support iPhone App
Thanks for the reply scott. Peer wlc also 7.5 only.
But as i said our anchor wlc has 7.4.
Anyway we will upgrade it tomorrow to 188.8.131.52.
Hope this Anchor - Foriegn design is not the cause