Dell EMC SmartFabric OS10 User Guide Release 10.5.0

Configure the VLT peer liveliness check

The VLT peer liveliness mechanism checks for the availability of the peer node. The system sends periodic keep-alive messages to detect the liveliness of the peer node. You must use a different link other than the VLTi for the peer liveliness check. This link is referred to as the VLT backup link.

If the VLTi goes down, the backup link helps to differentiate the VLTi link failure from a peer node failure. If all links in the VLTi fail, the VLT nodes exchange node liveliness information through the backup link.

Based on the node liveliness information:

• If only the VLTi link fails, but the peer is alive, the secondary VLT peer shuts down its VLT ports.
• If the primary VLT node fails, both the VLTi and heartbeat fail, and the current secondary peer takes over the primary role.

Configure the VLT backup link using the backup destination {ip-address | ipv6 ipv6–address} [vrf management] [interval interval-time]. The interval range is from 1 to 30 seconds. The default interval is 30 seconds. Irrespective of the interval that is configured, when the VLTi link fails, the system checks for the heartbeat connection without waiting for the timed intervals, thus allowing faster convergence.

OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# backup destination 10.16.151.110 vrf management interval 20

OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# backup destination ipv6 1::1 vrf management interval 20

The following examples describe different cases where the VLT backup link is used:

In the following figure, the backup link is not configured:

Support for new streams during VLTi failure

If the VLTi fails, MAC addresses that are learned after the failure are not synchronized with VLT peers. Thus, instead of unicast, the VLTi failure causes a continuous traffic flood.

If the VLTi links fail, MAC and ARP synchronization does not happen, and it causes the system to flood L2 packets and drop L3 packets.

For example, as shown, after the VLTi is down, VLT peer1 learns the MAC address of Host 2:

VLT Peer 2 is not synchronized with the MAC address of Host 2 because the VLTi link is down. When traffic from Host 1 is sent to VLT Peer 2, VLT Peer 2 floods the traffic.

When the VLT backup link is enabled, the secondary VLT Peer 2 identifies the node liveliness through the backup link. If the primary is up, the secondary peer brings down VLT port channels. The traffic from Host 1 reaches VLT Peer 1 and then reaches the destination, Host 2. In this case, the traffic is unicasted instead of flooding, as shown:

Role of VLT backup link in the prevention of loops during VLTi failure

When the VLTi is down, STP may fail to detect any loops in the system. This failure creates a data loop in an L2 network.

As shown, STP is running in all three switches:

In the steady state, VLT Peer 1 is elected as the root bridge. When the VLTi is down, both the VLT nodes become primary. In this state, VLT Peer 2 sends STP BPDU to TOR assuming that TOR sends BPDU to VLT Peer 1. Due to this, VLT Peer 2 does not receive BPDU on the VLT port, but receives TOR BPDU from the orphan port. The STP in VLT Peer 2 assumes that there is no loop in the system and opens up both the VLT and the orphan ports. Opening up both the VLT and orphan ports creates a data loop and brings down the system.

When the VLT backup link is enabled, the secondary VLT peer identifies the node liveliness of primary through the backup link. If the primary VLT peer is up, the secondary VLT peer brings down the VLT port channels. In this scenario, the STP opens up the orphan port and there is no loop in the system, as shown: