Could you confirm that in an infrastructure configured with "per packet" load balancing on the Routers (same route same metric), the usage of traceroute become unusable ? In this case the infrastucture should delivered traceroute results like random results for the same destination host ?

  • You will need to edit your question to give us more information. This question lacks detail and specificity, and it is really too broad. – Ron Maupin Jan 22 '18 at 2:17

There is no way to trace the route of a packet in typical IP infrastructure. There was an experimental extension for it but it was never widely implemented.

So what traceroute actually does it send out probes with increasing TTL and look for the time-exceeded messages.

So in a per-packet load balanced infrstructure traceroute will be able to tell you how far along the path(s) each router it finds is but it cannot tell whether router(s) it finds at hop "n" and router(s) it finds at hop "n+1" are on the same path or different paths.

per-packet load balancing is rarely used through, most load balancing is done on a basis of "flows" because re-ordering packets within a flow often leads to poor performance. The flow is characterised by some combination of header fields, often source/destination IPs and source/destination ports.

In a per flow load balanced environment it is possible to get useful traceroutes but you have to be careful what traceroute implementation you use. To get a self-consistent trace the traceroute implementation must ensure that the relavent header fields are kept consistent such that all packets are seen as part of the same flow.

I recall a presentation (think it was a uknof video) which mentioned a traceroute monitoring tool that had the ability to trace with consistent source ports across multiple traces and report which paths had problems. It looks like the video was https://www.youtube.com/watch?v=jqaiXtBF4ug and the tool was "fbtracert"


Using load-balancing trunks, the hardware needs to keep the flows in order - out-of-order reception in high bandwidth flows usually causes a high performance penalty. So basically, load-balancing works on flows and not on a packet-by-packet basis.

Traceroute uses its own "flow" (ICMP oder some UDP port) which may or may not follow the same path as the flow you're analyzing, so it might show you a completely different route.


Due to how a traceroute utility typically works (by sending a series of ping packets with an ever increasing TTL and then watching for the response packets), you are spot-on that the utility may not give you very reliable information as each of the successive packets sent by traceroute might have taken different paths through the network in a real "per-packet" load-balanced network (note that these are rare).

If you do need a utility to trace the route that a single packet takes through your network, you could try using the RECORD_ROUTE feature of an ECHO_REQUEST. The record RECORD_ROUTE flag requests that any intermediary routing hosts add their "hop" to the route in the IP header.

Note: there is limited space in the IP header for this route recording, and so only about 9 hops will be recorded. Also note that not all routing hosts may support this flag on echo requests, but if the usage is on your internal network (limited number of hops) and your gear does record the hops (you'll know). Then it can be a useful tool.

Check the ping man pages for your platform / OS of choice, but on my Mac (and most Linux distributions) it is as easy as this:

ping -R -c 1 <dest-ip-address>

enter image description here

  • ...another cool feature of this for your per-packet LB network is that, if you don't specify the request count (omit the -c 1 from my answer above) ping will send multiple packets, and you can compare the routes that each of them took. 😎 – cmlccie Jan 23 '18 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.