Hands-On Lab: Configuring EtherChannel Load-Balancing Methods

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 connection

Task 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 pair

Switch1(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 links

Key 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.