Loading learning content...
OSPF's power lies in a remarkable property: every router in an area computes routes from an identical view of the network topology. This isn't coincidence or configuration—it's the result of a sophisticated database synchronization process that ensures all routers possess the same Link-State Database (LSDB).
But how do distributed systems achieve this consistency? When Router A joins a network with established Router B, how does A obtain B's entire database? When network topology changes, how do updates propagate reliably? The answer lies in OSPF's database synchronization mechanism—a carefully orchestrated exchange protocol that handles initial synchronization, incremental updates, and ensures reliable delivery.
Database synchronization is the heart of link-state routing. Unlike distance-vector protocols where routers share only their own view, OSPF routers share raw topology data and compute routes independently. This requires perfect synchronization—any discrepancy leads to routing loops or black holes.
By the end of this page, you will understand: (1) Why database synchronization is critical for link-state routing, (2) The complete Database Description (DD) packet exchange process, (3) Master/Slave negotiation and sequence number handling, (4) Link State Request/Update/Acknowledgment packet mechanics, (5) How initial synchronization differs from ongoing flooding, and (6) Common synchronization problems and their solutions.
To understand database synchronization, we must first understand why it's essential and what happens without it.
The Link-State Database (LSDB):
Every OSPF router maintains an LSDB—a complete map of all links, routers, and networks in its area. This database consists of Link-State Advertisements (LSAs), each describing some portion of the topology:
The critical requirement: All routers in an area must have identical Type 1 and Type 2 LSAs. If Router A's LSDB differs from Router B's, they'll compute different shortest path trees, potentially creating loops.
Why LSDB Consistency Matters - Example═══════════════════════════════════════════════════════════════════════════ Scenario: 4 routers, R1-R2-R3-R4 in a square topology Physical Topology: ════════════════════ ┌─────┐ 10 ┌─────┐ │ R1 │─────────────│ R2 │ └─────┘ └─────┘ │ │ 20 │ │ 5 │ │ ┌─────┐ 10 ┌─────┐ │ R4 │─────────────│ R3 │ └─────┘ └─────┘ (Numbers are link costs) Case 1: All Routers Have Consistent LSDB─────────────────────────────────────────────────────────────────────────────All routers see: R1-R2(10), R1-R4(20), R2-R3(5), R3-R4(10) R1 → R3 path calculation: • R1: Best path via R2 → R3 (cost 15) ✓ • R4: Best path to R3 direct (cost 10) ✓ Traffic flows correctly, no loops. Case 2: R4 Has Stale LSDB (Missing R2-R3 link update)─────────────────────────────────────────────────────────────────────────────R4's outdated view: thinks R2-R3 cost is 50 (old value) R1 → R3 path calculation: • R1: Still sends via R2 (cost 15 in R1's view) • R4: Thinks path via R1-R2-R3 costs 65, chooses R1 for R3-bound traffic Result: R1 sends to R2, but R4 might send R3-bound traffic to R1!Potential routing loop until R4's LSDB is updated. ═══════════════════════════════════════════════════════════════════════════Conclusion: LSDB consistency is not optional—it's mandatory for correctness.When Synchronization Occurs:
Database synchronization happens at two distinct times:
Initial Synchronization: When a new adjacency forms (neighbor reaches EXSTART state), the routers exchange their complete LSDBs with each other.
Incremental Updates: When topology changes (link up/down, cost change), affected routers generate new LSA versions and flood them through the network.
The initial synchronization is what transforms empty adjacencies into operational routing relationships. Without it, routers would have no topology data from their neighbors.
A router cannot use an adjacency for routing until synchronization completes and the neighbor reaches FULL state. In the EXSTART, EXCHANGE, and LOADING states, the adjacency is "warming up"—routers are exchanging data but haven't finished synchronizing their databases.
OSPF uses four specific packet types for database synchronization. Each serves a distinct role in the exchange process.
Database Synchronization Packet Overview:
| Type | Name | Direction | Purpose | When Used |
|---|---|---|---|---|
| 2 | Database Description (DD) | Bidirectional | Summarize LSDB contents (LSA headers) | EXSTART, EXCHANGE states |
| 3 | Link State Request (LSR) | Requesting router → Holder | Request specific LSAs by identifier | LOADING state |
| 4 | Link State Update (LSU) | Holder → Requester | Send full LSA content | LOADING state and flooding |
| 5 | Link State Acknowledgment (LSAck) | Receiver → Sender | Confirm LSA receipt for reliability | After LSU reception |
Database Description (DD) Packet:
The DD packet carries LSA headers (not full LSAs) that describe what the router has in its LSDB. This allows neighbors to efficiently learn what each other knows without transferring entire LSAs upfront.
Database Description (DD) Packet Structure═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1├───────────────────────────────┼───────────────────────────────┤│ Interface MTU │ Options │├───────────────────────────────┼─────┬─────┬─────┬─────────────┤│ Reserved │ 0 │ I │ M │ MS │├───────────────────────────────┴─────┴─────┴─────┴─────────────┤│ DD Sequence Number │├───────────────────────────────────────────────────────────────┤│ ││ LSA Header 1 (20 bytes) ││ │├───────────────────────────────────────────────────────────────┤│ LSA Header 2 (20 bytes) ││ │├───────────────────────────────────────────────────────────────┤│ ... │└───────────────────────────────────────────────────────────────┘ Key Fields:════════════• Interface MTU: Maximum packet size (MUST MATCH between neighbors!)• Options: Capability flags (same as Hello packet)• I-bit (Init): Set in first DD packet only• M-bit (More): Set if more DD packets follow• MS-bit (Master/Slave): 1 = Master, 0 = Slave• DD Sequence Number: Monotonically increasing, ensures ordering LSA Header (20 bytes each):════════════════════════════Each header identifies an LSA:• LS Age (2 bytes): How old the LSA is• Options (1 byte): Options from originating router• LS Type (1 byte): Type 1-7• Link State ID (4 bytes): Identifier (varies by type)• Advertising Router (4 bytes): Router that created this LSA• LS Sequence Number (4 bytes): Version number (higher = newer)• LS Checksum (2 bytes): Fletcher checksum• Length (2 bytes): Total LSA length (header + body)Link State Request (LSR) Packet:
After exchanging DD packets, a router knows which LSAs the neighbor has that it needs. The LSR packet requests specific LSAs by their identifying information.
Link State Request (LSR) Packet Structure═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1├───────────────────────────────────────────────────────────────┤│ LS Type (1) │├───────────────────────────────────────────────────────────────┤│ Link State ID (1) │├───────────────────────────────────────────────────────────────┤│ Advertising Router (1) │├───────────────────────────────────────────────────────────────┤│ LS Type (2) │├───────────────────────────────────────────────────────────────┤│ Link State ID (2) │├───────────────────────────────────────────────────────────────┤│ Advertising Router (2) │├───────────────────────────────────────────────────────────────┤│ ... │└───────────────────────────────────────────────────────────────┘ Each request entry is 12 bytes:• LS Type: The LSA type wanted• Link State ID: The specific identifier• Advertising Router: Who originated the LSA Multiple LSAs can be requested in a single LSR packet.The DD→LSR→LSU sequence is efficient because routers first exchange compact headers (20 bytes each), then request only the LSAs they actually need. If a router already has an LSA (or a newer version), it doesn't request it, saving bandwidth during synchronization.
Before DD packets can be exchanged, the two routers must agree on who controls the exchange. This Master/Slave relationship ensures orderly, reliable packet exchange with proper sequencing.
Why Master/Slave?
The DD exchange uses a poll/response mechanism similar to HDLC. One router (the Master) controls the conversation by:
The other router (the Slave) responds to the Master's DD packets with its own DD packets using the Master's sequence number. This ensures all packets are properly acknowledged and none are lost.
Negotiation Process (EXSTART State):
Master/Slave Negotiation - EXSTART State═══════════════════════════════════════════════════════════════════════════ Initial state: Both routers in 2-WAY, ready to form adjacency.Both enter EXSTART state. Step 1: Both routers send initial DD (empty, I/M/MS all set to 1)───────────────────────────────────────────────────────────────────────────── Router A (RID: 1.1.1.1) Router B (RID: 2.2.2.2) [EXSTART] [EXSTART] │ │ │ DD Packet (I=1, M=1, MS=1) │ │ Seq = 100 (A's initial) │ │───────────────────────────────────▶│ │ │ │ DD Packet (I=1, M=1, MS=1) │ │ Seq = 200 (B's initial) │ │◀───────────────────────────────────│ │ │ Both routers claim to be Master (MS=1). Conflict resolution: HIGHER Router ID wins. B (2.2.2.2) > A (1.1.1.1), so B becomes Master. Step 2: Slave acknowledges Master───────────────────────────────────────────────────────────────────────────── Router A (SLAVE) Router B (MASTER) │ │ │ DD Packet (I=0, M=1, MS=0) │ │ Seq = 200 (use Master's seq!) │ │───────────────────────────────────▶│ │ │ A sends DD with: • I=0: No longer initial • MS=0: Acknowledging Slave role • Seq=200: Using B's sequence number (accepts B as Master) This transitions both to EXCHANGE state. ═══════════════════════════════════════════════════════════════════════════ Summary:• Both start claiming Master (MS=1)• Higher Router ID wins Master role• Loser becomes Slave (MS=0) and uses Master's sequence number• This handshake is the EXSTART state's purpose Higher RID = Master ┌─────────────────────────────────────────────────┐ │ Router ID Comparison: 2.2.2.2 > 1.1.1.1 │ │ │ │ Router B (2.2.2.2) → MASTER │ │ Router A (1.1.1.1) → SLAVE │ └─────────────────────────────────────────────────┘Exchange Mechanics:
Once Master/Slave is established:
The sequence number acts as both an ordering mechanism and an implicit acknowledgment. If the Slave doesn't respond with the correct sequence number, the Master retransmits.
| Flag | Initial DD | Master During Exchange | Slave During Exchange |
|---|---|---|---|
| I (Init) | 1 (first packet) | 0 | 0 |
| M (More) | 1 (more to send) | 1 until last packet, then 0 | 1 until last, then 0 |
| MS (Master/Slave) | 1 (claim Master) | 1 (is Master) | 0 (is Slave) |
If routers get stuck in EXSTART state, the most common cause is an MTU mismatch. The Interface MTU field in the DD packet must match—if one router sends MTU 1500 and the other has MTU 1400, the DD is rejected. Also check for duplicate Router IDs (both routers have the same RID = neither can win Master).
After Master/Slave negotiation completes in EXSTART, routers enter the EXCHANGE state where they send DD packets containing LSA headers. This is where the actual database summary exchange occurs.
Complete Exchange Sequence:
DD Exchange Process - EXCHANGE State═══════════════════════════════════════════════════════════════════════════ Scenario: Router B is Master (higher RID), Router A is SlaveBoth have some LSAs to advertise. Router A (SLAVE) Router B (MASTER) │ │ │ │ DD #1: Seq=200, M=1 │◀───────────────────────────────────│ Contains: LSA headers 1-5 │ │ │ DD #1: Seq=200, M=1 │ │ Contains: LSA headers A-C │ │───────────────────────────────────▶│ │ │ │ │ DD #2: Seq=201, M=1 │◀───────────────────────────────────│ Contains: LSA headers 6-10 │ │ │ DD #2: Seq=201, M=1 │ │ Contains: LSA headers D-F │ │───────────────────────────────────▶│ │ │ │ │ DD #3: Seq=202, M=0 (last!) │◀───────────────────────────────────│ Contains: LSA headers 11-12 │ │ │ DD #3: Seq=202, M=0 (last!) │ │ Contains: LSA header G │ │───────────────────────────────────▶│ │ │ Exchange complete when both send M=0 (no more data). During Exchange, Each Router:════════════════════════════1. Receives neighbor's LSA headers2. Compares to own LSDB: • If LSA is newer than local → Add to REQUEST LIST • If LSA is older than local → Will be sent in Update later • If LSA is same → No action needed3. Builds REQUEST LIST of LSAs to fetch from neighbor ═══════════════════════════════════════════════════════════════════════════ Request List Building Example: Router A receives B's DD packets with these LSA headers:─────────────────────────────────────────────────────────────────────────────│ LSA ID │ Seq in DD │ A's Local Seq │ Action │├───────────────┼──────────────┼───────────────┼──────────────────┤│ 1.1.1.1/Type1 │ 0x80000005 │ 0x80000005 │ Already have ││ 2.2.2.2/Type1 │ 0x80000003 │ (none) │ ADD TO REQUEST ││ 3.3.3.3/Type1 │ 0x80000010 │ 0x80000008 │ ADD TO REQUEST ││ 10.0.0.0/Type2│ 0x80000001 │ 0x80000002 │ A has newer, nop │───────────────────────────────────────────────────────────────────────────── A's Request List after exchange: [2.2.2.2/Type1, 3.3.3.3/Type1]Key Observations:
Both routers send DD packets — Even though there's a Master/Slave relationship, BOTH routers include their LSA headers. The roles only affect sequencing, not who shares data.
Implicit acknowledgment — The Slave's response with the correct sequence number serves as acknowledgment. If the Master doesn't receive a response, it retransmits.
Request list population — The primary output of the DD exchange is the request list: LSAs you need from your neighbor that are newer than what you have (or that you don't have at all).
M-bit coordination — Both routers independently set M=0 when they have no more LSA headers to send. The exchange ends when both have sent M=0.
A single DD packet can contain dozens of LSA headers (20 bytes each). For a typical enterprise network with hundreds of LSAs, the entire DD exchange might complete in just a few packets, making initial synchronization quite fast over modern links.
After the DD exchange completes (EXCHANGE state ends), routers transition to the LOADING state if they have LSAs to request. In this state, routers use Link State Request (LSR) and Link State Update (LSU) packets to fetch the actual LSA content.
Loading State Sequence:
Loading State - LSR/LSU Exchange═══════════════════════════════════════════════════════════════════════════ After DD exchange, Router A has request list: [2.2.2.2/Type1, 3.3.3.3/Type1]Router B has request list: [10.0.0.0/Type2] Both enter LOADING state. Router A Router B [LOADING] [LOADING] │ │ │ Link State Request │ │ Request: 2.2.2.2/Type1, │ │ 3.3.3.3/Type1 │ │───────────────────────────────────▶│ │ │ │ Link State Update │ │◀───────────────────────────────────│ │ Contains: Full LSAs for both │ │ │ │ Link State Acknowledgment │ │───────────────────────────────────▶│ │ Ack: 2.2.2.2/Type1, 3.3.3.3/Type1 │ │ │ │ Link State Request │ │◀───────────────────────────────────│ │ Request: 10.0.0.0/Type2 │ │ │ │ Link State Update │ │───────────────────────────────────▶│ │ Contains: Full LSA 10.0.0.0/Type2 │ │ │ │ Link State Acknowledgment │ │◀───────────────────────────────────│ │ │ Both request lists empty → Both transition to FULL state! ┌─────────────────────────────────────────────────────────────────┐ │ ADJACENCY COMPLETE - FULL STATE │ │ │ │ • Databases are synchronized │ │ • SPF calculation can proceed │ │ • Routing tables will now include this adjacency │ └─────────────────────────────────────────────────────────────────┘Link State Update (LSU) Packet:
The LSU packet carries complete LSAs, not just headers. This is where the actual topology data is transferred.
Link State Update (LSU) Packet Structure═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1├───────────────────────────────────────────────────────────────┤│ # of LSAs (4 bytes) │├───────────────────────────────────────────────────────────────┤│ ││ LSA 1 (Header + Body, variable) ││ │├───────────────────────────────────────────────────────────────┤│ ││ LSA 2 (Header + Body, variable) ││ │├───────────────────────────────────────────────────────────────┤│ ... │└───────────────────────────────────────────────────────────────┘ LSA Structure (for each LSA in the update):════════════════════════════════════════════┌────────────────────────────────────────┐│ LSA Header (20 bytes) ││ • LS Age, Options, LS Type ││ • Link State ID, Advertising Router ││ • LS Sequence Number, Checksum ││ • Length │├────────────────────────────────────────┤│ LSA Body (variable) ││ • Content depends on LSA Type ││ • Router LSA: link entries ││ • Network LSA: attached routers ││ • Summary/External: prefix/metric │└────────────────────────────────────────┘Link State Acknowledgment (LSAck) Packet:
OSPF uses explicit acknowledgment for reliable LSA delivery. Every LSA received in an LSU must be acknowledged with an LSAck packet. The LSAck contains LSA headers of the acknowledged LSAs.
| Ack Type | When Used | Method |
|---|---|---|
| Delayed Ack | Normal case | Batch ack multiple LSAs in single LSAck (up to RxmtInterval) |
| Direct Ack | Immediate response required | Individual LSAck sent immediately |
| Implicit Ack | Neighbor is origin of LSA | Receiving the same LSA from another interface acknowledges |
The transition from LOADING to FULL occurs when the router's request list for that neighbor becomes empty—all requested LSAs have been received. If both routers had empty request lists after DD exchange (their LSDBs were already synchronized), they skip LOADING entirely and go directly to FULL.
Beyond initial synchronization, OSPF uses reliable flooding to propagate topology changes throughout the network. When a link changes state, the affected router generates a new LSA version and floods it to all neighbors—who then flood it to their neighbors, and so on.
The Flooding Algorithm:
Reliable Flooding Example═══════════════════════════════════════════════════════════════════════════ Topology: R1 ────── R2 ────── R3 ────── R4 Event: Link cost R1→R2 changes from 10 to 100 Step 1: R1 generates new Router LSA─────────────────────────────────────────────────────────────────────────────R1 creates Router LSA: • Link State ID: 1.1.1.1 • Advertising Router: 1.1.1.1 • LS Sequence: 0x80000005 → 0x80000006 (incremented) • Contains updated cost to R2 Step 2: R1 floods to R2───────────────────────────────────────────────────────────────────────────── R1 ────LSU────▶ R2 R1 ◀───LSAck─── R2 Step 3: R2 installs and re-floods─────────────────────────────────────────────────────────────────────────────R2 compares received LSA to local: • Local: 0x80000005, Received: 0x80000006 • Received is NEWER → Install in LSDB • Flood to all adjacencies except R1 R2 ────LSU────▶ R3 R2 ◀───LSAck─── R3 Step 4: R3 installs and re-floods───────────────────────────────────────────────────────────────────────────── R3 ────LSU────▶ R4 R3 ◀───LSAck─── R4 Step 5: R4 receives, installs, no more neighbors to flood─────────────────────────────────────────────────────────────────────────────R4 installs LSA in LSDB. Has no other adjacencies.Flooding complete. All routers now have updated view: R1→R2 cost = 100Each router runs SPF independently to update routes. Timeline (typical):════════════════════T=0: R1 detects changeT=0.01s: R2 receives, acks, re-floodsT=0.02s: R3 receives, acks, re-floodsT=0.03s: R4 receives, acksT=0.1s: All routers completed SPF, routes updatedFlood Prevention Mechanisms:
OSPF includes several mechanisms to prevent flooding loops and ensure efficiency:
| Mechanism | Purpose | How It Works |
|---|---|---|
| Sequence Numbers | Detect newest LSA version | Higher sequence = newer (wraps from 0x7FFFFFFF to 0x80000001) |
| LS Age | Expire old LSAs | LSAs age out after MaxAge (1 hour); must be refreshed |
| Checksum | Detect corruption | Fletcher checksum validated on receipt |
| Split Horizon | Prevent loops | Don't re-flood LSA back to interface it arrived on |
| MinLSInterval | Rate limit origination | Router waits 5s between originating same LSA |
| RxmtInterval | Ensure delivery | Retransmit LSA if no ack within 5s |
On broadcast networks (like Ethernet), routers send LSUs to the DR using 224.0.0.6 (AllDRouters). The DR then floods to 224.0.0.5 (AllSPFRouters). This prevents multiple duplicate LSUs from non-DR routers, optimizing flooding on multi-access networks.
Every LSA carries an age field that tracks how long it has existed. This mechanism ensures stale information is eventually removed from the network, even if the originating router fails silently.
LSA Aging Mechanics:
| Constant | Value | Purpose |
|---|---|---|
| LS Age at origination | 0 seconds | LSA starts fresh when created |
| Age increment | 1 per second | Each router ages LSAs in its LSDB |
| LSRefreshTime | 1800 seconds (30 min) | Originating router re-floods before expiry |
| MaxAge | 3600 seconds (1 hour) | LSA expires; flushed from all LSDBs |
| MaxAgeDiff | 900 seconds (15 min) | Max age difference to accept LSA as newer |
The LSA Lifecycle:
LSA Lifecycle Timeline═══════════════════════════════════════════════════════════════════════════ Time │ Event │ LS Age────────┼──────────────────────────────────────────┼─────────T=0 │ Router originates LSA │ 0T=1 │ Router ages LSA │ 1... │ ... │ ...T=300 │ LSA in LSDB, aging normally │ 300... │ ... │ ...T=1800 │ LSRefreshTime reached │ 1800 │ → Router originates NEW instance │ │ (Seq incremented, Age reset to 0) │T=1801 │ New instance flooded, old replaced │ 1 (new)... │ ... │ ... What if originating router fails?═══════════════════════════════════════════════════════════════════════════ T=0 │ Router A originates LSA (Seq: 0x80000005) │ 0T=500 │ Router A fails catastrophically │ 500 │ (No graceful shutdown, no MaxAge flush) │... │ Other routers continue aging A's LSA │ ...T=3600 │ LSA reaches MaxAge (3600) │ 3600 │ → All routers flush LSA from LSDB │ │ → SPF recalculates without A's routes │ │ → Network eventually converges │ MaxAge Flush Process:══════════════════════When any LSA reaches MaxAge:1. Router floods it with Age=MaxAge (explicit purge)2. All routers remove it from LSDB3. Routes dependent on that LSA are removed This ensures orphaned LSAs don't persist indefinitely.LSA Refresh Before Expiry:
Under normal operation, routers refresh their self-originated LSAs before they expire. At LSRefreshTime (30 minutes), the router:
This keeps the LSA perpetually alive as long as the originating router is operational. Neighbors never need to know if the underlying topology hasn't changed—the refresh maintains the LSA's presence in all LSDBs.
OSPF defines a DoNotAge (DNA) option for LSAs on demand circuits. LSAs with the DNA bit set don't age, preventing periodic refresh floods over metered/slow links. However, this requires all routers on the path to support the DC (Demand Circuit) option, or the LSA behaves normally.
Database synchronization issues can leave adjacencies stuck in intermediate states or cause routing inconsistencies. Understanding common problems and their solutions is essential for network operations.
Common Synchronization Problems:
| State Stuck | Likely Cause | Verification | Solution |
|---|---|---|---|
| EXSTART | MTU mismatch | show ip ospf interface - compare MTU | Match MTU or ip ospf mtu-ignore |
| EXSTART | Duplicate Router ID | show ip ospf - check RID | Set unique RIDs |
| EXCHANGE | DD packet loss/corruption | debug ip ospf adj | Check link quality, MTU |
| LOADING | LSA request not answered | debug ip ospf lsa-generation | Check neighbor LSDB, restart OSPF |
| LOADING (prolonged) | Very large databases | show ip ospf database count | Normal; wait for completion |
| Inconsistent LSDBs | Flooding problem | show ip ospf database compare | Check adjacencies, restart if needed |
1234567891011121314151617181920212223242526272829303132333435363738394041
! Troubleshooting OSPF Synchronization!! Step 1: Check neighbor stateshow ip ospf neighbor! Look for states other than FULL or 2-WAY! EXSTART stuck = likely MTU issue ! Step 2: Compare MTU on both endsshow ip ospf interface GigabitEthernet0/0! Interface MTU is 1500! Ensure both ends match ! Step 3: If MTU can't be changed, ignore MTU checkinterface GigabitEthernet0/0 ip ospf mtu-ignore! WARNING: Only use this if you understand the implications! Actual fragmentation may still cause issues ! Step 4: Check for duplicate Router IDshow ip ospf! Look for "Router ID" field! MUST be unique within OSPF domain ! Step 5: Verify LSDB is synchronizedshow ip ospf database! Compare output on both routers! Should be identical for Type 1, 2 LSAs in same area ! Step 6: Debug adjacency formation (use carefully!)debug ip ospf adj! Shows DD exchange, sequence numbers, state transitions ! Example output - MTU mismatch:OSPF: Rcv DBD from 2.2.2.2 on GigabitEthernet0/0OSPF: MTU mismatch: received 9000 config 1500OSPF: Dropping DBD packet ! Step 7: Force OSPF process restart (last resort)clear ip ospf process! This tears down ALL adjacencies and restarts! Use with extreme caution in productionLSDB Consistency Verification:
Periodically verify that LSDBs are consistent across your OSPF domain:
show ip ospf database database-summary on multiple routersshow ip ospf database router and compare Router LSA contentsOSPF is designed to self-heal. If you bounce an adjacency (e.g., shut/no shut an interface), the routers will re-execute the full synchronization process, typically resolving any transient database inconsistencies. However, persistent issues indicate a configuration or network problem that must be addressed.
We've covered the complete OSPF database synchronization process—from initial adjacency formation to ongoing flooding and LSA maintenance. Let's consolidate the key concepts:
What's Next:
With Hello protocol establishing neighbors and database synchronization achieving LSDB consistency, we're ready to explore what OSPF does with that data: SPF Calculation. Every router independently runs Dijkstra's algorithm on its synchronized LSDB to compute the shortest path tree and build its routing table.
You now understand how OSPF routers achieve and maintain database synchronization. This knowledge is critical for understanding OSPF behavior, diagnosing neighbor issues, and ensuring your network has consistent routing. The synchronization process, while invisible in steady state, is the foundation of everything OSPF does.