BGP NSR vs Graceful Restart: Control Plane HA

Two mechanisms are routinely confused because both promise "no traffic loss during a control plane event". Graceful restart (also called nonstop forwarding) lets the forwarding table keep working while the protocol restarts - but it depends on neighbours acting as helpers, and it does flap state on the wire. Nonstop active routing (NSR) replicates protocol state to a standby Routing Engine so the neighbour never even sees a restart. Choosing the wrong one is why some maintenance windows lose a BGP session and others do not.

What graceful restart actually does

With GR/NSF configured, a restarting router advertises the restart capability and asks neighbours to preserve its routes for a grace period. Neighbours become helpers: they keep the stale paths in the forwarding table and mark them stale for the configured stalepath time, giving the restarting control plane time to re-establish and re-advertise. The restart time (typically 120 seconds) and stalepath time (typically 360 seconds) are negotiated per session.

Three consequences follow. Forwarding survives only if every neighbour supports and honours GR. Routes are stale - not verified - during the grace period, which is a correctness trade-off. And if the restart exceeds the timer, neighbours purge the paths and you are in a hard outage.

What NSR adds

NSR uses the same infrastructure as graceful Routing Engine switchover (GRES) to keep interface and kernel state, and then goes further by continuously synchronising the routing protocol's state - adjacencies, RIB-in, sequence numbers - to the standby RE. On a switchover the standby takes over with sessions intact: no adjacency flap, no helper needed on the neighbour, no stale routes. The cost is CPU and memory: the protocol process runs on both engines and state must be replicated continuously.

# Junos: enable NSR for the routing protocols
set routing-options nonstop-routing
set protocols bgp group EBGP nonstop-routing

# Junos: graceful restart instead, if the neighbours must be helpers
set routing-options graceful-restart
set routing-options graceful-restart restart-time 120
set protocols bgp group EBGP graceful-restart

Verification

user@router> show bgp neighbor 192.0.2.1 | match -i "nsr|graceful|restart"
  Nonstop routing is enabled
  Graceful restart is enabled
user@router> show task replication
  Stateful Replication: Enabled
user@router> show redundancy
  ...  switchover-requested / failover

On IOS XR the equivalent pair is bgp graceful-restart and nsr under router bgp, verified with show bgp neighbor, show bgp nsr and show redundancy. If show bgp nsr reports that NSR is unavailable for a session - for example because the peer negotiated a capability NSR cannot replicate - the fallback is exactly graceful restart, so configure both rather than assuming NSR.

Choosing between them

• Control-plane switchover only: NSR is the better answer - no neighbour involvement, no stale routes. Enable it on BGP, OSPF/IS-IS and RSVP where the platform supports it.
• Peer devices that must survive a restart of the other box: graceful restart helps only for control plane restarts; a full chassis reload still results in stale routes until reconvergence unless the peer is also restarting.
• Mixed-vendor edges: verify helper capability with the carrier before relying on GR. A neighbour that ignores the restart flag turns your maintenance into a session flap.
• Timers: set restart-time and stalepath-time generously enough that a busy router finishing a route refresh still completes inside the window - and alert if a GR restart exceeds the timer, because that is a latent outage.
• Do not treat either as a substitute for path redundancy: they reduce, not eliminate, the impact of a control plane event.

Related: BGP session stuck in Idle or Active, BGP best path selection: the 13-step algorithm, and NX-OS ISSU upgrade impact checks.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic-map/nonstop-active-routing-understanding.html