Configuring Cisco NSF with SSO

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for NSF with SSO

The following are prerequisites and considerations for configuring NSF with SSO.

  • Use of the routing protocols requires the IP Services license level. EIGRP-stub and OSPF for routed access are supported on IP Base license level.

  • BGP support in NSF requires that neighbor networking devices be NSF-aware; that is, the devices must have the graceful restart capability and advertise that capability in their OPEN message during session establishment. If an NSF-capable router discovers that a particular BGP neighbor does not have graceful restart capability, it does not establish an NSF-capable session with that neighbor. All other neighbors that have graceful restart capability continue to have NSF-capable sessions with this NSF-capable networking device.

  • OSPF support in NSF requires that all neighbor networking devices be NSF-aware. If an NSF-capable router discovers that it has non-NSF -aware neighbors on a particular network segment, it disables NSF capabilities for that segment. Other network segments composed entirely of NSF-capable or NSF-aware routers continue to provide NSF capabilities.

Restrictions for NSF with SSO

The following are restrictions for configuring NSF with SSO:

  • NSF capability is supported for IPv4 routing protocols only. NSF capability is not supported for IPv6 routing protocols.

  • NSF does not support IP Multicast Routing, as it is not SSO-aware.

  • NSF is not supported if the IOS-XE software is running in the LAN Base mode.

  • For NSF operation, you must have SSO configured on the device.

  • NSF with SSO supports IP Version 4 traffic and protocols only; NSF with SSO does not support IPv6 traffic.

  • All Layer 3 neighboring devices must be NSF Helper or NSF-capable to support graceful restart capability.

  • For IETF, all neighboring devices must be running an NSF-aware software image.

Information About NSF with SSO

Overview of NSF with SSO

The switch supports fault resistance by allowing a standby switch to take over if the active switch becomes unavailable. Cisco nonstop forwarding (NSF) works with stateful switchover (SSO) to minimize the amount of time a network is unavailable.

NSF provides these benefits:

  • Improved network availability—NSF continues forwarding network traffic and application state information so that user session information is maintained after a switchover.

  • Overall network stability—Network stability may be improved with the reduction in the number of route flaps, which were created when routers in the network failed and lost their routing tables.

  • Neighboring routers do not detect a link flap—Because the interfaces remain up during a switchover, neighboring routers do not detect a link flap (the link does not go down and come back up).

  • Prevents routing flaps—Because SSO continues forwarding network traffic during a switchover, routing flaps are avoided.

  • Maintains user sessions established prior to the switchover.
Keepalive messages are sent and received between the active and standby switches.
  • If the standby switch does not respond, a new standby switch is elected.

  • If the active switch does not respond, the standby switch becomes the active switch.

In addition, hello messages are sent and received by all stack members.
  • If a stack member does not respond, that member is removed from the stack.

  • If the standby switch does not respond, a new standby switch is elected.

  • If the active switch does not respond, the standby switch becomes the active switch.

SSO Operation

When a standby switch runs in SSO mode, the standby switch starts up in a fully-initialized state and synchronizes with the persistent configuration and the running configuration of the active switch. 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 synchronization. Consequently, it offers minimum interruption to Layer 2 sessions in a redundant active switch configuration.

If the active switch fails, the standby switch becomes the active switch. This new active switch 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 switch.


Note

SSO Layer 2 Only is supported if the IOS-XE software is running the LAN Base license level.

The state of these features is preserved between both the active and standby switches:

  • 802.3

  • 802.3u

  • 802.3x (Flow Control)

  • 802.3ab (GE)

  • 802.3z (Gigabit Ethernet including CWDM)

  • 802.3ad (LACP)

  • 802.1p (Layer 2 QoS)

  • 802.1q

  • 802.1X (Authentication)

  • 802.1D (Spanning Tree Protocol)

  • 802.3af (Inline power)

  • PAgP

  • VTP

  • Dynamic ARP Inspection

  • DHCP

  • 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

  • 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 standby and active switches:

  • 802.1Q tunneling with Layer 2 Protocol Tunneling (L2PT)

  • Baby giants

  • Jumbo frame support

  • CDP

  • Flood blocking

  • UDLD

  • SPAN/RSPAN

  • NetFlow

All Layer 3 protocols on a switch are learned on the standby switch if SSO is enabled.

Cisco Express Forwarding

A key element of Cisco IOS Nonstop Forwarding (NSF) is packet forwarding. In a Cisco networking device, packet forwarding is provided by Cisco Express Forwarding (CEF). CEF maintains the FIB and uses the FIB information that was current at the time of the switchover to continue forwarding packets during a switchover. This feature reduces traffic interruption during the switchover.

During normal NSF operation, CEF on the active supervisor switch synchronizes its current FIB and adjacency databases with the FIB and adjacency databases on the standby switch. Upon switchover, the standby switch initially has FIB and adjacency databases that are mirror images of those that were current on the active switch. CEF keeps the forwarding engine on the standby switch current with changes that are sent to it by CEF on the active switch. The forwarding engine can continue forwarding after a switchover as soon as the interfaces and a data path are available.

As the routing protocols start to repopulate the RIB on a prefix-by-prefix basis, the updates cause prefix-by-prefix updates to CEF, which it uses to update the FIB and adjacency databases. Existing and new entries receive the new version (“epoch”) number, indicating that they have been refreshed. The forwarding information is updated on the forwarding engine during convergence. The switch signals when the RIB has converged. The software removes all FIB and adjacency entries that have an epoch older than the current switchover epoch. The FIB now represents the newest routing protocol forwarding information.

How to Configure Cisco NSF with SSO

Configuring SSO

You must configure SSO in order to use NSF with any supported protocol.

Procedure

  Command or Action Purpose
Step 1

redundancy

Example:

Switch(config)# redundancy

Enters redundancy configuration mode.

Step 2

mode sso

Example:

Switch(config-red)# mode sso

Configures SSO. When this command is entered, the standby switch is reloaded and begins to work in SSO mode.

Step 3

end

Example:

Switch(config-red)# end

Returns to EXEC mode.

Step 4

show running-config

Example:

Switch# show running-config

Verifies that SSO is enabled.

Step 5

show redundancy states

Example:

Switch# show redundancy states

Displays the operating redundancy mode.

Configuring SSO Example

This example shows how to configure the system for SSO and display the redundancy state:

Switch(config)# redundancy 
		Switch(config)# mode sso
  Switch(config)# end
		Switch# show redundancy states
		my state = 13 -ACTIVE
  peer state = 8 -STANDBY HOT
  Mode = Duplex
		Unit = Primary
		Unit ID = 5
		Redundancy Mode (Operational) = sso
		Redundancy Mode (Configured) = sso
		Split Mode = Disabled
		Manual Swact = Enabled
		Communications = Up
		client count = 29
		client_notification_TMR = 30000 milliseconds
		keep_alive TMR = 9000 milliseconds
		keep_alive count = 1
		keep_alive threshold = 18
		RF debug mask = 0x0

Verifying CEF NSF

To verify CEF NSF, use the show cef state privileged EXEX command.

Switch# show cef state
CEF Status:
RP instance
common CEF enabled
IPv4 CEF Status:
CEF enabled/running
dCEF enabled/running
CEF switching enabled/running
universal per-destination load sharing algorithm, id DEA83012
IPv6 CEF Status:
CEF disabled/not running
dCEF disabled/not running
universal per-destination load sharing algorithm, id DEA83012
RRP state:
I am standby RRP: no
RF Peer Presence: yes
RF PeerComm reached: yes
RF Progression blocked: never
Redundancy mode: rpr(1)
CEF NSF sync: disabled/not running
CEF ISSU Status:
FIBHWIDB broker
No slots are ISSU capable.
FIBIDB broker
No slots are ISSU capable.
FIBHWIDB Subblock broker
No slots are ISSU capable.
FIBIDB Subblock broker
No slots are ISSU capable.
Adjacency update
No slots are ISSU capable.
IPv4 table broker
No slots are ISSU capable.
CEF push
No slots are ISSU capable.