Re: Pointers please - OSPFv3 vs Cisco IOS XR
Hi Ondrej, sorry, I missed your response (T., thank you for forwarding):
I am very certain somebody has experienced similar issues and solved them; I did not find any pointers - please throw them at me. If this is new or unsolved, please help me forward, I can get more output, naturally.
Hi
It might be useful if you enable 'debug all' for OSPFv3 in BIRD.
Alright...sorry, I thought I had "all" on, but apparently didn't. Here's the output from that, shortened and edited to protect the innocent. (If you require the full output, I'll email it to you) Thank you for taking a look at this, Elmar. ======================================================================================= 2020-06-03 12:30:13.801 <TRACE> ospf2: HELLO packet received from nbr <router-1> on igb0 2020-06-03 12:30:16.899 <TRACE> ospf2: DBDES packet received from nbr <router-1> on igb0 2020-06-03 12:30:16.899 <TRACE> ospf2: length 28 2020-06-03 12:30:16.899 <TRACE> ospf2: router <router-1> 2020-06-03 12:30:16.899 <TRACE> ospf2: mtu 1500 2020-06-03 12:30:16.899 <TRACE> ospf2: imms I M MS 2020-06-03 12:30:16.899 <TRACE> ospf2: ddseq 147850133 2020-06-03 12:30:16.899 <TRACE> ospf2: Neighbor <router-1> on igb0 changed state from ExStart to Exchange 2020-06-03 12:30:16.899 <TRACE> ospf2: DBDES packet sent to nbr <router-1> on igb0 2020-06-03 12:30:16.899 <TRACE> ospf2: length 108 2020-06-03 12:30:16.899 <TRACE> ospf2: router <bird-ip> 2020-06-03 12:30:16.899 <TRACE> ospf2: mtu 1500 2020-06-03 12:30:16.899 <TRACE> ospf2: imms 2020-06-03 12:30:16.899 <TRACE> ospf2: ddseq 147850133 (a handful of LSAs) 2020-06-03 12:30:16.901 <TRACE> ospf2: DBDES packet received from nbr <router-1> on igb0 2020-06-03 12:30:16.901 <TRACE> ospf2: length 1228 2020-06-03 12:30:16.901 <TRACE> ospf2: router <router-1> 2020-06-03 12:30:16.901 <TRACE> ospf2: mtu 1500 2020-06-03 12:30:16.901 <TRACE> ospf2: imms M MS 2020-06-03 12:30:16.901 <TRACE> ospf2: ddseq 147850134 (more LSAs) 2020-06-03 12:30:16.901 <TRACE> ospf2: DBDES packet sent to nbr <router-1> on igb0 2020-06-03 12:30:16.901 <TRACE> ospf2: length 28 2020-06-03 12:30:16.901 <TRACE> ospf2: router <bird-ip> 2020-06-03 12:30:16.901 <TRACE> ospf2: mtu 1500 2020-06-03 12:30:16.901 <TRACE> ospf2: imms 2020-06-03 12:30:16.901 <TRACE> ospf2: ddseq 147850134 2020-06-03 12:30:16.903 <TRACE> ospf2: LSREQ packet sent to nbr <router-1> on igb0 2020-06-03 12:30:16.903 <TRACE> ospf2: length 736 2020-06-03 12:30:16.903 <TRACE> ospf2: router <bird-ip> (some LSRs) 2020-06-03 12:30:16.906 <TRACE> ospf2: LSREQ packet received from nbr <router-1> on igb0 2020-06-03 12:30:16.906 <TRACE> ospf2: length 52 2020-06-03 12:30:16.906 <TRACE> ospf2: router <router-1> (more LSRs) 2020-06-03 12:30:16.906 <TRACE> ospf2: LSUPD packet sent to nbr <router-1> on igb0 2020-06-03 12:30:16.906 <TRACE> ospf2: length 144 2020-06-03 12:30:16.906 <TRACE> ospf2: router <bird-ip> (some LSAs) 2020-06-03 12:30:16.906 <TRACE> ospf2: DBDES packet received from nbr <router-1> on igb0 2020-06-03 12:30:16.906 <TRACE> ospf2: length 28 2020-06-03 12:30:16.906 <TRACE> ospf2: router <router-1> 2020-06-03 12:30:16.906 <TRACE> ospf2: mtu 1500 2020-06-03 12:30:16.906 <TRACE> ospf2: imms I M MS 2020-06-03 12:30:16.906 <TRACE> ospf2: ddseq 147850135 2020-06-03 12:30:16.906 <RMT> ospf2: Bad DBDES packet from nbr <router-1> on igb0 - I-bit mismatch (7) =======================================================================================
On Wed, Jun 03, 2020 at 02:36:53PM +0200, Elmar K. Bins wrote:
Hi Ondrej,
sorry, I missed your response (T., thank you for forwarding):
I am very certain somebody has experienced similar issues and solved them; I did not find any pointers - please throw them at me. If this is new or unsolved, please help me forward, I can get more output, naturally.
Hi
It might be useful if you enable 'debug all' for OSPFv3 in BIRD.
Alright...sorry, I thought I had "all" on, but apparently didn't. Here's the output from that, shortened and edited to protect the innocent. (If you require the full output, I'll email it to you)
Hi 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): May 31 13:09:16.280 UTC: ospfv3[1021]: ADJ: Recv DBD fr <server> on TenGigE0/1/0/23.4 seq 0x8ce5d6a opt R/E/V6 flag NONE len 28 mtu 1500 state EXCHANGE May 31 13:09:16.280 UTC: ospfv3[1021]: ADJ: Send DBD to <server> on TenGigE0/1/0/23.4 seq 0x8ce5d6b opt R/E/V6 flag I/M/MS len 28 mtu 1500 So any explanation of this has to be found in Cisco side, I suppose that this exchage repeats indefinetly and 'show ospf neighbors' on BIRD also shows the other side in ExStart/Exchange? -- 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."
Hi Ondrej,
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. Thank you anyway, if I find anything, I'll share. For the moment, it's back to Quagga. Elmar.
Moin Elmi, Can you please take pcap from both software stacks: Quagga and Bird? Guess this should show the difference... Rgds, SJ On Wed, Jun 3, 2020 at 3:45 PM Elmar K. Bins <elmi@noir.de> wrote:
Hi Ondrej,
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.
Thank you anyway, if I find anything, I'll share. For the moment, it's back to Quagga.
Elmar.
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. Yours, Elmar. elmi@noir.de (Elmar K. Bins) wrote:
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.
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."
participants (3)
-
Elmar K. Bins -
Ondrej Zajicek -
Stefan Jakob