![]() |
IP Routing: EIGRP Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3850 Switches)
|
||||||||||||||||||||||||||
EIGRP Nonstop Forwarding Awareness
![]() |
|||||||||||||||||||||||||||
Contents
EIGRP Nonstop Forwarding AwarenessLast Updated: November 30, 2012
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.
Finding Feature InformationYour software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and 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 table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Prerequisites for EIGRP Nonstop Forwarding AwarenessThis module 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
Information About EIGRP Nonstop Forwarding Awareness
Cisco NSF Routing and Forwarding OperationCisco 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, EIGRP, 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 ForwardingA 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.
EIGRP Nonstop Forwarding AwarenessNSF 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, to maintain the peering session with this neighbor, to retain known routes, and to continue to forward packets for these routes. The deployment of EIGRP NSF awareness can minimize the effects 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.
EIGRP NSF-Capable and NSF-Aware InteroperationEIGRP 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 NeighborsNSF-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. EIGRP NSF TimersNSF/GR supports three types of timers: namely, signal timer, converge timer, and graceful-restart purge-time timer. The signal timer can be configured to adjust the maximum time of the initial restart period where the restarting router sends hello packets with the restart(RS)-bit set. When the timer expires, if the restarting router has not learnt about any neighbor, or has not learnt about any NSF-aware neighbor, or has not received all the updates from the neighbors, the routing information base is notified for convergence. The default value for the signal timer is 20 seconds. The timers nsf signal command is used to configure the signal timer. The converge timer can be configured to adjust the maximum time the restarting router waits for the end-of-table (EOT) indications from all the neighbors. The default value for the converge timer is 120 seconds. The timers nsf converge command is used to configure the converge timer. The graceful-restart purge-time timer can be configured to adjust the maximum waiting time to receive the convergent signal from the restarting router. The graceful-restart purge-timer is used when the NSF-aware peer does not receive the EOT indication from the restarting neighbor. When the graceful-restart purge-timer expires, the EIGRP peer scans the topology table for the stale routes from the restarting neighbor and changes the stale routes to active, thereby allowing EIGRP peers to find alternate routes instead of waiting during a long switchover operation. The default value for the graceful-restart purge-time timer is 240 seconds. The timers graceful-restart purge-time command is used to configure the graceful-restart purge-timer. The timers graceful-restart purge-time command is accepted under router configuration mode for IPv4 EIGRP classic mode and under address-family configuration mode for EIGRP named mode. How to Configure EIGRP Nonstop Forwarding Awareness
Enabling EIGRP Nonstop Forwarding AwarenessSUMMARY STEPS
DETAILED STEPS Modifying EIGRP Nonstop Forwarding Awareness Timers
SUMMARY STEPS
DETAILED STEPS Troubleshooting TipsNeighbor adjacencies are maintained during NSF switchover operations. If adjacencies between NSF-capable and NSF-aware neighbors are being reset too often, the graceful-restart purge-time timers may need to be adjusted. The show ip eigrp neighbor detail command can be used to help determine if the graceful-restart purge-time 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 the last time those specific neighbors have been restarted. Monitoring EIGRP NSF Debug Events and NotificationsUse 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 because 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. DETAILED STEPS Verifying the Local Configuration of EIGRP NSF AwarenessUse the following steps to verify the local configuration of NSF-awareness on a router that is running EIGRP: DETAILED STEPS Configuration Examples for EIGRP Nonstop Forwarding Awareness
Example: Monitoring EIGRP NSF Debug Events and Notifications ConfigurationThe 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 10.100.10.1,
00:00:00. Wait for EOT.
*Oct 4 11:39:18.092:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 2:Neighbor
10.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-restart
Example: Verifying Local Configuration of EIGRP NSF AwarenessThe 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 graceful-restart purge-time timer is set to 240 seconds, which is the default value.
Router# show ip protocols
*** IP Routing is NSF aware ***
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
Maximum path: 4
Routing for Networks:
10.4.9.0/24
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Additional References for EIGRP Nonstop Forwarding AwarenessRelated Documents
Technical Assistance
Feature Information for EIGRP Nonstop Forwarding AwarenessThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: 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. (1110R) 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. © 2012-2013 Cisco Systems, Inc. All rights reserved.
|
|||||||||||||||||||||||||||
|
|