EtherChannel and Link Aggregation: LACP, PAgP, and When STP Blocks Half Your Bandwidth
Spanning Tree Protocol is good at exactly one thing: preventing Layer 2 loops. What it is not good at is letting you use every link you paid for. In a standard redundant topology with two uplinks between an access switch and a distribution switch, STP will block one of them. The blocked link sits idle, providing failover protection but contributing zero bandwidth until its partner fails. For an access switch with a single 1 Gbps uplink, this means your maximum throughput is capped at 1 Gbps regardless of how many physical cables you run. Add a second cable and you still get 1 Gbps — the second link is blocked. Add a third and you still get 1 Gbps. STP is the answer to the loop problem but it introduces a bandwidth ceiling that feels arbitrary once you understand what is happening.
EtherChannel solves this by presenting multiple physical links to STP as a single logical interface. Instead of seeing two 1 Gbps links between two switches and blocking one, STP sees a single 2 Gbps port-channel and has nothing to block. Both physical links carry traffic simultaneously. From the spanning tree’s perspective there is no redundant path; from the network’s perspective there are two physical paths that together provide double the bandwidth and survive the failure of either individual member. This is the core insight behind link aggregation: hide the redundancy from STP by combining the links into a single logical entity before STP ever sees them.
What Problem EtherChannel Actually Solves
Before getting into the mechanics, it helps to be precise about what EtherChannel is solving and what it is not.
The bandwidth ceiling is the most visible problem. A distribution-to-core uplink carrying aggregated traffic from dozens of access switches can easily saturate a single 10 Gbps link. Before moving to 40 Gbps or 100 Gbps optics, bundling four 10 Gbps interfaces into a 40 Gbps port-channel is a common and cost-effective intermediate step. The same logic applies at any tier of the hierarchy.
The STP blocking problem is related but distinct. Without EtherChannel, multiple physical links between the same pair of switches will always result in STP blocking all but one. This is correct behavior — STP is doing exactly what it should to prevent loops. But the consequence is that you have purchased and cabled redundant links that do not contribute to capacity under normal operation. EtherChannel changes the STP topology so that redundancy and capacity are not mutually exclusive.
There is a third benefit that gets less attention: fast failover. When a port-channel member fails, the remaining members absorb the traffic in milliseconds — at the link level, not at the STP convergence level. STP reconvergence, even with Rapid PVST+, involves negotiation and state transitions that take hundreds of milliseconds to seconds. An EtherChannel member failure does not trigger STP reconvergence at all from the rest of the network’s perspective, because the port-channel interface stays up as long as any member link is operational. Traffic redistributes across surviving members at hardware speed.
The honest constraint to understand upfront: EtherChannel provides aggregated bandwidth across multiple flows, not across a single flow. A single TCP connection cannot exceed the bandwidth of one member link, because a single flow hashes to a single physical interface within the bundle. If your workload is dominated by a few very large single flows, EtherChannel helps much less than its aggregate bandwidth implies. This is covered in detail in the load-balancing section below.
The Three Formation Modes: LACP, PAgP, and Static
EtherChannel can form through negotiation or through static configuration. There are three modes: IEEE 802.3ad LACP, Cisco proprietary PAgP, and manual static (on mode). Understanding when to use each requires understanding what each does.
LACP: The Open Standard
LACP (Link Aggregation Control Protocol) is defined in IEEE 802.3ad, later incorporated into IEEE 802.1AX. It is the modern standard for link aggregation and the right choice for any network that may include non-Cisco equipment. Cisco, Juniper, Arista, Cumulus, Linux bonding, and virtually every managed switch vendor support LACP. Unifi switches support it. MikroTik supports it. Netgear smart switches with LACP capability support it. If you are building a homelab and your switches are a mix of whatever you could afford, LACP is the protocol that will actually work.
LACP exchanges PDUs (LACPDUs) between adjacent switches to negotiate and maintain the port-channel. The PDUs are sent to the multicast destination MAC 01:80:C2:00:00:02 (the slow protocols address). Each side advertises its LACP system priority (16-bit value), system MAC address, port priority (16-bit), port key (encoding speed and duplex), and a set of state flags indicating whether the port is active, aggregatable, synchronized, and collecting/distributing traffic.
The negotiation works on the concept of “activity.” LACP defines two modes per port:
- Active: The port sends LACPDUs regardless of what the neighbor does. It initiates negotiation.
- Passive: The port only responds to LACPDUs received from the other end. It does not initiate.
The compatibility rule is straightforward: at least one side must be active. Two passive ports facing each other will never negotiate a channel. Active-active works. Active-passive works. Passive-passive does not.
LACP also supports a system priority and port priority concept that governs which ports are selected into the active bundle when more physical ports are configured in the channel-group than the maximum allowed (typically 8 active plus 8 standby hot-spare ports). The port with the lower LACP port priority is preferred for inclusion in the active bundle.
PAgP: The Cisco Proprietary Protocol
PAgP (Port Aggregation Protocol) is Cisco proprietary and predates LACP. It has the same goal — negotiate EtherChannel formation between adjacent switches — but it only works between Cisco devices. You will not find PAgP support on a Ubiquiti switch or a Linux bonded interface. The CCNA still tests PAgP because Cisco networks have used it for decades and you will encounter it on legacy equipment.
PAgP modes use different terminology than LACP:
- Desirable: The port actively sends PAgP packets, initiating negotiation. The PAgP equivalent of LACP active.
- Auto: The port responds to PAgP packets but does not initiate. The PAgP equivalent of LACP passive.
Analogously, desirable-desirable works, desirable-auto works, and auto-auto does not form a channel.
PAgP has a “silent” mode concept worth knowing: PAgP considers a port “silent” if it has been connected and no PAgP packets have been received for a period. In silent mode, PAgP will still bundle the port even though no PAgP response was received, which is useful for connecting to devices that do not run PAgP (a server, for example). The non-silent keyword overrides this behavior and requires actual PAgP negotiation before adding a port to the bundle.
Static On Mode
The channel-group X mode on configuration creates an EtherChannel without any negotiation protocol. Both sides are configured manually to use the same channel-group number. No LACP or PAgP PDUs are exchanged. The ports simply assume they are part of a bundle.
Static mode is operationally risky. When negotiation protocols are running, the protocol detects configuration mismatches and refuses to form the channel — protecting you from misconfigured bundles that would silently corrupt traffic. With static mode, if one side believes it has a port-channel but the other side does not, you get a forwarding loop or traffic blackhole with no warning. For this reason, static mode is generally not recommended in production. Its primary use case is connecting to a device that does not support LACP or PAgP — a specific type of load balancer or a network appliance whose driver speaks raw 802.3ad without the control protocol.
Comparison Table
| Feature | LACP (802.3ad) | PAgP | Static (On) |
|---|---|---|---|
| Standard | IEEE 802.3ad / 802.1AX | Cisco proprietary | N/A |
| Multi-vendor | Yes | Cisco only | Depends on device |
| Negotiation | Yes | Yes | No |
| Modes | Active / Passive | Desirable / Auto | On |
| Mismatch detection | Yes | Yes | No |
| Max active members | 8 (+ 8 standby) | 8 | 8 |
| Homelab compatible | Yes (widely) | Limited | Varies |
| Recommended | Yes | Legacy only | Avoid if possible |
Negotiation Matrix: Who Initiates, Who Responds
The mode on each side determines whether a channel forms. Getting this wrong is one of the most common reasons a port-channel never comes up. The matrix below shows the outcome for each combination.
LACP Matrix:
| Local \ Remote | Active | Passive | On |
|---|---|---|---|
| Active | Channel forms | Channel forms | No channel (incompatible) |
| Passive | Channel forms | No channel | No channel (incompatible) |
| On | No channel | No channel | Channel forms (no LACP) |
PAgP Matrix:
| Local \ Remote | Desirable | Auto | On |
|---|---|---|---|
| Desirable | Channel forms | Channel forms | No channel (incompatible) |
| Auto | Channel forms | No channel | No channel (incompatible) |
| On | No channel | No channel | Channel forms (no PAgP) |
The key rule: LACP and PAgP modes cannot be mixed with static on mode. A port in LACP active mode facing a port in static on mode will not form a channel. The negotiation protocol expects to exchange PDUs and receives silence. If you must connect to a static-only device, both ends must be on. If you have any choice in the matter, use LACP active on both ends — it is the most explicit and compatible configuration.
Layer 2 vs Layer 3 EtherChannel
EtherChannel can operate as either a Layer 2 or a Layer 3 interface, and the distinction matters significantly for where it fits in your network design.
Layer 2 Port-Channel
A Layer 2 port-channel is a logical switch interface. The physical member ports are configured as switchports (access or trunk), and the port-channel interface inherits their switchport configuration. STP runs on the port-channel interface, not on the individual member ports. MAC learning occurs at the port-channel level. From every other switch and device in the network, the port-channel looks and behaves like a single switch interface.
+----------+ Gi0/1 (member) +----------+
| |-----------------| |
| SW-ACC | Gi0/2 (member) | SW-DIST |
| |-----------------| |
+----------+ Port-channel1 +----------+
(logical trunk)
The member ports carry no individual STP role — they are subsumed into the port-channel. show spanning-tree will show Po1 (Port-channel 1) as the interface, not Gi0/1 or Gi0/2. This is fundamental to why EtherChannel defeats STP blocking: there is only one logical link for STP to evaluate.
Layer 3 Port-Channel
A Layer 3 port-channel is a routed interface. Instead of being a switchport carrying VLANs, the port-channel interface is assigned an IP address and participates directly in routing. The physical member ports are converted from switchport to routed mode with no switchport, then added to the channel-group. The port-channel interface receives an IP address just like any other routed interface.
SW-CORE(config)# interface port-channel 1
SW-CORE(config-if)# no switchport
SW-CORE(config-if)# ip address 10.0.0.1 255.255.255.252
SW-CORE(config)# interface GigabitEthernet0/1
SW-CORE(config-if)# no switchport
SW-CORE(config-if)# channel-group 1 mode active
SW-CORE(config)# interface GigabitEthernet0/2
SW-CORE(config-if)# no switchport
SW-CORE(config-if)# channel-group 1 mode active
Layer 3 EtherChannel is common between distribution and core switches in a three-tier campus architecture where the distribution-to-core links are routed. The port-channel as a routed interface participates in OSPF, EIGRP, or static routing, and load balancing across the bundle is handled by the same load-balancing algorithms as Layer 2 EtherChannel. STP is not relevant on a Layer 3 port-channel because routed interfaces do not participate in spanning tree.
Load-Balancing Algorithms: Where the Bandwidth Actually Goes
EtherChannel does not stripe bytes across member links like RAID-0 stripes bytes across disks. It distributes entire flows — individual conversations identified by some combination of source/destination addresses or ports — to member links using a hash function. All packets belonging to a single flow take the same path through the bundle. This preserves packet ordering within a flow (critical for TCP) and ensures that related packets arrive at the destination in sequence.
The hash input determines which flow gets mapped to which link. Cisco IOS supports several hash methods, and choosing the right one for your traffic profile significantly affects how evenly the load distributes.
Available Load-Balancing Methods
| Method | Input to Hash | Best For |
|---|---|---|
src-mac |
Source MAC address | Traffic from many different hosts to fewer destinations |
dst-mac |
Destination MAC address | Traffic from one source to many different hosts |
src-dst-mac |
XOR of source + destination MAC | General Layer 2 traffic with diverse source-destination pairs |
src-ip |
Source IP address | Many different source IPs to fewer destinations |
dst-ip |
Destination IP address | One source to many different destinations |
src-dst-ip |
XOR of source + destination IP | General-purpose IP traffic; default on most platforms |
src-port |
Source TCP/UDP port | Flows with different source ports from same IP |
dst-port |
Destination TCP/UDP port | Less common; use when destination ports differentiate flows |
src-dst-port |
Source and destination ports | Maximizes diversity when IPs are few but ports vary |
The platform support for these methods varies. Not all Cisco platforms support all methods. The port-channel load-balance command tells you what is available.
How the Hash Works
The hash is computed on the selected fields and then reduced to select a member link. For a two-member port-channel, only the last bit of the hash result matters: even hash = link 1, odd hash = link 2. For a four-member port-channel, the last two bits matter, giving four possible buckets. For an eight-member port-channel, three bits, eight buckets.
This matters because poor hash distribution can be invisible. Consider a two-member EtherChannel with src-dst-ip load balancing connecting a hypervisor host to a switch. If the hypervisor runs ten virtual machines but all of them talk to the same NFS storage server, every flow has a different source IP but the same destination IP. Whether those map to two different links depends on whether the hash results land in both odd and even buckets. In a worst case, all ten flows happen to produce even hash results and all traffic goes to one member link while the other sits idle. The port-channel is “up” and “fully functional” — it just happens to be unbalanced.
Choosing a Method
The practical decision tree is short. If your traffic is IP (it almost certainly is), use src-dst-ip as the default. It distributes based on both ends of the conversation, which works well for most traffic mixes. If you have traffic with very few unique source or destination IPs — storage traffic between a handful of servers and a NAS array, for example — switch to src-dst-port to get more hashing diversity from the port number fields. If you are dealing with Layer 2 traffic without IP (uncommon in modern networks), use src-dst-mac.
! Verify current load-balance method
SW-A# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
src-dst-ip
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
IPv4: Source XOR Destination IP address
IPv6: Source XOR Destination IP address
! Change the method globally
SW-A(config)# port-channel load-balance src-dst-ip
! On some platforms you can check the predicted hash for a given flow
SW-A# test etherchannel load-balance interface port-channel 1 ip 10.0.1.1 10.0.2.1
! Returns which member interface would carry this flow
The load-balance method is global on most Cisco IOS platforms — it applies to all port-channels on the device, not just one. This is a notable limitation if you have port-channels carrying different types of traffic that would benefit from different hash inputs.
ASCII Topology: Two Switches with a Bundled Uplink
+------------------+
| SW-ACCESS |
| |
| Gi0/1 (member) |
| Gi0/2 (member) |
| Po1 (logical) |
+----+------+------+
| |
Gi0/1 | | Gi0/2
(link1)| |(link2)
| |
+----+------+------+
| SW-DIST |
| |
| Gi0/1 (member) |
| Gi0/2 (member) |
| Po1 (logical) |
+------------------+
STP view: SW-ACCESS
|
[Po1] <-- single link, nothing to block
|
SW-DIST
Physical reality: SW-ACCESS
/ \
Gi0/1 Gi0/2 <-- both active, both forwarding
\ /
SW-DIST
Both physical links carry traffic. STP sees one logical interface. If either physical link fails, the port-channel remains up and traffic shifts to the surviving member in hardware time, with no STP reconvergence required.
IOS Configuration: Building the Port-Channel
The configuration sequence matters. The port-channel interface should be configured first (or the physical ports need to match exactly). The channel-group command on the physical interfaces binds them to the logical port-channel.
Layer 2 Trunk Port-Channel (LACP Active)
! --- SW-ACCESS ---
! Create and configure the port-channel interface first
interface port-channel 1
description EtherChannel-to-SW-DIST
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,99,999
switchport nonegotiate
spanning-tree guard loop
no shutdown
! Add physical members -- configuration on members must match port-channel
interface GigabitEthernet0/1
description EC-member-to-SW-DIST
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,99,999
switchport nonegotiate
channel-group 1 mode active
no shutdown
interface GigabitEthernet0/2
description EC-member-to-SW-DIST
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,99,999
switchport nonegotiate
channel-group 1 mode active
no shutdown
! --- SW-DIST ---
interface port-channel 1
description EtherChannel-to-SW-ACCESS
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,99,999
switchport nonegotiate
spanning-tree guard root
no shutdown
interface GigabitEthernet0/1
description EC-member-to-SW-ACCESS
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,99,999
switchport nonegotiate
channel-group 1 mode active
no shutdown
interface GigabitEthernet0/2
description EC-member-to-SW-ACCESS
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,99,999
switchport nonegotiate
channel-group 1 mode active
no shutdown
Both sides are LACP active. Either side would also work with passive, since the other side is active. Using active on both ends is more explicit and eliminates the possibility of a passive-passive mismatch if one side is reconfigured.
Layer 2 Port-Channel with PAgP (Legacy Reference)
! PAgP desirable on both ends (or desirable + auto)
interface GigabitEthernet0/1
channel-group 1 mode desirable
interface GigabitEthernet0/2
channel-group 1 mode desirable
Use only when connecting to legacy Cisco equipment that predates LACP support. On any switch that supports LACP (virtually all modern Cisco IOS releases), prefer LACP.
Layer 3 Port-Channel
! Routed port-channel between distribution and core
interface port-channel 1
description Routed-EtherChannel-to-SW-CORE
no switchport
ip address 10.0.0.2 255.255.255.252
no shutdown
interface GigabitEthernet0/1
no switchport
channel-group 1 mode active
no shutdown
interface GigabitEthernet0/2
no switchport
channel-group 1 mode active
no shutdown
Note: the IP address goes on the port-channel interface, not on the physical members. Assigning an IP to a physical member after it is in the channel-group will fail or produce a warning.
Mismatch Failures: The Silent Killers
EtherChannel mismatches are one of the more frustrating categories of network problems because many of them do not produce a clear error message. The port-channel may form but behave incorrectly, or individual ports may be suspended from the bundle without an obvious cause. The following are the mismatches that come up most frequently.
Speed and Duplex Mismatch
All member ports in a channel-group must run at the same speed and operate in full duplex. If one physical interface auto-negotiates to 100 Mbps and another negotiates to 1000 Mbps, the switch will refuse to bundle them. The port that does not match the channel’s operating speed will be suspended from the bundle with a log message indicating a compatibility failure.
Duplex is equally critical. Half-duplex interfaces cannot be bundled. In practice, any modern switch interconnect should be auto-negotiating to full duplex, but if you hard-code speed on one side and leave the other on auto, duplex mismatch (and speed mismatch) can occur. Always hard-code speed and duplex to identical values on both ends for inter-switch links that will be members of a port-channel.
interface GigabitEthernet0/1
speed 1000
duplex full
channel-group 1 mode active
Native VLAN Mismatch
For Layer 2 trunk port-channels, the native VLAN configured on the port-channel interface (and therefore on all its member ports) must match on both ends. A native VLAN mismatch on a plain trunk generates a CDP warning and silently passes traffic into the wrong VLAN. On a port-channel, this is exactly as dangerous and equally invisible. CDP warns you if CDP is enabled and both ends are Cisco, but you should verify native VLAN manually.
If the native VLAN mismatches after an EtherChannel is already formed, the port-channel stays up but traffic in the native VLAN crosses VLAN boundaries silently.
STP Mode Mismatch
If one side of a trunk port-channel runs Rapid PVST+ and the other runs classic PVST+, they will interoperate but the RSTP switch will fall back to 802.1D behavior on that port-channel. The consequence is slow STP convergence (30-50 seconds) if the port-channel ever needs to reconverge, even though the switch itself runs RSTP everywhere else. This is not specific to EtherChannel but is worth calling out because port-channels are often trunk links between switches where you want fast convergence.
Allowed VLAN List Mismatch
Both ends of a trunk port-channel should have identical allowed VLAN lists. If SW-ACCESS has VLANs 10, 20, 99, 999 allowed on Po1 but SW-DIST has VLANs 10, 20, 30, 99, 999 allowed, VLAN 30 traffic will be dropped inbound at SW-ACCESS because the port-channel there does not permit it. The mismatch will not prevent the port-channel from forming but will cause specific VLANs to be unreachable and produce no explicit error message.
LACP / PAgP Mode Incompatibility
Attempting to connect an LACP active port to a PAgP desirable port produces no channel. The protocols are completely different and do not interoperate. The physical links will come up but LACP PDUs will be ignored by the PAgP side and vice versa. You will see the physical interfaces flap or the port-channel never form. The fix is to ensure both sides use the same protocol — or use static on mode if one device does not support the other’s protocol (with the risks noted above).
Inconsistent Port-Channel Interface Parameters
The most subtle mismatch: the port-channel interface and its member ports must have consistent Layer 2 parameters. If the port-channel interface is configured as a trunk but one member port is configured as an access port, IOS will either refuse to add the member to the bundle or will suspend it with an error. A common mistake is forgetting to apply trunk configuration to the port-channel interface and only applying it to the physical member ports, or vice versa.
Some Cisco IOS versions automatically apply port-channel interface configuration to the members; others require matching configuration on each member explicitly. The safest practice is to configure all parameters explicitly on both the port-channel interface and each member, and verify with show etherchannel detail that all members show as “bundled” rather than “suspended.”
Verification Commands
Verification is where most EtherChannel troubleshooting begins and ends. The three primary commands cover everything you need.
show etherchannel summary
SW-A# 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 N - not in use, no aggregation
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
A - formed by Auto LAG
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Gi0/1(P) Gi0/2(P)
Decode the flags carefully. SU on the port-channel means the interface is a Layer 2 switchport (S) and is in use (U) — both member ports are bundled and operational. P on the member ports means they are bundled in the port-channel and forwarding traffic.
If a member shows I (stand-alone), it was not successfully bundled — it is operating as an independent link, not as a port-channel member. If it shows s (suspended), it was added to the bundle configuration but suspended due to an incompatibility or mismatch. Either state means traffic that should be distributed across two links is only going over one (or none).
H (Hot-standby) is an LACP flag indicating the port is eligible to join the bundle but is held in reserve as a hot spare because the bundle already has the maximum number of active members. If an active member fails, a hot-standby member moves to active state immediately.
show etherchannel detail
SW-A# show etherchannel detail
Channel-group listing:
----------------------
Group: 1
----------
Group state = L2
Ports: 2 Maxports = 8
Port-channels: 1 Max Port-channels = 1
Protocol: LACP
Minimum Links: 0
Ports in the group:
-------------------
Port: Gi0/1
------------
Port state = Up Mstr Assoc In-Bndl
Channel group = 1 Mode = Active Gcchange = -
Port-channel = Po1 GC = - Psw = -
Port index = 0 Load = 0x00 Protocol = LACP
Flags: S - Device is sending Slow LACPDUs F - Device is sending fast LACPDUs.
A - Device is in active mode. P - Device is in passive mode.
Local information:
LACP port Admin Oper Port Port
Port Flags State Priority Key Key Number State
Gi0/1 SA bndl 32768 0x1 0x1 0x102 0x3D
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi0/1 SA 32768 aabb.cc00.0200 23s 0x0 0x1 0x102 0x3D
Age of the port in the current state: 01d:04h:22m:15s
The detail output shows the operational state of each member port, including LACP system and port priorities, the operational key (which must match across all members in the bundle), and partner information. The Age of the port in the current state field tells you how long the port has been in its current state — a low value on a bundled port indicates recent reconvergence, which may indicate instability.
The key field in the LACP output is significant. IOS derives the LACP key from the interface’s speed and duplex settings. If two interfaces have different speeds, they will have different keys and cannot be bundled together. A port that should be in the bundle but is not will show a different oper key than the other members.
show interface port-channel
SW-A# show interface port-channel 1
Port-channel1 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 0050.56a0.0001 (bia 0050.56a0.0001)
Description: EtherChannel-to-SW-DIST
MTU 1500 bytes, BW 2000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 2Gb/s, link type is auto, media type is unknown media type
input flow-control is off, output flow-control is unsupported
Members in this channel: Gi0/1 Gi0/2
...
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
...
The BW 2000000 Kbit/sec (2 Gbps) confirms two 1 Gbps members are active and contributing. Members in this channel: Gi0/1 Gi0/2 confirms which physical interfaces are bundled. If you see only one member listed here while expecting two, a member has been suspended — go back to show etherchannel summary to find the suspension flag and then show etherchannel detail to find the mismatch.
Input and output error counters on the port-channel interface itself, as well as on each member interface, are useful for diagnosing physical problems. A member with high input errors indicates a cable or optic issue, not a protocol problem.
EtherChannel in a Homelab Context
The CCNA teaches EtherChannel in the context of Cisco IOS, but the protocol — particularly LACP — is widely supported in homelab hardware at non-enterprise prices.
Ubiquiti UniFi switches support LACP on most managed models (USW-24, USW-48, and the Pro/XG variants). The configuration is straightforward through the UniFi controller UI: select the ports, create a bond, choose LACP. The controller creates the LAG and the switch negotiates with the peer. If you are running a UniFi switch alongside a Cisco switch in a lab, LACP active on the Cisco side and LACP (which defaults to active in most UniFi firmware) on the UniFi side will negotiate successfully.
MikroTik switches (including the CSS series and CRS series running SwOS or RouterOS) support 802.3ad LACP bonding. In RouterOS, bonding is configured via Interfaces > Bonding, with mode set to 802.3ad and the LACP transmit rate configurable as fast or slow. The transmit rate must match the peer — fast (1-second intervals) versus slow (30-second intervals) causes longer detection of link failures on the peer side but is otherwise functional.
Netgear managed switches (the GS3xx and GS7xx series commonly found in homelabs) include LACP support, typically labeled “LAG” (Link Aggregation Group) in the UI. Static LAG (equivalent to static on mode) is often the default; look specifically for the 802.3ad LACP option.
Linux bonding/team fully supports 802.3ad LACP, making it straightforward to bond a server NIC pair to a switch-side port-channel. The bonding driver requires mode=802.3ad (or mode=4) and should have lacp_rate=fast for quicker failure detection. The connected switch port must be configured as LACP active (or the Linux bond must be set as active, which is the default for 802.3ad). A Linux server bonded at 802.3ad and connected to a Cisco or Ubiquiti switch with LACP active will negotiate successfully.
One nuance for homelabs: many consumer and prosumer managed switches that advertise “link aggregation” actually only support static LAG (equivalent to mode on), not LACP. The distinction matters if you want negotiation and failure detection. Read the spec sheet carefully — look specifically for “IEEE 802.3ad” or “LACP” rather than just “link aggregation.”
Where This Fits in the Bigger Picture
EtherChannel sits at the intersection of Layer 2 switching, STP, and physical infrastructure. The spanning tree behavior of a port-channel is discussed in detail in the STP guide — particularly the port roles and how a port-channel interface is treated as a single STP segment. The trunk configuration on a port-channel follows exactly the same rules as any other trunk: native VLAN, allowed VLAN lists, and 802.1Q encapsulation are all covered in VLANs and trunking. For the physical design context — how many uplinks, where to place redundancy, how EtherChannel fits into access-distribution-core hierarchy — see the home network design guide. For how EtherChannel relates to the full CCNA exam objective structure, see the CCNA 200-301 complete study guide.
Verdict
EtherChannel is the answer to STP’s bandwidth ceiling, but it is not magic: it aggregates bandwidth across flows, not within a single flow, which means a single TCP session can still saturate only one member link regardless of how many links are in the bundle. In practice, for uplinks carrying aggregated traffic from many hosts, this is not a problem — the diversity of flows distributes naturally. Where it becomes a problem is storage replication, large database backups, or any workload that is fundamentally one or two fat flows rather than many concurrent thin ones. If that describes your traffic, EtherChannel still helps at the STP level and provides redundancy, but do not expect linear bandwidth scaling for the heavy hitters.
For protocol choice, the answer is almost always LACP active on both sides. It provides negotiation, mismatch detection, and interoperability with non-Cisco equipment. PAgP is a legacy option for Cisco-only environments with older switches that predate LACP support. Static on mode is a tool of last resort for devices that cannot negotiate — use it only when you have no alternative and accept that misconfiguration will produce silent failures rather than visible errors.
Mismatch failures are the thing that will consume your troubleshooting time. Speed, duplex, native VLAN, allowed VLAN list, STP mode, and protocol type all need to match. None of these mismatches prevent the physical links from coming up. The port-channel interface may form, may show as up, and may still be broken in ways that produce confusing symptoms. show etherchannel summary tells you whether members are bundled or suspended; show etherchannel detail tells you why; show interface port-channel tells you the aggregate view. Run all three before concluding that EtherChannel is healthy.
Sources
- IEEE 802.1AX-2020: Link Aggregation — IEEE Standards Association
- EtherChannel Configuration Guide, Cisco IOS XE — Cisco
- Understanding EtherChannel Load Balancing and Redundancy — Cisco Support
- Link Aggregation Control Protocol (LACP) — NetworkLessons
- PAgP vs LACP vs Static EtherChannel — 9tut
- EtherChannel Troubleshooting — Cisco Community
- MikroTik 802.3ad Bonding Documentation — MikroTik Wiki
- UniFi Link Aggregation (LAG) — Ubiquiti Help Center
Comments