C H A P T E R 5

Configuring NSF with SSO

Supervisor Engine Redundancy

This chapter describes how to configure supervisor engine redundancy using Cisco nonstop forwarding
(NSF) with stateful switchover (SSO) on Catalyst 6500 series switches.

Note • For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Software Releases 12.2SX Command References at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sx_mcl.html
• Cisco ME 6500 Series Ethernet switches do not support redundancy.
• NSF with SSO does not support IPv6 multicast traffic.

This chapter consists of these sections:

• Understanding NSF with SSO Supervisor Engine Redundancy, page 5-1
• Supervisor Engine Configuration Synchronization, page 5-9
• NSF Configuration Tasks, page 5-11
• Copying Files to the Redundant Supervisor Engine, page 5-19

Understanding NSF with SSO Supervisor Engine Redundancy

These sections describe supervisor engine redundancy using NSF with SSO:
• NSF with SSO Supervisor Engine Redundancy Overview, page 5-2
• SSO Operation, page 5-2
• NSF Operation, page 5-2
• Cisco Express Forwarding, page 5-3
• Multicast MLS NSF with SSO, page 5-3
• Routing Protocols, page 5-4
• NSF Benefits and Restrictions, page 5-8

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-1
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

NSF with SSO Supervisor Engine Redundancy Overview

Note • The two Gigabit Ethernet interfaces on the redundant supervisor engine are always active unless you
enter the fabric switching-mode allow dcef-only command.
• With a Supervisor Engine 720, if all the installed switching modules have DFCs, enter the fabric
switching-mode allow dcef-only command to disable the Ethernet ports on both supervisor
engines, which ensures that all modules are operating in dCEF mode and simplifies switchover to
the redundant supervisor engine. (CSCec05612)

Catalyst 6500 series switches support fault resistance by allowing a redundant supervisor engine to take
over if the primary supervisor engine fails. Cisco NSF works with SSO to minimize the amount of time
a network is unavailable to its users following a switchover while continuing to forward IP packets.
Catalyst 6500 series switches also support route processor redundancy (RPR), route processor
redundancy plus (RPR+), and single router mode with stateful switchover (SRM with SSO) for
redundancy. For information about these redundancy modes, see Chapter 6, “Configuring RPR
Supervisor Engine Redundancy.”
The following events cause a switchover:
• A hardware failure on the active supervisor engine
• Clock synchronization failure between supervisor engines
• A manual switchover

SSO Operation
SSO establishes one of the supervisor engines as active while the other supervisor engine is designated
as standby, and then SSO synchronizes information between them. A switchover from the active to the
redundant supervisor engine occurs when the active supervisor engine fails, or is removed from the
switch, or is manually shut down for maintenance. This type of switchover ensures that Layer 2 traffic
is not interrupted.
In networking devices running SSO, both supervisor engines must be running the same configuration so
that the redundant supervisor engine is always ready to assume control following a fault on the active
supervisor engine. SSO switchover also 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. Following an initial synchronization between the two supervisor engines, SSO
maintains state information between them, including forwarding information.
During switchover, system control and routing protocol execution is transferred from the active
supervisor engine to the redundant supervisor engine. The switch requires between 0 and 3 seconds to
switchover from the active to the redundant supervisor engine.

NSF Operation
Cisco NSF always runs with SSO and provides redundancy for Layer 3 traffic. NSF works with SSO to
minimize the amount of time that a network is unavailable to its users following a switchover. The main
purpose of NSF is to continue forwarding IP packets following a supervisor engine switchover.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-2 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

Cisco NSF is supported by the BGP, OSPF, and IS-IS protocols for routing and is supported by Cisco
Express Forwarding (CEF) for forwarding. The routing protocols have been enhanced with
NSF-capability and awareness, which means that routers running these protocols can detect a switchover
and take the necessary actions to continue forwarding network traffic and to recover route information
from the peer devices. The IS-IS protocol can be configured to use state information that has been
synchronized between the active and the redundant supervisor engine to recover route information
following a switchover instead of information received from peer devices.
A networking device is NSF-aware if it is running NSF-compatible software. A device is NSF-capable
if it has been configured to support NSF; it will rebuild routing information from NSF-aware or
NSF-capable neighbors.
Each protocol depends on CEF to continue forwarding packets during switchover while the routing
protocols rebuild the Routing Information Base (RIB) tables. After the routing protocols have converged,
CEF updates the FIB table and removes stale route entries. CEF then updates the line cards with the new
FIB information.

Cisco Express Forwarding

A key element of 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 engine synchronizes its current FIB and
adjacency databases with the FIB and adjacency databases on the redundant supervisor engine. Upon
switchover of the active supervisor engine, the redundant supervisor engine initially has FIB and
adjacency databases that are mirror images of those that were current on the active supervisor engine.
For platforms with intelligent line cards, the line cards will maintain the current forwarding information
over a switchover. For platforms with forwarding engines, CEF will keep the forwarding engine on the
redundant supervisor engine current with changes that are sent to it by CEF on the active supervisor
engine. The line cards or forwarding engines will be able to 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 will cause
prefix-by-prefix updates to CEF, which it uses to update the FIB and adjacency databases. Existing and
new entries will receive the new version (“epoch”) number, indicating that they have been refreshed. The
forwarding information is updated on the line cards or forwarding engine during convergence. The
supervisor engine 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.

Multicast MLS NSF with SSO

Note NSF with SSO does not support IPv6 multicast traffic. If you configure support for IPv6 multicast traffic,
configure RPR or RPR+ redundancy.

Multicast multilayer switching (MMLS) NSF with SSO is required so that Layer 3 multicast traffic that
is switched by the router is not dropped during switchover. Without MMLS NSF with SSO, the Layer 3
multicast traffic is dropped until the multicast protocols converge.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-3
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

During the switchover process, traffic is forwarded using the old database (from the previously active
supervisor engine). After multicast routing protocol convergence has taken place, the shortcuts
downloaded by the newly active route processor (RP) will be merged with the existing flows and marked
as new shortcuts. Stale entries will slowly be purged from the database allowing NSF to function during
the switchover while ensuring a smooth transition to the new cache.
Because multicast routing protocols such as Protocol Independent Multicast (PIM) sparse mode and PIM
dense mode are data driven, multicast packets are leaked to the router during switchover so that the
protocols can converge.
Because the traffic does not need to be forwarded by software for control-driven protocols such as
bidirectional PIM, the switch will continue to leak packets using the old cache for these protocols. The
router builds the mroute cache and installs the shortcuts in hardware. After the new routes are learned,
a timer is triggered to go through the database and purge the old flows.

Note Multicast MLS NSF with SSO requires NSF support in the unicast protocols.

Routing Protocols
The routing protocols run only on the RP of the active supervisor engine, and they receive routing
updates from their neighbor routers. Routing protocols do not run on the RP of the redundant supervisor
engine. Following a switchover, the routing protocols request that the NSF-aware neighbor devices send
state information to help rebuild the routing tables. Alternately, the IS-IS protocol can be configured to
synchronize state information from the active to the redundant supervisor engine to help rebuild the
routing table on the NSF-capable device in environments where neighbor devices are not NSF-aware.
Cisco NSF supports the BGP, OSPF, IS-IS, and EIGRP protocols

Note For NSF operation, the routing protocols depend on CEF to continue forwarding packets while the
routing protocols rebuild the routing information.

BGP Operation
When an NSF-capable router begins a BGP session with a BGP peer, it sends an OPEN message to the
peer. Included in the message is a statement that the NSF-capable device has “graceful” restart
capability. Graceful restart is the mechanism by which BGP routing peers avoid a routing flap following
a switchover. If the BGP peer has received this capability, it is aware that the device sending the message
is NSF-capable. Both the NSF-capable router and its BGP peers need to exchange the graceful restart
capability in their OPEN messages at the time of session establishment. If both the peers do not exchange
the graceful restart capability, the session will not be graceful restart capable.
If the BGP session is lost during the supervisor engine switchover, the NSF-aware BGP peer marks all
the routes associated with the NSF-capable router as stale; however, it continues to use these routes to
make forwarding decisions for a set period of time. This functionality prevents packets from being lost
while the newly active supervisor engine is waiting for convergence of the routing information with the
BGP peers.
After a supervisor engine switchover occurs, the NSF-capable router reestablishes the session with the
BGP peer. In establishing the new session, it sends a new graceful restart message that identifies the
NSF-capable router as having restarted.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-4 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

At this point, the routing information is exchanged between the two BGP peers. After this exchange is
complete, the NSF-capable device uses the routing information to update the RIB and the FIB with the
new forwarding information. The NSF-aware device uses the network information to remove stale routes
from its BGP table; the BGP protocol then is fully converged.
If a BGP peer does not support the graceful restart capability, it will ignore the graceful restart capability
in an OPEN message but will establish a BGP session with the NSF-capable device. This function will
allow interoperability with non-NSF-aware BGP peers (and without NSF functionality), but the BGP
session with non-NSF-aware BGP peers will not be graceful restart capable.

Note 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 will not establish an NSF-capable session with that neighbor. All other neighbors
that have graceful restart capability will continue to have NSF-capable sessions with this NSF-capable
networking device.

OSPF Operation
When an OSPF NSF-capable router performs a supervisor engine switchover, it must perform the
following tasks in order to resynchronize its link state database with its OSPF neighbors:
• Relearn the available OSPF neighbors on the network without causing a reset of the neighbor
relationship
• Reacquire the contents of the link state database for the network
As quickly as possible after a supervisor engine switchover, the NSF-capable router sends an OSPF NSF
signal to neighboring NSF-aware devices. Neighbor networking devices recognize this signal as an
indicator that the neighbor relationship with this router should not be reset. As the NSF-capable router
receives signals from other routers on the network, it can begin to rebuild its neighbor list.
After neighbor relationships are reestablished, the NSF-capable router begins to resynchronize its
database with all of its NSF-aware neighbors. At this point, the routing information is exchanged
between the OSPF neighbors. Once this exchange is complete, the NSF-capable device uses the routing
information to remove stale routes, update the RIB, and update the FIB with the new forwarding
information. The OSPF protocols are then fully converged.

Note OSPF 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 will disable NSF
capabilities for that segment. Other network segments composed entirely of NSF-capable or NSF-aware
routers will continue to provide NSF capabilities.

IS-IS Operation
When an IS-IS NSF-capable router performs a supervisor engine switchover, it must perform the
following tasks in order to resynchronize its link state database with its IS-IS neighbors:
• Relearn the available IS-IS neighbors on the network without causing a reset of the neighbor
relationship
• Reacquire the contents of the link state database for the network

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-5
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

The IS-IS NSF feature offers two options when you configure NSF:
• Internet Engineering Task Force (IETF) IS-IS
• Cisco IS-IS
If neighbor routers on a network segment are running a software version that supports the IETF Internet
draft for router restartability, they will assist an IETF NSF router that is restarting. With IETF, neighbor
routers provide adjacency and link-state information to help rebuild the routing information following a
switchover. A benefit of IETF IS-IS configuration is operation between peer devices based on a proposed
standard.

Note If you configure IETF on the networking device, but neighbor routers are not IETF-compatible, NSF will
abort following a switchover.

If the neighbor routers on a network segment are not NSF-aware, you must use the Cisco configuration
option. The Cisco IS-IS configuration transfers both protocol adjacency and link-state information from
the active to the redundant supervisor engine. An advantage of Cisco configuration is that it does not rely
on NSF-aware neighbors.

IETF IS-IS Configuration

As quickly as possible after a supervisor engine switchover, the NSF-capable router sends IS-IS NSF
restart requests to neighboring NSF-aware devices using the IETF IS-IS configuration. Neighbor
networking devices recognize this restart request as an indicator that the neighbor relationship with this
router should not be reset, but that they should initiate database resynchronization with the restarting
router. As the restarting router receives restart request responses from routers on the network, it can
begin to rebuild its neighbor list.
After this exchange is complete, the NSF-capable device uses the link-state information to remove stale
routes, update the RIB, and update the FIB with the new forwarding information; IS-IS is then fully
converged.
The switchover from one supervisor engine to the other happens within seconds. IS-IS reestablishes its
routing table and resynchronizes with the network within a few additional seconds. At this point, IS-IS
waits for a specified interval before it will attempt a second NSF restart. During this time, the new
redundant supervisor engine will boot up and synchronize its configuration with the active supervisor
engine. The IS-IS NSF operation waits for a specified interval to ensure that connections are stable
before attempting another restart of IS-IS NSF. This functionality prevents IS-IS from attempting
back-to-back NSF restarts with stale information.

Cisco IS-IS Configuration

Using the Cisco configuration option, full adjacency and LSP information is saved, or checkpointed, to
the redundant supervisor engine. Following a switchover, the newly active supervisor engine maintains
its adjacencies using the check-pointed data, and can quickly rebuild its routing tables.

Note Following a switchover, Cisco IS-IS NSF has complete neighbor adjacency and LSP information;
however, it must wait for all interfaces to come on line that had adjacencies prior to the switchover. If
an interface does not come on line within the allocated interface wait time, the routes learned from these
neighbor devices are not considered in routing table recalculation. IS-IS NSF provides a command to
extend the wait time for interfaces that, for whatever reason, do not come on line in a timely fashion.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-6 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

The switchover from one supervisor engine to the other happens within seconds. IS-IS reestablishes its
routing table and resynchronizes with the network within a few additional seconds. At this point, IS-IS
waits for a specified interval before it will attempt a second NSF restart. During this time, the new
redundant supervisor engine will boot up and synchronize its configuration with the active supervisor
engine. After this synchronization is completed, IS-IS adjacency and LSP data is check-pointed to the
redundant supervisor engine; however, a new NSF restart will not be attempted by IS-IS until the interval
time expires. This functionality prevents IS-IS from attempting back-to-back NSF restarts.

EIGRP Operation
When an EIGRP NSF-capable router initially comes back up from an NSF restart, it has no neighbor and
its topology table is empty. The router is notified by the redundant (now active) supervisor engine when
it needs to bring up the interfaces, reacquire neighbors, and rebuild the topology and routing tables. The
restarting router and its peers must accomplish these tasks without interrupting the data traffic directed
toward the restarting router. EIGRP peer routers maintain the routes learned from the restarting router
and continue forwarding traffic through the NSF restart process.
To prevent an adjacency reset by the neighbors, the restarting router will use a new Restart (RS) bit in
the EIGRP packet header to indicate a restart. The RS bit will be set in the hello packets and in the initial
INIT update packets during the NSF restart period. The RS bit in the hello packets allows the neighbors
to be quickly notified of the NSF restart. Without seeing the RS bit, the neighbor can only detect an
adjacency reset by receiving an INIT update or by the expiration of the hello hold timer. Without the RS
bit, a neighbor does not know if the adjacency reset should be handled using NSF or the normal startup
method.
When the neighbor receives the restart indication, either by receiving the hello packet or the INIT packet,
it will recognize the restarting peer in its peer list and will maintain the adjacency with the restarting
router. The neighbor then sends it topology table to the restarting router with the RS bit set in the first
update packet indicating that it is NSF-aware and is helping out the restarting router. The neighbor does
not set the RS bit in their hello packets, unless it is also a NSF restarting neighbor.

Note A router may be NSF-aware but may not be participating in helping out the NSF restarting neighbor
because it is coming up from a cold start.

If at least one of the peer routers is NSF-aware, the restarting router would then receive updates and
rebuild its database. The restarting router must then find out if it had converged so that it can notify the
routing information base (RIB). Each NSF-aware router is required to send an end of table (EOT) marker
in the last update packet to indicate the end of the table content. The restarting router knows it has
converged when it receives the EOT marker. The restarting router can then begin sending updates.
An NSF-aware peer would know when the restarting router had converged when it receives an EOT
indication from the restarting router. The peer then scans its topology table to search for the routes with
the restarted neighbor as the source. The peer compares the route timestamp with the restart event
timestamp to determine if the route is still available. The peer then goes active to find alternate paths for
the routes that are no longer available through the restarted router.
When the restarting router has received all EOT indications from its neighbors or when the NSF converge
timer expires, EIGRP will notify the RIB of convergence. EIGRP waits for the RIB convergence signal
and then floods its topology table to all awaiting NSF-aware peers.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-7
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

NSF Benefits and Restrictions

Cisco 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 that had been
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 throughout 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 in the event of a switchover, routing flaps are
avoided.
• No loss of user sessions
User sessions established before the switchover are maintained.
Cisco NSF with SSO has these restrictions:
• For NSF operation, you must have SSO configured on the device.
• NSF with SSO supports IP Version 4 traffic and protocols only.
• The Hot Standby Routing Protocol (HSRP) is not SSO-aware, meaning state information is not
maintained between the active and standby supervisor engine during normal operation. HSRP and
SSO can coexist but both features work independently. Traffic that relies on HSRP may switch to
the HSRP standby in the event of a supervisor switchover.
• The Gateway Load Balancing Protocol (GLBP) is not SSO-aware, meaning state information is not
maintained between the active and standby supervisor engine during normal operation. GLBP and
SSO can coexist but both features work independently. Traffic that relies on GLBP may switch to
the GLBP standby in the event of a Supervisor switchover.
• The Virtual Redundancy Routing Protocols (VRRP) is not SSO-aware, meaning state information is
not maintained between the active and standby supervisor engine during normal operation. VRRP
and SSO can coexist but both features work independently. Traffic that relies on VRRP may switch
to the VRRP standby in the event of a supervisor switchover.
• Multiprotocol Label Switching (MPLS) is not suported with Cisco NSF with SSO; however, MPLS
and NSF with SSO can coexist. If NSF with SSO is configured in the same chassis with MPLS, the
failover performance of MPLS protocols will be at least equivalent to RPR+ while the supported
NSF with SSO protocols still retain the additional benefits of NSF with SSO.
• All neighboring devices participating in BGP NSF must be NSF-capable and configured for BGP
graceful restart.
• OSPF NSF for virtual links is not supported.
• All OSPF networking devices on the same network segment must be NSF-aware (running an NSF
software image).
• For IETF IS-IS, all neighboring devices must be running an NSF-aware software image.
• IPv4 Multicast NSF with SSO is supported by the PFC3 only.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-8 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Supervisor Engine Configuration Synchronization

• The underlying unicast protocols must be NSF-aware in order to use multicast NSF with SSO.
• Bidirectional forwarding detection (BFD) is not SSO-aware and is not supported by NSF with SSO.

Supervisor Engine Configuration Synchronization

These sections describe supervisor engine configuration synchronization:
• Supervisor Engine Redundancy Guidelines and Restrictions, page 5-9
• Redundancy Configuration Guidelines and Restrictions, page 5-9

Note Configuration changes made through SNMP are not synchronized to the redundant supervisor engine.
After you configure the switch through SNMP, copy the running-config file to the startup-config file on
the active supervisor engine to trigger synchronization of the startup-config file on the redundant
supervisor engine.

Supervisor Engine Redundancy Guidelines and Restrictions

These sections describe supervisor engine redundancy guidelines and restrictions:
• Redundancy Configuration Guidelines and Restrictions, page 5-9
• Hardware Configuration Guidelines and Restrictions, page 5-10
• Configuration Mode Restrictions, page 5-10

Redundancy Configuration Guidelines and Restrictions

These guidelines and restrictions apply to all redundancy modes:
• Because the Supervisor Engine 720 and Supervisor Engine 720-10GE integrate the switch fabric
functionality on the supervisor engine, a supervisor engine switchover will force a fabric switchover
as well. During the fabric switchover, data will be lost for a period of between 0.5 seconds and 1.5
seconds. When a Supervisor Engine 720 or Supervisor Engine 720-10GE is installed in a
Catalyst 6500 series switch E series chassis (such as the WS-C6509-E), Release 12.2(33)SXH
incorporates a fast fabric switchover mechanism, called enhanced hot-standby fabric switchover
time, to reduce the data loss to a period of between 50 milliseconds and 0.5 seconds for
feature-capable cards.
• When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the
redundant supervisor engine are always active unless you enter the fabric switching-mode allow
dcef-only command.
• With a Supervisor Engine 720, if all the installed switching modules have DFCs, enter the fabric
switching-mode allow dcef-only command to disable the Ethernet ports on both supervisor
engines, which ensures that all modules are operating in dCEF mode and simplifies switchover to
the redundant supervisor engine.
• Supervisor engine redundancy does not provide supervisor engine mirroring or supervisor engine
load balancing. Only one supervisor engine is active.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-9
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Supervisor Engine Configuration Synchronization

• Configuration changes made through SNMP are not synchronized to the redundant supervisor
engine. After you configure the switch through SNMP, copy the running-config file to the
startup-config file on the active supervisor engine to trigger synchronization of the startup-config
file on the redundant supervisor engine.
• Supervisor engine switchover takes place after the failed supervisor engine completes a core dump.
A core dump can take up to 15 minutes. To get faster switchover time, disable core dump on the
supervisor engines.
• If a fabric synchronization error occurs, the default behavior is to switchover to the redundant
supervisor engine. In some cases, a switchover to the redundant supervisor engine is more disruptive
than powering down the module that caused the fabric synchronization error. Enter the no fabric
error-recovery fabric-switchover command to disable the switchover and power down the module
with the fabric synchronization error.

Hardware Configuration Guidelines and Restrictions

For redundant operation, the following guidelines and restrictions must be met:
• Cisco IOS running on the SP and the RP supports redundant configurations where the supervisor
engines are identical. If they are not identical, one will boot first and become active and hold the
other supervisor engine in a reset condition.
• Each supervisor engine must have the resources to run the switch on its own, which means all
supervisor engine resources are duplicated, including all flash devices.
• Make separate console connections to each supervisor engine. Do not connect a Y cable to the
console ports.
• Both supervisor engines must have the same system image (see the “Copying Files to the Redundant
Supervisor Engine” section on page 5-19).

Note If a newly installed redundant supervisor engine has the Catalyst operating system installed,
remove the active supervisor engine and boot the switch with only the redundant supervisor
engine installed. Follow the procedures in the current release notes to convert the redundant
supervisor engine from the Catalyst operating system.

• The configuration register in the startup-config must be set to autoboot.

Note There is no support for booting from the network.

Configuration Mode Restrictions

The following configuration restrictions apply during the startup synchronization process:
• You cannot perform configuration changes during the startup (bulk) synchronization. If you attempt
to make configuration changes during this process, the following message is generated:
Config mode locked out till standby initializes

• If configuration changes occur at the same time as a supervisor engine switchover, these
configuration changes are lost.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-10 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

NSF Configuration Tasks

The following sections describe the configuration tasks for the NSF feature:
• Configuring SSO, page 5-11
• Configuring Multicast MLS NSF with SSO, page 5-12
• Verifying Multicast NSF with SSO, page 5-12
• Configuring CEF NSF, page 5-13
• Verifying CEF NSF, page 5-13
• Configuring BGP NSF, page 5-13
• Verifying BGP NSF, page 5-14
• Configuring OSPF NSF, page 5-14
• Verifying OSPF NSF, page 5-15
• Configuring IS-IS NSF, page 5-16
• Verifying IS-IS NSF, page 5-16

Configuring SSO
You must configure SSO in order to use NSF with any supported protocol. To configure SSO, perform
this task:

Command Purpose
Step 1 Router(config)# redundancy Enters redundancy configuration mode.
Step 2 Router(config-red)# mode sso Configures SSO. When this command is entered, the
redundant supervisor engine is reloaded and begins to
work in SSO mode.
Step 3 Router# show running-config Verifies that SSO is enabled.
Step 4 Router# show redundancy states Displays the operating redundancy mode.

This example shows how to configure the system for SSO and display the redundancy state:
Router> enable
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# redundancy
Router(config-red)# mode sso
Router(config-red)# end
Router# 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

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-11
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

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
Router#

Configuring Multicast MLS NSF with SSO

Note The commands in this section are optional and can be used to customize your configuration. For most
users, the default settings are adequate.

Multicast MLS NSF with SSO is on by default when SSO is selected as the redundancy mode. To
configure multicast NSF with SSO parameters, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# mls ip multicast sso convergence-time Specifies the maximum time to wait for protocol
time convergence; valid values are from 0 to 3600
seconds.
Step 3 Router(config)# mls ip multicast sso leak interval Specifies the packet leak interval; valid values are
from 0 to 3600 seconds. For PIM sparse mode and
PIM dense mode this is the period of time after
which packet leaking for existing PIM sparse mode
and PIM dense mode mutlitcast forwarding entries
should be completed.
Step 4 Router(config)# mls ip multicast sso leak percentage Specifies the percentage of multicast flows; valid
values are from 1 to 100 percent. The value
represents the percentage of the total number of
existing PIM sparse mode and PIM dense mode
multicast flows that should be flagged for packet
leaking.

Verifying Multicast NSF with SSO

To verify the multicast NSF with SSO settings, enter the show mls ip multicast sso command:
router# show mls ip multicast sso
Multicast SSO is enabled
Multicast HA Parameters
---------------------------------------------------+------+
protocol convergence timeout 120 secs
flow leak percent 10
flow leak interval 60 secs

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-12 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Configuring CEF NSF

The CEF NSF feature operates by default while the networking device is running in SSO mode. No
configuration is necessary.

Verifying CEF NSF

To verify that CEF is NSF-capable, enter the show cef state command:
router# show cef state

CEF Status [RP]

CEF enabled/running
dCEF enabled/running
CEF switching enabled/running
CEF default capabilities:
Always FIB switching: yes
Default CEF switching: yes
Default dCEF switching: yes
Update HWIDB counters: no
Drop multicast packets: no
.
.
.
CEF NSF capable: yes
IPC delayed func on SSO: no
RRP state:
I am standby RRP: no
My logical slot: 0
RF PeerComm: no

Configuring BGP NSF

Note You must configure BGP graceful restart on all peer devices participating in BGP NSF.

To configure BGP for NSF, perform this task (repeat this procedure on each of the BGP NSF peer
devices):

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router bgp as-number Enables a BGP routing process, which places the
router in router configuration mode.
Step 3 Router(config-router)# bgp graceful-restart Enables the BGP graceful restart capability,
starting BGP NSF.
If you enter this command after the BGP session
has been established, you must restart the session
for the capability to be exchanged with the BGP
neighbor.
Use this command on the restarting router and all
of its peers.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-13
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Verifying BGP NSF

To verify BGP NSF, you must check that the graceful restart function is configured on the SSO-enabled
networking device and on the neighbor devices. To verify, follow these steps:

Step 1 Verify that “bgp graceful-restart” appears in the BGP configuration of the SSO-enabled router by
entering the show running-config command:
Router# show running-config

.
.
.
router bgp 120
.
.
.
bgp graceful-restart
neighbor 10.2.2.2 remote-as 300
.
.
.

Step 2 Repeat step 1 on each of the BGP neighbors.

Step 3 On the SSO device and the neighbor device, verify that the graceful restart function is shown as both
advertised and received, and confirm the address families that have the graceful restart capability. If no
address families are listed, then BGP NSF also will not occur:
router# show ip bgp neighbors x.x.x.x

BGP neighbor is 192.168.2.2, remote AS YY, external link

BGP version 4, remote router ID 192.168.2.2
BGP state = Established, up for 00:01:18
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 famiiy IPv4 Multicast:advertised and received
Graceful Restart Capabilty: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 1544 messages, 0 notifications, 0 in queue
Default minimum time between advertisement runs is 30 seconds

Configuring OSPF NSF

Note All peer devices participating in OSPF NSF must be made OSPF NSF-aware, which happens
automatically once you install an NSF software image on the device.

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-14 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

To configure OSPF NSF, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router ospf processID Enables an OSPF routing process, which places the
router in router configuration mode.
Step 3 Router(config-router)# nsf Enables NSF operations for OSPF.

Verifying OSPF NSF

To verify OSPF NSF, you must check that the NSF function is configured on the SSO-enabled
networking device. To verify OSPF NSF, follow these steps:

Step 1 Verify that ‘nsf’ appears in the OSPF configuration of the SSO-enabled device by entering the show
running-config command:
Router# show running-config

router ospf 120

log-adjacency-changes
nsf
network 192.168.20.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 1
network 192.168.40.0 0.0.0.255 area 2
.
.
.

Step 2 Enter the show ip ospf command to verify that NSF is enabled on the device:
router> show ip ospf

Routing Process "ospf 1" with ID 192.168.2.1 and Domain ID 0.0.0.1

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:06 ago (took 44 secs)
Area BACKBONE(0)
Number of interfaces in this area is 1 (0 loopback)
Area has no authentication
SPF algorithm executed 3 times

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-15
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Configuring IS-IS NSF

To configure IS-IS NSF, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router isis [tag] Enables an IS-IS routing process, which places the
router in router configuration mode.
Step 3 Router(config-router)# nsf [cisco | ietf] Enables NSF operation for IS-IS.
Enter the ietf keyword to enable IS-IS in a
homogeneous network where adjacencies with
networking devices supporting IETF draft-based
restartability is guaranteed.
Enter the cisco keyword to run IS-IS in
heterogeneous networks that might not have
adjacencies with NSF-aware networking devices.
Step 4 Router(config-router)# nsf interval [minutes] (Optional) Specifies the minimum time between
NSF restart attempts. The default time between
consecutive NSF restart attempts is 5 minutes.
Step 5 Router(config-router)# nsf t3 {manual [seconds] | (Optional) Specifies the time IS-IS will wait for the
adjacency} IS-IS database to synchronize before generating
overloaded link-state information for itself and
flooding that information out to its neighbors.
The t3 keyword applies only if you selected IETF
operation. When you specify adjacency, the router
that is restarting obtains its wait time from
neighboring devices.
Step 6 Router(config-router)# nsf interface wait seconds (Optional) Specifies how long an IS-IS NSF restart
will wait for all interfaces with IS-IS adjacencies to
come up before completing the restart. The default
is 10 seconds.

Verifying IS-IS NSF

To verify IS-IS NSF, you must check that the NSF function is configured on the SSO-enabled networking
device. To verify IS-IS NSF, follow these steps:

Step 1 Verify that “nsf” appears in the IS-IS configuration of the SSO-enabled device by entering the show
running-config command. The display will show either the Cisco IS-IS or the IETF IS-IS configuration.
The following display indicates that the device uses the Cisco implementation of IS-IS NSF:
Router# show running-config
<...Output Truncated...>
router isis
nsf cisco
<...Output Truncated...>

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-16 OL-13013-02
Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Step 2 If the NSF configuration is set to cisco, enter the show isis nsf command to verify that NSF is enabled
on the device. Using the Cisco configuration, the display output will be different on the active and
redundant RPs. The following display shows sample output for the Cisco configuration on the active RP.
In this example, note the presence of “NSF restart enabled”:
router# show isis nsf

NSF is ENABLED, mode 'cisco'

RP is ACTIVE, standby ready, bulk sync complete

NSF interval timer expired (NSF restart enabled)
Checkpointing enabled, no errors
Local state:ACTIVE, Peer state:STANDBY HOT, Mode:SSO

The following display shows sample output for the Cisco configuration on the standby RP. In this
example, note the presence of “NSF restart enabled”:
router# show isis nsf

NSF enabled, mode 'cisco'

RP is STANDBY, chkpt msg receive count:ADJ 2, LSP 7
NSF interval timer notification received (NSF restart enabled)
Checkpointing enabled, no errors
Local state:STANDBY HOT, Peer state:ACTIVE, Mode:SSO

Step 3 If the NSF configuration is set to ietf, enter the show isis nsf command to verify that NSF is enabled on
the device. The following display shows sample output for the IETF IS-IS configuration on the
networking device:
router# show isis nsf

NSF is ENABLED, mode IETF

NSF pdb state:Inactive
NSF L1 active interfaces:0
NSF L1 active LSPs:0
NSF interfaces awaiting L1 CSNP:0
Awaiting L1 LSPs:
NSF L2 active interfaces:0
NSF L2 active LSPs:0
NSF interfaces awaiting L2 CSNP:0
Awaiting L2 LSPs:
Interface:Serial3/0/2
NSF L1 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
Interface:GigabitEthernet2/0/0
NSF L1 Restart state:Running
NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE
Interface:Loopback1

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-17
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

NSF L1 Restart state:Running

NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE

Configuring EIGRP NSF

To configure EIGRP NSF, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router eigrp as-number Enables an EIGRP routing process, which places
the router in router configuration mode.
Step 3 Router(config-router)# nsf Enables EIGRP NSF.
Use this command on the restarting router and all
of its peers.

Verifying EIGRP NSF

To verify EIGRP NSF, you must check that the NSF function is configured on the SSO-enabled
networking device. To verify EIGRP NSF, follow these steps:

Step 1 Verify that “nsf” appears in the EIGRP configuration of the SSO-enabled device by entering the show
running-config command:
Router# show running-config
.
.
.
router eigrp 100
auto-summary
nsf
.
.
.
Step 2 Enter the show ip protocols command to verify that NSF is enabled on the device:
Router# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-18 OL-13013-02
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Copying Files to the Redundant Supervisor Engine

EIGRP maximum metric variance 1

Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
EIGRP NSF enabled
NSF signal timer is 20s
NSF converge timer is 120s
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170

Synchronizing the Supervisor Engine Configurations

During normal operation, the startup-config and config-registers configurations are synchronized by
default between the two supervisor engines. In a switchover, the new active supervisor engine uses the
current configuration.

Copying Files to the Redundant Supervisor Engine

Enter this command to copy a file to the disk0: device on a redundant supervisor engine:
Router# copy source_device:source_filename slavedisk0:target_filename

Enter this command to copy a file to the bootflash: device on a redundant supervisor engine:
Router# copy source_device:source_filename slavesup-bootflash:target_filename

Enter this command to copy a file to the bootflash: device on a redundant RP:
Router# copy source_device:source_filename slavebootflash:target_filename

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
OL-13013-02 5-19
 Chapter 5 Configuring NSF with SSO Supervisor Engine Redundancy
Copying Files to the Redundant Supervisor Engine

Cisco IOS Software Configuration Guide, Release 12.2(33)SXH and Later Releases
5-20 OL-13013-02