Lab Objective
Configure the default EtherChannel load-balancing method, observe traffic concentrating on a single link for a specific traffic pattern, then switch to a different hashing algorithm and verify traffic distributes more evenly across the bundle's member links.
Lab Purpose
EtherChannel, discussed earlier in this series, bundles multiple physical links into one logical interface, but the specific member link any given packet actually traverses is determined by a hash calculation — the wrong hashing input for a given traffic pattern can result in all traffic concentrating on a single link despite multiple links being bundled, completely defeating the purpose of load distribution.
Lab Topology
Switch1 ---- Po1 (Gi1/0/1, Gi1/0/2) ---- Switch2
Traffic pattern for this lab: many flows
between the SAME pair of hosts (Server-A and
Server-B), differing only in TCP source port
across each connectionTask 1: Verify the Default Load-Balancing Method
Check the currently active load-balancing algorithm on Switch1.
Task 2: Generate Traffic Under the Default Method
Generate multiple flows between Server-A and Server-B and observe how traffic distributes across the two bundled links.
Task 3: Change the Load-Balancing Method
Change the algorithm to one that considers Layer 4 port information rather than only Layer 3 addresses.
Task 4: Regenerate Traffic and Verify Improved Distribution
Generate the same multiple flows again and confirm traffic now spreads more evenly across both links.
Solution and Verification
Switch1# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-dst-ip
-- The default method hashes based only on
-- source and destination IP address -- since
-- every flow in this lab's traffic pattern
-- uses the exact same source/destination IP
-- pair, every flow hashes to the identical
-- result-- Multiple connections generated between
-- Server-A and Server-B:
Switch1# show interfaces gigabitethernet1/0/1 | include packets output
1,204,382 packets output
Switch1# show interfaces gigabitethernet1/0/2 | include packets output
142 packets output
-- Nearly all traffic concentrated on a
-- single member link (Gi1/0/1), despite
-- two links being bundled -- exactly the
-- problem src-dst-ip hashing creates when
-- traffic only ever flows between the same
-- IP pairSwitch1(config)# port-channel load-balance src-dst-port
-- Now hashes based on Layer 4 port numbers
-- in addition to IP addresses -- since each
-- connection in this lab's traffic uses a
-- different source port, this provides the
-- variability needed for the hash to actually
-- distribute traffic differently per flow-- Same traffic pattern regenerated:
Switch1# show interfaces gigabitethernet1/0/1 | include packets output
621,204 packets output
Switch1# show interfaces gigabitethernet1/0/2 | include packets output
598,331 packets output
-- Traffic now distributes roughly evenly
-- across both member linksKey Takeaway
EtherChannel load balancing always sends an individual flow entirely over a single member link — never splitting one flow's packets across multiple links, which would cause packet reordering — so genuine distribution across the bundle depends entirely on having enough variability in the chosen hash inputs across different flows; a hashing method poorly matched to the actual traffic pattern (such as src-dst-ip when all traffic shares the same IP pair) can silently leave most of a bundle's capacity unused.