Some of the content i had committed during the early days of the blog, specifically on VLT – continues to receive a lot of traffic/queries.
As such, this will be a brief revisit of Virtual Link Trunking. A number of enhancement have happened to the protocol since my initial posts many years ago. I cannot emphasise enough how important it is to always have a quick browse of the particular feature you are looking to implement, in the current configuration & User guides. The content that was true for a feature, on a particular code revision 4 years ago – may not, and infact will not (in its entirety) be true for the current software revision. Much could have changed. the syntax, the enhancements, maybe some depreciation around commands. Just to give an example with VLT – Per VLAN STP+ is now supported. With regards to FHRP to be used with VLT, VRRP now has an alternate in peer routing, within the DC.
Some of the limitations of VLT could be that
- It only supports two nodes/peers within a VLT domain. However, High density/bandwidth switches supporting breakouts can provide ample upfront capacity to accommodate for expansion.
- ARP response and L2/L3 protocol Scale is handled by Core, just as in the traditional 3 Tier Design’s Aggregation layer switches.
For a detailed comparison with Layer 3 Spine & Leaf, have a look at the following post:
The following is a visio i had compiled a few years ago. the basics still stay the same.
So, With VLT providing Layer 2 multi-path, you still have to implement:
- A Layer 2 Gateway redundancy, or First Hop Redundancy Protocol: your choices are VRRP, or Peer Routing. VRRP is VIP based, Peer Routing does a proxy route on behalf of the peer’s address on a given VLAN. If your VLT domain is setup as isolated, non-routed (e.g. certain storage solutions) and you are using it purely as a layer 2 fabric, then ofcourse an FHRP is not needed.
- Layer 2 Loop detection mechanism: VLT does eliminate bandwidth wastage via Active-Active links, nevertheless you will still have a spanning tree protocol in the background as a failsafe. your choices could be RSTP, PVST+ etc.
The following are some of the pointers to be mindful of with VLT. The User guides will give a more comprehensive list of dos and donts. :
- Do not enable both Stacking & VLT in conjunction. the results could be unpredictable.
- Per VLAN STP is supported (In early days of VLT, RSTP was a pre-requisite). Configure PVST before you configure VLT.
- If using VRRP, align L2 and L3 roots. i.e. Spanning Tree root and VRRP Master should ideally be the same switch to avoid sub-optimal traffic flows.
- VLT interconnect over 1G is not supported.
- VLT interconnect is used to synch L2 and L3 control plane info acrosss the VLT peers. During normal operation, it is not intended to pass user traffic. however, in case of a link/port failure that leaves the VLTi as the only means for the packets to flow to the destination, VLTi would then be used for data/user traffic.
- The backup link carries no Control plane info. It only serves as heartbeat.
- When using VRRP, both the Master and Backup switches behave as Active Forwarders.
- When using Peer Routing (Unicast Routing) as an alternate to VRRP, note that Peer-routing does not use VIP. Instead, both peers proxy/route traffic on behalf of each other. Please do have a look at my blog post focused exclusively on peer routing (from about a year ago). To facilitate Peer Routing,
- for a given VLAN, MAC addresses of the SVIs on both VLT peers, are listed in the L2 CAM tables as LOCAL_DA addresses
- IP routing tables on both peers should be fully converged.
- The following features are not supported on VLT ports:
- DHCP snooping,
- FRRP, GVRP,
- ERSPAN, RSPAN,
- VXLAN (Note that this may be about to change with support for VLT HA with Static VXLAN)
- ingress and egress QOS.
Sample Configuration : VLT with Peer Routing
This configuration uses RSTP as L2 loop prevention, and Peer Routing as FHRP.