best trunk load balancing method

[robertkwild]

hi all,

atm i have set up a trunk from a 7000 to a SG300 and its working (see pic) this end is from the SG300

as you can see all 3 cables are active so im happy its working correctly

a question regarding whats the best method for load balancing to use, is it this or can i use some other methods, also i imagine if i change this side i need to change the 7000 side aswell?

basically i want best for whatever KVM uses

thanks,

rob

[Reza Sharifi]

Hi Rob,

Not sure what are the available options on the SG300, as I am not familiar with that series, but usually scr-des-mac is the default for layer-2 switches, and that should work fine on both sides.

HTH

[Joseph W. Doherty]

". . . also i imagine if i change this side i need to change the 7000 side aswell?"

Maybe, maybe not.  It depends on what the defaults are for your devices, what choices the switches actually offer/provide and what's the best choice for your traffic.

The forgoing also applied not only to your latter part of your question, but to your primary question, what's the best choice (on your first switch).

Ideally, you want whatever you're using, to feed the hash, vary as much a possible, per different flows.

As Reza suggested, choices which include both source and destination attributes, generally work well.

Again, to be clear, what choices a device supports, can vary between devices, and what they might use for their default, can also vary per device.

[Elliot Dierksen]

You really have to think about your traffic patterns as well as the capabilities of the device doing the load balancing. Most devices default to some sort of destination mac address and/or IP address. That is great in most situations, but not if you have a port channel to a NAS devices. All the destinations will be the same, so your distribution won't be very good. That means the switch facing the NAS would want to load balance based on source. The NAS would want to load balance based on destination. It just depends on the use case.