On Fri, Sep 01, 2006 at 02:48:10PM +0200, Jeroen Massar wrote: > > How sure are you these have a MTU of 1500? Best way to test is to do > ping6's in the form of "ping6 -M do -s 1500 <target>" and decrementing > per 10 or 20 till it doesn't respond anymore and then increasing again. > > >19: 52.ge0-0.cr2.lhr1.uk.occaid.net asymm 18 16. 63ms pmtu 1480
These seem to be OK. > Maybe a traceroute6 interface on http://noc.ietf.org/ could help debug > these issues easier? I'll send the secretariat a separate message about > that, also that they might want to ask Neustar join up with GRH > (http://www.sixxs.net/tools/grh/) to make debugging easier as then we at > least have ASpaths also which might help here. I think that would be helpful. I think IETF could support nice diagnostics if showcasing v6 connectivity. > Check your neighbor cache after the traceroute/path or even a full TCP > connect has completed, you should have an entry similar to: > > [EMAIL PROTECTED]:~$ ip -6 ro sho cache > 2001:503:c779:b::d1ad:35b4 via 2001:7b8:5:10:74::1 dev eth1 metric 0 > cache expires 429sec mtu 1480 advmss 1440 hoplimit 4294967295 > > The 1480 is noted here, check that that is the case. Well, I can see www.ipv6tf.org fine, but www.ietf.org hangs in the browser, but both seem to negotiate 1480 MTU: For www.ipv6tf.org $ /usr/sbin/tracepath6 www.ipv6tf.org 1?: [LOCALHOST] pmtu 1500 1: 2001:630:d0:f102::2 1.231ms 2: zaphod.6core.ecs.soton.ac.uk 4.443ms 3: ford.6core.ecs.soton.ac.uk 1.849ms 4: 2001:630:c1:100::1 1.982ms 5: 2001:630:c1:10::1 2.681ms 6: no reply 7: no reply 8: no reply 9: po9-0.cosh-scr.ja.net 7.729ms 10: po2-0.lond-scr.ja.net 9.693ms 11: po0-0.lond-scr4.ja.net 10.444ms 12: gi0-1.lond-isr4.ja.net 5.880ms 13: 2001:630:0:10::52 6.636ms 14: uk6x.ipv6.btexact.com 8.269ms 15: uk6x.ipv6.btexact.com asymm 14 11.370ms pmtu 1480 15: v6-tunnel-consulintel.ipv6.btexact.com asymm 16 68.662ms 16: no reply 17: no reply <snip> Indicates 1480, and I get the 1480 MTU in my cache: [EMAIL PROTECTED] ~]$ /sbin/ip -6 ro sho cache 2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev eth0 metric 0 cache mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440 2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0 metric 0 cache expires 557sec mtu 1480 advmss 1440 Then doing the same to www.ietf.org $ /usr/sbin/tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1500 1: 2001:630:d0:f102::2 1.297ms 2: zaphod.6core.ecs.soton.ac.uk 1. 94ms 3: ford.6core.ecs.soton.ac.uk 1.984ms 4: 2001:630:c1:100::1 2. 35ms 5: 2001:630:c1:10::1 2.746ms 6: no reply 7: no reply 8: no reply 9: po9-0.cosh-scr.ja.net 3. 16ms 10: po2-0.lond-scr.ja.net 6. 13ms 11: po0-0.lond-scr4.ja.net 5.876ms 12: gi0-1.lond-isr4.ja.net 8.529ms 13: 2001:630:0:10::52 8.918ms 14: ge-2-24.r01.londen03.uk.bb.gin.ntt.net 8.277ms 15: xe-0-1-0.r23.londen03.uk.bb.gin.ntt.net asymm 16 8.742ms 16: xe-0-2-0.r22.londen03.uk.bb.gin.ntt.net asymm 17 8.823ms 17: 1d-uk6x.ipv6.btexact.com 12. 38ms 18: 52.ge0-0.cr2.lhr1.uk.occaid.net 16.152ms 19: 52.ge0-0.cr2.lhr1.uk.occaid.net asymm 18 12.347ms pmtu 1480 19: v3323-mpd.cr1.ewr1.us.occaid.net 88.965ms 20: ge-0-1-0.cr1.iad1.us.occaid.net 93.819ms 21: unknown.occaid.net 100.504ms 22: no reply 23: no reply <snip> Suggests 1480, and that's in the cache: [EMAIL PROTECTED] ~]$ /sbin/ip -6 ro sho cache 2001:503:c779:b::d1ad:35b4 via fe80::214:1bff:fe3d:2c00 dev eth0 metric 0 cache expires 591sec mtu 1480 advmss 1440 2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev eth0 metric 0 cache mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440 2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0 metric 0 cache expires 329sec mtu 1480 advmss 1440 So both behave the same apparently in terms of PMTU discovery. I just wondered if it might be an Apache thing because have run into things like SENDFILE optimisation issues before. But you've ruled that out I think. > >$ /usr/sbin/traceroute6 www.ietf.org > >traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from > >2001:630:d0:f102:230:48ff:fe23:58df, 30 hops max, 16 byte packets > > 1 2001:630:d0:f102::2 (2001:630:d0:f102::2) 1.883 ms 2.719 ms 4.513 ms > > 2 zaphod.6core.ecs.soton.ac.uk (2001:630:d0:f001::1) 4.462 ms 2.485 ms > > 2.886 ms > > 3 ford.6core.ecs.soton.ac.uk (2001:630:d0:f000::1) 3.444 ms 0.648 ms > > 0.64 ms > > 4 2001:630:c1:100::1 (2001:630:c1:100::1) 1.235 ms 1.104 ms 0.962 ms > > 5 2001:630:c1:10::1 (2001:630:c1:10::1) 1.21 ms 1.138 ms 1.186 ms > > 6 * * * > > 7 2001:630:c1::1 (2001:630:c1::1) 4.982 ms 2.891 ms 2.138 ms > > 8 2001:630:c1::1 (2001:630:c1::1) 2.562 ms 2.189 ms 2.662 ms > > These hops are weird IMHO, 7 & 8 should not be duplicate, prolly a Cisco > IOS located there as there are some releases which didn't decrement the > TTL when going from Ethernet->ATM or some other weird interface changeover. Yeah, it's a Cisco MPLS network used by our regional academic network. > [EMAIL PROTECTED]:~$ tracepath6 2001:630:d0:f102::2 > 1?: [LOCALHOST] pmtu 1500 > 1: 2001:7b8:5:10:74::1 33.450ms > 2: i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm 3 33.178ms > 3: jun1.telecity.ipv6.network.bit.nl asymm 4 34.478ms > 4: ge-0.ams-ix.amstnl02.nl.bb.verio.net asymm 5 34.595ms > 5: xe-0-2-0.r22.amstnl02.nl.bb.gin.ntt.net 34.464ms > 6: p64-2-0-0.r23.londen03.uk.bb.gin.ntt.net 42.452ms > 7: xe-3-1.r01.londen03.uk.bb.gin.ntt.net asymm 6 42.515ms > 8: ge-0.ukerna.londen03.uk.bb.gin.ntt.net asymm 7 42.596ms > 9: fa1-1.lond-isr4.ja.net asymm 8 43.537ms > 10: gi4-0-1.lond-scr4.ja.net asymm 9 44.426ms > 11: po0-0.lond-scr.ja.net asymm 10 44.597ms > 12: po2-0.cosh-scr.ja.net asymm 11 46.558ms > 13: po0-0.cosham-bar.ja.net asymm 12 46.572ms > 14: lense.site.ja.net asymm 13 46.602ms > 15: no reply > 16: 2001:630:c1:1::1 asymm 15 47.266ms > 17: 2001:630:c1:10::2 asymm 16 48.727ms > 18: 2001:630:c1:100::2 asymm 17 48.722ms > 19: internal-router.6core.ecs.soton.ac.uk asymm 18 48.714ms > 20: internal-router.6core.ecs.soton.ac.uk asymm 18 48.597ms !H > Resume: pmtu 1500 > > Seems also to think it is a MTU of 1500, though the traceroute doesn't > finalize. Try to www.ecs.soton.ac.uk maybe. I guess we should take this offline or to the IPv6 ops list. Thanks for the far end help :) Whatever's happening changed quite recently. Just curious as to what... I believe we follow the ICMPv6 filtering recommendations text here, and the above suggests PMTU discovery is acting reasonably. -- Tim/::1 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
