Tim Chown wrote:
On Fri, Sep 01, 2006 at 01:25:19PM +0200, Jeroen Massar wrote:
Tim Chown wrote:
[..]
jeroen(_at_)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 1500
1: 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 reply
7: no reply
8: no reply
9: 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(_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.
$ /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(_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.
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf