A deep dive into the OSPF adjacency process

Although, the topology begs to differ...
Let me preface this by saying that this is not a crazy topology…

OSPF Packet Type Overview

OSPF uses it’s own protocol for communication.

This protocol defines five different packet types.

  1. Hello
  2. Database Descriptor
  3. Link-State Request
  4. Link-State Update
  5. Link-State Acknowledgement.

OSPF Adjacency Overview

RFC 2328 Adjacency States

Down State

A hello packet has not been heard.

Init State

A hello packet has been heard but does not list it’s own router ID.

2-way State

A hello packet has been heard and also is listing it’s own router ID. (both seen each other)

ExStart State

The two routers elect a master and a slave based on their Router ID and determine sequence numbers.

Exchange State

Routers start exchanging DBD Packets between each other.

Loading State

The routers send LSR’s to finish populating the LSDB.

Full State

The routers have finished syncing and have same LSDBs.

 

Now for the gory details

The standard OSPF Header and Hello Packet

Blue is the standard header / Red is the Hello

The Down State of the Adjacency

The routers are sending hello’s but have not received a hello packet from any neighbor. So sad.

Quick refresher on OSPF adjacency requirements:

  • MTU must match
  • Must be in same subnet
  • Same Area and type! (stub must match in entire area)
  • Router ID’s must be unique
  • Hello and Hold Timers must match

 

Two of the five above requirements are covered with a simple OSPF header with two more in the hello packet. MTU comes into play with the next packet type.

OSPF Header
Version: 2
Message Type: Hello Packet (1)
Packet Length: 44
Source OSPF Router: 2.2.2.2
Area ID: 0.0.0.0 (Backbone)
Checksum: 0xe79e [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000

OSPF Hello Packet
Network Mask: 255.255.255.252
Hello Interval [sec]: 10
Options: 0x12 ((L) LLS Data block, (E) External Routing)
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
OSPF LLS Data Block

Init and 2-way State of Adjacency

A router is now sending Hello Packets and as soon as a  router receives a Hello Packet, it enters Init State. Keep in mind that that Hello Packet still did not list its own router ID just yet.

The routers enter the 2-way State when the neighbors have both heard their own router ID’s in the network ID field of the hello packets.

Before transitioning to the next state, a DR and BDR is elected if necessary. If using the defaults, the higher router ID wins.

OSPF Hello Packet
Network Mask: 255.255.255.252
Hello Interval [sec]: 10
Options: 0x12 ((L) LLS Data block, (E) External Routing)
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Active Neighbor: 1.1.1.1

Database Description Packet

Up until now we’ve only seen one type of packet being used — the Hello Packet — now we’ll introduce another packet that is only ever utilized during the adjacency process.

Introducing, the Database Description Packet!

OSPF Database Description packet

A Database Description packet hereby known as a DD Packet only has a few fields which we’ll focus on at the moment.

  • I — Initial bit — set if it is the first packet being sent
  • M — More bit — set if there is more packets to send
  • MS — Master Slave bit — set if router is the master
  • LSA — Link State Advertisement Header

Knowledge of this packet leads us into our next adjacency phase.

EXSTART in green / Exchange in purple

EXSTART Adjacency Phase

So both routers have seen each other and are now ready to begin exchanging information. In this state the routers need to determine which one will be the MASTER and which one will be the SLAVE.

They both begin by sending empty DD Packets with the I, M and MS bit set to 1. They also both choose a DD sequence number.

Its at this point in time where the router with the lower router ID will realize that it should become the slave. Once this occurs, the SLAVE will adopt the sequence number of the MASTER and set it’s own MS bit to 0.

The entire purpose of the MASTER SLAVE relationship is to determine which router will send the initial DD Packets and set the sequence numbers.

vIOS2 as the master

OSPF DB Description
Interface MTU: 1500
Options: 0x52 (O, (L) LLS Data block, (E) External Routing)
DB Description: 0x07 ((I) Init, (M) More, (MS) Master)
…. 0… = (R) OOBResync: Not set
…. .1.. = (I) Init: Set
…. ..1. = (M) More: Set
…. …1 = (MS) Master: Yes
DD Sequence: 8146
OSPF LLS Data Block

 

vIOS1 as the SLAVE

OSPF DB Description
Interface MTU: 1500
Options: 0x52 (O, (L) LLS Data block, (E) External Routing)
DB Description: 0x00
…. 0… = (R) OOBResync: Not set
…. .0.. = (I) Init: Not set
…. ..0. = (M) More: Not set
…. …0 = (MS) Master: No
DD Sequence: 8146
OSPF LLS Data Block

Notice that vIOS1 has adopted vIOS2’s sequence number and has changed the I, M and MS bits to 0.

The SLAVE has agreed upon the DD Sequence Numbers and MASTER election. Time to move on to the next phase.

The OSPF Exchange Phase

The MASTER is now sending DD packets that are no longer empty. Instead, they hold LSA header information. We’ll cover the LSA’s in another post since this one is getting lengthy. Nonetheless, below is the first non-empty DD Packet sent from vIOS2.

vIOS2
OSPF DB Description
Interface MTU: 1500
Options: 0x52 (O, (L) LLS Data block, (E) External Routing)
DB Description: 0x01 ((MS) Master)
…. 0… = (R) OOBResync: Not set
…. .0.. = (I) Init: Not set
…. ..0. = (M) More: Not set
…. …1 = (MS) Master: Yes
DD Sequence: 8147

LSA-type 1 (Router-LSA), len 48
.000 0011 1010 1110 = LS Age (seconds): 942
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)
LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000003
Checksum: 0x121f
Length: 48

LSA-type 2 (Network-LSA), len 32
.000 0011 1010 1110 = LS Age (seconds): 942
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)
LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000001
Checksum: 0x02bb
Length: 32
OSPF LLS Data Block

That one packet has two LSA’s a type 1 and a type 2.

vIOS1 will acknowledge receipt of the above packet by sending a DD packet back to vIOS2 with the same DD sequence number which in this case if looking above is 8147.

vIOS1 (the slave) is only sending empty DD packets for acknowledgement only. It is not advertising any of it’s own LSA’s through DD packets. Since there was only one DD packet to send which is indicated with the 0 bit set in the ‘More’ field, we’ve now reached the second to final stage.

OSPF Loading Phase

Time to introduce the final OSPF packet types: a Link-State Request Packet, Link-State Update Packet and finally a Link-State Acknowledgement packet. These are the last types of packets I promise!

Link-State Request Packet

This packet is sent from a router if it does not have up to date information regarding the LSA header that it received from the DD packets. It knows whether or not its up to date from the LSA age field in the initial DD packets.

vIOS1
OSPF Header
Link State Request
LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Link State Request
LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2

Notice in the above packet vIOS1 is asking vIOS2 to send it information regarding two LSA’s.

So how does vIOS2 respond to a LSA Request Packet? With a LSA Update Packet.

OSPF LSA Update Packet

LSA Update Packet

This packet contains two fields. The number of LSA’s in the packet and the actual LSA’s themselves.

Below is the LSA Update Packet that vIOS2 sends upon receiving the LSA Request Packet.

vIOS2
OSPF Header
LS Update Packet
Number of LSAs: 2
LSA-type 1 (Router-LSA), len 48
.000 0000 0001 1010 = LS Age (seconds): 26
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)

LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000033
Checksum: 0xb14f
Length: 48
Flags: 0x00
Number of Links: 2
Type: Stub ID: 2.2.2.2 Data: 255.255.255.255 Metric: 1
Link ID: 2.2.2.2 – IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 – Connection to a stub network
Number of Metrics: 0 – TOS
0 Metric: 1
Type: Transit ID: 192.168.0.2 Data: 192.168.0.2 Metric: 1
Link ID: 192.168.0.2 – IP address of Designated Router
Link Data: 192.168.0.2
Link Type: 2 – Connection to a transit network
Number of Metrics: 0 – TOS
0 Metric: 1

LSA-type 2 (Network-LSA), len 32
.000 0011 0110 1001 = LS Age (seconds): 873
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)
LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000005
Checksum: 0xf9bf
Length: 32
Netmask: 255.255.255.252
Attached Router: 2.2.2.2
Attached Router: 1.1.1.1

vIOS1 receives the update packet and acknowledges receipt with the final packet type a LSA Acknowledgement Packet which is discussed below.

OSPF LSA Acknowledgement Packet

LSA Acknowledgement Packet

This packet shares almost the same exact structure as a Database Description packet except it doesn’t have a sequence number field.

OSPF Header
LSA-type 1 (Router-LSA), len 48
.000 0000 0001 1010 = LS Age (seconds): 26
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)

LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000033
Checksum: 0xb14f
Length: 48
LSA-type 2 (Network-LSA), len 32
.000 0011 0110 1001 = LS Age (seconds): 873
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)

LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000005
Checksum: 0xf9bf
Length: 32

During the loading phase an OSPF router will continue requesting link-state information until it can build a complete database. The routers will continue sending link-state request, link-state update and link-state acknowledgement packets until this is achieved.

OSPF Full Phase

At this point adjacency has been fully established and the databases between area neighbors are fully synchronized.

We didn’t cover the LSA types in this post so we’ll save it for next time. All information in this post is in reference to RFC 2328.

Thanks for reading!

 

 

One thought on “A deep dive into the OSPF adjacency process”

Leave a Reply

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