It is a common mistake to assume X number of ports in an etherchannel equates to the common port speed * X; however, this is grossly incorrect and I’ll attempt to explain this behavior to you in layman terms
First, you should ALWAYS combine etherchannel bonds in even numbers (2, 4, 6, or 8). Why? It is the hashing algorithm used to determine how to load balance across the Etherchannel, more to come on how that works.
Second, you need to examine the traffic patterns on your network. If you have a model where your servers live in the “core” of your office and you have access switches connecting back to the core through etherchannel, you’re likely to have a lot of different source addresses (IP and MAC address) going to a common destination address (IP and MAC address). This is especially true of a backup server solution pulling backups for all your computers in the network or for users sending their default gateway traffic to a router which has a L3 port-channel configured from the core switch, which is a common network pattern you’ll find today. Finally, you can have server-to-server traffic patterns, where the source and destination IP addresses remain constant; however, the servers are probably utilizing numerous source and destination TCP/UDP ports; thus, the Etherchannel carrying this traffic needs to be adjusted. What about if the both models are going across the same Etherchannel (clients to the server and server-to-server) and you can’t build a separate etherchannel? The only recommendation here is to examine your traffic carefully, figure out what is more effective for your organization, we won’t get into that here.
Third, you need to understand what load balancing algorithms are available to you. However, take notice, this largely depends on the equipment you’re using. If your organization, like one I have worked inside, has decided that using 3650/3750 devices as a “core” to their network, you’re limited to the basic; however, if your organization uses true core switches (4500, 6500, 6800) you have all the options available to you. I will list the options available in ALL models below
- src-ip – Source IP address only
- dst-ip – Destination IP address only
- src-dst-ip – Source and destination IP address only (XOR)
- src-mac – Source mac address only
- dst-mac – Destination mac address only
- src-dst-mac – Source and Destination mac address only (XOR)
Now, here is what you’ll find available on true core switch models, in addition to the above:
- src-port – Source port only
- dst-port – Destination port only
- src-dst-port – Source and Destination port only (XOR)
- src-dst-mixed-ip-port – Source and destination IP along with the Source and Destination ports
- src-mixed-ip-port – Source IP address and port
- dst-mixed-ip-port – Destination IP address and port
The above commands all depend on what you’re running in your infrastructure, hardware and code level. It pays to put in the appropriate devices according to their duties. If you’re using devices like a 3560/3750 as your “core” you could be out of luck considering the few options available to you with one exception, you can look at installed a 10GB module in your switch and running Etherchannel 10GbE. This WILL NOT fix the load balancing issue but it will provide you the increased bandwidth to get you through until you’re capable of installing the appropriate hardware to support your needs This is given you’re using fiber for Inter-switch links and it supports 10GbE across the distances you’re looking to span.
Understanding your traffic patterns will be a process; however, one I think a lot of you forget is about the L3 Etherchannel you could be using between your core switch and your router. Think about this, the switch resolves the next-hop default gatway and this NEVER changes; thus, destination traffic address is always the same; thus, if you want to see if you’re able to utilize that Etherchannel more appropriately, set your etherchannel to hash based on source mac address towards the router.
I won’t let this get too long, I’ll follow up with some nice diagrams later.