Help interpret a strange traceroute?

Mon Oct 31 21:54:33 UTC 2016

On 10/31/16 4:20 PM, Olivier Benghozi wrote:
> Hi Randy,
>
>
> ECMP loadbalancing is most frequently done on layer3+layer4 headers, and unixlike traceroute use UDP with increasing destination port number for each packet (usually starting at 33434), which allows to see the different available paths, as wrote William.
>
> Would you want/need to stick to only one traceroute path, you may use ICMP traceroute instead of UDP traceroute (no port in ICMP, so only layer 3 available to loadbalance, so all packets will go through the same interface).
>
> Usually it is achieved by using traceroute -I yourdest
> Windows tracert is ICMP only traceroute by the way. MTR tool is also ICMP based by default.
>
> Keep in mind that it looses some useful information, though (since you see only one path and don't decide which).
> So, you can also use UDP traceroute with fixed port (by example 33434 with no port increase), and try again the same traceroute with another destport (with fixed port too, by example 33435), which would display two different paths in a more readable way. RTFM is required since the options depend on your traceroute particular specie :)
>
>
> Olivier
>
>> On 31 oct. 2016 à 20:42, William Herrin <bill at herrin.us> wrote :
>>
>> On Mon, Oct 31, 2016 at 3:33 PM, Randy <amps at djlab.com> wrote:
>>> Any idea how a traceroute (into my network) could end up this fubar'd?
>>> Discovered this wierd routing while investigating horrendously slow speeds
>>> (albeit no packet loss) to a particular ISP abroad.
>>
>> Hi Randy,
>>
>> This is per-packet load balancing. In the forward path the alternates
>> are different lengths but the traceroute stops as soon as at least one
>> of the paths reaches the destination.
>>
>> The return path is also engaged in per-packet load balancing but the
>> paths are all the same length.
>

This is also a handy tool that addresses the same issues:

https://paris-traceroute.net/