nanog mailing list archives

Re: Help interpret a strange traceroute?


From: Olivier Benghozi <olivier.benghozi () wifirst fr>
Date: Mon, 31 Oct 2016 22:20:01 +0100

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 () herrin us> wrote :

On Mon, Oct 31, 2016 at 3:33 PM, Randy <amps () 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.


Current thread: