ECMP to One VTEP: Where VXLAN Entropy Comes From

The claim that equal-cost multipath is pointless for a host route gets repeated often enough to sound true. A /32 selects a destination address, and nothing about that selection restricts the packet to one physical link. When the destination is a remote VXLAN tunnel endpoint, several next hops can carry different overlay flows, and whether they do depends on what the forwarding hash is allowed to see. The rest is arithmetic on the outer header, not a property of the prefix.

The route decides reachability; the hash decides distribution.

The Myth: a /32 Means One Path

OSPF can report equal-cost reachability to a VTEP loopback while the forwarding table installs a group of next hops for that same prefix. The protocol supplies the candidates; the platform decides which of them are usable and how a packet is assigned. No routing protocol computes a fresh hash for each encapsulated frame. That separation is why two routers holding identical routes can still distribute traffic differently.

Look at the installed forwarding entry rather than the route display alone, because hardware or policy limits can drop candidates that the control plane still advertises.

Where the Entropy Has to Come From

Between two VTEPs, the outer source and destination addresses stay fixed, and the UDP destination port is 4789 in a conventional deployment. A hash reading only those values sees a constant input and returns a constant path. Something in the outer header has to vary, and the VTEP is the device that can make it vary.

RFC 7348 suggests deriving the UDP source port from fields inside the encapsulated frame. Different inner conversations then produce different outer tuples, which gives an ordinary transport hash something to work with.

If the forwarding hardware can inspect further into the packet, check which inner fields its hash implementation supports. That depth should not be treated as a requirement for every underlay device, since source-port variation alone already exposes useful differences.

Check the Hash You Actually Get

Measure rather than assume. Capture a sample of encapsulated traffic and look at the outer source ports, then compare the result with the forwarding entries and per-link counters.

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

One source port appearing across many different inner conversations means the VTEP is not varying the field, and no amount of underlay tuning will spread the load. Many distinct ports with one next hop in use points at the forwarding group instead.

Record the counters before and after the sample, and note unrelated traffic that shares the uplinks, or the numbers will look worse than the hash deserves.

What Even Distribution Does Not Mean

A per-flow hash is designed to keep one conversation on one path while its inputs and the available path set stay unchanged. A single large TCP transfer therefore does not aggregate every uplink, and adding links will not speed that one flow up. This is normal behaviour, not a fault.

Several flows can also collide on the same next hop by chance. A short sample can look badly skewed while the hash is doing exactly what it was configured to do, and a link failure or path-set change can move established flows mid-transfer.

Test with representative address pairs, transports and rates under an approved plan, and keep link-aggregation member selection separate from routed multipath selection, because two hashing stages compose into their own pattern. A populated next-hop group plus visible outer entropy explains the outcome; the prefix length does not.