When you configure VLT, the following conditions
apply.
VLT domain
A VLT domain supports two chassis members, which
appear as a single logical device to network access devices connected
to VLT ports through a port channel.
A VLT domain consists of the two core chassis, the
interconnect trunk, backup link, and the LAG members connected to
attached devices.
Each VLT domain has a unique MAC address that you
create or VLT creates automatically.
ARP tables are synchronized between the VLT peer
nodes.
VLT peer switches operate as separate chassis with
independent control and data planes for devices attached on non-VLT
ports.
One device in the VLT domain is assigned a primary
role; the other device takes the secondary role. The primary and secondary
roles are required for scenarios when connectivity between the chassis
is lost. VLT assigns the primary chassis role according to the lowest
MAC address. You can configure the primary role manually.
In a VLT domain, the peer switches must run the same
Dell EMC Networking OS software version.
Separately configure each VLT peer switch with the
same VLT domain ID and the VLT version. If the system detects mismatches
between VLT peer switches in the VLT domain ID or VLT version, the
VLT Interconnect (VLTi) does not activate. To find the reason for
the VLTi being down, use the show vlt statistics command
to verify that there are mismatch errors, then use the show
vlt brief command on each VLT peer to view the VLT version
on the peer switch. If the VLT version is more than one release different
from the current version in use, the VLTi does not activate.
The chassis members in a VLT domain support connection
to orphan hosts and switches that are not connected to both switches
in the VLT core.
VLT interconnect (VLTi)
The VLT interconnect can consist of 1G or 10G ports. A maximum
of eight ports are supported.
The port channel must be in Default mode (not Switchport
mode) to have VLTi recognize it.
The system automatically includes the required VLANs
in VLTi. You do not need to manually select VLANs.
VLT peer switches operate as separate chassis with
independent control and data planes for devices attached to non-VLT
ports.
Port-channel link aggregation (LAG) across the ports
in the VLT interconnect is required; individual ports are not supported.
Dell EMC Networking strongly recommends configuring a static LAG for
VLTi.
The VLT interconnect synchronizes L2 and L3 control-plane
information across the two chassis.
The VLT interconnect is used for data traffic only
when there is a link failure that requires using VLTi in order for
data packets to reach their final destination.
Unknown, multicast, and broadcast traffic can be flooded
across the VLT interconnect.
MAC addresses for VLANs configured across VLT peer
chassis are synchronized over the VLT interconnect on an egress port
such as a VLT LAG. MAC addresses are the same on both VLT peer nodes.
ARP entries configured across the VLTi are the same
on both VLT peer nodes.
If you shut down the port channel used in the VLT
interconnect on a peer switch in a VLT domain in which you did not
configure a backup link, the switch’s role displays in the show vlt brief command output as Primary instead of Standalone.
When you change the default VLAN ID on a VLT peer
switch, the VLT interconnect may flap.
In a VLT domain, the following software features are
supported on VLTi: link layer discovery protocol (LLDP), flow control,
port monitoring, and jumbo frames.
When you enable the VLTi link, the link between the
VLT peer switches is established if the following configured information
is true on both peer switches:
the VLT system MAC address matches.
the VLT unit-id is not identical.
NOTE If you configure
the VLT system MAC address or VLT unit-id on only one of the VLT peer
switches, the link between the VLT peer switches is not established.
Each VLT peer switch must be correctly configured to establish the
link between the peers.
If the link between the VLT peer switches is established,
changing the VLT system MAC address or the VLT unit-id causes the
link between the VLT peer switches to become disabled. However, removing
the VLT system MAC address or the VLT unit-id may disable the VLT
ports if you happen to configure the unit ID or system MAC address
on only one VLT peer at any time.
If the link between VLT peer switches is established,
any change to the VLT system MAC address or unit-id fails if the changes
made create a mismatch by causing the VLT unit-ID to be the same on
both peers and/or the VLT system MAC address does not match on both
peers.
If you replace a VLT peer node, preconfigure the switch
with the VLT system MAC address, unit-id, and other VLT parameters
before connecting it to the existing VLT peer switch using the VLTi
connection.
If the size of the MTU for VLTi members is less than 1496 bytes,
MAC addresses may not synchronize between VLT peers. Dell EMC Networking
does not recommend using an MTU size lower than the default of 1554
bytes for VLTi members.
VLT backup link
In the backup link between peer switches, heartbeat
messages are exchanged between the two chassis for health checks.
The default time interval between heartbeat messages over the backup
link is 1 second. You can configure this interval. The range is from
1 to 5 seconds. DSCP marking on heartbeat messages is CS6.
In order that the chassis backup link does not share
the same physical path as the interconnect trunk, Dell EMC Networking
recommends using the management ports on the chassis and traverse
an out-of-band management network. The backup link can use user ports,
but not the same ports the interconnect trunk uses.
The chassis backup link does not carry control plane
information or data traffic. Its use is restricted to health checks
only.
Virtual link trunks (VLTs) between access devices
and VLT peer switches
To connect servers and access switches with VLT peer switches, you
use a VLT port channel, as shown in Overview.
Up to 48 port-channels are supported; up to 16 member links are supported
in each port channel between the VLT domain and an access device.
The discovery protocol running between VLT peers automatically
generates the ID number of the port channel that connects an access
device and a VLT switch. The discovery protocol uses LACP properties
to identify connectivity to a common client device and automatically
generates a VLT number for port channels on VLT peers that connects
to the device. The discovery protocol requires that an attached device
always runs LACP over the port-channel interface.
VLT provides a loop-free topology for port channels
with endpoints on different chassis in the VLT domain.
VLT uses shortest path routing so that traffic destined
to hosts via directly attached links on a chassis does not traverse
the chassis-interconnect link.
VLT allows multiple active parallel paths from access
switches to VLT chassis.
VLT supports port-channel links with LACP between
access switches and VLT peer switches. Dell EMC Networking recommends
using static port channels on VLTi.
If VLTi connectivity with a peer is lost but the
VLT backup connectivity indicates that the peer is still alive, the
VLT ports on the Secondary peer are orphaned and are shut down.
In one possible topology, a switch uses the BMP feature
to receive its IP address, configuration files, and boot image from
a DHCP server that connects to the switch through the VLT domain.
In the port-channel used by the switch to connect to the VLT domain,
configure the port interfaces on each VLT peer as hybrid ports before
adding them to the port channel (see Connecting a VLT
Domain to an Attached Access Device (Switch or Server)). To
configure a port in Hybrid mode so that it can carry untagged, single-tagged,
and double-tagged traffic, use the portmode hybrid command in Interface Configuration mode as described in Configuring
Native VLANs.
For example, if the DHCP server is on the ToR and
VLTi (ICL) is down (due to either an unavailable peer or a link failure),
whether you configured the VLT LAG as static or LACP, when a single
VLT peer is rebooted in BMP mode, it cannot reach the DHCP server,
resulting in BMP failure.
Software features supported on VLT port-channels
In a VLT domain, the following software features
are supported on VLT port-channels: 802.1p, ingress and egress ACLs,
BGP, DHCP relay, IS-IS, OSPF, active-active PIM-SM, PIM-SSM, VRRP,
Layer 3 VLANs, LLDP, flow control, port monitoring, jumbo frames,
IGMP snooping, sFlow, ingress and egress ACLs, and Layer 2 control
protocols RSTP and PVST only.
NOTE Peer VLAN spanning
tree plus (PVST+) passthrough is supported in a VLT domain. PVST+
BPDUs does not result in an interface shutdown. PVST+ BPDUs for a
nondefault VLAN is flooded out as any other L2 multicast packet. On
a default VLAN, RTSP is part of the PVST+ topology in that specific
VLAN (default VLAN).
In a VLT domain, ingress and egress QoS policies
are supported on physical VLT ports, which can be members of VLT port
channels in the domain.
Ingress and egress QoS policies applied on VLT ports
must be the same on both VLT peers.
Apply the same ingress and egress QoS policies on
VLTi (ICL) member ports to handle failed links.
For detailed information about how to use VRRP in
a VLT domain, see the following VLT and VRRP interoperability section.
For information about configuring IGMP Snooping in
a VLT domain, see VLT and IGMP Snooping.
All system management protocols are supported on
VLT ports, including SNMP, RMON, AAA, ACL, DNS, FTP, SSH, Syslog,
NTP, RADIUS, SCP, TACACS+, Telnet, and LLDP.
Enable Layer 3 VLAN connectivity VLT peers by configuring
a VLAN network interface for the same VLAN on both switches.
Dell EMC Networking does not recommend enabling peer-routing
if the CAM is full. To enable peer-routing, a minimum of two local
DA spaces for wild-card functionality are required.
RSPAN and ERSPAN are supported on VLT.
FRRP is supported only on the VLTi. This feature
enables configuration of an FRRP ring through VLTi. However, FRRP
is not supported on any other VLT port-channel except for VLTi.
Software features supported on VLT physical ports
In a VLT domain, the following software features
are supported on VLT physical ports: 802.1p, LLDP, flow control, IPv6
dynamic routing, port monitoring, DHCP snooping, and jumbo
frames.
Software features not supported with VLT
In a VLT domain, the following software features
are not supported on VLT ports: 802.1x, GVRP,
and BFD.
VLT and VRRP interoperability
In a VLT domain, VRRP interoperates with virtual link
trunks that carry traffic to and from access devices (see Overview). The VLT peers belong to the same VRRP group and are assigned master
and backup roles. Each peer actively forwards L3 traffic, reducing
the traffic flow over the VLT interconnect.
VRRP elects the router with the highest priority
as the master in the VRRP group. To ensure VRRP operation in a VLT
domain, configure VRRP group priority on each VLT peer so that a peer
is either the master or backup for all VRRP groups configured on its
interfaces. For more information, see Setting VRRP Group
(Virtual Router) Priority.
To verify that a VLT peer is consistently configured
for either the master or backup role in all VRRP groups, use the show vrrp command on each peer.
Configure the same L3 routing (static and dynamic)
on each peer so that the L3 reachability and routing tables are identical
on both VLT peers. Both the VRRP master and backup peers must be able
to locally forward L3 traffic in the same way.
In a VLT domain, although both VLT peers actively
participate in L3 forwarding as the VRRP master or backup router,
the show vrrp command output displays one peer as
master and the other peer as backup.
Failure scenarios
On a link failover, when a VLT port channel fails,
the traffic destined for that VLT port channel is redirected to the
VLTi to avoid flooding.
When a VLT switch determines that a VLT port channel
has failed (and that no other local port channels are available),
the peer with the failed port channel notifies the remote peer that
it no longer has an active port channel for a link. The remote peer
then enables data forwarding across the interconnect trunk for packets
that would otherwise have been forwarded over the failed port channel.
This mechanism ensures reachability and provides loop management.
If the VLT interconnect fails, the VLT software on the primary switch
checks the status of the remote peer using the backup link. If the
remote peer is up, the secondary switch disables all VLT ports on
its device to prevent loops.
If all ports in the VLT interconnect fail, or if
the messaging infrastructure fails to communicate across the interconnect
trunk, the VLT management system uses the backup link interface to
determine whether the failure is a link-level failure or whether the
remote peer has failed entirely. If the remote peer is still alive
(heartbeat messages are still being received), the VLT secondary switch
disables its VLT port channels. If keepalive messages from the peer
are not being received, the peer continues to forward traffic, assuming
that it is the last device available in the network. In either case,
after recovery of the peer link or reestablishment of message forwarding
across the interconnect trunk, the two VLT peers resynchronize any
MAC addresses learned while communication was interrupted and the
VLT system continues normal data forwarding.
If the primary chassis fails, the secondary chassis
takes on the operational role of the primary.
The SNMP MIB reports VLT statistics.
Data is not available for the Topic
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\