Behavior during OSPF premature aging

Lennard Klein Lennard.Klein at
Mon Jul 14 10:42:12 CEST 2014

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 at 

-----Original Message-----
From: owner-bird-users at [mailto:owner-bird-users at] On Behalf Of Olivier Benghozi
Sent: zaterdag 12 juli 2014 18:33
To: bird-users at
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.

Olivier Benghozi

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.

More information about the Bird-users mailing list