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
pgpqQvIziFK6m.pgp
Description: PGP signature
