Seamless Mobility: Validating OpenStack Live Migration in EVPN-VXLAN Fabrics with FTAS

What really happens inside the network when a VM moves?

In modern cloud data centers, Live Migration is a critical operational capability. It moves a running Virtual Machine (VM) between physical hosts with near-zero disruption to active applications.

However, when compute mobility occurs over a large-scale EVPN-VXLAN fabric, the network must update the VM's location in real time across all VTEPs. If it doesn't, traffic can continue flowing to the old destination—resulting in packet loss or blackholing.

At Aviz, we use our Fabric Test Automation Suite (FTAS)—an automated, platform-agnostic network validation framework—to move beyond basic connectivity checks. FTAS validates both control-plane correctness and data-plane stability, ensuring production-grade reliability during events like live migration.

The Infrastructure: A Production-Grade SONiC Fabric

Our validation environment reflects real-world deployments, using a standard Leaf-Spine topology powered by SONiC.CCS_202411.

• Hardware Foundation: A 4-switch Leaf-Spine fabric
• Control Plane: MP-BGP (EVPN) with unique ASNs (1001–1004) for route exchange
• Overlay: VXLAN-based Layer 2 extension, mapping VLAN 20 to VNI 100020
• Gateway Design: A Static Anycast Gateway (SAG) with IP 192.168.20.1 and MAC 00:11:22:33:44:55 across all Leaf switches — ensures the VM's default gateway is always one hop away, even after migration

How FTAS Validates Seamless Mobility

FTAS transforms complex manual testing into a predictable, automated validation workflow. Here's how we validated the migration of VM vm1 from host os02 to os03.

1. Fabric Initialization & Baseline

The system begins by bringing up BGP neighbors and VXLAN interfaces, ensuring the fabric is fully operational before introducing workloads.

• Action: Spawn vm1 on host os02
• Validation: The fabric correctly learns the VM MAC (fa:16:3e:7f:2e:0a) on the local physical interface

2. Data-Plane Continuity Analysis

During migration, FTAS measures real user impact using a continuous ping stream from the VM to its gateway.

• Action: Perform an OpenStack block migration of vm1
• Observed Result: Only 1.42% transient packet loss during hypervisor handoff
• Why This Matters: In lab environments, a ~10% threshold is commonly used to account for hypervisor switchover behavior. Achieving 1.42% demonstrates fast and stable fabric convergence.

3. Control-Plane Integrity: MAC Mobility

While traffic continues to flow, FTAS audits the control plane to ensure the network updates the VM's location correctly.

• The Challenge: The fabric must update the VM's location to the new VTEP. Without this, traffic would continue flowing to the old VTEP, causing drops.
• Validation: The new Leaf switch advertises the VM route with a MAC Mobility (MM) sequence of 1
• Why It Matters: This sequence increment signals the move to all other VTEPs, triggering immediate updates and preventing stale forwarding paths.

Outcome: Predictable Reliability for Operators

By the end of the automated run, FTAS validated a clean and stable migration—without any manual intervention.

• Traffic Convergence without Blackholing: ARP and MAC tables updated correctly to the new physical interface
• System Stability: No crashes or core dumps (e.g., orchagent, zebra) during the event
• Clean Lifecycle: The test VM and configurations were automatically removed, leaving the environment ready for the next run

For operators, this means live migrations can be executed during maintenance or scaling events without risking application disruption or requiring manual network intervention.

The Bottom Line

With FTAS, validation goes beyond simple reachability.

It delivers continuous, automated assurance that both the control plane and data plane behave correctly during real-world events like VM mobility—independent of underlying hardware platforms.

If you are evaluating SONiC-based EVPN-VXLAN fabrics for production, this is the level of validation you should demand.