With ECMP active across the NOC's two fibre uplinks to a regional aggregation point, engineers notice that a single large file transfer only ever uses one of the two links, even though many separate sessions are spread across both. Why does ECMP behave this way for that one transfer?
Select an answer to reveal the explanation.
Short Explanation
ECMP balances the traffic jam, not each individual car's trip. Once a session picks a lane based on the hash, it stays in that lane for its whole trip so packets don't arrive out of order — that's why one big transfer rides one link start to finish while other sessions fill the other.
Full Explanation
ECMP distributes load across equal-cost paths on a per-session basis using a hash of session attributes, not by splitting an individual session's packets across multiple links; keeping all of one session's packets on the same path avoids reordering issues that would otherwise degrade throughput and complicate stateful inspection. This is exactly why many small, independent sessions spread across both fibre uplinks in aggregate while a single large transfer, being one session, is pinned to whichever link its hash selected for its entire duration. This is expected behavior, not a malfunction, so removing the routes would be the wrong response and would simply eliminate the redundancy the design relies on. ECMP load-balancing is not restricted to UDP; TCP sessions are balanced the same way, just as whole units, which is precisely the described symptom. There is also no requirement to manually split a file transfer into multiple connections — that is an application-layer decision unrelated to how the FortiGate's routing layer distributes sessions. An operational check is to open several concurrent smaller sessions to the aggregation point and confirm interface counters show traffic on both fibre links, confirming ECMP is active even though one large transfer alone will not visibly split.