Summary

  • An OSPFv3 grace-LSA asks helpers to continue advertising the restarting router as fully adjacent for a stated interval. It does not demonstrate that the preserved forwarding table still delivers packets.
  • Continuity also depends on semantic identity: RFC 5187 requires stable LSA-ID-to-prefix correspondence and stable Interface IDs so pre-restart LSAs continue to describe the same objects.

The restart panel showed ninety seconds of grace remaining. Every helper still advertised the router as fully adjacent. The control processor was rebuilding its link-state database exactly as planned.

Packets were still entering the preserved FIB and leaving toward a next hop that had failed during the restart.

The timer was correct. The adjacency claim was correct within helper mode. The conclusion was not. Graceful restart can keep a router on the forwarding path while its OSPF software returns, but the mechanism assumes that the topology stays stable and that the forwarding state retained before restart remains usable. A green grace period measures permission to preserve a claim; it does not measure the truth of the data path that claim protects.

A request for help, not an automatic acceptance

RFC 5187, published on the Standards Track in June 2008, adapts the OSPFv2 graceful-restart mechanism of RFC 3623 to OSPFv3. The restarting router originates a link-local grace-LSA. Its neighbors are asked to keep advertising it as fully adjacent for a bounded grace period while control-plane state is reconstructed.

The OSPFv3 grace-LSA has LS type 0x000b, function code 11. Its Link State ID is the Interface ID of the originating interface. It carries a mandatory grace-period TLV and a mandatory reason TLV: unknown, software restart, software reload or upgrade, or switch to a redundant control processor. OSPFv3 identifies neighbors on every link by Router ID, so it does not need OSPFv2's router-address TLV.

Sending that LSA does not prove that any neighbor entered helper mode. RFC 3623 allows local policy to refuse all assistance, cap the acceptable interval, help only selected restart reasons or decline while the prospective helper is restarting. Receipt is a request boundary. Helper acceptance is a separate local decision and must have its own evidence.

The mechanism begins with two conditions

The base design is safe when the network topology remains stable and the restarting router keeps its forwarding tables across the restart. For a planned restart, the router must first ensure those tables are current and will remain in place. During recovery it runs routing calculations, but it relies on pre-restart forwarding entries until it exits graceful restart.

Those conditions are operational, not ceremonial. A line card can remain powered while a next hop becomes unusable. An ECMP member can fail while the control processor is absent. A preserved FIB can faithfully retain a route that was already wrong. A packet counter can continue increasing because packets are being discarded downstream.

The minimum evidence therefore includes before-and-during probes, egress and next-hop counters, forwarding-entry fingerprints, path observations and loss. It also includes the topology changes seen by helpers. Without those, “forwarding plane intact” is an assumption copied from the change plan.

OSPFv3 identifiers do not carry their own meaning

RFC 5187 adds obligations that are easy to miss if graceful restart is treated only as a timer. In OSPFv2, summary and external LSA IDs correspond directly to advertised prefixes. In OSPFv3, the LSA ID for inter-area-prefix and external LSAs is simply an unsigned 32-bit integer.

The restarting router must preserve the mapping from that integer to the prefix. Reusing the same number for a different prefix is numeric continuity and semantic discontinuity. Changing the number for the same prefix produces churn even when forwarding hardware still contains a usable entry.

A restart receipt needs the complete mapping before and after, not just a set of LSA IDs or a count. It should identify additions, removals and remaps and explain every legitimate difference. An equal hash over sorted integers proves nothing if the associated prefixes changed.

Interface ID is part of the topology contract

OSPFv3 also maps Link-LSA and Network-LSA IDs, and interface descriptions inside Router-LSAs, to Interface IDs. If those identifiers change during restart, the pre-restart LSAs no longer align with neighbor adjacency state. RFC 5187 says this disparity causes graceful restart to end prematurely.

Neighbors could theoretically synchronize changed identifiers. The specification deliberately places the burden on the restarting router because preservation is more robust, deterministic and simple. Many implementations use MIB-II IfIndex as the OSPFv3 Interface ID. RFC 2863 describes persistence and the possibility of reassignment across reinitialization, which means an operator cannot infer preservation merely from a familiar interface name.

Record the tuple: physical port identity, ifName and ifAlias where available, IfIndex, OSPF Interface ID, link-local address, neighbor Router ID and every LSA reference. Compare it before and after. If a chassis enumerates modules in a different order, the same label on a bezel may receive a new number while the old number names another port.

Helpers are deliberately conservative

A helper relationship is per network segment. The helper monitors the topology and stops helping on successful completion, grace-period expiry or a qualifying topology change. Strict LSA checking can terminate assistance when relevant link-state information changes, because the restarting router cannot promptly adapt its preserved forwarding table.

That early exit is not a graceful-restart failure to be suppressed. It is the safety mechanism reverting to ordinary OSPF behavior. A high-level dashboard that displays only the original grace timer may remain green after one helper has already withdrawn cooperation. Aggregate status must therefore be derived from per-segment helper state and exit reason.

The restarting router has its own exit conditions. It must rebuild the required consistency with pre-restart LSAs and adjacencies before the period expires. If a neighbor no longer advertises the expected pre-restart relationship, or the timer runs out, the bounded fiction ends and normal convergence resumes.

Planned and unplanned restarts are not equivalent

A planned upgrade can prepare: refresh forwarding state, originate grace-LSAs before software stops, store the requested interval and reason, and verify that helpers are eligible. An unplanned restart did none of that preparation. It may not know whether its forwarding tables are sane, and it has to originate its request after returning.

Both paths can use the vocabulary of graceful restart, but their evidence differs. A change-management field saying reason=unknown is not just another label. It means the operator lacks the pre-restart preparation receipt that supports the continuity assumption.

Leadership should not offer the same risk treatment to an intentional control-processor switch and an unexplained crash. The protocol permits local decisions; the operational policy should use them.

Authentication protects a message, not current reality

RFC 5187 discusses replay of an old Link-Update containing a grace-LSA. Such a replay could make neighbors believe that an out-of-service router is restarting. The document observes that replaying ordinary Hello packets is an easier way to keep an adjacency up and therefore does not claim a new security category.

That comparison sets a careful boundary. Valid formatting, a recognized function code and an authentication mechanism do not prove freshness, current forwarding health or the physical presence of the router. RFC 4552's earlier authentication approach and RFC 7166's later OSPFv3 authentication trailer context matter, but the operational record still needs anti-replay state, packet age, sequence evidence and observed neighbor behavior.

A complete receipt joins time, identity and execution

For each restart, retain an immutable change ID; planned or unplanned classification; software and control-processor identity; Router ID; grace interval and reason; every grace-LSA and its Interface ID; every helper's policy decision, start, deadline and exit reason; forwarding-table fingerprint; packet-path evidence; LSA-ID-to-prefix map; interface-to-IfIndex-to-OSPF-ID map; adjacency and database synchronization timeline; LSDB, RIB and FIB snapshots; topology changes; authentication and replay state; rollback; and final reconciliation.

This structure follows Heng Lu's reality layers. The grace-LSA is a symbolic request. Helper mode is a distributed control decision. The preserved FIB is running code. Delivered packets are the outcome. None can silently inherit the authority of the next.

RFC 5187's discipline is sharper than “keep routes during restart.” It says continuity depends on keeping meanings stable while control returns. A timer can preserve old claims. Only identity maps and forwarding observations show whether those claims still point to the same world.

Sources

  1. RFC 5187 — HTML
  2. RFC 5187 — plain text
  3. RFC Editor information page
  4. IETF Datatracker document page
  5. IETF Datatracker history
  6. IETF Datatracker references
  7. RFC 5187 errata
  8. RFC 3623 — Graceful OSPF Restart
  9. RFC 3623 information page
  10. RFC 5340 — OSPF for IPv6
  11. RFC 5340 information page
  12. RFC 2740 — original OSPF for IPv6
  13. RFC 2863 — Interfaces Group MIB
  14. RFC 1213 — MIB-II
  15. RFC 4552 — Authentication/Confidentiality for OSPFv3
  16. RFC 7166 — OSPFv3 Authentication Trailer
  17. IANA OSPFv3 Parameters
  18. Heng Lu — reality layers
  19. Heng Lu — minimum specification and voluntary adoption
  20. Heng Lu — running code is primary