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
Unique router-id In the routing graph, every OSPF node/router is expected to have an UUID, 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 password The authentication secret itself
Hello/Dead interval By default, hello = 10s and dead = 40s
L3 MTU The MTU announced on OSPF DBD packets
Compatible network type The network type must be consistent on the network segment. You’d have a broken 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

collapsed_core_2pes_ospf

Base configuration

vMX1

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

vMX2

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

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
Authentication type show ospf neighbor (the neighbor entry is empty) error
Authentication password show ospf neighbor (the neighbor entry is empty) error
Hello/Dead interval show ospf statistics | find error error
L3 MTU show ospf neighbor (the neighbor is stuck in ExStart state) error, database-description
Compatible network type show ospf neighbor (the neighbor is stuck 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

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

Area

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

Area Flags

1
2
3
4
5
6
root@vMX2# run show ospf statistics | find error
Receive errors:
5 stub area mismatches
root@vMX2# run show log ospf.log | last | match ignored
Jul 1 16:22:18.104341 OSPF packet ignored: area stubness mismatch from 10.1.2.1 on intf 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:

1
2
root@vMX2# run show log ospf.log | last | match ignored
Jul 1 16:30:13.426460 OSPF packet ignored: authentication type mismatch (0) from 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:

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

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

1
2
3
root@vMX2# run show ospf neighbor
Address Interface State ID Pri Dead
10.1.2.1 ge-0/0/0.0 Init 1.1.1.1 128 37

Network Mask

1
2
3
4
5
6
7
root@vMX2# run show ospf statistics | find error
Receive errors:
3 netmask mismatches
[edit]
root@vMX2# run show log ospf.log | match ignored
Jul 1 16:59:05.632968 OSPF packet ignored: netmask 255.255.255.128 mismatch from 10.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.