Lab 2: Spine-Leaf Clos VXLAN-EVPN Fabric -- VM Mobility Demonstration

Week: 2 -- Datacenter Networking
Points: 20
Time estimate: 90 min lab + 3 hr independent
Deliverable: lab-2-report.md + Containerlab topology + mobility trace

Objectives

1. Deploy a 2-spine / 4-leaf spine-leaf Clos fabric in Containerlab with FRR 9.x.
2. Configure VXLAN-EVPN with eBGP unnumbered and symmetric IRB.
3. Assign Docker containers (simulating VMs) to tenant VNIs on two different leaves.
4. Demonstrate VM mobility: move a container from one leaf to another and verify reachability is maintained without manual reconfiguration.

Topology

       [Spine1]  [Spine2]
       /  \  \  / /  \
      /    \  \/  /    \
  [Leaf1][Leaf2][Leaf3][Leaf4]
    ||       |             ||
 [VM-A] [VM-B]         [VM-C]

• Spine1, Spine2: BGP Route Reflectors (ASN 65000)
• Leaf1-4: VTEP leaf switches (each in its own ASN: 65001-65004)
• VNI 10010: Tenant "red" L2 segment
• VNI 10020: Tenant "blue" L2 segment
• L3VNI 10099: transit VNI for symmetric IRB

Part A: Containerlab Topology Bootstrap (20 min)

Create lab2/topology.yaml with 2 spines and 4 leaves. Each leaf peering with both spines via eBGP (link-local, RFC 5549). Full configuration templates are in lab2/configs/.

Enable VXLAN in the kernel:

sudo modprobe vxlan
sudo containerlab deploy -t lab2/topology.yaml

Verify physical underlay connectivity:

# From Leaf1, ping Leaf3 loopback
docker exec clab-evpn-lab2-leaf1 ping -c 3 10.255.0.3

Part B: VXLAN-EVPN Configuration (40 min)

Configure the EVPN overlay on Leaf1 (example -- repeat for all leaves):

! FRR config on Leaf1 (ASN 65001)
!
interface lo
 ip address 10.255.0.1/32
!
router bgp 65001
 bgp router-id 10.255.0.1
 no bgp default ipv4-unicast
 !
 neighbor SPINES peer-group
 neighbor SPINES remote-as external
 neighbor SPINES capability extended-nexthop
 neighbor eth1 interface peer-group SPINES   ! link to Spine1
 neighbor eth2 interface peer-group SPINES   ! link to Spine2
 !
 address-family ipv4 unicast
  redistribute connected                      ! advertise loopback
  neighbor SPINES activate
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor SPINES activate
  advertise-all-vni
 exit-address-family
!
! VXLAN interface
interface vxlan1
 vxlan id 10010
 vxlan local-tunnelip 10.255.0.1
 bridge-access 10
!
interface vxlan2
 vxlan id 10020
 vxlan local-tunnelip 10.255.0.1
 bridge-access 20
!
! L3VNI for symmetric IRB
vrf tenant-red
 vni 10099
!
interface vxlan99
 vxlan id 10099
 vxlan local-tunnelip 10.255.0.1
!

Verify EVPN Type-2 routes are exchanged:

docker exec clab-evpn-lab2-leaf1 vtysh -c "show bgp l2vpn evpn"
docker exec clab-evpn-lab2-leaf1 vtysh -c "show bgp l2vpn evpn route type 2"

Part C: VM Placement and Mobility Test (30 min)

Attach Docker containers to the VXLAN bridge on Leaf1 and Leaf3:

# VM-A on Leaf1 (VNI 10010, "red" tenant)
docker run -d --name vm-a --network none alpine sleep 3600
docker exec clab-evpn-lab2-leaf1 ip link add veth-vma type veth peer veth-vma-host
# ... (full veth plumbing to bridge)

# VM-C on Leaf3 (VNI 10010, same "red" tenant on a different leaf)
docker run -d --name vm-c --network none alpine sleep 3600

Verify VM-A can ping VM-C across the EVPN fabric:

docker exec vm-a ping -c 5 <vm-c-ip>

VM mobility: detach VM-A from Leaf1 and re-attach to Leaf2 with the same IP address. The EVPN fabric should automatically update the Type-2 route (new VTEP IP = Leaf2) and VM-C should be able to reach VM-A without any manual intervention.

# Simulate VM migration: detach from Leaf1
docker exec clab-evpn-lab2-leaf1 bridge fdb del <vm-a-mac> dev vxlan1

# Attach VM-A to Leaf2
# ... (full attachment to Leaf2 bridge with same IP)

# Verify: does Leaf3 now show the updated VTEP for VM-A's MAC?
docker exec clab-evpn-lab2-leaf3 vtysh -c "show bgp l2vpn evpn route type 2" | grep <vm-a-mac>

# Verify reachability from VM-C is maintained
docker exec vm-c ping -c 5 <vm-a-ip>

Lab Report

Create lab-2-report.md with:

1. show bgp l2vpn evpn output from Leaf1 showing Type-2 and Type-3 routes
2. VM-A → VM-C ping output before migration (baseline)
3. show bgp l2vpn evpn route type 2 output after migration (confirming VTEP update)
4. VM-C → VM-A ping output after migration (confirming reachability)
5. One-paragraph analysis: explain why ARP suppression (EVPN Type-2 with IP field) prevents ARP floods in this fabric

Grading