Dell OS10 VLT Setup: Step-by-Step Virtual Link Trunking Guide

2026年8月31日 LOG admin

Dell OS10 does not support physical stacking — instead, two identical PowerSwitch units join into a Virtual Link Trunking (VLT) domain: a single logical extended switch with active-active ports, high availability, and no spanning-tree blocked uplinks for the connected servers or switches. Based on Dell's official KB 000102901, this guide walks through the complete VLT setup: spanning-tree mode, the VLT domain and VLTi interconnect, priority and MAC, backup link, and the VLT port-channel that faces the attached device.

Everything in the KB is expanded below with the operational detail that decides whether the design survives a failure: what the peers must have in common, why the VLTi must not be a switchport, how the primary role is really elected, what the backup link is for, and exactly which ports drop when the interconnect dies. If you are building this in a lab first — which you should — the verification and failure sections near the end are the parts worth rehearsing before the change window.

Why VLT Exists in OS10

Classic stacking fuses two or more switches into one control plane with a shared backplane-like fabric. OS10 deliberately does not do that on the S- and Z-series: every switch remains independently managed, and redundancy between pairs is delivered by VLT instead. The result feels similar from the server's point of view — a dual-homed host sees what looks like one switch and can run an ordinary LACP bond across both peers — but the failure domains, upgrade procedures and troubleshooting workflows stay per-switch.

Practically, VLT buys three things. First, active-active forwarding: both peers can carry traffic for the same VLAN simultaneously, so you do not pay the "half your uplinks are blocked by spanning tree" tax. Second, fast convergence: a peer failure moves traffic without waiting for STP timers. Third, a stable LACP view for the downstream device: the bond stays up while one member's parent switch is rebooting, because the LACP actor IDs are synchronised between the peers.

VLT is a pair technology, not a fabric technology. If you need more than two switches in a highly available access layer, you build multiple VLT pairs and connect them with standard L2/L3 links — or you move to a VXLAN EVPN fabric, where VLT becomes the access-side multihoming mechanism.

Requirements and Design Rules Before You Start

Exactly two switches per VLT domain. A domain ID (1-255) identifies the pair; it must match on both peers.
Identical platforms and software. Use the same model and the same OS10 release on both peers. Mixed versions will come up, but you are then debugging differences in feature behaviour under load.
A dedicated VLTi. The interconnect carries control traffic and, when required, data traffic between peers. At least one link is mandatory; two or more physical links in the VLTi is the normal recommendation. The VLTi interfaces must have no switchport applied, and they are not LAG members.
A backup (heartbeat) link. In practice this is the management network. It exists purely so that the peers can distinguish "the VLTi failed" from "my peer has died" — a distinction that decides whether the secondary shuts its VLT ports or takes over the primary role.
LACP for every VLT port-channel. VLT LAGs must be dynamic LACP LAGs. Static LAGs cannot be VLT port-channels.
A unique VLT MAC. Configure the same vlt-mac on both peers and pick an address that is not in use anywhere else in the L2 domain. If you skip this, the VLT port-channel on the secondary can flap when the primary goes down, which produces exactly the kind of small traffic interruption VLT was supposed to remove.
Spanning tree kept enabled. RSTP or RPVST+ on the VLT ports, as configured in step 1 below.

Step 1: Configure Spanning Tree Mode

Spanning tree is enabled by default and recommended to prevent loops in the VLT domain. RPVST+ (default) and RSTP are supported on VLT ports:

OS10# configure terminal
OS10(config)# spanning-tree mode rstp
OS10(config)# spanning-tree mode rapid-pvst

Pick one mode and use it consistently across the whole L2 domain, including any non-Dell switches in the path. RPVST+ gives you a per-VLAN topology, which is usually what you want in a mixed-vendor environment because it mirrors Cisco's PVST+ behaviour; RSTP gives you a single topology with faster convergence and fewer instances to reason about. Leaving spanning tree enabled on VLT ports is not optional — the VLTi itself is not visible to STP, so an accidental physical loop outside the VLT LAGs has nothing else to break it.

Step 2: Create the VLT Domain and VLTi

The VLT interconnect (VLTi) carries control traffic and data between the peers. Remove switchport mode from the VLTi ports and designate them as discovery interfaces:

OS10# configure terminal
OS10(config)# interface range ethernet 1/1/1-1/1/2
OS10(conf-range-eth1/1/1-1/1/2)# no switchport
OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# discovery-interface ethernet 1/1/1
OS10(conf-vlt-1)# discovery-interface ethernet 1/1/2

Three details are easy to get wrong here. The domain ID must be identical on both peers — 1 in this example, but any value from 1 to 255 works as long as the pair agrees. The no switchport is what turns the ports into routed (non-switched) interfaces so they can carry the VLT control traffic rather than being treated as a normal L2 port; leaving them as switchports is a classic reason for a domain that never reaches "up". And each physical member of the VLTi is listed individually with discovery-interface — the VLTi is defined by its members, not by a port-channel wrapper.

Size the VLTi with headroom in mind. On a pair of S5212F-ON switches, one or two 100G QSFP28 links is the usual choice; on 25G platforms, a pair of 25G links covers most access usage. In a VXLAN environment the VLTi must also carry the traffic that the peers exchange to reach each other's VTEPs, so capacity planning matters much more than it does in a plain L2 access pair.

Step 3: Priority, VLT MAC and Backup Link

OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# primary-priority 4096   (primary peer)
OS10(conf-vlt-1)# primary-priority 8192   (secondary peer)
OS10(conf-vlt-1)# vlt-mac 00:11:22:33:44:55
OS10(conf-vlt-1)# backup destination 100.1.1.2

The VLT MAC must be unique and identical on both peers; the backup destination is the management/backup link used when the VLTi fails.

Read the priority values as a "lowest wins" election: 4096 on one peer and 8192 on the other gives you a deterministic primary, and keeping the values well apart means a single reconfiguration will not accidentally flip the roles. On the primary run backup destination <secondary mgmt IP>; on the secondary, point it at the primary's management address. The backup destination must be reachable through a path that does not traverse the VLTi — if the heartbeat rides over the interconnect you have gained nothing, because a VLTi failure takes the heartbeat with it and both peers conclude that the other has died.

Two optional knobs are worth knowing at this point. delay-restore sets how long the secondary waits before bringing up its VLT ports and orphan ports after a role change or a reload; the default is generous (90 seconds in the output shown below), and shortening it speeds convergence at the cost of hitting the switch while it is still learning its MAC table. peer-routing is the L3 companion feature and is covered in step 5.

OS10(conf-vlt-1)# delay-restore 60
OS10(conf-vlt-1)# peer-routing
OS10(conf-vlt-1)# peer-routing-timeout 60

Step 4: Configure the VLT Port-Channel

Create the LAG to the end device using the same LAG number on both peers, and mark it as a VLT port-channel:

OS10# configure terminal
OS10(config)# interface port-channel 5
OS10(conf-if-po-5)# vlt-port-channel 5
OS10(config)# interface ethernet 1/1/10
OS10(conf-if-eth1/1/10)# channel-group 5 mode active

VLT port-channels are LACP-negotiated (dynamic) LAGs, so use channel-group <n> mode active on both peers.

The LAG number and the value passed to vlt-port-channel must match on both peers, and every member interface must be a member of the same LAG ID on both sides. Add the members on each peer as you would for any LACP LAG; the crucial difference is that the peer switch will now negotiate with the server using a synchronised LACP system ID, so the server sees a single LACP neighbour instead of two.

OS10(config)# interface range ethernet 1/1/10-1/1/11
OS10(conf-range-eth1/1/10-1/1/11)# channel-group 5 mode active
OS10(conf-range-eth1/1/10-1/1/11)# no shutdown

Do not mark a LAG as a VLT port-channel and then configure it as a static LAG — OS10 will reject or ignore the combination, and the downstream device will see an unstable bundle. Also keep the member count symmetric: if peer A has two members and peer B has one, the server's LACP bundle will keep negotiating as links come and go.

Step 5: Optional Layer 3 — VLT Peer Routing

If the VLT pair also provides the default gateway for the attached hosts, enable peer routing so that either peer can route traffic on behalf of the other, which keeps an active-active path for L3 flows during a link failure:

OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# peer-routing
OS10(conf-vlt-1)# peer-routing-timeout 60
OS10(conf-vlt-1)# end
OS10# show running-configuration vlt

Peer routing synchronises the router MAC between the peers. Without it, a host that sends a frame to the router MAC learned on the "wrong" peer will have it dropped after a topology change until ARP and MAC entries age out. For gateway designs, pair peer routing with VRRP active-active or with an anycast-style SVI so both peers answer for the same virtual address.

Verify the VLT Domain

OS10# show vlt 1
OS10# show vlt 1 vlt-port-detail
OS10# show interface port-channel summary

Confirm both peers show the VLT domain up, the VLTi is operational, and the port-channel status is Active.

The main status output is compact but it tells you everything that matters. On a healthy pair the primary shows Role: primary, the peer row shows the partner's system MAC and a status of up, and the VLTi link status line reports the interconnect as up. Typical fields to confirm:

OS10# show vlt 1
Domain ID: 1
Unit ID: 1
Role: primary
Version: 2.0
Local System MAC address: f4:8e:38:5f:3d:ca
Role priority: 4096
VLT MAC address: 00:11:22:33:44:55
IP address: 100.1.1.1
Delay-Restore timer: 90 seconds
Peer-Routing: Enabled
Peer-Routing-Timeout timer: 60 seconds
VLTi Link Status
 port-channel1000: up
VLT Peer Unit ID  System MAC Address   Status  IP Address   Version
2                 f4:8e:38:5f:3d:cb  up      100.1.1.2    2.0

For deeper checks, use the port-detail view to confirm that the downstream LAG is reported as a VLT port-channel on both peers, the backup-link view to confirm the heartbeat, and the mismatch view to catch inconsistencies between the two halves of the domain:

OS10# show vlt 1 vlt-port-detail
OS10# show vlt 1 backup-link
OS10# show vlt mismatch
OS10# show spanning-tree virtual-interface
OS10# show running-configuration vlt
OS10# show vlt 1 delay-restore-orphan-port

show vlt mismatch is the fastest way to spot configuration drift between peers, and show spanning-tree virtual-interface confirms that STP sees the VLT pair as one logical bridge rather than two competing roots. If you are troubleshooting a domain that will not come up, work through the checks in Dell OS10 VLT troubleshooting with show vlt commands before changing anything.

Failure Behaviour: What Actually Drops

Understanding the failure modes is what separates a VLT design that is safe from one that surprises you at 3 a.m.

VLTi fails, heartbeat still up. The peers exchange node-liveliness information over the backup link and conclude that the peer is alive but the interconnect is gone. The secondary VLT peer shuts down its VLT ports, so the attached device keeps a single, loop-free active path through the primary. This is the designed behaviour — do not "fix" it by disabling the mechanism.
Primary peer dies. Both the VLTi and the heartbeat fail, and the surviving secondary takes over the primary role. After the delay-restore timer, its VLT ports and orphan ports come up and forward again.
Orphan ports. Ports on a VLT peer that are not members of a VLT LAG are orphans. After an election, the primary keeps them up while the secondary brings them down and starts the delay-restore timer; they come back after the timer expires. A single-homed server on an orphan port therefore loses connectivity during a peer failover, which is exactly why dual-homed LACP attachments are the recommended design.
Downstream device failure. If the attached server or switch loses one member link, LACP keeps the bundle up on the remaining member and neither VLT peer changes role. Nothing in the VLT domain needs to reconverge.

The lesson from all four cases is the same: the backup link is not optional. Without a heartbeat path outside the VLTi, OS10 cannot tell a broken cable from a dead switch, and the pair makes the wrong decision in one of the two cases.

Common Mistakes and Constraints

Using the same MAC address range for vlt-mac as a real device in the L2 domain, which breaks forwarding for that host.
Configuring a different domain ID or a different LAG number on the two peers, which leaves the domain down with no obvious error in the config.
Leaving the VLTi ports as switchports, or adding them to a LAG so they are no longer individual discovery interfaces.
Running the heartbeat across the VLTi, so a single cable fault looks like a peer failure.
Forgetting that VLT pairs two switches only — a third switch cannot join an existing domain.
Saving the configuration on one peer only. Both halves of the pair must be saved with write memory or copy running-configuration startup-configuration.