[192525] in North American Network Operators' Group
Re: Help interpret a strange traceroute?
daemon@ATHENA.MIT.EDU (Olivier Benghozi)
Mon Oct 31 17:20:06 2016
X-Original-To: nanog@nanog.org
From: Olivier Benghozi <olivier.benghozi@wifirst.fr>
Date: Mon, 31 Oct 2016 22:20:01 +0100
To: "nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <CAP-guGXsfOH_UFo8WrL+BrSZ=4CAjP7AxBU+=cY7Sh=cW=ChHQ@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
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 =C3=A0 20:42, William Herrin <bill@herrin.us> wrote :
>=20
> 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.
>=20
> Hi Randy,
>=20
> 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.
>=20
> The return path is also engaged in per-packet load balancing but the
> paths are all the same length.
