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 <b...@herrin.us> wrote :
On Mon, Oct 31, 2016 at 3:33 PM, Randy <a...@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/
