A core router or switch reloading should not take the network down. In a well-designed high-availability platform, a supervisor can fail, or software can be upgraded, and traffic keeps flowing with barely a ripple. The technologies that make that possible, SSO, NSF, and graceful restart, work together but solve different halves of the problem, and understanding the division of labour is the whole topic.
This article covers high-availability techniques at CCNP depth. It extends the QoS cluster guide and the campus design article.
A Note on the Lab
Keeping to this site's honesty rule: SSO (Stateful Switchover) requires a device with two supervisor modules, so one can take over from the other. That is a hardware-redundancy feature that a single-supervisor virtual router cannot demonstrate, and the IOL platform in this lab has one supervisor. So the SSO mechanics below are explained conceptually. The routing-protocol side, NSF and graceful restart, is partly observable on IOL, and the real capture of OSPF's NSF helper capability is shown below. No switchover output is fabricated.
The Two Halves of the Problem
When a supervisor fails and a backup takes over, two things must survive for traffic to keep flowing:
Solve only the first and your box keeps forwarding but its OSPF neighbors declare it dead and reroute, causing churn. Solve only the second and the neighbors wait patiently while your box has actually stopped forwarding. You need both, and they are different mechanisms with different names.
SSO: Keeping the Standby Supervisor Ready
Stateful Switchover is the hardware-redundancy foundation. In a dual-supervisor chassis, one supervisor is active and one is standby (hot). SSO continuously synchronises state from the active to the standby, the configuration, the interface state, and critically the Layer 2 protocol state, so that if the active fails, the standby takes over already knowing where everything is.
The key thing SSO preserves is the forwarding information. The CEF/FIB (the hardware forwarding table) is maintained on the standby, so at the moment of switchover, the new active supervisor can forward packets immediately using the tables that were already there. It does not have to rebuild them. That is what makes the switchover fast enough that traffic barely notices.
What SSO does not preserve on its own is the control-plane routing protocol state, the OSPF adjacencies, the BGP sessions. Those are held by the supervisor's CPU, and during the switchover the routing process restarts. Without help, the routing protocols would flap. That is where NSF comes in.
NSF: Forward While the Control Plane Recovers
Nonstop Forwarding is the bridge between SSO and the routing protocols. The insight is elegant: because SSO preserved the forwarding table (the FIB), the box can keep forwarding traffic using the old FIB while the control plane (the routing protocols) restarts and rebuilds in the background. The data plane does not wait for the control plane.
So during a switchover: SSO hands over to the standby supervisor, which forwards packets using the retained FIB (NSF), while the routing protocols restart, re-establish, and eventually recompute the tables. As long as the topology has not actually changed during the brief switchover, the retained FIB is still correct, and traffic flows the entire time. NSF is what turns "the forwarding table survived" (SSO) into "traffic keeps flowing" during the control-plane rebuild.
Graceful Restart: Convincing the Neighbors to Wait
Here is the remaining problem. Your box is forwarding fine via NSF, but its OSPF neighbors have noticed the routing process restart. Normally, a neighbor that sees an adjacency drop declares the router dead and reroutes around it, exactly the churn you were trying to avoid. Graceful restart (also called NSF-awareness on the neighbor side) is the agreement that prevents this.
The restarting router signals its neighbors: "I am restarting my control plane, but I am still forwarding. Please keep our adjacency up and keep sending me traffic; do not reroute." A graceful-restart-aware neighbor honours this, holding the adjacency and continuing to forward toward the restarting router for a grace period, giving it time to rebuild. This is a cooperative protocol: the restarting router needs its neighbors to be NSF-aware (also called GR helpers) for it to work.
And this is the part that is observable on the lab platform. Here is OSPF's real graceful-restart helper capability, captured live:
R1#show ip ospf | include NSF|Graceful|helper
IETF NSF helper support enabled
Cisco NSF helper support enabled
Graceful Reload FSU Global status : None (global: None)Both the IETF and Cisco flavours of NSF helper support are enabled, meaning this router will act as a graceful-restart helper for a restarting neighbor: it will hold the adjacency and keep forwarding while that neighbor recovers, rather than tearing down and rerouting. This is the neighbor-side half of the mechanism, and it is real. The restarting-side (the box with dual supervisors actually doing the switchover) is what needs the hardware SSO/NSF this virtual platform lacks.
The Three Working Together
The full sequence of a graceful supervisor failover:
The result: a supervisor fails (or you upgrade its software), and traffic through the box continues with sub-second or no interruption, because the forwarding never stopped and the neighbors never rerouted. That is the goal of the whole HA stack, and it takes all three pieces cooperating.
Where HA Fits in the Design
These techniques matter most exactly where the campus design demands no single point of failure: the core and distribution layers, where a device reload would otherwise be disruptive. They complement, rather than replace, topological redundancy (redundant devices and links). A dual-supervisor core switch with SSO/NSF handles a supervisor failure gracefully; a pair of core switches handles a whole-device failure. You want both: the box survives a component failure with SSO/NSF, and the topology survives a box failure with redundancy. For faster failure detection to complement this, see BFD.
FAQ
What is the difference between SSO and NSF?
SSO synchronises state to a standby supervisor so it can take over with the forwarding table intact. NSF uses that retained forwarding table to keep forwarding packets while the routing protocols restart. SSO preserves the tables; NSF keeps forwarding with them.
What does graceful restart do?
It convinces the restarting router's neighbors to hold their adjacencies and keep forwarding toward it, rather than declaring it dead and rerouting. It is the neighbor-cooperation half of the HA story.
Can I lab SSO?
Not on a single-supervisor virtual router. SSO needs two physical supervisor modules. The neighbor-side graceful-restart helper capability (NSF-awareness) is observable, as shown in the real OSPF capture.
Do my neighbors need to support anything?
Yes. Graceful restart is cooperative: the neighbors must be NSF-aware (GR helpers) to hold their adjacencies while your box restarts. If they are not, they will reroute despite your NSF.
Does this replace having redundant devices?
No, it complements it. SSO/NSF handles a component (supervisor) failure within a box; topological redundancy (paired devices, redundant links) handles a whole-device failure. Design for both.
Key Takeaways
- Surviving a supervisor failover needs two things: keep forwarding (inside the box) and keep the routing relationships (with neighbors). Different mechanisms.
- SSO synchronises state to a standby supervisor so it takes over with the FIB and L2 state intact.
- NSF uses that retained FIB to keep forwarding packets while the routing protocols restart in the background.
- Graceful restart convinces NSF-aware neighbors to hold their adjacencies and keep sending traffic instead of rerouting around the box.
- The real capture: OSPF
IETF NSF helper support enabled/Cisco NSF helper support enabled, the neighbor-side (helper) half, which IOL can show. SSO itself needs dual supervisors and is covered conceptually. - HA complements, not replaces, topological redundancy. The box survives a component failure with SSO/NSF; the topology survives a box failure with redundant devices and links.
Next: On-prem vs cloud network design, or the QoS cluster guide.
