Local APs on Second Controller

[Ian_Broadway]

Hi All,

We have 2 x c5210 controllers running 10.41.07.

We use one of them as a "Primary", all APs are local to that specific controller.

over time we see the APs terminate on the "secondary" i.e. they appear blue in the availability reports on the "primary" controller.

While there inst any real issue with this, it means we have to view both controllers for stats etc.

Only way i know to get them back is to go on the "secondary" controller and release them back to the "primary".

Is there not an automated way to do this? What would cause them to swap controllers in the first place?

thanks in advance

Ian

[Hawkins__Bruce]

You likely have your Local Area Network to thank for performing the "automatic load balancing" function. The Controllers and APs are dependent on the LAN (or potentially WAN/VPN) that interconnects them ... to deliver the Polling Timeout, Fast Failover and "keep alive packets" that are in constant flow between the two controllers in a High Availability pair and from the APs back to both controllers ... and the APs are dependent on the switches to which they connect to deliver consistent and sufficient PoE power (in most cases, unless you are using PoE injectors).

You have two values, Fast Failover and AP Polling Timeout that you can configure that controls how long the APs and controllers will wait to hear back from either a controller or an AP ... before they will function as designed ... and decide that something has either gone wrong with a controller or AP that they are not getting a reply from within those configured parameters ... or that the controller or AP simply has gone down. In the case of a HA pair... the AP will fail over to it's opposing controller as is designed.

If you have APs failing over frequently ... and you look in the logs of your controller(s) and see multiple "AP Polling Timeout" errors ... the LAN has an issue that is causing the controllers and APs to not communicate in a manner that meets the parameters of the FF Timeout and AP Polling Timeout values you have configured.

We have found through experience that a FF Timeout value of 20 seconds and an AP Polling Timeout value of 30 seconds ... seems to work well in most reasonably performing and configured LANs. The controller(s) look for a 2/3 ratio between FF and AP Timeout and this also satisfies that. If you have values that are significantly lower than that, you can adjust them to 20 and 30 and see if your issue is lessened or mitigated entirely. If you do that, and you are still experiencing AP Polling Timeout errors often ... then you should inspect the LAN/WAN/VPN side of things from end to end ... to understand better why your APs and controllers are communicating quickly and efficiently enough. Is there excessive multicast traffic that could be lessened through employing IGMPsnooping on non-AP ports? Is there excessive broadcast traffic? Do you have frequent spanning tree re-convergences occurring. Are there certain switches or uplink ports that are over-subscribed and not "keeping up" with the flow of traffic as they should? Do you have issues with PoE Power on one or more switches? When you look at the AP Polling Timeout Errors that are occurring ... is it usually the same "group" of APs .... and if so ... what commonalities are there between those APs ... same switches? Same building or location? Are they all APs coming across a WAN/VPN? If they are remotely connecting that way through a lower bandwidth link ... you may need to adjust the MTU being used for those APs.

Basically ... your APs are "canaries" in your LAN/WAN/VPN "coal mine". If they are frequently failing back and forth between controllers in a HA pair ... they are calling your attention to address the short comings of your LAN ... either in terms of design, or configuration but certainly of performance in the areas where the APs are timing out often.

Poll Timeouts can also occur if there's not enough memory allocated to the Virtual controller, but that happens less often than most of the other reasons listed above.

Here are some KCS articles that provide additional detail and one that includes instructions for how to adjust the MTU in cases where that is appropriate:

https://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Wireless-AP-s-do-not-have-backu...

https://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Access-Points-reboot-due-to-Pol...

https://gtacknowledge.extremenetworks.com/articles/Q_A/At-what-interval-do-the-Access-Points-poll-th...

https://gtacknowledge.extremenetworks.com/articles/Solution/AP-s-drop-when-connected-to-specific-swi...

https://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Wireless-AP-s-are-having-poll-t...

https://gtacknowledge.extremenetworks.com/articles/Solution/Wireless-AP3935-session-poll-disconnect-...

https://gtacknowledge.extremenetworks.com/articles/Solution/IdentiFi-Access-Points-reboot-due-to-Pol...

[Andre_Brits_Kan]

We have the same symptoms, I like to think of this as a automatic load balancer - but I would guess that this is not a load balancing function by design...... 😉