Featured image

Table of Contents Link to heading

Dual Route Processor Architecture Link to heading

High-end Cisco routers and switches (Catalyst 6800/9400/9600, ASR 1000, ASR 9000, Nexus 7000/9000) support redundant Route Processors (RPs) or Supervisor Engines. The RP is the control-plane card — it runs the OS, routing protocols, and management functions.

In a dual-RP system:

  • One RP is active: handles all control-plane functions
  • One RP is standby: ready to take over if the active fails

The behaviour during failover — and how much disruption occurs — depends on which redundancy mode is configured.

Info
Data-plane forwarding ASICs on line cards typically continue forwarding based on their cached FIB entries during RP failover. The question is how quickly the control plane recovers and how routing protocol adjacencies are maintained during the transition.

RP Redundancy Modes: Pre-SSO Link to heading

Cisco implemented RP redundancy in progressive generations, each reducing failover impact:

Mode Full Name Standby State Config Sync Protocol State Failover Impact
HSA High System Availability Inactive (cold standby) None None Full reload of standby — minutes of downtime
RPR Route Processor Redundancy Partially initialised (warm) Startup config only None Standby boots faster but re-runs protocols
RPR+ Route Processor Redundancy+ Fully initialised (warm) Startup + running config None Faster yet — still re-runs protocols on failover

In all pre-SSO modes, routing protocol adjacencies (OSPF, BGP, EIGRP) go down during RP failover. Traffic is black-holed until protocols re-converge and the RIB and FIB are rebuilt.

SSO: Stateful Switchover Link to heading

Info
SSO (Stateful Switchover) fully synchronises both the startup config and the running config to the standby RP in real time. When the active RP fails, the standby takes over in milliseconds without reloading — from the perspective of routing protocol neighbours, the device appears to have simply continued running.

SSO synchronises to the standby:

  • Full running configuration
  • Layer 2 state — spanning tree, EtherChannel, MAC tables
  • Layer 2 forwarding (via CEF/FIB checkpointing to line cards)

SSO does not automatically synchronise:

  • Routing protocol state (RIB, adjacency tables) — this requires NSF, GR, or NSR
  • Dynamic ARP entries
  • DHCP binding tables (unless separately configured)

When the active RP fails under SSO, the standby takes over and line cards continue forwarding based on the FIB that was checkpointed before the failure. However, routing protocol adjacencies are initially down — the device is forwarding on potentially stale routes.

Non-Stop Forwarding (NSF) Link to heading

Info
NSF (Non-Stop Forwarding) is automatically enabled when SSO is configured. NSF ensures that line cards continue forwarding traffic based on the last known FIB entries during the RP switchover period — even while routing protocol adjacencies are being re-established.

NSF provides:

  • Continued data-plane forwarding during RP failover (using the pre-switchover FIB)
  • A window of time (NSF grace period) during which the new active RP re-establishes routing protocol adjacencies and rebuilds the routing table

NSF does not checkpoint L3 control-plane state — routing protocol adjacencies and RIB entries are lost at switchover. The device is forwarding on a potentially stale FIB until protocols reconverge.

Warning
NSF alone does not prevent routing protocol adjacencies from going down. Without GR or NSR, neighbours will detect hello timeout and declare the adjacency down — potentially triggering reconvergence across the whole network, not just on the failing device.

Graceful Restart (GR) Link to heading

Info
Graceful Restart is a two-party mechanism where the restarting router and its neighbours cooperate to maintain routing adjacencies and forwarding during an RP failover.

GR roles:

  • GR-capable: The device that is performing the RP failover. Must signal GR intent to neighbours before or during the restart.
  • GR-aware (helper): Neighbouring devices that recognise the GR signal and continue to advertise routes to the restarting device during the grace period, without declaring the adjacency down.

GR grace period: The maximum time the restarting router is given to re-establish its routing protocol sessions and rebuild its RIB. During this window, GR-aware neighbours continue forwarding traffic toward the restarting router as if nothing happened.

Protocol-specific GR implementation:

  • OSPF GR: RFC 3623 / Cisco proprietary. Helper routers maintain the restarting router’s LSAs in the LSDB during the grace period.
  • BGP GR: RFC 4724. Helper routers continue advertising preserved routes while the BGP session recovers.
  • EIGRP GR: Cisco proprietary. Neighbours hold adjacency during the grace period.
Tip
Set the GR grace period conservatively — long enough for the RP failover and protocol re-establishment to complete, but not so long that a genuine device failure causes traffic to be forwarded toward a dead device for minutes. Typical values are 120–300 seconds for BGP, 40–120 seconds for OSPF.

Non-Stop Routing (NSR) Link to heading

Info
NSR (Non-Stop Routing) checkpoints full routing protocol state — including adjacency tables, RIB entries, and protocol data structures — to the standby RP in real time. During an RP failover, the standby takes over with all routing state intact. Neighbours are completely unaware that a switchover occurred.

NSR advantages over GR:

  • No dependency on neighbour support — GR requires neighbours to be GR-aware; NSR is entirely local
  • Routing protocol adjacencies never go down from the perspective of any device in the network
  • No grace period concept — the new active RP already has all protocol state

NSR disadvantages:

  • Significant additional load on both RPs — all protocol state must be continuously synchronised in real time
  • More complex failure modes — if the synchronisation between active and standby fails silently, the standby may have stale state at switchover time
  • Not supported on all protocols or platforms — check platform documentation

GR vs NSR: Choosing the Right HA Mechanism Link to heading

Criterion Graceful Restart (GR) Non-Stop Routing (NSR)
Neighbour awareness Neighbours must be GR-aware (helpers) Completely transparent to neighbours
Protocol state at switchover Lost — re-established during grace period Fully preserved — no reconvergence
RP overhead Low High — continuous state synchronisation
Suitable for Environments where neighbours support GR Service provider or carrier-grade networks
Failure transparency Visible to GR-aware neighbours (grace period signal) Completely invisible
Note
GR and NSR cannot be used simultaneously for the same routing protocol on the same neighbour. Use GR for neighbours that are confirmed GR-aware; use NSR for peers that do not support GR. Many enterprise deployments use GR for OSPF (widely supported) and NSR for BGP (where NSR-capable hardware is available).

Configuration Link to heading 

! Enable SSO (automatically enables NSF)
redundancy
 mode sso

! Verify standby RP is in SSO state before proceeding
show redundancy states

OSPF NSF/GR (Cisco proprietary):

router ospf 1
 nsf cisco

OSPF NSF/GR (IETF RFC 3623):

router ospf 1
 nsf ietf

BGP GR:

router bgp 65001
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360

EIGRP NSF:

router eigrp 100
 nsf

NSR (platform-dependent — IOS XR example):

router ospf 1
 nsr

Verification Link to heading 

show redundancy
show redundancy states
show redundancy history

! Protocol-specific NSF/GR state
show ip ospf nsf
show bgp ipv4 unicast neighbors <ip> | include Graceful
show ip eigrp neighbors detail | include NSF

show redundancy states is the primary command. It shows which RP is active, which is standby, and the current redundancy mode. The standby should show Standby Hot — any other state (Standby Cold, Disabled) indicates the redundancy mechanism is not fully operational and failover will not be hitless.