Follow a consistent flow through a changing network
On a network with load balancing, probes that change the packet fields used to select a route can visit different paths. A single printed hop list can then combine routers that were never on one route.
Equal-cost multi-path routing distributes traffic across available next hops. Many routers select a next hop using packet fields such as the source and destination addresses, protocol, and TCP or UDP ports. Keeping those fields constant helps probes follow the same route while the routing remains stable.
Classic UDP traceroute commonly changes the destination port to identify each probe. ICMP probing can also change the checksum as the sequence or payload changes. When a load balancer uses those fields, consecutive probes may take different routes. Matching replies requires an identifier, but that identifier need not change the fields used to select the path.
The output still looks like one path. It is printed as one column, numbered one to fifteen. Nothing on screen suggests that hop three and hop five were never on the same route as each other.
Same network, same moment, two methods
In this illustration, three routes exist between the agent and target, labelled A, B and C. The left column combines probes that took different routes. The right uses one flow on a stable route with a transport that provides full flow control.
Classic traceroute
Flow identifier changes every probe. Each row is a different conversation.
- 110.0.0.1A
- 210.4.2.1A
- 3203.0.113.9B
- 4198.51.100.4A
- 5198.51.100.71C
- 6192.0.2.18B
- 7192.0.2.33A
Hop 4 does not follow hop 3. They are routers on different routes, printed adjacently. Any latency you compute between them is arithmetic on unrelated numbers.
RouteSpear
One flow identifier, fixed for the whole sweep. Every hop is on the same route.
- 110.0.0.1A
- 210.4.2.1A
- 3203.0.113.4A
- 4198.51.100.4A
- 5198.51.100.23A
- 6192.0.2.11A
- 7192.0.2.33A
Three addresses differ from the column on the left, highlighted above. Those are the routers on route A in this example. Additional flows can reveal routes B and C; a finite set of flows is not guaranteed to find every branch.
A hop's round-trip time describes its response to a probe. Comparing adjacent hops to estimate a link's delay requires evidence that the probes followed the same route, and return-path differences still matter. A silent hop also needs downstream and destination evidence before its missing replies can be interpreted as forwarding loss.
Then vary the flow on purpose
Holding one flow constant gives a coherent path. It gives you one of them. The parallel routes are still there, still carrying your traffic, and one of them can be broken while the others are fine.
With full flow control, each discovery cycle launches several traces concurrently (three by default), each with its own flow identifier held constant across the trace. The snapshot describes the paths those flows observed. A transport with partial or no flow control runs one trace and records the limitation.
By default, two flows stay stable across cycles and one explorer is drawn again each cycle. Stable flows support route-change comparisons; the explorer can find branches the base flows have not visited. With only one configured flow, that flow stays stable. The topology fingerprint uses the stable base flows and connections between hops. Finding a branch with a new explorer alone does not assert a route change. Changes to an already observed flow are recorded, including retained flows outside the base set.
A hop's identity is the flow it was found on, its position in the sweep, and the address that answered. Monitored flows keep separate primary health histories, even when they reach the same address at the same position after different branches. Each subsequent probe reuses its discovered flow.
What you get is a width: the largest number of distinct routers seen at any one position. It describes observed diversity, not the total number of routes. Route changes during a sweep and the transport's flow-control limits also matter when interpreting it.
The honest part
Sampling parallel routes is a coupon-collector problem: three flows will not find eight routes, and RouteSpear does not pretend otherwise. Width is reported as what was observed, not as a discovered total.
ICMP flows can travel together even when the agent varies them correctly: ICMP has no TCP or UDP ports, and the router's hashing policy determines which fields distinguish its probes.
So a width of one from an ICMP test is not evidence that the path does not fork. The result says so in those terms, and tells you to run the test over TCP if fan-out is the question you care about.
Overlap the waits, keep the flow
A silent router should not make every later hop wait for its timeout. Supported transports keep a small window of hop probes in flight while preserving the flow used to discover the path.
Agents with discovery pipelining use up to four TTL positions per flow by default on Linux UDP, raw ICMP, and datagram ICMP transports. Results are assembled in hop order, even when replies arrive out of order. TCP and Windows helper API traces remain sequential within each flow. New portal path checks require TCP by default, so this optimization does not change their protocol or make their hop probes concurrent.
Destination arrival, unreachable replies, configured gap limits, and probe failures still determine where a trace ends. With a window of four, up to three extra TTL positions per flow may already have been attempted beyond that point. Pending work is cancelled, and those extra positions are excluded from the path and its fingerprint. Every probe still passes through the existing rate limiter.
Overlapping waits can shorten discovery on supported transports, especially across silent hops. The gain depends on the path and rate limits; it is not a fixed speedup for every check. Continuous health sampling keeps its own cadence and timeout.
Path Health settings, defaults, and sequential fallbackKeep current evidence separate from path history
Supported checks retain representative flows to revalidate observed branches and spend a bounded allowance on deeper discovery when triggered or periodically. Additional discovery reports its stopping reason; it does not claim exhaustive coverage.
The map contains the selected discovery's observations. A separate path-evidence list records when branches were first and last observed, whether they were reverified, and when a representative flow took another route. A silent probe leaves uncertainty; it does not turn a remembered path into a current one or prove that the route disappeared.
Branch history and discovery limitsWhat the flow identifier actually is
It depends on the protocol, and the difference is not cosmetic. This is the table worth asking any vendor to produce.
| Transport | Identifier | Control | Notes |
|---|---|---|---|
| UDP | Source port | Full | The port sits inside the five-tuple a load balancer hashes, so binding a source port gives flow consistency directly. On Linux the agent reads the returned error through the socket error queue rather than needing a second raw socket. |
| TCP | Source port | Full | TTL-limited TCP probes reuse a source port across a trace and vary it between traces. New portal path checks require TCP with full flow control by default. TCP probes still run sequentially within each flow. |
| Raw ICMP | Identifier and checksum | Full on IPv4; partial on IPv6 | On IPv4, sufficient payload space lets the agent keep the checksum constant while matching replies by sequence. ICMPv6 checksum control is partial. ICMP probes can overlap their reply waits, but a width of one remains inconclusive about fan-out. |
| Datagram ICMP | OS-chosen identifier | Partial | The kernel rewrites the echo identifier. The agent matches replies using transport-allocated sequences and runs one discovery trace per cycle. Reply waits can overlap even though the transport cannot provide full flow control. |
| Windows helper API | Owned by the OS | None | The unprivileged Windows path hands the identifier to the operating system, which supplies its own. The agent cannot hold it constant or vary it, so it runs a single trace per cycle and marks the fidelity of the result degraded. |
Every measurement records which of these produced it. Comparing a figure from a privileged Linux agent against one from an unprivileged Windows host without noticing they used different transports is a mistake the data itself prevents you from making silently.
The parts most tools round off
A silent hop keeps its position
Many routers are configured never to generate ICMP. Recording that as "no hop here" renumbers everything behind it and quietly changes which router your evidence accuses. A hop that does not answer is stored at its position with no address, and the trace continues past it rather than stopping at the first silence.
MPLS labels are read when present
Where a router includes RFC 4884 extensions, the label stack is extracted and kept. Inside a carrier tunnel this is often the only clue about where a packet actually went, and it is the difference between "somewhere in their network" and a specific segment you can quote.
A route change mid-window invalidates the baseline
If the address answering at a position changes, the samples before and after describe different routers. The new sample is kept (it is a real measurement) but the baseline and jitter estimate are reset at that point rather than continuing across the seam as though nothing happened.
Per-hop probing follows the discovered flow
Primary TTL-limited health probes reuse a flow and TTL from discovery, helping them follow the observed route while routing stays stable. Direct echoes to a router are separate diagnostic measurements; they do not claim to follow that discovered path.
Next: why a hop that shows loss may be perfectly healthy
Having a coherent path is the prerequisite. Reading the numbers on it correctly is the other half.