Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
I ran into this a few years ago. Even without going into the JUNOS implementation (they will probably tell you that this is works-as-designed, and that this was a conscious decision), this should not cause an issue in the OSPF session establishment. Per RFC 2328 section 10.6, If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. Otherwise, if the neighbor state is: ... ExStart If the received packet matches one of the following cases, then the neighbor state machine should be executed with the event NegotiationDone (causing the state to transition to Exchange)... Theoretically, MTU=0 would imply that the DBD packets should always be received/processed, and thereby *not* cause any interop concerns. --Addy. On Thu, Jun 17, 2010 at 6:29 PM, Volker D. Pallas juniper-...@sqmail.de wrote: Hi again, yeah, this makes total sense! At first I thought this is a JUNOS-problem, as Cisco does send the right mtu along. I closed the bug report on the quagga bugzilla for now (with closed/invalid) and will talk to JTAC. I'll get back to you and the list as soon as I have some confirmation and/or fix. I'm not so sure anymore. A fellow reader has challenged my interpretation of the RFC wording, that it might mean OSPF virtual links, not tunnel (and similar virtual, non-physical) interfaces. Upon re-reading with that interpretation in mind, I tend to agree. Thinking further about it, mtu=0 for OSPF virtual links makes sense, as only OSPF PDUs are being tunnelled, no actual traffic. So there is no sensible MTU to report in the DBD packets. On real tunneling interfaces though, everything (OSPF PDUs and actual traffic) gets tunnelled, and the tunnel has a real MTU associated. So in fact, I think my interpretation was wrong and JUNOS is actually misbehaving by advertising MTU=0. It should report the tunnel interface L3 MTU. Sorry for the noise. I suggest raising a case with JTAC and closing off the Quagga bug filing. No, not at all! Thanks a lot for your input! I did not even read the appropriate RFC before you posted, which I should do next time. BTW, I noticed your Linux tunnel interface being named gre-nc - I guess the gre part is a leftover misnomer from trying GRE encaps? exactly ;-) It's actually sit now on the linux side Best regards from Porz to Porz, Daniel and best wishes back to you! Volker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi Daniel, thank you for your reply. I've read the RFC now and you're right. I opened a bug report with quagga regarding this issue: https://bugzilla.quagga.net/show_bug.cgi?id=602 OSPFv3 on quagga seems to be a bit buggy in general, I'm still waiting for a fix of another problem (bug #600). Thanks again and have a good night, Volker On 06/16/10 08:49, Daniel Roesen wrote: On Wed, Jun 16, 2010 at 03:39:47AM +0200, Volker D. Pallas wrote: I'm having an issue with an OSPFv3 neighborship between Linux/quagga (0.99.16) and JUNOS (10.1R2.8 on SRX-100) via a standard ip-tunnel: the dbd info sent by JUNOS always contains mtu 0, which quagga does not like at all. This keeps my neighborship in ExStart. According to the OSPFv3 spec (RFC2740), JUNOS is correct in sending MTU 0 on a tunnel interface: Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out theassociated interface, without fragmentation. The MTUs of common Internet link types can be found in Table 7-1of [Ref12]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. [...] I'd say Quagga is wrong to expect anything else than MTU 0 on a tunnel type interface... Best regards, Daniel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi, On Thu, Jun 17, 2010 at 10:46:51PM +0200, Volker D. Pallas wrote: I've read the RFC now and you're right. I'm not so sure anymore. A fellow reader has challenged my interpretation of the RFC wording, that it might mean OSPF virtual links, not tunnel (and similar virtual, non-physical) interfaces. Upon re-reading with that interpretation in mind, I tend to agree. Thinking further about it, mtu=0 for OSPF virtual links makes sense, as only OSPF PDUs are being tunnelled, no actual traffic. So there is no sensible MTU to report in the DBD packets. On real tunneling interfaces though, everything (OSPF PDUs and actual traffic) gets tunnelled, and the tunnel has a real MTU associated. So in fact, I think my interpretation was wrong and JUNOS is actually misbehaving by advertising MTU=0. It should report the tunnel interface L3 MTU. Sorry for the noise. I suggest raising a case with JTAC and closing off the Quagga bug filing. BTW, I noticed your Linux tunnel interface being named gre-nc - I guess the gre part is a leftover misnomer from trying GRE encaps? Best regards from Porz to Porz, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi again, yeah, this makes total sense! At first I thought this is a JUNOS-problem, as Cisco does send the right mtu along. I closed the bug report on the quagga bugzilla for now (with closed/invalid) and will talk to JTAC. I'll get back to you and the list as soon as I have some confirmation and/or fix. I'm not so sure anymore. A fellow reader has challenged my interpretation of the RFC wording, that it might mean OSPF virtual links, not tunnel (and similar virtual, non-physical) interfaces. Upon re-reading with that interpretation in mind, I tend to agree. Thinking further about it, mtu=0 for OSPF virtual links makes sense, as only OSPF PDUs are being tunnelled, no actual traffic. So there is no sensible MTU to report in the DBD packets. On real tunneling interfaces though, everything (OSPF PDUs and actual traffic) gets tunnelled, and the tunnel has a real MTU associated. So in fact, I think my interpretation was wrong and JUNOS is actually misbehaving by advertising MTU=0. It should report the tunnel interface L3 MTU. Sorry for the noise. I suggest raising a case with JTAC and closing off the Quagga bug filing. No, not at all! Thanks a lot for your input! I did not even read the appropriate RFC before you posted, which I should do next time. BTW, I noticed your Linux tunnel interface being named gre-nc - I guess the gre part is a leftover misnomer from trying GRE encaps? exactly ;-) It's actually sit now on the linux side Best regards from Porz to Porz, Daniel and best wishes back to you! Volker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
On Wed, Jun 16, 2010 at 03:39:47AM +0200, Volker D. Pallas wrote: I'm having an issue with an OSPFv3 neighborship between Linux/quagga (0.99.16) and JUNOS (10.1R2.8 on SRX-100) via a standard ip-tunnel: the dbd info sent by JUNOS always contains mtu 0, which quagga does not like at all. This keeps my neighborship in ExStart. According to the OSPFv3 spec (RFC2740), JUNOS is correct in sending MTU 0 on a tunnel interface: Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out theassociated interface, without fragmentation. The MTUs of common Internet link types can be found in Table 7-1of [Ref12]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. quagga log: 2010/06/16 03:01:19 OSPF6: DbDesc received on gre-nc 2010/06/16 03:01:19 OSPF6: src: fe80::b2c6:9aff:fe39:b200 2010/06/16 03:01:19 OSPF6: dst: ff02::5 2010/06/16 03:01:19 OSPF6: OSPFv3 Type:2 Len:28 Router-ID:172.23.5.1 2010/06/16 03:01:19 OSPF6: Area-ID:0.0.0.1 Cksum:6d7e Instance-ID:0 2010/06/16 03:01:19 OSPF6: MBZ: 0 Option: --|R|-|--|E|V6 IfMTU: 0 2010/06/16 03:01:19 OSPF6: MBZ: 0 Bits: IMm SeqNum: 0xac14361c 2010/06/16 03:01:19 OSPF6: I/F MTU mismatch I'd say Quagga is wrong to expect anything else than MTU 0 on a tunnel type interface... Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
