Bundling two links into a port-channel is the most routine thing you will ever do on a switch, right up until you do it on a Nexus for the first time. The command gets rejected outright, and when a member does not join you get a state that is neither up nor down. This walkthrough uses real output from a four-node Nexus 9000v spine-leaf lab built for the Data Center Fabric guide, running NX-OS 10.6(2) on N9K-C9300v virtual chassis. Everything below is copied from that session.
The command is rejected, not queued
Here is the first thing NX-OS does to you. Two leaf switches, LEAF1 and LEAF2, cabled together on Ethernet1/3 and Ethernet1/4. Fresh configuration, nothing enabled yet:
LEAF1(config)# interface Ethernet1/3
LEAF1(config-if)# channel-group 1 mode active
LACP process needs to be started before configuring active or passive mode
That is not a warning. The command did not apply, nothing was queued for later, and the interface is exactly as it was before you pressed enter. NX-OS ships with almost nothing running: on a fresh box in this lab, show feature | include enabled returned four processes (icam, intersight, license-smart and sshServer), and LACP was not among them. If you are coming from IOS XE, where EtherChannel is simply available, this is the single most common wasted five minutes.
The fix is one line, and it goes first, always:
feature lacp
Worth noting what the error does not say. It does not complain about channel-group 1 mode on, because static bundling needs no protocol process. Only active and passive require the LACP process, which is exactly what the message says if you read it literally. That distinction matters when you inherit a config: a working static port-channel on a box with no feature lacp is entirely normal, and it is also entirely unprotected against miscabling. If you want more background on how NX-OS differs from the platform most of us learned on, the NX-OS versus IOS XE comparison covers the feature model in depth.
The configuration that works
This is the full working config, applied identically on both leaves:
feature lacp
interface Ethernet1/3-4
switchport
channel-group 1 mode active
interface port-channel1
switchport
switchport mode trunk
no shutdown
Three details in there are easy to skip past.
The explicit switchport. Nexus leaf ports may or may not be Layer 2 depending on the platform default and on what the previous engineer did with system default switchport. Putting switchport on the member interfaces is not padding, it is the thing that stops you from building a routed port-channel by accident.
The range syntax. interface Ethernet1/3-4 configures both members in one pass. Every member of a bundle must be identically configured, and applying the config as a range is the cheapest way to guarantee that. Mismatched speed, duplex, MTU, or switchport mode between members is a classic cause of a port that will not join.
The port-channel interface is configured after the members. On NX-OS the logical interface is created automatically when the first channel-group lands, and settings applied to it are inherited by the members. Trunk configuration belongs on port-channel1, not on the physical ports. If you configure the trunk on the members instead, you get an inheritance argument you do not need to have. VLAN and trunking behaviour on the bundle follows the same rules as any other trunk, covered in the VLANs and Layer 2 switching guide.
Reading show port-channel summary
With both sides configured, this is the healthy state:
show port-channel summary
Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
b - BFD Session Wait
S - Switched R - Routed
U - Up (port-channel)
p - Up in delay-lacp mode (member)
M - Not in use. Min-links not met
--------------------------------------------------------------------------------
Group Port- Type Protocol Member Ports
Channel
--------------------------------------------------------------------------------
1 Po1(SU) Eth LACP Eth1/3(P) Eth1/4(P)
Everything you need is in that last line. Po1(SU) means the bundle is Switched and Up. Protocol LACP confirms this is a negotiated bundle rather than a static one, and both members carry (P), which is the only member flag that means traffic is being hashed onto that link.
The legend is printed on every invocation because you will need it. Here is what the flags actually mean in operational terms:
lacp min-links requires, so the bundle is deliberately held down rather than run degraded.The two flags on the bundle itself are separate from the member flags. S versus R tells you Layer 2 or Layer 3, and U versus D tells you whether the bundle as a whole is usable. A port-channel can sit at Po1(SD) with every member (D), which just means the whole thing is dark. The dangerous case is (SU) with one member (P) and one (s): the bundle is up, traffic is flowing, and you have quietly lost half your bandwidth.
show lacp neighbor and the SA flags
show port-channel summary tells you the local view. To see what the far end is claiming, look at the neighbor table:
show lacp neighbor interface port-channel1 | head lines 20
Flags: S - Device is sending Slow LACPDUs F - Device is sending Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
port-channel1 neighbors
Partner's information
Partner Partner Partner
Port System ID Port Number Age Flags
Eth1/3 32768,52-1f-ff-1f-1b-8 0x103 13 SA
LACP Partner Partner Partner
Port Priority Oper Key Port State
32768 0x8000 0x3d
Partner's information
Partner Partner Partner
Port System ID Port Number Age Flags
Eth1/4 32768,52-1f-ff-1f-1b-8 0x104 13 SA
LACP Partner Partner Partner
Port Priority Oper Key Port State
32768 0x8000 0x3d
SA is two independent flags stuck together, and it is the single most useful field here.
S means the partner is sending slow LACPDUs, one every 30 seconds, which is the default. A means the partner is in Active mode, so it initiates negotiation rather than waiting to be spoken to. Together: the far end is a healthy default-timer LACP speaker that will start the conversation. If you saw SP on both ends you would have two passive devices waiting for each other forever, and the bundle would never form. At least one side must be Active.
The S flag also has a failure-timing consequence. With slow LACPDUs the partner sends every 30 seconds and the timeout is three missed PDUs, so it can take up to 90 seconds to declare a member dead through LACP alone. Fast rate (lacp rate fast, giving one-second PDUs and a three-second timeout) brings that down. On a physical link failure this rarely matters because loss of light kills the member instantly, but on a link that stays up while the far end stops speaking, the LACP timeout is the only thing that will catch it.
Two other fields are worth a glance. Both members report the same System ID of 32768,52-1f-ff-1f-1b-8, which is the partner's priority and system MAC. If those did not match across members you would be bundling links to two different devices, and LACP would refuse to aggregate them (which is precisely the miscabling that static mode on lets through). The Oper Key of 0x8000 is identical on both members too, and it must be: members with different operational keys cannot be aggregated.
The Port State value of 0x3d is the raw LACP state octet. It decodes as bits for Activity, Aggregation, Synchronisation, Collecting and Distributing set, with the Timeout bit clear, which independently corroborates the SA flags: active, aggregatable, in sync, and using the slow timer. Collecting and Distributing both being set is the definition of a member that is receiving and sending user traffic.
A suspended member, produced on purpose
Here is the state everyone ends up googling at 2am. To create it, the lab removed channel-group from LEAF2's Ethernet1/4, leaving LEAF1's Ethernet1/4 physically up but with no LACP partner:
LEAF1# show port-channel summary
1 Po1(SU) Eth LACP Eth1/3(P) Eth1/4(s)
LEAF1# show interface Ethernet1/4 | include "is down|is up|Members"
Ethernet1/4 is down (suspended(no LACP PDUs))
admin state is up, Dedicated Interface
Look at what the bundle is doing. Po1(SU): still up, still switching, still carrying traffic on Eth1/3. Nothing alarmed, nothing flapped, and if you were watching an interface-status dashboard that only tracks port-channels you would see a perfectly healthy link. You are running at half capacity and the bundle will not tell you.
Why (s) is not the same as down
This is the distinction that makes the whole state readable. A (D) member is a Layer 1 problem: no link, no signal, nothing to negotiate with. Fix the cable, the transceiver, or the far-end shutdown, and it comes back.
A (s) member is a Layer 2 protocol decision. The link is up. Frames could physically traverse it. LACP has looked at the situation, concluded it cannot safely bundle this member, and put the port into a state where it will not forward user traffic. That refusal is a feature: an unbundled member forwarding traffic into a topology that thinks it is part of a bundle is a loop or a black hole, depending on what is on the other end. Suspension is NX-OS deciding that half a bundle is better than a broken one.
The parenthetical reason is the diagnosis. suspended(no LACP PDUs) means exactly what it says: the local port is sending LACPDUs and receiving nothing back. That has a short list of causes.
The admin state is up signature
Read those two lines together one more time:
Ethernet1/4 is down (suspended(no LACP PDUs))
admin state is up, Dedicated Interface
An interface that is down while admin state is up is the fingerprint of a protocol-driven suspension. Those two lines describe different layers of the same port. admin state is the configured intent: nobody typed shutdown, the operator wants this port in service. is down is the operational result: something below or beside the configuration is refusing.
Compare the alternatives. A port someone shut down reads admin state is down, and no amount of cable-swapping will help. A port with a dead link reads is down with a Layer 1 reason such as link-not-connected, and the fix is physical. Only the protocol-suspended case gives you an administratively willing port that is operationally refusing, and NX-OS prints the reason in brackets so you do not have to guess which protocol did it. The same pattern shows up for other reasons on Nexus (error-disable conditions, and the vPC consistency failures covered in the vPC explainer), and the reading is always the same: config says yes, protocol says no, and the bracket tells you which protocol.
In the lab the port was restored by putting the far end back into the bundle with channel-group 1 mode active, and the member returned to (P). That is the other useful property of suspension: it is self-clearing. Fix the negotiation and LACP unsuspends the port on its own, no shut/no shut required.
A troubleshooting order that works
When a member will not join, work outward rather than jumping to the cable:
- Read the member flag first.
(D)sends you to Layer 1.(s)sends you to LACP.(I)means the port is running standalone.(M)means min-links. These are four completely different investigations and the flag picks one for you. - Confirm the process is running on both ends.
show featureand look for lacp. A missing feature on the far end suspends your member with no local misconfiguration at all. - Check the mode combination. Active/active and active/passive both work. Passive/passive and anything paired with
mode ondo not. - Check the partner system ID and oper key across members. Different system IDs mean you are cabled to two devices; different keys mean the members are not compatible for aggregation.
- Only then look at the physical layer, and only for members flagged
(D).
One habit worth building: alert on member count, not on bundle state. Every monitoring system will catch Po1 going down. Very few catch Po1 staying up with one member suspended, and that is the failure that silently halves your capacity between a leaf pair or, worse, between a leaf and a spine.
Where this leads
A port-channel between two switches is useful on its own, but on Nexus it is more often a building block. The same port-channel1 from this lab was later promoted to a vPC peer-link with a single command, and the flags legend, the suspension behaviour and the LACP timers all carry over unchanged into that role. That progression is covered in what vPC is and how to read its health, and both fit into the wider spine-leaf data center fabric series alongside the underlay, VXLAN and EVPN pieces built on this same four-node lab.
Key Takeaways
feature lacpcomes first.channel-group ... mode activeis rejected outright without it, not deferred, and onlymode onworks without the process.- Configure members as a range and put trunking on the logical
port-channelinterface, not on the physical ports. - In
show port-channel summary, the bundle flags (SU) and the member flags (P,D,s,I,H,M) answer different questions. Read both. SAinshow lacp neighbormeans the partner sends slow LACPDUs and is in Active mode. At least one end must be Active or the bundle never forms.(s)suspended is a protocol refusal on a physically healthy link.(D)down is a Layer 1 fault. They need completely different troubleshooting.Ethernet1/4 is downalongsideadmin state is upis the signature of protocol suspension, and the bracketed reason names the protocol.- A bundle can report
(SU)while running on half its members. Monitor member count, not just bundle state.