OSPF Packets and Neighbor Discovery

In this lesson, I’m going to show you the different packets OSPF uses and how neighbor discovery works.

OSPF uses its own protocol, like EIGRP, and doesn’t use a transport protocol like TCP or UDP. If you would look at the IP packet in Wireshark, you can see that OSPF has protocol ID 89 for all its packets.

R2#debug ip ospf packet 
OSPF packet debugging is on
OSPF: rcv. v:2 t:1 l:48 rid:1.1.1.1
      aid:0.0.0.0 chk:4D40 aut:0 auk: from FastEthernet0/0

If we use debug ip ospf packet we can look at the OSPF packet on our router. Let’s look at the different fields we have:

• V:2 stands for OSPF version 2. If you are running IPv6, you’ll version 3.
• T:1 stands for OSPF packet number 1, which is a hello packet. I’m going to show you the different packets in a bit.
• L:48 is the packet length in bytes. This hello packet seems to be 48 bytes.
• RID 1.1.1.1 is the Router ID.
• AID is the area ID in dotted decimal. You can write the area in decimal (area 0) or dotted decimal (area 0.0.0.0).
• CHK 4D40 is the checksum of this OSPF packet, so we can check if the packet is corrupt or not.
• AUT:0 is the authentication type. You have three options:
  • 0 = no authentication
  • 1 = clear text
  • 2 = MD5
  • AUK: If you enable authentication, you’ll see some information here.

Let’s continue by looking at the different OSPF packet types:

I’m throwing them right at you; here are all our OSPF packet types. What is the role of each OSPF packet?

• Hello: neighbor discovery, build neighbor adjacencies and maintain them.
• DBD: This packet is used to check if the LSDB between the two routers is the same. The DBD is a summary of the LSDB.
• LSR: Requests specific link-state records from an OSPF neighbor.
• LSU: Sends specific link-state records that were requested. This packet is like an envelope with multiple LSAs in it.
• LSAck: OSPF is a reliable protocol, so we have a packet to acknowledge the others.

OSPF has to get through 7 states to become neighbors…here they are:

1. Down: no OSPF neighbors have been detected at this moment.
2. Init: Hello packet received.
3. Two-way: own router ID found in received hello packet.
4. Exstart: master and slave roles determined.
5. Exchange: database description packets (DBD) are sent.
6. Loading: exchange of LSRs (Link state request) and LSUs (Link state update) packets.
7. Full: OSPF routers now have an adjacency.

Let’s have a detailed look at this process! You can also see it in this packet capture:

OSPF Neighbor Adjacency – Network Type Broadcast

This is the topology I’m using. R1 and R2 are connected using a single link, and we will see how R1 learns about the 2.2.2.0 /24 network.

As soon as I configure OSPF on R1, it will send hello packets. R1 has no clue about other OSPF routers at this moment, so it’s in the down state. The hello packet will be sent to the multicast address 224.0.0.5.

R2 receives the hello packet and will put an entry for R1 in the OSPF neighbor table. We are now in the init state.

R2 has to respond to R1 with a hello packet. This packet is not sent using multicast but with unicast, and in the neighbor field, it will include all OSPF neighbors that R2 has. R1 will see its own name in the neighbor field in this hello packet.

R1 will receive this hello packet and sees its own router ID. We are now in the two-way state.

I have to take a pause here. If the link we use is a multi-access network, OSPF has to elect a DR (Designated Router) and BDR (Backup Designated Router). This has to happen before we can continue with the rest of the process. In another lesson, I’m going to teach you DR/BDR…for now, just hold the thought that the DR/BDR election happens right after the two-way state, ok?

Our next stop is the exstart state. Our routers are ready to sync their LSDB. At this step, we have to select a master and slave role. The router with the highest router ID will become the master. R2 has the highest router ID and will become the master.