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