So, I was intrigued by Ivan’s post on Extra LSAs within the LSDB here : http://blog.ioshints.info/2012/12/change-in-ospf-designated-router.html
And I decided to do a little digging of my own.
I have confirmed Ivan’s work through his blog. Essentially, when issuing the “ip ospf priority 0” command to allow for a graceful shutdown of a DR on a segment, it is leaving an extra LSA in the LSDB of other routers in the segment.
It seems, as is described in the comments on Ivan’s blog, the extra LSA is kept within the LSDB for 60 seconds. Once that 60 seconds passes, the LSA is MaxAged out. As seen below.
*Jan 2 15:07:23.023: OSPF: Reset old DR on FastEthernet0/0
*Jan 2 15:07:23.055: OSPF: Rcv LS UPD from 18.104.22.168 on FastEthernet0/0 length 76 LSA count 1
*Jan 2 15:07:23.851: OSPF: service_maxage: Trying to delete MAXAGE LSA
It would seem that, on what was the old BDR, now the DR – it is remembering the old DR on the segment that the interface is connected to. And not until this old DR is reset on the interface does it MaxAge the LSA. You can see below the debug output where it remembers the old DR :
*Jan 2 15:04:17.019: OSPF: Remember old DR 22.214.171.124 (id)
As I’ve stated in Ivan’s blog, in a comment, I’ve done some light digging as to why this is happening, but I can’t think of a timer, or combination of timers, that is causing this to happen so methodically.
Anyone have any insight? Otherwise, I’ll keep digging until I find something.
After more digging it would seem there is a 180 second delay between the forced step down of the DR and the MaxAging of the corresponding LSA. Not 60 seconds as I’d previously witnessed.