because the a9k provides for a total distributed architecture, whereby the control plane is separated from teh forwarding, there is natively already NSF, so for that you dont have to configure anything.
You can read up more on that topic if you like when you google asr9000 route scale architecture.
NSR, that is bascially to keep a peering alive, while the standby sending the actual TCP packets (to keep the seq numbers in sync) is something that you configure separately via:
Assisting in NSF can be the fucntionality of graceful restart (to maintain the session before declaring it down), and NSF is also implemented by nature via the functionality of SSO (stateful switchover).
The NSR implementation in XR relies on the use of the Standby RP. If the
process were to fail/crash on the Active RP, unless control is passed to the
Standby RP, NSR operation will not work - in effect it will then revert back to
either Graceful-restart (if enabled) or a full process restart (peer down/adj
down etc.). The process on the Active RP cannot recover state from the Standby
RP. If you were to have a situation where the Active RP were to crash, then NSR
functionality will kick-in as control will be passed to the Standby RP.
The question is, do you only want NSR to occur in the event of an RP failure
(which should be a rare occurrence)? If the answer is 'yes', then do no enable
the configuration 'nsr process-failures switchover'. If the answer is 'no' and
the customer understand that an RP failover is expected in the circumstances,
then enable 'nsr process-failures switchover'. For some customer, the very idea
of an RP failover is just 'bad' - for others, they are comfortable with this
form of operation.
There are only a few SPs using NSR today, since for many, the key driver has
been BGP NSR which was only delivered in rls 3.8.0. We do have customers who
are in service with NSR for OSPF and LDP and BGP - we have a good number of
customers who are using ISIS with NSF CISCO (which is actually NSR), which was
delivered back in rls 3.3.x. They do use the 'nsr process-failures switchover'
since the RP failover is considered to be too rare an event.
Without 'nsr process-failures switchover' enabled, NSR will only come into
effect should the RP crash or an RP failover be manually triggered.
Enabling this config will result in a failover being initiated if BGP, TCP, LDP
or OSPF were to crash. Since an FO is immediately triggered to preserve NSR, a
core-dump of the crashed process will not be available. If diagnosing such a
crash is more important for the customer, then this knob should not be turned
on.
