Symptoms
You've configured OSPF on two Juniper routers, the interfaces are up, IP reachability looks fine between the two endpoints, and yet
show ospf neighborreturns nothing — or worse, a neighbor is visible but stuck in Init or ExStart and absolutely refuses to advance. OSPF-learned routes are absent from
show route, traffic that should be following an OSPF path is black-holing or falling back to a static default, and your monitoring system is firing alerts about unreachable prefixes.
Sometimes the symptom is more subtle: the neighbor reaches 2-Way but never hits Full. Or adjacency forms briefly and then resets on a timer. Either way, the network isn't converged and you need to find out why.
The first thing to run when OSPF adjacency isn't forming is the trio of commands below. Keep these outputs visible throughout the troubleshooting process — they answer the most common questions in one pass.
infrarunbook-admin@sw-infrarunbook-01> show ospf neighbor detail
infrarunbook-admin@sw-infrarunbook-01> show ospf interface detail
infrarunbook-admin@sw-infrarunbook-01> show log messages | match OSPFThe syslog output from that last command is chronically underused. Junos logs meaningful OSPF mismatch details to
/var/log/messages, and in my experience it tells you the root cause within 30 seconds of looking — if you know what to look for. Let's walk through each failure mode.
Root Cause 1: Hello Interval or Dead Interval Mismatch
OSPF neighbors must agree on both the hello interval and the dead interval before they'll form an adjacency. These values are carried inside every hello packet, and if they don't match exactly, the receiving router discards the packet without ceremony. Junos defaults to a 10-second hello interval and a 40-second dead interval on broadcast and point-to-point links — but those defaults are easy to override, and they get overridden all the time.
In my experience this happens most often during migrations. One router is freshly provisioned with default timers. The other inherited a config that was tuned to 5-second hellos three years ago for faster convergence, and nobody documented it. The adjacency just never comes up, and both sides look perfectly healthy in isolation.
To identify this, pull the interface detail on both routers and compare the Hello and Dead values:
infrarunbook-admin@sw-infrarunbook-01> show ospf interface ge-0/0/1.0 detail
Interface State Area DR ID BDR ID Nbrs
ge-0/0/1.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
Type: LAN, Address: 10.0.12.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
Adj count: 0
Hello: 5, Dead: 20, ReXmit: 5, Not Stub
Auth type: NoneIf the remote router shows
Hello: 10, Dead: 40while this side shows
Hello: 5, Dead: 20, you've found it. Junos also logs this explicitly:
Apr 15 09:12:44 sw-infrarunbook-01 rpd[1423]: OSPF hello from 10.0.12.2 (IFL ge-0/0/1.0, area 0.0.0.1)
ignored: hello timer mismatch (ours 5, theirs 10)The fix is to decide which timer value is correct — usually the standard 10/40 unless you have a documented convergence requirement — and align both ends:
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 hello-interval 10
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 dead-interval 40
infrarunbook-admin@sw-infrarunbook-01# commitAfter committing on both sides, run
show ospf interface ge-0/0/1.0 detailto confirm the timers updated, then watch
show ospf neighbor— within one dead interval the neighbor should appear and advance to Full.
Root Cause 2: Area ID Mismatch
Every OSPF interface belongs to a specific area, and two routers peering across the same subnet must have their connecting interfaces in the same area. The area ID is embedded in every hello packet. If one side puts the interface in area 0.0.0.0 (the backbone) and the other puts it in area 0.0.0.1, the hellos arrive but get discarded — and unlike some other mismatches, this one produces no neighbor entry at all. The other router is completely invisible in
show ospf neighbor.
This happens during staged rollouts where one side of a link gets configured ahead of the other, and the operator working on the second router copies a config snippet without noticing the area ID is different. It also happens at area boundaries where someone accidentally configures the ABR's transit interface in the wrong area.
infrarunbook-admin@sw-infrarunbook-01> show ospf interface ge-0/0/2.0 detail
Interface State Area DR ID BDR ID Nbrs
ge-0/0/2.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
Type: LAN, Address: 10.0.23.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
Adj count: 0
Hello: 10, Dead: 40, ReXmit: 5, Not StubThe syslog entry is explicit and worth knowing by heart:
Apr 15 09:15:03 sw-infrarunbook-01 rpd[1423]: OSPF hello from 10.0.23.2 (IFL ge-0/0/2.0, area 0.0.0.0)
ignored: area mismatch (ours 0.0.0.0, theirs 0.0.0.1)Determine which area is correct for the link, then move the interface into that area on whichever router is wrong. If it's currently under the wrong area in the config, delete it there and re-add it under the correct one:
infrarunbook-admin@sw-infrarunbook-01# delete protocols ospf area 0.0.0.0 interface ge-0/0/2.0
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.1 interface ge-0/0/2.0
infrarunbook-admin@sw-infrarunbook-01# commitOne thing to verify after fixing: if this interface is on an ABR, confirm that the router has at least one interface (typically the loopback or a backbone-facing link) still in area 0.0.0.0. An ABR with no backbone connection will have LSA distribution problems even after the adjacency forms.
Root Cause 3: Authentication Mismatch
Junos supports both simple (plaintext) and MD5 authentication for OSPF. If one side has authentication configured and the other doesn't — or both sides have it configured but with different passwords or different authentication types — adjacency won't form. This one is particularly insidious because the failure is silent at default log levels. The router receiving an unauthenticated hello when it expects MD5 just drops the packet without logging anything obvious at INFO severity. You have to know to look at OSPF statistics or crank up trace options to catch it quickly.
The first indicator is the
Auth typeline in
show ospf interface detail. Compare both sides — one might show
Auth type: MD5while the other shows
Auth type: None.
infrarunbook-admin@sw-infrarunbook-01> show ospf interface ge-0/0/3.0 detail
Interface State Area DR ID BDR ID Nbrs
ge-0/0/3.0 DRother 0.0.0.1 0.0.0.0 0.0.0.0 0
Type: LAN, Address: 172.16.0.1, Mask: 255.255.255.252, MTU: 1500, Cost: 1
Adj count: 0
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 2026-01-01 00:00:00Then check the OSPF statistics for authentication-related drop counters:
infrarunbook-admin@sw-infrarunbook-01> show ospf statistics
Receive errors:
Bad checksum: 0
Bad version: 0
Bad area: 0
Authentication failed: 47
Bad authentication type: 3
...A non-zero count in
Authentication failedor
Bad authentication typeis definitive. Forty-seven failures in this example means packets have been arriving but getting dropped repeatedly. To fix it, ensure both sides have matching authentication type and the same key. If the remote side has no authentication configured, add it:
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.1 interface ge-0/0/3.0 authentication md5 1 key "R3dT3am$ecure99"
infrarunbook-admin@sw-infrarunbook-01# commitJunos stores the configured key in its proprietary
$9$encrypted format in the running config, so you can't read back the plaintext to verify it. The safest approach when fixing an authentication mismatch is to set the same new plaintext key on both routers simultaneously and commit both. That eliminates any ambiguity about which key was in place before.
If you need to verify authentication is working after the fix, the authentication failure counters in
show ospf statisticsshould stop incrementing. Clear them first with
clear ospf statistics, wait 60 seconds, then check again — if the counters remain at zero, authentication is passing.
Root Cause 4: MTU Mismatch
This one is subtle and particularly frustrating because the neighbor will appear in
show ospf neighbor— but it'll be stuck in ExStart or Exchange indefinitely. What's happening is that the Database Descriptor packets used during the LSDB exchange phase are too large for the effective MTU on one side of the link, so they get dropped. Both routers keep retransmitting DD packets, the exchange never completes, and the adjacency never reaches Full state.
In my experience this shows up most often on links with jumbo frames enabled on one side but not the other, on GRE or MPLS tunnels where overhead reduces the effective payload size, and on provider-managed links where the customer doesn't control the remote interface MTU.
The signature in
show ospf neighbor detailis unmistakable once you know what you're looking at:
infrarunbook-admin@sw-infrarunbook-01> show ospf neighbor detail
Address Interface State ID Pri Dead
10.0.45.2 ge-0/0/4.0 ExStart 192.168.1.2 128 32
Area: 0.0.0.0, opt: 0x52, DR: 0.0.0.0, BDR: 0.0.0.0
Up 00:08:14, adjacent 00:00:00
Retransmit list: DBD, length 1Stuck in ExStart with DBD sitting in the retransmit queue. Now check the physical MTU on both interfaces:
infrarunbook-admin@sw-infrarunbook-01> show interfaces ge-0/0/4.0 detail | match MTU
Link-level type: Ethernet, MTU: 9192, Speed: 1000mbpsinfrarunbook-admin@sw-infrarunbook-02> show interfaces ge-0/0/4.0 detail | match MTU
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbpsOne side has jumbo frames at 9192 bytes, the other is at standard Ethernet MTU. The preferred fix is to align the physical MTU on both sides — match them either both to standard or both to jumbo, depending on your network design. If you can't touch the remote interface — carrier link, third-party device — Junos has an escape hatch:
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 ignore-mtu-mismatch
infrarunbook-admin@sw-infrarunbook-01# commitUse
ignore-mtu-mismatchdeliberately, not carelessly. It tells OSPF to skip the MTU check during DD exchange, which lets the adjacency form — but it doesn't solve the underlying fragmentation problem. Large LSAs can still get dropped mid-path if the MTU is genuinely inconsistent across the link. The right answer is always aligning MTU at the interface level and treating
ignore-mtu-mismatchas a workaround of last resort.
Root Cause 5: Interface Configured as Passive
A passive OSPF interface advertises its connected prefix into the OSPF topology but doesn't send or receive hello packets. No hellos means no adjacency — ever. It's the correct setting for loopbacks, out-of-band management interfaces, and stub segments you want OSPF to know about without running a full routing protocol. The problem is when it ends up on a transit link by accident.
This happens when someone uses a configuration pattern like
interface all passiveto suppress hellos on all interfaces, then adds explicit non-passive overrides for each transit link — and misses one. It also happens when a config is cloned from a device where a given interface was passive, and the operator doesn't notice the flag carried over.
The
show ospf interface detailoutput tells you directly — look for the word
Passivein the adjacency count line:
infrarunbook-admin@sw-infrarunbook-01> show ospf interface ge-0/0/5.0 detail
Interface State Area DR ID BDR ID Nbrs
ge-0/0/5.0 PtToPt 0.0.0.2 0.0.0.0 0.0.0.0 0
Type: P2P, Address: 10.10.10.1, Mask: 255.255.255.252, MTU: 1500, Cost: 1
Adj count: 0, Passive
Hello: 10, Dead: 40, ReXmit: 5, Not StubThe
Passiveflag is your answer. To remove it:
infrarunbook-admin@sw-infrarunbook-01# delete protocols ospf area 0.0.0.2 interface ge-0/0/5.0 passive
infrarunbook-admin@sw-infrarunbook-01# commitAfter committing, hellos start flowing immediately. You should see the neighbor appear and reach Full state within one dead interval. Note that if your config uses the
interface all passivepattern, removing the passive flag on a single interface requires adding an explicit non-passive override rather than a delete:
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.2 interface ge-0/0/5.0 no-eligible-backup
[or, to explicitly override the interface-all passive:]
infrarunbook-admin@sw-infrarunbook-01# set protocols ospf area 0.0.0.2 interface ge-0/0/5.0
infrarunbook-admin@sw-infrarunbook-01# delete protocols ospf area 0.0.0.2 interface ge-0/0/5.0 passive
infrarunbook-admin@sw-infrarunbook-01# commitAlways verify the interface is no longer passive after the commit — confirm
Adj count: 0, Passiveis gone from the detail output before closing the change.
Root Cause 6: Subnet Mask Mismatch
On broadcast and NBMA network types, OSPF validates that both routers on the same segment have matching subnet masks on their connecting interfaces. If one side has a /30 and the other has a /29, the hello is discarded. This sounds like a basic IP addressing error — and it is — but it surfaces more often than you'd expect in environments where IP addressing is managed by a separate team from the routing team, or where interface configurations are edited manually and cross-checked only after the fact.
The syslog entry is explicit:
Apr 15 10:03:17 sw-infrarunbook-01 rpd[1423]: OSPF hello from 192.168.100.2 (IFL ge-0/0/6.0, area 0.0.0.0)
ignored: netmask mismatch (ours 255.255.255.252, theirs 255.255.255.248)Fix the IP addressing on the affected interface so both sides use the same subnet mask, then recommit. OSPF is working exactly as designed here — it's refusing to form an adjacency across a subnet that isn't consistently defined, which is the correct behavior. Don't work around this with
ignoreflags; fix the IP configuration.
Root Cause 7: Router ID Conflict
If two routers in the same OSPF domain share the same Router ID, the behavior ranges from unpredictable to actively harmful. Neighbors may form and then flap on a timer, LSAs from one router overwrite the other's, and routing loops become possible. Junos selects its Router ID automatically from the highest loopback address configured — but if loopbacks are inconsistently configured or if someone explicitly sets a
router-idunder
routing-optionsto the same value as another device, you'll have a conflict.
The tell-tale sign is two neighbors with different IP addresses but the same Router ID in
show ospf neighbor:
infrarunbook-admin@sw-infrarunbook-01> show ospf neighbor
Address Interface State ID Pri Dead
10.0.12.2 ge-0/0/1.0 Full 192.168.1.1 128 35
10.0.23.2 ge-0/0/2.0 Init 192.168.1.1 128 38Two different neighbors — 10.0.12.2 and 10.0.23.2 — both claiming Router ID 192.168.1.1. Assign unique loopback addresses on every router in the domain and make sure the Router ID derives from or is explicitly set to a unique value:
infrarunbook-admin@sw-infrarunbook-02# set routing-options router-id 192.168.1.2
infrarunbook-admin@sw-infrarunbook-02# commitIn most Junos versions a commit is sufficient to trigger a Router ID change and OSPF renegotiation. In some older versions you may need to restart rpd with
restart routingto force the new Router ID into effect. After the fix, verify that every router in your OSPF domain has a unique ID —
show ospf database routerlists all Router IDs in the domain and is a quick sanity check.
Prevention
Most OSPF adjacency failures trace back to configuration inconsistency across devices. The most effective prevention strategy is to template your OSPF configuration in your automation toolchain — Ansible, Salt, or even Jinja2 fed through Netconf — so that hello intervals, area IDs, authentication keys, and MTU settings are rendered from a single source of truth rather than typed by hand on each device. When every router in a given role gets identical OSPF parameters from the same template, the class of mismatches described in this article largely disappears.
For authentication, default to MD5, rotate keys on a regular schedule, and manage them in a secrets store rather than in plaintext automation variables. Junos supports MD5 key rollover natively — you can configure multiple keys with different start times and let the router transition between them without dropping adjacencies. Use that feature.
MTU consistency deserves its own policy: document the effective OSPF MTU for each link type in your runbook and enforce it through interface templates. If you're running OSPF over tunnels or MPLS, calculate the encapsulation overhead carefully and either set
ip-mtuexplicitly on the OSPF-facing interface or make a deliberate, documented decision to use
ignore-mtu-mismatch. The worst outcome is using it as an undocumented workaround that gets inherited into future configs.
Passive interface configuration should follow a strict, written convention: passive on loopbacks and dedicated management interfaces, never on transit links. If your OSPF config uses the
interface all passivepattern with per-interface non-passive overrides, audit every transit interface to confirm the override is present. One missing line and you're chasing a phantom adjacency failure at 2am.
Get in the habit of running
show ospf interface detailand
show ospf neighbor detailimmediately after any OSPF-related config change, and before closing a maintenance window. Catching a timer mismatch while you're already logged into both routers is far less painful than diagnosing it from a ticket the next morning. Keeping a saved baseline of
show ospf neighbor summaryoutput for each device — captured post-change and filed in your IPAM or documentation system — gives you a quick reference for what a healthy state looks like when something goes wrong later.
Finally, enable OSPF tracing selectively during troubleshooting, and disable it when you're done. Leaving
traceoptionsrunning in production generates significant log volume and can impact rpd performance on high-adjacency-count routers. Use it as a diagnostic tool, not a permanent fixture.