5 mins read

OSPF Neighborship Requirements and Troubleshooting

SRL0Tagged ,

1. Intro

It is often times a struggle to bring up an OSPF Neighborship between two routers. Well, it can be if you don’t clearly know all requirements. In this post we will see all OSPF neighborship requirements and how to troubleshoot when the neighbors are not UP.

As a network engineer we must know all these requirements and quickly be able to fix any mismatch that can prevent the OSPF neighborship from happening. This can also be part of the JNCIE exam where fixing the OSPF neighborship with speed is essential.

2. OSPF Neighborship Requirements

First, let’s list all OSPF neighborship requirements:

  • Area must match
  • Area type must match
  • Authentication type and key must match
  • Subnet must match, both address and mask
  • Timers must match, both hello and dead interval
  • MTU must match
  • Interface type must match
  • Bonus: Protect-RE firewall filter must allow OSPF packets to RE.
  • Bonus: OSPF3 requires family inet6 on the interface (LSA are exchanged using IPv6 addressing, even for ipv4 realm)

Because we are discussing about OSPF neighborship, let’s also review the neighborship states:

  • Down – this is the initial state.
  • Init – The local router sent a hello packet, but the communication is still not established.
  • 2way – bidirectional communication is started. Local router received a Hello packet with its own router ID listed.
  • ExStart – start of the database synchronization process. During this state the routers negotiate which router is the master of this process.
  • Exchange – LSA exchange between the routers.
  • Loading – The local router finished sending LSA information but is still receiving database information.
  • Full – this state indicates that the databases on both neighbors are synchronized and adjacency is formed.

To troubleshoot OSPF neighborships, generally speaking, the first option is to use OSPF traceoptions, but once you know all neighborship requirements you can also do it with the common show commands.

3. OSPF traceoptions

To configure OSPF traceoptions use the commands presented bellow. Remember that you can use different flag options to filter and limit the number of generated logs, this will make it easier to spot the issues. 

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

To view the content of the configured trace options file you can use the commands presented bellow. You can search for specific words in the log file (e.g.: | match mismatch ) to make it easier to pinpoint the issue. Be creative when and use different keywords when checking the log file, use keywords like: mismatch, ignored, fail/failure, error, NBRDOWN, down, MTU, etc.

show log ospf.log
show log ospf.log | match mismatch

Find bellow different traceoptions logs as examples: 

### Configure traceoptions for the OSPF protocol: 

root@R6# set protocols ospf traceoptions file ospf.log 
root@R6# set protocols ospf traceoptions flag error detail 

[edit]
root@R6# show |compare 
[edit protocols ospf]
+    traceoptions {
+        file ospf.log;
+        flag error detail;
+    }

[edit]
root@R6# commit 
commit complete

### Run the 'show log ospf.log' command and observe the logs:
 
root@R6> show log ospf.log 

### Area number mismatch: 
Jun  4 05:24:02.571767 OSPF packet ignored: area mismatch (0.0.0.200) from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2

### Area type mismatch: 
Jun  4 05:15:51.499577 OSPF packet ignored: area stubness mismatch from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2

### Authentication type mismatch:
Jun  4 05:26:29.371601 OSPF packet ignored: authentication type mismatch (2) from 17.28.14.2
### Authentication key mismatch: 
Jun  4 05:27:58.087864 OSPF packet ignored: authentication failure (bad cksum).
Jun  4 05:27:58.087924 OSPF packet ignored: authentication failure from 17.28.14.2

### Subnet mismatch: 
Jun  4 06:53:06.379859 OSPF packet ignored: subnet mismatch from 17.28.144.2 on intf ge-0/0/3.0 area 0.0.0.2
### Netmask mismatch: 
Jun  4 06:51:31.253699 OSPF packet ignored: netmask 255.255.255.128 mismatch from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2

### Timers mismatch: 
Jun  4 06:56:03.199266 OSPF packet ignored: hello interval mismatch 7 from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2
Jun  4 06:55:00.253185 OSPF packet ignored: dead interval 35 mismatch from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2

### MTU mismatch:
Jun  4 07:00:01.948302 OSPF packet ignored: MTU mismatch from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2

### Interface type mismatch (missing interface-type p2p):
Jun  4 05:20:47.141703 OSPF packet ignored: configuration mismatch from 17.28.14.2 on intf ge-0/0/3.0 area 0.0.0.2

### If Protect-RE firewall filter is denying OSPF packets, we will likely NOT see any error logs.

4. OSPF show commands

With some practice, you will easily spot the OSPF neighborship issues with the following commands: 

show configuration protocol ospf
show interfaces
show ospf neighbors
show ospf interfaces
show ospf database
show log ospf.log

5. OSPF MTU

MTU is an important requirement for OSPF, and should be one of the first criteria to check if met. This stems from the fact that this simple MTU word can represent many things. We can have different MTU values for interface MTU, inet protocol MTU, inet6 MTU, other protocols MTU.

A particularly interesting and important use case is when we have a OSPF session between different vendors, like Juniper and Cisco, this is because there are differences in how they use and apply the MTU concept in their platforms, and these differences are often times poorly understood, making troubleshooting a complicated task. I will cover the MTU differences between different vendors in a dedicated post. Stay tunned!

External Resources:

Related Posts