NSF/NSR Whitepapers

When preparing for Cisco exams, it is useful to study the white papers and config guides for topics on the blueprint. Sometimes “trivia” type of questions can come from these resources. For this reason, I’ve spent some time combing through the config guides for NSF and NSR. I’ve summarized my findings and tried to point out any important “trivia” knowledge that seemed worthy of noting.

LDP

NSF/GR

Cisco refers to the GR helper mode as “LDP GR,” and the ability to preform a switchover as “LDP NSF SSO.” For this reason there are two separate chapters: one for GR and one for NSF SSO.

A router in NSF SSO mode must also run in LDP GR mode. (Although LDP GR technically refers to “helper only” mode where the router cannot perform NSF SSO switchover). For this reason, to enable the feature for both “modes” you simply use mpls ldp graceful-restart. What controls SSO or GR mode appears to be whether redundancy mode sso is enabled.

For GR, the router simply holds stale label bindings and allows the neighbor to gracefully switchover to the standby RP. You enable mpls ldp graceful-restart globally. In GR mode, the router cannot locally preform an SSO switchover event.

For NSF SSO, the config guide makes a point to mention that you must enable NSF on the routing protocols. This isn’t really explained, but I believe the idea is that your LDP sessions run ontop of the IGP, so you must ensure that the IGP supports NSF too. For this reason, the overall steps to enable LDP NSF SSO are as follows:

  • Enable SSO

    redundancy
 mode sso

  • Enable CEF (automatically supported on most routers these days)

    ip cef distributed

  • Enable NSF for the IGP

  • Enable MPLS LDP GR globally

    mpls ldp graceful-restart

  • Enable LDP on each interface

    int Gi1
 mpls ip

    • Because enabling LDP GR requires existing neighborships to restart, you should enable LDP GR globally before enabling LDP on an interface.

NSF SSO mode also has a checkpointing mechanism, where state information from the active RP is checkpointed to the backup RP. I usually think of this as an NSR feature instead of NSF, but it appears this is implemented in NSF as well.

A router in NSF SSO mode and a router in GR-only mode will both have output seen in show mpls ldp neighbor graceful-restart. For example:

Router# show mpls ldp neighbor graceful-restart
Peer LDP Ident: 10.20.20.20:0; Local LDP Ident 10.17.17.17:0
  TCP connection: 10.20.20.20.16510 - 10.17.17.17.646
  State: Oper; Msgs sent/rcvd: 8/18; Downstream
  Up time: 00:04:39
  Graceful Restart enabled; Peer reconnect time (msecs): 120000

The difference between a NSF SSO router and GR-only router can be seen with the command show mpls ldp checkpoint. A NSF SSO router will show a sync’ed checkpoint status:

Router# show mpls ldp checkpoint
Checkpoint status: dynamic-sync
Checkpoint resend timer: not running
5 local bindings in add-skipped
9 local bindings in added
1 of 15+ local bindings in none

A GR-only router will show that sync is disabled:

Router#show mpls ldp checkpoint
Checkpoint status: disabled
Checkpoint resend timer: not running
Checkpoint NSR ACK timer: not running
Local Bindings:
  65 of 65+ local bindings in none
IGP Sync Records:
  1 of 1 IGP Sync records in none

LDP NSR

Remeber that NSR is an “internal-only” mechanism that allows a router to switchover from the Active RP to the Standby RP with no “help” from its neighbor. For this reason, NSR is a little easier to configure and verify.

In NSR, all LDP messages are replicated by the active RP to the standby RP. The standby RP essentially runs in a “hot standby” state, where it receives all LDP messages but does not send messages to its neighbors.

There are three states LDP NSR operates in:

  • Initial State

    • The standby RP is ready to support NSR but it is not sync’ed to the active RP yet. This might be seen right when NSR is enabled or when the system/standby RP boots up.

  • Steady State

    • The active and standby LDP processes on the RPs are sync’ed. The standby RP is ready to take over.

  • Port Switchover

    • The standby RP has taken over as active.

To enable LDP NSR you simply use the following global command:

mpls ldp nsr

In the LDP NSR chapter, no mention is made about enabling NSR for IGPs prior to enabling NSR for LDP.

The show command show mpls ldp nsr verifies whether NSR is enabled.

References

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ha/configuration/xe-3s/mp-ha-xe-3s-book/mp-ldp-grace-rstrt.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ha/configuration/xe-3s/mp-ha-xe-3s-book/mp-ldp-grace-nsfsso.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ha/configuration/xe-3s/mp-ha-xe-3s-book/mp-nsr-ldp-supp.html

OSPF

NSF/GR

The config guide for OSPF NSF makes a similar disctintion to LDP’s NSF SSO and GR modes. In OSPF, “restarting mode” is the name given to a router that can preform an RP switchover, and “helper mode” is the name given to an NSF-aware router that can help its neighbor rebuild its RIB.

OSPF is unique in that there are two NSF modes: cisco mode, and ietf mode. You can only enable one mode at a time. Neither modes are supported over sham-links. Cisco mode is not supported over virtual links, however the config guide seems to imply that ietf mode is supported over virtual links.

By default, a router supports helper mode for both cisco and ietf NSF modes. You cannot configure the router to be able to preform a switchover (”restarting mode”) in both cisco and ietf modes, however the router can be a helper for both modes at the same time (and it is by default).

If you want to disable helper mode, you can use the following command:

router ospf 1
 nsf ietf helper disable
 nsf cisco helper disable

To enable “restarting mode,” you enable NSF for either ietf mode, or cisco mode:

router ospf 1
 nsf cisco
 ! or
 nsf ietf

While it’s not explicitly stated, you will need to enable SSO support on the router to be able to use NSF in “restarting mode.”

You can verify both the helper mode and restarting mode using the following show command:

show ip ospf 1
 <snip>
 IETF Non-Stop Forwarding enabled
    restart-interval limit: 200 sec
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 <snip>

OSPFv3 calls this same feature “graceful-restart.” Remember that the terms NSF and GR are generally interchangable. To enable the restart capability, you use the following command:

router ospfv3 1
 graceful-restart

Graceful restart awareness (”helper mode”) is enabled by default as in OSFPv2. To disable it, use the following command:

router ospfv3 1
 graceful-restart helper disable

You can verify OSPFv3 GR using its own show command:

R1#show ospfv3 graceful-restart 

          OSPFv3 1 address-family ipv6 (router-id 10.1.2.1)

  Graceful Restart helper support enabled
    Number of neighbors performing Graceful Restart is 0

There is also a feature called strict-lsa-checking which is available to be used on a helper router in ietf mode. The IETF specification states that if a helper router is currently “helping” a neighbor that is undergoing graceful restart, and the helper router sees that an LSA has been updated, it should completely exit the GR process. The idea behind this, is that the nature of OSPF requires the LSDB to always be synchronized. If an LSA is updated, the “helper” router should accept the updated LSA so that its LSDB is in sync. It should now break the GR process instead of holding onto stale information for its neighbor.

By default, strict LSA checking is disabled. To enable it you use the following command:

router ospf 1
 nsf ietf helper strict-lsa-checking

NSR

Enabling and understanding NSR for OSPF is more straightforward than NSF. As you’ve seen in LDP NSR, NSR is a self-contained restart mechanism that allows a router to preform an RP switchover with no “help” from its neighbor.

The only interesting point the config guide makes, is that NSR can significantly increase memory consumption. My guess is that this is not much of an issue on today’s hardware.

To enable NSR you simply use the following command:

router ospf 1
 nsr

Likewise to enable NSR for OSPFv3 you can use the same command. You also have the option of enabling or disabling NSR on a per-address family basis.

router ospfv3 1
 nsr

! Or per address-family

router ospfv3 1
 address-family ipv4 unicast
  nsr [disable]
 address-family ipv6 unicast
  nsr [disable]

References

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-s/iro-15-s-book/iro-nsf-ospf.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-s/iro-15-s-book/ip6-route-ospfv3-gr-rest.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-s/iro-15-s-book/iro-nsr-ospf.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-s/iro-15-s-book/iro-ospfv3-nsr.html

ISIS

You may think ISIS supports two NSF modes as OSPF does: cisco and ietf mode. This is true from a configuration standpoint, but cisco mode for ISIS is really an early implementation of NSR. For this reason, cisco mode NSF doesn’t quite count as NSF in my eyes.

It is not clear to me whether NSF ietf mode helper support is enabled by default as with OSPF and LDP. It seems that you may need to enable NSF for ietf mode if you want to have the router act as a GR helper. To enable NSF in ietf mode you simply use the following configuration:

router isis 1
 nsf ietf

To enable NSR on IOS-XE, you actually enable NSF for cisco mode. There is no “NSR” configuration.

router isis 1
 nsf cisco

On IOS-XR you can enable both NSF cisco and NSR, which likely do the same thing.

References

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ha/configuration/15-sy/ha-15-sy-book/ha-cfg-nsf.html#GUID-53E2A6DF-3323-4CEC-B0BC-C186EBC4DFBD

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/60x/b-ncs5500-routing-configuration-guide-60x/b-ncs5500-routing-configuration-guide-60x_chapter_00.html#con_1276652

PreviousNSRNextBFD

Last updated