OSPF Graceful Restart

This topic is to discuss the following lesson:

Hi Rene,
Thanks for your nice stuff .
So , how can we configure the Graceful restart and First we have to check the device is supported or not ?? Thx

br//zaman

Hello Zaman

You can find out about how to configure OSPF graceful restart at this Cisco Documentation. Note that OSPF graceful restart comes in two flavours: one which was implemented by Cisco, and one which is the IETF equivilent. Both can be implemented on Cisco devices. Because cisco Calls it Non Stop Forwarding, the command in both cases is nsf. nsf cisco is used to implement the Cisco version while nsf ietf is use for the IETF version.

Both commands are available in IOS version 12.2(33)SXH and later.

I hope this has been helpful!

Laz

Dear Agapides,
kindly,

  1. i have confuse about sentecnce “Once OSPF has restarted, it will re-establish neighbor adjacencies with the helper routers” it contradict ( sorry if wrong with using word I am not native), with concept of gracefull restart that neighbor adjacency is not down during ospf process restart…
    2.usually i clear ospf process when i make change in LSDB using filtering or summerization or any thing else change LSDB ,so you mentioned if thers is changed in LSDB before & after gracefull restart , it terminate gracefull restart ( mean neighbor reset ) & interupt in network happen ,so how can compromise between two concept .need your nice clearification

Dear Agapides,
from cisco documents,
During the NSF restart process, if neighbors that are not NSF-aware are detected on a network interface,NSF restart is aborted on the interface; however, NSF restart will continue on other interfaces.
is it mean if router 2 detect router 3 is non helpler capable " support or configure ",it will reset adj with r3 during restart ospf process ,keep traffic not interrup with R1 need your clearfication

Dear sir
kindlty, related with nsf ietf helper strict-lsa-checking, if defalut behavior when there have been changes in LSA type 1-5 and 7. helper mode will be exit …why i need this command…

Hello saif

I will attempt to answer all your questions in this one post.

Graceful restart informs OSPF neighbors that the router will reset its OSPF process. The neighbor routers maintain their neighbor adjacencies, but the router performing the graceful restart actually disengages its adjacencies. So from the point of view of the neighbours, the adjacency stays up, but from the point of view of the router performing the graceful restart, the OSPF process is stopped, restarted, and adjacencies are reestablished.

An OSPF router that is gracefully restarting will exit the graceful restart mode only under certain circumstances. These are clearly described. A change in the LSDB during the restart will cause it to exit. Any LSDB change after, will not affect the graceful restart since it will have been completed.

Yes, this is exactly correct.

This command is necessary to be enabled on helper routers when you want the helper to terminate the graceful restart of its neighbor if the helper receives an LSA that will have to be relayed to the restarting router. This will eliminate the need for the helper router to send the LSA to the restarting router and having the restarting router detect this and cancel the graceful restart. It saves the router an extra step.

I hope this has been helpful!

Laz

1 Like

dear sir

High appreciated yout support , your answer reflect high level unterstansding of features
Thanks thanks :heart_eyes:
god safe you

1 Like

Hello Saif

I appreciate your high praise! Just doing our best here at Networklessons. :sunglasses:

God be with you too!

Laz

1 Like

hi Good stuff
I have a question
Once the GR completes will the router (neighboring router) which is in helper mode go through the whole adjacency process (init to full) all over again ?
If i see the router (in helper mode) go through init to FUll , what would have caused that

Hello Chinchu

Actually, when the GR completes, the router will have to reestablish adjacencies with the other routers, so yes, the whole adjacency process (init to full) does complete in full. Using the example in the lesson, when the graceful restart of R2 completes, it will reestablish the adjacencies with R1 and R3.

The purpose of GR is to keep the routes learned from R2 in the routing tables of R1 and R3 even when R2 stops sending hellos. If GR was not enabled, when OSPF restarts on R2, these routes would be removed, and reinstated after the process completes.

I hope this has been helpful!

Laz

hi Laz

Thanks for replying. I am clear on that part. My questions is more about what happens when things go unexpected. For example , let’s say as R2 goes through a restart, R2 goes into GR mode and R3 into helper mode. As R2 restarts , let’s say 1 or 2 opsf enabled interfaces on R2 did not come up properly , then GR would fail. When the GR fails , will R3 exit helper mode ? what exchanges happen between R2 and R3 in this scenario ? Also now R2 and R3 has to establish adjacency again (init to full ) so in the mean time will there be packet loss ?

Hello Chinchu

Graceful restart has a defined grace period. This is the period of time in which the restart of OSPF of R2 (as in our example) will take place. If during its restart R2 malfunctions and the OSPF process does not come back up, the routes in R1 and R3 will remain in the routing table until the grace period is expired. This grace period by default is 120 seconds and can be changed, but it cannot exceed an LSA refresh time of 1800 seconds or 30 minutes.

Once the graceful restart period has expired, and R2 has not recovered from its graceful restart, then the graceful restart process ends, and the routers begin to operate normally under OSPF. This means that any routes installed in R1 and R3 that have been learned from R2 are removed due to the fact that the neighbor adjacency has failed.

More information about when the graceful restart process exits and when the graceful restart helper mode operation occurs can be found in this documentation:

I hope this has been helpful!

Laz

Hello everyone,

I learned about NSF in some 2014 CCNP SWITCH Book.

So far I saw that the CCIE Written Exam topics only require Graceful restart and when I searched about the difference between both NSF and GR, I found another topic which is NSR

NSF- Non-Stop Forwarding
NSR- Non-Stop Routing
GR- Graceful restart

I read the OSPF Graceful Restart lesson and it mentioned the NSF feature and I couldn’t understand how it differ from each other?

In the CCNP SWITCH the NSF feature doesn’t explained very deeply about how it works and which messages are generated to build the RIB faster after SSO Switchover, so I was wondering if anyone knows how it works and how it differ from graceful restart and also, some explenation about NSR and is that neccessary for the CCIE Writen Exam as it seems like an important topic!

Thanks you very much!

Hello Nitay

NSF is a feature that Cisco had developed that allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored following a stateful switchover (SSO). NSF and SSO work together to minimize the amount of time a network is unavailable during a switchover. NSF is a feature that exists for most routing protocols including BGP, EIGRP, IS-IS, and OSPF. You can find out more details about how it works at the following Cisco documentation:

Now there is an issue here concerning terminology. Graceful Restart for OSPF is a feature of OSPF that has been included in the OSPF RFC 3623 in 2003. This feature is specific to OSPF. However, Cisco also calls NSF by the term “Graceful Restart” and applies it to all routing protocols. So it is important to realize what is being spoken about in each case. Graceful Restart for OSPF, as defined in the RFC, is the subject of this particular lesson while NSF/Graceful Restart is a feature available for all routing protocols as described in the above Cisco link.

I hope this has been helpful!

Laz

“OSPF Graceful Restart” feature is supported mostly on switchs with “Dual CPU”

Hello Syed

I was unable to find Cisco documentation that confirms what you suggest. For example, the ASR 1000-RP1 which has a single core CPU does support the feature. Can you share where you have found this information?

Thanks!

Laz

Hi Laz,

This information was given By one of the Cisco Tac engineer while I was troubleshooting with him.
I dont have any supporting document for this statement.

Regards,
Abrar

1 Like

Hello,

I have a question regarding the following RFC 3623 statement:
“If an NSF-capable device discovers that it has non-NSF-aware neighbors (helpers) on a particular network segment, the device 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.”

Can you please explain what actually happens to restarting router in this case?
For example, restarting router X has 2 OSPF adjacencies to routers Y and Z.
Router Y is a helper while router Z is not helper (non-NSF-aware)

What will happen to restarting router X during graceful-restart? Will it fully exit the graceful-restart or it will perform graceful-restart for Y and but not for Z, meaning that there will no be traffic-hit between Y and X but there will be traffic hit between Z and X?

I mean that all the stale OSPF routes in FIB of X will be removed in this case or they will stay as stale at least for helper Y during graceful restart?

Also please clarify if behaviour for restarting router will be different in the following 2 cases:

  • recognise on some link non-helper router
  • have helper router which gets topology change

Thanks,
Vladimir

Hello Vlad

I was unable to find this statement in the RFC 3623 but I was able to find it in Cisco documentation describing NSF-OSPF. In any case, this statement describes the behaviour of an NSF-aware device when it detects non-NSF-aware neighbors.

This depends upon the routes found within the restarting device. Theoretically, based on your example, router X may be able to maintain a graceful restart with Y, and to have a regular OSPF restart with Z. However, one of the prerequisites of graceful restart is that the network topology remains stable during the grace period. RFC3623 states the following:

However, if (a) the network topology remains stable and (b) the
restarting router is able to keep its forwarding table(s) across the
restart, it would be safe to keep the restarting router on the
forwarding path.  This memo documents an enhancement to OSPF that
makes such graceful restart possible, and automatically reverts back
to a standard OSPF restart for safety when network topology changes
are detected.

So if the restarting router attempts to initiate a graceful restart with Y, but it contains routes to Z that it shares with Y that are suddenly lost, then the topology has changed. This results in an automatic revert to a standard OSPF restart for safety, as stated above.

Now because the restarting router will begin the grace period at the same time as when it loses its routes with Z, does that count as a topology change within the grace period or before the grace period? To be honest, the only way to determine this is to test it on actual equipment.

To conclude however, if the topology is such that it remains stable during an OSPF restart, and a restarting router does have some non-NSF-aware neighbors, then yes, it may be possible to maintain a graceful restart with NSF-aware neighbors, and to perform a regular OSPF restart with non-NSF-aware neighbors.

I hope this has been helpful!

Laz