nly one of those addresses. The only solutions for this problem are manual load balancing or faster links. Split- ting the link into four 1 Gbps links, each with its own IP network, and mounting different filesystems on each link will solve the problem. However, that's too compli- cated for my tastes. A better solution, if available, might be to use a faster physical link, such as 10 Gbps Ethernet. Configuring and Managing EtherChannel The device on the other end of the EtherChannel is usually the determining factor in how the EtherChannel is configured. One design rule that must always be applied is that each of the links participating in an EtherChannel must have the same configu- ration. The descriptions can be different, but each of the physical links must be the same type and speed, and they must all be in the same VLAN. If they are trunks, they must all be configured with the same trunk parameters. EtherChannel Protocols EtherChannel will negotiate with the device on the other side of the link. Two protocols are supported on Cisco devices. The first is the Link Aggregation Control Protocol (LACP), which is defined in IEEE specification 802.3ad. LACP is used when connecting to non-Cisco devices, such as servers. As an example, Solaris will negoti- ate with a Cisco switch via LACP. The other protocol used in negotiating EtherChannel links is the Port Aggregation Control Protocol (PAgP), which is Cisco-proprietary protocol. Since PAgP is Cisco-proprietary, it is used only when connecting two Cisco devices via an EtherChannel. Each protocol supports two modes: a passive mode (auto in PAgP and passive in LACP), and an active mode (desirable in PAgP and active in LACP). Alternatively, you can set the mode to on, thus forcing the creation of the EtherChannel. The available protocols and modes are outlined in Figure 7-6. Generally, when you are configuring EtherChannels between Cisco switches, the ports will be EtherChannels for the life of the installation. Setting all interfaces in the EtherChannel on both sides 