I have one more question regarding topology change on helper router while strict-lsa-checking is disabled.
I was looking in different forums and didn’t find exact answer on what topology change is described here from the LSA perspective.
From RFC 3623:
**RestartHelperStrictLSAChecking
Indicates whether or not an OSPF restart helper should terminate
graceful restart when there is a change to an LSA that would be
flooded to the restarting router or when there is a changed LSA on
the restarting router's retransmission list when graceful restart
is initiated. The suggested default is enabled.**
And R1 is configured with strict-lsa-checking disable and during the restarting event on R2, R1 gets the following topology changes:
New interface is added into the R1 OSPF DB in area 10 and area 0 (router-lsa is changed)
new external LSA is added into the R1 DB by redistributing prefix from another protocol (BGP)
R1 is ABR and new summary LSA is generated by R1 into the area 0
Can you please tell me if for any of the mentioned cases, R1 will not terminate GR capability for R2 or only for LSA type 5 topology changes it’s relevant and all the rest of LSA changes will still terminate GR capability of R1 helper router?
It’s always interesting to look into the mechanisms of various protocols in detail, and determine what happens when particular situations occur. For this particular case, it’s always useful to check out all useful portions of the related RFC3623. Particularly page 8 under the section 3.2 Exiting Helper Mode where it explains the circumstances under which helper mode is exited.
Now for a more specific look at “what happens if…” it’s always a good idea to lab it up and do some debugs to check it out. debug ospf nfs [detail] is a useful debug command that can be used for this. For additional support on configuring and debugging (and verification) take a look at the following two Cisco links:
Hello,
Is there a way (feature) like Graceful Restart by which I can implement OSPF authentication on a already converged network without breaking the adjacency?
There is no feature that I know of that can help you to keep an OSPF topology converged while employing authentication. However, there are some best practices and some “tricks” that you can do to minimize and even eliminate any downtime due to convergence.
Remember that OSPF has a dead interval defined. If the dead interval expires without the receipt of a hello packet, then the neighbor adjacency will expire. If you configure OSPF authentication on both ends of a particular link between OSPF routers before that dead timer expires, then your OSPF topology will not reconverge. It should remain stable. In such a case, you should configure authentication on a per-interface basis rather than a per-area basis. This will give you more control over which adjacencies will be affected by the changes in configuration.
Typically on a Cisco IOS router, the default hello timer is set to 10 seconds while the default dead timer is four times that value, at 40 seconds. Before you do anything, check to see what the dead timer is set at to make sure you have enough time to make the changes. Some platforms, such as the Nexus devices, have a default hello timer of 1 second and a dead timer of 4 seconds!
Before you do anything I suggest you try to lab this up and test it in an emulator. Also keep in mind that for more complex topologies, there may be additional considerations that are involved that may make your goal more difficult to achieve. Take a look at this Cisco community thread for some more information and experience from other users on the subject.