avior vary by circumstance. Figure 7-4 shows a relatively common layout: a group of users connected to Switch A reach a group of servers on Switch B through an EtherChannel. By default, the load- balancing method will be based on the destination MAC address in each packet. The issue here is one of usage patterns. You might think that with the MAC addresses being unique, the links will be used equally. However, the reality is that it is very common for one server to receive a good deal more traffic than others. Email 10.0.0.101 10.0.0.1 00:00:0c:00:11:11 00:00:0c:00:00:01 Switch A Switch B Database 10.0.0.102 10.0.0.2 00:00:0c:00:11:12 00:00:0c:00:00:02 EtherChannel File/print 10.0.0.103 10.0.0.3 00:00:0c:00:11:13 00:00:0c:00:00:03 Sarah Archive server 10.0.0.104 10.0.0.4 00:00:0c:00:11:14 00:00:0c:00:00:04 Figure 7-4. EtherChannel load-balancing factors Let's assume that the email server in this network is receiving more than 1 Gbps of traffic, while the other servers average about 50 Mbps. Using the destination MAC address method will cause packets to be lost on the EtherChannel because every packet destined for the email server's MAC address will ride on the same physical link within the EtherChannel. Overflow does not spill over to the other links-when a physical link becomes saturated, packets are dropped. Chapter 7: EtherChannel In the case of one server receiving the lion's share of the traffic, destination MAC address load balancing does not make sense. Given this scenario, balancing with the source MAC address might make more sense. Another important idea to remember is that the load-balancing method is only applied to packets being transmitted over the EtherChannel. This is not a two-way function. While changing the method to source MAC address on Switch A might be a good idea, it would be a terrible idea on Switch B, given that the email server is the most-used server. Remember, when packets are being returned from the email server, the source MAC address is that of the email server itself. So, if we us