request for help in finding a blackhole
Andrew Yourtchenko
ayourtch at gmail.com
Wed May 5 10:02:41 CEST 2010
On Wed, May 5, 2010 at 8:35 AM, Jogi Hofmüller <jogi at mur.at> wrote:
> After hop 12 (our border router) there is only our webserver which does
> not reply to UDP pakets. You can use birke.mur.at as an alternative
> traceroute6/ping6 target since this host is less restrictive than our
This is a tracepath6 from my stdio.be box (systeminplace's Xen VPS, in
L.A. AFAIR), it does show a trace of MTU 1450 in there:
1?: [LOCALHOST] pmtu 1500
1: 2607:f128:42:73::1 0.265ms
1: 2607:f128:42:73::1 0.273ms
2: 2607:f128:40:400::9 0.952ms
3: 2607:f128:a:3::2 0.903ms
4: 2607:f128:a::2 1.049ms asymm 3
5: te8-4-116.ar1.ord1.us.nlayer.net 1.153ms asymm 3
6: ae1-40g.cr2.ord1.us.nlayer.net 0.904ms asymm 7
7: 2001:450:2002:1d9::1 178.648ms asymm 6
8: 2001:7f8:4::d1c:1 90.848ms asymm 9
9: 2001:7f8:4::d1c:1 90.858ms pmtu 1450
9: tu-613.sar1.Amsterdam1.Level3.net 112.758ms asymm 12
9: tu-613.sar1.Amsterdam1.Level3.net 109.083ms asymm 12
10: Aconet.tu-637.sar1.Amsterdam1.Level3.net 129.158ms asymm 13
11: 2001:628::a089:0:1 135.536ms asymm 14
12: birke.mur.at 139.920ms reached
Resume: pmtu 1450 hops 12 back 50
Pcap does confirm the 2001:7f8:4::d1c:1 sending ICMP Too Big.
Wild guess on what might be happening: one of the boxes in the
interconnect is configured with a larger MTU than everything else
(possibly - larger than the L2 MTU ?), so when you give it large
packets, it transmits them, and they are eaten at L2. The other boxes
are configured correctly and can spew ICMP Too Big just fine.
However, for this theory to be even remotely right, we'd need to
verify that dropping is in one direction only. Is that a valid
assumption (aka do we have a way to test it in the other direction) ?
cheers,
andrew
More information about the ipv6-ops
mailing list