OSPF neighbours and adjacencies

How do R1 and R2 find each other?

OSPF (Open Shortest Path First) routers use Hello messages to discover other routers on a connected link. Finding a neighbour is the first step; exchanging the required network information comes afterwards.

R1 and R2 are routers joined by an Ethernet link. R1 uses address 10.0.12.1 on Gi0/1. R2 uses 10.0.12.2 on Gi0/0. Both addresses belong to subnet 10.0.12.0/30. Gi is short for GigabitEthernet; it names a device interface, not a TCP or UDP port.

A router ID (RID) identifies an OSPF router. R1 uses 1.1.1.1 and R2 uses 2.2.2.2. These look like IPv4 addresses, but they identify the routers; the packets on this link use the different interface addresses above. Their switches connect the user LANs; this lesson follows the separate router-to-router link.

Each router sends Hello messages. In this Ethernet example, the destination is 224.0.0.5, a group IP address used by OSPF routers on the link. It is not a website address. OSPFv2 uses IP protocol number 89; this is a protocol identifier, not TCP port 89.

The Hello interval says how often to send a Hello. The Dead interval says how long to wait without a valid Hello before treating the neighbour as down. Cisco normally uses 10 and 40 seconds on broadcast and point-to-point interfaces.

How a Hello becomes two-way communication

R1 receives a Hello from R2 and records R2 as a neighbour. R1 then lists R2's router ID in its own Hello. When R2 sees that list, it knows R1 has heard it. The same check happens in the other direction.

Each router reaches 2-Way when it sees its own ID in the other router's Hello. This confirms that both routers can receive and accept one another's messages.

2-Way proves bidirectional Hello recognition. It does not mean the databases have finished synchronising.

When the cable works but the neighbour fails

Suppose R2 changes to Hello 5 / Dead 20 while R1 stays on 10/40. Hellos still reach the cable, but their settings fail validation.

Check the area number, Hello and Dead timers, and authentication settings on both ends. For this broadcast IPv4 link, the subnet settings must also agree. A working cable only proves that a physical connection exists; it does not prove that OSPF settings match.

Also check that OSPF is enabled on the intended interfaces, neither router link is passive, RIDs are unique, and filtering permits the required OSPF traffic. Network types must work together; mask checking has exceptions on point-to-point links.

Which neighbours should reach Full?

On a shared Ethernet LAN, the routers choose a designated router (DR) to help share updates and a backup designated router (BDR) to take over if it fails. The remaining routers are DROthers. They still learn routes and forward traffic.

A DROther forms Full connections with the DR and BDR. Two DROthers normally stay at 2-Way with each other. They do not need a Full connection with every router on the LAN. This reduces the number of database exchanges on a busy LAN, at the cost of electing and maintaining those special roles.

The optional figure uses a separate shared-LAN example: four routers connect to one Layer 2 switch on 10.0.50.0/24. Its DR and BDR have already been elected. It is not an extra connection added to the two-router 10.0.12.0/30 lab.

On an OSPF point-to-point link, compatible neighbours are expected to form a Full adjacency. On a broadcast LAN, check the DR/BDR roles before treating 2-Way as a fault. The next lesson explains DR/BDR election.

Synchronise the database before Full

The link-state database (LSDB) stores OSPF records about the network. Each record is a link-state advertisement (LSA). Neighbours that need an adjacency compare their records and ask for information they are missing.

Read each state from the router reporting it. If R1 reports R2 as Init, that describes R1's conversation with R2; it does not tell us exactly what R2 currently reports. The states below follow this same pair towards a completed adjacency. They are milestones, not a fixed-length countdown: some pass too quickly to appear in a show command.

Down: R1 has no recent Hello from R2

Before R1 receives a valid Hello from R2, their conversation starts in Down. A previously working neighbour also goes down if its Dead interval expires without a valid Hello. A local link failure can trigger the change sooner; OSPF does not have to wait for the timer when the interface itself reports the failure.

On this dynamically discovered Ethernet link, an unknown or expired neighbour may simply be absent from show ip ospf neighbor. Do not expect a permanent Down row. Start with the local interface state and whether Hellos can pass in both directions, rather than assuming that Down proves a broken cable.

Init: R1 hears R2, but has not seen its own ID returned

R1 accepts a Hello from R2, whose router ID is 2.2.2.2. However, that Hello does not yet include R1's ID, 1.1.1.1, in its neighbour list. From R1's perspective, R2 is now Init: there is evidence of reception in one direction, but bidirectional recognition is incomplete.

A brief Init state is normal during discovery. Persistent Init needs investigation on both devices. R2 may not be receiving or accepting R1's Hellos, perhaps because of filtering or incompatible settings. The state points us towards that check; it does not identify the cause by itself.

2-Way: R1 sees that R2 has heard it

R1 receives a Hello from R2 that includes 1.1.1.1. R1 can now recognise bidirectional Hello communication and move R2 to 2-Way. R2 makes the corresponding decision using its own received Hellos.

2-Way is where OSPF decides whether this pair needs a Full adjacency. Two DROthers can stay here on a healthy broadcast LAN. Our two-router example proceeds because the pair is selected to become adjacent; a point-to-point pair also normally proceeds. Discovery alone does not require every pair to synchronise its databases.

ExStart: agree how to organise the database exchange

The selected pair enters ExStart, short for Exchange Start. They negotiate the initial sequence number and the roles used for database description (DBD) packets, OSPF packet type 2. These sequence numbers keep that exchange in order; they are different from the version numbers inside individual LSAs.

R2 has the higher router ID, so it controls DBD sequencing; R1 follows and echoes the sequence numbers. Older documentation calls these the master and slave roles. They apply to this database exchange and do not determine the DR election or the path user packets follow. MTU or negotiation problems can keep a pair here even while Hellos work.

Exchange: compare the LSA headers

In Exchange, R1 and R2 describe their database contents using DBD packets. These contain LSA headers, the identifying and version information for records, rather than each record's full contents. A header tells R1 which LSA R2 has and helps it decide whether R2's copy is newer.

For example, R1 may recognise R2's router LSA but discover that its own copy is older. It places that LSA on a request list. A database can require several DBD packets; seeing one packet does not mean that Exchange is finished. Requests and updates can already occur during Exchange.

Loading: obtain the records still needed

Once the DBD exchange finishes, R1 enters Loading if its request list still contains records to obtain. A link-state request (LSR), packet type 3, identifies a missing or outdated LSA. R2 answers in a link-state update (LSU), packet type 4, which carries the full LSA contents. One LSU can carry several LSAs.

R1 processes the received records and removes satisfied requests. If the request list is already empty when Exchange finishes, it can move directly to Full without waiting in Loading. Repeated requests or a persistent Loading state call for checking packet delivery and the particular records involved, rather than restarting every router.

Full: the required database synchronisation is complete

R1 reaches Full with R2 when their required database exchange has completed. The relationship continues: Hellos maintain neighbour detection, and later topology changes still produce updates. Full does not mean that the network will stop changing.

Full confirms this adjacency, not end-to-end connectivity. A remote subnet can still be unadvertised, a preferred route can come from another source, or a host can have the wrong gateway. After checking the adjacency, inspect the destination route and the return path before testing the application.

Which packet acknowledges the update?

A link-state acknowledgement (LSAck), packet type 5, explicitly acknowledges individual LSAs using their headers. It does not acknowledge an entire LSU as one indivisible item, and it does not acknowledge a DBD packet. Multiple LSA acknowledgements can share one packet, and some are delayed briefly to group them. OSPF packet types and LSA types are separate numbering systems: a type 4 LSU can carry a type 1 router LSA.

OSPF also permits an implicit acknowledgement. If R1 is waiting for acknowledgement of an LSA it sent to R2, receiving that same LSA instance back from R2 can satisfy the wait. Therefore, a packet capture need not show a separate LSAck for every LSU. The simplified ladder below shows an explicit acknowledgement so you can follow one requested record.

Attempt is an additional state for manually configured neighbours on a non-broadcast multi-access (NBMA) network, such as a legacy Frame Relay WAN. It is not part of this broadcast Ethernet example. Shortest path first (SPF) is the calculation OSPF uses to find paths through its network records. It may run while the network is converging; Full is a database milestone, not the first moment SPF is allowed to run.

Why ExStart or Exchange can stall

Maximum transmission unit (MTU) is the largest IP packet size an interface is configured to carry without fragmentation. If the routers report different MTUs, they may reject database description messages and fail to finish the exchange. Hello messages can still work because they are small.

MTU is one possible cause. DBD sequencing, duplicate identities, packet loss and other exchange problems also need investigation. Compare show ip ospf interface, interface MTU settings and logs before changing anything.

Fix the timers on both ends

Use an isolated Cisco IOS or IOS XE OSPFv2 lab with the link already addressed and enabled for OSPF in area 0. The interface names are those in our example; check your device's names and effective defaults. From privileged EXEC (R1#), enter configure terminal before the configuration below. Use end to return to privileged EXEC before running the show commands.

ip ospf hello-interval 5 sends a Hello every five seconds. ip ospf dead-interval 20 declares the neighbour down after twenty seconds without a valid Hello. Set both values on both ends. Shorter timers can detect a silent failure sooner, but generate more Hello traffic and leave less time to tolerate delays. These changes can interrupt the existing adjacency.

The outputs below are written examples based on Cisco documentation, not captures from a tested router. Interface details and exact wording can vary by software image.

R1#show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  ...
  Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
  ...
  Neighbor Count is 1, Adjacent neighbor count is 1

Read the neighbour row from R1’s perspective

show ip ospf neighbor lists the neighbours seen by the router where you run the command. Neighbor ID is the remote router's OSPF ID. Address is its IP address on the link. Interface is the local port used to reach it. These three values describe different things.

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

Choose the next check from the symptom

A state narrows the investigation; it does not prove a single cause. A neighbour can be Full while a particular subnet is absent or its route loses to another source.

Try it: compare both ends of the same link

In the configured lab, run show ip ospf interface GigabitEthernet0/1 on R1 and the corresponding command for Gi0/0 on R2. Compare area, Hello/Dead timers, network type and passive status. Then use show ip ospf neighbor on both routers.

If you apply the 5/20 timer example above, confirm those values at both ends. When returning to defaults, remove both timer overrides on both interfaces and verify again. Change one kind of setting at a time so you can tell which change fixed the problem.

Sources: Cisco neighbour states, neighbour troubleshooting, ExStart/Exchange troubleshooting and RFC 2328, sections 10.1, 10.6–10.9 and 13–13.5.

Test yourself on OSPF neighbours