BIRD OSPF floods illegal LSA seq no 0x80000000 after premature aging
Cheers, we have reproducible case in the lab where BIRD's OSPF sends LSUPDs with illegal sequence number 0x80000000. Here's what happens: - The OSPF is up and running fine, including BIRD - A change to bird.conf is made that affects OSPF routes - BIRD receives a SIGHUP - Apparently as part of reconfiguration, BIRD floods LSAs with MaxAge and MaxSequenceNumber 0x7fffffff (premature aging -- so far ok) - Immediately after that, but before any other OSPF packet is received (!), BIRD floods the same LSAs again, but with an Age of 2 or 3 (NOT MaxAge) and sequence number 0x80000000 We have a capture file (pcap) of this. If this is any help, I'm happy to e-mail it. The bug here is that sequence number 0x80000000 is reserved and not to be used (RFC 2328, section 12.1.6). As far as I can see, originate_ext_lsa() is called and simply looks up a matching entry in its database (*en). It finds the previously- originated entry with 0x7fffffff, blindly increments it to 0x80000000 (proto/ospf/topology.c:990) and then floods it.
On Fri, May 21, 2010 at 06:41:50PM +0200, Dennis Koegel wrote:
Cheers,
we have reproducible case in the lab where BIRD's OSPF sends LSUPDs with illegal sequence number 0x80000000.
Hello Thank you for the bugreport. I also noticed this problem some time ago. The illegal sequence number is just a symptom, the core of the problem is that a new LSA is originated before the old one is completely flushed and removed from the LSA db. This happens AFAIK only for ext-LSAs when other protocols remove and then immediately insert a route to the routing table (which causes the LSA to be flushed and then reoriginated). I already fixed this (in dev version) for the static protocol and i will add a check for LSA sequence number overflow (to generate seqnum 0x80000001 in that case), but the prober fix of LSA flushing would take some time. Which protocol created the route that was exported to the OSPF and caused the problem in your case? And what change to bird.conf was made (it was change to the OSPF or a change to the first protocol)? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Sat, May 22, 2010 at 11:36:43AM +0200, Ondrej Zajicek wrote:
we have reproducible case in the lab where BIRD's OSPF sends LSUPDs with illegal sequence number 0x80000000.
Which protocol created the route that was exported to the OSPF and caused the problem in your case? And what change to bird.conf was made (it was change to the OSPF or a change to the first protocol)?
Changing the "interface" statement within "protocol direct" triggered the problem here. The routes also came from "direct", interface addresses actually. We'll try the current version from git when the checks are in, thank you! Regards, - D.
On Sun, May 23, 2010 at 03:49:03PM +0200, Dennis Koegel wrote:
On Sat, May 22, 2010 at 11:36:43AM +0200, Ondrej Zajicek wrote:
we have reproducible case in the lab where BIRD's OSPF sends LSUPDs with illegal sequence number 0x80000000.
Which protocol created the route that was exported to the OSPF and caused the problem in your case? And what change to bird.conf was made (it was change to the OSPF or a change to the first protocol)?
Changing the "interface" statement within "protocol direct" triggered the problem here. The routes also came from "direct", interface addresses actually.
We'll try the current version from git when the checks are in, thank you!
I just commited that, you can try it. OTOH, in most cases it is unreasonable to export interface addresses from protocol 'direct' to OSPF. It is usually much better to just add these interfaces as OSPF interfaces (possibly with 'stub yes' option) and the OSPF protocol propagates their addresses itself (using stub records in router-LSA). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Dennis Koegel -
Ondrej Zajicek