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
[j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi, 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. I set an ipv6 mtu on all kinds of underlying interfaces but the transmitted mtu does not ever change. there is actually an mtu on the interface: # run show interfaces ip-0/0/0.2 | match mtu Protocol inet6, MTU: 1472 # run show ospf3 interface ip-0/0/0.2 extensive Interface State AreaDR ID BDR ID Nbrs ip-0/0/0.2 PtToPt 0.0.0.1 0.0.0.0 0.0.0.01 Address fe80::b2c6:9aff:fe39:b200, Prefix-length 64 OSPF3-Intf-index 3, Type P2P, MTU 1472, Cost 1 Adj count: 0, Router LSA ID: - Hello 5, Dead 10, ReXmit 5, Not Stub Protection type: None still JUNOS sends 0 (excerpt from trace on JUNOS): Jun 16 02:57:14.012463 OSPF sent DbD fe80::b2c6:9aff:fe39:b200 - ff02::5 (ip-0/0/0.2 IFL 86 area 0.0.0.1) Jun 16 02:57:14.012576 Version 3, length 28, ID 172.23.5.1, area 0.0.0.1 Jun 16 02:57:14.012669 checksum 0x0, instance-id 0 Jun 16 02:57:14.012763 options 0x13, i 1, m 1, ms 1, seq 0xac14361c, mtu 0 tcpdump on the linux side: 03:00:05.532800 IP6 fe80::b2c6:9aff:fe39:b200 ff02::5: OSPFv3-dd 28: rtrid 172.23.5.1 area 0.0.0.1 V6/E/R I/M/MS mtu 0 S AC14361C 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 Unfortunately quagga does not support mtu-ignore, so how can I influence what JUNOS sends as mtu? Thanks, Volker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
