Filter
Top Products
Implementing OSPF on Cisco IOS XR Software
Information About Implementing OSPF on Cisco IOS XR Software
RC-188
Cisco IOS XR Routing Configuration Guide
OL-14356-01
through intelligent line cards while the standby Route Processor (RP) assumes control from the failed
RP. The ability of line cards to remain up through a failover and to be kept current with the Forwarding
Information Base (FIB) on the active RP is key to Cisco IOS XR NSF operation.
Routing protocols, such as OSPF, run only on the active RP or DRP and receive routing updates from
their neighbor routers. When an OSPF NSF-capable router performs an RP failover, it must perform two
tasks to resynchronize its link-state database with its OSPF neighbors. First, it must relearn the available
OSPF neighbors on the network without causing a reset of the neighbor relationship. Second, it must
reacquire the contents of the link-state database for the network.
As quickly as possible after an RP failover, the NSF-capable router sends an OSPF NSF signal to
neighboring NSF-aware devices. This signal is in the form of a link-local LSA generated by the
failed-over router. Neighbor networking devices recognize this signal as a cue that the neighbor
relationship with this router should not be reset. As the NSF-capable router receives signals from other
routers on the network, it can begin to rebuild its neighbor list.
After neighbor relationships are re-established, the NSF-capable router begins to resynchronize its
database with all of its NSF-aware neighbors. At this point, the routing information is exchanged
between the OSPF neighbors. After this exchange is completed, the NSF-capable device uses the routing
information to remove stale routes, update the RIB, and update the FIB with the new forwarding
information. OSPF on the router and the OSPF neighbors are now fully converged.
Graceful Restart for OSPFv3
In the current release, various restart scenarios in the control plane of an IPv6-enabled router can disrupt
data forwarding. The OSPFv3 Graceful Restart feature can preserve the data plane capability in the
following circumstances:
• RP failure, resulting in a switchover to the backup processor
• Planned OSPFv3 process restart, such as software upgrade or downgrade
• Unplanned OSPFv3 process restart, such as a process crash
This feature supports nonstop data forwarding on established routes while the OSPFv3 routing protocol
is restarting. (Therefore, this feature enhances high availability of IPv6 forwarding.)
Modes of Graceful Restart Operation
The two operational modes that a router can be in for this feature are restart mode and helper mode.
Restart mode occurs when the OSPFv3 process is doing a graceful restart. Helper mode refers to the
neighbor routers that continue to forward traffic on established OSPFv3 routes while OSPFv3 is
restarting on a neighboring router.
Restart Mode
When the OSPFv3 process starts up, it determines whether it must attempt a graceful restart. The
determination is based on whether graceful restart was previously enabled. (OSPFv3 does not attempt a
graceful restart upon the first-time startup of the router.) When OSPFv3 graceful restart is enabled, it
changes the purge timer in the RIB to a nonzero value. See Configuring OSPFv3 Graceful Restart,
page RC-230, for descriptions of how to enable and configure graceful restart.
During a graceful restart, the router does not populate OSPFv3 routes in the RIB. It tries to bring up full
adjacencies with the fully adjacent neighbors that OSPFv3 had before the restart. Eventually, the
OSPFv3 process indicates to the RIB that it has converged, either for the purpose of terminating the
graceful restart (for any reason) or because it has completed the graceful restart.