Help interpret a strange traceroute?
dovid at telecurve.com
Tue Nov 1 10:59:47 UTC 2016
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 at 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 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
>> 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 :)
>> 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
>>>> (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:
More information about the NANOG