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

[Jeroen Massar]

On 2014-11-11 18:29, Matthew Luckie wrote:
> 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.

I would say, somebody is reading along and  fixed it, same result here:

$ scamper -I "trace -P udp-paris -M 2a01:310:8312:3900::2"
traceroute from 2a02:2528:fa:420::66 to 2a01:310:8312:3900::2
 1  2a02:2528:fa:420::1  0.201 ms [mtu: 1500]
 2  2a02:2528:503:2::ffff  0.556 ms [mtu: 1500]
 3  2a02:2528:502:1::1  13.036 ms [mtu: 1500]
 4  2001:7f8:c:8235:194:42:48:80  1.780 ms [mtu: 1500]
 5  2001:7f8:24::ad  2.455 ms [mtu: 1500]
 6  2a02:d28:5580:1::a2  19.674 ms [mtu: 1500]
 7  2a02:d28:5580::1:36  24.782 ms [mtu: 1500]
 8  2a02:d28:5580:1::145  17.503 ms [mtu: 1500]
 9  2a02:d28:5580:1::21  28.141 ms [mtu: 1500]
10  2a02:d28:5580:e:1000::136  17.942 ms [mtu: 1500]
11  2a01:310:8312:3900::2  18.194 ms [mtu: 1500]

$ tracepath6 -n 2a01:310:8312:3900::2
 1?: [LOCALHOST]                        0.033ms pmtu 1500
 1:  2a02:2528:fa:420::1                                   0.126ms
 1:  2a02:2528:fa:420::1                                   0.070ms
 2:  2a02:2528:503:2::ffff                               131.162ms
 3:  2a02:2528:502:1::1                                    2.183ms
 4:  2001:7f8:c:8235:194:42:48:80                          6.248ms
 5:  2001:7f8:24::ad                                       2.831ms
 6:  2a02:d28:5580:1::a2                                  17.387ms asymm  8
 7:  2a02:d28:5580::1:36                                  17.438ms asymm  8
 8:  2a02:d28:5580:1::145                                 18.135ms asymm  9
 9:  2a02:d28:5580:1::21                                  28.188ms
10:  2a02:d28:5580:e:1000::136                            18.782ms asymm 11
11:  2a01:310:8312:3900::2                                18.558ms reached
     Resume: pmtu 1500 hops 11 back 54

[..]
>>> 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.

Well, a simple '-V' or --verbose option would be useful too ;)

Greets,
 Jeroen