Skip to main content

Aviz details FTAS validation of EVPN-VXLAN live migration

The blog describes how EVPN-VXLAN networks must update VM reachability during live migration to avoid stale forwarding, and it reports results from an Aviz Fabric Test Automation Suite validation. The testing focuses on both control-plane correctness and data-plane stability for enterprise environments running VM mobility over leaf-spine overlays.

Research Overview

The post frames live migration as a way to move a running virtual machine between physical hosts with minimal disruption, while noting that large-scale EVPN-VXLAN fabrics require fast location updates for VTEPs. It explains that delays or missed updates can lead to traffic forwarding to the prior destination, resulting in packet loss or blackholing.

To address that validation gap, Aviz describes the Fabric Test Automation Suite (FTAS) as an automated, platform-agnostic framework that checks control-plane correctness and data-plane stability during events such as VM migration. The article presents a lab-based validation that mirrors a production-style leaf-spine setup.

Technical Breakdown

The validation environment uses a four-switch leaf-spine fabric as the hardware foundation and MP-BGP (EVPN) for EVPN route exchange with unique ASNs. The overlay is described as a VXLAN-based Layer 2 extension that maps VLAN 20 to VNI 100020.

For gateway behavior, the blog specifies a static anycast gateway design where the IP 192.168.20.1 and MAC 00:11:22:33:44:55 are used across all leaf switches. It states that this design keeps the VM default gateway one hop away after migration.

Key Findings

For the data-plane continuity check, FTAS uses a continuous ping stream from the VM to its gateway while an OpenStack block migration occurs from host os02 to os03. The observed result reported in the post is 1.42% transient packet loss during the hypervisor handoff.

For control-plane integrity, the blog describes an audit of how the fabric updates the VM’s MAC location to the new VTEP. It states that the new leaf advertises the VM route with a MAC Mobility sequence increment of 1, and it ties that increment to triggering updates across VTEPs to prevent stale forwarding paths.

Operational Impact

The blog outlines expected operator outcomes from the automated test workflow, including correct ARP and MAC table updates to the new physical interface to avoid blackholing. It also reports that system stability was maintained without crashes or core dumps such as orchagent and zebra during the migration event.

It further describes a clean lifecycle for the test by automatically removing the test VM and configurations after the run. The post concludes that operators can run live migrations during maintenance or scaling without requiring manual network intervention, based on the validation described.

Overall, the article ties seamless VM mobility in EVPN-VXLAN to timely control-plane updates that propagate the VM’s location across VTEPs, and it reports an FTAS-based lab validation with 1.42% transient packet loss during the hypervisor handoff. This “Blog Signals brief” is a fact-based summary of the vendor blog.