Home Network Layer OSPF Version 2 OSPF Graceful Restart: Operation & Configuration on Cisco IOS

OSPF Graceful Restart: Operation & Configuration on Cisco IOS

OSPF graceful restart, also known as OSPF non-stop forwarding (NSF), is an amazing feature of the OSPF routing protocol. When enabled on a particular OSPF node, it restarts the OSPF process while the router continues to forward traffic, without disrupting existing OSPF neighbor relationships and without flushing/updating any LSAs. OSPF software reloads without disrupting network traffic.

In this tutorial, you will learn how the OSPF graceful restart feature, as described in RFC 3623, works and how to configure it in Cisco IOS. I will use the following network diagram. The routing domain consists of four routers. all router interfaces are placed in area 0.

What is OSPF Graceful Restart?

OSPF graceful restart is a feature that allows a router to reload/restart the OSPF process while the OSPF router is still acting as a transit node on the forwarding paths to destinations in the routing domain without interrupting network traffic. OSPF graceful restart is documented in RFC 3623.

The restarting router accomplishes this by sending link-local Opaque LSAs, also called Grace LSAs, to its OSPF adjacent neighbors in order to inform them about its intention to reload the OSPF software and not be ready to send or receive any OSPF updates for a period of time, the grace period.

Over the course of the grace period, the restarting router’s neighbors, called helper neighbors, are operating in helper mode; they behave as if they have full neighbor relationships with the router and include it in their LSAs as long as OSPF LSA types 1, 2, 3, 4, 5, and 7 are not altered and periodic LSA refreshes are enabled.

The grace timer should be less than 1800 seconds, the maximum LSA refresh interval, so that the routers do not interrupt the reboot process.

How Does OSPF Graceful Restart Work?

Before continuing, the restarting router refers to a router intended to reload an OSPF instance, not a router that is not going to perform a reload operation of its operating system.

To understand how OSPF non-stop forwarding performs, you need to know what the restarting router and helper neighbors do during the grace period, the duration between the time when you enable this feature and the time when OSPF finishes reloading.

Operation of Restarting Router

In general, the restarting router does not produce any OSPF traffic during the grace period. After the grace period expires, it rebuilds full neighbor relationships with its previous adjacent neighbors (OSPF nodes with which it reaches full state).

What is Happening During an OSPF Graceful Restart

Over the course of the grace period:

  • The other routers, neighbor helpers, compute their SPT trees based on the LSAs in their OSPF databases, including the LSAs originated by the restarting router before its restart since it does not originate any types 1, 2, 3, 4, 5, and 7 LSAs while it is restarting.
  • The restarting router delays processing received self-originated LSAs until the router exits graceful restart. In fact, during the graceful restart operation, it considers received self-originated LSAs, including the grace-LSAs, as valid and it does not change or flush them. This way, those LSAs stay stored in other routers’ OSPF databases while the router’s OSPF software is restarting.
  • The restarting router does not add any new OSPF routes to the routing table, although it does run the SPF algorithm during the grace period. However, computing the SPF tree is required to make each OSPF virtual link functional again.
  • The restarting router uses the forwarding entries it installed before the restart to process incoming or IP packets.
  • If the restarting router receives a Hello packet, in which it is listed as the designated router, on an interface that is in the waiting state, it assumes that it was the designated router on that interface before the graceful restart and it re-elects itself as the designated router.

Entering Graceful Restart

An OSPF-enabled router running Cisco IOS starts preparing for a graceful restart, as it is documented in RFC 3623, once you issue the nsf ietf command. You can set the grace time period or let OSPF choose the default one, which is 2 minutes.

LSRefreshTime, the LSA refresh interval, is 1800 seconds. If the grace period is greater than 1800 seconds, it would age out the restarting router’s LSAs, thus breaking the graceful restart. Therefore, RFC 3623 recommends that you set the restart interval to up to 1800 seconds (LSRefreshTime).

Before restarting/reloading the OSPF software, the restarting router executes these actions:

  1. Ensure that it has enough routing information in order to redirect network traffic while OSPF is being reloaded.
  2. Make sure to not shut down the OSPF software as this would disrupt traffic sent to the router by its OSPF neighbors which are supposing that the restarting router is still up and running.

To notify neighboring routers of the graceful restart, the restarting router generates a grace LSA for each OSPF interface. The flooding scope of each grace LSA is the network link of its corresponding interface.

A grace LSA is a link-local Opaque LSA (LSA type 9), and unlike other OSPF LSA types such as router and network LSAs, it is not flooded outside of the link to which it is associated. In other words, when a neighbor receives a Grace LSA, it can only forward it through the interface on which the LSA was received.

Additionally, grace LSAs include the requested grace period and an LS age of 0. The restarting router keeps retransmitting grace LSAs until they are all acknowledged before reloading the OSPF software. If one router does not confirm the reception of a grace LSA, the OSPF graceful restart process fails and OSPF won’t get restarted.

Exiting Graceful Restart

OSPF graceful restart is stopped when one of the events below takes place:

  1. The restarting router has rebuilt all the adjacencies it has before reloading OSPF. To achieve this, the router uses the last versions of the router and network LSAs in its LSDB, including self-originated ones and those received from helper neighbors. The network LSAs are examined to form OSPF neighbor relationships on the links on which the router was elected Designated Router before OSPF graceful restart.
  2. The restarting router receives a different copy of a router LSA stored in the OSFP database. This may mean that the originating router of the router LSA does not support helper mode, has canceled its helper mode, or has not received a grace LSA (it is unaware of the graceful restart).
  3. The graceful restart interval expires.

Regardless of whether the OSPF graceful restart process succeeds or fails, the restarting router performs the following steps when it completes a graceful restart:

  1. The router re-originates its router LSA for each OSPF area to which it is connected.
  2. The router re-originates network LSAs for network links where it is the designated router.
  3. The router runs the SPF algorithm to compute a new SPF tree, generates the necessary Type 3, Type 5, and Type 7 LSAs, and updates the forwarding tables.
  4. The router removes invalid entries in the forwarding tables and flushes grace LSAs and invalid self-originated LSAs.

Overall, the restarting router returns to normal OSPF operation after completing a graceful restart.

Operation of Helper Neighbor

Entering Helper Mode

When an OSPF router receives a grace LSA on a particular interface from the restarting router, the neighbor enters helper mode on that interface if all the conditions below are met:

  • Helper mode is enabled.
  • The helper router has a full OSPF neighbor relationship with the restarting router through the interface on which it received grace LSAs.
  • LSA Types 1,2,3,4,5, and 7, stored in the helper router’s LSDB, did not change since OSPF graceful got started. If there are LSAs that have to be retransmitted to the restarting router whose contents have been modified, the neighbor router would refuse to enter helper mode.
  • The grace period is not expired yet.
  • Local policy is allowing the neighbor router to enter helper for the restarting router.
  • The neighboring router’s OSPF software should not be restarting gracefully at this time.

Exiting Helper Mode

When the helper router ceases the helper mode for the restarting router, it re-originates its router LSA for the network link’s area connecting it to the restarting router. The network link could be a physical connection or an OSPF virtual link.

Additionally, the help router is the designated router on the network segment shared with the restarting router, it would re-originate the network LSA for that segment.

The helper Router exists the helper mode for the restarting router on a particular interface if one of these events happens:

  • The grace LSA created by the restarting router gets flushed, which means the originating router stops performing OSPF graceful restart.
  • The grace LSA’s grace duration expires.
  • The OSPF graceful restart process is terminated because an LSA is modified to match a change in the network topology.

OSPF Graceful Restart Configuration and Verification on Cisco IOS

The nsf ietf command allows you to enable OSPF graceful restart, IETF nonstop forwarding (NSF), on Cisco IOS. You can also use the command to disable NSF helper mode.

Configuring OSPF Graceful Restart

By default, OSPF graceful restart mode is disabled in Cisco IOS. To enable it, use the nsf ietf command in router configuration mode. In this case, the grace period is 120 seconds.

To specify a different value for the length of the non-stop forwarding interval, use the nsf ietf restart-interval length command, where length is a number between 1 and 1800.

The following example enables IETF NSF on router R2 and sets the OSPF graceful restart interval to 500 seconds.

R2(config)# router ospf 1
R2(config-router)# nsf ietf restart-interval 500

To verify the configuration, we issue the show ip ospf command in enable mode, as illustrated in this example.

R2# show ip ospf
 Routing Process "ospf 1" with ID 2.2.2.2
 Start time: 00:07:32.965, Time elapsed: 00:48:01.669
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Supports NSSA (compatible with RFC 3101)
 Supports Database Exchange Summary List Optimization (RFC 5243)
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 50 msecs
 Minimum hold time between two consecutive SPFs 200 msecs
 Maximum wait time between two consecutive SPFs 5000 msecs
 Incremental-SPF disabled
 Initial LSA throttle delay 50 msecs
 Minimum hold time for LSA throttle 200 msecs
 Maximum wait time for LSA throttle 5000 msecs
 Minimum LSA arrival 100 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF Non-Stop Forwarding enabled
    restart-interval limit: 500 sec

omitted output

Configuring NSF helper mode

By default, OSPF graceful restart helper mode is enabled in Cisco IOS, as shown in the following output of the show ip ospf nsf command.

R4# show ip ospf nsf
 Routing Process "ospf 1"
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
  OSPF restart state is NO_RESTART 
  Handle 252300284, Router ID 4.4.4.4, checkpoint Router ID 0.0.0.0
  Config wait timer interval 10, timer not running
  Dbase wait timer interval 120, timer not running

To disable OSPF graceful restart helper mode, issue the nsf ietf helper disable command in router configuration mode. You cannot disable or activate IETF NSF helper mode per interface.

This example disables OSPF graceful restart helper mode on router R1.

R1(config)# router ospf 1
R1(config-router)# nsf ietf helper disable

To verify the configuration, we issue the show ip ospf nsf command in enable mode, as shown in this example.

R1# show ip ospf nsf
 Routing Process "ospf 1"
 IETF NSF helper support disabled
 Cisco NSF helper support enabled
  OSPF restart state is NO_RESTART 
  Handle 272778884, Router ID 1.1.1.1, checkpoint Router ID 0.0.0.0
  Config wait timer interval 10, timer not running
  Dbase wait timer interval 120, timer not running

To enable helper mode, use the nsf ietf helper command.

Finally, to instruct OSPF to perform strict LSA checking in NSF helper mode, use the nsf ietf helper strict-lsa-checking command.

Strict LSA checking is only efficient in OSPF graceful restart helper mode, although you can enable it on the restarting router and helper neighbors.

If strict LSA checking is enabled on a helper neighbor, the router will stop participating in the graceful restart operation when it discovers a change in an LSA that requires the LSA to be flooded during the grace period.

This example enables strict LSA checking on router R3.

R3(config)# router ospf 1
R3(config-router)# nsf ietf helper strict-lsa-checking

The show ip ospf nsf command output indicates that our configuration has been applied to router R3.

R3# show ip ospf nsf
 Routing Process "ospf 1"
 IETF NSF helper support enabled
 IETF NSF helper strict-lsa-checking enabled
 Cisco NSF helper support enabled
  OSPF restart state is NO_RESTART 
  Handle 272778884, Router ID 3.3.3.3, checkpoint Router ID 0.0.0.0
  Config wait timer interval 10, timer not running
  Dbase wait timer interval 120, timer not running

Related Lessons to OSPF Graceful Restart

Conclusion

I hope this blog post helps you learn something.
Now I’d like to turn it over to you:
What did you like about this tutorial?
Or maybe you have an excellent idea that you think I need to add.
Either way, let me know by leaving a comment below right now.

Mohamed Ouamer is a computer science teacher and a self-published author. He taught networking technologies and programming for more than fifteen years. While he loves to share knowledge and write, Mohamed's best passions include spending time with his family, visiting his parents, and learning new things.

Exit mobile version