[192536] in North American Network Operators' Group
Re: Help interpret a strange traceroute?
daemon@ATHENA.MIT.EDU (Dovid Bender)
Tue Nov 1 06:59:52 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <e36b7e3d-a36b-4048-1022-9f3a4f5603a8@shout.net>
From: Dovid Bender <dovid@telecurve.com>
Date: Tue, 1 Nov 2016 06:59:47 -0400
To: Bryan Holloway <bryan@shout.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Does anyone have an IP that involves a load balancing router to test with?
On Mon, Oct 31, 2016 at 5:54 PM, Bryan Holloway <bryan@shout.net> wrote:
> 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 differe=
nt
>> 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 laye=
r 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 ICM=
P
>> 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 tw=
o
>> different paths in a more readable way. RTFM is required since the optio=
ns
>> depend on your traceroute particular specie :)
>>
>>
>> Olivier
>>
>> On 31 oct. 2016 =C3=A0 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.
>>>
>>
>>
> This is also a handy tool that addresses the same issues:
>
> https://paris-traceroute.net/
>
>
