CCNP: The Inner Workings of EtherChannel
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One of the coolest features I have ever configured on a Cisco switch has to be, hands down, an EtherChannel. What is EtherChannel, you ask?
EtherChannel is a link aggregation technology. Imagine how cool it would be to group multiple physical Ethernet links into a single fault-tolerant high-speed link to another switch, router, or server. That is exactly what EtherChannels do; these new links have numerous advantages, the most desirable of which is speed. In close second comes their ability to work at Layer 2 or Layer 3 of the OSI model, and the fact that all Cisco switches have the ability to support them. There is a lot of inner working when it comes to these aggregate links, and we are to going to explore all of them, including link control protocols, configuration, and troubleshooting.
Link Aggregation Protocols
As mentioned earlier, EtherChannel actually aggregates individual Ethernet links into a single logical link that provides bandwidth up to 1600 Mbps, in the case of Fast Ethernet, or 16 Gbps when Gigabit interfaces are used to create the logical link. The restriction, however, is that all the bundled interfaces must be configured with matching speed and duplex settings, and both ends of each link must be configured as either a Layer 2 or Layer 3 interface.
If an individual link within an EtherChannel bundle fails, traffic previously carried over the failed link is carried over the remaining links within the EtherChannel.
An EtherChannel can be configured in one of these two dynamic modes:
- Port Aggregation Protocol (PAgP) is a Cisco proprietary protocol used to automate the logical aggregation of Ethernet switch ports. This means PAgP can only be used between Cisco switches.
- Link Aggregation Control Protocol (LACP) is an industry standard protocol designed to automate the logical aggregation ethernet ports. Also know by its IEEE designation 802.3ad LACP is not tied to any specific vendor.
Port Aggregation Protocol (PAgP)
As we have already discussed, PAgP packets are sent between EtherChannel capable ports to facilitate the negotiation needed for the successful creation of a channel. When PAgP sees matched Ethernet links, it will group the links into an EtherChannel.
PAgP uses three modes of operation:
- Auto—places an interface into a passive negotiating state, meaning that the interface will respond to PAgP packets it receives but it will not initiate PAgP packet negotiation. This setting minimizes the transmission of PAgP packets and is the default on devices like Catalyst 3560.
- Desirable—places an interface into an active negotiating state, meaning that the interface will start negotiations with other interfaces by sending PAgP packets.
- On—forces the interface to channel without PAgP. With the on mode, a usable EtherChannel exists only when an interface group in the on mode is connected to another interface group in the on mode. This is referred to as static aggregation.
Link Aggregation Control Protocol (LACP)
LACP performs the exact same function as the Cisco proprietary PAgP but it does it by sending LACP packets to its peer. Because LACP is an IEEE standard, it can be used to facilitate EtherChannels in mixed vendor environments.
LACP, like PAgP, has three modes of operation:
- Passive— The switch does not initiate the channel, but does respond to incoming LACP packets. When a peer initiates negotiation (by sending out an LACP packet) which we receive and reply to, eventually forming the aggregation channel with the peer. This is similar to the auto mode in PAgP.
- Active—We are willing to form an aggregate link and will actively seek to start the negotiation. The link aggregate will be formed if the other end is running in LACP active or passive mode. This is similar to the desirable mode of PAgP.
- On—A link aggregation is forced to be formed without any LACP negotiation. In other words, the switch will neither send the LACP packet nor process any incoming LACP packet. This is similar to the on state for PAgP. Again, this is referred to as static aggregation.
Forming an EtherChannel
Based on the information we have been presented thus far, it is obvious that there must be specific modes on each end of a link to allow an EtherChannel to form. We can see below exactly what mode combinations in each Aggregation Protocol will trigger the formation of a channel-group:
|
|
LACP |
|
|
|
PAgP |
|
|
|
Active |
Passive |
|
|
Desirable |
Auto |
|
Active |
–Yes– |
–Yes– |
|
Desirable |
–Yes– |
–Yes– |
|
Passive |
–Yes– |
–No– |
|
Auto |
–Yes– |
–No– |
Where ever we see a value of –Yes– we know that an EtherChannel will form based on the mode of the distant end.
Static EtherChannels
There are several advantages to using dynamic aggregation protocols over static configuration of EtherChannels. The most significant is that a device can confirm that the configuration at the other end is capable of link aggregation, when we use dynamic protocols, add to this the fact that LACP and PAgP both can detect cabling or a configuration mistake, while a static link configuration cannot and as a result packet loss or spanning-tree errors can occur. This is important, and you should always exercise care when setting the EtherChannel mode to on.
Configuration
We only need a single command line to configure a group of ports to operate as an EtherChannel:
SW1(config)# interface range f0/23 -24 SW1(config-if-range)# channel-group 23 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 SW1(config-if-range)# channel-group 23 mode active Creating a port-channel interface Port-channel 23
As expected, we have successfully created the logical interface Port-channel23. Note that any switchport configurations applied to this virtual interface will be replicated to the physical member interfaces. We can verify the configuration and the status of an EtherChannel by using the 'show EtherChannel summary' command:
SW1# show 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 Po23(SD) LACP Fa0/23(D) Fa0/24(D)
We see that this link is Layer 2 and it is down (SD), this is because the other end has not been configured. Once we configure the other end of the link as LACP passive or active the EtherChannel will transition to a status of 'up'. We will see console messages appear once LACP has negotiated the aggregate link:
%LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to up %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to up %LINK-3-UPDOWN: Interface Port-channel23, changed state to up
It may take several seconds before the Port-channel itself comes up. But once it does, a 'show EtherChannel summary' will reveal that the EtherChannel is "in use":
SW1# show 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 Po23(SU) LACP Fa0/23(P) Fa0/24(P)
We see immediately everything we would expect.
Conclusion
EtherChannels are easily configured and offer us a lot of capabilities. They provide an ability to increase the available bandwidth connecting multiple switches. They bring with them aggregation protocols that protect us from misconfiguration and cabling errors, while providing fault-tolerant connectivity in the ethernet fabric of our network.