ecmp·--ecmp

Where one hop becomes three.

Load balancers hash each flow onto a different link. A normal trace holds one flow and sees one member. --ecmp varies the source port per probe and sends more probes per hop, so every parallel next hop appears — drawn as a diamond in every diagram.

lft -S -m 3 -n www.yahoo.com

[edge.lax]$ lft -S -m 3 -n www.yahoo.com

TTL LFT trace to 209.73.190.12:443/tcp
 1  192.0.2.1 0/0/0 ±0ms
 2  198.51.100.10 1/1/1 ±0ms
**  [neglected] no reply packets received from TTL 3
 4  184.104.193.142 10/11/12 ±1ms
**  [neglected] no reply packets received from TTL 5
 6  74.6.226.215 8.2ms
 │  74.6.226.195 8.4ms
 │  209.73.188.55 8.5ms
 7  209.73.188.49 8.2ms
 │  209.73.188.73 8.3ms
**  [neglected] no reply packets received from TTLs 8 through 11
12  [target open] 209.73.190.12:443 8.5ms

TTL 4
184.104.193.142

→

74.6.226.215

74.6.226.195

209.73.188.55

→

TTL 12 [target open]
209.73.190.12:443

TTL 6 of the documented trace: three responders seen incidentally with -m 3; twelve members with --ecmp. The TTL prints once per hop; each further member of the same hop carries a │ in the TTL column. Both traces are verbatim from lft(8).

Why the ordinary trace is stable on purpose

Flow-hash stability is a feature, not a limitation: -z holds one random source port for the whole TCP trace, the UDP engine keeps one destination port with a session-unique IP ID, and ICMP keeps one sequence anchor — so a normal trace follows one path end to end, the way a real connection does. --ecmp deliberately breaks that to enumerate the alternatives, sending at least fifteen probes per replied hop.

How the diamond is drawn

In -g, --svg and --mermaid output, an ECMP hop renders as a fork-and-join: one node per member at that TTL, converging on the next hop. In --json, every member is an explicit entry in hops[].responders[]. Watch mode accumulates members across cycles and logs an "ECMP shift" — not a path change — when a hop alternates among addresses it has already seen.

See the renderings Build a command