Flush Expired LSA from the DB

[Net Admins]

Hi all, in 1 topology I have an OSPF LSA from a decommissioned router that is not reachable anymore.

#show ip ospf 20 database network 172.31.171.5

            OSPF Router with ID (172.31.170.1) (Process ID 20)

        Net Link States (Area 64.0.0.20)

  Delete flag is set for this LSA <<<<<<<<<<<
  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: MAXAGE(3680034) <<<<<<<<<<<
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 172.31.171.5 (address of Designated Router)
  Advertising Router: 10.64.252.12
  LS Seq Number: 80000458
  Checksum: 0x7160
  Length: 32
  Network Mask: /30
    Attached Router: 10.64.252.12
    Attached Router: 10.157.70.254

  LS age: 1117
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 172.31.171.5 (address of Designated Router)
  Advertising Router: 172.31.170.1
  LS Seq Number: 80000724
  Checksum: 0xBAFF
  Length: 32
  Network Mask: /30
    Attached Router: 172.31.170.1
    Attached Router: 10.157.70.254

How can I delete this LSA from the database as apparently the router didn't do even though the Adv Router is no longer in the network?

[Rolf Fischer · Accepted solution]

Hi,

I believe this is a bug.

Is this the only LSA with an age greater than 3840?

As you probably know, only the originating router is allowed to flush a valid LSA; however, in scenarios like yours a router should delete a LSA when MaxAge (1 hour) [+ not more than 4 minutes LSA Group Pacing] is exceeded.

According to your output the LSA age is more than 42 days (!). It shouldn't cause any harm since the router ignores it when doing its calculations but I would want to get rid of it as well.

I tried around with gns3 and was able to delete "orphaned" Type-2 LSAs (without clearing the whole process) by moving the corresponing IP interface temporarily in another area (*) but I wouldn't recommend to do something like this in a production environment.

So if nobody else here can provide with something better, the best advise I can give is to open a TAC case.

Would be great to hear how the problem was solved.

HTH

Rolf

(*) Even shutting down the interface or changing its IP address did not work ...

[Net Admins]

ye, it's the only one above 3840.

The issue is the router seems to be ignoring the second LSA I posted in its calculations. There's no harm as I have another redundant path to the same router.

Thanks for your suggestions.
 

[Rolf Fischer]

Well, if it's the only LSA and when this behaviour is not reproducible, you could also consider it as "hiccup" and simply clear the process during the next maintenance window and continue monitoring subsequently.
Just to satisfy my curiosity, what platform and IOS is it?

Thanks,

Rolf

[Net Admins]

>sh ver
Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVENTERPRISEK9-M), Version 15.3(3)S4, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Fri 19-Sep-14 01:29 by prod_rel_team

ROM: System Bootstrap, Version 12.2(33r)SRE2, RELEASE SOFTWARE (fc1)
BOOTLDR: Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVENTERPRISEK9-M), Version 15.3(3)S4, RELEASE SOFTWARE (fc1)

There's another LSA in the same situation but different process. I think this was caused by a migration where the same current configuration was in a different router and at some point they both could see eachother but were not directly attached.

I will certainly plan a step of fixes to sort this out and then I will share the outcome..

[Rolf Fischer]

I will certainly plan a step of fixes to sort this out and then 
I will share the outcome.

That would be great, thanks!

[Net Admins]

So we fixed it yesterday just but bouncing the directly connected interface that refers to the 2nd LSA which has the same mask as the "bad" one.

#sh ip ospf 20 data | i 172.31.171.5
172.31.171.5    10.64.252.12    3747912      0x80000458 0x007160 <<<
172.31.171.5    172.31.170.1    460         0x80000746 0x007622

Changing the interface area was not necessary.

#show ip ospf 20 database network 172.31.171.5

            OSPF Router with ID (172.31.170.1) (Process ID 20)

        Net Link States (Area 64.0.0.20)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 539
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 172.31.171.5 (address of Designated Router)
  Advertising Router: 172.31.170.1
  LS Seq Number: 80000008
  Checksum: 0x8D5
  Length: 32
  Network Mask: /30
    Attached Router: 172.31.170.1
    Attached Router: 10.157.70.254

[Rolf Fischer]

Thanks for the feedback!

Good to hear that you could fix it that way.