ospf

Pre-Alpha. This page describes behavior that may change.

Ze includes an experimental native OSPF engine under the ospf config root. One engine drives OSPFv2 for IPv4 and OSPFv3 for IPv6. The root container configures IPv4; ospf { address-family ipv6 { ... } } enables the OSPFv3 instance on the same engine.

Interface and neighbor state, LSDB flooding, SPF, ABR and NSSA policy, redistribution, and route installation are shared between the two families. Only the wire codec, the raw transport, and the prefix strategy are address-family specific. The IPv4 codec and IPv4 raw transport (protocol 89, 224.0.0.5 / 224.0.0.6) live in internal/plugins/ospf; the OSPFv3 IPv6 codec and IPv6 transport (protocol 89, ff02::5 / ff02::6, link-local source) live in internal/plugins/ospfv3.

SPF builds one graph per area from Router-LSAs and Network-LSAs, enforces the RFC 2328 two-way check, derives next-hops from the Router-LSA link data, merges equal-cost next-hops, and installs one route per next-hop. Selected routes go through the shared Loc-RIB to sysrib to fibkernel path with OSPF administrative distance 110. OSPF does not use redistribution events to reach the kernel FIB.

Areas and ABR

Areas are declared under areas, and each interface binds to a declared area through interfaces/interface/area. A router is treated as an Area Border Router (ABR) only when it is active in the backbone (0.0.0.0) and at least one other area.

An ABR originates Type 3 Summary-Network LSAs and Type 4 Summary-ASBR LSAs, applies configured area ranges (with optional cost or not-advertise), withdraws stale self-originated summaries, accepts backbone summaries when calculating on an ABR, and computes the inter-area cost as the cost to the advertising ABR plus the summary metric.

ospf {
    router-id 10.0.0.1
    reference-bandwidth 100000
    maximum-paths 8

    areas {
        area 0.0.0.0 {
            area-type normal
        }
    }

    interfaces {
        interface eth0 {
            area 0.0.0.0
            network-type point-to-point
            hello-interval 10
            dead-interval 40
            priority 1
        }
        interface lo0 {
            area 0.0.0.0
            network-type loopback
        }
    }
}

network-type accepts broadcast, point-to-point, or loopback. A loopback record sends no Hellos and opens no raw socket. router-id must be a dotted quad when set; if it is omitted, Ze derives one from the highest loopback IPv4 address, then the highest interface IPv4 address. YANG range-checks the numeric leaves: maximum-paths 1..32, interface cost 1..65535, priority 0..255, and OSPF metrics 0..16777215.

OSPFv3 (IPv6)

The IPv6 address family mirrors the area and interface model under address-family ipv6. The presence of the ipv6 container enables the OSPFv3 instance; instance-id defaults to 0 and is used for the RFC 5340 per-link demultiplex.

ospf {
    router-id 172.30.0.2
    address-family ipv6 {
        instance-id 0
        areas {
            area 0.0.0.0 {
                area-type normal
            }
            area 0.0.0.9 {
                area-type nssa
            }
        }
        interfaces {
            interface eth0 {
                area 0.0.0.0
                network-type point-to-point
            }
            interface eth1 {
                area 0.0.0.9
                network-type point-to-point
            }
        }
    }
}

The OSPFv3 transport uses the interface IPv6 link-local (fe80::/10) address as the source. If that address is not ready yet (IPv6 Duplicate Address Detection), the interface open is marked pending and retried by the periodic rescan and on interface/addr-added. The OSPFv3 packet checksum is the IPv6 upper-layer checksum over a pseudo-header that includes the IPv6 source and destination (RFC 5340), so the transport finalizes it from the egress link-local source on transmit. OSPFv3 sends with IPv6 Hop Limit 1, matching FRR ospf6d.

Stub and NSSA areas

area-type selects normal, stub, or nssa. A stub or NSSA area can set default-cost (the injected default metric) and no-summary true for a totally-stubby or totally-NSSA area.

A stub area carries no AS-External information. The E-bit is clear in every Hello and Router-LSA originated within it (a Hello whose E-bit does not match is dropped and no adjacency forms), Type 4 ASBR-Summary and Type 5 AS-External LSAs are neither accepted from nor flooded into the area, and each attached ABR injects a single Type 3 default (0.0.0.0/0; OSPFv3 injects the equivalent ::/0 as an Inter-Area-Prefix-LSA) at the configured default-cost. A totally-stubby area (no-summary true) additionally suppresses every inter-area Type 3 summary except that default, so a spoke holds only intra-area routes plus one default.

An NSSA (area-type nssa, RFC 3101) is stub-like but permits local external redistribution. The N-bit must match between neighbours (the E-bit stays clear as in a stub). An NSSA ASBR originates Type 7 / NSSA LSAs for the routes it redistributes. In OSPFv3 the P-bit lives in the prefix options and a non-zero IPv6 forwarding address is carried in the external body. A router that cannot inject a Type 5 directly sets the P-bit so its Type 7 is translatable; one that can clears it. The ABR may also originate a Type 7 default (nssa { default-originate true }).

ospf {
    router-id 10.0.0.1
    areas {
        area 0.0.0.0 {
            area-type normal
        }
        area 0.0.0.9 {
            area-type nssa
            no-summary true
            default-cost 20
            nssa {
                translate-role candidate
                stability-interval 40
                default-originate true
            }
        }
    }
    interfaces {
        interface eth0 { area 0.0.0.0 }
        interface eth1 { area 0.0.0.9 }
    }
}

Type 7 to Type 5 translation

Among the ABRs attached to an NSSA, exactly one is elected the Type 7 to Type 5 translator (RFC 3101 section 3.5): the translator-candidate ABR with the highest Router ID. Each ABR whose role is not never advertises the Nt-bit in its Router-LSA to stand as a candidate. A never ABR clears the Nt-bit and is excluded, so it cannot wedge translation off for a willing lower-Router-ID candidate. The role is configurable per area (nssa { translate-role candidate|always|never }) and is sticky across a stability-interval (default 40 seconds).

The elected translator re-originates each P=1, non-zero forwarding-address Type 7 as a Type 5 onto the backbone (P cleared, Advertising Router set to the translator, forwarding address / metric / tag preserved), counted by ze_ospf_nssa_translations_total{area}. A non-elected ABR does not translate, so no duplicate Type 5 reaches the backbone. When the same external prefix is known via a Type 7 (P=1), a Type 5, and a Type 7 (P=0), the route computation prefers them in that order (RFC 3101 section 2.5).

AS-external routes and redistribution

A router becomes an AS Boundary Router (ASBR) when it originates external LSAs, either by redistributing routes from another protocol or through default-information originate. The ASBR and ABR roles are independent. OSPFv2 uses Type 5 AS-External-LSAs; OSPFv3 uses AS-External-LSAs (0x4005) in normal areas and NSSA-LSAs (0x2007) in attached NSSA areas. AS-scoped Type 5 / 0x4005 LSAs live in an AS-wide store, separate from the per-area LSDBs.

Redistribution uses the shared redistribute orchestrator. The ospf container sets the per-source external metric, metric-type (type-1 / type-2), and route tag. The top-level redistribute block enrols the actual route flow:

• redistribute { destination ospf { import connected static bgp } } injects each accepted route as an external LSA in the configured address family (Type 5 for IPv4, AS-External-LSA for normal IPv6 areas, NSSA-LSA for attached IPv6 NSSA areas).
• redistribute { destination bgp { import ospf } } exports OSPF-selected routes back into BGP.

import ospf into OSPF itself is a runtime no-op (loop prevention: the import source equals the importing protocol). An unenrolled source falls back to metric 20, type-2. The source list accepts connected, static, kernel, bgp, and isis.

ospf {
    router-id 10.0.0.1

    default-information {
        originate true
        always false
        metric 10
        metric-type type-2
    }

    redistribute {
        connected {
            metric 20
            metric-type type-2
            tag 100
        }
        static {
        }
    }

    areas { area 0.0.0.0 { } }
    interfaces { interface eth0 { area 0.0.0.0 } }
}

redistribute {
    destination ospf {
        import connected
        import static
        import bgp
    }
    destination bgp {
        import ospf
    }
}

External SPF and metric types

Received external LSAs are resolved by the external SPF stage, which runs after the intra-area and inter-area route tables are built. Each external is resolved against its ASBR (or a non-zero forwarding address, re-resolved through the route table; unreachable externals are skipped).

Metric type	Cost formula	Tie-break
Type 1 (E1)	distance to the forwarding target plus the advertised metric	shortest path wins
Type 2 (E2)	the advertised metric only	the forwarding distance

A Type 1 external always wins over a Type 2 regardless of cost, and any external ranks below an intra-area or inter-area route for the same prefix. Unlike IS-IS, OSPF externals carry an explicit metric type, so E1 routes accumulate the IGP distance while E2 routes do not.

Default-information originate

default-information originate advertises a Type 5 default (0.0.0.0/0). With always true it originates unconditionally; with always false it originates only while a non-OSPF default route exists in the Loc-RIB (OSPF's own default does not satisfy the condition). The engine re-evaluates the condition at config-apply and live on Loc-RIB default-route changes, withdrawing the Type 5 when the condition lapses.

OSPFv3 Link-LSAs

OSPFv3 Link-LSAs (0x0008) are stored in a link-scoped LSDB keyed by the receiving interface, not in the area or AS-wide stores. Ze originates one self Link-LSA per active OSPFv3 interface, carrying the interface link-local address and the routable IPv6 prefixes, floods it only on that link, and releases the link store when the interface is removed. During database exchange, link-scoped LSAs participate in DD summaries and LS Request lookup using the interface context.

Authentication

OSPFv2 packets can be authenticated per interface with a named key chain (RFC 2328 Appendix D, RFC 5709, RFC 7474). The scheme is selected by the key algorithm and the chain's extended-sequence flag.

AuType	Scheme	Selected by
0	None	no chain bound
1	Simple 8-byte cleartext password	algorithm simple
2	Keyed-MD5 or HMAC-SHA-1/256/384/512	algorithm md5 / hmac-sha-*, extended-sequence false
3	Same HMAC-SHA algorithms with a 64-bit extended cryptographic sequence number	algorithm hmac-sha-*, extended-sequence true

Every outgoing packet is signed and every incoming packet is verified before it reaches the ISM/NSM/LSDB. A packet that fails is dropped before any protocol processing and increments ze_ospf_auth_failures_total{interface,reason}. All digest and password comparisons are constant-time. The cryptographic sequence number is non-decreasing per neighbour, key-id, and packet type, so a replayed packet is rejected; the send counter is seeded from a monotonic clock so it does not regress across a restart. For AuType 3 the IP source address is bound into the digest (RFC 7474), so a spoofed source fails verification.

Keys are organised as named chains for hitless rotation: a chain holds multiple keys, the first signs, and any chain key is accepted on receive during the overlap window. Bind a chain to an interface directly, or set the interface authentication { mode inherit } so it uses the chain bound to its area. Secrets are stored $9$-encoded and never appear in plaintext in show configuration or backups.

ospf {
    router-id 10.0.0.1
    key-chains core {
        extended-sequence true
        key 1 {
            algorithm hmac-sha-256
            secret $9$encoded
        }
    }
    areas {
        area 0.0.0.0 {
            authentication { key-chain core }
        }
    }
    interfaces {
        interface eth0 {
            area 0.0.0.0
            authentication { mode inherit }
        }
    }
}

OSPFv3 packets can carry an RFC 7166 Authentication Trailer; when its signer is installed the OSPFv3 packet checksum is left zero and the trailer provides integrity.

Web UI

The neighbor and database views are available in the web UI, with live updates over SSE.

URL	Purpose
/ospf	OSPF process and neighbor view.
/ospf/database	LSDB browser, live SSE updates.

CLI commands

Operational state is available through the show ip ospf command tree.

Command	Output
show ip ospf	Process summary: router-id, ABR/ASBR status, areas, and the active stub-router / max-metric state.
show ip ospf neighbor	Neighbour adjacencies and their states.
show ip ospf interface	Per-interface OSPF state.
show ip ospf database [router|network|summary|asbr-summary|external|nssa-external]	Every LSA, or one LS Type (1/2/3/4/5/7) filtered view.
show ip ospf route	Area, prefix, metric, path type, advertising router, and the equal-cost next-hop set.
show ip ospf spf	Per-area SPF run state: last run time, duration, node count, pending state, current throttle delay.
show ip ospf border-routers	Reachable ABRs and ASBRs with area, metric, and next-hop set.

The runtime can be reset without reconfiguring:

Command	Effect
clear ip ospf process	Tear down adjacencies and re-run SPF.
clear ip ospf neighbor	Re-form adjacencies.
clear ip ospf counters	Reset the SPF-run log.

See also

• Redistribution for the cross-protocol import/export model OSPF shares with BGP and IS-IS.
• FIB for the Loc-RIB to sysrib to fibkernel installation path.
• BFD for sub-second forwarding-failure detection.
• Web UI for the browser surfaces, including /ospf.
• Plugins for the plugin list.

Adapted from docs/guide/ospf.md.