cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
713
Views
5
Helpful
4
Replies
Highlighted
Beginner

Flood war message

Hello team,

i came across a ospf log called flood war.I did some research and came to known that if two routers has same router ID one router originates it and other discards it.
Suppose we have two router r1 and r2 and both have same router ID , if r1 originates an LSA and r2 receives it . R2 must have that LSA in its database then why does it discards because when the LSA will be received and it r2 will see that it is already in database. OR does this log occur when the route is discarded from the database and the routers receives the LSA with duplicate router ID.
Any help is appreciated

Thank you!

4 REPLIES 4
Highlighted
Beginner

Hi,

When 2 routers, R1 & R2 have the same router id in an area:

Then neighborship will not be established between the two, because as soon as R1 creates a Router LSA(Type 1) with his router id, R2 will see it & will discard it. And you will receive a error message stating, "Duplicate Router-ID".

Please rate if helpful.

Thanks.

Highlighted
Beginner

You can refer Troubleshooting Duplicate Router IDs with OSPF on this link http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/23862-duplicate-router-id-ospf.html

Highlighted
Cisco Employee

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.

Take the following topology as an example:

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:

 

R1#show ip ospf database

 

            OSPF Router with ID (1.1.1.1) (Process ID 1)

 

           Router Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         1046        0x80000003 0x0050EB 3

2.2.2.2         2.2.2.2         970         0x80000004 0x00E1F9 4

3.3.3.3         3.3.3.3         861         0x80000006 0x0090CF 2

44.44.44.44     44.44.44.44     890         0x80000002 0x00FC57 3

 

           Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.2.2        2.2.2.2         970         0x80000001 0x008589

 

           Summary Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.3.0        3.3.3.3         856         0x80000001 0x0002E0

44.44.44.44     3.3.3.3         162         0x80000001 0x00CB73

 

R2#show ip ospf database

 

            OSPF Router with ID (2.2.2.2) (Process ID 1)

 

           Router Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         1067        0x80000003 0x0050EB 3

2.2.2.2         2.2.2.2         989         0x80000004 0x00E1F9 4

3.3.3.3         3.3.3.3         878         0x80000006 0x0090CF 2

44.44.44.44     44.44.44.44     906         0x80000002 0x00FC57 3

 

           Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.2.2        2.2.2.2         988         0x80000001 0x008589

 

           Summary Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.3.0        3.3.3.3         873         0x80000001 0x0002E0

44.44.44.44     3.3.3.3         169         0x80000001 0x00CB73

 

R3#show ip ospf database

 

            OSPF Router with ID (3.3.3.3) (Process ID 1)

 

           Router Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.1.1.1         1.1.1.1         1073        0x80000003 0x0050EB 3

2.2.2.2         2.2.2.2         995         0x80000004 0x00E1F9 4

3.3.3.3         3.3.3.3         881         0x80000006 0x0090CF 2

44.44.44.44     44.44.44.44     912         0x80000002 0x00FC57 3

 

           Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.2.2        2.2.2.2         995         0x80000001 0x008589

 

           Summary Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.3.0        3.3.3.3         875         0x80000001 0x0002E0

44.44.44.44     3.3.3.3         172         0x80000001 0x00CB73

 

           Router Link States (Area 1)

         

Link ID         ADV Router      Age         Seq#       Checksum Link count

3.3.3.3         3.3.3.3         878         0x80000002 0x001E9C 2

44.44.44.44     44.44.44.44     174         0x80000003 0x00FA58 3

 

           Summary Net Link States (Area 1)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.1.0        3.3.3.3         885         0x80000001 0x0022C1

10.1.2.0        3.3.3.3         885         0x80000001 0x00948E

11.11.11.11     3.3.3.3         885         0x80000001 0x00C9F8

22.22.22.22     3.3.3.3         885         0x80000001 0x004B8B

33.33.33.33     3.3.3.3         885         0x80000001 0x004566

 

R4#show ip ospf database

 

            OSPF Router with ID (44.44.44.44) (Process ID 1)

 

           Router Link States (Area 1)

 

Link ID         ADV Router      Age         Seq#       Checksum Link count

3.3.3.3         3.3.3.3         880         0x80000002 0x001E9C 2

44.44.44.44     44.44.44.44     176         0x80000003 0x00FA58 3

 

           Summary Net Link States (Area 1)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.1.0        3.3.3.3         886         0x80000001 0x0022C1

10.1.2.0        3.3.3.3         886         0x80000001 0x00948E

11.11.11.11     3.3.3.3         886         0x80000001 0x00C9F8

22.22.22.22     3.3.3.3         886         0x80000001 0x004B8B

33.33.33.33     3.3.3.3         886         0x80000001 0x004566

 

 

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.

 

R1#show ip ospf database summary adv-router 3.3.3.3

 

            OSPF Router with ID (1.1.1.1) (Process ID 1)

 

           Summary Net Link States (Area 0)

 

  Routing Bit Set on this LSA in topology Base with MTID 0

  LS age: 953

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 10.1.3.0 (summary Network Number)

  Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0x2E0

  Length: 28

  Network Mask: /24

      MTID: 0    Metric: 64

 

  Routing Bit Set on this LSA in topology Base with MTID 0

  LS age: 259

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 44.44.44.44 (summary Network Number)

  Advertising Router: 3.3.3.3

  LS Seq Number: 80000001

  Checksum: 0xCB73

  Length: 28

  Network Mask: /32

      MTID: 0    Metric: 65

 

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.

 

R3(config)#router ospf 1

R3(config-router)#router-id 1.1.1.1

Reload or use "clear ip ospf process" command, for this to take effect

R3(config-router)#end

R3#clear ip ospf process

Reset ALL OSPF processes? [no]: y

 

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

 

%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 10.1.3.0 type-3 adv-rtr 1.1.1.1 in area 0

 

and the following in R3:

 

%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 10.1.3.0 type-3 adv-rtr 1.1.1.1 in area 0

 

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

 

R3#show ip ospf database

 

*snip*

           Summary Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.3.0        1.1.1.1         8           0x80000029 0x00EDD4

44.44.44.44     1.1.1.1         8           0x80000029 0x00B767

 

*snip*

 

R3#show ip ospf database

 

*snip*

 

           Summary Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.3.0        1.1.1.1         9           0x80000029 0x00EDD4

44.44.44.44     1.1.1.1         9           0x80000029 0x00B767

 

*snip*

 

R3#show ip ospf database

 

*snip*

           Summary Net Link States (Area 0)

 

Link ID         ADV Router      Age         Seq#       Checksum

10.1.3.0        1.1.1.1         0           0x8000002B 0x00E9D6

44.44.44.44     1.1.1.1         0           0x8000002B 0x00B369

 

*snip*

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:

 

R2#show ip ospf data router 1.1.1.1

 

            OSPF Router with ID (2.2.2.2) (Process ID 1)

 

           Router Link States (Area 0)

 

  LS age: 9

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 1.1.1.1

  Advertising Router: 1.1.1.1

  LS Seq Number: 80000053

  Checksum: 0xAF3C

  Length: 60

  Number of Links: 3

 

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 11.11.11.11

     (Link Data) Network Mask: 255.255.255.255

      Number of MTID metrics: 0

       TOS 0 Metrics: 1

 

    Link connected to: another Router (point-to-point)

     (Link ID) Neighboring Router ID: 2.2.2.2

     (Link Data) Router Interface address: 10.1.1.1

      Number of MTID metrics: 0

       TOS 0 Metrics: 64

 

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 10.1.1.0

     (Link Data) Network Mask: 255.255.255.0

      Number of MTID metrics: 0

       TOS 0 Metrics: 64

 

 

R2#show ip ospf data router 1.1.1.1

 

            OSPF Router with ID (2.2.2.2) (Process ID 1)

 

           Router Link States (Area 0)

 

  LS age: 5

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 1.1.1.1

  Advertising Router: 1.1.1.1

  LS Seq Number: 80000054

  Checksum: 0x8C95

  Length: 48

  Area Border Router

  Number of Links: 2

 

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 33.33.33.33

     (Link Data) Network Mask: 255.255.255.255

      Number of MTID metrics: 0

       TOS 0 Metrics: 1

 

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.1.2.2

     (Link Data) Router Interface address: 10.1.2.3

      Number of MTID metrics: 0

       TOS 0 Metrics: 1

Highlighted

Hi Aninda,

Appreciate your detailed info on the issue. In your explanation you have following statement:

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

if r1 is receiving a summary LSA with its own router ID and that LSA is not in LSDB how come it is a stale LSA. can you explain when you say stale LSA what exactly do you mean.

If r1 received

a LSA with same router-id it will set the age of lsa to max age and flood it . Please feel free to correct the statement if it is wrong.

Thank you!

Asit 

Content for Community-Ad