Summary

  • RFC 5185 deliberately creates a separate point-to-point OSPF adjacency for each added area across one common physical interface. Several FULL adjacencies therefore can share one port, circuit and cut risk.
  • Resilience and capacity claims require a physical-to-logical evidence map. Count the circuit's bandwidth once, enumerate every area-local consumer, and test the forwarding result after SPF rather than treating adjacency count as path diversity.

The resilience dashboard showed three healthy links between two area border routers. One belonged to the backbone, one to Area 1 and one to Area 2. Every neighbor state was FULL. The availability model concluded that two failures could be tolerated.

A single fiber cut removed all three at the same timestamp.

Nothing in OSPF had lied. RFC 5185 was built to let one physical link appear as an intra-area topological path in multiple areas. The dashboard had promoted three protocol objects into three independent pieces of infrastructure. It counted projections while the packets depended on one port, one line card, one circuit and one shared maintenance window.

The extension changes route choice without creating a second cable

RFC 5185 was published on the Standards Track in May 2008. Its motivating case is practical. Two ABRs have a high-speed link in the backbone, while routers in another area can reach one another over slower links inside that area. Ordinary OSPF route preference favors an intra-area path over an inter-area one. Traffic may therefore stay on the slower path even though the fast ABR link exists.

The extension allows the same physical link to support another adjacency in that non-backbone area. The added adjacency gives that area an intra-area path, allowing SPF to select the fast link without removing it from the backbone.

The alternatives reveal why the design is narrow. A virtual link would require treating the physical link as belonging to the other area rather than preserving its backbone role. Secondary addressing can manufacture separate interfaces on numbered links, but consumes addresses, cannot solve the unnumbered case and can add advertised routes. Simply declaring the same addressed subnet to be in several areas conflicts with the definition of an area as a collection of subnets.

RFC 5185 therefore multiplies adjacency context, not physical media. That distinction is the entire operational problem.

Every added adjacency receives a real state machine

For each configured multi-area adjacency, the implementation creates an OSPF interface data structure. It is always modeled as point-to-point, regardless of the network type of the underlying interface. Its interface state machine follows the point-to-point model; the neighbor structure and neighbor state machine remain ordinary OSPF.

The primary adjacency is not replaced. It continues to operate and advertise the link according to RFC 2328. Added adjacencies carry their own Area IDs and their own protocol state across the same interface.

On a physical point-to-point interface, the remote address need not be configured because only one neighbor exists. On other network types, the neighbor address must be configured or learned by a mechanism outside OSPF. Control packets that would use AllSPFRouters on a point-to-point network are instead unicast to that remote address. The Area ID in a received packet determines which area-scoped adjacency handles it.

These are not fictional records. Each can fail authentication, stall during database exchange, reach FULL, influence SPF and change forwarding. The error begins only when a management system assumes that distinct protocol lifecycles imply distinct lower-layer resources.

FULL is a routing fact, not a diversity certificate

When a multi-area adjacency becomes FULL, the router adds it to the area's Router-LSA as a type 1 point-to-point link. The Link ID is the remote Router ID. Link Data is the neighbor IP address, or the interface index when the underlying link is unnumbered. Unlike an ordinary numbered point-to-point link, the implementation does not add a type 3 stub-network link for the multi-area adjacency.

FULL therefore proves something precise: the OSPF neighbors completed the relevant database synchronization for that area-scoped relationship. It does not prove an additional optic, conduit, provider order, line card, power feed or physical route. Nor does it prove that the traffic newly attracted to the link fits inside its remaining capacity.

The primary and added adjacencies may expose several green states while relying on one executable substrate. In Heng Lu's reality-layer terms, the Router-LSA edges are symbolic and computational projections. The interface counters, optical levels, circuit record and actual forwarding path occupy another layer. A sound claim moves between those layers only through explicit evidence.

The same bandwidth cannot be sold three times

Traffic-engineering extensions make the accounting hazard concrete. RFC 3630 can advertise a TE metric, maximum bandwidth, maximum reservable bandwidth, unreserved bandwidth by priority and an administrative group for a link. Those attributes describe resources associated with the underlying link. Creating another area view does not replenish them.

Suppose a 100 Gb/s circuit supports a backbone adjacency and two multi-area adjacencies. A graph database that imports three OSPF edges and assigns 100 Gb/s to each will report 300 Gb/s. A placement engine may then admit workloads against invented headroom. The arithmetic is internally consistent and physically impossible.

The inventory must have a stable physical resource identifier. Each logical adjacency points to it as a consumer or projection. Capacity totals de-duplicate on that identifier. Utilization is measured at the physical interface and apportioned or attributed to logical traffic only when the method is explicit. Administrative groups and shared-risk sets likewise attach to the resource, not independently to every area edge.

This does not make logical telemetry unimportant. Per-area LSDB, SPF, RIB and FIB changes explain why traffic moved. They simply answer a different question from the circuit inventory.

Route improvement can concentrate failure impact

The extension exists because route preference changes. Once Area 1 gains an intra-area path across the fast ABR link, traffic that previously used its slower internal topology can move onto the common circuit. Performance may improve. So can the amount of traffic exposed to that circuit's failure.

A change record should therefore capture more than neighbor state. It needs before-and-after LSDBs, SPF results, installed routes, forwarding entries, utilization, loss and congestion. It should identify the traffic that migrated, the remaining alternate paths and the threshold at which the new concentration must be rolled back or drained.

RFC 6987's stub-router behavior and RFC 9355's reverse metric show that an operator can influence path selection without changing the cable. Those controls are useful during maintenance or overload, but their survival is not evidence that forwarding has left the shared resource. The test is observed path and traffic, not the presence of a metric knob.

Asymmetric configuration is compatible and operationally expensive

RFC 5185 is backward compatible. The remote endpoint need only model the adjacency as point-to-point; it does not have to use the identical multi-area construction. The RFC recommends symmetric configuration because it makes topology representation and troubleshooting easier, but symmetry is not a protocol prerequisite.

That flexibility is a localized future decision, not permission to omit provenance. If one router calls the relationship a multi-area adjacency and its peer presents an ordinary point-to-point view, both can exchange valid OSPF state while inventories, alarms and runbooks describe the same circuit differently.

An incident handoff must retain both views: local interface, remote Router ID, remote neighbor address or discovery source, primary adjacency, added Area ID, endpoint configuration and physical circuit identity. Otherwise two teams can each be correct about their router and still disagree about what failed.

Packet demultiplexing needs a rejected ambiguity

The Area ID normally selects the adjacency. A non-backbone Area ID that matches a configured multi-area adjacency is accepted into that context. A backbone packet is more delicate because it can be associated with a virtual link or a multi-area adjacency. If the same packet matches both, RFC 5185 calls that a configuration error to be handled when the configuration is created.

This is an important control pattern. Do not let runtime ordering decide which legitimate interpretation wins. Reject the ambiguous configuration before it can create inconsistent state. Record the validation result with the change artifact, including both endpoints and every affected area.

The same discipline applies to automation outside the router. A topology importer should reject a logical link whose physical parent is unknown, rather than inventing a parent from neighbor names. A capacity engine should stop if it cannot prove whether two adjacency records share a circuit. Unknown shared fate is not independent fate.

OSPFv3 makes the separation more visible

The design also applies to OSPFv3. Its Router-LSA describes topology independently of address semantics, so an area-local point-to-point link can identify the neighbor unambiguously. Yet RFC 5185 says prefixes corresponding to the multi-area adjacency are not advertised in an intra-area-prefix-LSA, and a link-LSA should not be advertised for that adjacency. A neighbor's IPv6 link-local address can be learned from received Hello packet headers and used for next-hop calculation on multi-access networks.

The result is deliberate: topological reachability can exist without manufacturing a second set of link prefixes. A tool that expects every Router-LSA edge to carry a matching address-inventory object will either report a false defect or fabricate address data. The correct model keeps topology, addressing and physical resource evidence separate while preserving their joins.

One evidence object keeps all layers honest

For a consequential deployment, the minimum receipt includes the change ID and topology snapshot; router IDs, ABR roles and software builds; local interface; remote neighbor address and its provenance; physical circuit, conduit, line card, bundle member and provider identifier; primary adjacency; every added adjacency and Area ID; underlying network type and forced point-to-point model; interface and neighbor state transitions; Router-LSA Link ID, Link Data and metric; the expected absence of the type 3 link; OSPFv3 prefix and link-LSA behavior; before-and-after LSDB, SPF, RIB and FIB; capacity counted once; measured traffic; shared-risk

membership; endpoint symmetry; ambiguity validation; drain and rollback criteria; and the final reconciled outcome.

That is not bureaucracy around a simple feature. It is the smallest record capable of answering three different questions: what OSPF believed, what forwarding did and which physical resource made both possible.

RFC 5185 is valuable precisely because its specification is modest. It creates an area-local path and leaves operators free to decide where that path is useful. Voluntary adoption remains safe when the local system also preserves the boundary the protocol assumes: many adjacency objects may be real, while the thing they share remains singular.

Sources

  1. RFC 5185 — HTML
  2. RFC 5185 — plain text
  3. RFC Editor information page
  4. IETF Datatracker document page
  5. IETF Datatracker history
  6. IETF Datatracker references
  7. RFC 5185 errata
  8. RFC 2328 — OSPF Version 2
  9. RFC 2328 information page
  10. RFC 5340 — OSPF for IPv6
  11. RFC 5340 information page
  12. RFC 3630 — Traffic Engineering Extensions to OSPF
  13. RFC 6987 — OSPF Stub Router Advertisement
  14. RFC 7770 — Extensions to OSPF for Advertising Optional Router Capabilities
  15. RFC 8665 — OSPF Extensions for Segment Routing
  16. RFC 9355 — OSPF Reverse Metric
  17. RFC 3137 — OSPF Stub Router Advertisement
  18. Heng Lu — reality layers
  19. Heng Lu — minimum specification and voluntary adoption
  20. Heng Lu — running code is primary