Last Updated on Tue, 04 Apr 2023 |Root Bridge
Modular switch platforms such as the Catalyst 4500R and 6500 can accept two supervisor modules installed in a single chassis. The first supervisor module to successfully boot up becomes the active supervisor for the chassis. The other supervisor remains in a standby role, waiting for the active supervisor to fail.
The active supervisor always is allowed to boot up and become fully initialized and operational. All switching functions are provided by the active supervisor. The standby supervisor, however, is allowed to boot up and initialize only to a certain level. When the active module fails, the standby module can proceed to initialize any remaining functions and take over the active role.
Redundant supervisor modules can be configured in several modes. The redundancy mode affects how the two supervisors handshake and synchronize information. In addition, the mode limits the standby supervisor's state of readiness. The more ready the standby module is allowed to become, the less initialization and failover time will be required.
You can use the following redundancy modes on Catalyst switches:
■ Route Processor Redundancy (RPR)—The redundant supervisor is only partially booted and initialized. When the active module fails, the standby module must reload every other module in the switch and then initialize all the supervisor functions.
■ Route Processor Redundancy Plus (RPR+)—The redundant supervisor is booted, allowing the supervisor and route engine to initialize. No Layer 2 or Layer 3 functions are started, however. When the active module fails, the standby module finishes initializing without reloading other switch modules. This allows switch ports to retain their state.
■ Stateful Switchover (SSO)—The redundant supervisor is fully booted and initialized. Both the startup and running configuration contents are synchronized between the supervisor modules. Layer 2 information is maintained on both supervisors so that hardware switching can continue during a failover. The state of the switch interfaces is also maintained on both supervisors so that links don't flap during a failover.
TIP Sometimes the redundancy mode terminology can be confusing. In addition to the RPR, RPR+, and SSO terms, you might see Single Router Mode (SRM) and Dual Router Mode (DRM).
SRM simply means that two route processors (integrated into the supervisors) are being used, but only one of them is active at any time. In DRM, two route processors are active at all times. HSRP usually is used to provide redundancy in DRM.
Although RPR and RPR+ have only one active supervisor, the route processor portion is not initialized on the standby unit. Therefore, SRM is not compatible with RPR or RPR+.
SRM is inherent with SSO, which brings up the standby route processor. You usually will find the two redundancy terms together, as "SRM with SSO."
Configuring the Redundancy Mode
Table 13-5 details the redundancy modes you can configure on supported switch platforms.
Table 13-5 Redundancy Modes, Platform Support, and Failover Time
Table 13-5 Redundancy Modes, Platform Support, and Failover Time
Redundancy Mode | Supported Platforms | Failover Time |
RPR | Catalyst 6500 Supervisors 2 and 720, Catalyst 4500R Supervisors IV and V | Good (> 2 minutes) |
Route Processor Redundancy Plus (RPR+) | Catalyst 6500 Supervisors 2 and 720 | Better (> 30 seconds) |
Stateful Switchover (SSO) | Catalyst 6500 Supervisor 720, Catalyst 4500R Supervisors IV and V | Best (> 1 second) |
Figure 13-5 shows how the supervisor redundancy modes compare with respect to the functions they perform. The shaded functions are performed as the standby supervisor initializes and then waits for the active supervisor to fail. When a failure is detected, the remaining functions must be performed in sequence before the standby supervisor can become fully active. Notice how the redundancy modes get progressively more initialized and ready to become active.
Figure 13-5 Standby Supervisor Readiness as a Function of Redundancy Mode
Figure 13-5 Standby Supervisor Readiness as a Function of Redundancy Mode
Standby Initializes | ||||||||
Supervisor Bootstrap Image Loaded | Supervisor Bootstrap Image Loaded | Supervisor Bootstrap Image Loaded | ||||||
IOS Image Loaded | IOS Image Loaded | IOS Image Loaded | ||||||
Sync Startup-Config | Sync Startup-Config | Sync Startup-Config | ||||||
Supervisor Diagnostics | Supervisor Diagnostics | Supervisor Diagnostics | ||||||
1 | ||||||||
SBP Active Fails | All Switch Modules Reloaded | \ | ||||||
Route Engine Initialized | \ | Route Engine Initialized | Route Engine Initialized | |||||
Layer 2 Protocols Initialized j | Layer 2 Protocols Initialized j | \ | Layer 2 Protocols Initialized | |||||
\ | FIB Table Synchronized | |||||||
Layer 3 Protocols Initialized | Layer 3 Protocols Initialized | Layer 3 Protocols Initialized | NSF (Optional Optimization) | |||||
Routing Protocols Converge | Routing Protocols Converge | Routing Protocols Converge | ||||||
FIB Table Flushed and Re-Created | FIB Table Flushed and Re-Created | FIB Table Updated | ||||||
RPR | RPR + | SSO |
You can configure the supervisor redundancy mode by entering the redundancy-configuration mode with the following command:
Router(config)# redundancy
Next, select the redundancy mode with one of the following commands:
Router(config-red)# mode {rpr | rpr-plus | sso} If you are configuring redundancy for the first time on the switch, you must enter the previous commands on both supervisor modules. When the redundancy mode is enabled, you will make all configuration changes on the active supervisor only. The running configuration is synchronized automatically from the active to the standby module.
TIP If you configure RPR+ with the rpr-plus keyword, the supervisor attempts to bring up RPR+ with its peer module. The IOS images must be of exactly the same release before RPR+ will work. If the images differ, the supervisor automatically falls back to RPR mode instead.
You can verify the redundancy mode and state of the supervisor modules by using the following command:
Router# show redundancy states The output in Example 13-10 shows that the switch is using RPR+ and that the second supervisor module (denoted by unit ID 2 and "my state") holds the active role. The other supervisor module is in the standby state and is "HOT," meaning that it has initialized as far as the redundancy mode will allow.
Example 13-10 Verifying Supervisor Module Redundancy Mode and State
Router# show redundancy states | |||
my state | = 13 -ACTIVE | ||
peer state | = 8 -STANDBY HOT | ||
Mode | = Duplex | ||
Unit | = Secondary | ||
Unit ID | = 2 | ||
Redundancy Mode | (Operational) = Route Processor | Redundancy | Plus |
Redundancy Mode | (Configured) = Route Processor | Redundancy | Plus |
Split Mode | = Disabled | ||
Manual Swact | = Enabled | ||
Communications | = Up | ||
client count | = 11 | ||
client_notification_TMR = 30000 milliseconds | |||
keep_alive TMR = 9000 milliseconds | |||
keep_alive count = 1 | |||
keep_alive threshold = 18 | |||
RF debug mask = 0x0 | |||
Router# |
Configuring Supervisor Synchronization
By default, the active supervisor synchronizes its startup configuration and configuration register values with the standby supervisor. You also can specify other information that should be synchronized.
First, use the following commands to enter the main-cpu configuration mode:
Router(config)# redundancy Router(config-red)# main-cpu
Then use the following command to specify the information that will be synchronized:
Router(config-r-mc)# auto-sync {startup-config I config-register I bootvar}
You can repeat the command if you need to use more than one of the keywords. To return to the default, use the auto-sync standard command.
Non-Stop Forwarding
You can enable another redundancy feature along with SSO on the Catalyst 4500R and 6500 (Supervisor 720 only). Non-Stop Forwarding (NSF) is an interactive method that focuses on quickly rebuilding the routing information base (RIB) table after a supervisor switchover. The RIB is used to generate the FIB table for CEF, which is downloaded to any switch modules or hardware that can perform CEF.
Instead of waiting on any configured Layer 3 routing protocols to converge and rebuild the FIB, a router can use NSF to get assistance from other NSF-aware neighbors. The neighbors then can provide routing information to the standby supervisor, allowing the routing tables to be assembled quickly. In a nutshell, the Cisco-proprietary NSF functions must be built into the routing protocols on both the router that will need assistance and the router that will provide assistance.
NSF is supported by the BGP, EIGRP, OSPF, and IS-IS routing protocols. NSF is available on the Catalyst 6500 Supervisor 720 (with the integrated MSFC3) and on the Catalyst 4500R Supervisor III, IV, and V running IOS Software Release 12.2(20)EWA or later.
To configure NSF, you must add the commands in Table 13-6 to any routing protocol configuration on the switch.
Table 13-6 Configuring NSF (by Routing Protocol)
Table 13-6 Configuring NSF (by Routing Protocol)
Routing Protocol | Configuration Commands |
BGP | Router(config)# router bgp as-number Router(config-router)# bgp graceful-restart |
EIGRP | Router(config)# router eigrp as-number Router(config-router)# nsf |
OSPF | Router(config)# router ospf process-id Router(config-router)# nsf |
IS-IS | Router(config)# router isis [tag] Router(config-router)# nsf [cisco 1 ietf] Router(config-router)# nsf interval [minutes] Router(config-router)# nsf t3 {manual [seconds] 1 adjacency} Router(config-router)# nsf interface wait seconds |
Continue reading here: Redundant Power Supplies
Was this article helpful?