By Andrew Stibbards, Sunset Learning Institute Cisco Specialized Instructor

This is the follow-on article to: ETHERCHANNEL: LACP, PAgP, AND STATIC PROTOCOLS

In my last article (EtherChannel: LACP, PAgP, and Static Protocols), I discussed the benefits and uses of EtherChannel. We looked at the Link Aggregation Control Protocol (LACP), the Port Aggregation Protocol (PAgP), and Static modes of operation. In this article, we are going to look deeper into the decision making process of EtherChannel, and how to optimize it.

To begin, the first question we ask is, “how does EtherChannel decide which physical interface will carry and individual packet?” Let’s start with a diagram:

In this diagram we have two switches, connected on their FastEthernet ports 1 through 4. We don’t have to connect port with the same number to each other; I just did this for simplicity. All four ports have been bundled into an EtherChannel. Now when this happens, the EtherChannel applies what is called an “index” to the physical interfaces participating. When traffic is going to be sent down the EtherChannel, it uses an algorithm to decide which index, and therefore which interface, will carry the traffic. The breakdown for interfaces:

The index is represented by a binary number. In our example, we have four interfaces, so on the left we have labeled the four indexes and the interfaces they were assigned to.

Now you are asking, “How did you come up with 00, 01, 10, and 11?” The answer is the algorithm in use, called XOR, or “exclusive OR.” What this does is it takes address information from the packets passing through the EtherChannel, and runs it through a hash. Then the output pattern is compared to the indexes assigned. Whichever interface’s index the pattern matches that is the interface the used. As shown in the table, when you have a certain number of interfaces participating in an EtherChannel, the switch will automatically use a set number of indexes. When you have more indexes than interfaces, the switch will assign multiple indexes to an interface. So for example if we have five interfaces participating, and eight indexes, the ratio would look something like 2:2:2:1:1, where all of the interfaces got at least one index, but then some interfaces received more until all eight were assigned. Another example would be seven interfaces, we would have a 2:1:1:1:1:1:1 ratio. Keep in mind, that is not a load-balancing or weighting. That is just the labeling of the ports from the perspective of the EtherChannel. The only time you could expect true load-balancing is if you have two, four, or eight interfaces. Any other number and you will see more traffic on the interfaces carrying multiple indexes.

So now comes the fun part. The default information that XOR uses is the Source and Destination IP addresses. This means that when we start looking at traffic being sent to a specific destination, or sourcing from a specific destination, we can might see traffic being assigned to the same links, not really being spread across all the participating interfaces. I say may, because all networks have different traffic loads and addressing, so the default parameters might work just fine in your network. But it is worth investigating. You can use the command #show etherchannel load-balance to verify what method your switch is currently using, and you can use the #port-channel load-balance XXXXX command to change the variable used. All switches that support EtherChannel can do just source or just destination based load-balancing using either MAC or IP addresses, or source and destination MAC or IP addresses. The 4500 and 6500 series can also use port numbers. In the end, use the variable that gives you the best traffic spread across your links, so it’s not bunching up on the one index that it happens to use based on the XOR.

Once you change the algorithm you can look at counters and interfaces statistics, also the #show etherchannel port-channel command to verify what indexes have been assigned to interfaces and what traffic load is being handled per interface. You may have to use the #clear counters command to reset statistics and counters after the update, in order to see what the new usage looks like. My last note on this is that when you change the EtherChannel XOR variable on a switch, you change it for all EtherChannels. You cannot change the algorithm for only one of the EtherChannels.

That about does it. You already configured your EtherChannel, using one of the negotiating protocols or maybe Static configuration, and all port are up and participating. We have the increased throughput and resiliency we were looking for. But now we can fine tune even that to guarantee we are not bottlenecking inside our EtherChannels.

Course Information and Guaranteed to Run Training Schedule 

 Authorized Cisco Routing and Switching Training 

Check Out our Blog Page for Additional Sunset Learning Instructor Blog Posts!