Troubleshooting OSPF Neighbor Mismatch

Effectively on Junos
As a JNCIE-SP candidate, you’re expected to troubleshoot OSPF neighbor mismatch
quickly. So, in this article, we’ll recap all the OSPF attributes and criteria that must match
before OSPF routers actually become functional neighbors. Next, I’ll show you which show
commands and traceoptions flags are more appropriate to troubleshoot effectively such
OSPF neighbor mismatches that you’re likely to encounter. Plus, it’s worth mentioning
that being able to effectively troubleshoot these type of mismatches is really such a valuable
skill to have, especially if you work in a multi vendor environment.

OSPF Neighborship Criteria

Cutting to the chase, Table 1 shows the criteria that OSPF routers must match (or be
compatible) before becoming functional neighbors.

OSPF attribute Further information

In the routing graph, every OSPF node/router is expected to have an UUID,

Unique router-id
otherwise Dijkstra’s algorithm would perceive two nodes as being the same.

Area Area ID 32-bit

Area flags Stub/NSSA flag

Authentication type MD5 (type 2), Simple (type 1) or None (type 0)

Authentication
The authentication secret itself
password
 OSPF attribute Further information

Hello/Dead interval By default, hello = 10s and dead = 40s

L3 MTU The MTU announced on OSPF DBD packets

Compatible The network type must be consistent on the network segment. You’d have a broken
network type graph if one OSPF node is expecting to have a DR and other OSPF nodes aren’t.

Network Mask Since the network mask is coupled with the underlying graph, it has to match.

Table 1 - OSPF neighborship attributes

Great! Now that we just reviewed the attributes that have to match, let’s simulate a
mismatch for each of them and verify which show commands and traceoptions flags would
be appropriate to troubleshoot the specific situation. I’ll use two OSPF routers, vMX1 and
vMx2, to simulate these conditions as illustrated in Figure 1.

Topology

Figure 1 - OSPF topology vMX1 and vMX2

Base configuration

vMX1
1root@vMX1# show interfaces
2ge-0/0/0 {
3 unit 0 {
4 family inet {
5 address 10.1.2.1/24;
 6 }
7 }
8}
9lo0 {
10 unit 0 {
11 family inet {
12 address 1.1.1.1/32;
13 }
14 }
15}
16root@vMX1# show protocols ospf
17traceoptions {
18 file ospf.log;
19 flag error;
20 flag database-description;
21}
22area 0.0.0.0 {
23 interface lo0.0 {
24 passive;
25 }
26 interface ge-0/0/0.0 {
27 authentication {
28 md5 1 key "$9$XMbNVYJGifT3goT369OBxNd"; ## SECRET-DATA
29 }
30 }
31}
32

vMX2
1root@vMX2# show interfaces
2ge-0/0/0 {
3 unit 0 {
4 family inet {
5 address 10.1.2.2/24;
6 }
7 }
8}
9lo0 {
10 unit 0 {
11 family inet {
12 address 2.2.2.2/32;
13 }
14 }
15}
16[edit]
17root@vMX2# show protocols ospf
18traceoptions {
19 file ospf.log;
20 flag error;
21 flag database-description;
22}
23area 0.0.0.0 {
24 interface lo0.0 {
25 passive;
26 }
27 interface ge-0/0/0.0 {
28 authentication {
29 md5 1 key "$9$/4VdAu1Srv7-wRh-wYgUD9Ap"; ## SECRET-DATA
30 }
31 }
32}
33

Troubleshooting Neighbor Mismatch

In the Table 2, I summarized which show commands and traceoption flags should be used in
case of every mismatch that I mentioned previously. Actually, there are other show
commands that you can use to get here, but the show command that I am pointing out here
is the final one which will explicitly show the mismatch. Also, it’s important to master this
specific show and traceoptions flag in case you don’t have access to the other/remote
OSPF router for whatever reason or if you run into a interoperability issue and you need to
know how the device is actually parsing and handling the message received on wire.

OSPF attribute Junos show command Junos traceoptions flag

Unique router-id show ospf statistics | find error error

Area show ospf statistics | find error error

Area flags show ospf statistics | find error error

show ospf neighbor (the neighbor entry is

Authentication type error
empty)

Authentication show ospf neighbor (the neighbor entry is

error
password empty)
 OSPF attribute Junos show command Junos traceoptions flag

Hello/Dead interval show ospf statistics | find error error

show ospf neighbor (the neighbor is stuck error, database-

L3 MTU
in ExStart state) description

Compatible network show ospf neighbor (the neighbor is stuck

-
type in Init state)

Network Mask show ospf statistics | find error error

Table 2 - Junos show commands and traceoptions flag for troubleshooting OSPF neighbor
mismatch
As you can see, basically, if you want to troubleshoot whatever mismatch that you can
possibly encounter, all you have to do is to enable both error and database-
description traceoptions flag and use show ospf statistics | find error and show ospf
neighbor. There you go! With these two commands you can effectively narrow down
whatever OSPF neighbor mismatch. Neat! Now, I’ll show you some output of these
commands in action for every mismatch situation we’ve discussed so far.

Unique router-id
1root@vMX2# run show ospf statistics | find error
2Receive errors:
3 7 Hellos received with our router ID
4[edit]
5root@vMX2# run show log ospf.log | match ignored
6Jul 1 16:55:52.977808 OSPF packet ignored: our router ID received from 10.1.2.1 on
7intf ge-0/0/0.0 area 0.0.0.0

Area
1root@vMX2# run show ospf statistics | find errors
2Receive errors:
3 53 area mismatches
4root@vMX2# run show log ospf.log | last | match ignored
5Jul 1 16:10:34.822195 OSPF packet ignored: area mismatch (0.0.0.1) from 10.1.2.1 on
6intf ge-0/0/0.0 area 0.0.0.0

Area Flags
1root@vMX2# run show ospf statistics | find error
2Receive errors:
3 5 stub area mismatches
4root@vMX2# run show log ospf.log | last | match ignored
5Jul 1 16:22:18.104341 OSPF packet ignored: area stubness mismatch from 10.1.2.1 on
6intf ge-0/0/0.0 area 0.0.0.1

Authentication Type

The show ospf neighbor entry will be empty and you’ll see this in the output of traceoption:

root@vMX2# run show log ospf.log | last | match ignored

1
Jul 1 16:30:13.426460 OSPF packet ignored: authentication type mismatch (0) from
2
10.1.2.1

Authentication Password

Again, the show ospf neighbor entry will be empty and you’ll see this in the output of
traceoption:

1root@vMX2# run show log ospf.log | last | match ignored

2Jul 1 16:35:43.822242 OSPF packet ignored: authentication failure (bad cksum).
3Jul 1 16:35:43.822508 OSPF packet ignored: authentication failure from 10.1.2.1

Hello/Dead Interval

The traceoption, in addition to show the mismatch, also shows the actual value received,
which is really helpful if you’re not allowed to change the remote router and a local change
has to be made instead.

1
root@vMX2# run show ospf statistics | find error
2
Receive errors:
3
2 hello interval mismatches
4
[edit]
5
root@vMX2# run show log ospf.log | last | match ignored
6
 7Jul 1 16:39:24.047315 OSPF packet ignored: hello interval mismatch 11 from
810.1.2.1 on intf ge-0/0/0.0 area 0.0.0.0
9root@vMX2# run show ospf statistics | find error
10Receive errors:
11 1 dead interval mismatches
12[edit]
13root@vMX2# run show log ospf.log | last | match ignored
14Jul 1 16:40:51.283654 OSPF packet ignored: dead interval 41 mismatch from 10.1.2.1
15on intf ge-0/0/0.0 area 0.0.0.0

L3 MTU

This one is a classic, and a great indicator you’ve got a L3 MTU mismach is the fact that the
OSPF router will be stuck in the ExStart state. Note the MTU values exchanged are shown in
the output bellow.

1root@vMX2# run show ospf neighbor

2Address Interface State ID Pri Dead
310.1.2.1 ge-0/0/0.0 ExStart 1.1.1.1 128 34
4[edit]
5root@vMX2# run show log ospf.log | last
6Jul 1 16:47:10.689043 OSPF resend last DBD to 10.1.2.1
7Jul 1 16:47:10.689106 OSPF sent DbD 10.1.2.2 -> 10.1.2.1 (ge-0/0/0.0 IFL 329 area
80.0.0.0)
9Jul 1 16:47:10.689112 Version 2, length 32, ID 2.2.2.2, area 0.0.0.0
10Jul 1 16:47:10.689117 options 0x52, i 1, m 1, ms 1, r 0, seq 0x209559a, mtu 1500
11Jul 1 16:47:11.309097 OSPF rcvd DbD 10.1.2.1 -> 10.1.2.2 (ge-0/0/0.0 IFL 329 area
120.0.0.0)
13Jul 1 16:47:11.309160 Version 2, length 32, ID 1.1.1.1, area 0.0.0.0
14Jul 1 16:47:11.309165 checksum 0x0, authtype 2
15Jul 1 16:47:11.309171 options 0x52, i 1, m 1, ms 1, r 0, seq 0x1076ffe, mtu 1499
16Jul 1 16:47:14.538085 OSPF resend last DBD to 10.1.2.1

Compatible Network type

This is a tricky one, because actually the network type isn’t explicitly negotiated to form the
adjacency. Because of this, the OSPF process won’t explicitly tear down the adjacency.
However, as I briefly mentioned, the network type needs to be compatible otherwise the
underlying graph will be completely broken and unusable. As far as my lab experience on
Junos, if you’ve got this mismatch you’ll see that one OSPF router will be stuck in
the Init state. In this case, vMX2 was running a network type p2p, whereas vMX1 was
running broadcast.

1root@vMX2# run show ospf neighbor

2Address Interface State ID Pri Dead
310.1.2.1 ge-0/0/0.0 Init 1.1.1.1 128 37

Network Mask
1root@vMX2# run show ospf statistics | find error
2Receive errors:
3 3 netmask mismatches
4[edit]
5root@vMX2# run show log ospf.log | match ignored
6Jul 1 16:59:05.632968 OSPF packet ignored: netmask 255.255.255.128 mismatch from
710.1.2.1 on intf ge-0/0/0.0 area 0.0.0.0

Summary
To sum up, OSPF has some attributes that needs to match before the neighbors actually
become functional neighbors. If you need to troubleshoot whatever OSPF mismatch and if
you’re running Junos, with just two show commands at most and some traceoptions flags
are enough to show you precisely which parameter is the issue. I hope you enjoyed this
article and hopefully it was useful to speed up your troubleshooting skills.