Dell OS10 LACP Fallback for PXE Provisioning

LACP fallback is the feature that lets a port-channel be used by a device that cannot negotiate LACP — most importantly, a server attempting to PXE boot with no operating system yet. On Dell SmartFabric OS10 the commands are simple but the election timing and the VLT interaction are where provisioning runs fail. This article covers LACP fallback in detail, alongside the port-channel fundamentals it builds on and the verification output that tells you which member the switch elected.

OS10 uses the same port-channel concept as other enterprise switches but with its own command syntax, and the differences are small enough to cause real mistakes when you work across vendors daily. There is no switchport mode trunk, the mode keyword lives in the channel-group command rather than a separate LACP stanza, and LACP fallback for PXE booting has no direct equivalent on some platforms. The verification commands at the end show whether LACP actually negotiated, and which member the switch elected in fallback mode.

Static versus dynamic port-channels

Static port-channels are configured with mode on and negotiate nothing — the members are aggregated as soon as they are up. Dynamic port-channels use LACP, which comes in two modes: active puts the interface in an active negotiation state and can form an aggregate with an active or passive peer; passive runs LACP but only responds, and will never form an aggregate with another passive interface.

Prefer active on at least one side. A link where both ends are passive or both ends are on will aggregate and look healthy while providing none of the protection LACP offers against a miswired or half-failed link.

Configuring a dynamic port-channel

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)# end

Configure the identical port-channel on the peer switch. If the two ends disagree on mode, the aggregate will come up but only one member will carry traffic, which is the classic "why is my link only using half the bandwidth" complaint.

Adding VLAN configuration

OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# description To-Core-Switch
OS10(conf-if-po-1)# no shutdown
OS10(conf-if-po-1)# switchport mode trunk
OS10(conf-if-po-1)# switchport trunk allowed vlan 10,20,30

VLAN configuration belongs on the port-channel interface, not on the members. OS10 inherits member configuration from the port-channel, so a VLAN applied to an individual member either has no effect or is inconsistent with the rest of the aggregate.

LACP fallback for PXE provisioning

A PXE-booting server has no operating system yet, therefore no LACP stack and no way to negotiate an aggregate. LACP fallback makes the port-channel usable anyway by electing one member to come up as a normal access port while LACP is unnegotiated.

OS10# configure terminal
OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# lacp fallback enable
OS10(conf-if-po-1)# lacp fallback timeout 30
OS10(conf-if-po-1)# lacp fallback preemption
OS10(conf-if-po-1)# end

The fallback port is elected only once the port-channel is down and the timer expires — which is why the timeout setting matters during automated provisioning: too long and the boot attempt times out before the port comes up. If the port-channel is part of a VLT domain, configure the fallback statements on both peers, or the two switches will disagree about which port is forwarding.

LACP individual — the related feature

OS10(config)# interface port-channel 1
OS10(conf-if-po-1)# lacp individual
OS10(conf-if-po-1)# mtu 9216      # workaround for 10.5.4.x MTU behaviour

lacp individual lets member ports that fail LACP negotiation continue to operate as individual ports rather than being removed from service. Note the OS10 10.5.4.x behaviour where VLANs on a LAG operating in this mode could default to a 1532-byte MTU; the manual MTU statement works around it, and the issue was resolved in 10.5.5.10 and later. If you own a 10.5.4.x estate, that combination is worth checking before an outage teaches you about it.

Verification

OS10# show port-channel summary
OS10# show interface port-channel 1
OS10# show interface port-channel summary
OS10# show lacp port-channel interface port-channel 1
OS10# show lacp port-channel interface port-channel 1 | grep fallback
OS10# show running-configuration interface ethernet 1/1/33
OS10# show vlan
OS10# show mac address-table

The summary output uses flags worth memorising: D down, I member up but inactive, P member up and active, U the port-channel is up, F fallback activated, IND LACP individual. A port-channel showing U with members marked I is the single most useful diagnostic you will read: the aggregate exists but the members are not passing traffic.

Group Port-Channel    Type   Protocol  Member Ports
1     port-channel1   (U)    Eth       DYNAMIC   1/1/33(P) 1/1/34(P)

Compare that with a fallback scenario where one member shows (I) and the port-channel shows (UF), which tells you the aggregate is up in fallback mode and the fallback port is the one carrying traffic.

Cross-vendor notes

If your fabric mixes vendors, the semantic differences are worth documenting: the LACP fallback concept appears in Arista EOS as well, with different syntax, described in Dell OS10 storm control configuration. VLT and its counterparts change where you apply configuration, and the VLT-specific checks matter far more than the port-channel commands themselves. Platform-specific behaviour such as storm control interaction with port-channels is covered in LACP fallback and static LAG configuration.

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