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 bo...@bootc.net
