In OSPF, what does the link-state database hold, and why must every router in an area end up with an identical copy?
answer
- pieces written first-hand
- each LSA: its originator's own links
- same map, different root
- mismatched maps: loops, black holes
basics
~20 sThe OSPF link-state database is the set of LSAs in which each router describes only its own links and their costs. Every router in an area computes routes from it, so the copies must match; mismatched maps cause loops and black holes.
solid answer
~50 sAn OSPF router's **link-state database (LSDB)** is a collection of LSAs. Each LSA is one originator's description of its *own* local state — its usable interfaces, the neighbours it reaches and the cost of each link — identified by `LS type`, `Link State ID` and `Advertising Router`. Nobody describes another router's links, so the database is a topology graph assembled from first-hand pieces. RFC 2328 requires every router in an area to hold an identical database for that area, because each router runs the shortest-path calculation over it with itself as the root. The trees differ, but they are cut from one map, so the next hops agree. If two routers compute from different maps, one can hand a packet to a neighbour that hands it straight back — a loop — or send it toward a link that no longer exists — a black hole.
go deeper
Recall that each OSPF LSA describes only its originator's own links, that together they form one map, and that every router in the area must hold the same map.
Explain how one shared map yields different but consistent shortest-path trees, and name the header fields that identify an LSA and its instance.
Walk through how a transient database mismatch during flooding produces a loop or black hole between two routers, and what bounds how long it lasts.
Discuss what an area's database size costs in flooding, memory and recalculation, and why that pressure drives how large a single OSPF area should be allowed to grow.
## What the database is OSPF is a **link-state** routing protocol: instead of passing routes along, every router publishes a description of its own surroundings and collects everybody else's. RFC 2328 calls the collection the **link-state database (LSDB)** and states the goal plainly: each participating router has an identical database, and each piece of it is one router's *local state* — its usable interfaces and the neighbours it reaches. The pieces are **link-state advertisements (LSAs)**. A router writes an LSA about itself and floods it; it never writes one about a router it merely heard of. Put every router's piece together and you get a graph: routers and networks as vertices, links as edges, each edge labelled with the cost its originator assigned. ## What identifies an LSA Every LSA starts with a 20-byte header. Three of its fields name *which* LSA it is; three more say *which instance* of it this is. | Header field | Role | |---|---| | `LS type` | what kind of LSA (router, network, summary, external) | | `Link State ID` | which object it describes, interpreted per type | | `Advertising Router` | the Router ID of the originator | | `LS sequence number` | which instance is newer | | `LS checksum` | detects corruption; also a tie-breaker | | `LS age` | seconds since origination; drives refresh and expiry | The first three together are the LSA's identity. A router keeps exactly one instance per identity and replaces it only with a newer instance. ## Why the copies must be identical Each router computes its routing table by building a **shortest-path tree** over the database with *itself* as the root. Ten routers in one area build ten different trees from one shared map, and because the map is shared, the trees are consistent: if R1's best path to a prefix goes through R4, then R4's own tree continues that same path rather than turning back. That consistency is what makes hop-by-hop forwarding safe, and it breaks the moment the maps differ. Suppose R4's best path to a prefix behind R8 runs R4 → R3 → R7 → R8, and R3's runs R3 → R7 → R8. Now the R7–R8 link fails, and the update has reached R3 but not yet R4: 1. R3's new map shows the detour R3 → R4 → R9 → R8, so R3 now forwards that traffic to R4. 2. R4's map still shows the R7–R8 link, so R4 forwards the same traffic back to R3. 3. Packets bounce between R3 and R4 until their TTL expires — a **loop**. 4. The same mismatch can produce a **black hole**: a router with a stale map picks a next hop that, on its own newer map, has no usable route onward, and the traffic is dropped there. Both last only until flooding brings the two databases back into step, which is why OSPF puts so much machinery into making flooding fast and reliable. ## How the copies are kept in step - **Reliable flooding**: a new or changed LSA is sent to every adjacent neighbour in a Link State Update and retransmitted until each one acknowledges it; each neighbour floods it on in turn. - **Database exchange at adjacency bring-up** (a separate subject, the neighbour state machine) gives a newly attached router the whole database at once. - **Instance comparison**: sequence number, then checksum, then age decides which copy is newer, so every router converges on the same instance. - **Periodic refresh**: every originator re-floods each of its LSAs every 30 minutes (`LSRefreshTime`), repairing any copy that was lost or corrupted. ## The database as the input to the shortest-path calculation The database is the input to OSPF's route computation (the algorithm itself is a separate subject). A few rules connect the two: - An LSA whose age has reached **MaxAge** (1 hour) is not used in the routing table calculation; it is on its way out. - Installing an LSA schedules recalculation only when its *contents* changed — not when only its sequence number and checksum changed, as in a routine refresh. - A router attached to several areas keeps **one database per area**; how LSAs are scoped to areas is a separate subject. ## Common misconceptions - The database is not a routing table: it holds topology, and routes are derived from it. - Identical databases do not mean identical routing tables; each router is the root of its own tree. - OSPF does not resend the whole database periodically; each LSA is refreshed individually, every 30 minutes.
- Do ten OSPF routers with identical link-state databases compute identical routing tables?No. Each router builds a shortest-path tree with itself as the root, so next hops and costs differ from router to router. What the shared database guarantees is consistency: every router's choice agrees with the choices of the routers further along the path, so hop-by-hop forwarding forms loop-free paths.
- What does an OSPF router do with an LSA in its database whose age has reached MaxAge?It stops using that LSA in the routing table calculation and refloods it so that every other router drops it too. It keeps the LSA only until no neighbour's retransmission list holds it and no neighbour is in the middle of a database exchange, then deletes it.
A link-state database is like a hiking club where every member surveys only the trails leaving their own hut and posts the survey to everyone. Each member assembles the same full map from those surveys and plans routes from their own hut; if one member is working from an outdated map, two people can send a walker back and forth between them.
saying these in an interview costs you the question
- Each OSPF router's database holds its own best route to every prefix.
- An OSPF router advertises the whole topology it sees, not just its own links.
- Identical OSPF databases mean every router installs the same routing table.
- OSPF routers resend their full database to every neighbour every 30 seconds.
- Two OSPF routers with different databases only get suboptimal paths, never loops.