RING measurements don't match access-networks (Was: Some very nice broken IPv6 networks...)

[Matthew Luckie]

On Tue, Nov 11, 2014 at 12:56:06PM +0100, Jeroen Massar wrote:
> On 2014-11-11 06:38, Matthew Luckie wrote:
> >> Also, broken pMTU/traceroute for:
> >>
> >> 2a02:58:3:110::23:1
> >> 2a01:310:8312:1001::19
> >> 2a00:1f00:dc06:11::10
> >> 2001:48c8:3:2::2
> >> 2607:fcc0:2:1:208:70:247:50
> >> 2001:67c:2274:4021::101
> > 
> > with that list of IP addresses:
> > scamper -c "trace -P udp-paris -M" -f <file>
> 
> See attached f.out, though I used:
> 
> (for i in `cat f`; do echo "==================== $i"; tracepath6 -n $i;
> scamper -I "trace -P udp-paris -M $i"; done) >>f.out
> 
> This to show the difference between tracepath6 and scamper output, there
> are some to be seen, some quite scary (eg the 1455 change).
> Could be that one just gets through the ICMP ratelimits in one run and
> not the other.

Unsure what happened with that one in your file, scamper got an
address unreachable response eventually.  When I tried it just now
it worked and has a 1500 PMTU.

traceroute from 2001:48d0:101:501:d267:e5ff:fe14:a701 to 2a01:310:8312:3900::2
 1  2001:48d0:101:501::18  0.195 ms [mtu: 1500]
 2  2001:468:e00:c48::1  2.592 ms [mtu: 1500]
 3  2607:f380::108:9a41:af60  3.132 ms [mtu: 1500]
 4  2001:468:f000:2300::1  2.622 ms [mtu: 1500]
 5  2001:468:f000:f17::1  11.068 ms [mtu: 1500]
 6  2001:504:d::5580:1  20.959 ms [mtu: 1500]
 7  2a02:d28:5580:1::d1  69.738 ms [mtu: 1500]
 8  2a02:d28:5580::1:c9  75.740 ms [mtu: 1500]
 9  2a02:d28:5580:5:1008::5  155.666 ms [mtu: 1500]
10  2a02:d28:5580:1::136  159.654 ms [mtu: 1500]
11  2a02:d28:5580:1::156  159.484 ms [mtu: 1500]
12  2a02:d28:5580:e:1000::136  158.690 ms [mtu: 1500]
13  2a01:310:8312:3900::2  158.653 ms [mtu: 1500]

For the rest, those addresses are just unresponsive to traceroute,
i.e. no port unreachable response comes back from the destination.

> I am always surprised to see networks filtering out packets, and
> especially wonder what they are trying to achieve with such a filter.
> 
> > http://www.caida.org/tools/measurement/scamper/
> > http://www.caida.org/~mjl/pubs/debugging-pmtud.imc2005.pdf
> > 
> > Happy to help anyway I can (I wrote scamper)
> 
> I am quite aware. Great tool, but not very verbose unfortunately. Hence,
> typically it just does/outputs nothing.

It is designed for doing lots of measurements in parallel, so does not
output anything until it is done.  To do PMTU debugging, it relies
on the end host being responsive to at least some probes, to distinguish
between all packets being discarded, and just big ones.

If you want the full details on what is going on, output to warts
format and use sc_wartsdump or sc_warts2json.

Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20141112/7ccd18fb/attachment.sig>