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:
jeroen(_at_)purgatory:~$ 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:
[tjc(_at_)login ~]$ /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:
[tjc(_at_)login ~]$ /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.
jeroen(_at_)purgatory:~$ 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf