e the source MAC address to determine load balancing on Switch B, we'll end up with the same problem we were trying to solve. In this circumstance, the solution would be to have source MAC address load ancing on Switch A, and destination MAC address load balancing on Switch B. If all your servers are on one switch, and all your users are on another, as in this example, this solution will work. Unfortunately, the real world seldom provides such simple problems. A far more common scenario is that all of the devices are connected in one large switch, such as a 6509. Changing the load-balancing algorithm is done on a chas- sis-wide basis, SO with all the devices connected to a single switch, you're out of luck. Figure 7-5 shows an interesting problem. Here we have a single server connected to Switch A via an EtherChannel, and a single network attached storage (NAS) device that is also attached to Switch A via an EtherChannel. All of the filesystems for the server are mounted on the NAS device, and the server is heavily used-it's a data- base server that serves more than 5,000 users at any given time. The bandwidth required between the server and the NAS device is in excess of 2 Gbps. Server Network attached storage 10.0.0.1 10.0.0.100 00:00:0c:00:00:01 00:00:0c:00:11:11 Switch A EtherChannel EtherChannel Figure 7-5. Single server to single NAS Unfortunately, there is no easy solution to this problem. We can't use the destina- tion MAC address or the source MAC address for load balancing because in each case there is only one address, and it will always be the same. We can't use a combi- nation of source and destination MAC addresses, or the source and/or destination IP addresses, for the same reason. And we can't use the source or destination port num- bers, because once they're negotiated, they don't change. One possibility, assuming Load Balancing the drivers support it, is to change the server and/or NAS device SO that each link has its own MAC address, but the packets will still be sourced from and destined for o