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 <Lennard.Klein@eu.equinix.com> 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 lennard.klein@eu.equinix.com EQUINIX
-----Original Message----- From: owner-bird-users@atrey.karlin.mff.cuni.cz [mailto:owner-bird-users@atrey.karlin.mff.cuni.cz] On Behalf Of Olivier Benghozi Sent: zaterdag 12 juli 2014 18:33 To: bird-users@trubka.network.cz 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.