ospf6d: review LSA sequence number comparison

It seems that there is a bug in ospf6d in ospf6_lsa_compare(): If LSA A
has sequence number smaller than 0x80000000 and LSA B has sequence
number larger than 0x80000000, ospf6_lsa_compare() returns that B is
more recent than A, although RFC says that sequence numbers should be
compared as signed numbers (0x8000001 smallest and 0x7FFFFFFF largest).

In ospfd, the function ospf_lsa_more_recent() has it right.

The problem appears when Quagga is used together with OSPFv3 in
development version of BIRD daemon ( http://bird.network.cz/ ),
which creates LSAs with maximum sequence number (0x7FFFFFFF)
as a part of flushing/premature aging LSA from OSPF area.

Because both daemons has different idea of which LSA instance
is more recent, it would lead to LSA storm.

0 files changed, 0 insertions, 0 deletions