This post is a bit of a departure from the usual topics covered on this site, but there’s a good reason, as I’m currently studying to renew my Cisco ‘CCNP’ certification. One of the study topics covers etherchannels and the various ways in which they can be configured. I’m not going to cover what an etherchannel is etc in detail – there are plenty of resources around, such as this one. Instead, I’m going to go straight into some examples using the different negotiation modes. In my lab, I have two switches connected using two interfaces on each:
To begin with, I have the following configuration on my port channel interfaces, on both switches:
interface Port-channel1 switchport switchport trunk encapsulation dot1q switchport mode trunk ! interface Ethernet0/0 switchport trunk encapsulation dot1q switchport mode trunk duplex auto channel-group 1 mode on ! interface Ethernet0/1 switchport trunk encapsulation dot1q switchport mode trunk duplex auto channel-group 1 mode on
As it stands, all my interfaces are in the ‘On’ mode – which means that we’re not trying to negotiate an etherchannel, but are manually configuring the ports to form an etherchannel. So long as all participating interfaces are set to ‘On’, an etherchannel will be formed:
S1>sh etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Et0/0(P) Et0/1(P)
From the output of the ‘show etherchannel summary’ command we can see that a layer 2 etherchannel has been created, using et0/0 and et0/1. Note that no protocol is listed. So far, all is good. But what if I were to change the configuration so that the etherchannel was negotiated dynamically? There are two protocols used for link aggregation:
- Cisco’s proprietary Port Aggregation Protocol (PAgP).
- IEEE standard Link Aggregation Protocol (LACP)
Regardless of the protocol used, it’s important to be aware of which port configurations will work with each other. When configuring a port to be a member of a channel group there are a number of options:
S1(config-if-range)#channel-group 1 mode ? active Enable LACP unconditionally auto Enable PAgP only if a PAgP device is detected desirable Enable PAgP unconditionally on Enable Etherchannel only passive Enable LACP only if a LACP device is detected
The table below shows the configuration combinations that will result in a etherchannel being negotiated successfully, and the combinations that will result in it failing.
| Protocol | S1 Configuration | S2 Configuration | Successful Negotiation |
| PAGP | AUTO | AUTO | NO |
| DESIRABLE | AUTO | YES | |
| ON | AUTO | NO | |
| DESIRABLE | DESIRABLE | YES | |
| LACP | PASSIVE | PASSIVE | NO |
| ACTIVE | PASSIVE | YES | |
| ON | PASSIVE | NO | |
| ACTIVE | ACTIVE | YES |
To demonstrate, I have set my first switches interfaces to use PAGP Auto, and the second switch to use PAGP Auto. Looking at the ‘show etherchannel summary’ output, it shows:
Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SD) PAgP Et0/0(D) Et0/1(D)
As shown in the table using PAgP AUTO/AUTO won’t result in a etherchannel being formed. The output confirms this, with the Po1 interface marked as Po1 (SD), meaning it is down.
Changing the configuration to PAgP Desirable on one of the switches results in:
Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SU) PAgP Et0/0(P) Et0/1(P)
An etherchannel has now been formed. The state of Po1 has changed to Po1 (SU), indicating that the port channel is up. At this point, changing the configuration of the S1 etherchanel to use LACP will result in the following:
*Feb 9 09:14:07.846: %EC-5-L3DONTBNDL2: Et0/0 suspended: LACP currently not enabled on the remote port. *Feb 9 09:14:08.189: %EC-5-L3DONTBNDL2: Et0/1 suspended: LACP currently not enabled on the remote port. Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SD) LACP Et0/0(s) Et0/1(s)
The etherchannel is now down, with the error message stating that both ports are in a suspended state due to LACP not being enabled on the remote port. To remedy this issue the mode needs to be changed on one of the switches. I used ‘channel-group 1 mode active’ as the configuration on S1, so will use ‘channel-group 1 mode passive’ on S2. This results in the etherchannel being created:
Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SU) LACP Et0/0(P) Et0/1(P)
Etherchannel Load Balancing
Another thing to be aware of when configuring etherchannels is the load balancing method. Changing the load balancing policy of the switch changes how frames are distributed across the member links of an etherchannel. Depending on the switch there are a number of modes:
S1(config)#port-channel load-balance ? dst-ip Dst IP Addr dst-mac Dst Mac Addr src-dst-ip Src XOR Dst IP Addr src-dst-mac Src XOR Dst Mac Addr src-ip Src IP Addr src-mac Src Mac Addr
You can view the mode that is currently in use by running the following:
S1# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-mac
Etherchannel load balancing is documented in detail here.