Exploring OSPF Messages Between New Neighbors

A basic network is setup and OSPF is configured.  R1 is then prevented from forming an OSPF adjacency with R2 due to R1’s serial interface being configured as a passive interface.

Only Hello packets are seen from R2.

From this Wireshark output we can see:

1. OSPF Version 2 is utilized
2. This is a Hello packet
3. The Hello packet is sourced from a router with OSPF Router ID 2.2.2.2.  Duplicate RIDs will prevent an OSPF adjacency and cause other issues.
4. The interface that sourced this Hello packet resides in OSPF area 0.  This item is used to verify that the two connected router interfaces are within the same OSPF area – this is a requirement in order to form an OSPF adjacency.
5. No authentication is used
6. A /30 network mask is used on R2’s connected interface.  This item is used to verify that the two connected router interfaces are using the same subnet mask, which is a requirement in order to form an OSPF adjacency in addition to the two interfaces being within the same primary subnet.
7. Hello and Dead timers.  These must be the same on both connected routers in order to form an OSPF adjacency.
   1. Hello is set to the default 10 seconds
   2. Dead is set to the default 40 seconds
8. The configured router priority is the default of 1.
9. An active neighbor is listed.  This was due to the fact that an adjacency existed before I set the interface to passive, and the dead timer hadn’t expired yet on R2.  This line will disappear in subsequent Hello packets once the timer on R2 expires and it drops the now broken adjacency.

Also, notice that the OSPF process-id is not included in the Hello packet.  This is because the process-id is only locally-significant.

So now, let’s re-enable R1’s s1/0 interface as an active OSPF interface.

As the neighborship begins to form and the LSDB exchange process starts, the first thing we see is a Hello from R1 while it is in the Init state.  R2 then sends a hello that indicates it has seen R1.  This means R2 is now in a 2-way state.

The next two packets appear to be a negotiation between the two routers to determine who will be the master and slave in the relationship, as they both have the master bit set, and no LSA headers.  I also noticed that the Init bit is set in both of these DD packets.  I believe this would equate to the ExStart state.

 

The next two packets indicate that R2 is the master, which it should be due to the higher RID.  Also notice the Init bit is no longer set, and LSA Headers are provided.  The LSDB Exchange has started.

 

These LSAs are Router LSAs and do not contain any in-depth information such as the actual links contained within them. An important thing to note is the LS Sequence number.  A router uses this to see if a) it already has this LSA and b) if the LS Sequence number is later than the received LSA’s.  If the received LSA’s sequence number is later than the LSA it has in its database, the router assumes the received LSA is more recent, and will in turn send a LS Request to get a full copy of that LSA.

Now that both routers have a list of LSAs that their neighbor has, LS Requests are sent to retrieve the full LSAs for any that they do not have locally, or LSAs that their neighbor has a more recent version of (Again, going off the LS Sequence number). This is the Loading state.

 

LS Updates are sent in return with full information regarding the requested LSA.  Here we see R1 send its Router-LSA (LS ID 1.1.1.1) with sequence number ending in 04. R2 sends its Router-LSA (LS ID 2.2.2.2) with sequence number ending in 03.  Both of these LSAs contain the links and metric that each respective router has at that point in time.  These LSAs will then be locally updated with the new information, and their sequence numbers incremented.  Also, LS Acknowledgements are sent to tell each router that their LS Updates were received successfully by mirroring the previously-received LS Sequence number. 

  

The next LS Updates are sent out containing their previous information in addition to the updated links that were newly added by the previous LS Updates.  Notice the incremented LS Sequence numbers.

 

LS Acknowledgements are sent, LSAs and their LS Sequence numbers now  match – all is good.  These neighbors are now fully adjacent.