Cisco high-end switches or routers (4500, 6500, 7600, etc) allow a redundant Supervisor Engine to take over if the primary Supervisor Engine fails in order to support fault resistance. Redundant Supervisor Engines must be of the same type with the same model feature card to support redundancy. When you install two Supervisor Engines, the first one to come online becomes the active module. The second Supervisor Engine goes into standby mode. All administrative and network management functions, such as SNMP, CLI console, Telnet, STP, CDP, and VTP, etc. are processed on the active Supervisor Engine. On the standby Supervisor Engine, the console port is inactive. Redundant Supervisor Engines are hot-swappable. The system continues to operate with the same configuration after it switches over to the redundant Supervisor Engine.
Redundancy is always enabled and cannot be disabled. Redundancy is enabled anytime the switch has two Supervisor Engines installed on it and the switch decides which specific redundancy mode to use in accordance with the type of images it has but if you have support for all redundancy mode then you can choose according to your need.
There are below redundancy modes available:
1. Route Processor Redundancy(RPR)
3. Stateful Switchover(SSO)
The basic differences between the modes are failover timing, it is 30 seconds or longer in RPR mode, depending on the configuration; sub seconds in the SSO mode.
When a redundant supervisor engine runs in RPR mode, it starts up in a partially-initialized state and is synchronized with the persistent configuration (Persistent configuration includes the following components: startup-config, boot variables, config-register, and VLAN database) of the active supervisor engine.
The redundant supervisor engine pauses the startup sequence after basic system initialization, and in the event that the active supervisor engine fails, the redundant supervisor engine becomes the new active supervisor engine.
In a supervisor engine switchover, traffic is disrupted because in the RPR mode all of the physical ports restart since there is no state maintained between supervisor engines relating to module types and statuses. When the redundant supervisor engine completes its initialization, it will read hardware information directly from the module.
RPR supports the following features:
• Auto-startup and bootvar synchronization between active and redundant supervisor engines
• Hardware signals that detect and decide the active or redundant status of supervisor engines
• Clock synchronization every 60 seconds from the active to the redundant supervisor engine
• A redundant supervisor engine that is booted but not all subsystems are up: if the active supervisor engine fails, the redundant supervisor engine become fully operational
• An operational supervisor engine present in place of the failed unit becomes the redundant supervisor engine
• Support for fast software upgrade (FSU)
When the switch is powered on, RPR runs between the two supervisor engines. The supervisor engine that boots first becomes the RPR active supervisor engine. The Multilayer Switch Feature Card and Policy Feature Card become fully operational. The MSFC and PFC on the redundant supervisor engine come out of reset but are not operational.
In a switchover, the redundant supervisor engine becomes fully operational and the following occurs:
• All switching modules power up again
• Remaining subsystems on the MSFC (including Layer 2 and Layer 3 protocols) are brought up
• Access control lists (ACLs) are reprogrammed into supervisor engine hardware
When RPR+ mode is used, the redundant supervisor engine is fully initialized and configured, which shortens the switchover time. The active supervisor engine checks the image version of the redundant supervisor engine when the redundant supervisor engine comes online. If the image on the redundant supervisor engine does not match the image on the active supervisor engine, RPR redundancy mode is used.
With RPR+, the redundant supervisor engine is fully initialized and configured, which shortens the switchover time if the active supervisor engine fails or if a manual switchover is performed.
When the switch is powered on, RPR+ runs between the two supervisor engines. The supervisor engine that boots first becomes the active supervisor engine. The Multilayer Switch Feature Card and Policy Feature Card become fully operational. The MSFC and PFC on the redundant supervisor engine come out of reset but are not operational.
RPR+ enhances RPR by providing the following additional benefits:
• Reduced switchover time
Depending on the configuration, the switchover time is 30 or more seconds.
• Installed modules are not reloaded
Because both the startup configuration and the running configuration are continually synchronized from the active to the redundant supervisor engine, installed modules are not reloaded during a switchover.
• Online insertion and removal (OIR) of the redundant supervisor engine
RPR+ allows OIR of the redundant supervisor engine for maintenance. When the redundant supervisor engine is inserted, the active supervisor engine detects its presence and begins to transition the redundant supervisor engine to a fully initialized state.
• Synchronization of OIR events
• Manual user-initiated switchover using the redundancy force-switchover command
SSO is supported in Cisco IOS Release 12.2(20)EWA and later releases. When a redundant supervisor engine runs in SSO mode, the redundant supervisor engine starts up in a fully-initialized state and synchronizes with the persistent configuration and the running configuration of the active supervisor engine. It subsequently maintains the state on the protocols listed below, and all changes in hardware and software states for features that support stateful switchover are kept in sync. Consequently, it offers zero interruption to Layer 2 sessions in a redundant supervisor engine configuration.
Because the redundant supervisor engine recognizes the hardware link status of every link, ports that were active before the switchover will remain active, including the uplink ports. However, because uplink ports are physically on the supervisor engine, they will be disconnected if the supervisor engine is removed.
If the active supervisor engine fails, the redundant supervisor engine becomes active. This newly active supervisor engine uses existing Layer 2 switching information to continue forwarding traffic. Layer 3 forwarding will be delayed until the routing tables have been repopulated in the newly active supervisor engine.
SSO supports stateful switchover of the following Layer 2 features. The state of these features is preserved between both the active and redundant supervisor engines:
• 802.3x (Flow Control)
• 802.3ab (GE)
• 802.3z (Gigabit Ethernet including CWDM)
• 802.3ad (LACP)
• 802.1p (Layer 2 QoS)
• 802.1X (Authentication)
• 802.1D (Spanning Tree Protocol)
• 802.3af (Inline power)
• Dynamic ARP Inspection
• DHCP snooping
• IP source guard
• IGMP snooping (versions 1 and 2)
• DTP (802.1q and ISL)
• BPDU guard and filtering
• Voice VLAN
• Port security
• Unicast MAC filtering
• ACL (VACLS, PACLS, RACLS)
• QOS (DBL)
• Multicast storm control/broadcast storm control
SSO is compatible with the following list of features. However, the protocol database for these features is not synchronized between the redundant and active supervisor engines:
• 802.1Q tunneling with Layer 2 Protocol Tunneling (L2PT)
• Baby giants
• Jumbo frame support
• Flood blocking
The following features are learned on the redundant supervisor engine if the SSO feature is enabled:
• All Layer 3 protocols on Cisco switches (Switch Virtual Interfaces)
The module status of the standby Supervisor Engine in the “show module” command output is different for the different redundancy modes:
RPR—Status shows Cold.
Cold redundancy refers to the degree of resiliency that a redundant system traditionally provides. A redundant system is cold when no state information is maintained between the backup or standby system and the system it protects.
RPR+—Status shows Warm.
Warm redundancy refers to a degree of resiliency beyond the cold standby system. In this case, the redundant system is partially prepared. However, the system does not have all the state information that the primary system knows for an immediate take-over. Some additional information must be determined or gleaned from the traffic flow or the peer network devices to handle packet forwarding.
SSO—Status shows Hot.
Hot redundancy refers to a degree of resiliency where the redundant system is fully prepared to handle the traffic of the primary system. Substantial state information is saved, so the network service is continuous, and the effect on traffic flow is minimal or nil in the case of a failover.
dir disk0: and slavedisk0: or similar command dir sup-bootdisk: and slavesup-bootdisk:
copy tftp disk0: and slavedisk0: or similar command copy tftp sup-bootdisk: and slavesup-bootdisk:
hw-module module reset
Sources of the document:
I hope this helps you guys. If you like it then do not forget to hit the like button and share it with your friends and family.
All the best guys.