Dell OS10 Port-Channel Configuration: LACP Step-by-Step

2026年8月25日 LOG admin

Link aggregation is the foundation of resilient switch-to-switch and switch-to-server connectivity, and on Dell PowerSwitch S-series hardware running SmartFabric OS10 the process is refreshingly straightforward. This article walks through the official Dell Technologies procedure for configuring port-channels with LACP, covering static versus dynamic channels, the exact CLI sequence, and the verification commands that confirm your aggregated link is healthy. Following these steps will let you double your inter-switch bandwidth while eliminating single points of failure in the data path.

Why Link Aggregation, and When LACP Beats a Static Channel

A single 25 or 100 GbE uplink is a single point of failure. A port-channel solves two problems at once: it multiplies the available bandwidth between two devices, and it keeps traffic flowing when one member link fails, because the surviving links inherit the logical interface. On Dell OS10 that logical interface is a port-channel, and the members are physical ports bound to it with channel-group.

The choice between a static channel and a dynamic (LACP) channel is the first decision to make, and getting it wrong is the most common cause of mysterious outages:

Static port-channel — members are bundled with channel-group 1 mode on. No protocol negotiation happens, so both ends must be configured identically. If one side is misconfigured, the link can form a loop rather than fail, because neither end notices the mismatch.
Dynamic port-channel (LACP, IEEE 802.1AX) — members are bundled with mode active or mode passive. The two ends exchange Link Aggregation Control Protocol data units and only bundle links that agree on speed, duplex, VLAN state and mode. A misconfiguration results in an unbundled link, not a loop.

Use LACP whenever both ends support it — that is, almost always for switch-to-switch and switch-to-server connections. Reserve static channels for devices that genuinely cannot speak LACP, and document them, because they carry real risk.

Port-Channel Basics: Static vs. Dynamic (LACP)

Port-channels on OS10 can be static or dynamic. Dynamic port-channels are configured using the Link Aggregation Control Protocol (LACP) and operate in one of two modes:

Active - the interface is placed in the Active Negotiation state; an active port can form a port-channel with another port in Active or Passive mode.
Passive - the interface is in the Inactive Negotiating state, but LACP still runs on the link; a passive port responds to active negotiation requests but will never initiate a channel with another passive port.

LACP Modes and the Negotiation State Machine

LACP runs per member link and moves each link through five state bits — LACP_Activity, LACP_Timeout, Aggregation, Synchronization, Collecting, Distributing, commonly written as the six that include Timeout. In CLI output you will see them abbreviated, and a healthy member shows Aggregation, Synchronization, Collecting and Distributing all set while the link is Up.

The two modes control only who initiates, not whether LACP is used:

Local mode	Remote mode	Result
Active	Active	Channel forms (normal design)
Active	Passive	Channel forms
Passive	Active	Channel forms
Passive	Passive	No channel — both sides wait for the other to start
Active/Passive	Not configured (mode on)	No channel — one side sends LACPDUs the other ignores

That last row is the classic failure: a server administrator configures a Linux bond with mode=4 (802.3ad) while the switch port is left unbundled or in static mode. The switch never sees a partner, the server never gets a synchronised partner, and the bond refuses to come up. Configuring mode active on the switch and mode=4 with lacp_rate=fast on the Linux side — or mode active on both switches — avoids the ambiguity entirely.

Prerequisites and Topology

For this example, switch #1 and switch #2 exist with two links between them on ports 1/1/33 and 1/1/34. Both switches must be reachable via console or management IP, and you log in with the default OS10 credentials (user admin, password admin).

Step-by-Step OS10 Port-Channel Configuration

Step 1: Enter Global Configuration Mode

OS10# configure terminal
OS10(config)#

Step 2: Create Port-Channel 1

OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# exit
OS10(config)#

Step 3: Select the Member Interfaces

OS10(config)# interface range ethernet 1/1/33-1/1/34
OS10(conf-range-eth1/1/33-1/1/1/34)#

Step 4: Add Members with Active LACP

OS10(conf-range-eth1/1/33-1/1/1/34)# channel-group 1 mode active
OS10(conf-range-eth1/1/33-1/1/1/34)# end
OS10#

Repeat the same procedure on switch #2. Using mode active on both ends ensures LACP negotiation completes and both links bundle into a single logical channel.

Adding VLANs, MTU and LACP Timers to the Port-Channel

Once the members are bundled, the port-channel is a normal switchport and everything you would configure on a physical interface goes on the logical one. A trunk toward a server or another switch usually looks like this:

OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# description UPLINK-TO-SW2
OS10(conf-if-po-1)# switchport mode trunk
OS10(conf-if-po-1)# switchport trunk allowed vlan 10,20,30
OS10(conf-if-po-1)# mtu 9216
OS10(conf-if-po-1)# no shutdown
OS10(conf-if-po-1)# exit

Never configure VLAN membership or mtu on the individual member interfaces — OS10 inherits them from the port-channel, and setting them per member either has no effect or produces an inconsistent bundle that will not synchronise. If a member refuses to join, the first thing to check is that no per-port configuration conflicts with the channel.

Two LACP timers are worth knowing. The default long timeout is 30 seconds between LACPDUs with a 90-second hold time; short timeout sends every second with a 3-second hold time. Short timers detect failure faster at the cost of more control traffic, and are the right choice for ports facing servers that also support fast rate:

OS10(conf-if-po-1)# lacp rate fast

For a server-side view of the same negotiation — hashing policies, lacp_rate, and how the kernel distributes flows across members — see Linux bonding 802.3ad: LACP rate and hash policy. If you are bundling uplinks inside a hypervisor instead, Proxmox VE VLAN-aware bridges and LACP bonds walks through the equivalent on the host side.

Verifying the Port-Channel

Confirm the configuration with:

OS10# show interface port-channel summary

Check LACP state and counters with show lacp and show lacp port-channel 1. The channel members should show an Up/Up state with LACP in the Bundled or Collected state. Remember to save your work with write memory so the configuration survives a reload.

Reading the Verification Output

Knowing what "good" looks like saves a support call. After the configuration in the previous step, show interface port-channel summary should report the channel as up with both members listed under it, and show lacp port-channel 1 should show the local and partner information agreeing:

OS10# show lacp port-channel 1

Port-channel1 is up, line protocol is up
Flags: S - Device is requesting Slow LACPDUs
       F - Device is requesting Fast LACPDUs
       A - Device is in Active mode       P - Device is in Passive mode

Local information:
                        LACP port     Admin   Oper    Port        Port
Port       Flags  State  Priority      Key     Key     Number      State
Eth 1/1/33 SA     bndl   32768         0x1     0x1     0x21        0x3d
Eth 1/1/34 SA     bndl   32768         0x1     0x1     0x22        0x3d

Partner information:
                        LACP port     Admin   Oper    System
Port       Flags  Priority  Dev ID   Key     Key     ID
Eth 1/1/33 SA     32768     0x8000   0x1     0x1     00:11:22:33:44:55
Eth 1/1/34 SA     32768     0x8000   0x1     0x1     00:11:22:33:44:55

Four things to confirm in that output. First, the per-member port state should end in bndl (bundled) rather than indiv (individual). Second, both members must show the same Oper Key — that is the aggregator they joined. Third, both members must show the same Partner System ID; different IDs mean the cables run to different devices. Fourth, the LACP Partner information must be populated at all: if it is empty, the remote end is not sending LACPDUs and the channel is only half-negotiated.

For a continuous view, show lacp counters 1 on OS10 shows the LACPDUs transmitted and received per member. Counting stops moving on a member that is up but no longer receiving means the partner stopped talking — often the first sign of a one-way fibre or a peer that lost power. Pair that with show interface ethernet 1/1/33 to catch error counters, and with show mac address-table interface port-channel 1 to prove that traffic is actually being forwarded over the aggregate.

Planning Port-Channel Sizes and Cabling

Two practical design notes before you commit to a bundle size. First, the number of members is limited by hardware — most S-series platforms cap a port-channel at 8 or 16 active members — and adding members beyond what the hash can spread across yields diminishing returns. With a typical 5-tuple hash, a bundle of two 25 GbE links saturates at 50 GbE only when there are many simultaneous flows; a single large flow still uses one member.

Second, keep the members on the same line card or the same asic group where the platform allows it, and always spread a two-link bundle across modules so that a single line card failure cannot take the whole channel down. When you cable, label both ends and record which physical port maps to which logical channel: the fastest troubleshooting of a half-broken bundle starts with knowing what the intended topology was.

Finally, verify that the feature is licensed and the interface type supports LACP before planning the design around it. On OS10, show interface port-channel summary lists every channel regardless of state, so an existing but unbundled channel is visible immediately — a common finding on switches inherited from another team.

Troubleshooting Common Port-Channel Problems

Almost every port-channel incident falls into one of a handful of categories. Work through this list before opening a case:

Members show "not bundled" or stay in a non-synchronised state. A parameter mismatch between the two ends: speed, duplex, VLAN membership, MTU or LACP mode. Compare show interface port-channel summary on both switches.
Only some members come up. The remaining physical links are usually shut or have an error — check for CRC errors and interface flaps with show interface ethernet 1/1/33.
Channel is up but throughput is worse than a single link. Traffic is being hashed onto one member because the flow set is small (for example a backup between two hosts, which is one flow). Link aggregation multiplies capacity across many flows, not within one flow.
Intermittent packet loss under load. A member link negotiated half duplex or is dropping on an undersized MTU. Confirm with show interfaces counters and a large-packet ping across the channel.
The bundle disappears after a reload. The configuration was never written. Always finish with write memory.
Members are bundled but traffic loops. Someone used static mode where LACP was intended. Reconfigure to mode active.

A useful sanity check on the Dell side is that the LACP partner information should list the peer's system ID and the same port-channel key on every member. If one member reports a different partner system ID, cabling has been crossed between two switches.

Port-Channels, VLT and Switch-to-Switch Design

On OS10, port-channels are also the transport for VLT (Virtual Link Trunking), Dell's MLAG implementation. VLT lets two switches act as one logical device toward downstream servers and switches: the inter-switch link carries the VLT peer traffic, and downstream devices can run a normal LACP port-channel with one member landing on each switch. That gives an active/active path with no spanning-tree blocking and sub-second failover if a switch or link dies.

If you intend to use VLT, the sequencing matters — bring up the VLT interconnect and the peer link before adding downstream port-channels, and verify with show vlt brief and show vlt redundancy. Failures here present as a downstream channel that loses half its members on a single event. The diagnostic workflow is covered in Dell OS10 VLT troubleshooting with show vlt commands.

Whether you bundle across a stack, a VLT pair or a plain two-switch pair, keep spanning tree in mind: a port-channel should be treated as one logical link by STP, and consistent VLAN-to-STP-instance mapping on both ends avoids the classic "one member forwarding, one blocking" outcome. See Dell OS10 spanning-tree: RSTP and Rapid-PVST for the configuration on the same platform.