What ensures seamless mobility during OpenStack Live Migration in EVPN-VXLAN fabrics?
April 21, 2026
Fabric Test Automation Suite
TL;DR
- Applications continue to operate when a virtual machine (VM) is moving thanks to live migration, but the network must quickly monitor this movement across the EVPN-VXLAN fabric.
- Traffic may reach the incorrect destination and be dropped if the control plane does not update in real time.
- This blog explains how the network responds to migration and explains why precise, quick updates are necessary for smooth connectivity.
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.
What is happening inside the network during live migration in EVPN-VXLAN fabrics?
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 does FTAS validate seamless mobility during VM migration?
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.
How is the fabric initialized and baseline validated?
- 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
How is data-plane continuity maintained during migration?
- 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.
How is control-plane integrity ensured with MAC mobility?
- 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.
What outcomes can operators expect from this validation?
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.
What is the bottom line for production EVPN-VXLAN validation?
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.
Frequently Asked Questions
1. What ensures seamless VM mobility during OpenStack Live Migration in EVPN-VXLAN fabrics?
Seamless mobility occurs when the EVPN-VXLAN control plane updates the VM's location in real time across all VTEPs. Fast updates prevent traffic from reaching the old destination and stop packet drops or blackholing.
2. Why must EVPN-VXLAN fabrics track VM movement in real time?
When a VM moves between physical hosts, the network must quickly relearn the VM’s MAC location. Without real-time updates, traffic continues to flow toward the old VTEP, causing packet loss.
3. What role does the control plane play during VM live migration?
The control plane uses MP-BGP EVPN to advertise the VM’s updated MAC location to all VTEPs. A MAC Mobility sequence increment signals the move and triggers quick forwarding updates across the fabric.
4. How does the data plane maintain application connectivity during live migration?
Connectivity is kept by continuously forwarding traffic while the VM migrates. In the validation, a steady ping stream showed only 1.42% transient packet loss during the hypervisor handoff, indicating quick fabric convergence.
5. How does FTAS validate seamless mobility in EVPN-VXLAN fabrics?
Aviz uses the Fabric Test Automation Suite (FTAS) to automate validation of control-plane accuracy and data-plane stability. FTAS checks MAC learning, traffic flow, and control-plane updates during VM migration without needing manual input.
6. What network architecture is used to validate live migration behavior?
The validation environment uses a Leaf-Spine topology with MP-BGP EVPN, VXLAN Layer 2 overlay, unique ASNs for each switch, and a Static Anycast Gateway shared across all leaf switches to keep the VM gateway one hop away after migration.
7. Why is the MAC Mobility sequence important during VM migration?
The MAC Mobility sequence increment shows a VM move to all VTEPs. An incremented sequence ensures old forwarding entries are removed quickly, preventing traffic from being sent to the previous location.
8. What outcomes can operators expect from automated EVPN-VXLAN migration validation?
Operators can expect traffic convergence without blackholing, stable system behavior without crashes, and clean test teardown. Live migrations can be done during maintenance or scaling events without disrupting applications or needing manual network changes.
Explore more network validation strategies or get started with FTAS to ensure production-grade reliability in your EVPN-VXLAN deployments.
