What Is Cisco Non-Stop Forwarding (NSF) and How Does It Work?
Cisco Non-Stop Forwarding (NSF) is a high-availability feature that keeps a router or switch forwarding IP packets while its control plane restarts after a supervisor or route-processor (RP) switchover. It always runs with Stateful Switchover (SSO): SSO brings a standby processor up in a synchronized state, and NSF uses the hardware forwarding table to keep traffic moving on the last-known routes until the routing protocols rebuild.
The name is slightly misleading, and the misunderstanding is worth clearing up first. NSF does not keep routing alive through a switchover — the routing protocols on the failed processor stop completely and start over from an empty routing table on the standby. What survives is forwarding. This guide traces exactly what happens to the data plane and the control plane in the seconds around a switchover, how NSF differs from SSO and from Non-Stop Routing (NSR), and the neighbor and platform conditions it depends on.
What Is Cisco Non-Stop Forwarding (NSF)?
Non-Stop Forwarding is Cisco’s mechanism for suppressing routing disruption when a device with redundant processors fails over from the active RP to the standby. Its single objective, in Cisco’s words, is to continue forwarding IP packets following an RP switchover.
The problem it solves is the routing flap. Normally, when a device’s control plane restarts, every routing neighbor sees the session drop, withdraws the routes learned through it, and reconverges — and that disturbance ripples outward across routing domains as instability. NSF suppresses that flap in an SSO-enabled device: interfaces stay up, neighbors never see the link go down, and packets keep flowing along known routes while the routing protocols quietly rebuild in the background. Cisco NSF is supported by the BGP, EIGRP, OSPF, IS-IS, and IPv6 routing protocols, and by Cisco Express Forwarding (CEF) for the forwarding itself.
How NSF Works: A Supervisor Switchover Timeline
NSF works by splitting the two things a router does — deciding routes (control plane) and moving packets (data plane) — and protecting only the second one through the failure. The clearest way to see it is a timeline across a single switchover.
Before the Switchover: CEF Syncs the FIB to the Standby
During normal operation, CEF on the active RP continuously mirrors its Forwarding Information Base (FIB) and adjacency database onto the standby RP. The FIB is the hardware forwarding table — the compiled “to reach this prefix, send out this port to this next-hop” instructions that the line cards or forwarding engines actually execute. Because the standby’s FIB is kept as a live mirror, the moment it is needed it is already correct.
The routing protocols themselves run only on the active RP. They are not mirrored, because the RIB is far larger and more volatile than the FIB and does not need to survive — the FIB is enough to keep forwarding.
During the Switchover: Forwarding Continues on the Last-Known FIB
When the active RP fails, SSO promotes the standby to active. It inherits the mirrored FIB and adjacency databases and, as soon as the interfaces and a data path are available, the line cards keep forwarding packets using that last-known forwarding table. From a passing packet’s point of view, nothing happened.
The control plane, however, is starting from nothing. The Routing Information Base (RIB) is empty on the newly active RP, and the routing protocols begin the work of relearning every route from scratch. Forwarding is running on a snapshot; routing is rebuilding live.
After the Switchover: Prefix-by-Prefix Refresh and Epoch Cleanup
As the routing protocols reconverge, they repopulate the RIB one prefix at a time, and each update flows down into CEF, which refreshes the matching FIB and adjacency entry. Cisco stamps every refreshed entry with a new version number it calls an epoch. When a protocol signals that its RIB has fully converged, the software sweeps the FIB and deletes every entry still carrying an epoch older than the current switchover — those are the stale routes that were valid before the failure but were never refreshed, so they are removed. What remains is a FIB rebuilt entirely from current information. This epoch mechanism is how NSF forwards on old data safely: it can trust the snapshot precisely because it has a deterministic way to identify and purge whatever the new control plane did not re-confirm.
NSF vs SSO: Which Feature Does What
NSF and SSO are two halves of one high-availability system, and NSF cannot run without SSO. SSO is the redundancy engine; NSF is the Layer 3 protection layer that sits on top of it.
| Feature | What it protects | What it does at switchover |
|---|---|---|
| SSO (Stateful Switchover) | Layer 2 state and device redundancy | Brings the standby up pre-synchronized with config and protocol state; the standby uses existing Layer 2 switching information to keep forwarding |
| NSF (Non-Stop Forwarding) | Layer 3 forwarding continuity | Uses the CEF-mirrored FIB to keep routing packets, and coordinates with neighbors so routing rebuilds without a flap |
Per Cisco’s High Availability Configuration Guide (Catalyst 9500/9600, IOS XE 17). SSO is a prerequisite: NSF must be configured on a device already running SSO.
Why is NSF needed on top of SSO at all? Because SSO alone protects Layer 2 cleanly, but Layer 3 forwarding is delayed until the routing tables are rebuilt on the new active processor — and Cisco documents that on an SSO device without NSF, that repopulation takes roughly 80 seconds. NSF closes that 80-second Layer 3 gap by forwarding on the FIB snapshot the entire time the RIB is empty.
NSF-Capable vs NSF-Aware Devices
NSF involves two roles, and reading Cisco’s documentation correctly depends on telling them apart: the device that restarts is NSF-capable, and the neighbors that help it are NSF-aware.
- NSF-capable — a device configured to support NSF that can perform the restart operation itself. It relies on its neighbors to hand back the routing information it lost. Full NSF capability requires a distributed platform with redundant processors — a single-RP box cannot restart gracefully because it has no standby to switch to.
- NSF-aware — a device running NSF-compatible software that recognizes a neighbor is restarting and holds that neighbor’s routes instead of tearing down the adjacency. A single-processor switch can be NSF-aware (a helper) even though it can never be NSF-capable (a restarter).
The default states catch people out, so verify them rather than assuming. Per Cisco, NSF capability is enabled by default only for EIGRP; for OSPF, IS-IS, and BGP it is off until you configure it. NSF awareness (helper mode) is on by default for EIGRP and OSPF but off for BGP. The practical consequence: BGP needs graceful restart turned on explicitly at both ends before any of this engages.
NSF vs Graceful Restart vs NSR Compared
These three terms describe overlapping high-availability mechanisms and are constantly confused. The short version: graceful restart is the protocol handshake, NSF is Cisco’s feature that uses it, and NSR is the alternative that hides the restart from neighbors entirely.
| Non-Stop Forwarding (NSF) | Graceful Restart (GR) | Non-Stop Routing (NSR) | |
|---|---|---|---|
| What it is | Cisco feature: forward on the FIB while the control plane rebuilds | The standardized protocol extension that lets neighbors hold routes for a restarting peer | Keep full routing-protocol state on the standby so it resumes with no restart |
| Where routing state lives | Rebuilt from neighbors after switchover | Rebuilt from neighbors after switchover | Synchronized to the standby before switchover |
| Do neighbors cooperate? | Yes — neighbors must be NSF-aware | Yes — this is the neighbor agreement | No — neighbors never know a switchover happened |
| Neighbor awareness of the event | Neighbors know and assist | Neighbors know and assist | Transparent to neighbors |
Terminology per Cisco’s High Availability and BGP configuration guides. Graceful restart is standardized per protocol: OSPFv2 in RFC 3623, BGP in RFC 4724, and IS-IS in RFC 5306.
Technically, “graceful restart” and “NSF” name almost the same thing from two directions — GR is the IETF protocol extension, NSF is the Cisco feature built on it — which is why Cisco’s own OSPF documentation uses the phrase “graceful restart, or non-stop forwarding.” In practice the distinction that matters is NSF/GR versus NSR: NSF and GR both rebuild routing from cooperating neighbors after the switchover, so they need the neighbors to play along, while NSR carries full protocol state to the standby ahead of time and needs nothing from the neighbors at all. NSR is heavier on the device and lighter on the network; NSF is lighter on the device and depends on the network.
How OSPF, BGP, and EIGRP Handle an NSF Restart
Each routing protocol implements the restart handshake differently, and the differences change how you deploy NSF. The pattern is the same — tell the neighbors “I’m restarting, hold my routes” — but the signal and the failure conditions vary.
OSPF: One Non-Aware Neighbor Disables NSF for the Segment
OSPF NSF has the strictest neighbor requirement of the three. After a switchover the NSF-capable device sends an OSPF NSF signal so neighbors keep the adjacency up instead of resetting it, then resynchronizes its link-state database. But this only works if every device on the segment is NSF-aware: if the NSF-capable device finds even one non-aware neighbor on a segment, it disables NSF for that entire segment. Other fully-aware segments keep working, but the mixed one loses the protection. OSPF NSF also covers OSPFv2 and IPv4 only — OSPFv3, virtual links, and sham links are not supported.
BGP: Graceful Restart Is Negotiated in the OPEN Message
BGP negotiates graceful restart per neighbor, at session setup, inside the OPEN message. Both peers must advertise the graceful restart capability in their OPEN messages, or the session simply comes up without it — a non-aware BGP peer ignores the capability and peers normally, just without NSF protection on that session. When the switchover hits, the NSF-aware peer marks the restarting device’s routes as stale but keeps using them to forward for a set grace period, so no packets drop while the new active RP re-establishes the session and re-exchanges routes. Because BGP graceful restart is off by default, this is the protocol most likely to be silently unprotected.
EIGRP: The RS Bit and the 240-Second Route-Hold Timer
EIGRP signals the restart by setting the restart (RS) bit in a hello packet. The NSF-aware neighbor responds by holding the restarting device’s known routes and starting a route-hold timer — 240 seconds by default — during which it maintains the adjacency and waits for the restarting device to signal it is ready to receive the topology table. If the timer expires first, the neighbor discards the held routes and treats the device as brand new. EIGRP is also the most forgiving of the three: it is NSF-capable by default, and a non-aware EIGRP neighbor simply ignores the capability and re-peers normally rather than breaking anything.
How to Enable and Verify NSF with SSO
NSF has two configuration layers: SSO at the system level, then graceful restart on each routing protocol. SSO is the prerequisite — configure it first, in redundancy configuration mode.
Device(config)# redundancy
Device(config-red)# mode sso
Device(config-red)# end
Entering mode sso reloads the standby supervisor so it comes back up in SSO mode. Confirm the redundancy state before relying on it:
Device# show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
STANDBY HOT and an operational mode of sso mean the standby is fully synchronized and ready to take over. CEF NSF then operates automatically in SSO mode with no extra configuration. On the routing protocols, enable graceful restart where it is not already on — most importantly BGP, which is off by default — using each protocol’s nsf or graceful-restart command, and confirm CEF’s NSF state with:
Device# show cef state
One platform note for IS-IS: it uniquely offers two modes. IETF mode rebuilds state from NSF-aware neighbors like the other protocols; Cisco mode transfers link-state and adjacency information directly from the active to the standby RP, which lets IS-IS keep NSF working even when the neighbors are not NSF-aware. All devices on a segment must use the same mode.
NSF Limitations and Common Misconceptions
NSF is powerful but conditional, and most “NSF didn’t work” cases trace to one of these documented limits rather than a bug.
- NSF does not mean routing never stops. The routing protocols fully restart and the RIB starts empty; only forwarding is continuous. If you expected the control plane to survive untouched, you wanted NSR, not NSF.
- It depends on neighbor cooperation. NSF is a pact with the neighbors. For OSPF, a single non-aware device disables it for the segment; for BGP, both ends must negotiate graceful restart or the session runs unprotected.
- HSRP is not supported with NSF/SSO. If first-hop redundancy on the box relies on the Hot Standby Router Protocol, NSF/SSO will not protect it — Cisco lists this as an explicit restriction.
- One restart at a time per neighbor. An NSF-aware device cannot assist two NSF-capable peers restarting simultaneously; the second falls back to a normal reconvergence.
- Sub-millisecond failure detectors can trip the port. If BFD or Fast UDLD timers are set aggressively low (in milliseconds) during an SSO switchover, the port can be driven into err-disabled state before NSF completes — a known interaction on several Catalyst 9500 models.
Which Cisco Platforms Run NSF with SSO
NSF with SSO runs on Cisco platforms that have a redundant route processor or supervisor to switch to — chiefly dual-supervisor modular chassis and redundant stacks. A single fixed switch with one supervisor can be NSF-aware (a helper for restarting neighbors) but cannot be NSF-capable, because there is no standby for it to fail over to.
Modular Catalyst chassis are the typical NSF-capable platforms. The Cisco Catalyst 9600 Series, with dual Supervisor Engine modules, runs NSF/SSO to keep forwarding through a supervisor failover, and the Cisco Catalyst 9400 Series delivers the same NSF/SSO redundancy — Cisco rates its dual-supervisor switchover at sub-second — alongside ISSU and StackWise Virtual. On the Catalyst 9500 fixed-chassis line, NSF/SSO has shipped since Cisco IOS XE Everest 16.6.1. Because support and defaults vary by platform, protocol, and release, confirm the specifics for your exact model and software train in its High Availability configuration guide before you design around it.
Frequently Asked Questions
Does NSF drop any packets during a switchover?
In principle, no. The whole design goal is zero forwarding loss: the standby forwards on the mirrored FIB from the instant a data path is available, and NSF-aware neighbors hold routes during reconvergence so nothing is withdrawn. Packet loss usually appears only when a neighbor condition is not met — a non-aware OSPF neighbor on the segment, or BGP graceful restart not negotiated.
Is NSF enabled by default?
Partly. Per Cisco, NSF capability is on by default only for EIGRP; OSPF, IS-IS, and BGP require you to enable it. NSF awareness (helper mode) is on by default for EIGRP and OSPF but off for BGP. SSO itself must be configured before any of it applies.
What handles Layer 2 traffic during a switchover?
SSO does. The standby uses existing Layer 2 switching information to keep forwarding L2 traffic immediately, while NSF handles the Layer 3 side by keeping the FIB live until the routing protocols reconverge.
What is the difference between NSF and ISSU?
They solve different problems. NSF keeps traffic forwarding through an unplanned processor failure or switchover; In-Service Software Upgrade (ISSU) is a planned procedure for upgrading software on a redundant system with minimal disruption. ISSU relies on the same SSO redundancy NSF does.
Can a device help NSF without redundant supervisors?
Yes — that is exactly what NSF-aware means. A single-supervisor switch can run NSF-compatible software and act as a helper, holding routes for a restarting NSF-capable neighbor, even though it can never perform an NSF restart itself.
References
- Cisco, High Availability Configuration Guide — Configuring Nonstop Forwarding with Stateful Switchover (Catalyst 9500 and Catalyst 9600 Series, IOS XE 17)
- Cisco, High Availability Configuration Guide — Configuring Nonstop Forwarding (IOS XE 17)
- Cisco, NSF/SSO Configuration Guide (Catalyst 9400 Series)
- IETF RFC 3623, Graceful OSPF Restart
- IETF RFC 4724, Graceful Restart Mechanism for BGP
- IETF RFC 5306, Restart Signaling for IS-IS
