OSPF flood wars

Updated: Mar 1, 2019



A flood war occurs when the same LSA is re-originated and flushed out again and again. This typically occurs due to duplicate router IDs on routers not directly connected. Let’s take the following topology into consideration.


The network is stable right now. R3, which is the ABR, sends a summary (type-3) LSA into areas 0 and 1. The LSDB for all routers looks like this:






Let’s take a closer look at the summary LSA going into area 0 - this should contain information about networks 10.1.3.0/24 and 44.44.44.44/32, with the advertising router ID set to 3.3.3.3.



What would happen if I change the router ID of R3 to 1.1.1.1 now? The same summary LSA goes into area 0 with the same networks being advertised with the advertising router ID being set to 1.1.1.1 instead. When R1 receives this, it looks at the router ID and sees that it is its own router ID. If the router ID is the same, from R1s perspective, this implies that it has received a self-originated LSA (section 13.4 of RFC 2328). Does R1 have these networks in its OSPF LSDB? No. This means that the LSA is a stale LSA. When this happens, RFC dictates that we need to set max age for this LSA, increase the sequence number by one and flood it back out, which is what R1 does.


Now R3 gets a summary LSA with router ID set to 1.1.1.1, which again, is its own router ID. R3 assumes that it has received a self-originated LSA, however, the sequence number is higher than what it currently holds in the LSDB. This can potentially happen if a router reloads and gets its own LSA back (which would naturally have a higher sequence number than what the router has locally, since we start with sequence number 0x80000001). Also, since the LSA is present in the LSDB, it is not a stale LSA. Since the LSA received is a newer LSA (because of a higher sequence number), R3 increments the sequence number and re-originates the LSA (floods it back out again) as per RFC. This cycle will continue endlessly.


Let’s go ahead and make this change and verify that has been described above is indeed what happens.



After some time, we see the following log in R1:

And the following in R3:



We would also see the LSA age constantly refreshing (outputs below are taken quickly, at a gap of around 1 second between each output):



Basically, a flood war is declared if:


- we are the originating router and there is another OSPF router flushing our LSA again and again.

- we are the flushing router and we don’t agree that some LSA should be present in our LSDB. This can occur for LSA type-2 with link state ID equal to one of our interfaces or type-3/type-5 LSA with advertising router ID equal to our router ID.


Note that we declare a flood war only if this flushing/re-origination happens very often within a specific interval of time.


Another thing to note is the behavior observed on the middle router(s) – R2, in this case. Since there should now be two routers generating the same type-1 LSA, which one would R2 install? It would constantly oscillate between the two. This is because both R1 and R3, on receipt of a type-1 LSA with router ID of 1.1.1.1, would simply increment sequence number and flood it back out (in accordance with RFC 2328, section 13.4, Receiving Self-originated LSAs). R2, the router in the middle, would constantly get LSAs that have a higher sequence number than what it holds in the LSDB, and would thus install the newer LSA. This cycle would continue till the flood war persists.


Snapshots of R2s changing type-1 LSA is below:


For any queries, concerns or conversations, please email contact@theasciiconstruct.com