What is LACP EtherChannel, and why does active/passive matter? EtherChannel groups compatible physical Ethernet links into one logical port-channel; LACP negotiates membership rather than forcing links into a static bundle.[1]
Short answer: active starts LACP negotiation, passive responds, and passive/passive does not form an LACP bundle.[1] For the Catalyst 9300 release documented here, an LACP group supports up to eight active members plus up to eight standby members; treat that as a platform limit, not a universal definition of LACP.[1]
This article focuses on bundle formation, mode selection and the interview question about member limits. For a performance investigation after the bundle is already healthy, use the separate LACP load-balancing troubleshooting guide.
EtherChannel, port-channel and LACP: different jobs
An EtherChannel is the bundle, the port-channel is its logical interface, and a channel group binds physical interfaces to that logical interface.[1]
LACP is the negotiation mechanism; Cisco also documents proprietary PAgP and static on mode as different ways of building EtherChannels.[1]
Configuration applied to the port-channel propagates to its member interfaces on the documented platform.[1]
Keep two questions separate during an interview: Did the correct links join the bundle? and How is traffic distributed across those links? Negotiation and forwarding are not the same troubleshooting problem.
Active vs passive vs static on
The following combinations summarize Cisco's documented negotiation behavior; successful formation also requires compatible member configuration.[1]
| Local mode | Remote mode | Expected negotiation result |
|---|---|---|
| LACP active | LACP active | Can form; both sides initiate |
| LACP active | LACP passive | Can form; the passive side responds |
| LACP passive | LACP passive | Does not form; neither starts negotiation |
| Static on | Static on | Forced bundle without LACP; configuration must be correct |
| Static on | LACP active/passive | Not a valid matching LACP design |
Passive does not mean backup. It describes whether a port initiates negotiation, whereas hot standby describes a member that is not currently selected to forward as an active bundle member.[1]
Likewise, active mode does not mean that the switch is the STP root or the primary chassis; it means that the port initiates LACP exchanges.[1]
For a new lab, I recommend active/active because it removes the passive/passive mistake. Do not use static on as a quick fix for unexplained LACP failure: Cisco warns that mismatched static configurations can cause packet loss or spanning-tree loops.[1]
Does LACP have an eight-link limit?
The precise interview answer is: check the platform and release. The Catalyst 9300 IOS XE 17.15 guide allows up to sixteen configured LACP ports of the same type, with up to eight active and eight standby members.[1]
Its lacp max-bundle setting can further limit active members, and LACP priorities influence active/standby selection.[1]
Do not quote this as “every LACP implementation can forward on exactly eight links.” It is the documented capacity of this example platform, not a protocol-wide guarantee.
Also distinguish max-bundle from min-links: the former limits active bundle size, while port-channel min-links requires a minimum number of active links before the logical interface is active.[1]
That distinction matters when troubleshooting a port-channel that stays down despite some healthy members.
A simple formation and forwarding flow
Use this conceptual sequence to explain the process; it is not a packet capture or an executed lab:
- Check physical connectivity and compatibility. On this platform, members need compatible speed and duplex, and Layer 2 members must have consistent access/trunk and VLAN settings.[1]
- Start negotiation. At least one endpoint must use active mode for LACP negotiation to begin.[1]
- Select usable members. LACP selects active and, where applicable, standby members according to configuration, limits and priorities.[1]
- Forward through the logical bundle. The switch uses its configured load-distribution method to select physical links for traffic.[1]
- Handle a failed member. EtherChannel redistributes traffic over remaining links; a configured minimum-link threshold can instead make the logical port-channel inactive when too few members remain.[1]
Do not promise zero packet loss or a particular recovery time from that sequence. Measure application interruption in the actual design.
Why the port-channel does not make every flow faster
Cisco's documented forwarding methods select a member from packet address information, with available modes including source/destination MAC or IP addresses.[1] Traffic with the same relevant hash inputs can therefore keep using the same member; a working bundle does not imply evenly distributed interface counters.[1]
A useful interview distinction is aggregate capacity versus individual traffic placement. Ask which hash inputs the switch uses before deciding that uneven utilization is a fault. The linked performance guide covers controlled single-stream and multi-stream tests; this article's first acceptance condition is correct bundle membership.
Illustrative Cisco IOS XE configuration
The example below is for an isolated two-switch lab, not a production change or tested output. Use two compatible ports between the same pair of switches, with VLANs 10 and 20 created at both ends. Adapt interface names and review the running configuration before applying it.
Cisco documents channel-group ... mode active for LACP and requires consistent trunk/access and VLAN settings across members.[1]
! Apply this illustrative configuration at BOTH lab endpoints.
! Keep both physical members shut until both ends are ready.
interface range GigabitEthernet1/0/1 - 2
shutdown
switchport mode trunk
switchport trunk allowed vlan 10,20
channel-group 1 mode active
exit
!
interface Port-channel1
switchport mode trunk
switchport trunk allowed vlan 10,20
no shutdown
exit
!
! After reviewing both endpoints:
interface range GigabitEthernet1/0/1 - 2
no shutdown
The intended result is one trunk port-channel with both physical interfaces bundled. The snippet assumes matching native VLAN behavior at both endpoints; review that explicitly rather than treating a successful LACP negotiation as an end-to-end VLAN test. See access ports, trunks and native VLANs for the frame-level explanation.
Verification and troubleshooting checklist
Cisco provides the following read-only commands for EtherChannel and LACP inspection; use the command help for the installed release.[1]
show etherchannel summary
show etherchannel 1 detail
show lacp neighbor
show etherchannel load-balance
show interfaces Port-channel1
Do not stop at “the physical interfaces are up.” Record evidence for each of these checks:
| Check | What to establish | Next action if wrong |
|---|---|---|
| Protocol and mode | Both endpoints intend LACP; at least one is active | Fix mode mismatch before changing forwarding settings |
| Physical members | Intended links are healthy and correctly cabled | Inspect errors, optics and patching |
| Bundle membership | Each intended forwarding member is actually bundled | Compare member configuration and peer information |
| Peer identity | Members connect to the intended logical peer | Investigate an unexpected partner before enabling more links |
| VLAN consistency | Allowed VLANs and native behavior match the design | Test actual VLAN connectivity, not just LACP |
| Limits and standby | Active count meets the design and minimum-link policy | Review priorities, standby status and configured thresholds |
| Forwarding | Traffic passes and counter changes match the test | Investigate hash inputs only after membership is healthy |
In Cisco's documented summary output, H identifies a hot-standby member; it should not automatically be treated as a broken cable.[1]
An unbundled port's behavior also needs care: the guide describes standalone forwarding and the option to suspend such ports with port-channel standalone-disable.[1]
Do not assume that every platform or configuration safely suspends every unbundled link; inspect the actual state before reconnecting redundant Layer 2 paths.
A concise interview answer
“EtherChannel presents compatible physical links as one logical port-channel, and LACP negotiates which members participate.[1] Active initiates negotiation, passive responds, and passive/passive does not build an LACP bundle.[1] On the Catalyst 9300 release in this example, up to eight members forward and another eight can be standby, but I verify the target platform's limits.[1] Traffic distribution depends on the forwarding hash, so I verify membership separately from utilization.”[1]
Common pitfalls and a small lab exercise
Avoid conflating passive mode with hot standby, assuming on means LACP, or counting configured members as proof that all members are forwarding. Those distinctions follow directly from the separate mode, selection and forwarding mechanisms above.[1]
Proposed lab: begin with active/active, save the read-only outputs, change one endpoint to passive and compare membership, then use passive/passive to observe the failure to negotiate. Restore active/active before testing a member failure. Record observed packet loss and port-channel state rather than inventing an expected recovery time. This exercise has not been executed for this article.
Summary and related reading
LACP mode answers who starts negotiation; membership shows which links actually participate; forwarding policy explains how traffic uses the bundle.[1] Verify all three, and qualify the eight-active-member answer with the platform and software release.
- Access Port vs Trunk Port vs Native VLAN Explained
- LACP Load Balancing Troubleshooting: Why One Flow Uses Only One Link
- STP vs RSTP Port States and Roles
Preparing for a network engineering interview? Practice explaining passive versus standby without looking at the table, then describe which command would prove that a member actually joined the bundle.
Post a Comment