OSPF Subnet Mask Mismatch: How to Troubleshoot and Fix

On broadcast networks, every OSPF hello packet carries the subnet mask of the interface that sent it, and the receiving router checks that mask against its own. If the two disagree, the hello is rejected, the routers never see each other as valid neighbors, and the adjacency either never forms or quietly dies. It is one of the strictest and least forgiving checks in OSPF neighbor formation, and this article covers how to spot it and fix it - part of our full OSPF guide, with all output taken from a live Cisco Modeling Labs topology on IOS XE 17.18.

What makes this failure sneaky is that everything else keeps working. With one side at /24 and the other at /25 on the same wire, both addresses may still sit in overlapping ranges, so ping succeeds, ARP resolves, CDP sees the neighbor - and OSPF alone refuses to play. It is a classic typo failure: someone fat-fingers 255.255.255.128 for 255.255.255.0 during an address change, and the adjacency drops forty seconds later.

The symptom: hellos rejected, then the dead timer fires

In the lab: R1 and R2 share a LAN in area 0 (10.0.12.0/24). We changed R1's Ethernet0/0 mask to /25 while R2 stayed at /24, then ran debug ip ospf hello on R2:

*Jul  4 23:38:08.575: OSPF-1 HELLO Et0/0: Mismatched hello parameters from 10.0.12.1
*Jul  4 23:38:18.139: OSPF-1 HELLO Et0/0: Mismatched hello parameters from 10.0.12.1
*Jul  4 23:38:48.536: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

The pattern reads exactly like a timer mismatch: R1's hellos keep arriving every ten seconds, R2 rejects each one as Mismatched hello parameters, and because rejected hellos do not reset the dead timer, the existing adjacency runs out its forty seconds and collapses from FULL to DOWN with Dead timer expired. If there was no adjacency to begin with, you simply see the mismatch lines repeat forever while show ip ospf neighbor stays empty for that interface.

And that is the key diagnostic point: Mismatched hello parameters is a shared error message. The hello's checked fields include the hello interval, the dead interval, and the network mask, and IOS prints the same debug line whichever one disagrees. So the workflow is: see the line, compare hello and dead timers on both sides, and if the timers match, check the mask. (For the other failure modes that keep neighbors down, work through troubleshooting OSPF neighbors not forming.)

Checking the mask the fast way

show ip ospf interface puts the mask, the area, and the network type on adjacent lines, which makes side-by-side comparison across two routers quick:

R2# show ip ospf interface Ethernet0/0
Ethernet0/0 is up, line protocol is up
  Internet Address 10.0.12.2/24, Interface ID 2, Area 0

Run the same command on the other router and compare the Internet Address line. In our broken state, R1 showed /25 where R2 showed /24. That is the entire diagnosis. The debug is useful for proving OSPF is actively rejecting hellos, but two copies of this output are usually faster than turning on debugging at all.

Why point-to-point links do not care

Here is the wrinkle that surprises people: the mask check only applies on network types that model a shared segment. On a point-to-point network type, OSPF skips the mask comparison entirely - RFC 2328 says so explicitly - because two routers on a dedicated link do not need to agree on a common subnet definition to exchange routes. A serial link, or an Ethernet link converted with ip ospf network point-to-point, will happily form a FULL adjacency with /30 on one end and /24 on the other.

That behavior cuts both ways. It means a mask typo on a point-to-point link will not take your adjacency down, but it also means the typo survives silently: the link works, while the two routers advertise different prefixes for the same wire into the LSDB, and downstream routers see inconsistent routes for it. So do not rely on OSPF to police your addressing on point-to-point links - it will not. It is also why the same misconfiguration can appear to be "intermittent" to a team migrating links between broadcast and point-to-point types: the mask mismatch only bites on the broadcast segments.

The fix

Correct the mask on whichever side is wrong, so both interfaces agree on the prefix:

R1(config)# interface Ethernet0/0
R1(config-if)# ip address 10.0.12.1 255.255.255.0

The next hello from R1 passes validation, the routers walk back up through the neighbor state machine (2-WAY, EXSTART, EXCHANGE, LOADING - the full ladder is in OSPF neighbor states explained), and within seconds the table returns to the healthy baseline we started the lab with:

R2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:34    10.0.12.1       Ethernet0/0
3.3.3.3           1   FULL/BDR        00:00:34    10.0.23.1       Ethernet0/1

While you are in there, decide which mask was actually intended. Fixing the router that disagrees with the addressing plan (not just the one that is easier to reach) saves you from re-breaking the segment when the next device joins it.

Key Takeaways

• OSPF hellos on broadcast networks carry the subnet mask, and both ends of a segment must agree, or hellos are rejected and no adjacency forms.
• The debug signature is Mismatched hello parameters followed by Dead timer expired - the exact same lines as a timer mismatch. If the timers match, check the mask.
• Compare the Internet Address line of show ip ospf interface on both routers; it is faster than debugging.
• Point-to-point network types skip the mask check, so mismatches there form FULL anyway - convenient, but it lets addressing errors hide in the LSDB.
• Fix the mask to match the addressing plan, and the adjacency rebuilds to FULL on its own within seconds.