switching SSO from layer 2 to back-to-back connections.

[atifali.zaidi1]

my existing topology for Cisco 9800-40 SSO is via access switches , as per design standard we cannot connect anything on the core layer except access switches and routers so we had to connect the wlc's to the access layer.  there were issues with HA sync so we have decided to connect the controllers back to back via 1G SFP RP port as the distance between the two comms rooms exceeds 30 meters.  the access switches and core switches are Juniper and the core switches are in VSS (trying to plain and simple) . currently the standby controller has become active so in order to have HA using back to back connections, shall i simply disconnect the RP port cable from the primary unit's uplink switch first so the secondary remains active and then unplug the RP port cable from the secondary wlc switch . 

connect both the controllers back to back using fiber RP cable and then HA should form automatically ? 

please advise and refer to the existing and proposed topologies.

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213915-configure-catalyst-9800-wireless-control.html

check this 

MHM

[marce1000]

 - To avoid any confusing for the controllers and pr a split brain simply power off the current standby and then make the intended network changes

Afterwards verify the redundancy states on the controller pair.
          Added : you can also test back to back connectivity with the command 9800# test wireless redundancy rping

 M

[eglinsky2012]

Agreed, powering off current standby to perform the work is the best way.

For your information, here are the various failure behaviors of our 9800-80 WLCs with RMI running 17.9.4a with back-to-back RP and fiber uplinks port channeled across a VSS switch as tested in our lab. Reference to drops/latency are from a wireless client pinging the default gateway.

• Remove redundancy link: No interruption. Standby chassis goes to recovery state, all interfaces down. Reconnect the link and the standby reboots. No interruption. Once HA sync completed, a few latent and 1 dropped packet on WiFi client device.
• Remove single fiber uplink on active: No interruption. Some latency when reconnecting.
• Remove both fiber links on active: A couple packets dropped. Standby becomes active. Former active reboots. When back online, HA sync completes, with console message on new standby about RMI gateway not unreachable (due to fiber removed). Plugged fiber back in, RMI recovers, no interruption, no change in HA.
• Power off active chassis: A couple dropped packets, slight latency for a few. Switchover occurs smoothly.
• Reload VSS switch pair (loss of uplinks but not redundancy links): Active reboots, attempts bulk sync, then both reboot. Uplinks come back and HA is restored.

[Leo Laohoo]

If you're trying to avoid CSCwj73634, it is a useless exercise.  At the end of the day, as long as the controller is on 17.9.X (and later) or 17.12.X (and later), it will happen even if/when the Redundant Port (RP) is directly connected or connected through a LAN.  

[Rich R]

CSCwj73634 and CSCwj53599 are fixed in 17.12.3 SMU CSCwj96199 and 17.12.4 released last week.

17.12.4 release notes have been updated since I sent feedback on a number of bugs which they said were open even though they were fixed,  Now correctly under resolved caveats.  I think their own slow updating of the bug database caught out the person writing the release notes! CSCwj73634 and CSCwj53599 are not mentioned at all in the 17.12.4 release notes (even though CSCwj73634 is sev 2) but are both fixed in 17.12.4.