skip to content

An OSPF router reloads and originates its router-LSA at sequence 0x80000001, while neighbours still hold its pre-reload instance at 0x80000250; how does the network converge on the new LSA?

level: seniorimportance: should knowfreq 14%

answer

  1. the old copy wins the comparison
  2. the neighbour hands it back
  3. self-originated, but newer
  4. one past the received number

basics

~20 s

The neighbours judge 0x80000250 newer and hand it back. The reloaded router recognises a newer copy of its own LSA, advances its sequence number to 0x80000251 and re-originates its current contents, which then supersede the stale copy everywhere.

solid answer

~50 s

After the reload, the router's fresh instance at `0x80000001` loses the comparison everywhere: neighbours still hold `0x80000250`, which is newer. A neighbour that receives the older instance sends its own database copy straight back; during database exchange at adjacency bring-up, the router sees the newer copy listed and requests it anyway. Either way, the router receives an LSA whose `Advertising Router` is its own Router ID and which is newer than the last instance it originated. RFC 2328 §13.4 treats that as evidence of a pre-reload LSA still circulating: the router advances the sequence number to one past the received value, `0x80000251`, and originates its *current* contents, which flood out and replace the stale copy. If the router no longer wants that LSA at all — say a network-LSA for a segment where it is no longer DR — it flushes it by premature ageing instead.

go deeper

for a junior

Recall that after a reload an OSPF router starts its LSA sequence numbers again from the lowest value, so its old copies look newer to everyone else.

for a middle

Explain how a neighbour hands back the newer copy and how the originator re-originates one sequence number past it.

for a senior

Diagnose climbing sequence numbers and flapping LSAs after a reload or a duplicated Router ID, and say when the originator flushes rather than re-originates.

for a principal

Assess the design choice of letting routers forget sequence state across reloads and repairing it in-protocol, against requiring stable storage on every router.

## The situation OSPF routers are not required to remember their LSA sequence numbers across a reload. A router that has lost that state starts every LSA again at `InitialSequenceNumber`, `0x80000001`, the *oldest* possible value. Its neighbours, meanwhile, still hold what it flooded before the reload. | Who | Holds | Sequence | |---|---|---| | R2, the reloaded router | its new router-LSA, current contents | `0x80000001` | | R1, R3 and the other routers in the area | R2's pre-reload router-LSA | `0x80000250` | Both copies have the same identity: LS type 1, `Link State ID` and `Advertising Router` both equal to R2's Router ID. By the sequence-number rule, the stale copy is the newer one. ## Step by step 1. R2 comes up, forms adjacencies and originates its router-LSA at `0x80000001`. 2. **Two paths lead to the same place.** During the database exchange R2 sees a summary of its own LSA at `0x80000250`, newer than its copy, and requests it. Or, if R2 floods its `0x80000001` instance to a neighbour, that neighbour finds its database copy more recent and sends it straight back, without acknowledging the older one. 3. R2 receives its own LSA at `0x80000250` in a Link State Update. The flooding procedure installs it as the newer instance — then step 5(f) of §13 notices it is **self-originated**. 4. Per §13.4, a self-originated LSA newer than the last instance the router actually originated means a pre-reload copy is still in the domain. R2 sets the sequence number to **one past the received value**, `0x80000251`, and originates its current contents. 5. `0x80000251` beats `0x80000250` at every router, floods across the area and replaces the stale copy. The databases converge on R2's real topology. RFC 2328 also forbids originating two instances of one LSA within `MinLSInterval` (5 s), so the corrective origination in step 4 may wait up to 5 s after R2's previous one. ## Why the network does not stay stuck - **Neighbours return newer copies.** A router that receives an older instance than its own sends its copy back, so the originator learns the truth on the first exchange. - **The originator is the only authority.** A self-originated LSA it did not produce is never accepted as final; the router either supersedes it or flushes it. - **No waiting for MaxAge.** Without §13.4, the reloaded router's updates would be ignored until the stale instance aged out — up to an hour — while every router computed on R2's pre-reload links. ## When the router no longer wants the LSA §13.4 lists cases where re-originating makes no sense, and the router flushes the stale LSA by **premature ageing** (age set to `MaxAge`, sequence number kept, reflooded): - a summary-LSA or AS-external-LSA for a destination it no longer has a route to; - a network-LSA for a segment where it is **no longer the designated router**; - a network-LSA whose `Link State ID` is one of its interface addresses but whose `Advertising Router` is a different Router ID — a sign its own Router ID changed. ## The same sequence number with different contents A restart can also land on a sequence number that is already in use. Then the checksums differ, and §13.1 picks the larger checksum. RFC 2328's notes admit this can choose the wrong instance, but the self-originated rule repairs it: if the stale contents won, the originator receives them, sees an LSA newer than what it last originated, and re-originates with a higher sequence number. ## What it looks like in operation - After a reload, a router's LSAs jump straight to a high sequence number instead of starting at `0x80000001`; that is §13.4 working, not a fault. - Sequence numbers for one LSA climbing continuously, with repeated route recalculation, point to two routers fighting over one identity. Two routers configured with the **same Router ID** each see the other's router-LSA as a newer copy of their own and each re-originates it — the same rule, applied by two routers that each believe they own the LSA.

  • What happens if two OSPF routers in one area are configured with the same Router ID?
    Each router-LSA has the same identity, so each router receives the other's LSA as a newer copy of its own. Following RFC 2328 §13.4, each advances the sequence number and re-originates its own contents, which the other then treats the same way. The LSA flaps, sequence numbers climb and routes are recalculated repeatedly until one Router ID is changed.
  • Why does the reloaded OSPF router re-originate instead of flushing the stale LSA and starting over?
    It still has links to describe. Flushing would remove its router-LSA from every database and only then let it originate again, opening a window in which its links vanish. Re-originating one past the stale sequence number replaces the old contents in a single flood. Flushing is reserved for LSAs the router no longer wants to originate.

saying these in an interview costs you the question

  • Neighbours accept the reloaded OSPF router's 0x80000001 LSA because it is the freshest they have seen.
  • A stale pre-reload OSPF LSA blocks the router's updates until it reaches MaxAge.
  • Any OSPF router may flush a stale LSA it finds, whoever originated it.
  • A reloaded OSPF router must wait an hour before reusing its own LSA identity.
  • An OSPF router that receives a newer copy of its own LSA simply accepts it as current.