Nonstop Forwarding For Ospf Version 2 - Cisco NCS 6000 Series Configuration Manual

Implementing OSPF

Nonstop Forwarding for OSPF Version 2

Notice that the wait interval between SPF calculations doubles when at least one topology change event is
received during the previous wait interval. After the maximum wait time is reached, the wait interval remains
the same until the topology stabilizes and no event is received in that interval.
If the first topology change event is received after the current wait interval, the SPF calculation is delayed by
the amount of time specified as the start interval. The subsequent wait intervals continue to follow the dynamic
pattern.
If the first topology change event occurs after the maximum wait interval begins, the SPF calculation is again
scheduled at the start interval and subsequent wait intervals are reset according to the parameters specified in
the timers throttle spf command. Notice in Figure 18: Timer Intervals Reset After Topology Change Event,
on page 271that a topology change event was received after the start of the maximum wait time interval and
that the SPF intervals have been reset.
Figure 18: Timer Intervals Reset After Topology Change Event
Nonstop Forwarding for OSPF Version 2
Cisco IOS XR Software NSF for OSPF Version 2 allows for the forwarding of data packets to continue along
known routes while the routing protocol information is being restored following a failover. With NSF, peer
networking devices do not experience routing flaps. During failover, data traffic is forwarded 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 Software 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 reestablished, 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.
Routing Configuration Guide for Cisco NCS 6000 Series Routers, IOS XR Release 6.4.x
271