Quick reference
| Item | Meaning | Check |
|---|---|---|
| Active / passive | At least one active peer initiates | Passive + passive does not initiate |
| Actor / partner | Local and peer negotiation state | Correct peer system and key |
| Collecting / distributing | Member eligible to receive/send | Not just physical link up |
| Logical interface | Port-channel or ae | VLANs, MTU and L3 config |
| Minimum links | Threshold for bundle operation | Design versus surviving members |
| Hashing | Flow-to-member selection | Distribution across multiple flows |
What to understand first
Treat the aggregate as one logical forwarding interface. Confirm member compatibility and the logical interface configuration rather than only comparing physical status.
Negotiated LACP and a forced static channel are different mechanisms. Mixing them can leave individual links or create an unsafe forwarding topology.
Cisco summary flags must be read against the legend in that output. Junos actor/partner state and collecting/distributing indicate negotiation and participation.
A surviving member may satisfy link state but fail a capacity or minimum-links requirement. Monitor both health and the service acceptance threshold.
Commands and interpretation
Inspection commands are read-only unless explicitly labeled otherwise. Capture commands start collection; configuration-mode commits change device state.
Cisco IOS XE
Read-only EXEC
show etherchannel summary
show lacp neighbor
show interfaces port-channel 1
show interfaces trunkInspect: Verify bundled member flags, the expected peer, logical errors and carried VLANs.
Junos
Read-only operational
show lacp interfaces
show interfaces ae0 extensive
show interfaces terseInspect: Check actor/partner synchronization and eligible members; compare ae0 counters with physical members.
Worked example · Illustrative, not a device capture
Illustrative bundle evidence
Expected members: 2 x 10G
Member A: collecting / distributing
Member B: link up, not synchronized
Logical bundle: up on Member AService may remain reachable while redundancy and capacity are degraded. Inspect partner state on Member B.
This is a normalized teaching example; vendor output names and flags differ.
Troubleshooting sequence
- Check the actual cabling and peer system on every member.
- Compare LACP mode, system/key information and compatible link settings at both ends.
- Verify member participation, logical VLAN/L3 configuration and minimum-links behavior.
- Compare timed error samples; run multiple representative flows for a capacity test.
- Perform only an approved member-loss test and observe application continuity.
Common mistakes
- Forcing channel mode to conceal a negotiation mismatch.
- Expecting a single TCP flow to fill every member.
- Declaring success because the logical interface remains up with a missing member.
Acceptance checks
- All planned members participate with the correct peer.
- Logical VLANs, MTU and routing match the intended service.
- Member-loss behavior and available capacity meet acceptance criteria.
Primary references
Vendor documentation and protocol specifications support this guide. The diagrams, scenarios and troubleshooting sequences are Wolex-authored.