Table Of Contents
Configuring Nonstop Forwarding
Finding Feature Information
Contents
Prerequisites for Nonstop Forwarding
Restrictions for Nonstop Forwarding
General Restrictions
BGP NSF Restrictions
EIGRP NSF Restrictions
OSPF NSF Restrictions
Cisco 7200 Series Router Restrictions
Information About Nonstop Forwarding
Nonstop Forwarding
Cisco NSF Routing and Forwarding
Routing Protocols and CEF Support in Cisco NSF
Cisco Express Forwarding and NSF
BGP NSF Operations
EIGRP NSF Operations
IPv6 support for NSF Operations
Nonstop Forwarding and Graceful Restart for MP-BGP IPv6 Address Family
Nonstop Forwarding for IPv6 RIP
Nonstop Forwarding for Static Routes
IS-IS NSF Operations
IETF IS-IS Configuration
Cisco IS-IS Configuration
OSPF NSF Operations
How to Configure Nonstop Forwarding
Configuring and Verifying BGP NSF
Configuring and Verifying EIGRP NSF
Configuring OSPF NSF
Configuring Cisco NSF for OSPF
Configuring IETF NSF for OSPF
Configuring and Verifying IS-IS NSF
Troubleshooting Nonstop Forwarding
Configuration Examples for Nonstop Forwarding
Example: NSF-Capable CEF
Example: BGP NSF
Example: EIGRP NSF
Example: OSPF and Cisco NSF
Example: OSPF and IETF NSF
Example: IS-IS NSF
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Feature Information for Nonstop Forwarding
Configuring Nonstop Forwarding
First Published: July 22, 2002
Last Updated: November 22, 2010
This module describes how to configure Nonstop Forwarding (NSF) in Cisco software to minimize the amount of time a network is unavailable to its users following a switchover. The main objective of NSF is to continue forwarding IP packets following a Route Processor (RP) switchover. NSF is supported by the BGP, EIGRP, IPv6, IS-IS, and OSPF protocols for routing and by CEF for forwarding.
The following terms are used throughout this document:
•
NSF-aware device—A device that is running NSF-compatible software
•
NSF-capable device—A device that is configured to support NSF. NSF-capable devices can rebuild routing information from either NSF-aware or NSF-capable neighboring devices.
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 Nonstop Forwarding" 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 Nonstop Forwarding
•
Restrictions for Nonstop Forwarding
•
Information About Nonstop Forwarding
•
How to Configure Nonstop Forwarding
•
Configuration Examples for Nonstop Forwarding
•
Additional References
•
Feature Information for Nonstop Forwarding
Prerequisites for Nonstop Forwarding
•
The networking device that is to be configured for NSF must first be configured for SSO. For informations, see Configuring Stateful Switchover.
•
For Border Gateway Protocol (BGP) NSF, all neighboring devices must be NSF-aware and must be configured for BGP graceful restart.
•
For Enhanced Interior Gateway Routing Protocol (EIGRP) NSF:
–
All neighboring devices must be NSF-capable or NSF-aware.
–
An NSF-aware device must be completely converged with the network before it can assist an NSF-capable device in an NSF restart operation.
•
For Internet Engineering Task Force (IETF) Intermediate System to Intermediate System (IS-IS), all neighboring devices must be NSF-aware.
•
For Open Shortest Path First (OSPF) NSF, all networking devices on the same network segment must be NSF-aware.
•
For IPv6 NSF, IPv6 must be enabled on your networking device.
•
On platforms supporting the Route Switch Processor (RSP), and where the Cisco Express Forwarding (CEF) switching mode is configurable, configure distributed CEF (dCEF) switching mode using the ip cef distributed command.
Restrictions for Nonstop Forwarding
•
General Restrictions
•
BGP NSF Restrictions
•
EIGRP NSF Restrictions
•
OSPF NSF Restrictions
•
Cisco 7200 Series Router Restrictions
General Restrictions
•
The Hot Standby Routing Protocol (HSRP) is not supported with Cisco NSF with SSO. Do not use HSRP with Cisco NSF with SSO.
•
NSF capability is not enabled by default for OSPF, ISIS, or BGP. NSF capability is enabled by default for EIGRP only.
BGP NSF Restrictions
•
BGP support in NSF requires that neighbor networking devices be NSF-aware. If an NSF-capable device 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.
•
All devices must be configured with the same type of NSF helper mode, either IETF graceful restart or Cisco NSF.
EIGRP NSF Restrictions
•
An NSF-aware device cannot support two NSF-capable peers performing an NSF restart operation at the same time. However, both neighbors will reestablish peering sessions after the NSF restart operation is complete.
•
Distributed platforms that run a supporting version of Cisco software can support full NSF capabilities. These devices can perform a restart operation and can support other NSF capable peers.
•
Single processor platforms that run a supporting version of Cisco software support only NSF awareness. These devices maintain adjacency and hold known routes for the NSF-capable neighbor until it signals that it is ready for the NSF-aware device to send its topology table or the route-hold timer expires.
OSPF NSF Restrictions
•
OSPF NSF for virtual links is not supported.
•
OSPF NSF for sham links is not supported.
•
OSPF NSF supports NSF/SSO for IPv4 traffic only.
•
OSPFv3 is not supported with NSF/SSO. Only OSPFv2 is supported with NSF/SSO.
•
All neighbor networking devices must be NSF-aware. If an NSF-capable device 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 devices will continue to provide NSF capabilities.
•
You can configure strict link state advertisement (LSA) checking on both NSF-aware and NSF-capable devices; however, it is effective only when the device is in helper mode.
Cisco 7200 Series Router Restrictions
•
The Cisco 7200 series router has a single CPU and cannot support the stateful switchover in the event of a network processor engine (NPE) fault.
•
The Cisco 7206 supports NSF and can operate in a peer role with a Cisco 7500, 10000, or 12000 series router running Cisco IOS Release 12.0(23)S or a later release. With NSF enabled, an RP switchover on the Cisco 7500, 10000, or 12000 series router peer should not cause a loss of PPP, ATM, high-level data link control (HDLC), or Frame Relay sessions, or a loss of any OSPF, BGP, or IS-IS adjacencies established between the Cisco 7200 and the peer.
Information About Nonstop Forwarding
•
Nonstop Forwarding
•
Cisco NSF Routing and Forwarding
•
Cisco Express Forwarding and NSF
•
BGP NSF Operations
•
EIGRP NSF Operations
•
IPv6 support for NSF Operations
•
IS-IS NSF Operations
•
OSPF NSF Operations
Nonstop Forwarding
Note
Throughout this document, the term Route Processor (RP) is used to describe the route processing engine on all networking devices, regardless of the platform designation, unless otherwise noted.
NSF works with the SSO feature in Cisco software to minimize the amount of time a network is unavailable to its users following a switchover. The main objective of NSF is to continue forwarding IP packets following an 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. NSF helps to suppress routing flaps in SSO-enabled devices, thus reducing network instability.
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 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 NSF operation.
The NSF feature provides the following benefits:
•
Improved network availability—NSF continues forwarding network traffic and application state information so that user session information is maintained after a switchover.
•
Overall network stability—Network stability may be improved with the reduction in the number of route flaps that had been created when devices in the network failed and lost their routing tables.
•
Neighboring devices do not detect link flapping—Because the interfaces remain up across a switchover, neighboring devices do not detect a link flap (that is, the link does not go down and come back up).
•
Prevents routing flaps—Because SSO continues forwarding network traffic in the event of a switchover, routing flaps are avoided.
•
No loss of user sessions—User sessions established prior to the switchover are maintained.
NSF always runs together with SSO. 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 (CEF; OSPF; BGP; and IS-IS) have been made to support the HA features in SSO.
Cisco NSF Routing and Forwarding
Cisco NSF is supported by the BGP, EIGRP, IPv6, IS-IS, and OSPF protocols for routing and by CEF for forwarding. Of the routing protocols, BGP, EIGRP, IPv6, IS-IS, and OSPF have been enhanced with NSF-capability and awareness, which means that devices 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.
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.
Routing Protocols and CEF Support in Cisco NSF
Table 1 lists the routing protocol and CEF support in Cisco NSF.
Table 1 Routing Protocol and CEF Support in Cisco NSF
Protocol
|
Platform
|
NSF Support in Cisco IOS Software Release
|
12.0(22)S
|
12.0(23)S
|
12.0(24)S
|
12.2(18)S
|
12.2(28)SB
|
12.2(33)SRA
|
BGP
|
Cisco 7200
|
Yes1
|
Yes1
|
Yes1
|
No2
|
No
|
No
|
Cisco 7304
|
No
|
No
|
No
|
No
|
Yes
|
No
|
Cisco 7500
|
Yes
|
Yes
|
Yes
|
Yes
|
No
|
No
|
Cisco 7600
|
No
|
No
|
No
|
No
|
No
|
Yes
|
Cisco 10000
|
Yes
|
Yes
|
Yes
|
No
|
Yes
|
No
|
Cisco 12000
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
OSPF
|
Cisco 7200
|
Yes1
|
Yes1
|
Yes1
|
No2
|
No
|
No
|
Cisco 7304
|
No
|
No
|
No
|
No
|
Yes
|
No
|
Cisco 7500
|
Yes
|
Yes
|
Yes
|
Yes
|
No
|
No
|
Cisco 7600
|
No
|
No
|
No
|
No
|
No
|
Yes
|
Cisco 10000
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
Cisco 12000
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
IS-IS
|
Cisco 7200
|
Yes1
|
Yes1
|
Yes1
|
No2
|
No
|
No
|
Cisco 7304
|
No
|
No
|
No
|
No
|
Yes
|
No
|
Cisco 7500
|
Yes
|
Yes
|
Yes
|
Yes
|
No
|
No
|
Cisco 7600
|
No
|
No
|
No
|
No
|
No
|
Yes
|
Cisco 10000
|
Yes
|
Yes
|
Yes
|
No
|
Yes
|
No
|
Cisco 12000
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
CEF
|
Cisco 72003
|
—
|
—
|
—
|
—
|
—
|
—
|
Cisco 7304
|
No
|
No
|
No
|
No
|
Yes
|
No
|
Cisco 7500
|
Yes
|
Yes
|
Yes
|
Yes
|
No
|
No
|
Cisco 7600
|
No
|
No
|
No
|
No
|
No
|
Yes
|
Cisco 10000
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
Cisco 12000
|
Yes
|
Yes
|
Yes
|
No
|
No
|
No
|
EIGRP
|
Cisco 7200
|
No
|
No
|
No
|
Yes2
|
No
|
No
|
Cisco 7304
|
No
|
No
|
No
|
No
|
Yes
|
No
|
Cisco 7500
|
No
|
No
|
No
|
Yes
|
No
|
No
|
Cisco 7600
|
No
|
No
|
No
|
No
|
No
|
Yes
|
Cisco 10000
|
No
|
No
|
No
|
No
|
No
|
No
|
Cisco 12000
|
No
|
No
|
No
|
No
|
No
|
No
|
Cisco Express Forwarding and NSF
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 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 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 devices. 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.
For NSF operation, the routing protocols depend on CEF to continue forwarding packets while the routing protocols rebuild the routing information. The CEF NSF feature operates by default while the networking device is running in SSO mode. No configuration is necessary.
BGP NSF Operations
When a NSF-capable device 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 device 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 RP switchover, the NSF-aware BGP peer marks all the routes associated with the NSF-capable device 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 device reestablishes the session with the BGP peer. In establishing the new session, it sends a new graceful restart message that identifies the NSF-capable device 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.
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 device 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.
EIGRP NSF Operations
EIGRP NSF capabilities are exchanged by EIGRP peers in hello packets. The NSF-capable device notifies its neighbors that an NSF restart operation has started by setting the restart (RS) bit in a hello packet. When an NSF-aware device receives notification from an NSF-capable neighbor that an NSF-restart operation is in progress, the NSF-capable and NSF-aware devices immediately exchange their topology tables. The NSF-aware device sends an end-of-table (EOT) update packet when the transmission of its topology table is complete. The NSF-aware device then performs the following actions to assist the NSF-capable device:
•
The EIGRP hello hold timer is expired to reduce the time interval set for hello packet generation and transmission. This allows the NSF-aware device to reply to the NSF-capable device more quickly reducing the amount of time required for the NSF-capable device to rediscover neighbors and rebuild the topology table.
•
The route-hold timer is started. This timer is used to set the period of time that the NSF-aware device will hold known routes for the NSF-capable neighbor.
•
The NSF-aware device 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 device to send its topology table or the route-hold timer expires. If the route-hold timer expires on the NSF-aware device, the NSF-aware device will discard held routes and treat the NSF-capable device as a new device joining the network and reestablishing adjacency accordingly.
•
The NSF-aware device will continue to send queries to the NSF-capable device that is still converging after switchover, effectively extending the time before a stuck-in-active (SIA) condition can occur.
When the switchover operation is complete, the NSF-capable device notifies its neighbors that it has reconverged and has received all of their topology tables by sending an EOT update packet to the assisting devices. The NSF-capable device then returns to normal operation. The NSF-aware device will look for alternate paths (go active) for any routes that are not refreshed by the NSF-capable (restarting device). The NSF-aware device will then return to normal operation. If all paths are refreshed by the NSF-capable device, the NSF-aware device will immediately return to normal operation.
NSF-aware devices 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 adjacencies and otherwise maintain the peering sessions normally.
IPv6 support for NSF Operations
•
Nonstop Forwarding and Graceful Restart for MP-BGP IPv6 Address Family
•
Nonstop Forwarding for IPv6 RIP
•
Nonstop Forwarding for Static Routes
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 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 the 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 fail-safe 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 modular and scalable, and supports multiple AFIs and subsequent address family identifier (SAFI) configurations.
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 NSF Operations
When an IS-IS NSF-capable device 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:
•
IETF IS-IS
•
Cisco IS-IS
If neighbor devices on a network segment are NSF-aware, meaning that neighbor devices are running a software version that supports the IETF Internet draft for device restartability, they will assist an IETF NSF device that is restarting. With IETF, neighbor devices 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.
If you configure IETF on the networking device, but neighbor devices are not IETF-compatible, NSF will abort following a switchover.
If the neighbor devices 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
With the IETF IS-IS configuration, the NSF-capable device sends IS-IS NSF restart requests to neighboring NSF-aware devices as quickly as possible after an RP switchover. Neighbor networking devices recognize this restart request as a cue that the neighbor relationship with this device should not be reset, but that they should initiate database resynchronization with the restarting device. As the restarting device receives restart request responses from devices 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
With the Cisco configuration option, full adjacency and link-state packet (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.
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. IS-IS NSF provides a command to extend the wait time for interfaces that, for whatever reason, do not come up in a timely fashion.
Following a switchover, Cisco IS-IS NSF has complete neighbor adjacency and LSP information; however, it must wait for all interfaces that had adjacencies prior to the switchover to come up. If an interface does not come up within the allocated interface wait time, the routes learned from these neighbor devices are not considered in routing table recalculation.
OSPF NSF Operations
Before an OSPF NSF-capable device can perform an RP switchover, it must relearn the available OSPF neighbors on the network, without resetting the neighbor relationship, and it must reacquire the contents of the Link State Database for the network.
To do this, the NSF-capable device sends an OSPF NSF signal to neighboring NSF-aware devices to notify the devices that the neighbor relationship with the sending device must not be reset. Then the NSF-capable device uses the signals it receives from other devices on the network to rebuild its neighbor list.
Next, the NSF-capable device resynchronizes its database with all of the NSF-aware neighbors on its list. After all of the neighbors exchange routing information, the NSF-capable device uses the routing information to remove stale routes, update the RIB, and update the FIB with the new forwarding information. Following that, the OSPF protocols are fully converged.
Prior to RFC 3623, Cisco implemented the proprietary Cisco NSF. The RFC 3623 Graceful OSPF Restart feature allows you to configure IETF NSF for OSPF processes in multivendor networks. The NSF device modes of operation common to the Cisco and IETF NSF implementations are as follows:
•
Restarting mode—In this mode, the OSPF device is performing nonstop forwarding recovery because of an RP switchover.
•
Helper mode—Also known as NSF-awareness. In this mode, the neighboring device is restarting and helping in the NSF recovery.
The strict LSA checking feature allows a helper device to terminate the graceful restart process if it detects a changed LSA that would cause flooding during the graceful restart process. Strict LSA checking is disabled by default. You can enable strict LSA checking when there is a change to an LSA that would be flooded to the restarting device.
How to Configure Nonstop Forwarding
•
Configuring and Verifying BGP NSF (reuired)
•
Configuring and Verifying EIGRP NSF (optional)
•
Configuring OSPF NSF (required)
•
Configuring and Verifying IS-IS NSF (required)
•
Troubleshooting Nonstop Forwarding (optional)
Configuring and Verifying BGP NSF
Repeat this procedure on each peer device.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router bgp autonomous-system-number
4.
bgp graceful-restart [restart-time seconds | stalepath-time seconds]
5.
end
6.
show ip bgp neighbors [ip-address [advertised-routes | dampened-routes | flap-statistics | paths [reg-exp] | received prefix-filter | received-routes | routes | policy [detail]]]
DETAILED STEPS
|
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
router bgp autonomous-system-number
Example:
Router(config)# router bgp 120
|
Enables a BGP routing process, and enters router configuration mode.
|
Step 4
|
bgp graceful-restart [restart-time seconds |
stalepath-time seconds]
Example:
Router(config-router)# bgp graceful-restart
|
Enables the BGP graceful restart capability, which starts NSF for BGP.
|
Step 5
|
end
Example:
Router(config-router)# end
|
Exits to privileged EXEC mode.
|
Step 6
|
show ip bgp neighbors [ip-address [advertised-routes |
dampened-routes | flap-statistics | paths [reg-exp] |
received prefix-filter | received-routes | routes |
policy [detail]]]
Example:
Router# show ip bgp neighbors
|
Displays information about BGP and TCP connections to neighbors.
|
Configuring and Verifying EIGRP NSF
Repeat this procedure on each peer device.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router eigrp as-number
4.
no nsf
5.
timers nsf converge seconds
6.
timers nsf signal seconds
In releases prior to Cisco IOS 12.2(33)SRE:
7.
timers nsf route-hold seconds
In Cisco IOS Release 12.2(33)SRE and later releases:
8.
timers graceful-restart purge-time seconds
9.
end
10.
show ip protocols
DETAILED STEPS
|
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
router eigrp as-number
Example:
Router(config)# router eigrp 109
|
Enables an EIGRP routing process, and enters router configuration mode.
|
Step 4
|
nsf
Example:
Router(config)# no nsf
|
(Optional) Enables NSF capabilities.
• This command is enabled by default.
|
Step 5
|
timers nsf converge seconds
Example:
Router(config-router)# timers nsf converge 120
|
(Optional) Adjusts the maximum time that the restarting device will wait for the EOT notification from an NSF-capable or NSF-aware peer.
• Enter this command on NSF-capable devices only.
|
Step 6
|
timers nsf signal seconds
Example:
Router(config-router)# timers nsf signal 20
|
(Optional) Adjusts the maximum time for the initial restart period.
• Enter this command on NSF-capable devices only.
|
Step 7
|
timers nsf route-hold seconds
Example:
Router(config-router)# timers nsf route-hold 240
|
(Optional) Sets the route-hold timer to determine how long an NSF-aware EIGRP device will hold routes for an inactive peer.
• This command is suported in releases before Cisco IOS 12.2(33)SRE.
|
Step 8
|
timers graceful-restart purge-time seconds
Example:
Router(config-router)# timers graceful-restart
purge-time 240
|
(Optional) Sets the route-hold timer to determine how long an NSF-aware EIGRP device will hold routes for an inactive peer.
• This command is supported in Cisco IOS Release 12.2(33)SRE and later releases.
|
Step 9
|
end
Example:
Router(config-router)# end
|
Exits to privileged EXEC mode.
|
Step 10
|
show ip protocols
Example:
Router# show ip protocols
|
Displays the parameters and current state of the active routing protocol process.
|
Configuring OSPF NSF
Perform only one of the following tasks:
•
Configuring Cisco NSF for OSPF
•
Configuring IETF NSF for OSPF
Configuring Cisco NSF for OSPF
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router ospf process-id [vrf vpn-name]
4.
nsf cisco [enforce-global]
5.
no nsf cisco helper disable
6.
nsf ietf helper disable
7.
end
8.
show ip ospf nsf
DETAILED STEPS
|
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
router ospf process-id [vrf vpn-name]
Example:
Router(config)# router ospf 12
|
Enables OSPF and enters router configuration mode.
|
Step 4
|
nsf cisco [enforce global]
Example:
Router(config-router)# nsf cisco
|
Enables Cisco NSF restarting mode.
• This command is not required on devices that will operate in NSF helper mode only.
|
Step 5
|
no nsf cisco helper disable
Example:
Router(config-router)# no nsf cisco helper disable
|
(Optional) Reeneables Cisco NFS helper support.
• This command is included here only to show how to reenable Cisco NSF helper mode if helper mode was explicitly disabled
|
Step 6
|
nsf ietf helper disable
Example:
Router(config-router)# nsf ietf helper disable
|
(Optional) Disables IETF NSF helper mode on an NSF-aware device.
|
Step 7
|
end
Example:
Router(config-router)# end
|
Exits to privileged EXEC mode.
|
Step 8
|
show ip ospf nsf
Example:
Router# show ip ospf nsf
|
Displays OSPF NSF state information
|
Configuring IETF NSF for OSPF
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router ospf process-id [vrf vpn-name]
4.
nsf ietf [restart-interval seconds]
5.
nsf ietf [helper [disable | strict-lsa-checking]]
6.
no nsf ietf helper disabl
7.
nsf cisco helper disable
8.
end
9.
show ip ospf nsf
DETAILED STEPS
|
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
router ospf process-id [vrf vpn-name]
Example:
Router(config)# router ospf 12
|
Enables OSPF and enters router configuration mode.
|
Step 4
|
nsf ietf [restart-interval seconds]
Example:
Router(config-router)# nsf ietf restart-interval 180
|
Enables IETF NSF restarting mode.
• This command is not required on devices that will operate in helper mode only.
|
Step 5
|
nsf ietf [helper [disable | strict-lsa-checking]]
Example:
Router(config-router)# nsf ietf helper
strict-lsa-checking
|
(Optional) Configures IETF NSF helper mode on neighbor devices that will operate in helper mode.
|
Step 6
|
no nsf ietf helper disable
Example:
Router(config-router)# no nsf ietf helper disable
|
(Optional) Reenables IETF NSF helper mode.
• This command is included here only to show how to reenable IETF NSF helper mode if helper mode was expliciltly disabled.
|
Step 7
|
nsf cisco helper disable
Example:
Router(config-router)# nsf cisco helper disable
|
(Optional) Disables Cisco NSF helper mode on an NSF-aware device.
|
Step 8
|
end
Example:
Router(config-router)# end
|
Exits to privileged EXEC mode.
|
Step 9
|
show ip ospf nsf
Example:
Router# show ip ospf nsf
|
Displays OSPF NSF state information
|
Configuring and Verifying IS-IS NSF
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
router isis area-tag
4.
nsf [cisco | ietf]
5.
nsf interval minutes
For IETF NSF only:
6.
nsf t3 {manual seconds | adjacency}
For Cisco NSF only:
7.
nsf interface wait seconds
8.
end
9.
show isis nsf
DETAILED STEPS
|
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
configure terminal
Example:
Router# configure terminal
|
Enters global configuration mode.
|
Step 3
|
router isis area-tag
Example:
Router(config)# router isis cisco1
|
Enables the IS-IS routing protocol to specify an IS-IS process and enters router configuration mode.
|
Step 4
|
nsf [cisco | ietf]
Example:
Router(config-router)# nsf ietf
|
Enables IS-IS NSF operations.
|
Step 5
|
nsf interval minutes
Example:
Router(config-router)# nsf interval 2
|
(Optional) Configures the minimum time between NSF restart attempts.
|
Step 6
|
nsf t3 {manual seconds | adjacency}
Example:
Router(config-router)# nsf t3 manual 40
|
(Optional) Specifies the methodology used to determine how long IETF NSF will wait for the link-state packet (LSP) database to synchronize before generating overloaded link-state information.
• This command is supported for IETF NSF only.
|
Step 7
|
nsf interface wait seconds
Example:
Router(config-router)# nsf interface wait 15
|
(Optional) Specifies how long a Cisco NSF restart will wait for all interfaces with IS-IS adjacencies to come up before completing the restart.
• This command is supported for Cisco NSF only.
|
Step 8
|
end
Example:
Router(config-router)# end
|
Exits to privileged EXEC mode.
|
Step 9
|
show isis nsf
Example:
Router# show isis nsf
|
Displays current state information regarding IS-IS NSF.
|
Troubleshooting Nonstop Forwarding
SUMMARY STEPS
1.
enable
2.
debug eigrp nsf
3.
debug ip eigrp notifications
4.
debug isis nsf [detail]
5.
debug ospf nsf [detail]
6.
show cef nsf
7.
show cef state
8.
show clns neighbors
9.
show ip bgp
10.
show ip bgp neighbor
11.
show ip cef
12.
show ip eigrp neighbors [interface-type | as-number | static | detail]
13.
show ip ospf
14.
show ip ospf neighbor [detail]
15.
show ip protocols
16.
show isis database [detail]
17.
show isis nsf
DETAILED STEPS
|
Command
|
Purpose
|
Step 1
|
enable
Example:
Router> enable
|
Enables privileged EXEC mode.
• Enter your password if prompted.
|
Step 2
|
debug eigrp nsf
Example:
Router# debug eigrp nsf
|
Displays notifications and information about NSF events for an EIGRP routing process.
|
Step 3
|
debug ip eigrp notifications
Example:
Router# debug ip eigrp notifications
|
Displays information and notifications for an EIGRP routing process. This output includes NSF notifications and events.
|
Step 4
|
debug isis nsf [detail]
Example:
Router# debug isis nsf [detail]
|
Displays information about the IS-IS state during a Cisco NSF restart.
|
Step 5
|
debug ospf nsf [detail]
Example:
Router# debug ospf nsf [detail]
|
Displays debugging messages related to OSPF Cisco NSF commands.
|
Step 6
|
show cef nsf
Example:
Router# show cef nsf
|
Displays the current NSF state of CEF on both the active and standby RPs.
|
Step 7
|
show cef state
Example:
Router# show cef state
|
Displays the CEF state on a networking device.
|
Step 8
|
show clns neighbors
Example:
Router# show clns neighbors
|
Display both end system and intermediate system neighbors.
|
Step 9
|
show ip bgp
Example:
Router# show ip bgp
|
Displays entries in the BGP routing table.
|
Step 10
|
show ip bgp neighbor
Example:
Router# show ip bgp neighbor
|
Displays information about the TCP and BGP connections to neighbor devices.
|
Step 11
|
show ip cef
Example:
Router# show ip cef
|
Displays entries in the FIB that are unresolved, or displays a FIB summary.
|
Step 12
|
show ip eigrp neighbors [interface-type | as-number |
static | detail]
Example:
Router# show ip eigrp neighbors detail
|
To display detailed information about neighbors discovered by EIGRP.
|
Step 13
|
show ip ospf
Example:
Router# show ip ospf
|
Displays general information about OSPF routing processes.
|
Step 14
|
show ip ospf neighbor [detail]
Example:
Router# show ip ospf neighbor [detail]
|
Displays OSPF-neighbor information on a per-interface basis.
|
Step 15
|
show ip protocols
Example:
Router# show ip protocols
|
Displays the parameters and current state of the active routing protocol process.
• The status of EIGRP NSF configuration and support is displayed in the output.
|
Step 16
|
show isis database [detail]
Example:
Router# show isis database [detail]
|
Displays the IS-IS link-state database.
|
Step 17
|
show isis nsf
Example:
Router# show isis nsf
|
Displays the current state information regarding IS-IS NSF.
|
Configuration Examples for Nonstop Forwarding
•
Example: NSF-Capable CEF
•
Example: BGP NSF
•
Example: EIGRP NSF
•
Example: OSPF and Cisco NSF
•
Example: OSPF and IETF NSF
•
Example: IS-IS NSF
Example: NSF-Capable CEF
The CEF NSF feature operates by default while the networking device is running in SSO mode. No configuration is necessary. The following sample output shows that CEF is NSF capable:
CEF switching enabled/running
CEF default capabilities:
Always FIB switching: yes
Default CEF switching: yes
Default dCEF switching: yes
Update HWIDB counters: no
Drop multicast packets: no
IPC delayed func on SSO: no
Example: BGP NSF
The following partial output shows the BGP configuration on the SSO-enabled device:
Router# show running-config
neighbor 10.2.2.2 remote-as 300
The following sample output shows that the graceful restart function is both advertised and received and that the address families have the graceful restart capability. If no address families were listed, then BGP NSF will not occur.
Router# show ip bgp neighbors 192.168.2.2
BGP neighbor is 192.168.2.2, remote AS YY, external link
BGP version 4, remote router ID 192.168.2.2
BGP state = Established, up for 00:01:18
Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds
Route refresh:advertised and received(new)
Address family IPv4 Unicast:advertised and received
Address family IPv4 Multicast:advertised and received
Graceful Restart Capabilty:advertised and received
Remote Restart timer is 120 seconds
Address families preserved by peer:
IPv4 Unicast, IPv4 Multicast
Received 1539 messages, 0 notifications, 0 in queue
Sent 1544 messages, 0 notifications, 0 in queue
Default minimum time between advertisement runs is 30 seconds
Example: EIGRP NSF
The following sample output shows that EIGRP NSF support is present in the installed software image.
•
"EIGRP NSF-aware route hold timer is..." is displayed in the output for either NSF-aware or NSF-capable devics, and displays the default or user-defined value for the route-hold timer.
•
"EIGRP NSF enabled," or "EIGRP NSF diasabled," appears in the output only when the NSF capability is supported by the device.
Router# show ip protocols
Routing Protocol is "eigrp 100"
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 100
EIGRP NSF-aware route hold timer is 240s
NSF converge timer is 120s
Automatic network summarization is in effect
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170
Example: OSPF and Cisco NSF
The following output from the show ip ospf nsf command shows that NSF is enabled for OSPF process 400. NSF helper mode is enabled by default on routers running NSF-compatible software. Note that in this configuration, IETF helper mode is disabled for process 400.
Routing Process "ospf 400"
Non-Stop Forwarding enabled
IETF NSF helper support disabled
Cisco NSF helper support enabled
OSPF restart state is NO_RESTART
Handle 2162698, Router ID 192.0.2.155, checkpoint Router ID 0.0.0.0
Config wait timer interval 10, timer not running
Dbase wait timer interval 120, timer not running
Example: OSPF and IETF NSF
The following output from the show ip ospf nsf command shows that NSF is enabled for OSPF process 500. NSF helper mode is enabled by default on routers running NSF-compatible software. Note that in this configuration, Cisco helper mode is disabled.
Routing Process "ospf 500"
Non-Stop Forwarding enabled
IETF NSF helper support enabled
Cisco NSF helper support disabled
OSPF restart state is NO_RESTART
Handle 1786466333, Router ID 192.0.2.2, checkpoint Router ID 0.0.0.0
Config wait timer interval 10, timer not running
Dbase wait timer interval 120, timer not running
Example: IS-IS NSF
The following partial output shows that this device uses the Cisco implementation of IS-IS NSF. The display will show either Cisco IS-IS or IETF IS-IS configuration.
Router# show running-config
In a Cisco NSF configuration, the display output is deifferent on the active and the standby RPs.
The following sample output on the active RP shows that Cisco NSF is enabled on the device:
NSF is ENABLED, mode 'cisco'
RP is ACTIVE, standby ready, bulk sync complete
NSF interval timer expired (NSF restart enabled)
Checkpointing enabled, no errors
Local state:ACTIVE, Peer state:STANDBY HOT, Mode:SSO
The following sample output on the standby RP shows that NSF is enabled on the device (NSF restart enabled):
NSF enabled, mode 'cisco'
RP is STANDBY, chkpt msg receive count:ADJ 2, LSP 7
NSF interval timer notification received (NSF restart enabled)
Checkpointing enabled, no errors
Local state:STANDBY HOT, Peer state:ACTIVE, Mode:SSO
The following sample output shows that IETF NSF is configured for the IS-IS networking device:
NSF is ENABLED, mode IETF
NSF L1 active interfaces:0
NSF interfaces awaiting L1 CSNP:0
NSF L2 active interfaces:0
NSF interfaces awaiting L2 CSNP:0
NSF L1 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
Interface:GigabitEthernet2/0/0
NSF L1 Restart state:Running
NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE
NSF L1 Restart state:Running
NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE
Additional References
Related Documents
Standards
Standard
|
Title
|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
|
—
|
MIBs
MIB
|
MIBs Link
|
No new or modified MIBs are supported, and support for existing MIBs has not been modified.
|
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
RFC
|
Title
|
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
Description
|
Link
|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
|
http://www.cisco.com/cisco/web/support/index.html
|
Feature Information for Nonstop Forwarding
Table 2 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 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
Table 2 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.
Table 2 Feature Information for Nonstop Forwarding
Feature Name
|
Releases
|
Feature Information
|
EIGRP Nonstop Forwarding (NSF) Awareness
|
12.2(18)S
|
NSF support for EIGRP allows an NSF-aware device that is running EIGRP to forward packets along routes known to a device performing a switchover operation or in a well-known failure condition.
The following sections provide information about this feature:
• EIGRP NSF Operations
• Configuring and Verifying EIGRP NSF
The following commands were introduced or modified: debug eigrp nsf, debug ip eigrp notifications, show ip eigrp neighbors, show ip protocols, timers graceful-restart purge-time, timers nsf route-hold.
|
MFIB: IPv4 SSO/ISSU
|
12.2(33)SRE
|
This feature was introduced.
|
Nonstop Forwarding Support for EIGRP
|
12.2(18)S 12.2(28)SB
|
NSF support for EIGRP allows an NSF-aware device that is running EIGRP to forward packets along routes known to a device performing a switchover operation or in a well-known failure condition.
The following sections provide information about this feature:
• EIGRP NSF Operations
• Configuring and Verifying EIGRP NSF
The following commands were introduced or modified: nsf (EIGRP), router eigrp, timers nsf converge, timers nsf signal.
|
NSF Awareness—OSPF
|
12.2(31)SB2 15.0(1)S
|
Allows customer premises equipment (CPE) devices to participate in the upstream device's NSF recovery process.
The following sections provide information about this feature:
• OSPF NSF Operations
• Configuring Cisco NSF for OSPF
The following commands were introduced or modified: debug ospf nsf, nsf (OSPF), nsf cisco, nsf ietf, show ip ospf neighbor, show ip ospf nsf.
|
NSF—OSPF (RFC 3623 OSPF Graceful Restart)
|
12.0(32)S 12.2(33)SRA 12.2(31)SB2 12.2(33)SXH
|
NSF for OSPFv2 in Cisco IOS software, using the IETF standardized graceful restart functionality as described in RFC 3623, was introduced.
The following sections provide information about this feature:
• OSPF NSF Operations
• Configuring Cisco NSF for OSPF
The following commands were introduced or modified: nsf cisco, nsf ietf, nsf (OSPF).
|
NSF—Graceful Restart (GR) and Non Stop Routing (NSR) for IS-IS Road/FIT
|
15.0(1)S
|
This feature is supported.
|
NSF/SSO (Nonstop Forwarding with Stateful Switchover)
|
12.0(22)S 12.0(23)S 12.0(24)S 12.2(20)S 15.0(1)S
|
This feature was introduced.
In Cisco IOS Release 12.0(23)S, support was added for 1xGE and 3xGE line cards on the
In Cisco IOS Release 12.0(24)S, support was added for the following line cards on the
• Engine 1
– 2-port OC-12/STM-4c DPT
• Engine 2
– 1-port OC-48/STM-16c DPT
– 8-port OC-3/STM-1c ATM
• IP Service Engine (ISE)
– 4-port OC-3c/STM-1c POS/SDH ISE
– 8-port OC-3c/STM-1c POS/SDH ISE
– 16-port OC-3c/STM-1c POS/SDH ISE
– 4-port OC-12c/STM-4c POS/SDH ISE
– 1-port OC-48c/STM-16c POS/SDH ISE
– 4-port channelized OC-12/STM-4 (DS3/E3, OC-3c/STM-1c) POS/SDH ISE
– 1-port channelized OC-48/STM-16 (DS3/E3, OC-3c/STM-1c) POS/SDH ISE
The following commands were introduced or modified: bgp graceful-restart, debug isis nsf, ip cef distributed, nsf (IS-IS), nsf interface wait, nsf interval, nsf t3, router bgp, router isis, router ospf, show cef nsf, show cef state, show clns neighbors, show ip bgp, show ip bgp neighbors, show ip cef, show ip eigrp neighbors, show ip protocols, show isis database, show isis nsf.
|
NSF/SSO—IPv4 Multicast
|
12.2(33)SRE 15.0(1)S
|
This feature was introduced.
|
NSF/SSO—IPv6 Multicast
|
12.2(33)SRE
|
This feature was introduced.
|
NSF/SSO—MPLS VPN
|
12.2(25)S 12.2(28)SB 12.2(33)SRA 12.2(33)SXH
|
This feature allows a provider edge (PE) router or Autonomous System Border Router (ASBR) (with redundant Route Processors) to preserve data forwarding information in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) when the primary Route Processor restarts.
In 12.2(25)S, this feature was introduced on the Cisco 7500 series router.
In 12.2(28)SB, support was added for the Cisco 10000 series routers.
In 12.2(33)SRA, support was added for the Cisco 7600 series routers.
|
NSF/SSO—Virtual Private LAN Services
|
12.2(33)SXI4 15.0(1)S
|
This feature was introduced.
|
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. 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-2010 Cisco Systems, Inc. All rights reserved.