Feedback
Table Of Contents
EIGRP Nonstop Forwarding (NSF) Awareness
Prerequisites for EIGRP Nonstop Forwarding Awareness
Restrictions for EIGRP Nonstop Forwarding Awareness
Information About EIGRP Nonstop Forwarding Awareness
Cisco NSF Routing and Forwarding Operation
EIGRP Nonstop Forwarding Awareness
EIGRP NSF Capable and NSF Aware Interoperation
How to Modify and Maintain EIGRP Nonstop Forwarding Awareness
Adjusting NSF Route-Hold Timers
Monitoring EIGRP NSF Debug Events and Notifications
Verifying the Local Configuration of EIGRP NSF Awareness
Configuration Examples for EIGRP Nonstop Forwarding Awareness
Example: EIGRP Graceful-Restart Purge-Time Timer Configuration
Example: Monitoring EIGRP NSF Debug Events and Notifications Configuration
Example: Verifying Local Configuration of EIGRP NSF Awareness
Feature Information for EIGRP Nonstop Forwarding (NSF) Awareness
EIGRP Nonstop Forwarding (NSF) Awareness
First Published: November 25, 2009Last Updated: November 25, 2009Nonstop Forwarding (NSF) awareness allows an NSF-aware router to assist NSF-capable and NSF-aware neighbors to continue forwarding packets during a switchover operation or during a well-known failure condition. The EIGRP Nonstop Forwarding Awareness feature allows an NSF-aware router that is running Enhanced Interior Gateway Routing Protocol (EIGRP) to forward packets along routes that are already known for a router that is performing a switchover operation or is in a well-known failure mode. This capability allows the EIGRP peers of the failing router to retain the routing information that is advertised by the failing router and continue to use this information until the failed router has returned to normal operating behavior and is able to exchange routing information. The peering session is maintained throughout the entire NSF operation.
Finding Feature Information
Your software release may not support all the features documented in this module. 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 EIGRP Nonstop Forwarding (NSF) Awareness" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for EIGRP Nonstop Forwarding Awareness
•
•
•
•
•
Prerequisites for EIGRP Nonstop Forwarding Awareness
This document assumes that your network is configured to run EIGRP. The following tasks must also be completed before you can configure this feature:
•
•
Restrictions for EIGRP Nonstop Forwarding Awareness
The following restrictions apply to the EIGRP Nonstop Forwarding Awareness feature:
•
•
Information About EIGRP Nonstop Forwarding Awareness
•
•
•
•
Cisco NSF Routing and Forwarding Operation
Cisco NSF is supported by the BGP, EIGRP, OSPF, and IS-IS protocols for routing and by Cisco Express Forwarding (CEF) for forwarding. Of the routing protocols, BGP, OSPF, and IS-IS 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 CEF to continue forwarding packets during switchover while the routing protocols rebuild the Routing Information Base (RIB) tables. Once the routing protocols have converged, CEF updates the FIB table and removes stale route entries. CEF, in turn, 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 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 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, CEF will keep the forwarding engine on the standby RP current with changes that are sent to it by CEF 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 for 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 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
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.
Note
EIGRP Nonstop Forwarding Awareness
NSF awareness allows a router that is running EIGRP to assist NSF-capable neighbors to continue forwarding packets during a switchover operation or well-known failure condition. The EIGRP Nonstop Forwarding Awareness feature provides EIGRP with the capability to detect a neighbor that is undergoing an NSF restart event (route processor [RP] switchover operation) or well-known failure condition, maintain the peering session with this neighbor, retain known routes, and continue to forward packets for these routes. The deployment of EIGRP NSF awareness can minimize the affects of the following:
•
•
•
EIGRP NSF awareness is enabled by default, and its operation is transparent to the network operator and EIGRP peers that do not support NSF capabilities.
Note
EIGRP NSF Capable and NSF Aware Interoperation
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.
Non-NSF Aware EIGRP Neighbors
NSF-aware routers are completely compatible with non-NSF aware or capable neighbors in an EIGRP network. A non-NSF aware neighbor will ignore NSF capabilities and reset the adjacency when they are received.
The NSF-capable router will drop any queries that are received while converging to minimize the number of transient routes that are sent to neighbors. But the NSF-capable router will still acknowledge these queries to prevent these neighbors from resetting adjacency.
Note
EIGRP NSF Route-Hold Timers
The route-hold timer is configurable so that you can tune network performance and avoid undesired effects, such as "black holing" routes if the switchover operation takes too much time. When this timer expires, the NSF-aware router scans the topology table and discards any stale routes, allowing EIGRP peers to find alternate routes instead of waiting during a long switchover operation.
The route-hold timer is configured with the timers nsf route-hold router configuration command. The default time period for the route-hold timer is 240 seconds. The configurable range is from 10 to 300 seconds.
How to Modify and Maintain EIGRP Nonstop Forwarding Awareness
•
•
•
Adjusting NSF Route-Hold Timers
Use the following steps to configure NSF route-hold timers on an NSF-aware router:
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Troubleshooting Tips
Neighbor adjacencies are maintained during NSF switchover operations. If adjacencies between NSF-capable and NSF-aware neighbors are being reset too often, the route-hold timers may need to be adjusted. The show ip eigrp neighbor detail command can be used to help determine if the route-hold timer value should be set to a longer time period. The output will display the time that adjacency is established with specific neighbors. This time will tell you if adjacencies are being maintained or reset and when the last time that specific neighbors have been restarted.
Monitoring EIGRP NSF Debug Events and Notifications
Use the following steps to monitor EIGRP NSF debug events and notifications on an NSF-aware router:
The debug eigrp nsf and debug ip eigrp notifications commands do not need to be issued together or even in the same session as there are differences in the information that is provided. These commands are provided together for example purposes.
The output of debug commands can be very verbose. These commands should not be deployed in a production network unless you are troubleshooting a problem.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying the Local Configuration of EIGRP NSF Awareness
Use the following steps to verify the local configuration of NSF-awareness on a router that is running EIGRP:
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuration Examples for EIGRP Nonstop Forwarding Awareness
•
•
•
Example: EIGRP Graceful-Restart Purge-Time Timer Configuration
The timers graceful-restart purge-time command is used to set the route-hold timer that determines how long an NSF-aware router that is running EIGRP will hold routes for an inactive peer. The following example shows how to set the route-hold timer to two minutes:
Router(config-router)# timers graceful-restart purge-time 120Example: Monitoring EIGRP NSF Debug Events and Notifications Configuration
The following example output shows that an NSF-aware router has received a restart notification. The NSF-aware router waits for EOT to be sent from the restarting (NSF-capable) neighbor.
Router# debug ip eigrp notifications*Oct 4 11:39:18.092:EIGRP:NSF:AS2. Rec RS update from 135.100.10.1,00:00:00. Wait for EOT.*Oct 4 11:39:18.092:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 2:Neighbor135.100.10.1 (POS3/0) is up:peer NSF restarted*Sep 23 18:49:07.578: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 1.1.2.1 (GigabitEthernet1/0/0) is resync: peer graceful-restartExample: Verifying Local Configuration of EIGRP NSF Awareness
The following is example output from the show ip protocols command. The output from this command can be used to verify the local configuration of the EIGRP NSF awareness. The output below shows that the router is NSF-aware and that the route-hold timer is set to 240 seconds, which is the default value for the route-hold timer.
Router# show ip protocols*** IP Routing is NSF aware ***Routing Protocol is "eigrp 101"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 101EIGRP NSF-aware route hold timer is 240sAutomatic network summarization is in effectMaximum path: 4Routing for Networks:10.4.9.0/24Routing Information Sources:Gateway Distance Last UpdateDistance: internal 90 external 170Additional References
Related Documents
Cisco IOS commands
CEF commands
EIGRP commands
Nonstop forwarding (NSF)
Cisco Nonstop Forwarding with Stateful Switchover Deployment Guide
Command Lookup Tool
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
Technical Assistance
Feature Information for EIGRP Nonstop Forwarding (NSF) Awareness
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which 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
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned 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. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2003-2010 Cisco Systems, Inc. All rights reserved.
