In OSPF, how does a router flood a new LSA reliably to its neighbours, and what happens when an acknowledgement is lost?
answer
- two packet types, update and ack
- a list per adjacency
- resend every RxmtInterval
- a duplicate can be an acknowledgement
basics
~20 sAn OSPF router sends a new LSA in a Link State Update and places it on each adjacency's retransmission list. It resends the LSA to each neighbour every RxmtInterval until that neighbour acknowledges it, explicitly or by echoing the same instance.
solid answer
~50 sOSPF floods with two packet types: the **Link State Update** carries LSAs and the **Link State Acknowledgment** confirms them, one acknowledgement per LSA. When a router accepts an LSA as newer than its database copy, it installs it, floods it out every eligible interface (normally not back to the neighbour it came from) and puts it on the **retransmission list** of each adjacency it sent it to. Each LSA stays on a list until that neighbour acknowledges it — with an explicit acknowledgement, or *implicitly* by sending the same instance back. If an acknowledgement is lost, the LSA is simply resent, unicast to that neighbour, every `RxmtInterval` (RFC 2328's sample value is 5 s); the neighbour recognises a duplicate and acknowledges it directly. The list is cleared only when the LSA is acknowledged or the adjacency is torn down.
go deeper
Recall the two packets, Link State Update and Link State Acknowledgment, and that OSPF resends an LSA until each neighbour acknowledges it.
Explain the per-adjacency retransmission list, the three ways an LSA is acknowledged, and what a router does with a newer, identical or older instance.
Show how retransmission timing interacts with a congested control plane during an LSA storm, and why prioritising Hellos and acknowledgements keeps adjacencies alive.
Weigh hop-by-hop reliable flooding against its cost in a large, dense area, where every change is sent over every adjacency, and what that argues about area size and topology density.
## Two packets do the work OSPF runs directly over IP as protocol 89, so it gets no reliability from a transport layer and builds its own. Flooding uses two of OSPF's five packet types: | Packet type | Name | Carries | |---|---|---| | 4 | Link State Update | one or more complete LSAs | | 5 | Link State Acknowledgment | LSA headers, one per LSA acknowledged | RFC 2328 is explicit that **each LSA is acknowledged separately**, although many acknowledgements can share one packet. Reliability is hop by hop: every router makes sure each of its adjacent neighbours has the LSA, and each neighbour does the same for its own neighbours. ## What a router does with each LSA it receives RFC 2328 §13 processes every LSA in an incoming Link State Update in order. In outline: 1. Verify the **LS checksum**; a corrupt LSA is discarded and not acknowledged, so the sender will retransmit it. 2. Discard an unknown LS type, or an AS-external-LSA arriving in a stub area. 3. Look up the database copy with the same identity and compare instances (sequence number, then checksum, then age). 4. **Newer**: unless the database copy arrived by flooding less than `MinLSArrival` (1 s) ago, flood the LSA out the eligible interfaces, remove the old copy from every retransmission list, install it, acknowledge it where RFC 2328's acknowledgement table calls for one, and take special action if it is the router's own LSA. 5. **Same instance**: if it is on the retransmission list for the neighbour that sent it, treat it as an **implied acknowledgement** and remove it from that list; otherwise acknowledge the duplicate directly. 6. **Older**: send the newer database copy straight back to that neighbour, without acknowledging the stale one. ## Sending: the retransmission list Flooding an LSA out an interface means, for each neighbour on that interface that is taking part in flooding: - skip the neighbour that sent the LSA in the first place; - otherwise add the LSA to that adjacency's **link state retransmission list**, which is what makes the flood reliable; - then send the Link State Update — multicast on a broadcast network, unicast on a non-broadcast one. On a broadcast segment the designated router relays floods for the segment (that election is a separate subject), so a router that heard the LSA from the DR or backup DR does not repeat it there. Even when a router decides not to transmit on an interface, the RFC still requires the neighbours to receive the LSA eventually. ## Three kinds of acknowledgement | Kind | When | How | |---|---|---| | Delayed | a newer LSA was received and not flooded back out the same interface (a backup DR acknowledges only one heard from the DR) | grouped and sent on a short timer, multicast on broadcast networks | | Direct | a duplicate arrived that was not an implied acknowledgement, or a MaxAge LSA the router does not hold | sent immediately, unicast to that neighbour | | Implied | the neighbour sends back the very instance the router is waiting on | no packet; the LSA leaves the retransmission list | Delayed acknowledgements are multicast on a shared segment because several routers are waiting for the same acknowledgement — one packet satisfies all of them. Their timer must be shorter than `RxmtInterval`, or needless retransmissions follow. ## When an acknowledgement is lost Take R5 flooding a new router-LSA to R6 over a point-to-point link in a ten-router area: 1. R5 sends the Link State Update and puts the LSA on R6's retransmission list. 2. R6 installs the LSA and sends an acknowledgement, which is lost. 3. After `RxmtInterval`, R5 resends the LSA, unicast to R6. 4. R6 sees an instance identical to its database copy that is not on its own list for R5, so it sends a **direct acknowledgement** at once. 5. R5 removes the LSA from R6's list. Nothing is re-originated: the same instance, with the same sequence number, is resent until acknowledged. If R6 goes down, retransmissions continue until the Hello protocol declares the adjacency dead, and then the list is cleared. ## Tuning and storms - `RxmtInterval` is configured per interface and should exceed the round-trip time on the link; too low wastes bandwidth, too high slows recovery from loss. - RFC 4222 (BCP 112) recommends processing Hello and acknowledgement packets ahead of other OSPF packets and backing `RxmtInterval` off exponentially during an LSA storm, because retransmissions are what keep a congested control plane congested. - Retransmissions carry several LSAs per Link State Update, and are always sent directly to the neighbour.
- Why does an OSPF router send its own copy back when a neighbour floods it an older instance of an LSA?The neighbour is evidently holding stale data. Under RFC 2328 §13, step 8, the router sends its newer database copy directly to that neighbour in a Link State Update, does not acknowledge the stale instance and does not put the copy on a retransmission list. It skips the send if it already sent that copy within the last `MinLSArrival` (1 s).
- On a broadcast segment, why are OSPF's delayed acknowledgements multicast instead of sent to the router that flooded the LSA?More than one adjacent router can be waiting for the same acknowledgement: when the DR floods an LSA, both the DR and the backup DR expect every other router on the segment to acknowledge it. One multicast clears both retransmission lists. Routers in state DR or Backup send to AllSPFRouters (224.0.0.5); the others send to AllDRouters (224.0.0.6).
- What does RFC 4222 recommend for OSPF retransmissions during an LSA storm?RFC 4222 (BCP 112) recommends an exponential back-off: `R(1) = Rmin`, `R(i+1) = min(K × R(i), Rmax)`, with example values K = 2, Rmin = 5 s, Rmax = 40 s. It also recommends processing Hello and Link State Acknowledgment packets ahead of other OSPF packets, so a busy router keeps its adjacencies and stops provoking retransmissions.
saying these in an interview costs you the question
- OSPF relies on TCP to deliver its LSAs reliably.
- An OSPF router always floods a new LSA back to the neighbour that sent it.
- One acknowledgement from any OSPF neighbour on a segment clears the LSA for all neighbours.
- A lost OSPF acknowledgement makes the originator reissue the LSA with a new sequence number.
- A duplicate LSA is always an error that an OSPF router silently drops.