Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Dell SmartFabric OS10 User Guide Release 10.5.3

PDF

VLT events

This section describes the impact of VLT events on BGP EVPN control plane.

VLT local port failure

No change in BGP EVPN. The MAC addresses learnt on these ports are re-directed by VLT logic and continue to be advertised in EVPN.

When VLT port fails on both VLT nodes, then the MAC is removed from both nodes and is withdrawn by both BGP speakers. This causes the MAC to be removed from all remote VTEPs.

VLT single node failure

Since each VLT node is an independent BGP speaker there is no special handling needed in BGP EVPN. The local VLT MACs continue to be advertised by EVPN on the VLT peer.

All orphan port MACs on the failed peer that were installed on the VLTi locally, are removed by VLT logic; as a result, these MAC EVPN routes are withdrawn by the remaining VLT peer nodes as well.

VLT VLTi failure

When the Heartbeat is up (nodes are still alive), all VLT local ports and network ports are forced down on the VLT secondary node using UFD. This behavior causes all BGP sessions to go down and all remote MACs to be removed from the VLT secondary node. Effectively, the VLT secondary node is isolated from the network.

Orphan local MACs on the VLT secondary node are withdrawn from all the remote VTEPs.

VLT local MACs continue to be advertised by the VLT Primary node; as a result, they are retained in the remote VTEPs.

Network port failure

As long as the VTEP has connectivity to at least one Spine node, all the BGP routes are intact and there is no change.

When a VLT node has lost connectivity to all Spine nodes, the behavior differs depending on the deployment scenario:

  • Separate overlay BGP session on separate loopback interface:
    • Leaf and Spine loopback IP addresses should still be reachable from each other in the underlay based on underlay routing re-convergence using the VLTi with the VLT peer as the first-hop.
    • In this case, the BGP sessions between Leaf and Spine nodes are still active.
    • Encapsulated data traffic from Leaf to Spine node is also redirected through VLTi once the underlay routing re-converges.
  • Combined underlay and overlay BGP sessions directly on the network link:
    • BGP sessions between Leaf and Spine nodes go down. All EVPN remote MACs or ARPs are removed from the data-plane.
    • Overlay Layer 2 switched data traffic from Leaf to Spine node is flooded to all remote VTEPs. The encapsulated traffic is redirected through VLTi after the underlay routing re-converges.
    • Overlay Layer 3 routed data traffic from Leaf to Spine node is dropped.

VLT single node recovery

The following topology diagram depicts the VLT single node recovery scenario:

vlt-single-node-recovery

When a VLT node boots up, if the VLT role is detected as secondary, all the server facing VLT ports and all the network facing ports are held in down state for a specified interval. This phase is called the delay-restore phase.

Before the ports come up, the following are expected to be completed:

  • The overlay BGP sessions are established ; this establishment happens between Leaf and Spine loopback IP addresses over VLTi with the VLT primary acting as transit hop.
  • Overlay EVPN routes are received from remote VTEPs and all remote MACs and ARPs are installed in the data-plane.
  • Underlay route reachability to remote VTEPs is installed in the data-plane through VLTi with primary acting as transit hop.

The VLT delay restore timer needs to be adjusted to accommodate these changes.


Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  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: <>()\