Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
updates
- rfc-1793 — Extending OSPF to Support Demand Circuits
Extracted elements (15)
Hello suppression in OSPF demand circuits (RFC 1793) prevents detection of an OSPF-inactive neighbor: if the remote OSPF process dies or the link is oversubscribed, the local router and routers behind it may never learn of the problem and continue forwarding traffic to an incapable router.
Neighbor probing reuses the standard LSDB synchronization flooding procedure (re-sending an already-known LSA) rather than introducing new packet types, ensuring implementations need only follow existing OSPF flooding rules to support the mechanism.
The neighbor probing mechanism is based on standard OSPF flooding behavior (re-flooding an existing LSA), making it fully backward-compatible with standard OSPF implementations that do not implement this extension.
Neighbor probing applies only to point-to-point links, virtual links, and point-to-multipoint interfaces; broadcast and NBMA links are excluded because Hello suppression is not used on those link types.
When the first probe LSA has a higher sequence number than what the probed neighbor holds (because LSA refreshes are not flooded over demand circuits), the neighbor will flood the probe LSA further; subsequent probe LSAs with the same sequence number will not cause additional flooding.
If ospfIfDemandNbrProbe is enabled, routers SHOULD probe each other when the demand circuit link comes up and may probe periodically every ospfIfDemandNbrProbeInterval while the link remains up.
Implementations SHOULD limit the number of times an LSA can be retransmitted to ospfIfDemandNbrProbeRetxLimit when used for neighbor probing; if no acknowledgement is received after that limit, the adjacency should be brought down.
Neighbor probing must be restricted to neighbors for which a circuit is actually established at the time probing is initiated, to avoid falsely declaring temporarily unreachable (oversubscribed) neighbors as down.
Neighbor probing MUST NOT be considered interesting traffic and MUST NOT prevent the demand circuit from being torn down.
Neighbor probing uses link-state update packets (flooding an LSA already in the LSDB) to verify that the OSPF process is operational on a neighbor reachable over a demand circuit. An explicit or implicit acknowledgement (link state acknowledgement or link state update) confirms the neighbor is alive.
ospfIfDemandNbrProbe is a configurable boolean parameter indicating whether neighbor probing is enabled; it is disabled by default.
ospfIfDemandNbrProbeInterval defines how often a neighbor is probed while the demand circuit link is up; a sample value is 2 minutes.
ospfIfDemandNbrProbeRetxLimit defines the maximum number of consecutive LSA retransmissions before the neighbor is declared inactive and the adjacency brought down; a sample value is 10.
Virtual links are treated analogously to point-to-point links for neighbor probing purposes. Point-to-multipoint demand circuit interfaces are treated as collections of individual point-to-point links.
The neighbor probing mechanism described in this document does not modify the security aspects of the OSPF routing protocol; no new security considerations are introduced.