XR 5.3.0 BGP NSR will be by default on

[xthuijs]

In XR 5.3.0 we will be enabling BGP NSR by default to be on.

Since default changes always catch us by surprise I wanted to give a heads up notification.

NSR helps with the redundancy by sending, for BGP that is, TCP packets via the standby router to synchronize the TCP sequence numbers, so that when there is a control plane or RSP failover, the peer doesnt even realize that the affected router failed over its control plane. Graceful restart (GR), can help here too by providing a grace period on the peer before tearing the session down, allowing the control plane to reestablish the adjacency. NSR in that regard is more powerful since GR requires peer support and GR also results in temporary "headless" routing (during the GR and adj reestablishment).

XR's scale is always tested with NSR. BGP in XR supports 5000 bgp peerings and beyond easily.

xander

[xthuijs]

More detail!

CSCuq94496           IOS-XR BGP NSR to be turned on by default starting 5.2.3/5.3.0
 
==================================================================
Existing behavior before introduction of this feature (CSCuq94496)
==================================================================
 
o Default Behavior (i.e w/o any nsr configuration) : BGP NSR is disabled
-        'nsr' configuration enables BGP NSR functionality
-        'no nsr' removes the configuration and BGP NSR is disabled
 
 
Configuration
-----------------
 
o To enable BGP NSR, configure the following
 
router bgp <ASN>
 nsr
end
 
o To disable BGP NSR, remove 'nsr' configuration
 
router bgp <ASN>
 no nsr
end
 
 
 
============================================================
New behavior after introduction of this feature (CSCuq94496)
============================================================
 
o Default Behavior (i.e. w/o any nsr configuration) : BGP NSR is enabled
-        'nsr' configuration is accepted and displayed in show run.
            * BGP NSR will be enabled if previously disabled else the configuration does nothing.
-        New disable option introduced to nsr configuration
            * 'nsr disable'. This will disable BGP NSR functionality
* 'no nsr' removes the configuration and default functionality is established (BGP NSR is enabled)
* 'no nsr disable' will also remove the configuration and default functionality is established (BGP NSR is enabled)
 
 
Configuration
-----------------
 
o To enable BGP NSR, no configuration is needed
 
o To disable NSR, configure 'nsr disable'
 
router bgp <ASN>
 nsr disable
end
 
o If 'nsr' is configured, it will be displayed in show run as follows
 
router bgp <ASN>
 nsr
end
 
o If 'nsr' configuration is present & 'nsr disable' is configured, NSR will be disabled.
  The configuration will be displayed in show run as follows
 
router bgp <ASN>
 nsr disable
end
 
o If 'nsr disable' configuration is present & 'nsr' is configured, NSR will be enabled.
  The configuration will be displayed in show run as follows
 
router bgp <ASN>
 nsr
end
 
 
 
===================================
Future Configuration Recommendation
===================================
 
o To enable BGP NSR - remove any existing 'nsr' configuration so that the default behavior takes effect
 
o To disable (or not enable) BGP NSR - use only 'nsr disable' configuration
 
 

[Florian Frotzler]

Hi Xander,

Why does this only apply to BGP? Would it not make more sense to change the default behavior for all NSR supported protocols at once? This again leaves the behavior different from other protocols, creating inconsistency.

Florian

[xthuijs]

Hi Florian,

indeed, that was noted already and that will happen shortly too.

making default changes is never easy, so some analysis had to be done for OSPF and ISIS to see if it doesnt break the advertised scale and what ramifications there are, who we please, who we set off :)

Note ISIS NSR is new in 52, though there is no difference between "ISIS NSR" and "ISIS NSF/Cisco", other than a slight inconsistency with our naming conventions.

The idea behind NSR (for any protocol) is the ability to maintain state
upon switchover without having to rely on protocol extensions, for cases where the peer
doesnt understand the protocol extensions.  ISIS NSF/Cisco accomplishes this by
checkpoining everything needed to maintain the session to the standby.

ISIS NSF/IETF is the mode that relies on protocol extensions.

cheers!

xander

[marpina]

Hi xander,

I have a SP client where the network is configured with fast convergence ospf and they are planning to upgrade to 5.3.x on several asr9k so we should be considered to enable NSR on ospf/ldp as well?

best regards

marce

[xthuijs]

hi marce,

definitely, whenever you can, NSR is a great redundancy mechanism to use!

xander

[r.pfffli]

Hi Xander,

Nice doc, but I have to jump in regarding your sentence 

"Note ISIS NSR is new in 52, though there is no difference between "ISIS NSR" and "ISIS NSF/Cisco", other than a slight inconsistency with our naming conventions."

I have figured out, that if you use the global command nsr process-failures switchover, it will NOT work for ISIS, if you have configured isis nsf-cisco. You MUST configure isis nsr in order to have the process failure working. AFAIK this is described in the internal bug CSCul38974.

So there is some difference....there are also various nice show commands, if you have configured isis nsr instead of isis nsf-cisco.

regards

Roger