Wireless Access

I know that if I have an L2-Connected cluster there's no impact to clients if an MC fails.  But what is the impact to the clients if I do not have L2-Connected Hitless Failover? What happens in an L3-Connected cluster when an MC fails ? 

 

Thank you.

All users will need to reauth since the firewall sessions are not shared between controllers



Thank you

Victor Fabian

Pardon typos sent from Mobile

Thanks, Victor.   Do the APs perform an LMS style failover?  I'm trying to get an idea of how long the client wireless connections will be down.

Yes



Thank you

Victor Fabian

Pardon typos sent from Mobile

Is this an accurate statement? 

• In an L3-Connected cluster, wireless clients will experience about 10+ seconds of downtime as their AP fails over to the other Mobility Controller, and the client reauthenticates.

I'm basing the "10+ seconds" timeframe on L3-CONNECTION being an "LMS style Failover".  If it's wrong, please let me know the correct timing.   

Thank you.

It depends on the application, the AP registering to the controller, the client reassociating after a deauth, and the client doing a full reauthentication.  It depends....

I apologize for my confusion on this topic. I haven't been able to find much detail on what happens in a L3 Connected cluster failover. 

 

Is L3-Connected clustering the 8.x verion of LMS/Backup-LMS redundancy?  Will the APs wait for a set number of heartbeats, then turn off their radios, and rebootsrap to the working MC? 

 

Or is the AP's association to the working MC fast (sub-second?) and the client impact is just due to the reauth? 

 

Thanks a lot.

 

 

If a cluster is l3-connected, you want to fix the issue that is keeping it from being l2.  There is no real utility to having a l3 cluster.   You want to make sure that every controller has VLANs trunked so that they can see each other.  You can find out what VLANs are not trunked properly by typing:

 

show lc-cluster vlan-probe status

 

The vlan_fail column will tell you what VLAN is not common between the controllers.

It's not that I want to use an L3 cluster. I just have to be able to explain the difference to my boss and the other engineers.  They're going to ask me what the failover time difference is between L2 and L3, and if I can't give them a quantifiable answer, they're going to think I don't know what I'm talking about, and ignore the entire discussion.  We're going to be deploying 8.x controllers at a lot of sites and I want to insure they make the effort to get L2-Connected clusters.

Explain to them that when a cluster is l3-connected, that is meant to flag you that you have your cluster misconfigured and all the L2- VLANs are not plumbed to all controllers.  L3-connected is a suboptimal mode that clusters fall into when they are not configured properly.  It is NOT a feature.  In a L3 cluster If a controller fails it will be evident to clients because access points must send deauths to them.  The same thing does not happen with an L2 cluster.  I don't have timing like you asked, but clients will notice and any delay-sensitive applications will either not work, or will have errors.

 

Okay.  Thank you!

More advantage by having L2 connected MC, but if you looking for a fail over plan it is best to set up 2x L2 clusters. If 1 of the clusters is having an issue fail the cluster out to the other. Also within the cluste size for a fail of a single controller. In my setup 3x 7240s in a cluster in a Primary data center and 2x 7240 in another cluster in back up data center. This way in cluster 1 i can lose or take a controller out of service and keep rocking. If i lose 2 i manually fail the access points to the backup data center. Using this setup I don't have to worry about L3 Clusters or setting up a VXLAN type of setup to extend over 100+ VLANs between controllers. BTW VRRP instances are your friend. Some of the issues I see on airheads is people over thinking networking and not going back to the basics and standards.... I blame Cisco for this (j/k but funny)