Dell Force10 – Layer 2 Multipathing via Virtual Link Trunking (VLT)

In this blog I use one Dell Force10 S50N [FTOS 8.4.2.7] and three Dell Force10 S4810 switches [FTOS 8.3.12.1] to demonstrate Dell Force10’s layer 2 mulipathing technology called Virtual Link Trunking (VLT). With VLT, you can create a LAG for a server, switch, or any device that supports LACP to two different upstream switches.

Traditionally, a LAG from an access switch or server could only connect to a single upstream switch. For redundanacy purposes, many users would implement stacking on the upstream switches and then use a port-channel/LAG up to the stacked switch now seen as one logical entity. However, stacking is not the preferred solution here. Two main reasons for this is that stacking provides a single control plane mechanism that is managed by the master switch; there is no hitless failover. Compare this to VLT which provides a dual control plane mechanism and is hitless in nature. Additionally, when upgrading the switch firmware, the entire stack would need to be brought down. With VLT, one switch can be upgraded at a time without bringing down the other switch.

Stacking is more seen at the ToR or access layer. The ToR switches are usually stacked and VLT is then used upstream to the aggregate and core switches. However, if the ToR switch supports VLT such as the S4810 does, VLT can also be used from the switch down to the server. 1 GbE switches like the Dell S50N and Dell S60 do not support VLT, so, in these cases, stacking can still be employed.

In the least recommended approach, if no VLT or stacking is used at the aggregate layer connecting to the ToR on a layer 2 network, spanning tree protocol (STP) would need to be employed to block redundant links. This would create link and switch level redundancy. The issue with this is that you lose half the ports/bandwidth on the switch. By leveraging VLT, you can have an active-active multi-path connection from an access server/switch to two upstream switches seen as one logical entity employing a dual control plane mechanism. No putting-up with STP or blocked ports!

Layer 2 multipath support is implemented by several vendors each having their own proprietary solution. For example, Dell Force10 uses Virtual Link Trunking (VLT), Cisco uses Multichassis EtherChannel (MEC) and Virtual Port Channel (vPC), Brocade uses Multi-Chassis Trunking (MCT) and Virtual Link Aggregation Group (vLAG), and Juniper uses Virtual Chassis technology. There are also open standards such as Transparent Interconnection of Lots of Links (TRILL) and Shortest Path Bridging (SPB) that as of yet have not seen wide spread adoption in the industry.

In this lab, I will focus on Dell Force10’s VLT technology. Again, VLT allows a single device to use a LAG across two upstream devices while providing a loop-free topology using all available uplink bandwidth. From the perspective of the access layer device, VLT presents as a single logical layer 2 domain that has a virtual link trunk terminating on separate switches in the VLT domain. The VLT interconnect (VLTi) is used to synchronize states between the VLT peer switches. Both ends of the VLTi must be on 10G or 40G interfaces. For devices in the upstream network, the two VLT switches are independent L2/L3 switches. The VLT backup link monitors for VLT peer failures by sending periodic keep-alive messages between VLT peer switches.

Below is the network diagram for this lab.

The only switch configuration I don’t show in this lab is for the Dell Force10 S50N (S50N_1) simply because I am using it only for the management network and the configuration is very basic. It just involves creating a VLAN and putting the respective interfaces in the VLAN. The cable I used for the 40GbE VLTi link is a 40 GbE QSFP+ passive cable (5m); it’s a twinax copper cable.

On all S4810 switches I change the ‘reload-type’ to ‘normal’ mode since I don’t want to use the default bare metal provisioning (BMP). I do this with the “reload-type normal” command in “enable” mode. I decide to use the FortyGigE 0/60 interface on both switches as my virtual link interconnect trunk (VLTi). However, I see that on Force10_S4810_2, the forty gig port I want to use has been broken-out into 4 x 10GbE ports. Further, it looks like port TenGigabitEthernet 0/60 has been set to a stacking port making it unusable for anything else. So, the first thing I have to do is remove the stacking port configuration on “TenGigabitEthernet 0/60” and then convert TenGigabitEthernet 0/60 – 0/63 back to FortyGigE 0/60.

I remove TenGigabitEthernet 0/60 as a stack port with the below commands:

Force10_S4810_2

– enable
– conf
– no stack-unit 0 stack-group 15
– end
– wr
– reload

I then convert the TenGigabitEthernet 0/60 – 0/63 ports back to the FortyGigE 0/60 port via the below commands:

Force10_S4810_2

– enable
– conf
– no stack-unit 0 port 60 portmode quad
– end
– wr
– reload

Once that’s resolved, I continue on to the main VLT configuration which I have divided into four subparts.

A. Setup management ports and RSTP on the core peer switches

Force10_S4810_1

– enable
– conf
– int managementethernet 0/0
– ip address 20.0.0.2/24
– exit
– protocol spanning-tree rstp
– no disable
– bridge-priority 0
– exit

Force10_S4810_2

– enable
– conf
– int managementethernet 0/0
– ip address 20.0.0.3/24
– exit
– protocol spanning-tree rstp
– no disable
– bridge-priority 4096
– exit

* Also enable RSTP on Access Switch:

Force10_S4810_3

– enable
– conf
– protocol spanning-tree rstp
– no disable
– bridge-priority 8192
– exit

B. Enable all ports and create VLTi port channel on peer switches

Force10_S4810_1

– interface range tengigabitethernet 0/2 , fortyGigE 0/60
– no shutdown
– interface port-channel 100
– channel-member fortyGigE 0/60
– no shutdown
– exit

Force10_S4810_2

– interface range tengigabitethernet 0/2 , fortyGigE 0/60
– no shutdown
– interface port-channel 100
– channel-member fortyGigE 0/60
– no shutdown
– exit

C. Enable VLT on peer switches

Force10_S4810_1

– vlt domain 100
– back-up destination 20.0.0.3
– peer-link port-channel 100
– primary-priority 1
– unit-id 0
– exit

Force10_S4810_2

– vlt domain 100
– back-up destination 20.0.0.2
– peer-link port-channel 100
– primary-priority 2
– unit-id 1
– exit

D. Configure the access port-channel

Force10_S4810_1

– interface tengigabitethernet 0/2
– port-channel-protocol lacp
– port-channel 10 mode active
– interface port-channel 10
– sw
– vlt-peer-lag port-channel 10
– end
– wr

Force10_S4810_2

– interface tengigabitethernet 0/2
– port-channel-protocol lacp
– port-channel 10 mode active
– interface port-channel 10
– sw
– vlt-peer-lag port-channel 10
– end
– wr

Force10_S4810_3

– enable
– conf
– int tengigabitethernet 0/46
– port-channel-protocol lacp
– port-channel 10 mode active
– no shut
– int tengigabitethernet 0/47
– port-channel-protocol lacp
– port-channel 10 mode active
– no shut
– exit
– int port-channel 10
– sw
– no shut
– end
– wr

Once configured, I use a few CLI commands to verify all is functioning correctly:

I had setup RSTP on the core VLT peers for initial VLT setup/startup phase loop prevention. Below I confirm that no ports are being blocked by RSTP.