Skip to main content

L2 EtherChannel

Introduction to link aggregation

image.pngSTP blocking redundant links to prevent loops

EtherChannel

EtherChannel is a link aggregation technology that groups multiple physical Ethernet links together into one single logical link. It is used to provide fault-tolerande, load-sharing, increased bandwidth, and redundancy between switches, routers, and servers. EtherChannel technology makes it possible to combine a certain number of physical links between the switches to increase the overall speed of switch-to-switch communication.

When an EtherChannel is configured, the resulting virtual interface is called a port channel. The physical interfaces are bundled together into a port channel interface:

image.pngHow EtherChannel works

Advantages of EtherChannel
  • Most configuration tasks can be done on the EtherChannel interface instead of on each individual port, ensuring configuration consistency throughout the links.
  • EtherChannel relies on existing switch ports. There is no need to upgrade the link to a faster and more expensive connection to have more bandwidth.
  • Load balancing takes place between links that are part of the same EtherChannel. Depending on the hardware platform, one or more load-balancing methods can be implemented. These methods include source MAC and destination MAC load balancing, or source IP and destination IP load balancing, across the physical links.
  • EtherChannel creates an aggregation that is seen as one logical link. When several EtherChannel bundles exist between two switches, STP may block one of the bundles to prevent switching loops. When STP blocks one of the redundant links, it blocks the entire EtherChannel. This blocks all the ports belonging to that EtherChannel link. Where there is only one EtherChannel link, all physical links in the EtherChannel are active because STP sees only one (logical) link.
  • EtherChannel provides redundancy because the overall link is seen as one logical connection. Additionally, the loss of one physical link within the channel does not create a change in the topology. Therefore, a spanning tree recalculation is not required. Assuming at least one physical link is present; the EtherChannel remains functional, even if its overall throughput decreases because of a lost link within the EtherChannel.

Autonegotiation protocols

EtherChannels can be formed through negotiation using one of two protocols, Port Aggregation Protocol (PAgP) or Link Aggregation Control Protocol (LACP). These protocols allow ports with similar characteristics to form a channel through dynamic negotiation with adjoining switches.

It is also possible to configure a static or unconditional EtherChannel without PAgP or LACP.

PAgP

Cisco-proprietary protocol that aids in the automatic creation of EtherChannel links. When an EtherChannel link is configured using PAgP, PAgP packets are sent between EtherChannel-capable ports to negotiate the forming of a channel. When PAgP identifies matched Ethernet links, it groups the links into an EtherChannel. The EtherChannel is then added to the spanning tree as a single port.

When enabled, PAgP also manages the EtherChannel. PAgP packets are sent every 30 seconds. PAgP checks for configuration consistency and manages link additions and failures between two switches. It ensures that when an EtherChannel is created, all ports have the same type of configuration.

PAgP helps create the EtherChannel link by detecting the configuration of each side and ensuring that links are compatible so that the EtherChannel link can be enabled when needed. The modes for PAgP as follows:

  • PAgP desirable - This PAgP mode places an interface in an active negotiating state in which the interface initiates negotiations with other interfaces by sending PAgP packets.
  • PAgP auto - This PAgP mode places an interface in a passive negotiating state in which the interface responds to the PAgP packets that it receives but does not initiate PAgP negotiation.

The modes must be compatible on each side. If one side is configured to be in auto mode, it is placed in a passive state, waiting for the other side to initiate the EtherChannel negotiation. If the other side is also set to auto, the negotiation never starts and the EtherChannel does not form.

The table shows the various combination of PAgP modes between two switches and the resulting channel establishment outcome:

image.pngPAgP

LACP

LACP is part of an IEEE specification (802.3ad) that allows several physical ports to be bundled to form a single logical channel. LACP allows a switch to negotiate an automatic bundle by sending LACP packets to the other switch. It performs a function similar to PAgP with Cisco EtherChannel. Because LACP is an IEEE standard, it can be used to facilitate EtherChannels in multivendor environments. On Cisco devices, both protocols are supported.

LACP was originally defined as IEEE 802.3ad. However, LACP is now defined in the newer IEEE 802.1AX standard for local and metropolitan area networks.

LACP provides the same negotiation benefits as PAgP. LACP helps create the EtherChannel link by detecting the configuration of each side and making sure that they are compatible so that the EtherChannel link can be enabled when needed. The modes for LACP are as follows:

  • LACP active - This LACP mode places a port in an active negotiating state. In this state, the port initiates negotiations with other ports by sending LACP packets.
  • LACP passive - This LACP mode places a port in a passive negotiating state. In this state, the port responds to the LACP packets that it receives but does not initiate LACP packet negotiation.

Just as with PAgP, modes must be compatible on both sides for the EtherChannel link to form.

LACP allows for eight active links, and also eight standby links. A standby link will become active should one of the current active links fail.

The table shows the various combination of LACP modes between two switches and the resulting channel establishment outcome:

image.pngLACP

Manual configuration

For manual configuration of L2 EtherChannels, that is, without using autonegotiation protocols (PAgP/LACP), use the on mode.

The on mode manually places the interface in an EtherChannel, without any negotiation. It works only if the other side is also set to on. If the other side is set to negotiate parameters through PAgP/LACP, no EtherChannel forms, because the side that is set to on mode does not negotiate. Interfaces configured in the on mode do not exchange PAgP/LACP packets.

No negotiation between the two switches means there is no checking to make sure that all the links in the EtherChannel are terminating on the other side, or that there is PAgP/LACP compatibility on the other switch.

Guidelines for configuring EtherChannel

  • PAgP is Cisco-proprietary and not compatible with LACP.
  • LACP is defined in 802.3ad.
  • It is not required that the interfaces are physically contiguous.
  • A max. of 48 EtherChannels are supported on a switch or switch stack.
  • A single PAgP EtherChannel can be made by combining anywhere from 2 to 8 parallel links.
  • A single LACP EtherChannel can be made by combining up to 16 Ethernet ports of the same type. Up to 8 ports can be active and up to 8 ports can be in standby mode.
  • All ports in the EtherChannel must be identical:
    • Same speed/duplex
    • Range of VLANs
    • Cannot mix Fast Ethernet and Gigabit Ethernet
    • Cannot mix PAgP and LACP in a single EtherChannel
    • Can have PAgP and LACP EtherChannels on the same switch, but each must be exclusively PAgP or LACP
    • Must all be VLAN trunk or nontrunk operational status (cannot mix access and trunk links on the same EtherChannel)

If these settings must be changed, configure them in port channel interface configuration mode. Any configuration that is applied to the port channel interface also affects individual interfaces. However, configurations that are applied to the individual interfaces do not affect the port channel interface. Therefore, making configuration changes to an interface that is part of an EtherChannel link may cause interface compatibility issues.

Back to top