Hi Lennard, Damn, I also have Fortinet stuff and I was thinking about replacing Quagga by BIRD for the same use (announcing service loopbacks as tagged external routes - Quagga knows nothing about LSA type 5/7 tag) :P Another case to open...
On Ericsson's side, the bug is only in OSPFv3; OSPFv2 is OK (two different processes, and two different codes for the same LS SeqNum comparison...). Olivier Le 14 juil. 2014 à 10:42, Lennard Klein <[email protected]> a écrit : > Hi Olivier, > > I was having problems with a Fortinet device. In my environment, I've simply > removed the line I mentioned in my original e-mail. I don't think this has > had any adverse effects, though I can't be quite sure (I am having some other > issues which seem to be unrelated). > > Lennard Klein > Special Projects, Netherlands > [email protected] > EQUINIX > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Olivier > Benghozi > Sent: zaterdag 12 juli 2014 18:33 > To: [email protected] > Subject: Re: Behavior during OSPF premature aging > > 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 > > > > This email is from Equinix (EMEA) B.V. or one of its associated companies in > the territory from where this email has been sent. This email, and any files > transmitted with it, contains information which is confidential, is solely > for the use of the intended recipient and may be legally privileged. If you > have received this email in error, please notify the sender and delete this > email immediately. Equinix (EMEA) B.V.. Registered Office: Luttenbergweg 4, > 1101 EC Amsterdam-Zuidoost, The Netherlands. Registered in The Netherlands > No. 57577889.
