Dell OS10 Port-Channel Setup: LACP and Static LAG CLI

Dell PowerSwitch OS10 builds link aggregation through port-channels (also called LAGs). A port-channel can be statically configured with mode ON, or negotiated dynamically with the Link Aggregation Control Protocol (LACP) in active or passive mode. This walkthrough creates an LACP port-channel between two S-series switches, adds a VLAN to it, tunes LACP parameters and verifies the bundle with the exact OS10 show commands.

Static vs Dynamic Port-Channels on OS10

• Static (mode ON) — members are manually forced into the bundle; no negotiation frames are exchanged.
• LACP active — the port actively sends LACP PDUs and can peer with an active or passive partner.
• LACP passive — LACP runs on the link but only responds to an active partner; two passive ports never form a bundle.

The practical consequence of those three lines is that only one of the three combinations is a sensible default. Active against active is the configuration used between switches, because both ends converge as soon as the first PDU arrives and neither depends on the other's role. Active against passive is reserved for devices that support LACP but are configured to wait, such as some host NIC teaming drivers. Static ON exists for devices that cannot speak LACP at all, and it is the mode that loses the most protection: a static bundle will happily include a link that has become a forwarding-loop path, because nothing negotiates. Prefer LACP wherever the peer supports it, and treat static bundling as a documented exception rather than a shortcut.

One more naming detail: each side must use the same mode family, but the numbers do not have to match. The port-channel identifier is local to the switch, so port-channel 1 on one end may be port-channel 24 on the other, and the bundle still forms. What must match is the physical member set, the speed, and the VLAN configuration applied to the logical interface.

OS10 LACP Port-Channel Configuration

Repeat the following on both switches. Create the logical port-channel first, then add the physical members with a range:

OS10# configure terminal
OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# exit
OS10(config)# interface range ethernet 1/1/33-1/1/34
OS10(conf-range-eth1/1/33-1/1/34)# channel-group 1 mode active
OS10(conf-range-eth1/1/33-1/1/34)# no shutdown
OS10(conf-range-eth1/1/33-1/1/34)# end
OS10# write memory

For a static bundle, replace mode active with mode on. If the port-channel carries a specific VLAN, configure it in Layer 2 mode (the default on access interfaces) or make the member a trunk:

OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# switchport access vlan 10
OS10(conf-if-po-1)# end

For a trunk carrying several VLANs, or for a routed port-channel, the configuration is applied on the logical interface only:

OS10(config)# interface port-channel 1
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)# switchport trunk native vlan 999
OS10(conf-if-po-1)# end

OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# no switchport
OS10(conf-if-po-1)# ip address 10.0.1.1/30
OS10(conf-if-po-1)# end

The distinction matters during troubleshooting: VLAN membership is a property of the port-channel, never of the members. If show running-configuration interface ethernet 1/1/33 shows a VLAN statement, the configuration has been applied at the wrong level and should be removed.

Adding and Removing Members Safely

Membership changes cause a brief disruption to the affected member only, not to the whole bundle, provided the changes are made one at a time:

OS10(config)# interface ethernet 1/1/35
OS10(conf-if-eth1/1/35)# channel-group 1 mode active
OS10(conf-if-eth1/1/35)# end
OS10(config)# interface ethernet 1/1/33
OS10(conf-if-eth1/1/33)# no channel-group 1 mode active
OS10(conf-if-eth1/1/33)# end

Always check the member count after a change and confirm the remaining links carry the traffic. A bundle that quietly drops to a single member keeps forwarding, so nothing alarms until a peak load or a second failure pushes the last link over capacity — the classic "the LAG has been running on one cable for three months" incident. Alert on member count and per-member link state, not only on the port-channel being up.

Verifying the OS10 Port-Channel

OS10# show interface port-channel summary
OS10# show interface port-channel 1
OS10# show lacp port-channel
OS10# show lacp interface ethernet 1/1/33
OS10# show running-configuration interface port-channel 1

A healthy LACP bundle shows both member ports Up with status L2. show lacp port-channel displays the actor and partner system IDs plus the negotiated keys — if the partner system ID is missing, the far end is not running LACP in a compatible mode. Reading the summary output is a habit worth building: look for the member count, then the per-port state column, then the activity column that tells you whether the port is in active, passive or suspended state. A member stuck in a negotiating state usually indicates a mode mismatch; a member in a defaulted state means no LACP PDUs have been received for a period, which points at the remote side or the physical layer rather than at the configuration.

OS10# show ethernet 1/1/33
OS10# show interface ethernet 1/1/33 status
OS10# show switch

Tuning LACP on OS10

When the remote switch has a lower system priority, it wins LACP decisions. Influence the outcome from global and interface configuration:

OS10(config)# lacp system-priority 4096
OS10(config)# interface range ethernet 1/1/33-1/1/34
OS10(conf-range-eth1/1/33-1/1/34)# lacp port-priority 100
OS10(conf-range-eth1/1/33-1/1/34)# lacp rate fast
OS10(conf-range-eth1/1/33-1/1/34)# end

The two priorities control different things and are frequently confused. System priority decides which switch's port selection algorithm is authoritative, which matters when the number of usable links is smaller than the number of eligible members — for example, when a four-port bundle is built across two devices. Port priority decides which member is kept when the bundle has to shrink, so a lower value keeps the link. Setting the system priority identically on both ends, as most designs do, is safe; the lower value wins ties, and an explicit value removes any doubt about who is in control after a firmware change resets a default.

Changing the PDU rate affects convergence time. Fast rate is appropriate on links between switches where a sub-second failure detection matters; the default rate is fine for host-facing bundles and generates far less control traffic on a large fabric.

Port-Channels and VLT

In a virtual link trunking (VLT) pair, the port-channel that faces a dual-homed server or switch spans both chassis. The domain is defined once and the peer-link carries the interswitch control traffic:

OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# backup destination 10.0.0.2
OS10(conf-vlt-1)# discovery-interface ethernet 1/1/31
OS10(conf-vlt-1)# peer-link port-channel 10
OS10(conf-vlt-1)# end
OS10# show vlt 1
OS10# show vlt 1 vlt-port-detail

From the server's point of view nothing changes: it runs LACP toward a single logical switch and both members terminate on the LACP system ID of the VLT pair. When verifying, check the domain status and the per-port detail before you inspect the individual member links, because a VLT fault presents identically to a bundle problem from the server side.

Common Failure Modes

• Mode mismatch: static on one end and LACP on the other leaves the bundle up but the members down — the classic "the link is up, the LAG is not".
• VLAN applied to members: traffic works for the first member's VLAN and fails for others, or the configuration is rejected outright depending on the OS10 build.
• Speed or duplex mismatch: the member stays out of the bundle; check the physical layer and any intermediate media converter.
• MTU mismatch: small packets pass, large frames drop, and only storage or backup traffic notices.
• One-sided VLT: both switches believe they are primary, or a peer-link flaps and the bundle members go down in unison.
• Forgotten write memory: everything works until the next reload, then the bundle has never existed.

Load Balancing Across Members

A port-channel does not spread traffic evenly; it hashes each flow onto one member. A four-member bundle carrying three elephant flows uses three links and leaves the fourth idle, which is a property of the traffic rather than a fault. OS10 selects a hash policy per platform family, and the useful skill is reading the result instead of assuming the bundle is impaired:

OS10# show interface port-channel 1
OS10# show interface ethernet 1/1/33
OS10# show interface ethernet 1/1/34

If a bundle looks unbalanced, count the flows first: many small flows should spread well, while a single large flow cannot be split. Where the platform exposes a configurable hash, choose the policy that matches the traffic — Layer 3 source and destination for routed flows, Layer 4 ports when many conversations share the same address pair, and a Layer 2 policy for pure bridging. On host-facing bundles the server NIC teaming driver makes its own hashing decision, and a mismatch there explains far more "the LAG is slow" tickets than the switch ever will.

Where Features Belong on a Bundle

The single most useful rule for OS10 port-channels is that almost everything belongs on the logical interface. That includes VLAN membership, spanning-tree parameters, ACLs and QoS policies:

OS10(config)# interface port-channel 1
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)# spanning-tree rstp edge-port

Physical members carry only two things: the channel-group membership and physical-layer settings such as speed and flow control. Any VLAN or ACL statement found on a member is drift and should be removed in the next change window, because it either does nothing at all or produces a mismatch that a bundled summary will never show you.

Port-Channel Change Checklist

• Create the logical port-channel before or together with the first member.
• Use LACP active on both ends unless the peer genuinely cannot negotiate.
• Keep VLAN, ACL and QoS configuration on the logical interface.
• Confirm member count and per-member state after every change.
• Save with write memory and verify after a reload in the lab.
• Monitor per-member utilisation so a degraded bundle is visible before it saturates.

Port-channels are the foundation of OS10 high availability. See our OS10 VLT peer-routing guide for active-active Layer 3 gateways, OS10 out-of-band management configuration for the management VRF, and compare the syntax with Arista EOS port-channel and LACP configuration. For spanning-tree behaviour on the same bundle members, see the OS10 RSTP and Rapid-PVST notes.

原文链接：https://dell.com/support/kbdoc/en-us/000204226/dell-emc-networking-os10-how-to-configure-port-channels