OSPF Deep Dive Part 9: Junos Implementation and Gotchas

EDGE-MX is the Junos router in this series’ lab, sitting in Area 0 and originating Area 2, reachable only via the virtual link Part 4 built through Area 1. Junos gets to the same protocol outcome as Cisco and FortiOS, same states, same LSA types, same SPF math, through a configuration model that’s structured differently enough to be its own source of gotchas, mostly in Junos’s favor, with one significant exception.

Nothing joins an area by accident

Cisco’s classic network statement matches a range against every interface’s address and enables OSPF wherever it matches. FortiOS’s config network range does the same thing, without Cisco’s passive-interface default safety net, as Part 8 covered. Junos doesn’t have a range-matching mechanism for OSPF area membership at all. Every interface that participates has to be listed explicitly under the area it belongs to:

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.2 interface ge-0/0/3.0

This is the safest of the three vendors in this series by construction: there’s no broad match to accidentally over-scope, because there’s no match at all, only an explicit list. The tradeoff is verbosity on a router with many interfaces, and a different failure mode from the ones Parts 7 and 8 covered, forgetting to add a new interface to the list entirely, which produces no adjacency and no warning, rather than an unwanted adjacency on an interface that should have stayed out of OSPF.

Junos’s passive statement (set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 passive) exists for the opposite case from Cisco’s passive-interface-default pattern: it’s for an interface that should be included in OSPF’s LSAs, so its subnet gets advertised, without actually forming adjacencies over it, typically a stub LAN or a loopback. It isn’t a safety default the way Cisco’s passive-interface default is; it’s a per-interface opt-in for a specific behavior, on a platform where nothing is included by accident in the first place.

Redistribution is a routing policy, not a protocol keyword

Cisco and FortiOS both configure redistribution as a statement inside the OSPF process itself: redistribute static and its FortiOS equivalent under config redistribute. Junos treats redistribution as an instance of its general routing-policy framework, applied to OSPF via an export statement, as Part 4 introduced:

set policy-options policy-statement REDIST-STATIC term 1 from protocol static
set policy-options policy-statement REDIST-STATIC term 1 then external metric-type 1
set policy-options policy-statement REDIST-STATIC term 1 then accept
set protocols ospf export REDIST-STATIC

This isn’t just a syntax difference. A Junos policy statement can match on prefix lists, route filters, other protocols, or combinations of conditions in a single reusable object, and the same policy framework governs BGP import/export, static route generation, and OSPF export identically. An engineer coming from Cisco’s protocol-scoped redistribute statements has to internalize that Junos redistribution failures are routing-policy debugging, checking term order, checking whether a term’s from conditions actually matched, checking for an implicit final reject, rather than an OSPF-specific problem at all. show policy REDIST-STATIC and show route protocol static are the actual troubleshooting entry points, not anything under show ospf.

The naming trap from Part 4, restated plainly

Cisco and FortiOS both spell totally-stubby’s defining keyword no-summary (singular). Junos spells the equivalent no-summaries (plural). It’s a one-letter difference that autocomplete and muscle memory both fight against when switching platforms mid-session, and Junos’s commit-time syntax checking will reject the wrong spelling outright rather than silently accepting a no-op, which is at least a fast failure compared to a same-vendor gotcha that silently misconfigures.

Router-id: configure it, don’t rely on selection

Junos can technically bring up OSPF using a router-id derived from an interface address if none is configured, but Junos documentation and standard practice both treat an explicitly configured routing-options router-id as a baseline requirement, not an optional hardening step the way it’s often treated on Cisco or FortiOS. EDGE-MX’s 10.0.0.3 in this lab is set exactly this way, under routing-options, a global stanza shared across every routing protocol on the box rather than nested inside the OSPF configuration itself, which is worth knowing precisely because looking for router-id under protocols ospf on Junos, the natural place to look coming from Cisco or FortiOS, won’t find it.

The default that actually surprises people: route preference

Cisco and FortiOS both default OSPF’s administrative distance to 110, comfortably behind eBGP’s default of 20. Junos’s default preference for internal OSPF routes is 10, and eBGP defaults to 170. Junos ranks OSPF above eBGP by default, the opposite ordering from the Cisco/FortiOS convention. This has no bearing on anything covered in Parts 1 through 6, since it’s a route-selection concern for choosing between different protocols’ routes to the same destination, not anything OSPF-internal, but it’s exactly the kind of assumption that transfers silently and wrongly from Cisco experience to a Junos box: a route that would lose to eBGP on a Cisco or FortiGate for the same prefix wins on a Junos router by default, with no OSPF-side symptom at all, because the divergence is entirely in the preference table one layer above OSPF.

The commit model is a genuine safety net for OSPF changes specifically

Every change in this series so far has been framed as a direct configuration edit. On Junos, none of it takes effect until commit, and commit confirmed <minutes> automatically rolls back to the prior configuration if a confirming commit doesn’t follow within the window, which matters more for OSPF changes than most: an area-type change, a virtual-link edit, or an authentication key rotation applied to the wrong end of a link can take down an adjacency to the device an engineer is actually connected through. Neither Cisco IOS/IOS-XE (outside of configure replace with a timed rollback) nor FortiOS has an equivalent built as directly into the normal configuration workflow, and it’s worth adopting deliberately on Junos precisely because the failure mode it protects against, changes that cut off remote access, is one this series will trigger on purpose in Part 12.

Parts 10 and 11 turn from configuration to diagnosis: a vendor-neutral troubleshooting methodology, then the actual show commands and LSDB output, side by side, across all three platforms.