Graceful OSPF Restart
Extracted elements (25)
Cryptographic sequence numbers for OSPF authentication may need to be preserved in non-volatile storage before a graceful restart, or the router's clock must be used and preserved across restarts. If neither can be guaranteed, adjacency reestablishment may be delayed by up to RouterDeadInterval seconds, forcing a much longer grace period.
DoNotAge is prohibited in grace-LSAs because the LS age field serves a dual purpose: it both tracks normal LSA aging and acts as an elapsed-time counter used to determine whether the grace period has expired. Using DoNotAge would break this timing mechanism.
Grace-LSAs have link-local scope (LS type 9) because they only need to be seen by the restarting router's direct neighbors. Domain-wide flooding is unnecessary and would waste bandwidth.
Normal OSPF shutdown procedures (flushing locally originated LSAs, withdrawing adjacencies) are deliberately NOT performed before a planned graceful restart. The goal is for the rest of the OSPF domain to continue routing through Router X as if it remained in continuous service; flushing LSAs would cause neighbors to reroute around it, defeating the purpose.
The helper termination algorithm is intentionally conservative: any topology-changing LSA that would be flooded to the restarting router immediately ends helper mode. A configuration option to disable LSA-change-triggered termination is allowed but increases the risk of transient routing loops and black holes.
The restarting router runs OSPF routing calculations (Section 16 of RFC 2328) during the restart even though it does not install results into the forwarding table. This is necessary specifically to return OSPF virtual links to operation, which depend on the routing calculation.
Backward compatibility with unmodified OSPF routers is automatic. If a neighbor does not support graceful restart or does not receive the grace-LSA, it will reissue its LSAs with links to the restarting router omitted. This is interpreted by helper neighbors as a topology change (triggering helper exit) and by the restarting router as an LSA inconsistency, causing both to revert to normal OSPF restart.
The operation of Traffic Engineering Extensions to OSPF (RFC 3630) during OSPF Graceful Restart is not specified in this document but is specified in a companion document on Routing Extensions in Support of Generalized MPLS.
A helper neighbor MUST NOT enter helper mode for a restarting router unless: (1) a full adjacency (neighbor state Full) currently exists, (2) no topology-changing LSAs (types 1–5, 7) have appeared since the restart, (3) the grace period has not expired, (4) local policy permits it, and (5) the helper itself is not currently performing graceful restart.
Additional Grace-LSA TLV types MUST be described in an Internet Draft and are subject to expert review by the OSPF Working Group before deployment.
Before restarting, Router X MUST ensure its forwarding table is up-to-date and will remain in place across the restart. It MUST also originate grace-LSAs for each OSPF interface and SHOULD retransmit them until acknowledged to maximize the chance that all neighbors enter helper mode.
DoNotAge MUST NOT be set in a grace-LSA, even when flooded over a demand circuit, because the grace-LSA's LS age field is used to calculate the remaining duration of the grace period.
During graceful restart, the restarting router MUST NOT install OSPF routes into the system forwarding table; it relies exclusively on forwarding entries installed prior to the restart. OSPF routing calculations are still run to restore virtual links.
For unplanned outages, grace-LSAs MUST be originated and sent before the restarted router sends any OSPF Hello packets. On broadcast networks they must be flooded to AllSPFRouters (224.0.0.5). The restart reason MUST be set to 0 (unknown) or 3 (switch to redundant control processor).
The grace period SHOULD NOT exceed LSRefreshTime (1800 seconds) to avoid the restarting router's LSAs from aging out while helpers are maintaining adjacency state.
The Grace-LSA is a link-local scoped Opaque-LSA (LS type 9) with Opaque Type 3 and Opaque ID 0, originated by a router wishing to execute a graceful restart. It requests that neighbors continue to advertise the router as fully adjacent during a specified grace period. Its body is TLV-encoded and includes the grace period length, restart reason, and optionally the router's IP interface address.
Injecting a false grace-LSA into the link-state database allows an attacker to spoof a router that has actually been withdrawn from service, causing neighbors to continue forwarding traffic toward it. The standard mitigation is cryptographic authentication of OSPF protocol exchanges as specified in RFC 2328; a stronger alternative using digital signatures is described in RFC 2154.
When cryptographic authentication is used, preserving received sequence numbers in non-volatile storage across a graceful restart is not mandatory. There is a risk that a replayed Hello packet could create neighbor state for a deceased neighbor, but this risk is no greater than during normal OSPF operation.
Helper neighbor state machine: (1) Normal — router receives a grace-LSA and checks five entry conditions. (2) Helper mode — router continues advertising full adjacency to the restarting router and suppresses normal adjacency-state-change processing. (3) Exit — triggered by: grace-LSA flushed (success), grace period expiry, or topology-changing LSA installed that would be flooded to the restarting router. On exit the helper reoriginates its LSAs reflecting the true adjacency state.
Restarting router state machine: (1) Pre-restart — operator command triggers origination of grace-LSAs and storage of grace period in non-volatile storage, then software restarts. (2) Graceful restart — router re-establishes adjacencies without originating LS types 1–5,7 and without updating the forwarding table. (3) Exit — triggered by: all adjacencies reestablished, LSA inconsistency detected, or grace period expiry. On exit the router reoriginates all LSAs, reinstalls forwarding table, and flushes grace-LSAs.
Each TLV within the Grace-LSA body encodes Type (2 octets), Length (2 octets, value portion only), and Value. TLVs are padded to 4-octet alignment; padding is not included in the length field. Unrecognized TLV types are ignored.
Grace Period TLV (Type=1, Length=4): a 32-bit unsigned integer specifying the number of seconds neighbors should continue to advertise the restarting router as fully adjacent. This TLV MUST always appear in a grace-LSA.
Graceful Restart Reason TLV (Type=2, Length=1): encodes the restart reason as one of 0 (unknown), 1 (software restart), 2 (software reload/upgrade), or 3 (switch to redundant control processor). This TLV MUST always appear in a grace-LSA.
IP Interface Address TLV (Type=3, Length=4): carries the restarting router's IPv4 interface address on the subnet associated with the grace-LSA. Required on broadcast, NBMA, and Point-to-MultiPoint segments so helpers can identify the restarting router.
The Grace-LSA header follows the standard OSPF Opaque-LSA format: LS age (2 octets), Options (1 octet), LS type 9 (1 octet), Opaque Type 3 (1 octet), Opaque ID 0 (3 octets), Advertising Router (4 octets), LS sequence number (4 octets), LS checksum (2 octets), length (2 octets), followed by TLVs.