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?