How to Configure EtherChannel with LACP on Cisco (Step by Step)

Step 1 — Select the member ports and negotiate with LACP

Group the physical ports you want to bundle with `interface range` so you configure them together instead of one at a time — this also helps keep their settings identical, which LACP requires. Then add each port to a channel-group and set the LACP mode.

Mode active means the port actively sends LACP packets to negotiate the bundle; passive only responds to LACP but never initiates. At least one side of the link must be active or the bundle never forms — two passive ends just sit there waiting for each other. Do this on both switches, using the same channel-group number locally (it doesn't have to match the number on the other switch, but keeping it consistent avoids confusion).

SW1(config)# interface range gigabitethernet0/1 - 2
SW1(config-if-range)# channel-group 1 mode active

Step 2 — Configure the logical port-channel interface

Once ports join a channel-group, IOS creates a port-channel interface automatically. All the switchport configuration — trunk mode, allowed VLANs, access VLAN, whatever the link needs — goes on that logical interface, not on the individual members. IOS then applies it down to each bundled port.

Do not configure switchport settings directly on gigabitethernet0/1 or 0/2 once they're in the bundle. If a member's settings disagree with the port-channel (or with its bundle-mates), that port gets suspended instead of forwarding.

Note: on switches that support dual ISL/802.1Q trunking (older 3550/3560/3750 platforms), IOS won't accept `switchport mode trunk` until you first set `switchport trunk encapsulation dot1q`. Platforms that only ever spoke 802.1Q — 2960, 9300, and the IOSv images used in labs — don't have that extra step; `switchport mode trunk` works on its own.

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

Step 3 — Verify the bundle

`show etherchannel summary` is the first command to run. The bundled/forwarding status is a per-member-port flag, not something shown once for the whole port-channel — look at each member's own entry, e.g. `Gi0/1(P)`: (P) means that port is bundled and forwarding; (s) means suspended, almost always because of a mismatch in speed, duplex, switchport mode, or allowed-VLAN list between that port and the rest of the bundle. (The Po1 line itself carries a different flag, like (SU), which just tells you it's a Layer 2 port-channel currently in use.)

`show lacp neighbor` confirms the other switch is actually negotiating — you should see the partner's system ID and a flags column next to each member link, e.g. `FA` meaning fast LACPDU rate and active mode. If the neighbor doesn't show up at all, check that at least one side is set to active mode.

SW1# show etherchannel summary
SW1# show lacp neighbor

A fully worked example: both switches, real ports, real output

The steps above only showed one side. In practice you configure a mirror-image bundle on each switch. Here SW1 and SW2 are joined by Gi0/1 and Gi0/2, and the bundle is a trunk carrying VLANs 10 and 20. Both ends are set to LACP active — active/active is preferred over active/passive because either side can initiate the negotiation, so convergence doesn't depend on which switch you brought up first. On IOSv, 2960, and 9300 platforms no 'switchport trunk encapsulation' step is needed; on older 3550/3560/3750 gear you would add it before 'switchport mode trunk'.

After both sides are applied, read 'show etherchannel summary' from the member flags outward. The Po1 line shows (SU) — S for Layer 2, U for in-use — which only tells you the logical interface exists and is up. What actually confirms success is each member showing (P) for bundled and forwarding. If you instead see (s) lowercase, that port is suspended for a config mismatch; (H) means it is a hot-standby beyond the 8-active limit; (D) means the physical link is down.

Finish with two sanity checks that catch the errors the summary won't. 'show interfaces trunk' confirms Po1 is trunking and that VLANs 10 and 20 are actually allowed and forwarding, and 'show lacp neighbor' confirms you are seeing the partner's system ID on both member links. A quick ping between hosts in VLAN 10 on either side proves data-plane forwarding, not just that the bundle formed.

SW1(config)# interface range gigabitethernet0/1 - 2
SW1(config-if-range)# channel-group 1 mode active
SW1(config-if-range)# exit
SW1(config)# interface port-channel 1
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 10,20
SW1(config-if)# end

SW2(config)# interface range gigabitethernet0/1 - 2
SW2(config-if-range)# channel-group 1 mode active
SW2(config-if-range)# exit
SW2(config)# interface port-channel 1
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 10,20
SW2(config-if)# end

SW1# show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        s - suspended   H - Hot-standby (LACP only)
        S - Layer2      U - in use
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)

Load balancing, the hash, and why STP never blocks a bundle

Understanding how a bundle picks a link explains most "it's not faster" complaints. The switch computes a hash over selected header fields and maps each flow to exactly one member. The default fields vary by platform — Layer 2 switches often hash on source-and-destination MAC, Layer 3 platforms on source-and-destination IP. If all your traffic exits through a single router, every frame carries that router's one MAC, so a src-dst-mac hash pins nearly everything onto one link. In that case switch the algorithm to something with more entropy, such as src-dst-ip or src-dst-port, with the global 'port-channel load-balance' command.

The member count matters too. Classic Catalyst hashing distributes the result across member links most evenly when the number of active links is a power of two — 2, 4, or 8. Bundles of 3, 5, 6, or 7 links leave some members carrying noticeably more flows than others, which is why a 6-link channel can look lopsided under load even though every port is bundled and healthy. You can predict placement without guessing: 'test etherchannel load-balance' tells you exactly which member a given source/destination pair will use.

Finally, the reason to bundle rather than just run two parallel cables is spanning tree. STP sees the entire port-channel as one logical port with a single path cost, so it never blocks the redundant members as a loop the way it would block a second discrete link. That single-logical-link view is also why all switchport settings live on the Port-channel interface and are pushed down to members — STP, and the far end, must see one consistent interface, not two.

SW1(config)# port-channel load-balance src-dst-ip
SW1# show etherchannel load-balance
  EtherChannel Load-Balancing Configuration:
        src-dst-ip
SW1# test etherchannel load-balance interface port-channel 1 ip 10.0.10.5 10.0.20.9
  Would select Gi0/1 of Po1

Common problems (and the fix)

Bundle never forms because both sides are passive — passive-passive never negotiates. Set at least one side to active.

Mixing 'on' with 'active' or 'passive' on the two ends. Mode 'on' forces the channel up with no negotiation at all; it can't talk LACP with a side configured for active or passive, so the link won't come up (or won't come up correctly). Use active/passive on both ends for LACP, or 'on' on both ends for a manual (non-negotiated) channel — never mix them.

A member port shows (s)/suspended next to its interface in `show etherchannel summary`. This means its config doesn't match its bundle-mates — check speed, duplex, switchport mode, and allowed VLANs are identical across every member.

Configuring switchport settings on the physical member interfaces instead of the port-channel. Always configure trunking, access VLAN, and allowed-VLAN lists on the logical `interface port-channel` — the members inherit it from there.

`switchport mode trunk` gets rejected on the port-channel. On platforms that support dual ISL/802.1Q trunking, you must set `switchport trunk encapsulation dot1q` first; on dot1q-only platforms (2960/9300/IOSv) this isn't needed.