How to keep APs registered to the primary controller

  • 0
  • 1
  • Question
  • Updated 6 months ago
  • Answered
We have a couple of C2510's running as availability peers.  Periodically throughout the day the APs will "roam" over to the availability peer.  I've got "Current Wireless Controller is primary connection point" selected on the controller that I'd like to be primary.  However, the APs will still fail over to the secondary.  I have to periodically get onto the secondary and release all APs.  Is there a way to force all APs to remain registered with the primary controller?  
Photo of Scott Van Artsdalen

Scott Van Artsdalen

  • 344 Points 250 badge 2x thumb

Posted 6 months ago

  • 0
  • 1
Photo of Craig Guilmette

Craig Guilmette, Employee

  • 2,984 Points 2k badge 2x thumb
https://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Access-Points-reboot-due-to-Pol...
You need to figure out why they cant stay connected to their local controller. 
Photo of Anton Sax

Anton Sax

  • 1,294 Points 1k badge 2x thumb
Hy Graig,
in this article is a link for special wireshark version that decodes WASSP.
do you know if there is a new version for 10.31.x or 10.41.x?
Photo of Craig Guilmette

Craig Guilmette, Employee

  • 2,984 Points 2k badge 2x thumb
The latest version of wire shark engineering has added the decode into is 1.12.8 I have not had any problems with this older rev when reviewing frames. 
(Edited)
Photo of Hawkins, Bruce

Hawkins, Bruce, Employee

  • 1,312 Points 1k badge 2x thumb
Hi Scott ...

They are only "registered" with whichever controller is Local for them.  By nature ... you can only keep the APs remaining up and running on that Local controller .... if that controller never goes down ... and if you keep the connection between the APs and the Local controller congestion and delay free such that they can both bidirectionally maintain a constant flow of WASSP AP Polling "keep alive" packets between them ... and consistent power delivered to the APs at all times.

You can configure the Fast Failover timeout value and AP Polling Timeout Value to be elevated such that the APs and controller(s) will wait longer between hearing back from each other ... before forcing a failover ... but that is probably just masking some issue on the LAN side.  

I like to tell customers that their APs are "canaries in their LAN coal mine".  If you have certain APs that are repeatedly and consistently experiencing AP Polling Timeouts and failing over to the Foreign side ("I am your father Luke") ... then it's worth investigating the L1/L2/L3 path between those APs and the controller they are failing away from.  APs that can't communicate to their Primary/Local controller for longer than 20-30 seconds ... are trying to do so over a LAN that isn't performing very well in some respects at least ... in most cases.

Power can also be an issue. If an AP isn't getting consistent and "good" PoE power and some of those APs are dropping below the power level required even briefly ... it can interrupt the flow of data and packets enough that even if the AP doesn't go down fully ... it could fail over to the Foreign controller in the HA pair.  So, PoE power to the switch the APs are connected to also useful to look at.

The values we usually use in the GTAC through years of experience in thousands of customer environments are 20 seconds for Fast Failover between the controllers and 30 seconds for the AP Polling Timeout value.  If you have APs connecting over a WAN and/or VPN ... those may both need to be elevated beyond that.  The MTU out to each branch location should also be examined to make sure AP <> Controller communication isn't suffering from excessive packet fragmentation.
Photo of Hawkins, Bruce

Hawkins, Bruce, Employee

  • 1,312 Points 1k badge 2x thumb
I was going to additionally post a link to a KCS article that outlines much of what I typed above ... but Craig has beaten me to it.  :-)
Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 51,266 Points 50k badge 2x thumb
or just disable fast failover...
Hi Scott, we have similar scenario, a couple of C5210's running as availability peers. We don't understand why the APs roamed to a second controller, roaming again to the first controller as soon as possible. And we have to do it  manually later.

Thanks a lot.
Photo of Scott Van Artsdalen

Scott Van Artsdalen

  • 344 Points 250 badge 2x thumb
Thanks for the suggestions everyone.  So our controller's fast failover was set to 2 seconds and the AP polling timeout was set to 4 seconds.  That seems pretty low so I'm going to bump them up to Bruce's recommendations and see what happens.
Photo of Hawkins, Bruce

Hawkins, Bruce, Employee

  • 1,312 Points 1k badge 2x thumb
To be clear ... in a very highly performing network ... with no Spanning Tree issues, and/or multicast or broadcast congestion ... that has been well designed with proper VLAN containment and switches that are not over-subscribed etc ... 2 seconds for FF and 4 for AP Polling Timeout can absolutely work.  But in our experience, 20 seconds for FF and 30 seconds for AP Polling Timeout are values that work more consistently across a variety of customer networks ... and allow for some "slack" in all the things mentioned previously.

Let us know if 20/30 works better for you Scott!