Table Of Contents
Prerequisites for Cisco Nonstop Forwarding
Restrictions for Cisco Nonstop Forwarding
Information About Cisco Nonstop Forwarding
Cisco Nonstop Forwarding Operation During RP Switchover
Cisco NSF Routing and Forwarding Overview
How to Configure Cisco Nonstop Forwarding
Troubleshooting Cisco Nonstop Forwarding
Configuration Examples for Cisco Nonstop Forwarding
Verifying that Cisco Express Forwarding Is NSF Capable: Example
Configuring BGP NSF Neighbor Device: Example
Configuring EIGRP NSF Converge Timer: Example
Configuring EIGRP NSF Route-Hold Timer: Example
Configuring EIGRP NSF Signal Timer: Example
Disabling EIGRP NSF Support: Example
Configuring IS-IS NSF: Example
Feature Information for Cisco Nonstop Forwarding
Cisco Nonstop Forwarding
First Published: July 22, 2002Last Updated: November 25, 2009Cisco Nonstop Forwarding (NSF) works with the Stateful Switchover (SSO) feature in Cisco IOS XE Software. NSF works with SSO to minimize the amount of time a network is unavailable to its users following a switchover. The main objective of Cisco NSF is to continue forwarding IP packets following a Route Processor (RP) switchover.
Finding Feature Information
For the latest feature information and caveats, see 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 for Cisco Nonstop Forwarding" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Cisco Nonstop Forwarding
•
•
•
•
•
Prerequisites for Cisco Nonstop Forwarding
•
•
Restrictions for Cisco Nonstop Forwarding
General Restrictions
•
BGP NSF
•
EIGRP NSF
•
•
OSPF NSF
•
•
•
IS-IS NSF
•
IPv6 NSF
•
Information About Cisco Nonstop Forwarding
Before you configure the NSF feature, you should understand the following concepts:
•
•
Note
Cisco Nonstop Forwarding Operation During RP Switchover
Cisco NSF works with the Stateful Switchover (SSO) feature in Cisco IOS XE Software. NSF works with SSO to minimize the amount of time a network is unavailable to its users following a switchover. The main objective of Cisco NSF is to continue forwarding IP packets following a Route Processor (RP) switchover.
Usually, when a networking device restarts, all routing peers of that device detect that the device went down and then came back up. This transition results in what is called a routing flap, which could spread across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities, which are detrimental to the overall network performance. Cisco NSF helps to suppress routing flaps in SSO-enabled devices, thus reducing network instability.
Cisco NSF allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored following a switchover. With Cisco NSF, peer networking devices do not experience routing flaps. Data traffic is forwarded through intelligent line cards or dual forwarding processors (FPs) while the standby RP assumes control from the failed active RP during a switchover. The ability of line cards and FPs to remain up through a switchover and to be kept current with the Forwarding Information Base (FIB) on the active RP is key to Cisco NSF operation.
NSF Dependency on SSO
Cisco NSF always runs together with SSO. This section provides some background information on the SSO feature.
In specific Cisco networking devices that support dual RPs, SSO establishes one of the RPs as the active processor while the other RP is designated as the standby processor, and then synchronizes information between them. A switchover from the active to the standby processor occurs when the active RP fails, is removed from the networking device, or is manually taken down for maintenance.
In networking devices running SSO, both RPs must be running the same configuration so that the standby RP is always ready to assume control following a fault on the active RP. The configuration information is synchronized from the active RP to the standby RP at startup and whenever changes to the active RP configuration occur. Following an initial synchronization between the two processors, SSO maintains RP state information between them, including forwarding information.
During switchover, system control and routing protocol execution is transferred from the active processor to the standby processor. The time required by the device to switch over from the active to the standby processor ranges from just a few seconds to approximately 30 seconds, depending on the platform.
SSO supported protocols and applications must be high-availability (HA)-aware. A feature or protocol is HA aware if it maintains, either partially or completely, undisturbed operation through an RP switchover. For some HA aware protocols and applications, state information is synchronized from the active to the standby processor. For Cisco NSF, enhancements to the routing protocols (Cisco Express Forwarding; Open Shortest Path First, or OSPF; Border Gateway Protocol, or BGP; and Intermediate System-to-Intermediate System, or IS-IS) have been made to support the HA features in SSO.
For more information on SSO, see the "How to Configure Cisco Nonstop Forwarding" section.
Cisco NSF Routing and Forwarding Overview
Cisco NSF is supported by the BGP, EIGRP, IPv6, IS-IS, and OSPF protocols for routing and by Cisco Express Forwarding for forwarding. Of the routing protocols, BGP, EIGRP, IPv6, IS-IS, and OSPF 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 standby RP to recover route information following a switchover instead of information received from peer devices.
In this document, a networking device is said to be NSF-aware if it is running NSF-compatible software. A device is said to be NSF-capable if it has been configured to support NSF; therefore, it would rebuild routing information from NSF-aware or NSF-capable neighbors.
Each protocol depends on Cisco Express Forwarding to continue forwarding packets during switchover while the routing protocols rebuild the Routing Information Base (RIB) tables. Once the routing protocols have converged, Cisco Express Forwarding updates the FIB table and removes stale route entries. Cisco Express Forwarding, in turn, updates the line cards with the new FIB information.
The following sections provides information about the following features:
Cisco Express Forwarding
A key element of NSF is packet forwarding. In a Cisco networking device, packet forwarding is provided by Cisco Express Forwarding. Cisco Express Forwarding 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, Cisco Express Forwarding on the active RP synchronizes its current FIB and adjacency databases with the FIB and adjacency databases on the standby RP. Upon switchover of the active RP, the standby RP initially has FIB and adjacency databases that are mirror images of those that were current on the active RP. For platforms with intelligent line cards, the line cards will maintain the current forwarding information over a switchover; for platforms with forwarding engines, Cisco Express Forwarding will keep the forwarding engine on the standby RP current with changes that are sent to it by Cisco Express Forwarding on the active RP. In this way, 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 in turn cause prefix-by-prefix updates to Cisco Express Forwarding, 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 RP 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.
Routing Protocols
The routing protocols run only on the active RP, and they receive routing updates from their neighbor routers. Routing protocols do not run on the standby RP. 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 standby RP to help rebuild the routing table on the NSF-capable device in environments where neighbor devices are not NSF-aware.
Note
BGP Operation
When a 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 declaration 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 peer(s) 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 RP 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 means that no packets are lost while the newly active RP is waiting for convergence of the routing information with the BGP peers.
After an RP 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. Once 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. Following that, the BGP protocol 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
EIGRP Operation
EIGRP NSF capabilities are exchanged by EIGRP peers in hello packets. The NSF-capable router notifies its neighbors that an NSF restart operation has started by setting the restart (RS) bit in a hello packet. When an NSF-aware router receives notification from an NSF-capable neighbor that an NSF-restart operation is in progress, the NSF-capable and NSF-aware routers immediately exchange their topology tables. The NSF-aware router sends an end-of-table (EOT) update packet when the transmission of its topology table is complete. The NSF-aware router then performs the following actions to assist the NSF-capable router:
•
•
•
•
When the switchover operation is complete, the NSF-capable router notifies its neighbors that it has reconverged and has received all of their topology tables by sending an EOT update packet to the assisting routers. The NSF-capable then returns to normal operation. The NSF-aware router will look for alternate paths (go active) for any routes that are not refreshed by the NSF-capable (restarting router). The NSF-aware router will then return to normal operation. If all paths are refreshed by the NSF-capable router, the NSF-aware router will immediately return to normal operation.
Note
IPv6 Operation
IPv6 support for NSF includes the following features:
•
•
•
Nonstop Forwarding and Graceful Restart for MP-BGP IPv6 Address Family
The graceful restart capability is supported for IPv6 BGP unicast, multicast, and VPNv6 address families, enabling Cisco nonstop forwarding (NSF) functionality for BGP IPv6. The BGP graceful restart capability allows the BGP routing table to be recovered from peers without keeping the TCP state.
NSF continues forwarding packets while routing protocols converge, therefore avoiding a route flap on switchover. Forwarding is maintained by synchronizing the FIB between the active and standby RP. On switchover, forwarding is maintained using the FIB. The RIB is not kept synchronized; therefore, the RIB is empty on switchover. The RIB is repopulated by the routing protocols and subsequently informs FIB about RIB convergence by using the NSF_RIB_CONVERGED registry call. The FIB tables are updated from the RIB, removing any stale entries. The RIB starts a failsafe timer during RP switchover, in case the routing protocols fail to notify the RIB of convergence.
The Cisco BGP address family identifier (AFI) model is designed to be modular and scalable, and to support multiple AFI and subsequent address family identifier (SAFI) configurations.
For information on how to configure the IPv6 BGP graceful restart capability, see the "Implementing Multiprotocol BGP for IPv6" document.
Nonstop Forwarding for IPv6 RIP
RIP registers as an IPv6 NSF client. Doing so has the benefit of using RIP routes installed in the Cisco Express Forwarding table until RIP has converged on the standby.
Nonstop Forwarding for Static Routes
Cisco NSF supports IPv6 static routes.
IS-IS Operation
When an IS-IS NSF-capable router performs an RP switchover, it must perform two tasks in order to resynchronize its Link State Database with its IS-IS neighbors. First, it must relearn the available IS-IS neighbors on the network without causing a reset of the neighbor relationship. Second, it must reacquire the contents of the Link State Database for the network.
The IS-IS NSF feature offers two options when configuring NSF:
•
•
If neighbor routers on a network segment are NSF-aware, meaning that neighbor routers are running a software version that supports the IETF Internet draft for router restartability, they will assist an IETF NSF router which 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 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 standby RP. A benefit of Cisco configuration is that it does not rely on NSF-aware neighbors.
IETF IS-IS Configuration
Using the IETF IS-IS configuration, as quickly as possible after an RP switchover, the NSF-capable router sends IS-IS NSF restart requests to neighboring NSF-aware devices. Neighbor networking devices recognize this restart request as a cue 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.
Once 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 RP 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 standby RP will boot up and synchronize its configuration with the active RP. 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 standby RP. Following a switchover, the newly active RP maintains its adjacencies using the checkpointed data, and can quickly rebuild its routing tables.
Note
The switchover from one RP 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 standby RP will boot up and synchronize its configuration with the active RP. Once this synchronization is completed, IS-IS adjacency and LSP data is checkpointed to the standby RP; 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.
OSPF Operation
When an OSPF NSF-capable router performs an RP switchover, it must perform two tasks in order to resynchronize its Link State Database with its OSPF neighbors. First, it must relearn the available OSPF neighbors on the network without causing a reset of the neighbor relationship. Second, it must reacquire the contents of the Link State Database for the network.
As quickly as possible after an RP switchover, the NSF-capable router sends an OSPF NSF signal to neighboring NSF-aware devices. Neighbor networking devices recognize this signal as a cue 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.
Once 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
The OSPF RFC 3623 graceful restart feature allows you to configure IETF NSF in multivendor networks. For more information, see OSPF RFC 3623 Graceful Restart.
Benefits of Cisco NSF
The Cisco NSF feature has several benefits, including the following:
•
•
•
•
•
How to Configure Cisco Nonstop Forwarding
These sections describe how to configure Cisco Nonstop Forwarding:
•
•
•
•
•
•
•
•
•
•
Verifying CEF NSF
The CEF NSF feature operates by default while the networking device is running in SSO mode. No configuration is necessary.
The following task explains how to verify that Cisco Express Forwarding is NSF-capable.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuring BGP NSF
The following task explains how to configure BGP for NSF. Repeat this task on each of the BGP NSF peer devices.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Verifying BGP NSF
To verify NSF for BGP, you must check that the graceful restart function is configured on the SSO-enabled networking device and on the neighbor devices. The following task explains how to perform this function.
SUMMARY STEPS
1.
2.
3.
paths [reg-exp] | received prefix-filter | received-routes | routes | policy [detail]]]DETAILED STEPS
Configuring EIGRP NSF
EIGRP NSF support is enabled by default. Distributed platforms that run a supporting version of Cisco IOS XE Software can support full NSF capabilities. These routers can perform a restart operation and can support other NSF capable peers. Single processor platforms that run a supporting version of Cisco IOS XE Software support only NSF awareness. These routers maintain adjacency and hold known routes for the NSF-capable neighbor until it signals that it is ready for the NSF-aware router to send its topology table or the route-hold timer expires.
Note
The following task explains how to configure EIGRP for NSF. Repeat this procedure on each of the EIGRP NSF peer devices.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Verifying EIGRP NSF
To verify NSF for EIGRP, you must check that NSF awareness and/or capability is enabled on the SSO-enabled networking device and on the neighbor devices. The following task explains how to perform this function.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuring OSPF NSF
Note
The following task explains how to configure OSPF for NSF.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Verifying OSPF NSF
The following task explains how to verify OSPF for NSF.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuring IS-IS NSF
The following task describes how to configure NSF for IS-IS.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Verifying IS-IS NSF
To verify NSF for IS-IS, you must check that the NSF function is configured on the SSO-enabled networking device. The following task describes how to verify NSF for IS-IS.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Troubleshooting Cisco Nonstop Forwarding
To troubleshoot Cisco Nonstop Forwarding, use the following commands as needed.
SUMMARY STEPS1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
DETAILED STEPS
Configuration Examples for Cisco Nonstop Forwarding
This section provides the following configuration examples:
•
•
•
•
•
•
•
•
Verifying that Cisco Express Forwarding Is NSF Capable: Example
The following example is used to verify that Cisco Express Forwarding is NSF capable:
Router# show cef stateCEF Status [RP]CEF enabled/runningdCEF enabled/runningCEF switching enabled/runningCEF default capabilities:Always FIB switching: yesDefault CEF switching: yesDefault dCEF switching: yesUpdate HWIDB counters: noDrop multicast packets: noCEF NSF capable: yesIPC delayed func on SSO: noRRP state:I am standby RRP: noMy logical slot: 0RF PeerComm: noConfiguring BGP NSF: Example
The following example configures BGP NSF on a networking device:
Router# configure terminalRouter(config)# router bgp 590Router(config-router)# bgp graceful-restartConfiguring BGP NSF Neighbor Device: Example
The following example configures BGP NSF on a neighbor router. All devices supporting BGP NSF must be NSF-aware, meaning that these devices recognize and advertise graceful restart capability.
Router# configure terminalRouter(config)# router bgp 770Router(config-router)# bgp graceful-restartVerifying BGP NSF: Example
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-configrouter bgp 120bgp graceful-restartneighbor 10.2.2.2 remote-as 300On 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.xBGP neighbor is 192.168.2.2, remote AS YY, external linkBGP version 4, remote router ID 192.168.2.2BGP state = Established, up for 00:01:18Last read 00:00:17, hold time is 180, keepalive interval is 60 secondsNeighbor capabilities:Route refresh:advertised and received(new)Address family IPv4 Unicast:advertised and receivedAddress family IPv4 Multicast:advertised and receivedGraceful Restart Capabilty:advertised and receivedRemote Restart timer is 120 secondsAddress families preserved by peer:IPv4 Unicast, IPv4 MulticastReceived 1539 messages, 0 notifications, 0 in queueSent 1544 messages, 0 notifications, 0 in queueDefault minimum time between advertisement runs is 30 secondsConfiguring EIGRP NSF Converge Timer: Example
The timers nsf converge command is used to adjust the maximum time that restarting router will wait for the EOT notification from an NSF-capable or NSF-aware peer. The following example sets the converge timer to 1 minute:
Router# configure terminalRouter(config)# router eigrp 101Router(config-router)# timers nsf converge 60Configuring EIGRP NSF Route-Hold Timer: Example
The timers nsf route-hold command is used to set the maximum period of time that an NSF-aware router will hold known routes for an NSF-capable neighbor during a switchover operation. The following example sets the route-hold timer to 2 minutes:
Router# configure terminalRouter(config)# router eigrp 101Router(config-router)# timers nsf route-hold 120Configuring EIGRP NSF Signal Timer: Example
The timers nsf signal command is used to adjust the maximum time for the initial restart period. The following example sets the signal timer to 10 seconds:
Router# configure terminal
Router(config)# router eigrp 101
Router(config-router)# timers nsf signal 10
Verifying EIGRP NSF: Example
Verify that EIGRP NSF support is present in the installed Cisco IOS XE Software image by entering the show ip protocols command. "EIGRP NSF-aware route hold timer is..." is displayed in the output when either NSF awareness or capability is supported by the router. This line displays the default or user-defined value for the route-hold timer. "EIGRP NSF..." is displayed in the output only when the NSF capability is supported by the router. This line will also print "disabled" or "enabled" depending on the status of the EIGRP NSF feature.
Router# show ip protocolsRouting Protocol is "eigrp 100"Outgoing update filter list for all interfaces is not setIncoming update filter list for all interfaces is not setDefault networks flagged in outgoing updatesDefault networks accepted from incoming updatesEIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0EIGRP maximum hopcount 100EIGRP maximum metric variance 1Redistributing: eigrp 100EIGRP NSF-aware route hold timer is 240sEIGRP NSF enabledNSF signal timer is 20sNSF converge timer is 120sAutomatic network summarization is in effectMaximum path: 4Routing for Networks:10.4.9.0/24Routing Information Sources:Gateway Distance Last UpdateDistance: internal 90 external 170Disabling EIGRP NSF Support: Example
EIGRP NSF capability is enabled by default on distributed platforms that run a supporting version of Cisco IOS XE Software. The nsf command used to enable or disable the EIGRP NSF capability. The following example disables NSF capability:
Router# configure terminalRouter(config)# router eigrp 101Router(config-router)# no nsfConfiguring OSPF NSF: Example
The following example configures OSPF NSF on a networking device:
Router# configure terminalRouter(config)# router ospf 400Router(config-router)# nsfVerifying OSPF NSF: Example
To verify NSF for OSPF, you must check that the NSF function is configured on the SSO-enabled networking device. Verify that "nsf" appears in the OSPF configuration of the SSO-enabled device by entering the show running-config command:
Router# show running-configrouter ospf 120log-adjacency-changesnsfnetwork 192.168.20.0 0.0.0.255 area 0network 192.168.30.0 0.0.0.255 area 1network 192.168.40.0 0.0.0.255 area 2Next, use the show ip ospf command to verify that NSF is enabled on the device.
Router> show ip ospfRouting Process "ospf 1" with ID 192.168.2.1 and Domain ID 0.0.0.1Supports only single TOS(TOS0) routesSupports opaque LSASPF schedule delay 5 secs, Hold time between two SPFs 10 secsMinimum LSA interval 5 secs. Minimum LSA arrival 1 secsNumber of external LSA 0. Checksum Sum 0x0Number of opaque AS LSA 0. Checksum Sum 0x0Number of DCbitless external and opaque AS LSA 0Number of DoNotAge external and opaque AS LSA 0Number of areas in this router is 1. 1 normal 0 stub 0 nssaExternal flood list length 0Non-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 authenticationSPF algorithm executed 3 timesConfiguring IS-IS NSF: Example
The following example configures Cisco proprietary IS-IS NSF operation on a networking device:
Router# configure terminalRouter(config)# router isisRouter(config-router)# nsf ciscoThe following example configures IS-IS NSF for IETF operation on a networking device:
Router# configure terminalRouter(config)# router isisRouter(config-router)# nsf ietfVerifying IS-IS NSF: Example
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 Cisco IS-IS or IETF IS-IS configuration. The following example indicates that the device uses the Cisco implementation of IS-IS NSF:
Router# show running-configrouter isisnsf ciscoIf the NSF configuration is set to cisco, use 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 standby RPs. The following example shows output for the Cisco configuration on the active RP. In this example, note the presence of the phrase "NSF restart enabled":
Router# show isis nsfNSF is ENABLED, mode 'cisco'RP is ACTIVE, standby ready, bulk sync completeNSF interval timer expired (NSF restart enabled)Checkpointing enabled, no errorsLocal state:ACTIVE, Peer state:STANDBY HOT, Mode:SSOThe following example shows sample output for the Cisco configuration on the standby RP. In this example, note the presence of the phrase "NSF restart enabled":
Router# show isis nsfNSF enabled, mode 'cisco'RP is STANDBY, chkpt msg receive count:ADJ 2, LSP 7NSF interval timer notification received (NSF restart enabled)Checkpointing enabled, no errorsLocal state:STANDBY HOT, Peer state:ACTIVE, Mode:SSOThe following example shows sample output for the IETF IS-IS configuration on the networking device:
Router# show isis nsfNSF is ENABLED, mode IETFNSF pdb state:InactiveNSF L1 active interfaces:0NSF L1 active LSPs:0NSF interfaces awaiting L1 CSNP:0Awaiting L1 LSPs:NSF L2 active interfaces:0NSF L2 active LSPs:0NSF interfaces awaiting L2 CSNP:0Awaiting L2 LSPs:Interface:Serial3/0/2NSF L1 Restart state:RunningNSF p2p Restart retransmissions:0Maximum L1 NSF Restart retransmissions:3L1 NSF ACK requested:FALSEL1 NSF CSNP requested:FALSENSF L2 Restart state:RunningNSF p2p Restart retransmissions:0Maximum L2 NSF Restart retransmissions:3L2 NSF ACK requested:FALSEInterface:GigabitEthernet2/0/0NSF L1 Restart state:RunningNSF L1 Restart retransmissions:0Maximum L1 NSF Restart retransmissions:3L1 NSF ACK requested:FALSEL1 NSF CSNP requested:FALSENSF L2 Restart state:RunningNSF L2 Restart retransmissions:0Maximum L2 NSF Restart retransmissions:3L2 NSF ACK requested:FALSEL2 NSF CSNP requested:FALSEInterface:Loopback1NSF L1 Restart state:RunningNSF L1 Restart retransmissions:0Maximum L1 NSF Restart retransmissions:3L1 NSF ACK requested:FALSEL1 NSF CSNP requested:FALSENSF L2 Restart state:RunningNSF L2 Restart retransmissions:0Maximum L2 NSF Restart retransmissions:3L2 NSF ACK requested:FALSEL2 NSF CSNP requested:FALSEAdditional References
The following sections provide references related to the Cisco Nonstop Forwarding feature.
Related Documents
High availability commands: complete command syntax, command mode, defaults, usage guidelines, and examples
Stateful switchover
"Stateful Switchover," Cisco IOS XE High Availability Configuration Guide
Configuring the IPv6 BGP graceful restart capability
"Implementing Multiprotocol BGP for IPv6," Cisco IOS XE IPv6 Configuration Guide
Information about IPv6 RIP
"Implementing RIP for IPv6," Cisco IOS XE IPv6 Configuration Guide
Information about IPv6 static routes
"Implementing Static Routes for IPv6," Cisco IOS XE IPv6 Configuration Guide
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
RFC 3623
Graceful OSPF Restart
RFC 3847
Restart Signaling for Intermediate System to Intermediate System (IS-IS)
RFC 4781
Graceful Restart Mechanism for BGP
Technical Assistance
Feature Information for Cisco Nonstop Forwarding
Table 1 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE Software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2002-2009 Cisco Systems, Inc. All rights reserved.
