Weird Availability Behaviour

[Ian_Broadway]

Here is my scenario, 2 x C5210 Controllers, both Physical appliances. Running the latest code 10.11.01.0210. Availability configured using Esa2 Ports on each controller, 10Gb SFP+ modules. Plug directly into their respective core switches in their respective DCs. fast failover is set to 2 seconds, with AP poll time set to 3 seconds (1.5 times as recommended in the documentation) system config and captive portal info is checked for sync. Same subnet, 172.25.7.0/28, controller 1 is 172.25.7.1, controller 2 is 172.25.7.2. GW is 172.25.7.14. These are the IPs used in the option 78 DHCP options. Topology is configured to allow ap registration to these addresses. We do use the "admin" ports on the controllers, but solely for web access. The AP discovery works perfectly, the APs appear on both controllers. Currently one is set to allow any APs to connect, the other is only allowed approved APs to connect. this way we can configure the APs on one controller. This seems to work ok, all APs become local automatically to the "allow all" controller and foreign to the "only approved" controller Our ideal solution is to split the APs between each controller at some point. we did actually start doing this. this is where we found an issue. With only one controller serving all APs at first, you can configure the AP, change name, location etc. and this then propagates the change to the other controller, the name, location etc is sync'd as we would expect. you can also delete an ap and it will disappear form the other. This is correct in that controller 2 is the "allow all" controller and controller 1 is the "only approved" controller. so changes made to the APs on controller 2, the info is sync;d to controller 1. If we reverse this process, it does not work. AP discovery for example, controller 1 has the local APs but on controller 2, the info is not updated, if you make a change to the name, it does not sync the other way, when you try to delete the AP it wont delete off the other controller! we get issues with AP authorisation failures and sometime we get the CM component complain about not being able to process a request. "Config Manager has experienced an error which has prevented it from properly processing a request. CM will continue running, however this error may be an indicator of a larger system problem. Error Details:[ERR ] Can't connect to remote controller at 172.25.7.2" This must be a process issue. the devices are part of the same broadcast domain (VLAN). They can ping eachother, ping the gateway, ping the APs. Its also fully routable, this is proven with the AP discovery in that the APs belong to different VLANs and can obviously route, proven with the discovery working. right now we're having to doctor the way it works if you like but this seems like controller 1 has issue talking to controller 2, yet the other way around is fine! I hope you can understand this scenario, please ask any questions if something is confusing. I do have some further questions aswell, like do i need mobility enabled with this setup for roaming?

[JK]

Looks like this has been seen before.
https://gtacknowledge.extremenetworks.com/articles/Solution/Wireless-Appliances-form-an-Availability...

[Ian_Broadway]

So after a few days of head scratching and investigation, the issue turned out to be "jumbo frames support" was enabled on the controllers yet the physical ports linking the controllers together through the network did not all have jumbo frames enabled. This caused management traffic issues. We didn't have a requirement to use Jumbo frames and it was recommended that this be disabled. All good now.

[Ian_Broadway]

Hmm still no joy. Was looking good when I made the changes and then deleting the AP from local controller removed it also from the foreign one. However when adding it back, the info of the AP does not sync to the other controller . I will raise the issue with my partner and subsequently GTAC.

[Ian_Broadway]

Hi Gareth, I will try this then first, see if the behaviour changes.