Behavior during OSPF premature aging

[Olivier Benghozi]

Hi guys,

Ondrej Zajicek wrote:
> On Tue, Jun 24, 2014 at 08:46:20AM +0100, Lennard Klein wrote:
>> 
>> When premature aging an LSA, bird seems to increase the LSA sequence number to its maximum (proto/ospf/lsupd.c line 616, in 1.4.3).
>> While I think the main fault lies with the other vendor, my question
>> at this time is: what is the reasoning behind updating the sequence
>> number to its maximum, even though the RFC says to leave it as-is?
> 
> This is done mainly to compensate other problems/quirks/hacks in BIRD
> OSPF implementation. One reason is that if you flush LSA using MaxSeqNo,
> you could forget old LSA sequence number, and when you originate a new
> one later, you could safely start from InitSeqNo.
> 
> Currently i am finishing OSPF revision that removes most of these BIRD
> quirks and problems related to LSA flood and makes BIRD much better in
> RFC compliance.


I've just hit the wall with that on Redback/Ericsson gears; for their code, signed 0x80000005 is more recent than signed 0x7fffffff according to the debugs (while I've no problem at all with a Juniper router).

For my use (announcing anycast service loopbacks as tagged N2 routes) I guess I could push the metric to Infinite to see the route disappear (but not the LSA), while it's not very satisfying.
However I must say that I'm more than interested by such a code revision (since manually replacing LSA_MAXSEQNO to 0xffffffff in ospf/lsupd.c line 616 would be a horrible hack) :)

Lennard, which vendor do you have problem with?

On my side I've opened a bug at Eric&Son's TAC.

-- 
regards,
Olivier Benghozi
Wifirst