How to keep APs registered to the primary controller

[Scott_Van_Arts1]

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?

[Hawkins__Bruce]

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. 

[Hawkins__Bruce]

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.

[Craig_Guilmette]

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.

[Craig_Guilmette]

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.

[AntonS]

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?