Wireless Access

User table is not forwarding from Primary master controller to secondary standby controller when primary master controller failed and vice versa, In this setup we are running HA and VRRP

 

 

AP's are failing over from master to standby and vice verse when there a failure on controller. only user table was not forward from active to standby  and client disconnects and need to reauthenticate

Hi,

 

It is very unusual, need to diagnose , usually user table should be updated periodically, verify the following areas,

 

BTW what is the image version you are using ?

 

1. Is the database sync enabled and time is specified ? if not enable and specify the period.

2. Check the communication statistics by using "show vrrp <id> statistics "

 

Please feel free for any further help on this

 

 

---

@Venuprasad wrote:

User table is not forwarding from Primary master controller to secondary standby controller when primary master controller failed and vice versa, In this setup we are running HA and VRRP

 

 

---

Do you have client state sync enabled?  http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/VRRP/HighAvStateSynch.htm

 

The client state sync does not synchronize users in the user table, rather when doing 802.1x it synchronizes PMK and cache key entries to minimize reconnect times.   Please read the link above to also see the limitations of state sync.  "Database Synchronization" has nothing to do with state sync - It only synchronizes the internal databases of the controller, NOT the user tables.

 

Hi Colin,

So the User table will be pushed to the standby along with the database or not ?

 

Please through some light on this.

 

Venu,

 

Please see the link above.  Only PMK and key cache entries are synchronized to avoid a full radius authentication for 802.1x clients upon failover.

Hi Colin,
I'm clear with "client state sync". my point is, how and when the user table will be updated to Standby controller ? as you said user table will bot be updated through database sync. I want to know what is the mechanism behind updating the usertable.
Thanks in advance. 

Hi Colin,

 

I got it now. correct me if I'm wrong. user table will not be pushed to the standby rather new entry will be created after 11i 4 way handshake. Here reauthentication is avoided due to sharing PMK through OKC.

 

 

 

This mystifies me as well.  On the standby, the user table does not contain users from the active.

 

An OKC 4-way handshake can't restore server-derived AAA roles.

 

An SSL fast-reauth session restore to the RADIUS server would allow a reload of role,

but not of the enforce-dhcp state.

 

And most clients will not re-dhcp after an OKC roam or even after a fast-reauth.

 

But I don't remember having to kick dhclient on my linux box when I tested this way back when.

 

So... ?    Something must be stored somewhere.  Or I didn't have Enforce-DHCP on when I tested.

 

HI bjulin,

 

 

The State Synchronization not only synchronizes PMK and Key cache values between the active and standby controllers , it allows clients to authenticate on the standby without having to do a full 802.1X auth.

 

This is the trick. :)

There is no mystery bjulin. Every client receives a deauth and has to reauthenticate using the same rules as before. A client reconnect is the shortest portion of the fail over...making hundreds of access points all come up on the destination controller quickly is the biggest improvement over traditonal VRRP or backup LMS.

 

Colin, see that's what I thought.  So what good can having the PMK values do, if you still need to do a RADIUS transaction to get the AAA roles?  That's the mystery.

 

Is it that the client state synch is only actually useful in certain situations where the roles are entirely derived from controller rules?

 

A full radius transaction puts a very heavy load on a radius server on failover for thousands of users.  PMK Caching decreases that load and decreases the time of failover.  Again, the client associating and the roles being assigned consumes the least amount of time when hundreds of access points fail over.

 

Colin,

 

I'm not arguing that the HA failover as a whole isn't a very welcome feature.  It works very well and is sufficient for our purposes.

 

But there's something I am still not apparently getting about the client state sync feature.  If your roles come from the RADIUS server, and you reauth, and the standby does not have the user table entry, the standby does not know what VLAN to put you in or anything else about your access policy.  So we've established that the clients cannot just do an OKC 4-way and go along their merry way.  So as far as I can see, having the PMK in this situation does nothing to reduce load to the RADIUS server -- the clients will fast-reauth whether or not the PMK was available, so client state sync does not help make that happen.

 

So my question is, when you are using roles derived from the RADIUS server or even just from the username, is there any reason to care whether you have this feature turned on or not?

 

 

OK, I finally sliced off some time to test this.

 

I used a client that does OKC, and moved one of my APs to the standby controller.

 

I associated that client to the AP on the standby and waited for an old user-table entry on the

master to time out.  Once it was gone, I started a ping from the client and I unplugged the

standby-attached AP so the station had to roam to an AP that was on the master.

 

Here's what happened:  The master got a 4-way handshake and pulled the correct vlan

from the client without any RADIUS transactions.  I can only assume it pulled it from the

standby using some mobility-ish protocol.  However, the client was NOT able to communicate,

because it had no user-table entry, and Enforce DHCP was preventing the pings from

creating a user-table entry.  I had to manually renew the DHCP lease on the client and

then pings started to work again.  I suspect the number of wifi clients that will tell their

dhclient to renew after an OKC roam is close to zero, so I would have to say, turn off

client state sync if you are using Enforce DHCP in an HA setup.  Especially if you

are spreading your APs between the master and standby.

 

To test further, I unplugged the new AP, forcing the client to roam to another AP that was

also on the master.  The client never lost a ping during this OKC roam.