bird6 1.4.5 OSPFv3 LSA checksum failures

[Chris Boot]

Hi folks,

I’m running bird6 1.4.5-1 (from Debian jessie) on my home network. Quite regularly I see floods of "Received bad lsa checksum” message in my syslog on the two routers that run BIRD, which causes connectivity interruptions.

The network is made up of a variety of devices running different OSPF stacks. The network is fully dual-stacked with the same devices running OSPFv2 and OSPFv3 with a mostly identical configuration. The network contains two Quagga (0.99.23.1-1 from Debian Jessie) routers, one Dell PowerConnect 8024F (fw 5.1.7.5), and several MikroTik RouterOS (6.28) routers. The problem *only* occurs on OSPFv3; OSPFv2 is unaffected.

The messages always follow a very specific pattern. Here are the last 10 received on one of my routers:

Apr 25 16:17:36 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff
Apr 25 16:17:37 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff
Apr 25 16:17:41 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff
Apr 25 16:17:42 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff
Apr 25 16:17:46 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff
Apr 25 16:17:47 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff
Apr 25 16:17:51 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff
Apr 25 16:17:52 clemens bird6: Received bad lsa checksum from fe80::5e26:aff:feb8:34ad: de00 deff
Apr 25 16:17:56 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff
Apr 25 16:18:01 clemens bird6: Received bad lsa checksum from fe80::290:7fff:fe3c:502a: de00 deff

If I grep my logs looking for unique entries, I see the following:

Received bad lsa checksum from $PEER: 1800 18ff
Received bad lsa checksum from $PEER: 30 ff30
Received bad lsa checksum from $PEER: 3500 35ff
Received bad lsa checksum from $PEER: 40 ff40
Received bad lsa checksum from $PEER: 5000 50ff
Received bad lsa checksum from $PEER: 6600 66ff
Received bad lsa checksum from $PEER: 6e00 6eff
Received bad lsa checksum from $PEER: 86 ff86
Received bad lsa checksum from $PEER: 9800 98ff
Received bad lsa checksum from $PEER: 9c00 9cff
Received bad lsa checksum from $PEER: 9e ff9e
Received bad lsa checksum from $PEER: 9f ff9f
Received bad lsa checksum from $PEER: bc ffbc
Received bad lsa checksum from $PEER: cc ffcc
Received bad lsa checksum from $PEER: cd ffcd
Received bad lsa checksum from $PEER: cf00 cfff
Received bad lsa checksum from $PEER: dc ffdc
Received bad lsa checksum from $PEER: dd ffdd
Received bad lsa checksum from $PEER: de00 deff
Received bad lsa checksum from $PEER: e600 e6ff
Received bad lsa checksum from $PEER: ee00 eeff
Received bad lsa checksum from $PEER: fe fffe

Thus, the problem occurs when (AIUI) the checksum sent by the peer has a zero octet, which doesn’t agree with how lsasum_check() calculates the checksum where the octet is always 0xff instead. This happens either when the first octet is zero or the second octet is zero.

Looking through my logs, it seems I have yet to run into a situation where the values are reversed, e.g. the checksum in the LSA always includes a zero octet and BIRD always calculates 0xff, never the other way around.

I have yet to look in much detail whether the problem is likely to be in BIRD’s lsasum_check() implementation or in the checksum generated by one of my other devices, and I don’t yet know which device(s) generate the LSAs that BIRD complains about.

Has anyone here run into this before?

Thanks,
Chris

-- 
Chris Boot
bootc at bootc.net