Howdy Mr. Neighbor Router: OSPF Adjacency vs. Neighborship

OSPF-Hello ( to all the network aficionados on the web. This will be my first article on Packet Pushers. Routing is my first love, so rest assured you are in for some piping hot protocol intricacies (read delicacies) from my writing oven :). I am hoping that whoever swings by my piece learns something from it. The past few days have been sheer insanity (courtesy CCIE-Service Provider  lab preps and grad school grind), yet somehow I squeezed in some time to write this piece on OSPF neighborships and adjacency formation on a broadcast link.

I have seen many people confuse neighborship and adjacency, and they end up thinking they mean the same thing, which is akin to committing blasphemy in the world of OSPF. (There – the wrath of Dijkstra burnt a n00b :).) I have taken a sample topology (shown below) to expound on this concept.


OSPF Adjacency Formation States

During the adjacency formation process, two OSPF routers transition through several states, which include:

  • Down. Down is the starting state for all OSPF routers. A start event, such as configuring the protocol, transitions the router to the Init state. The local router may list a neighbor in this state when no hello packets have been received within the specified router dead interval for that interface.
  • Init. The Init state is reached when an OSPF router receives a hello packet but the local router ID is not listed in the received Neighbor field. This means that bidirectional communication has not been established between the peers.
  • Attempt. The Attempt state is valid only for Non-Broadcast Multi-Access (NBMA) networks. It means that a hello packet has not been received from the neighbor and the local router is going to send a unicast hello packet to that neighbor within the specified hello interval period.
  • 2-Way. The 2-Way state indicates that the local router has received a hello packet with its own router ID in the Neighbor field. Thus, bidirectional communication has been established and the peers are now OSPF neighbors. (And this is where you stand and clap for the ingenuity of the neighborship concept. Note that till the point of Neighborship formation, databases haven’t  been exchanged. It is only before they become adjacent that they exchange databases which is explained below.)
  • ExStart. In the ExStart state, the local router and its neighbor establish which router is in charge of the database synchronization process. The higher router ID of the two neighbors controls which router becomes the master.
  • Exchange. In the Exchange state, the local router and its neighbor exchange DD packets that describe their local databases.
  • Loading. Should the local router require complete LSA information from its neighbor, it transitions to the Loading state and begins to send link-state request packets.
  • Full. The Full state represents a fully functional OSPF adjacency, with the local router having received a complete link-state database from its peer. Both neighboring routers in this state add the adjacency to their local database and advertise the relationship in a link-state update packet.

(There. I rode on the horse’s back and proclaimed, “All OSPF adjacent routers are neighbors, but all OSPF neighbors are not adjacent”. Say with me “FREEDOMMMMMMM from CONFUSIONNNNN”, the way Sir William Wallace (aka Mel Gibson) said to his comrades in the epic movie”Braveheart”, who complied.)

I have taken a Wireshark capture for neighborship and adjacency formation between the 2 routers to illustrate this concept.

(Note: You can click on the image to enlarge it for better clarity. I hope the IP addresses and message exchanges are readable.)

The adjacency formation can be diagrammatically summarized as follows:

Nailing the OSPF Adjacency Gotchas

Neighborship stuck in down stage : When an OSPF router first receives a hello packet, it verifies that the data in some fields matches its own locally configured information. Should any of the checked data be different, the hello packet is discarded and not processed. The data fields verified are the Area ID, Authentication, Network Mask (on broadcast networks), Hello Interval, Router Dead Interval, and Options fields. If this information doesn’t match, then neighborship is stuck in the down stage.

OSPF adjacency gets stuck in the ExStart state : This occurs due to a final check the routers perform. In the DD packet, each router advertises the IP MTU of the interface it is using. Should the local and remote routers not agree on the MTU of the network link, the database synchronization process stops and both neighbors remain in the ExStart state.

Comments and acknowledgements invited.


2. Juniper Networks  Certification Guide


  1. uri says

    Just a little addition : on a multi-access network OSPF will also stuck in 2-WAY state between two DROther (non-DR/BDR) routers.

    P.S. The point of your topic has already been covered in Jeff Doyle’s “OSPF and ISIS” book. However he operates w/ different terms:

    Neighbors are adjacent when they discover each other, but are not fully adjacent until they complete the database synchronization process

  2. Routerman Vats says

    Thanks uri for the addition and the invaluable comment.Did you mean NBMA,point to multipoint category of multiaccess networks?
    P.S I am a big fan of Sir Doyle and his thoughts on IPv6. I will surely read his text on IGP Routing considering that he mentioned it as well.

  3. says

    “All OSPF adjacent routers are neighbors, but all OSPF neighbors are not adjacent”. This mainly happens in broadcast network…In BC networks all the routers see each other as neighbor but they can see their DR and BDR as adjacent neighbor. This means the DB exchange will happen only with DR and BDR in BC network.

Leave a Reply

Your email address will not be published. Required fields are marked *