OSPF neighbours and adjacencies

A real-life situation

You have enabled OSPF on R1 and R2 in the lab. R1 learns every route from R2 within seconds. Then a colleague changes the hello timer on R2's Gi0/0 to 5 seconds "to make it faster". Forty seconds later R1 logs that its neighbour is down, and all the OSPF routes through R2 vanish. Nothing is wrong with the cable. The two routers simply stopped agreeing on how to talk. This lesson explains what that agreement is and how it forms.

If you have not met OSPF yet, start with the OSPF overview. It introduces link-state routing, the LSDB, SPF and cost. This lesson goes one level deeper into the first job OSPF does: finding neighbours.

What an OSPF neighbour is

An OSPF neighbour is another OSPF router on the same link that your router has heard from, and that agrees with it on a few basic settings. Routers keep a list of these in the neighbour table. OSPF only shares routing information with neighbours. No neighbour, no routes.

There is a second, stronger relationship called an adjacency. Two routers are adjacent when they have also copied each other's link-state database (the LSDB, the map of the network). Adjacent routers end in the Full state. On point-to-point links every neighbour becomes adjacent. On shared Ethernet segments some neighbours deliberately stop before that; the lesson on DR/BDR election and network types explains why.

The five OSPF packet types

OSPF does not use TCP or UDP. It sits directly on top of IP with IP protocol number 89. It has its own reliability: updates are acknowledged and resent if needed. There are five packet types:

What is inside a hello

Every OSPF packet starts with the same header, which names the sender's router ID (a 32-bit name written like an IP address, for example 1.1.1.1) and the area. A hello then adds the fields below. The highlighted ones must match on both routers, or they will never become neighbours.

The last field matters most for the states below. A router lists every router ID it has heard hellos from on that link. When R2 sees its own router ID in R1's hello, it knows the conversation works in both directions.

Why it works this way

Link-state routing only works if every router in an area has an identical map. If two routers disagreed on the area, or one expected hellos twice as often as the other sent them, they would keep timing each other out or build different maps. So OSPF checks the important settings in every hello, before any routing information is shared. It is strict on purpose: a neighbour that does not match is ignored rather than half-trusted.

The hello interval is how often hellos are sent. The dead interval is how long a router waits without a hello before it declares the neighbour dead. Defaults on Ethernet and point-to-point links are 10 and 40 seconds (dead = 4 × hello). Hellos keep flowing for as long as the routers run; they are the "I'm still here" heartbeat.

How it works: the neighbour states

Two routers move through a fixed series of states. You will see these names in show ip ospf neighbor, so knowing them tells you exactly where a problem is.

Here is the same process as a message exchange between R1 and R2 on the 10.0.12.0/30 link:

After Full, the routers keep sending hellos. When something changes, such as a link going down, the router that notices sends an LSU describing the change, neighbours acknowledge it and pass it on, and every router reruns SPF. Each LSA is also refreshed every 30 minutes even if nothing changes, so stale information never lives forever.

What must match to become neighbours

Two routers on the same link become neighbours only if all of these agree:

Three more conditions are not in the hello check list but still break things:

• Unique router IDs. Two routers with the same router ID will not form a working adjacency, and the router logs a duplicate router ID message.
• Matching IP MTU. The MTU is carried in DBD packets. If it differs, the routers get stuck in ExStart or Exchange.
• Not passive. A passive interface sends no hellos and ignores the ones it receives, so it can never form a neighbour.

💡 The process ID (the 1 in router ospf 1) does not need to match. It only identifies the OSPF process inside one router.

How to configure the neighbour-related settings

Most of the time you leave the timers at their defaults. The full OSPF setup is covered in Configuring single-area OSPFv2. These are the interface commands that affect neighbours directly:

A full example with matching timers on both sides of the R1–R2 link:

How to verify it

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:17    10.0.12.2       GigabitEthernet0/1

R1#show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  ...
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.12.1
  Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
    Hello due in 00:00:02
  ...
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Designated Router)

If the state is stuck or the table is empty, the router often tells you why in its log. You can also watch hellos arrive with a debug (use debugs carefully on busy production routers):

OSPF: Mismatched hello parameters from 10.0.12.2
OSPF: Dead R 40 C 20, Hello R 10 C 5  Mask R 255.255.255.252 C 255.255.255.252

What goes wrong and how to troubleshoot it

The state a neighbour is stuck in points straight at the cause:

Verifying and troubleshooting OSPF walks through each of these with the commands to fix them.

Common mistakes

• Thinking the process ID must match. It doesn't; the area does.
• Changing the hello interval on one side only. The routers do not negotiate: they simply refuse each other.
• Reading the Neighbor ID column as an IP address. It is the router ID. The interface IP is in the Address column.
• Treating 2-WAY/DROTHER as a fault. Between two DROthers on Ethernet it is exactly what should happen.
• Making the LAN interface passive and then wondering why a router on that LAN never becomes a neighbour.

💡 Exam tip: know the neighbour states in order (Down, Init, 2-Way, ExStart, Exchange, Loading, Full), and the settings that must match: area, subnet, hello/dead timers and authentication, plus unique router IDs and matching MTU. Expect questions like "R1 and R2 are not neighbours, which change fixes it?", where the answer is often a timer or area mismatch and a distractor is a different process ID. Remember 224.0.0.5 and 224.0.0.6 and the 10/40 default timers.

Key takeaways

Check yourself