Junos OSPF Configuration: Areas, Interfaces and Verification

OSPF configuration on Junos OS follows a different mental model than Cisco IOS: instead of typing network statements under a routing process, you attach interfaces directly to an area at the [edit protocols ospf] hierarchy. This guide walks through single-area and multiarea Junos OSPF configuration with copy-paste CLI commands, explains the router roles (internal, ABR, backbone and ASBR), and shows the exact operational commands that prove adjacencies and LSDBs are healthy.

Why OSPF Areas Matter on Junos

An OSPF autonomous system can be split into areas to reduce link-state advertisement (LSA) flooding, routing overhead and the size of the topology database each router must keep. Every router inside an area stores an identical LSDB; the area topology stays hidden from the rest of the AS. Before you configure anything, decide which roles your devices play: internal routers sit in one area, area border routers (ABRs) connect one or more areas to the backbone, and AS boundary routers (ASBRs) exchange routes with non-OSPF networks.

Junos enforces the area rules more strictly than some platforms, and two of them drive most configuration decisions. The backbone must be area 0.0.0.0, every non-backbone area must touch it (directly, through a virtual link, or via a tunnel), and any router with an interface in area 0 plus another area automatically becomes an ABR. The second is that the interface, not the subnet, is the unit of membership: a single physical interface can carry a logical unit in a different area, which is exactly what a virtual link or a per-VLAN OSPF design relies on.

Plan the addressing so each area maps to a contiguous block of interface addresses. Junos does not require it — there is no network statement to match — but a clean area-to-subnet mapping makes summarisation on the ABR and troubleshooting at 2 a.m. far simpler.

Junos OSPF Single-Area Configuration

The backbone always uses area ID 0.0.0.0. A single-area network is the simplest start — enable OSPF on each interface that should participate and commit:

[edit]
set protocols ospf area 0.0.0.0 interface ge-0/0/0
set protocols ospf area 0.0.0.0 interface ge-0/0/1
set protocols ospf area 0.0.0.0 interface lo0.0 passive
commit

Making the loopback passive advertises the router-id network without forming adjacencies on it. Set a stable router ID before bringing up neighbors:

set interfaces lo0 unit 0 family inet address 10.255.0.1/32
set routing-options router-id 10.255.0.1
commit

If neither router-id nor a loopback address exists, Junos elects the highest interface address at the moment OSPF starts — and the adjacency survives until that address changes. On a chassis that has just been renumbered, that is a recipe for a one-sided adjacency that clears and re-forms. Always set routing-options router-id explicitly on every device.

Two optional statements are worth adding while you are still in the stanza. Interface type overrides how OSPF sees the medium, and BFD gives sub-second failure detection for the same neighbor:

set protocols ospf area 0.0.0.0 interface ge-0/0/2 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2 bfd-liveness-detection minimum-interval 300
set protocols ospf area 0.0.0.0 interface ge-0/0/0 hello-interval 5
set protocols ospf area 0.0.0.0 interface ge-0/0/0 dead-interval 20
set protocols ospf area 0.0.0.0 interface ge-0/0/0 metric 20

On a point-to-point link, interface-type p2p removes the DR/BDR election and speeds up convergence. Hello and dead intervals must match on both ends of a segment or the neighbor never leaves Init; the dead interval is normally four times the hello interval. Interface metric maps directly to OSPF cost and is the knob you will tune most often when steering traffic away from a slow link.

Junos OSPF Multiarea Configuration (ABR)

To make a device an ABR, configure interfaces in the backbone plus another area. Each area statement is independent:

[edit]
set protocols ospf area 0.0.0.0 interface ge-0/0/0
set protocols ospf area 0.0.0.7 interface ge-0/0/2
set protocols ospf area 0.0.0.7 stub
set protocols ospf area 0.0.0.7 stub default-metric 10
commit

Configure the stub statement on every router inside area 7; only the ABR needs default-metric, which injects the default route that lets stub routers reach external destinations. Adding no-summaries on the ABR blocks Type 3 summary LSAs and converts the area into a totally stubby area. Areas that must import redistributed external routes while still filtering Type 5 LSAs should use NSSA instead.

A complete design mixing both looks like this on the ABR — one stanza per area, each with its own behaviour:

set protocols ospf area 0.0.0.0 interface ge-0/0/0
set protocols ospf area 0.0.0.0 interface ge-0/0/1
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.7 stub no-summaries
set protocols ospf area 0.0.0.7 interface ge-0/0/2
set protocols ospf area 0.0.0.8 nssa default-lsa default-metric 10
set protocols ospf area 0.0.0.8 interface ge-0/0/3

The mismatch trap is worth repeating: a stub or NSSA flag set on an ABR but not on the internal routers leaves every adjacency in the area stuck at ExStart, because the hello packets advertise different options bits. Make the area-type statement part of the same change window as the interface configuration, and verify with show ospf interface detail on both ends.

Redistribution and the ASBR Role

A router becomes an ASBR when it injects routes from outside OSPF — a static default, a BGP-learned prefix, a connected subnet belonging to another protocol. Junos does this with a routing policy, not with a redistribute statement:

set policy-options policy-statement EXPORT-OSPF term STATICS from protocol static
set policy-options policy-statement EXPORT-OSPF term STATICS from route-filter 0.0.0.0/0 exact
set policy-options policy-statement EXPORT-OSPF term STATICS then accept
set policy-options policy-statement EXPORT-OSPF then reject
set protocols ospf export EXPORT-OSPF

An OSPF export policy affects only this router's own route injection; it does not filter what OSPF learns. Prefixes redistributed into a normal area arrive as Type 5 externals, into an NSSA as Type 7 (translated back to Type 5 by the ABR). If you would rather not confuse stub routers with externals at all, keep the area stubby and let the ABR originate a default instead.

Verifying Junos OSPF Adjacencies

After commit, confirm the protocol stanza and then check neighbor state from operational mode:

show protocols ospf
show ospf interface detail
show ospf neighbor
show ospf neighbor detail

Neighbors should reach Full. If two devices never form an adjacency, check that area IDs match on the shared segment, the router IDs are unique, MTU matches (or ospf mtu-ignore is set), and no firewall filter silently drops protocol 89 traffic.

Once the neighbors are up, verify what OSPF actually computed rather than trusting the adjacency alone:

show ospf database
show ospf database summary
show ospf database external
show ospf route
show route protocol ospf
show ospf overview

show ospf route lists the SPF result (intra-area, inter-area and external entries) with the outgoing interface and next hop, which is the fastest way to spot a route that is being advertised but not installed. show ospf overview reports the router ID, the areas this device belongs to, and the SPF statistics — a climbing SPF count after a change usually means an unstable link is triggering recalculation.

For a problem that survives the basics, enable tracing and read the packet-level record of the adjacency attempt:

set protocols ospf traceoptions file ospf.log
set protocols ospf traceoptions flag hello detail
set protocols ospf traceoptions flag error detail

Then inspect the log from operational mode with show log ospf.log | last 100. A hello received with the wrong area ID, an authentication mismatch, or a duplicate router ID appears as an explicit error line, which is much faster than comparing counters by hand.

One Area or Many? A Design Rule of Thumb

Junos will happily run an entire campus in area 0, and for a few dozen routers that is often the right answer: fewer LSAs to reason about, no summarisation to get wrong, and no risk of a misconfigured area type breaking an adjacency. Split into additional areas when one of three pressures appears. The first is LSDB size — once the database grows into the hundreds of entries and the routers are ageing, summarisation at an ABR shrinks it. The second is stability: a flapping link in one large area triggers SPF on every router, while the same link inside a stub area is contained by the ABR. The third is policy — stub, totally stubby and NSSA areas let you say "this site does not need to know about the rest of the network" without running a routing filter on every device. Keep the number of areas low, keep each one topologically clean, and use area-range on the ABR so one summary is advertised per area instead of every prefix:

set protocols ospf area 0.0.0.7 area-range 10.7.0.0/16
set protocols ospf area 0.0.0.7 area-range 10.7.0.0/16 restrict

An area-range with restrict suppresses the component routes entirely and advertises only the aggregate, which is what you want when an area should be reachable as a single summary. Without restrict, the summary is advertised alongside any more specific prefixes that fall outside the range.

Junos and IOS: Two Configuration Models

The most common migration mistake is hunting for the IOS network statement. Junos has no equivalent: an interface participates in OSPF when it appears under [edit protocols ospf area <id>], and its advertised prefix comes from the interface address itself, not from a wildcard mask typed into the routing process. That single difference cascades through everything else — the router ID comes from routing-options router-id rather than being taken from a loopback automatically, redistribution is an export policy rather than a redistribute subcommand, and passive interfaces are explicit per-interface flags. Once that mapping is internalised, the verification commands read almost like their IOS counterparts and the operational confidence follows quickly.

Common Junos OSPF Pitfalls

• Bare interface names such as ge-0/0/0 imply unit 0; for a tagged subinterface you must write the full ge-0/0/0.100 name.
• Leaving the loopback non-passive forms an adjacency to itself on some designs and injects a duplicate LSA.
• Forgetting passive on an interface that connects to a host segment produces pointless hellos and log noise.
• Using an export policy to "filter" inbound routes — it does nothing for that; use an import policy or an area range instead.
• Changing the area ID on only one side of a link, which leaves both neighbors retrying hellos forever with no loopback of an error.
• Setting an MTU larger than the physical path supports on the OSPF interface, producing ExStart or Exchange states instead of Full.

Design Notes and Related Reading

Understand how stub, totally stubby and NSSA areas interact with LSA types in our OSPF area types guide. All Junos configuration changes should be staged with commit confirmed and rollback, and once OSPF is running, inter-area traffic often needs static routes with qualified next hops for backup paths. For neighbouring platforms, compare this stanza-by-stanza with NX-OS OSPF examples and Dell OS10 OSPF configuration, and use BFD liveness detection when you need faster failure detection than hellos can give.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/ospf/topics/topic-map/configuring-ospf-areas.html