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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: PGP signature
