EtherChannel and LACP Hashing: Why One Flow Fills One Link

A four-member port channel does not give any single conversation four times the bandwidth. It gives the switch a choice of four equally valid egress links, and that choice is made by a deterministic hash of selected fields in each frame. Understanding which fields are hashed - and which are not - explains almost every "the bundle is up but throughput is capped" complaint.

The hash is deterministic, and that is the point

As Cisco's documentation puts it plainly: if you use the same addresses and session information, you always hash to the same port in the channel. Determinism is required, because frames that arrive out of order would otherwise cause reordering at the receiver and destroy TCP performance. The side effect is that a single flow can never exceed the bandwidth of one member link.

! The classic symptom
Port-channel1 members: Et1 (100%), Et2 (2%), Et3 (1%), Et4 (1%)

Ten large flows between two hosts may use all four links well; one large flow between two hosts, no matter how much data it transfers, uses exactly one.

What the hash can use

The choice matters more on server and storage links than on switch uplinks. A backup server talking to one NAS over multiple TCP sessions is best spread by Layer 4; a pair of switches carrying thousands of inter-subnet conversations distributes acceptably with Layer 3 alone.

Configuring and verifying on IOS

SW1(config)# port-channel load-balance src-dst-ip
SW1# show etherchannel load-balance
SW1# show etherchannel summary
SW1# show etherchannel port-channel
SW1# show interfaces Port-channel1 | include rate

Two verification habits pay off. First, confirm the load-balance algorithm in both directions - the two ends of a channel do not have to match, and mismatched algorithms produce asymmetric distribution that looks like a capacity problem on one side. Second, look at per-member counters and rates rather than at the bundle total; the bundle total tells you nothing about whether the hash is spreading traffic or piling it onto one link:

SW1# show interfaces Ethernet1/1 | include rate|packets
SW1# show interfaces Ethernet1/2 | include rate|packets

Common causes of poor distribution

• Too few flows. Ten hosts to one server hashes to at most ten buckets. No algorithm fixes that except adding source ports to the hash.
• Traffic that never varies. A single encapsulated tunnel (GRE, IPsec, VXLAN with fixed outer addresses) presents one flow, because the inner headers are not hashed on many platforms unless the switch is explicitly configured for it.
• Member links that are down. A bundle with two of four members down runs at half capacity but still reports up; show etherchannel summary shows member flags individually for this reason.
• Hash algorithm unchanged after a migration. A bundle moved from switch-to-switch to server-facing roles keeps the old algorithm and distributes badly.
• Hardware limits. Some platforms offer fewer hash options per ASIC or per port group; the same configuration can behave differently across a mixed fleet.

LACP itself adds no load balancing - it negotiates and monitors membership, while the hash distributes frames. Confusing the two is the origin of most expectations that do not survive contact with production. For the bundling configuration itself see our MC-LAG failure behaviour comparison and Dell OS10 port-channel and LACP configuration; for the loss symptoms of a poorly balanced bundle see WRED versus tail drop.

原文链接：https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html