difference between RP + RMI and RP (Cisco 9800-40)

[atifali.zaidi1]

am i correct in my understanding that RP mode in Cisco 9800 in IOS 17.x is connecting the 9800's back to back via RP port and RP + RMI is connecting the RP port to the core switches running in VSS or HSRP ?  RP + RMI checks the gateway failover and dual-active detection as compared to RP port which is a single point of contact .

also if you have non-Cisco LAN (for example Juniper) in your network is it recommended to connect the 9800's back to back via RP port ?

the problem that i have is my 9800 controllers are connected to Juniper access switches as we cannot connect them to core switches which are also Juniper ( as per standards ). initially we connected the RP ports to the access switches only but the configuration for HA was done using "RP" instead of "RP + RMI".  so there are issues with failover somehow.

shall i clear the redundancy based configuration, and then connect the RP ports back to back and just use the option for "RP" to setup HA ?

[atifali.zaidi1]

i am running 17.3.6 on the controllers

[MHM Cisco World]

According to cisco after 17.1 you need back to back connect of RP.

The HA have two config mode

RP 

Or

RP + RMI

You can config any mode there is no difference except with RMI the WLC always ping GW if failed the failover is done between two wlc ha unit

MHM

[Rich R]

1. Upgrade to a currently recommended version of code as per the TAC recommended link below.  17.3 is already past End of Software Maintenance and End of Vulnerability/Security Support so 17.3.x is effectively End of Life.
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xe-17/ios-xe-17-3-x-eol.html
There are also multiple improvements to redundancy in later releases.

2. The RP ports should always be connected back to back if possible.  You can use switched connections if you absolutely have to (due to distance between WLCs) but it must meet all the essential requirements.

3. RMI adds an extra level of redundancy in addition to the RP ports and is always on the same subnet as the WLC AP management interface.

So you can use RP+RMI with the RP ports connected directly.

Read the documentation carefully to understand the supported options:
https://www.ciscolive.com/on-demand/on-demand-library.html?search=brkewn-2846&search=brkewn-2846#/session/1701824097599001nxrk
https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/220277-configure-high-availability-sso-on-catal.html
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-9/config-guide/b_wl_17_9_cg/m_vewlc_high_availability.html
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/technical-reference/c9800-best-practices.html#Highavailability

[marce1000]

  >...am i correct in my understanding that RP mode in Cisco 9800 in IOS 17.x is connecting the 9800's back to back via RP port and RP + RMI is connecting the RP port to the core switches running in VSS or HSRP ?
   No RP is always connected back to back in what ever scenario (on it's own or with RMI) , RP using it's own dedicated vlan  in whatever architecture.

  >...also if you have non-Cisco LAN (for example Juniper) in your network is it recommended to connect the 9800's back to back via RP port ?
    In essence the brand of the underlying network should not matter , at all. You always have back to back as far as the RP
   part is concerned ; You can test reachability of the partner's (standby) RP-interface with the command :
                                       9800 #  test wireless redundancy rping

  >...the problem that i have is my 9800 controllers are connected to Juniper access switches as we cannot connect them to core switches which are also Juniper ( as per standards ).
      Should be no problem

   >..shall i clear the redundancy based configuration, and then connect the RP ports back to back and just use the option for "RP" to setup HA ?
    You could indeed start with RP only and leave the RMI scenario out.
    However, when RP only is chosen, the reachability of the gateway is not checked, only the redundant WLC state is
    

        Always when configuring stages on the primary controller use the command show tech wireless and feed the
        output into Wireless Config Analyzer  
       look for errors , (if found) (do not use simple show tech as input for Wireless Config Analyzer)
                     Actually consider the above procedure 'always mandatory'

   Appendix : a number of useful commands to check redundancy scenarios

show redundancy | i ptime|Location|Current Software state|Switchovers
show chassis
show chassis detail
show chassis ha-status local
show chassis ha-status active
show chassis ha-status standby
show chassis rmi
show redundancy
show redundancy history
show redundancy switchover history
show tech wireless redundancy
show redundancy states
show logging process stack_mgr internal to-file bootflash:

show platform hardware slot R0 ha_port interface stats
show interface `redundant interface` (check second line of output concerning Shadow  state)
show platform hardware slot R0 ha_port sfp idprom (show details of SFP in SP)
test wireless redundancy rping


 

[atifali.zaidi1]

thanks for the valuable output so if i were to connect the controllers back to back then i will have to first disable redundancy ...reboot both the controllers and then change the IP on the standby .  unplug the RP cable from the switches  and plug it back to back and then setup HA again ?  or if can simply change the option from "RP"  to "RP+RMI" and then connect the cables back to back between the controllers ?

[marce1000]

   >... or if can simply change the option from "RP"  to "RP+RMI" and then connect the cables back to back between the controllers ?
  If you go to RP+RMI you must also make sure the the RMI setup is completed on both controllers too.
  Back to back only applies for connecting the RP(s). RMI on both is kind of a virtual address to be able to detect gateway down.

  Remember to always use this procedure when configuring controllers (afterwards) and or before production (if applicable) :
                Use the command show tech wireless and feed the
               output into Wireless Config Analyzer  
       look for errors , (if found) (do not use simple show tech as input for Wireless Config Analyzer)
 

 M.