So what is a VLT and what does it do :

In a nutshell, VLT (Virtual Link Trunking) makes two physical Dell switches look like one switch to the connected devices, so a server or another switch can build one LAG towards both of them.

Configuration steps :

  1. Enable spanning tree - RSTP and PVST supported - step is optional, but nevertheless recommended.
configure
protocol spanning-tree rstp
bridge-priority 4096 (primary VLT switch)
bridge-priority 8192 (Secondary VLT switch)
no disable

Recommended to have a root bridge on VLT master and to set STP priority to secondary VLT switch in case if the first fails no to have topology change when other third unknown device would become a root.

  1. Configure ports for VLTi link :
configure
interface range fortyGigE 0/56 , fortyGigE 0/60
no shutdown
interface port-channel 100
channel-member fortyGigE 0/56,60
no shutdown
  1. Create VLT domain on both switches, don’t forget to create a backup-link
configure
vlt domain 1
primary-priority 10 (primary VLT switch)
primary-priority 20 (Secondary VLT switch)
back-up destination 192.168.0.2 (Primary VLT switch, management interface)
back-up destination 192.168.0.3  (Secondary VLT switch management interface)
peer-link port-channel 100

Backup links are needed to have a heartbeat messages flowing between two switches. VLT also would work without the heartbeat but then you can encounter possible split brain scenario in case of VLTi link failure.

After configuring, show vlt brief should show the peer up and the primary/secondary roles.

Now let’s attach a device to our VLT switches. On both VLT members pick up a port for redundant connection :

interface port-channel 110
no ip address
switchport
channel-member tengigabitethernet x/x/x
no shutdown
vlt-peer-lag port-channel 110

And you are ready to go.

You can tweak the stuff like dampening - just to give some time for routing and other protocols to get online after rebooting the switch ,as ports will get up faster and devices without knowing that routing protocol is not ready yet may black hole the traffic.

You can also play with spanning-tree metrics - to have interruption after reboot as small as possible.

You can check that MACs are being synced using the command :

show mac-address-table count

Some of the interesting points to remember (my notes from the user guide) :

  • with L3 routing protocols on VLT peers, set delay-restore long enough so routes are exchanged before VLT ports come up
  • only RSTP and PVST are supported with VLT
  • no stacking together with VLT
  • source on an orphan port and receiver behind a VLT port-channel can see duplicated traffic when the VLT LAG to the ToR is down, keep source and receiver on spanned VLT VLANs
  • moving hosts from non-VLT to VLT ports: part of the ARP requests land on the peer and get ignored on VLTi, arp learn-enable and mac-address-table station-move refresh-arp on both peers fixes it
  • no VLAN config on VLTi, VLANs are matched automatically
  • static LAG on VLTi, no LACP
  • VLTi supports LLDP, flow control, port monitoring, jumbo frames and DCB
  • changing VLT system MAC or unit-id while peers are up brings the link down, keep them consistent on both peers
  • VLTi down but backup link says peer is alive - VLT ports and L3 VLANs on the secondary are shut down

Overall VLT is a great thing for load balancing, redundancy and availability (you can upgrade the switches one by one without having a downtime) - In stack this wouldn’t be possible.

Notes based on the Dell Networking S4048-ON (FTOS 9) configuration guide. For current OS10 see the Dell OS10 VLT reference architecture guide.