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 ?
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.
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>