Link Aggregation on IOS-XE
Most readers studying for the CCNP-SP will already be familiar with link aggregation on IOS-XE switching platforms, so this article will serve as a brief refresher.
When configuring link aggregation, you add member interfaces to a port-channel using the following command:
When first creating a port-channel, the port-channel will inherit the config of the member interface. When adding additional configuration to an existing port-channel, you do it under the port-channel, and the member interfaces will automatically inherit the configuration. If you configure a member interface sparately, the interface’s config will not align with the port-channel and it will be removed from the port-channel.
Modes
There are five port-channel modes:
Mode
Description
Active
LACP, the switch will actively send LACP discovery frames
Passive
LACP, the switch will passively watch for LACP discovery frames
Desirable
PAgP (Cisco proprietary), the switch will actively send PAgP discovery frames
Auto
PAgP (Cisco proprietary), the switch will passively watch for PAgP discovery frames
On
Unconditional aggregation. No protocol is used for link monitoring.
As you probably know, port-channel that uses passive can only form an LACP port-channel with a neighboring switch using active. The same logic applies for a switch using auto - it can only form a port-channel with a switch using desirable. Two switches using active or two switches using desirable can form a port-channel.
Load Balancing
A single flow can only use one link in a port-channel. So while a port-channel increases your bandwidth, a single flow can only ever achieve the bandwidth provided by a single link.
The load balancing method determines what factors a switch uses to run a hashing algorithm and distribute flows across multiple links. On most platforms you can use any combinition of src/dst mac/IP/layer4-port.
The load balancing method is not signaled in LACP or PAgP control frames, so it does not need to match on each switch. It is a local function.
LACP Priorities
During LACP negotiation, two LACP systems elect a “master” switch by using the lowest LACP system priority. If the priorities are the same, the lowest MAC address is used. (This is similar to other layer 2 technologies).
The “master” LACP switch is responsible for selecting the member interfaces that will be used in the port-channel. In situations where there are more member interfaces than allowed in the port-channel, interfaces with higher port priorities will be placed in “hot standby” mode. The default port priority is also 32768.
The system priority is set using the following command:
A port’s priority is set using the following command:
To demonstrate how this works, consider the following configuration:
SW1 will be the LACP master because it has a lower LACP system priority. Both switches have three links configured for the port-channel, but the port-channel can only have a max of two links. SW1 will select its port with the worst priority and place it in hot standby mode, which is Gi0/2. Even though SW2’s Gi0/2 has a better port-priority than Gi0/1, this doesn’t matter, because SW1 is the master, so it is the one that dictates which link is placed in hot standby mode.
What causes an LACP port-channel to not come up?
In general, nothing really needs to “match” for an LACP port channel to come up between two devices. One side can use slow rate PDUs (30 seconds) and one side can use fast rate PDUs (1 second), etc. The only thing that really needs to match is the partner's system ID among all member interfaces. (This is why MLAG requires the same LACP system ID on each chassis).
You may come across articles that state that you must have both port-channels be a trunk, with both having the same allowed vlan list, or both be in access mode, etc.
However, I’ve found that this is not true. I see nowhere in the LACP frame that the VLAN list is signaled. I believe people are confused with the fact that member interfaces must all have the same configuration. But two switches can put their port-channel in different VLANs, or have one side access and one side trunk, and the port-channel works just fine.
It’s true that you will see CDP native VLAN mismatch syslog messages, but the port-channel still works fine.
This is such a common misconception that in a test, if “native VLAN mismatch” was the only compelling answer to a port-channel troubleshooting question, I would reluctantly select that as the answer!
Further Reading
Last updated