LACP Explained: Static vs Passive vs Active with Real Lab Examples

—
Link aggregation is widely used in enterprise, campus and data-center networks to combine multiple physical Ethernet links into a single logical connection.
The main goals are:

• Increase available aggregate bandwidth

• Provide link redundancy

• Simplify logical interface management

• Distribute traffic across multiple physical links

• Reduce the impact of a single member-link failure

A standards-based method for dynamically forming and maintaining these bundles is Link Aggregation Control Protocol — LACP.
LACP was originally associated with IEEE 802.3ad. Link aggregation was later moved into the IEEE 802.1AX standard.

—

Understanding LACP and EtherChannel Modes

LACP allows network devices to exchange control information and determine which physical interfaces can participate in a link aggregation group.
On Cisco platforms, common EtherChannel configuration modes include:

• on

• active

• passive

Static Mode — on

Static EtherChannel does not use a negotiation protocol.
Both devices are manually configured to place selected interfaces into the same logical bundle.
Example concept:

Because no negotiation takes place, static EtherChannel cannot use LACP to detect whether the remote device is correctly configured for the same aggregation.

LACP Active Mode

An interface configured in active mode actively sends LACP control messages and attempts to establish an aggregation.
Active mode can normally form an LACP bundle with:

• Active

• Passive

LACP Passive Mode

An interface configured in passive mode listens for LACP negotiation but does not normally initiate it.
Passive can form a bundle with:

• Active

Passive will not normally form an LACP bundle with another passive interface because neither side initiates negotiation.

Mode Compatibility

—

Configure Static and LACP EtherChannel

The following examples use Cisco IOS-style configuration.
Assume two switches are connected using:

• GigabitEthernet0/1

• GigabitEthernet0/2

The examples use Port-Channel 1.

Lab Topology

Example 1 — Static EtherChannel

Configure Switch A:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode on
 exit

Configure Switch B:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode on
 exit

The bundle is static.
No LACP negotiation occurs.

Example 2 — Active to Passive

Switch A:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode active
 exit

Switch B:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode passive
 exit

Expected result:

Active + Passive

LACP negotiation: Successful
Port-Channel: Formed

Switch A initiates the LACP exchange.
Switch B responds.

Example 3 — Active to Active

Switch A:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode active
 exit

Switch B:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode active
 exit

Expected result:

Active + Active

LACP negotiation: Successful
Port-Channel: Formed

Both devices actively participate in LACP negotiation.

Example 4 — Passive to Passive

Switch A:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode passive
 exit

Switch B:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode passive
 exit

Expected result:

Passive + Passive

LACP negotiation: Not initiated
Port-Channel: Does not form normally

The problem is simple:
Both sides are waiting for the other side to initiate LACP.

Configuration of the Port-Channel Interface

The logical Port-Channel must also have the intended Layer 2 or Layer 3 configuration.
For a trunk example:

interface Port-channel1
 description LACP-UPLINK
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

Depending on platform and software behavior, configuration may also be inherited, propagated, or required consistently between the member links and port-channel interface.

—

Verify LACP and EtherChannel Operation

Never assume a bundle is healthy simply because the Port-Channel interface appears up.
Verify:

• Logical Port-Channel state

• Member-interface state

• LACP neighbor information

• VLAN or Layer 3 consistency

• Traffic distribution

• Physical-interface errors

Show EtherChannel Summary

A common Cisco command is:

show etherchannel summary

Example:

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-------------------------------
1      Po1(SU)         LACP      Gi0/1(P) Gi0/2(P)

Common indicators may include:

• S — Layer 2

• R — Layer 3

• U — In use

• P — Bundled in Port-Channel

Exact flags can vary by platform and software release.

Show LACP Neighbor

show lacp neighbor

This helps confirm that the local device is receiving LACP information from the expected peer.

Show EtherChannel Details

show etherchannel 1 detail

This can provide information about:

• Member interfaces

• Port states

• Protocol

• Partner information

• Port-channel state

Check the Port-Channel Interface

show interfaces port-channel 1

Useful fields include:

• Interface state

• Traffic counters

• Errors

• Drops

• Bandwidth

• Packet rates

Check Individual Members

show interfaces GigabitEthernet0/1
show interfaces GigabitEthernet0/2

Look for:

• Input errors

• CRC errors

• Output errors

• Drops

• Speed

• Duplex

• Physical state

Check Interface Configuration

show running-config interface GigabitEthernet0/1
show running-config interface GigabitEthernet0/2
show running-config interface Port-channel1

This is useful when troubleshooting configuration inconsistencies.
—

Troubleshoot Common LACP Problems

LACP failures are frequently caused by interface or configuration inconsistencies rather than the LACP protocol itself.

Problem 1 — Passive on Both Sides

Observed configuration:

For example:

interface range GigabitEthernet0/1 - 2
 channel-group 1 mode active

Problem 2 — Static on One Side, LACP on the Other

Example:

Problem 3 — VLAN or Trunk Mismatch

Example:
Switch A allows:

switchport trunk allowed vlan 10,20,30

Switch B allows:

switchport trunk allowed vlan 10,20

The EtherChannel itself may still exist, but traffic behavior for VLAN 30 will not match the intended design.

Problem 4 — Member Link Configuration Mismatch

Member interfaces in a bundle generally need compatible attributes.
Depending on platform and deployment, relevant settings may include:

• Speed

• Duplex

• Switchport mode

• VLAN configuration

• Native VLAN

• MTU

• Layer 2 vs Layer 3 mode

• Port-channel membership

Problem 5 — Physical Link Failure

If one physical member fails, LACP can remove that member while the remaining eligible links continue forwarding.

Problem 6 — One Member Not Bundled

Example:

Po1(SU)  LACP  Gi0/1(P) Gi0/2(I)

If one interface is not shown as properly bundled, investigate:

• Physical state

• LACP neighbor

• Interface configuration

• VLAN settings

• Speed

• Duplex

• Port-channel parameters

• Platform logs

Troubleshooting Workflow

—

Load Balancing, Design Considerations and Best Practices

LACP aggregates links, but it is important to understand what that means for actual traffic.

Four 1 Gbps Links Do Not Mean One Flow Gets 4 Gbps

A bundle containing:
4 × 1 Gbps links
can provide approximately 4 Gbps of aggregate physical capacity.
However, a single traffic flow is normally mapped to one member link by the platform’s hashing algorithm.

Load-Balancing Hash

Platforms may distribute traffic using combinations of fields such as:

• Source MAC address

• Destination MAC address

• Source IP address

• Destination IP address

• Layer 4 ports

Available algorithms are platform-dependent.
A Cisco platform may provide commands such as:

show etherchannel load-balance

An Even Number of Links Is Not Required

A common misconception is that EtherChannel should always use an even number of member links.
That is not a general LACP requirement.
A LAG may contain:

• 2 links

• 3 links

• 4 links

• Other supported member counts

depending on platform capabilities and design.

Use Compatible Member Interfaces

Avoid combining incompatible interfaces.
For example, most platforms will not allow a normal LAG containing arbitrary mixtures such as:

• 1 Gbps

• 10 Gbps

Member requirements are platform-specific, so always verify vendor documentation.

Use LACP for Dynamic Negotiation

Where supported and appropriate, LACP provides operational advantages compared with completely static aggregation.
It can:

• Exchange partner information

• Determine eligible members

• Detect aggregation inconsistencies

• Dynamically manage membership

Prefer Clear Operational Configuration

A common configuration choice is:

Switch A: Active
Switch B: Active

This removes ambiguity about which side initiates negotiation.

Configure the Logical Interface Consistently

Treat the Port-Channel as the logical forwarding interface.
Verify settings such as:

• Trunking

• VLANs

• Native VLAN

• MTU

• Layer 3 addressing

• Routing

• STP behavior

Monitor Individual Links as Well as the Bundle

A healthy Port-Channel can hide degradation on an individual member.
Monitor:

• CRC errors

• Drops

• Link flaps

• Optical levels where applicable

• Utilization

• LACP state

• Member count

Consider Minimum-Link Requirements

Some platforms allow a minimum number of active members to be required before the Port-Channel is considered operational.
This can be useful when an application or design requires a minimum aggregate capacity.

—

Summary

LACP provides a standards-based method for dynamically managing Ethernet link aggregation.
The most important distinction is:

Key Takeaways

1. LACP is used to dynamically manage link aggregation.
2. LACP was historically associated with IEEE 802.3ad and is now standardized under IEEE 802.1AX.
3. Static EtherChannel does not use LACP.
4. active actively participates in LACP negotiation.
5. passive waits for received LACP negotiation.
6. Active + Active works.
7. Active + Passive works.
8. Passive + Passive normally does not form.
9. Static + Static can form without protocol negotiation.
10. A Port-Channel being up does not guarantee correct VLAN or Layer 3 forwarding.
11. Member interfaces must satisfy platform compatibility requirements.
12. LACP protects against some aggregation mismatches but does not replace configuration validation.
13. Link aggregation increases aggregate capacity across traffic flows.
14. A single flow does not normally consume the combined bandwidth of all member links.
15. An even number of links is not an LACP requirement.
16. Individual physical members should be monitored for errors and degradation.
17. Always verify the Port-Channel, LACP neighbor and member states after configuration.

—

Useful Links and References

SanchitGurukul Static Resources

Official External References