- Preface
- Product Overview
- Configuring the Router for the First Time
- Configuring a Supervisor Engine 720
- Configuring a Route Switch Processor 720
- Configuring NSF with SSO Supervisor Engine Redundancy
- ISSU and eFSU on Cisco 7600 Series Routers
- Configuring RPR and RPR+ Supervisor Engine Redundancy
- Configuring Interfaces
- Configuring a Supervisor Engine 32
- Configuring LAN Ports for Layer 2 Switching
- Configuring Flex Links
- Configuring EtherChannels
- Configuring VTP
- Configuring VLANs
- Configuring Private VLANs
- Configuring Cisco IP Phone Support
- Configuring IEEE 802.1Q Tunneling
- Configuring Layer 2 Protocol Tunneling
- Configuring L2TPv3
- Configuring STP and MST
- Configuring Optional STP Features
- Configuring Layer 3 Interfaces
- Configuring GTP-SLB IPV6 Support
- IP Subscriber Awareness over Ethernet
- Configuring UDE and UDLR
- Configuring Multiprotocol Label Switching on the PFC
- Configuring IPv4 Multicast VPN Support
- Configuring Multicast VPN Extranet Support
- Configuring IP Unicast Layer 3 Switching
- Configuring IPv6 Multicast PFC3 and DFC3 Layer 3 Switching
- Configuring IPv4 Multicast Layer 3 Switching
- Configuring MLDv2 Snooping for IPv6 Multicast Traffic
- Configuring IGMP Snooping for IPv4 Multicast Traffic
- Configuring PIM Snooping
- Configuring Network Security
- Understanding Cisco IOS ACL Support
- Configuring VRF aware 6RD Tunnels
- Configuring VLAN ACLs
- Private Hosts (Using PACLs)
- Configuring IPv6 PACL
- IPv6 First-Hop Security Features
- Configuring Online Diagnostics
- Configuring Denial of Service Protection
- Configuring DHCP Snooping
- Configuring Dynamic ARP Inspection
- Configuring Traffic Storm Control
- Unknown Unicast Flood Blocking
- Configuring PFC QoS
- Configuring PFC QoS Statistics Data Export
- Configuring MPLS QoS on the PFC
- Configuring LSM MLDP based MVPN Support
- Configuring IEEE 802.1X Port-Based Authentication
- Configuring IEEE 802.1ad
- Configuring Port Security
- Configuring UDLD
- Configuring NetFlow and NDE
- Configuring Local SPAN, RSPAN, and ERSPAN
- Configuring SNMP IfIndex Persistence
- Power Management and Environmental Monitoring
- Configuring Web Cache Services Using WCCP
- Using the Top N Utility
- Using the Layer 2 Traceroute Utility
- Configuring Bidirectional Forwarding and Detection over Switched Virtual Interface
- Configuring Call Home
- Configuring IPv6 Policy Based Routing
- Using the Mini Protocol Analyzer
- Configuring Resilient Ethernet Protocol
- Configuring Synchronous Ethernet
- Configuring Link State Tracking
- Configuring BGP PIC Edge and Core for IP and MPLS
- Configuring VRF aware IPv6 tunnels over IPv4 transport
- ISIS IPv4 Loop Free Alternate Fast Reroute (LFA FRR)
- Multicast Service Reflection
- Y.1731 Performance Monitoring
- Online Diagnostic Tests
- Acronyms
- Cisco IOS Release 15S Software Images
- Index
- Understanding NSF with SSO Supervisor Engine Redundancy
- Supervisor Engine Configuration Synchronization
- NSF Configuration Tasks
- Configuring SSO
- Configuring Multicast MLS NSF with SSO
- Verifying Multicast NSF with SSO
- Configuring CEF NSF
- Verifying CEF NSF
- Configuring BGP NSF
- Verifying BGP NSF
- Configuring OSPF NSF
- Verifying OSPF NSF
- Configuring IS-IS NSF
- Verifying IS-IS NSF
- Configuring EIGRP NSF
- Verifying EIGRP NSF
- Synchronizing the Supervisor Engine Configurations
- Copying Files to the Redundant Supervisor Engine
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).

Note • For complete syntax and usage information for the commands used in this chapter, refer to the Cisco 7600 Series Routers Command References at this URL:
http://www.cisco.com/en/US/products/hw/routers/ps368/prod_command_reference_list.html
- NSF with SSO does not support IPv6 multicast traffic. However, for information about how to configure supervisor engine redundancy using route processor redundancy (RPR) and RPR+ (which does support IPv6 multicast traffic), see Chapter7, “Configuring RPR and RPR+ Supervisor Engine Redundancy”
- Release 12.2SR does not support single router mode (SRM) with SSO.
Understanding NSF with SSO Supervisor Engine Redundancy
These sections describe supervisor engine redundancy using NSF with SSO:
- NSF with SSO Supervisor Engine Redundancy Overview
- SSO Operation
- NSF Operation
- Cisco Express Forwarding
- Multicast MLS NSF with SSO
- Routing Protocols
- NSF Benefits and Restrictions
NSF with SSO Supervisor Engine Redundancy Overview

Note With a Supervisor Engine 720, if all of 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)
Post SRE release, the uplink ports are also enabled in dcef mode for RSP720-10G supervisor engine. The other supervisor engines continue to have the uplink ports disabled.
Cisco 7600 series routers 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. Cisco 7600 series routers also support route processor redundancy (RPR), route processor redundancy plus (RPR+). For information about these redundancy modes, see Chapter7, “Configuring RPR and RPR+ Supervisor Engine Redundancy”
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 router, 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 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.
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 MSFC 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 router 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 MSFC of the active supervisor engine, and they receive routing updates from their neighbor routers. Routing protocols do not run on the MSFC 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.
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
The IS-IS NSF feature offers two options when you configure NSF:
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.
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.

Note Effective with Cisco IOS Release 15.2(4)S, Cisco 7600 series routers support RFC 6213. If you configure IS-IS to use BFD on an interface, the BFD session must come up before the IS-IS adjacency comes up. If the BFD session is down, then the ISIS adjacency will not come up.
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.
NSF Benefits and Restrictions
Cisco NSF provides these benefits:
NSF continues forwarding network traffic and application state information so that user session information is maintained after a switchover.
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.
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).
Because SSO continues forwarding network traffic in the event of a switchover, routing flaps are avoided.
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.
- Enhanced Object Tracking is not SSO-aware and cannot be used with Hot Standby Routing Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP) in SSO mode.
- 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.
- The underlying unicast protocols must be NSF-aware in order to use multicast NSF with SSO.
- Starting from Release 12.2(33)SRE, bidirectional forwarding detection (BFD) is SSO-aware and is supported by NSF with SSO.
SSO-aware Virtual Router Redundancy Protocol
The Stateful Switchover (SSO) - aware Virtual Router Redundancy Protocol (VRRP) feature enables the Cisco IOS VRRP subsystem software detect the following:
- Installation of a standby Route Processor (RP)
- Configuration of the system in the SSO redundancy mode
In the event of an active RP failure, the VRRP group itself remains unchanged, and traffic continues to be forwarded through the current active gateway router. The SSO-aware VRRP feature preserves the forwarding path for traffic destined to VRRP virtual IP through an RP switchover. Configuring SSO on the edge router enables the traffic on the Ethernet links to continue during an RP failover: Ethernet traffic requires no switchover to another VRRP router. During a switchover, the synchronization of VRRP SSO information to the standby RP allows the continuous forwarding of the traffic that is sent with the VRRP virtual IP address without loss of data or path change.

Note The addition of SSO to the VRRP redundancy scheme provides high availability of gateway.
Supervisor Engine Configuration Synchronization
These sections describe supervisor engine configuration synchronization:
- Supervisor Engine Redundancy Guidelines and Restrictions
- Redundancy Configuration Guidelines and Restrictions

Note Configuration changes made through SNMP are not synchronized to the redundant supervisor engine. After you configure the router 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
These guidelines and restrictions apply to all redundancy modes:
- 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.
Post SRE release, the uplink ports are also enabled in dcef mode for RSP720-10G supervisor engine. The other supervisor engines continue to have the uplink ports disabled.s
- Supervisor engine redundancy does not provide supervisor engine mirroring or supervisor engine load balancing. Only one supervisor engine is active.
- Configuration changes made through SNMP are not synchronized to the redundant supervisor engine. After you configure the router 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.
- With a Supervisor Engine 720, 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 software running on the supervisor engine and the MSFC supports redundant configurations when the supervisor engines and MSFC routers are identical. If they are not identical, one will boot first and become active and hold the other supervisor engine and MSFC in a reset condition.
- Each supervisor engine must have the resources to run the router 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).

Note If a newly installed redundant supervisor engine has the Catalyst operating system installed, remove the active supervisor engine and boot the router 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.

Note There is no support for booting from the network.
Configuration Mode Restrictions
The following configuration restrictions apply during the startup synchronization process:
NSF Configuration Tasks
The following sections describe the configuration tasks for the NSF feature:
- Configuring SSO
- Configuring Multicast MLS NSF with SSO
- Verifying Multicast NSF with SSO
- Configuring CEF NSF
- Verifying CEF NSF
- Configuring BGP NSF
- Verifying BGP NSF
- Configuring OSPF NSF
- Verifying OSPF NSF
- Configuring IS-IS NSF
- Verifying IS-IS NSF
Configuring SSO
You must configure SSO in order to use NSF with any supported protocol. To configure SSO, perform this task:
Configures SSO. When this command is entered, the redundant supervisor engine is reloaded and begins to work in SSO mode. |
||
This example shows how to configure the system for SSO and display the redundancy state:
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:
Verifying Multicast NSF with SSO
To verify the multicast NSF with SSO settings, enter the show mls ip multicast sso command:
Configuring CEF NSF
The CEF NSF feature operates by default while the networking device is running in SSO mode. No configuration is necessary.
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 on each of the BGP NSF peer devices:
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:
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:
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.
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:
Step 2 Enter the show ip ospf command to verify that NSF is enabled on the device:
Configuring IS-IS NSF
To configure IS-IS NSF, perform this task:
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:
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”:
The following display shows sample output for the Cisco configuration on the standby RP. In this example, note the presence of “NSF restart enabled”:
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:
Configuring EIGRP NSF
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:
Step 2 Enter the show ip protocols command to verify that NSF is enabled on the device:
Copying Files to the Redundant Supervisor Engine
Enter this command to copy a file to the disk0: device on a redundant supervisor engine:
Enter this command to copy a file to the bootflash: device on a redundant supervisor engine:
Enter this command to copy a file to the bootflash: device on a redundant MSFC: