Tim Chown wrote:
On Fri, Sep 01, 2006 at 01:25:19PM +0200, Jeroen Massar wrote:Tim Chown wrote:
[..]
jeroen@purgatory:~$ tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 1480
This 1480 is actually from the pmtu cache, when it expires, or I flush it manually, it gives:
1?: [LOCALHOST] pmtu 1500 1: 2001:7b8:5:10:74::1 33.631ms 2: i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm 3 35.484ms 3: jun1.telecity.ipv6.network.bit.nl asymm 4 34.532ms 4: zpr2.amt.cw.net asymm 5 36.527ms 5: so-5-2-0-dcr1.amd.cw.net asymm 6 36.572ms 6: as0-dcr2.amd.cw.net asymm 7 36.553ms 7: so-4-0-0-dcr1.tsd.cw.net asymm 8 42.392ms 8: so-1-0-0-zcr1.lnt.cw.net asymm 9 44.520ms 9: 2001:7f8:4::31f9:1 asymm 8 137.479ms 10: 2001:7f8:4::31f9:1 asymm 8 137.774ms pmtu 1480 10: v3323-mpd.cr1.ewr1.us.occaid.net asymm 7 142.540ms 11: ge-0-1-0.cr1.iad1.us.occaid.net asymm 7 147.413ms 12: unknown.occaid.net asymm 8 148.820ms Long live native IPv6 over DSL :) Hop 9/10 are a bit weird though, most likely a TTL bug.
And then no responses, thus most likely filtered for this kind of trace.So I'm on RedHat, have tracepath6 installed (not used before, thanks for the pointer :) and I see in comparison:
Yes, tracepath6 is a *very* useful tool, but as I demonstrated myself above, it doesn't flush the cache, thus be careful there. Tracepath6 uses some Linux specific tricks for getting certain information, which is why (afaik) it is not available on eg BSD's.
$ /usr/sbin/tracepath6 www.ietf.org 1?: [LOCALHOST] pmtu 15001: 2001:630:d0:f102::2 1.191ms 2: zaphod.6core.ecs.soton.ac.uk 1. 93ms 3: ford.6core.ecs.soton.ac.uk 1.915ms 4: 2001:630:c1:100::1 2. 66ms 5: 2001:630:c1:10::1 2.353ms 6: no reply7: no reply 8: no reply9: po9-0.cosh-scr.ja.net 8.440ms
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
Though from this hop you should have 1480 which is at least the correct value for the rest of the route. 1280 should always work of course, but then the link has to indicate this too. The problem with debugging this is that you can't do a traceroute6 from both sides, there might be an async route back to your network which might be causing this issue. Assuming that http://www.sixxs.net/tools/traceroute/ indicates that the three SixXS PoPs inside the OCCAID network, over which the IETF seems to get connectivity at least pick Verio->NTT as an outbound route towards your network.
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.
[..]
Hmm, 1500 vs 1480.
Check your neighbor cache after the traceroute/path or even a full TCP connect has completed, you should have an entry similar to:
jeroen@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.
$ /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.
jeroen@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.
Greets, Jeroen
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf