1. Ch. 9 High Availability
CIS 187 Multilayer Switched Networks CCNP version 7 Rick Graziani Spring 2016

2. Chapter 9 High Availability
The Need for Logical Switching Architectures 394
What Is StackWise? 395
StackWise Benefits 396
Verifying StackWise 396
What Is VSS? 397
VSS Benefits 398
Verifying VSS 399
Redundant Switch Supervisors 401
Supervisor Redundancy Modes 402
Stateful Switchover 403
Nonstop Forwarding 404

3. The Need for Logical Switching Architectures
What Is StackWise? 395
StackWise Benefits 396
Verifying StackWise 396
What Is VSS? 397
VSS Benefits 398
Verifying VSS 399
Redundant Switch Supervisors 401
Supervisor Redundancy Modes 402
Stateful Switchover 403
Nonstop Forwarding 404
The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation.
In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions.
Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms.
Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN.
Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+.
Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP.
Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

4. High Availability Components
Network resiliency
Built with device and link redundancy.
System-level resiliency
Redundant components (power supplies, fans, supervisor engines)
Duplicate devices available to replace failed components.
Network monitoring
Can provide instant notification of network failure.

5. Network Resiliency Built with device and link redundancy.
Employs fast convergence.
Relies on monitoring with NTP, SNMP, Syslog, and IP SLA.
Network-level resiliency is built with device and link redundancy. Device redundancy refers to having backup or redundant devices in the network to provide switching or routing or services functionality. Link redundancy refers to having multiple or duplicate links between any two devices. When possible and needed, duplicate links are installed between devices. If one physical link fails, the redundant one can hold the load while you replace the first one. These redundant links can be set in a standby mode, where one link is active and the other one is blocked by the spanning tree, or in a load-balancing mode, with EtherChannel. Also, if the links are Layer 3 instead, load balancing is possible.
Another element of high availability at network level is fast convergence. When a link fails, the redundant link or path should take precedence immediately to avoid situations in which frames or packets are dropped due to slow convergence time. In this perspective, Rapid Spanning Tree Protocol (RSTP) is preferred over 802.1D STP. With the same logic in mind, fast convergence should apply to Layer 3 connections. Wherever possible, efficient routing protocols, such as OSPF or EIGRP, would be preferred to slower routing protocols such as RIP to increase convergence speed.
Monitoring the various network elements involves several components. The first one is to synchronize time between interconnecting devices and the monitoring station. Knowing precisely when an event occurs is fundamental to managing failures and recoveries. The second element is to track events related to devices status. This can be done using Syslog and SNMP. SNMP cannot monitor some elements. For example, your link to the next hop may be up, but a failure in the network renders your gateway unreachable. This event might be undetected by the local device-monitoring configuration. To circumvent this kind of issue, IP SLA is a protocol dedicated to testing connectivity between devices. It is an important addition to monitor the network with increased accuracy.

6. Network Resiliency: Failover Times
The overall failover time is the combination of convergence at Layer 2, Layer 3, and Layer 4 components.
The overall failover time in the data center is the combination of convergence at Layer 2, Layer 3, and Layer 4 components. Figure 5-3 shows failover times of high-availability protocols.
The network components have different recovery times:
Tuned routing protocols can failover in less than 1 second. Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP) can both achieve subsecond convergence time with recommended timer configurations.
RSTP converges in about 1 second. RSTP permits subsecond convergence time for minor failures when logical ports are under watermarks and can take 1 second to 2 seconds for major failure conditions.
EtherChannel can failover in approximately 1 second. When a link fails, Cisco EtherChannel technology redirects traffic from the failed link to the remaining links in less than 1 second.
Default HSRP timers are 3 seconds for the hello time and 10 seconds for the hold time. A recommended practice is to configure the timers with a hello time of 1 second and a hold time of 3 seconds so that convergence occurs in less than 3 seconds.
Stateful service modules typically failover within 3 to 5 seconds. The convergence time for Cisco Catalyst 6500 Series Firewall Services Module (FWSM) is approximately 5 seconds with recommended timers, and the Caching Services Module (CSM) is approximately 5 seconds with recommended timers. Cisco Application Control Engine (ACE) can achieve failovers in approximately 1 second with its active/active configuration.
The least tolerant TCP/IP stacks are the Windows Server and Windows XP client stacks, which have approximately a 9-second tolerance. Each of the TCP/IP stacks built into the various operating systems have a different level of tolerance for determining when a TCP session will drop. Other TCP/IP stacks such as those found in Linux, Hewlett-Packard (HP), and IBM systems are more tolerant and have a longer window before tearing down a TCP session.

7. Network Resiliency: Failover Times
Network components have different recovery times:
Tuned routing protocols failover in less than 1 second.
RSTP converges in about 1 second.
EtherChannel can failover in approximately 1 second.
HSRP timers are 3 seconds for hello and 10 seconds for hold time.
TCP/IP stacks in Windows Server and clients have up to a 9-second tolerance.
The overall failover time in the data center is the combination of convergence at Layer 2, Layer 3, and Layer 4 components. Figure 5-3 shows failover times of high-availability protocols.
The network components have different recovery times:
Tuned routing protocols can failover in less than 1 second. Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP) can both achieve subsecond convergence time with recommended timer configurations.
RSTP converges in about 1 second. RSTP permits subsecond convergence time for minor failures when logical ports are under watermarks and can take 1 second to 2 seconds for major failure conditions.
EtherChannel can failover in approximately 1 second. When a link fails, Cisco EtherChannel technology redirects traffic from the failed link to the remaining links in less than 1 second.
Default HSRP timers are 3 seconds for the hello time and 10 seconds for the hold time. A recommended practice is to configure the timers with a hello time of 1 second and a hold time of 3 seconds so that convergence occurs in less than 3 seconds.
Stateful service modules typically failover within 3 to 5 seconds. The convergence time for Cisco Catalyst 6500 Series Firewall Services Module (FWSM) is approximately 5 seconds with recommended timers, and the Caching Services Module (CSM) is approximately 5 seconds with recommended timers. Cisco Application Control Engine (ACE) can achieve failovers in approximately 1 second with its active/active configuration.
The least tolerant TCP/IP stacks are the Windows Server and Windows XP client stacks, which have approximately a 9-second tolerance. Each of the TCP/IP stacks built into the various operating systems have a different level of tolerance for determining when a TCP session will drop. Other TCP/IP stacks such as those found in Linux, Hewlett-Packard (HP), and IBM systems are more tolerant and have a longer window before tearing down a TCP session.

8. Network Resiliency: Optimal Redundancy
Optimal redundancy is important for high availability.
Avoid:
Too much redundancy!
Single point of failure.
If applicable, use:
Cisco Nonstop Forwarding (NSF)
Stateful Switchover (SSO).
Providing optimal redundancy is important to ensure high availability. The key is not to provide too much redundancy resulting in an overly complicated or expensive to build and maintain network nor too little to compromise the required high availability.
As a recommended practice, the core and distribution layers are built with redundant switches and fully meshed links that provide maximum redundancy and optimal convergence. Access switches should have redundant connections to redundant distribution switches. The network bandwidth and capacity is engineered to withstand a switch or link failure, usually recovering within 120 ms to 200 ms. OSPF and EIGRP timer manipulation quickly attempts to redirect the flow of traffic away from a router that has experienced a failure toward an alternate path.
In a fully redundant topology with tuned IGP timers, adding redundant supervisors with Cisco NSF and SSO might cause longer convergence times than single supervisors with tuned IGP timers. NSF attempts to maintain the flow of traffic through a router that has experienced a failure. NSF with SSO is designed to maintain the link up with neighbors while preserving the routing capabilities during a routing convergence event.
In nonredundant topologies, using Cisco NSF with SSO and redundant supervisors can provide significant resiliency improvements.

9. Network Resiliency: Provide Alternate Paths
Use redundant distribution-to-core links in case a core switch fails.
Configure Distribution switches to support summarization of routing information to the core.
Although dual distribution switches connected individually to separate core switches will reduce peer relationships and port counts in the core layer, this design does not provide sufficient redundancy. If a link or core switch failure occurs, traffic is dropped.
An additional link providing an alternative path to a second core switch from each distribution switch offers redundancy to support a single link or node failure. A link between the two distribution switches is needed to support summarization of routing information from the distribution layer to the core.

10. Network Resiliency: Too Much Redundancy
What are the implications of STP and RSTP convergence?
The network convergence is definitely not deterministic.
What links should be in a blocking state?
It is hard to determine how many ports will be in a blocking state.
Where should the root switch be placed?
With this design, it is not easy to determine where the root switch is located.
When something goes wrong, how do you find the source of the problem?
The design is much harder to troubleshoot.
A third switch is added to the distribution switches in the center. This extra switch adds unneeded complexity to the design.

11. Need for Logical Switching Architectures
To satisfy the redundancy requirements, every access switch needs its own uplink to the distribution switches, but one of the uplinks will be blocked by STP to prevent a loop, thus cutting the bandwidth in half.
To overcome some of these limitations, Cisco proposes the following virtualization solutions.
StackWise: Focused on the access layer module
VSS: Focused on the aggregation layer module
Hosts connected to ASW1 can only communicate with hosts in the same VLAN connected to ASW2 via one of the distribution switches.
Consider a topology where two (could be more) access layer switches and each one has redundant connections to distribution layer switches.
Every switch demands its own configuration and management, even though you can clearly identify only two different roles: access and distribution.
The Layer 2 switches are commonly mounted in the same rack in a wiring closet!
Topology introduces overhead in terms of management, resiliency, and performance.
Configuring the PVSTP will unequally utilize both uplinks, but with additional management overhead.

12. StackWise Access Switches
Cisco StackWise technology gives us a way to collectively utilize the capabilities of a stack of switches.
Configuration and routing information is shared by every switch in the stack, creating a single switching unit.
Switches can be added to and deleted from a working stack without affecting the performance
StackWise technology in the access layer supports the recommended practice of using a Layer 3 connection between the distribution switches without having to use a loopback cable or perform extra configuration.
The true stack creation provided by the Cisco Catalyst 3750 Series switches makes using stacks in the access layer much less complex than chains or stacks of other models. A stack of 3750 switches appears as one node from the network topology perspective.

13. StackWise Access Switches
The switches are united into a single logical unit, using special stack interconnect cables that create a bidirectional closed-loop path.
This bidirectional path acts as a switch fabric for all the connected switches.
The stack is managed as a single unit by a master switch, which is elected from one of the stack member switches.
Up to nine separate switches can be joined.
StackWise technology in the access layer supports the recommended practice of using a Layer 3 connection between the distribution switches without having to use a loopback cable or perform extra configuration.
The true stack creation provided by the Cisco Catalyst 3750 Series switches makes using stacks in the access layer much less complex than chains or stacks of other models. A stack of 3750 switches appears as one node from the network topology perspective.
Each stack of switches has a single IP address and is managed as a single object.

15. Verifying StackWise
Use the show switch command to verify the switch stack.
S1# show switch
Switch/Stack Mac Address:
Switch# Role Mac Address Priority H/W Version Current State
*1 Master Ready
2 Member e Ready
S1#
S1# show switch stack-ports
Switch # Port 1 Port 2
1 Ok Ok
2 Ok Ok
Each stack switch uses two ports to connect to other stack switches to form a bidirectional ring.

16.
Fast Forward to 2:54

17. What Is VSS? The Need for Logical Switching Architectures 394
What Is StackWise? 395
StackWise Benefits 396
Verifying StackWise 396
What Is VSS? 397
VSS Benefits 398
Verifying VSS 399
Redundant Switch Supervisors 401
Supervisor Redundancy Modes 402
Stateful Switchover 403
Nonstop Forwarding 404
The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation.
In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions.
Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms.
Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN.
Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+.
Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP.
Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

18. Virtual Switching System (VSS)
VSS is a network system virtualization technology that combines a pair of Catalyst 4500 or 6500 series switches into one virtual switch.
Increases the operational efficiency, boosting nonstop communications, and scaling the system bandwidth capacity.
VSS simplifies network configuration and operation by reducing the number of Layer 3 routing neighbors and by providing a loop-free Layer 2 topology.

19. VSS
VSS is made up of two Catalyst switches and a virtual switch link (VSL) between them.
VSL can use up to eight 10 Gigabit Ethernet connections bundled into an EtherChannel.
VSL carries the control plane communication and regular data traffic between the two VSS members.

20. Verifying VSS
To verify the status of VSS configuration, use the following show switch virtual commands with various parameters:
show switch virtual
show switch virtual link
show switch virtual role
show switch virtual link port-channel

22. Redundant Switch Supervisors
The Need for Logical Switching Architectures 394
What Is StackWise? 395
StackWise Benefits 396
Verifying StackWise 396
What Is VSS? 397
VSS Benefits 398
Verifying VSS 399
Redundant Switch Supervisors 401
Supervisor Redundancy Modes 402
Stateful Switchover 403
Nonstop Forwarding 404
The first STP, called the DEC STP, was invented in 1985 by Radia Perlman at the Digital Equipment Corporation.
In 1990, the IEEE published the first standard for the protocol as 802.1D based on the algorithm designed by Perlman. Subsequent versions were published in 1998 and 2004 incorporating various extensions.
Common Spanning Tree (CST) assumes one 802.1D spanning-tree instance for the entire bridged network, regardless of the number of VLANs. Because there is only one instance, the CPU and memory requirements for this version are lower than the others. However, because there is only one instance, there is only one root bridge and one tree. This means that traffic for all VLANs flows over the same path. This can lead to suboptimal traffic flows. Also the network is slow in converging after topology changes due to inherent 802.1D timing mechanisms.
Per VLAN Spanning Tree Plus (PVST+) is a Cisco enhancement of STP that provides a separate 802.1D spanning-tree instance for each VLAN configured in the network. The separate instance supports enhancement such as PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. Creating an instance for each VLAN increases the CPU and memory requirements but allows for per-VLAN root bridges. This allows the STP tree to be optimized for the traffic of each VLAN. Convergence of this version is similar to 802.1D; however, convergence is per-VLAN.
Rapid STP (RSTP), or IEEE 802.1w, is an evolution of STP that provides faster convergence of STP. This version addresses many of the convergence issues, but because it still had a single instance of STP, it did not address the suboptimal traffic flow issues. To support that faster convergence, the CPU usage and memory requirements of this version are slightly more than CST but less than Rapid PVST+.
Multiple Spanning Tree (MST) is an IEEE standard inspired from the earlier Cisco proprietary Multi-Instance Spanning Tree Protocol (MISTP) implementation. To reduce the number of required STP instances, MST maps multiple VLANs that have the same traffic flow requirements into the same spanning-tree instance. The Cisco implementation provides up to 16 instances of RSTP (802.1w) and combines many VLANs with the same physical and logical topology into a common RSTP instance. Each instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. The CPU and memory requirements of this version are less than Rapid PVST+ but more than RSTP.
Rapid PVST+ is a Cisco enhancement of RSTP that is similar to PVST+. It provides a separate instance of 802.1w per VLAN. The separate instance supports PortFast, BPDU Guard, BPDU filter, root guard, and loop guard. This version addressed both the convergence issues and the suboptimal traffic flow issues. To do this, this version has the largest CPU and memory requirements.

23. Single Point of Failure?
An edge device represents a single point of failure.
How are Catalyst 4500 and 6500 built to overcome this problem?
Using redundant:
Power supplies
Cooling Fans
Supervisor Engines

24. The “Sup”
The Supervisor Engine is the most important component in Catalyst switches.
If it fails, the switch fails to forward traffic.
Therefore providing Sup redundancy is the most critical form of high availability.
The Catalyst 4500, 6500, and 6800 families of switches support three main types of sup engines:
Supervisor 2
Supervisor 32
Supervisor 720
Two supervisor modules can be installed in a single chassis thereby removing a single point of failure.
The first supervisor module to successfully boot becomes the active supervisor for the chassis.
The other supervisor remains in a standby role, waiting for the active supervisor to fail.
When the active module fails, the standby module can proceed to initialize any remaining functions and take over the active role.

25. Catalyst 6800 Series Supervisor Engine

26. Redundancy Features on Catalyst 4500/6500
Redundant supervisor modules can be configured in several modes.
Note:
RPR and RPR+ are no longer the recommended option and SSO (with NSF) provides better convergence time.
Redundancy Mode
Behavior When Active Module Fails
Failover Time
RPR
(Route Processor Redundancy)
The standby module reloads every other module, initializes all supervisor functions.
> 2 minutes
RPR+
The standby module finishes initializing without reloading other modules.
> 30 seconds
SSO
(Stateful SwitchOver)
The standby module is already initialized.
> 1 second
NSF with SSO provides the highest level of high availability in the Catalyst 6500 and Catalyst 4500 families of switches.
This section briefly reviews the RPR and RPR+ features. The Catalyst 4500 and Catalyst 6500 families of switches support high availability by enabling a redundant Supervisor Engine to take over if the primary Supervisor Engine fails for both Layer 2 and Layer 3 functions.

27. Route Processor Redundancy (RPR)
RPR enables a quick switchover between an active and standby Route Switch Processor (RSP) if the active RSP experiences a fatal error.
First form of high availability feature in Cisco IOS Software starting with Cisco IOS Software Release 12.1(13)E.
When configured, the standby RSP loads a Cisco IOS image on bootup and initializes itself in standby mode.
In the event of a fatal error on the active RSP, the system switches to the standby RSP, which reinitializes itself as the active RSP, reloads all of the line cards, and restarts the system.
Any of the following events triggers an active to standby switchover:
A manual switchover from the CLI.
Removal of the active Supervisor Engine.
Route Processor (RP) or Switch Processor (SP) crash on the active Supervisor Engine.

28. RPR+ The RPR+ feature is an enhancement of the RPR feature.
RPR+ keeps the virtual IPs (VIPs) from being reset and reloaded when a switchover occurs between the active and standby RSPs.
Because VIPs are not reset and microcode is not reloaded on the VIPs, and the time needed to parse the configuration is eliminated, switchover time is reduced to 30 seconds.

29. RPR+ Additional Benefits
Reduced switchover time:
Depending on the configuration, the switchover time is 30 to 60 seconds.
No reloading of installed modules:
Both startup and running configuration stay continually synchronized between the active to the redundant Supervisor Engines.
Synchronization of Online Insertion and Removal (OIR) events between the active and standby:
Modules in the online state remain online and modules in the down state remain in the down state after a switchover.
With RPR+, the redundant Supervisor Engine remains fully initialized and configured, which shortens the switchover time if the active Supervisor Engine fails or if the network administrator performs a manual switchover.
Note: The active Supervisor Engine checks the image version of the standby Supervisor Engine when the standby Supervisor Engine comes online. If the image on the standby Supervisor Engine does not match the image on the active Supervisor Engine, RPR redundancy mode is used.

30. Configuring and Verifying RPR+ Redundancy
Use the redundancy command to start configuring redundancy modes.
Use the mode rpr-plus command under redundancy configuration submode to configure RPR+:
S1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# redundancy Switch(config-red)# mode rpr-plus Switch(config-red)# end Switch# show redundancy states my state = 13 –ACTIVE peer state = 1 -DISABLED Mode = Simplex Unit = Primary Unit ID = 1 Redundancy Mode (Operational) = Route Processor Redundancy Plus Redundancy Mode (Configured) = Route Processor Redundancy Plus Split Mode = Disabled Manual Swact = Disabled Reason: Simplex mode Communications = Down Reason: Simplex mode <output omitted>
The example illustrates a user configuring RPR+ redundancy on a Catalyst 6500 and verifying the configuration.
Here the standby supervisor is currently not present; therefore, the peer state is disabled in the display.

33. Stateful Switchover (SSO)
Provides minimal Layer 2 traffic disruption during Supervisor switchover.
SSO establishes one of the supervisor engines as active while the other supervisor engine is designated as standby.
SSO then synchronizes information between them.
Standby Supervisor in SSO mode keeps in sync with active Supervisor for all changes in hardware and software states for features supported via SSO.
SSO switchover preserves FIB and adjacency entries and can forward Layer 3 traffic after a switchover.
Configuration information and data structures are synchronized from the active to the redundant supervisor engine at startup and whenever changes to the active supervisor engine configuration occur.

34. Protocols and Features Supported by SSO
802.3x (Flow Control)
802.3ad (LACP) and PAgP
802.1X (Authentication) and Port security
802.3af (Inline power)
VTP
Dynamic ARP Inspection/DHCP snooping/IP source guard
IGMP snooping (versions 1 and 2)
DTP (802.1Q and ISL)
MST/PVST+/Rapid-PVST
PortFast / UplinkFast / BackboneFast /BPDU Guard and filtering
Voice VLAN
Unicast MAC filtering
ACL (VLAN ACLs, Port ACLs, Router ACLs)
QOS (DBL)
Multicast storm control/broadcast storm control
In SSO mode, ports that were active before the switchover remain active because the redundant Supervisor Engine recognizes the hardware link status of every link. The neighboring devices do not see the link-down event during the switchover except the link to the previous active Supervisor. On the Catalyst 4500 switches, the uplink on the previous active Supervisor Engine is also retained even though that Supervisor Engine might be rebooting. In such a case, no spanning-tree topology changes occur because no link states change.
On the Catalyst 6500 family of switches, the time it takes for the Layer 2 traffic to be fully operational following a Supervisor failure is between 0 and 3 seconds.
On the Catalyst 4500, subsecond switchover can be achieved for Layer 2 traffic. Layer 3 information, however, needs to be relearned after a Supervisor Engine failover with just the SSO mode of redundancy, but the newly active Supervisor Engine continues to use existing Layer 2 switching information to continue forwarding traffic until Layer 3 information is relearned. This relearning involves rebuilding ARP tables and Layer 3 CEF and adjacency tables. Until the routing converges and CEF and adjacency tables are rebuilt, packets that need to be routed are dropped.

35. Configuring and Verifying SSO
Enter the redundancy command to enter redundancy modes.
Use the mode sso configuration mode command to configure RPR+.
S1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. S1(config)# redundancy S1(config-red)# mode sso Changing to sso mode will reset the standby. Do you want to continue? [confirm] S1(config-red)# end S1# show redundancy states my state = 13 –ACTIVE peer state = 8 -STANDBY HOT Mode = Duplex Unit = Primary Unit ID = 2 Redundancy Mode (Operational) = Stateful Switchover Redundancy Mode (Configured) = Stateful Switchover Split Mode = Disabled Manual Swact = Enabled Communications = Up <output omitted>
The example illustrates a user configuring SSO redundancy on a Catalyst 4500 and verifying the configuration.

36. NSF (Non-Stop Forwarding) with SSO
SSO with NSF minimizes the time that the L3 network is unavailable following Supervisor switchover.
It continues to forward IP packets using CEF entries built from the old active Supervisor providing zero or near zero packet loss.
Prevents route flapping.
Supports BGP, EIGRP, OSPF, and IS-IS.
Routing protocol neighbor relationships are maintained during Supervisor failover.
Cisco NSF provides:
Improved network availability: NSF continues forwarding network traffic and application state information so that user traffic is not interrupted after a supervisor switchover.
Overall network stability: Network stability is improved by maintaining routing protocol neighbor relationships during supervisor failover.
The Catalyst 4500 and 6500 family of switches supports another form of redundancy called NSF with SSO.
NSF with SSO redundancy includes the standard SSO for Layer 2 switching; however, it also minimizes the amount of time that a Layer 3 network is unavailable following a Supervisor Engine switchover by continuing to forward IP packets using CEF entries built from the old active Supervisor. Zero packet loss or near-zero packet loss is achieved with NSF with SSO redundancy mode.
When using the NSF with SSO feature, reconvergence of supported Layer 3 routing protocols (BGP, EIGRP, OSPF, and IS-IS) happens automatically in the background while packet forwarding continues. The standby Supervisor Engine maintains the copy of the CEF entries from the active Supervisor Engine, and upon switchover, the new active Supervisor Engine uses the CEF entries while the routing protocol converges without interruption to user traffic. When the routing protocol has converged and the Routing Information Base (RIB) has been built afresh on the route processor, any stale CEF entries are removed, and packet forwarding is fully restored.
Changes have been made to the routing protocols so that upon switchover, an NSFenabled router sends special packets that trigger routing updates from the NSF-aware neighbors without resetting the peer relationship. This feature prevents route flapping and routing changes during a Supervisor failover. NSF-aware routers understand that a neighboring NSF router can still forward packets when an RP switchover happens. NSFaware routers are not required to be NSF routers themselves.
For information about the NSF operations for each of the routing protocols, refer to the “Configuring NSF with SSO Supervisor Engine Redundancy” configuration section of the Catalyst 6500 configuration guide at Cisco.com.

37. Configuring and Verifying NSF with SSO
NSF is an additional configuration option for configuring SSO.
Use the nsf command to configure NSF for OSPF, EIGRP, and IS-IS.
Use the bgp graceful-restart command to configure BGP for NSF support.
Switch# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# router ospf 200 Switch(config-router)# nsf Switch(config-router)# exit Switch(config)# router bgp 100 Switch(config-router)# bgp graceful-restart Switch(config-router)# end Switch#
The example illustrates a user configuring support for BGP and OSPF and verifying the configuration output.

38. Configuring and Verifying NSF with SSO
Verify NSF in OSPF.
Switch# show ip ospf Routing Process “ospf 200” with ID and Domain ID Supports only single TOS(TOS0) routes Supports opaque LSA SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 0. Checksum Sum 0x0 Number of opaque AS LSA 0. Checksum Sum 0x0 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa External flood list length 0 Non-Stop Forwarding enabled, last NSF restart 00:02:36 ago (took 34 secs) Area BACKBONE(0) Number of interfaces in this area is 1 (0 loopback) Area has no authentication SPF algorithm executed 3 times Switch#
The example illustrates a user configuring support for BGP and OSPF and verifying the configuration output.

39. Configuring and Verifying NSF with SSO
Verify NSF in OSPF.
Switch# show ip bgp neighbors BGP neighbor is , remote AS 200, external link BGP version 4, remote router ID BGP state = Established, up for 00:01:23 Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh:advertised and received(new) Address family IPv4 Unicast:advertised and received Address family IPv4 Multicast:advertised and received Graceful Restart Capability:advertised and received Remote Restart timer is 120 seconds Address families preserved by peer: IPv4 Unicast, IPv4 Multicast Received 1539 messages, 0 notifications, 0 in queue Sent 100 messages, 0 notifications, 0 in queue Default minimum time between advertisement runs is 30 seconds
The example illustrates a user configuring support for BGP and OSPF and verifying the configuration output.

40. Ch. 9 High Availability
CIS 187 Multilayer Switched Networks CCNP version 7 Rick Graziani Spring 2016