Table Of Contents
EIGRP Nonstop Forwarding (NSF) Awareness
Contents
Prerequisites for EIGRP Nonstop Forwarding Awareness
Restrictions for EIGRP Nonstop Forwarding Awareness
Information About EIGRP Nonstop Forwarding Awareness
Cisco NSF Routing and Forwarding Operation
Cisco Express Forwarding
EIGRP Nonstop Forwarding Awareness
EIGRP NSF Capable and NSF Aware Interoperation
Non-NSF Aware EIGRP Neighbors
EIGRP NSF Route-Hold Timers
How to Modify and Maintain EIGRP Nonstop Forwarding Awareness
Adjusting NSF Route-Hold Timers
Route-Hold Timers
Troubleshooting Tips
Monitoring EIGRP NSF Debug Events and Notifications
Debug Commands
Verifying the Local Configuration of EIGRP NSF Awareness
Configuration Examples for EIGRP Nonstop Forwarding Awareness
EIGRP Route-Hold Timer Configuration: Example
Monitoring EIGRP NSF Debug Events and Notifications Configuration: Example
Verifying Local Configuration of EIGRP NSF Awareness: Example
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Command Reference
EIGRP Nonstop Forwarding (NSF) Awareness
Nonstop 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.
History for the EIGRP Nonstop Forwarding (NSF) Awareness feature
Release
|
Modification
|
12.2(15)T
|
This feature was introduced.
|
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS 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
•
Restrictions for EIGRP Nonstop Forwarding Awareness
•
Information About EIGRP Nonstop Forwarding Awareness
•
How to Modify and Maintain EIGRP Nonstop Forwarding Awareness
•
Configuration Examples for EIGRP Nonstop Forwarding Awareness
•
Additional References
•
Command Reference
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:
•
An NSF-aware router must be up and completely converged with the network before it can assist an NSF-capable router in an NSF restart operation.
•
A version of Cisco IOS that support NSF awareness or NSF capabilities must be installed.
Restrictions for EIGRP Nonstop Forwarding Awareness
The following restrictions apply to the EIGRP Nonstop Forwarding Awareness feature:
•
All neighboring devices participating in EIGRP NSF must be NSF-capable or NSF-aware.
•
EIGRP NSF awareness does not support two neighbors performing an NSF restart operation at the same time. However, both neighbors will still reestablish peering sessions after the NSF restart operation is complete.
Information About EIGRP Nonstop Forwarding Awareness
To configure this feature, you must understand the following concepts:
•
Cisco NSF Routing and Forwarding Operation
•
Cisco Express Forwarding
•
EIGRP Nonstop Forwarding Awareness
•
EIGRP NSF Capable and NSF Aware Interoperation
•
Non-NSF Aware EIGRP Neighbors
•
EIGRP NSF Route-Hold Timers
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
For NSF operation, the routing protocols depend on CEF to continue forwarding packets while the routing protocols rebuild the routing information.
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:
•
Well-known failure conditions (for example, a stuck-in-active event).
•
Unexpected events (for example, an RP switchover operation).
•
Scheduled events (for example, a hitless software upgrade).
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
An NSF-aware router must be up and completely converged with the network before it can assist an NSF-capable router in an NSF restart operation.
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:
•
The router expires the EIGRP hello hold timer to reduce the time interval set for hello packet generation and transmission. This allows the NSF-aware router to reply to the NSF-capable router more quickly and reduces the amount of time required for the NSF-capable router to rediscover neighbors and rebuild the topology table.
•
The router starts the route-hold timer. This timer is used to set the period of time that the NSF-aware router will hold known routes for the NSF-capable neighbor. This timer is configured with the timers nsf route-hold command. The default time period is 240 seconds.
•
The router notes in the peer list that the NSF-capable neighbor is restarting, maintains adjacency, and holds known routes for the NSF-capable neighbor until the neighbor signals that it is ready for the NSF-aware router to send its topology table or the route-hold timer expires. If the route-hold timer expires on the NSF-aware router, the NSF-aware router will discard held routes and treat the NSF-capable router as a new router joining the network and reestablishing adjacency accordingly.
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
NSF-aware router will continue to send queries to the NSF-capable router which is still in the process of converging after switchover, effectively extending the time before a stuck-in-active (SIA) condition can occur.
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
This section contains the following procedures for configuring the EIGRP Nonstop Forwarding Awareness feature:
•
Adjusting NSF Route-Hold Timers
•
Monitoring EIGRP NSF Debug Events and Notifications
•
Verifying the Local Configuration of EIGRP NSF Awareness
Adjusting NSF Route-Hold Timers
Use the following steps to configure NSF route-hold timers on an NSF-aware router:
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.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router eigrp as-number
4.
timers nsf route-hold seconds
5.
exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
router eigrp autonomous-system-number
Example:
Router(config)# router eigrp 101
|
Enters router configuration mode and creates an EIGRP routing process.
|
Step 4
|
timers nsf route-hold seconds
Example:
Router(config-router)# timers nsf route-hold
120
|
Sets the maximum period of time that an NSF-aware router will hold known routes for an NSF-capable neighbor during a switchover operation. The configurable range of time for the seconds argument is from 20 to 300 seconds. The default value is 240 seconds. The example sets the route-hold timer to 2 minutes.
|
Step 5
|
exit
Example:
Router(config-router)# exit
|
Exits router configuration mode and enters global configuration mode.
|
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:
Debug Commands
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.
enable
2.
debug eigrp nsf
3.
debug eigrp ip notifications
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
debug eigrp nsf
Example:
Router# debug eigrp nsf
|
Displays NSF notifications and information about NSF events in an EIGRP network on the console of the router.
|
Step 3
|
debug ip eigrp notifications
Example:
Router# debug ip eigrp notifications
|
Displays EIGRP events and notifications in the console of the router. The output from this command also includes NSF notifications and information about NSF events.
|
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.
enable
2.
show ip protocols
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables higher privilege levels, such as privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
show ip protocols
Example:
Router# show ip protocols
|
Displays the parameters and current state of the active routing protocol process. The output of this command can be used to verify EIGRP NSF-awareness.
|
Configuration Examples for EIGRP Nonstop Forwarding Awareness
•
EIGRP Route-Hold Timer Configuration: Example
•
Monitoring EIGRP NSF Debug Events and Notifications Configuration: Example
•
Verifying Local Configuration of EIGRP NSF Awareness: Example
EIGRP Route-Hold Timer Configuration: 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(config-router)# timers nsf route-hold 120
Monitoring EIGRP NSF Debug Events and Notifications Configuration: Example
The following example output shows that the NSF-aware router has received the restart notification. The NSF-aware router will now wait for EOT to be sent from the restarting neighbor (NSF-capable).
Router# debug ip eigrp notifications
*Oct 4 11:39:18.092:EIGRP:NSF:AS2. Rec RS update from 135.100.10.1,
*Oct 4 11:39:18.092:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 2:Neighbor
135.100.10.1 (POS3/0) is up:peer NSF restarted
Verifying Local Configuration of EIGRP NSF Awareness: Example
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
Routing Protocol is "eigrp 101"
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
EIGRP maximum metric variance 1
Redistributing: eigrp 101
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Additional References
For additional information related to EIGRP Nonstop Forwarding Awareness feature, refer to the following references:
Related Documents
Standards
Standards
|
Title
|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
|
—
|
MIBs
MIBs
|
MIBs Link
|
No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.
|
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://www.cisco.com/go/mibs
|
RFCs
RFCs
|
Title
|
draft-ietf-idr-restart-06.txt
|
Graceful Restart Mechanism for BGP
|
Technical Assistance
Description
|
Link
|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.
To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.
|
http://www.cisco.com/techsupport
|
Command Reference
The following command was introduced or modified in the feature documented in this module. For information about these commands, see the Cisco IOS IP Routing Protocols Command Reference at http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_book.html. For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
•
debug eigrp nsf
•
debug ip eigrp notifications
•
show ip eigrp neighbors
•
show ip protocols
•
timers nsf route-hold
CCDE, CCVP, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, 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. (0801R)
Any Internet Protocol (IP) addresses 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.
© 2005 Cisco Systems, Inc. All rights reserved.