Information About Redundancy Management Interface
The Redundancy Management Interface (RMI) is used as a secondary link between the active and standby Cisco Catalyst 9800 Series Wireless Controllers. This interface is the same as the wireless management interface, and the IP address on this interface is configured in the same subnet as the Wireless Management Interface. The RMI is used for the following purposes:
-
Dual Active Detection
-
Exchange resource health between controllers, for instance, gateway reachability status from either controller.
-
Gateway Reachability detection: Gateway reachability is checked on the active and the standby controller through the RMI interface when the feature is enabled. It takes approximately 8 seconds to detect that a controller has lost gateway reachability.
Note |
The RMI might trigger a switchover based on the gateway status on the controllers. |
Active Controller
The primary address on the active controller is the management IP. The secondary IPv4 address on the management VLAN is the RMI IP for the active controller. Do not configure the secondary IPv4 addresses explicitly because a single secondary IPv4 address is configured automatically by RMI under the RMI interface.
Note |
RMI supports only IPv4 addresses. |
Standby Controller
The standby controller does not have the wireless management IP configured; it has the RMI IP address configured as the primary IP address. When the standby controller becomes active, the management IP becomes the primary IP and the RMI IP becomes the secondary IP. If the interface on the active controller is administratively down, the same state is reflected on standby controller.
Dual Stack Support on Management VLAN with RMI
Dual stack refers to the fact that the wireless management interface can be configured with IPv4 and IPv6 addresses. If RMI IPv4 address is configured along with an IPv4 management IP, you can additionally configure an IPv6 management address on the wireless management interface. This IPv6 management IP will not be visible on the standby controller.
Note |
The RMI feature supports only RMI IPv4 addresses. |
RMI-Based High-Availability Pairing
You should consider the following scenarios for High-Availability (HA) pairing:
-
Fresh Installation
-
Already Paired Controllers
-
Upgrade Scenario
-
Downgrade Scenario
Dynamic HA pairing requires both active controller and the standby controller to reload. However, dynamic HA pairing occurs on Cisco Catalyst 9800-40 Wireless Controller and Cisco Catalyst 9800-80 Wireless Controller when one of them reloads and becomes standby.
HA Pairing Without Previous Configuration
When HA pairing is done for the first time, no ROMMON variables are found for the RP IPs. You can choose from the existing privileged EXEC-mode RP-based CLIs or the RMI IP based mechanisms. However, the exec-mode RP-based CLIs will be deprecated soon. If you use the Cisco DNA Centre, you can choose the exec-mode RP-based CLI mechanism till the Cisco DNA Centre migrates to support the RMI method.
The RP IPs are derived from the RMI IPs after an HA pair is formed. Also, the privileged EXEC-mode RP-based CLI method of clearing and forming an HA pair is not allowed.
Note |
Though you can choose RP or RMI for a fresh installation, we recommended that you use RMI install method. |
Note |
To view the ROMMON variables, use the following command: show romvars |
If you choose the exec-mode RP-based CLI mechanism, the RP IPs will be configured similar to the 16.12 release.
The following occurs when the RMI configuration is done:
-
The RP IPs derived from the RMI IPs are overwritten, and used for HA pairing.
-
If the active and standby already exists due to prior HA pairing through the exec-mode RP-based CLI mechanism, the pair will not be interrupted.
-
Whenever the pair reloads later, the new RP IPs are used.
-
Exec-mode RP-based CLIs are blocked.
Already Paired Controllers
If the controllers are already in an HA pair, the existing exec-mode RP-based CLIs will continue to be used. You can enable RMI to migrate to the RMI based HA pairing.
If the controllers are already paired and RMI is configured, it will overwrite the RP IPs with the RMI derived IPs. The HA pair will not be disturbed immediately but the controllers will pick up the new IP when the next reload happens. RMI feature mandates a reload for the feature to be effective. When both controllers reload, they would come up as a pair with the new RMI derived RP IPs.
Upgrading from Cisco IOS XE 16.1.x to a Later Release
A system that is being upgraded can choose to:
-
Migrate with the existing RP IP configuration intact—In this case, the existing RP IP configuration will continue to be used. The exec-mode RP-based CLIs are used for future modifications.
-
Migrate after clearing the HA configuration—In this case, you can choose between the old (exec-mode RP-based CLIs) and new RMI based RP configuration methods.
Note |
In case the older configuration is retained, the RMI configuration updates the RP IPs with the IPs derived from the RMI IPs. |
Downgrade Scenario
The downgrade scenario will have only the exec-mode RP-based CLIs. The following are the two possibilities:
-
If the upgraded system used the RMI based RP configuration.
-
If the upgraded system continued to use the exec-mode RP-based CLIs.
Note |
In the above cases, the downgraded system uses the exec-mode RP-based CLIs to modify the configuration. However, the downgraded system will continue to use the new derived RP IPs. |