OSPF routers within the area will ensure LSDB synchronization

All OSPF routers in the same area have the identical LSDB. In other words, ensure synchronization of the LSDB. The LSDB synchronization process is basically done between two OSPF routers that form adjacency.

This section describes the LSDB synchronization process between two OSPF routers that are adjacency on Ethernet.

Synchronization process of OSPF LSDB

Let’s take a look at how to ensure LSDB synchronization on R1 and R2 in the following network diagram.

Figure OSPF LSDB Synchronization Network Diagram
Figure OSPF LSDB Synchronization Network Diagram

The process flow to ensure synchronization of LSDB in OSPF is as follows.

  1. Establish neighbor/adjacency with Hello packets
  2. Exchanging DD packets
  3. Advertising LSAs with LSR/LSU/LSAck packets

Establish neighbor/adjacency with Hello packets

The Hello packet discovers the neighbor, which is an OSPF router on the same network.

Assume that R1 sends the Hello packet first. Initially, the neighbor list of the Hello packet in R1 does not contain anything. When R2 receives the Hello packet, it recognizes the existence of R1, an OSPF router on the same network, and registers R1 in its neighbor table. At this time, R1 will be in the state of “INIT” on R2’s neighbor table.

When sending Hello packets from R2, the neighbor list will contain the router ID 1.1.1.1 of R1.R1 recognizes the existence of R2 by receiving Hello packets from R2, and registers R2 in its neighbor table. Also, the neighbor list of the Hello packet sent from R1 will contain the router ID of R2. The state where R1 and R2 recognize each other in this way is “2WAY”.

In a multi-access network such as Ethernet, the DR/BDR is elected: R1 is the DR from the priority, and R2 is the BDR. when the DR/BDR is elected, the Hello packet contains the IP address of each.

Figure OSPF LSDB Synchronization Part 1

Related article

For more information about OSPF Hello packets, see also the following articles

N-Study
OSPF Hello Packet | N-Study
https://www.n-study.com/en/ospf-detail/ospf-hello/
OSPF Hello packets are used to establish OSPF neighbors; this section details the format of OSPF Hello packets and the conditions for establishing a neighbor.

Exchanging DD packets

In order to synchronize the LSDBs in R1 and R2, the LSAs contained in each LSDB must be known. With the DD (Database Description) packet, R1 and R2 teach each other the summary information of the LSAs contained in their LSDB. The summary information of an LSA is the information of the header part of the LSA only.

Figure OSPF DD Packet Overview

When DD packets are exchanged, they determine which side to start from. That is master/slave. The router with the higher router ID becomes the master and sends the DD packet first. In this example, R2 is the master and R1 is the slave. The state in which the master/slave is determined is “ExStart”.

The master, R2, sends DD packets to inform the LSA header contained in its LSDB, and the slave, R1, sends DD packets to inform the LSA header contained in its LSDB. The state in which DD packets are exchanged is “ExChange”.

Figure OSPF LSDB Synchronization Part 2

Although omitted in the figure, empty DD packets are exchanged when determining the master/slave.

Related article

For more information about OSPF DD packets, see also the following articles

N-Study
OSPF DD(Database Description) Packet | N-Study
https://www.n-study.com/en/ospf-detail/ospf-dd/
OSPF DD packets are packets that provide an overview of LSDB. the format of DD packets is explained.

Advertising LSAs with LSR/LSU/LSAck packets

By exchanging DD packets, each router knows the LSAs that are missing in its own LSDB. LSR (Link State Request) packets request the missing LSAs. The LSU (Link State Update) advertises the LSA requested by the LSR. And when the LSU is received, LSAck is used to confirm the receipt. LSAckは受信したLSAのヘッダ部分のみを含んでいます。

R1 requests the missing LSA by LSR, R2 sends the LSA by LSU. R2 sends the LSA by LSU, and R1 notifies that the LSA was received by LSAck. R2 behaves in the same way. Then, the LSDBs of R1 and R2 will eventually have the same contents, and the LSDB synchronization will be completed.

The state in which LSR/LSU/LSAck is synchronizing LSDB is “LOADING”. And the state that LSDB synchronization is completed is “FULL”.

Figure OSPF LSDB Synchronization Part3

Related article

For more information about OSPF LSR/LSU/LSAck packets, please see the following articles.

N-Study
OSPF LSR(Link State Request) Packet | N-Study
https://www.n-study.com/en/ospf-detail/ospf-lsr/
Request the LSA with OSPF LSR Packet. This section describes the format of LSR packet.
N-Study
OSPF LSU(Link State Update) Packet | N-Study
https://www.n-study.com/en/ospf-detail/ospf-lsu/
The OSPF LSU packet is used to advertise the LSAs requested in the LSR packet.
N-Study
OSPF LSAck(Link State Acknowledgement) Packet | N-Study
https://www.n-study.com/en/ospf-detail/ospf-lsack/
OSPF LSAck packet is a packet to confirm the reception of LSAs.

Debug output and packet capture for LSDB synchronization

On Cisco routers, you can use the debug ip ospf adj command to verify the status of LSDB synchronization on the console. On R1, which we have described so far, if you verify the LSDB synchronization using the debug ip ospf adj command, you will see the following output.

debug ip ospf adjの出力例

R1(config-if)#do debug ip ospf adj
OSPF adjacency events debugging is on
R1(config-if)#no shutdown
R1(config-if)#
*Mar  1 00:33:47.327: OSPF: Interface FastEthernet0/0 going Up
*Mar  1 00:33:47.831: OSPF: Build router LSA for area 0, router ID 1.1.1.1, seq 0x80000002, process 1
R1(config-if)#
*Mar  1 00:33:49.307: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:33:50.307: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#
*Mar  1 00:33:56.607: OSPF: 2 Way Communication to 2.2.2.2 on FastEthernet0/0, state 2WAY
R1(config-if)#
*Mar  1 00:33:58.147: OSPF: end of Wait on interface FastEthernet0/1
*Mar  1 00:33:58.147: OSPF: DR/BDR election on FastEthernet0/1
*Mar  1 00:33:58.147: OSPF: Elect BDR 1.1.1.1
*Mar  1 00:33:58.147: OSPF: Elect DR 1.1.1.1
*Mar  1 00:33:58.147: OSPF: Elect BDR 0.0.0.0
*Mar  1 00:33:58.151: OSPF: Elect DR 1.1.1.1
*Mar  1 00:33:58.151:        DR: 1.1.1.1 (Id)   BDR: none
*Mar  1 00:33:58.651: OSPF: No full nbrs to build Net Lsa for interface FastEthernet0/1
R1(config-if)#
*Mar  1 00:34:27.331: OSPF: end of Wait on interface FastEthernet0/0
*Mar  1 00:34:27.331: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:34:27.331: OSPF: Elect BDR 1.1.1.1
*Mar  1 00:34:27.331: OSPF: Elect DR 1.1.1.1
*Mar  1 00:34:27.331: OSPF: Elect BDR 2.2.2.2
*Mar  1 00:34:27.331: OSPF: Elect DR 1.1.1.1
*Mar  1 00:34:27.331:        DR: 1.1.1.1 (Id)   BDR: 2.2.2.2 (Id)
*Mar  1 00:34:27.331: OSPF: Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0x173A opt 0x52 flag 0x7 len 32
*Mar  1 00:34:27.831: OSPF: No full nbrs to build Net Lsa for interface FastEthernet0/0
R1(config-if)#
*Mar  1 00:34:29.575: OSPF: Rcv DBD from 2.2.2.2 on FastEthernet0/0 seq 0xFB1 opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART
*Mar  1 00:34:29.575: OSPF: NBR Negotiation Done. We are the SLAVE
*Mar  1 00:34:29.579: OSPF: Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0xFB1 opt 0x52 flag 0x2 len 52
*Mar  1 00:34:29.623: OSPF: Rcv DBD from 2.2.2.2 on FastEthernet0/0 seq 0xFB2 opt 0x52 flag 0x3 len 52  mtu 1500 state EXCHANGE
*Mar  1 00:34:29.623: OSPF: Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0xFB2 opt 0x52 flag 0x0 len 32
*Mar  1 00:34:29.651: OSPF: Rcv DBD from 2.2.2.2 on FastEthernet0/0 seq 0xFB3 opt 0x52 flag 0x1 len 32  mtu 1500 state EXCHANGE
*Mar  1 00:34:29.655: OSPF: Exchange Done with 2.2.2.2 on FastEthernet0/0
*Mar  1 00:34:29.655: OSPF: Send LS REQ to 2.2.2.2 length 12 LSA count 1
*Mar  1 00:34:29.655: OSPF: Send DBD to 2.2.2.2 on FastEthernet0/0 seq 0xFB3 opt 0x52 flag 0x0 len 32
*Mar  1 00:34:29.675: OSPF: Rcv LS REQ from 2.2.2.2 on FastEthernet0/0 length 36 LSA count 1
*Mar  1 00:34:29.675: OSPF: Send UPD to 192.168.12.2 on FastEthernet0/0 length 52 LSA count 1
*Mar  1 00:34:29.687: OSPF: Rcv LS UPD from 2.2.2.2 on FastEthernet0/0 length 76 LSA count 1
*Mar  1 00:34:29.687: OSPF: Synchronized with 2.2.2.2 on FastEthernet0/0, state FULL
*Mar  1 00:34:29.687: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Mar  1 00:34:30.067: OSPF: Rcv LS UPD from 2.2.2.2 on FastEthernet0/0 length 76 LSA count 1
*Mar  1 00:34:30.191: OSPF: Build router LSA for area 0, router ID 1.1.1.1, seq 0x80000003, process 1
*Mar  1 00:34:30.191: OSPF: Build network LSA for FastEthernet0/0, router ID 1.1.1.1
*Mar  1 00:34:30.191: OSPF: Build network LSA for FastEthernet0/0, router ID 1.1.1.1
R1(config-if)#
R1(config-if)#
*Mar  1 00:34:36.263: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:34:36.263: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:34:36.263: OSPF: Elect BDR 2.2.2.2
*Mar  1 00:34:36.267: OSPF: Elect DR 1.1.1.1
*Mar  1 00:34:36.267:        DR: 1.1.1.1 (Id)   BDR: 2.2.2.2 (Id)
*Mar  1 00:34:36.267: OSPF: Neighbor change Event on interface FastEthernet0/0
*Mar  1 00:34:36.267: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:34:36.267: OSPF: Elect BDR 2.2.2.2
*Mar  1 00:34:36.271: OSPF: Elect DR 1.1.1.1
*Mar  1 00:34:36.271:        DR: 1.1.1.1 (Id)   BDR: 2.2.2.2 (Id)
R1(config-if)#do u all
All possible debugging has been turned off
R1(config-if)#

In addition, a file captured by Wireshark of the LSDB synchronization between R1 and R2 is available for download below.

OSPF LSDB Synchronization packet capture file download

Eventually, synchronize LSDB on all OSPF routers in the area

So far, we have seen how to ensure LSDB synchronization between two OSPF routers that form an adjacency. Eventually, it is important to have a good grasp of LSDB synchronization on all OSPF routers in the area. All OSPF routers in R1 to R5 in the following figure will have the identical LSDB.

Figure All OSPF routers in an area synchronize their LSDB
Figure All OSPF routers in an area synchronize their LSDB

How the OSPF works