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.

VLT Lab Network Diagram

VLT Lab Network Diagram


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.

Force10_s4810_2_switch - need to make port modifications

Force10_s4810_2_switch - need to make port modifications

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:

S4810_1 - "show vlt brief"

S4810_1 - "show vlt brief"


S4810_2 - "show vlt brief"

S4810_2 - "show vlt brief"


S4810_1 - "show vlt statistics"

S4810_1 - "show vlt statistics"


S4810_2 - "show vlt statistics"

S4810_2 - "show vlt statistics"



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.
S4810_1 - no ports being blocked by RSTP

S4810_1 - no ports being blocked by RSTP


S4810_2 - no ports being blocked by RSTP

S4810_2 - no ports being blocked by RSTP


Twitt

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

10 Responses to “Dell Force10 – Layer 2 Multipathing via Virtual Link Trunking (VLT)”

  1. Spoonfork says:

    Nice explanation but I don’t agree with the following point,

    “For redundanacy purposes, many users would implement stacking and then run spanning tree protocol (STP) to block redundant links.”

    If you stacked S4810_1 and S4810_2 you could create the same LAG from S4810_3 as per you diagram and there would be no blocked ports.
    I think it would be more correct to state that the advantage here is that the VLT domain allows for independent upgrade of S4810_1 and S4810_2 firmwares without an outage were as the stack would require a complete outage.

  2. Humair says:

    Hi,

    Yes – I had meant one thing but wrote something else resulting in a misstatement. In the past I have seen engineers stack at the access layer and then go up to two separate upstream L2 switches and employ STP to block redundant paths which is not a recommended solution. That’s what I meant to state. I have corrected this.

    Also added why VLT is preferred over stacking due to its dual control plane mechanism and hitless nature. In addition, as you mentioned, it allows for switch firmware to be upgraded without bringing down both switches.

    Thanks for catching this.

    Humair

  3. Johnny says:

    I wish the would add this to the c series switches :)

  4. srps says:

    Nice article. Thanks.

  5. Johnny says:

    question can you have 2 VLTi’s? lets say I need one at 1500 mtu and the second at 9000?

  6. Humair says:

    What is the use case or need for this? The end device is where the MTU is set. …. Since the VLTi is just a pipe like any other path between end devices, why not just set it to the max MTU you need? – it will have no effect on your frames at 1500 bytes but will also handle frames at 9000 bytes. Just configure the MTU in your network path(s) to the largest frame size you expect if you desire no fragmentation. You can have one VLTi for a given VLT domain but you can add additional ports/links to the VLTi as needed.

  7. Julia says:

    Hi,

    Do you have instructions on how to upgrade two Force10 MXL switches in VLT configuration, please?

    I am confused about the upgrade when the boot loader and the boot flash need to be upgraded as well.
    I am upgrading to 9.6, on partition B: On partition A: I have already the required version of the boot flash, and the boot selector show as being the right version.
    My question is, do I need to upgrade both the boot flash and the boot selector on B: where the new firmware is going to be installed, or just the boot flash?
    Also, I am confused about the order of reloading, if I need to upgrade the boot flash/selector, then reload, or I just upgrade the image, the boot flash/selector all on B: and then reload.

    Thanks

  8. KAMRAN says:

    Hi Julia,

    Your best bet is to contact Dell TAC support (1-866-203-6875) for Force10 products. They will ask you for the service TAG number from MXL.

    BTW Which code version you are running on MXLs?

    Refer to release notes of the release version (9.6) and check if upgrade directly to this version is allowed. I believe the release notes say specifically that if you are on 8.3.12 , you can go to 9.1 or 9.2 and from there, directly to 9.6.

    Are your servers connected Active/Active in MXLs? If thhis is the case, upgrading the MXL “B” (vlt peer) shold be done without disrupting traffic on A.
    Once B is upgraded, follow the same upgrade procedure on A side.
    Once the enviornment is stable you can upgrade B side first following same procedure and then A side.

    Please make sure you are doing the upgrade inside a maintenace window.

  9. JimmyH says:

    The release notes for the firmware upgrade have a upgrade path for vlt section.

Leave a Reply

*


one × 1 =