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
