200-301 · Network Access · Updated August 3, 2026

EtherChannel: LACP, PAgP, and On Modes Explained

EtherChannel bundles up to eight physical links into one logical interface so that spanning tree sees a single path and no member is blocked. Three negotiation behaviors are available through the channel-group command: LACP (Link Aggregation Control Protocol, the IEEE standard) using the active and passive keywords, PAgP (Port Aggregation Protocol, Cisco-proprietary) using desirable and auto, and on, which bundles unconditionally without any negotiation. Once the bundle exists, all Layer 2 and Layer 3 configuration belongs on the logical Port-channel interface, and traffic is spread across members by a hash, not round-robin.

Channel configuration

Select the member ports together and assign them to a group:

SW1(config)# interface range gigabitethernet1/0/1 - 2
SW1(config-if-range)# channel-group 12 mode active
Creating a port-channel interface Port-channel 12

IOS creates interface Port-channel 12 on its own the first time a port joins group 12. The syntax to remember is that channel-group <number> mode <keyword> is an interface subcommand; there is no port-channel <n> mode subcommand, and the command cannot be entered from global configuration with an interface list appended.

The group number is locally significant. SW1 can use group 12 while SW2 uses group 3 for the same bundle, and the channel still forms, because the number never appears in a negotiation packet. What must agree between the two switches is the mode pairing.

Mode pairing matrix

Local mode	Remote mode	Result
`active` (LACP)	`active`	Bundles
`active`	`passive`	Bundles
`passive`	`passive`	No channel: neither side initiates
`desirable` (PAgP)	`desirable`	Bundles
`desirable`	`auto`	Bundles
`auto`	`auto`	No channel: neither side initiates
`on`	`on`	Bundles, with no negotiation at all
`on`	`active`, `passive`, `desirable`, or `auto`	No usable channel
LACP keyword	PAgP keyword	No channel: different protocols

The pattern behind the table is worth internalizing rather than memorizing row by row. active and desirable are the assertive keywords: they send negotiation packets and ask for a channel. passive and auto are the responsive keywords: they answer a request but never make one. Two responsive ends therefore sit silent forever, and the direct fix is to change one side to its assertive counterpart, not to add on or to swap protocols. LACP and PAgP speak different packet formats and never interoperate, so a mixed pair leaves both ends waiting.

on deserves separate treatment because it is the one mode that skips verification. Both ends set to on produce a working channel immediately, since neither is waiting for a partner. on opposite any negotiating mode is the dangerous case: the on side starts forwarding across both links as a bundle while the other side never aggregates, which can produce a forwarding loop or drive ports into err-disabled. Nothing auto-corrects this. A port in on mode does not fall back to active when it receives LACP frames, and a port in active mode does not give up and go static.

Configuration placement

The Port-channel interface is the configuration point once the group exists:

SW1(config)# interface port-channel 12
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 10,20,30

Settings applied here propagate to every member at once, so the 802.1Q trunk settings the channel carries are entered once rather than port by port. Editing one physical member instead makes that port disagree with the rest of the group, and the compatibility check drops it out of the bundle, typically showing it as suspended. The repair is to bring the outlier back into line and to make future trunk changes under the Port-channel interface so the members cannot drift apart again. Why an EtherChannel will not bundle covers that failure in depth.

For a routed channel between distribution and core, the members and the logical interface all have to leave switchport mode, and the address goes on the logical interface:

SW1(config)# interface range gigabitethernet1/0/23 - 24
SW1(config-if-range)# no switchport
SW1(config-if-range)# channel-group 20 mode active
SW1(config)# interface port-channel 20
SW1(config-if)# no switchport
SW1(config-if)# ip address 10.10.10.1 255.255.255.252

A Layer 3 EtherChannel carries routed traffic and takes no part in 802.1Q trunking or VLAN membership. An address left on a member port after it joins the group is simply unused for forwarding, which is why a routed channel with the address in the wrong place passes no traffic. Routed channels are not restricted to two links and do not require PAgP or a matching SVI; LACP works on them exactly as it does at Layer 2.

Load balancing

The switch hashes selected fields of each frame and the result picks one member link. Because the hash is per-conversation, every frame belonging to one flow leaves on the same member, and a single conversation therefore never exceeds the bandwidth of one physical link. A four-member 1 Gbps channel is 4 Gbps of aggregate capacity, not a 4 Gbps pipe for one file transfer.

The method is set globally, once per switch:

SW1(config)# port-channel load-balance src-dst-ip

The available fields vary by platform and include source MAC, destination MAC, source and destination MAC, the equivalent IP combinations, and on some hardware Layer 4 ports. Choosing well means choosing a field that actually varies in your traffic. Frames leaving an access switch toward its default gateway all carry the same destination MAC address, so any destination-MAC method sends everything down one link; switching to a source-and-destination IP hash restores spread because the host addresses differ. show etherchannel load-balance reports the method currently in use, not per-link counters and not a table of pinned MAC addresses.

The method does not have to match on the two switches. Each device independently decides how to hash traffic it is transmitting.

Verification

show etherchannel summary is the first command, giving each group, its protocol, and a flag beside every member and the Port-channel itself:

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      Po1(SU)         LACP      Gi1/0/1(P)   Gi1/0/2(P)   Gi1/0/3(I)

Po1(SU) reads as a Layer 2 channel that is in use. (P) beside a member means it is bundled, (I) means it is standing alone outside the channel while still forwarding on its own, (s) means suspended, (D) means down, and (H) marks an LACP hot-standby member. U and S are channel-level flags and do not appear against individual ports.

Two other views fill in detail. show etherchannel 4 port-channel gives per-member index and load share, each member’s EC state, and how long the aggregator has been up. show interfaces port-channel 4 reports the logical interface’s own counters and status rather than member-by-member state.

Adding and removing members

Because spanning tree treats the bundle as one logical link with one port role, a member removed carelessly can start forwarding independently and create a loop. Shut the interface down on both switches first, then remove channel-group from that interface on both sides. Removing it on one side only leaves an asymmetric configuration. Deleting the whole Port-channel interface to drop one member is disruptive and unnecessary, and no channel-group entered under the Port-channel interface is not how membership is released. Once the group is empty of that port, re-enable it wherever it is going.

Eight links can forward in one bundle. On platforms that support it, LACP allows up to sixteen ports to be configured in a group, with the eight beyond the active set held as hot-standby and marked (H).

How the 200-301 exam tests this

Mode pairing outcomes. A stem states both switches’ keywords and asks whether a channel forms. Two responsive keywords (auto with auto, passive with passive) never form one, and the least-disruptive fix is to make one side assertive. on opposite a negotiating mode is presented as if it might work; it does not.
Protocol identification by keyword. Multi-select items ask which keywords select PAgP (desirable and auto) or LACP (active and passive). Keep the Cisco-proprietary protocol paired with its two keywords.
Where a command belongs. Trunk and IP settings go on the Port-channel interface, channel-group goes on the members, and port-channel load-balance is global. Distractors move each one to a plausible wrong prompt.
Reading the summary flags. You are shown a group with one member out of step and asked what is happening. Distinguish (P), (I), (s), (D), and (H) precisely, and read (SU) as a property of the channel.
Hash selection from a traffic description. A scenario describes traffic that is uniform in one field and asks why one link is saturated. The answer is a load-balancing method that hashes on a field which actually varies.

Bundling a channel is also a credible simulation task, and building one from memory rather than from the prompt is what protects the minutes a simulation consumes out of the 120 you get. The keyword pairings are multiple-choice territory, and a question bank catches a desirable-with-LACP mix-up long before the exam does.

Quick reference

LACP keywords: active (initiates) and passive (responds). PAgP keywords: desirable (initiates) and auto (responds).
Two responsive keywords never bundle; LACP never bundles with PAgP; on bundles only with on.
PAgP is Cisco-proprietary; LACP is the IEEE standard and works multivendor.
The channel-group number is locally significant and need not match the neighbor.
Eight links forward per bundle; LACP supports up to sixteen configured with hot-standby members.
Apply trunk, VLAN, and IP settings on interface port-channel <n>, never on one member.
Layer 3 channel: no switchport on members and on the Port-channel, address on the Port-channel.
port-channel load-balance is a global command, and one flow is confined to one member link.
Verify with show etherchannel summary, show etherchannel <n> port-channel, and show etherchannel load-balance.