Port-channel load-balance method

[Jon Eyes]

Hello Everyone,

We've been observing our aggregated link (4 x 1gbps) between our core and a stacked switch where our vm and storage are for more than a month now. And that link barely goes over 1gbps. Upon review and further reading, we discovered that our storage server (w/ bundled uplinks of 2gpbs) keeps on using the same interface member of that port-channel and will keep using it if we don't update the loadbalance method (currently src-mac).
The questions..
1. what port-channel loadbalance method should we use to be able to utilized and evenly distribute traffic across the port-channel member interface? We are planning to go 10G but if can't even show we are using more than 1G, it'll be a hard sell
2. how should we prepare to transition to a new loadbalance method and what consideration should we take note off. (ie, does all our switches' port-channel in the network needs to be updated as well?.. servers with bundled interface.. etc)

Thanks!

[MHM Cisco World]

sender -> receiver 
if Sender use same IP and same MAC 
if the receiver use same IP and same MAC
if the traffic use same L4 port 
then always the PO will use only one port member to pass traffic.
Last is Sender L4 port is it randomly change you can use it

[David Ruess]

Hello,

The load balance method is per switch and you can change it. The method you use depends on traffic and how it flows. Looking at direction of traffic flow from the stacked switch/VM to the core it will likely haev only one source mac address or src IP address....from the VM.

You can verify the load balance method with show etherchannel load-balance command.

Figure out what works for you. If several hosts access the VM maybe try Destination MAC/IP on the switch stack side since the destination is many hosts. On the core side (flowing to the stacked switch) will most likely be the one devices (depending on your network, but all we know about is the VM). If that's the only thing on the stacked switch you know it'll be 1 MAC and IP and it'll be the same one so it will use the same link for all the traffic if the load balance method is set to Destination MAC/IP on the core side.

Secondly, you will NOT have to upgrade you etherchannel links in your whole network just to plus that one up. However the ports in the same etherchannel must match everything.

Hope that helps

-David.

[Jitendra Kumar]

You can take help from the below tutorial however very useful.

https://youtu.be/FFyatmaGiN0

[Joseph W. Doherty]

"currently src-mac"

Is that on the switch and/or the host(s) (?) also using port-channel?  (BTW, at least on Cisco devices, keep in mind, a device's load-balance choice only impacts egress traffic on the port-channel.  I.e. you may need to update two devices.)

(Also BTW, if src-mac is being used on the Cisco switch, what Cisco switch is this?  Reason I ask, load-balance defaults and possible choices vary per Cisco platform.  [Old Cisco switches, I recall, used to default to src-mac, believe newer Cisco switches often use a different default.])

#1 It depends on the attributes of your traffic.  What you want, is the fields being used for distribution, to be different between different flows.  Often good generic choices are based on using both destination and source fields, such a src-dest-ip or src-dest-mac (the former, often a bit better than the latter).

#2 Again, choice should be based on traffic mix of your flows.  Also again, a src-dest combo often works well in many cases.

Note: multiple flows, between applications, between a pair of hosts, is often problematic as src and dest address fields are the same for the multiple flows.  Some/few (Cisco) switches offer an option to use UDP/TCP port numbers, which should differ between multiple flows between a pair of hosts.

As to changing load balance choices, I've done it many, many times during live production hours as the change is generally so quick, most applications are not adversely impacted.  But a safer approach would be to do during least business volume hours or during scheduled maintenance.