OSPF Neighbour Discovery

Introduction to Neighbour Discovery:

For OSPF, neighbour discovery is a critical component. Without OSPF routers dynamically discovering eachother they are unable to share routes, and obviously if in a production environment an OSPF state goes down, knowing how to make OSPF rediscover its neighbour is critical. OSPF Neighbour discovery is more complicated than that of EIGRP.

OSPF Neighbourship:

As mentioned in https://xavierj.co.uk/1-10-what-is-ospf/ for two OSPF routers to become neighbours they must:

Send hello packets to eachother. The hello packet has fields which must match between both routers.

Paramaters that must match:

Hello Interval -> The default Hello Interval is 10 seconds on a Broadcast segement such as Ethernet.
Dead Interval -> The default Hello Interval is 40 seconds on a Broadcast segment such as Ethernet.
Area ID -> For two OSPF routers to become peers they must have a link in the same area.
Stub/NSSA Flag -> Stubs/NSSA is something we will discuss later. But it is essentially a bit of 0 or 1 that indicates whether that area is a stub area or an NSSA area.
Authentication -> OSPF Authentication is something we will discuss later.
Subnet Mask -> The subnet mask must match, no matter if we configure it on interface or on network command. E.g. if the interface is set to /24 but the neighbour is a /26 it doesnt match and thus the neighbourship will not form.

Paramaters that dont have to match:

These may or may not be in the hello packet -> So these arent compulsory.

OSPF Router ID -> Definetly do not want the same Router-ID. The Router-ID is how the routers identify themselves. If we set it to the same, routers will become confused and the peering will go down.
Router Priority -> This is used for setting DR/BDR priority manually instead of allowing OSPF process to automatically decide.
DR/BDR IP address -> These should not match between peers. Typically it will use the Router-ID by default. If they are the same we will have an issue.

Neighbourship States:

We willl get into detail on the neighbourship states.
There are two major OSPF Classes:

2-Way Neighbour State -> This is when both routers have sent hello packets to eachother and have seen eachother’s router’s ID in the packet, thus recognising eachother. At this stage LSA’s have not been exchanged. This stage is normal for certain network types.
Full Adjacency State -> This is when OSPF is in a full state with its OSPF neighbour. They have exchanged LSA’s and both have the same LSDB.

Network Statement & Multicast

When we activate OSPF with the network statement, it does a check for exactly what type of interface OSPF is being enabled on is. Why?
It does this because some interfaces/network types support multicast such as broadcast. But other’s do not. For example Frame Relay does not support Multicast. Why is this an issue?
Remember that OSPF hello messages are sent to multicast address 224.0.0.5/6. This means if a network segment doesnt support multicast, it cannot support dynamic neighbour discovery. In which case – like frame Relay – OSPF neighbourship has to be statically defined. This will be discussed indepth later.
OSPF will send multicast hello messages when the network command or the ip ospf area interface-level has been configured.
Also hello messages are not sent to passive interfaces. Passive-Interfaces are interfaces manually configured to not accept hello packets. This could be for many reasons such as connecting to an external company, but where we still want the subnet advertised into OSPF. To configure Passive -Interfaces it is done via the Passive-Interface command under the router ospf process.

Hello & Dead Timers:

As mentioned, OSPF uses periodic hello messages. The interval at which the hello packets are sent is known as the hello interval -> This by default is 10 seconds. So this means every 10 seconds a hello packet will be sent to its neighbour. This acts as a keepalive mechanism.
If a hello is not received from its neighbour for a period of time, that neighbour will be considere down. The interval of wait is known as the dead interval -> By default this is 4*Hello interval. So this is 40 seconds.
These timers can be verified either by ‘Show ip ospf interface [Interface ID]’.

We can modify these times to have faster convergence. We can make the hello packet be in subseconds for super fast convergence but it is not recommended to do this. While it can detect failures in less than a second, OSPF hellos are processed by the CPU and thus putting this at 1 second or less will be very CPU intensive.
Instead we can use Bi-directional Forwarding Detection (BFD) which is used to quickly identify faults between interfaces. But this is outside of the scope.

OSPF Router-ID:

Every OSPF router will have a Router-ID. As mentioned, all OSPF routers must have a unique Router-ID. If two router’s have the same OSPF Router-ID a peering relationship will be prevented from being formed.
It will also cause issues with other routers (not directly connected) who have the same Router-ID.

There are two outcomes:

Same Router ID In same area -> There will be a syslog message saying that there is a duplicate Router-ID syslog message.
Same Router ID In Different area -> The routers will flush eachothers LSA and declare an OSPF Flood War.

This syslog message is shown below:

R3 (which is set as 3.3.3.3):

In the above, the source IP is from R3. It has a source OSPF router ID of 3.3.3.3 automatically picked.

R6 (Which I manually configured Router-ID as 3.3.3.3)

You can see the same information here.
The Area ID: 0.0.0.10 gives away that there is a duplicate Router-ID issue on this segment if you were to in real life do a PCAP and check the hello packets on an area.

Router ID Selection & Verification:

Manually Configured -> Underneath the router ospf process, using the command router-id <ip address> will be the most preferred and the one that will be picked.
Highest Loopback -> If a loopback is configured on the router – with an IP address – this is the next preferred.
Highest IP on Physical Interface -> The highest IP address configured on the physical interface is the final one preferred.
Non-Preemption -> Router-ID’s do not pre-eempt. You may remember pre-emption from HSRP in where a primary takes back over from the secondary after a failover. We cannot do the same for Router-ID’s. The router has to either be restarted or the ‘clear ip ospf process > yes’ command has to be done. This is service impacting and must be done in maintanence period in a production environment as all OSPF adjacencies will go down.

MTU Mismatch:

Routers in a typical network have an MTU of 1500 bytes -> If a router needs to forward a packet larger than the interface’s MTU it does fragmentation of the packet or it will discard the packet.
In the IP header we will see if the DF (dont fragment) bit is set, if it is, then the packet is dropped as it wont be fragmented. if it isnt set, it wil be fragmented.
MTU’s should be consistent between pretty much all devices in the network usually. But especially between the link between two OSPF routers it needs to eb the same.
If there is an MTU Mismatch between the two rotuers they will be unable to become OSPF neighbours -> They will be stuck in the Exstart state and go down. This means if we see an OSPF neighbour relationship being stuck on EXSTART, well, this should only be for a few seconds. If its stuck, then it should clue you in to a potential MTU issue
We will see a syslog message ‘too many retransmission’.
A database decriptor packet will continously be sent saying that the MTU is incorrect. We can see this below:

In the below I have changed the MTU but you have to clear the ospf process in order for the change to go through/impact OSPF:

You can see that the DBD’s continue to flood.
We can also see that the neighbour state went down to 6.6.6.6 (R6 in this case)
We can also do a debug command ‘debug ip ospf adjacency’ to find out what is stoping an ospf adjacency from forming.

Summary:

OSPF sends hello messages in order to form an OSPF neighbourship -> There are paramaters that must match like subnet mask, area-id etc, and some that must not match, like Router-ID’s.
Hello Timers on Ethernet segments are set to 10 seconds by default.
Dead Timers on Ethernet segments are set to 40 seconds by default.
Router-ID’s are used for the OSPF router to identify itself. Manually specified router ID is most preferred -> Loopback -> Highest physical IP address.
If OSPF adjacency is not being formed, we can run a debug ‘debug ip ospf adj’ which will show us why it is not forming.