On Sun, Jul 05, 2020 at 11:56:45AM +0200, Elmar K. Bins wrote:
G'day all,
we were able to solve the problem today (thanks to my ingenious colleague).
In IOS XR, Cisco supports multiprotocol SNMPv3 and thus sets the bits correctly for this. BIRD flukes on it. We got a lot of "I-bit mismatch(7)" messages.
Disabling rfc5838 support does the trick for us, since we're running ospf2 for IPv4 and ospf3 for IPv6 (because...old IOS boxes in the mix in other places...)
rfc5838 no;
My colleague supports the idea that this might be a bug in BIRD; if you need debugging output to help, please ping me.
Hi This should not matter. If rfc5838 option is enabled (by default) and instance 0 is used (by default), then only thing this does is to signal RFC 5838 support by having AF-bit flag set in Hello and Dbdes packets. Perhaps it is some bug in old IOS that rejects (instead of ignoring) unknown option flags? If i remember correctly, it is Cisco side who resets session back to initial state (so there is I-bit mismatch).
Do not see any issues on BIRD side. It seems to me that Cisco just resets the exchange (by sending DBD flag I) when it should be done (or in Loading state):
I could not find any trace on the XR side, but I'll continue digging. I did actually expect it to be an MTU issue, but could find no proof of that. I also don't understand why OSPFv2 would work, but OSPFv3 would not.
I suppose that this exchage repeats indefinetly and 'show ospf neighbors' on BIRD also shows the other side in ExStart/Exchange?
Actually, the routers show as ExStart/DR and ExStart/BDR, which is also strange.
-- 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."