Guide to BGP and VXLAN L2/L3EVPN in GNS3 SONiC DataCenter v2.2.0

[stordis-toc]

Introduction

Welcome to the STORDIS GNS3 SONiC DataCenter v2.2.0 guide.

This guide covers the current spine–leaf lab with two spine switches, three leaf switches, a dual-attached SONiC MH-host and three VPCS endpoints. The fabric uses an eBGP IPv4 underlay, a BGP L2VPN EVPN control plane, VXLAN for L2 and L3 tenant traffic, and EVPN multihoming for the MH-host.

The MGMT switch and Ansible server provide management access in the GNS3 topology. The scenarios below exercise the data plane; they do not change the existing management, ZTP or Ansible configurations.

Prerequisites

• GNS3 SONiC DataCenter v2.2.0 project with the topology shown below and the Broadcom Enterprise SONiC 4.6.0 virtual switch image used by this lab. - download it HERE

• Access to the management server (Ubuntu with Ansible installed)
• Basic knowledge of Ansible
• Established connectivity to SONiC nodes

Topology overview

Each leaf connects to both spines. LEAF-1 and LEAF-2 connect to the same MH-host through PortChannel1. PC1 and PC2 connect to different leaves but share VLAN 11; PC3 connects to LEAF-3 in VLAN 20. The management links are shown separately from the data-plane paths.

Fabric addressing

SPINE-1 uses Ethernet0–2 toward LEAF-1–3 Ethernet8. SPINE-2 uses Ethernet0–2 toward LEAF-1–3 Ethernet7. The six point-to-point links use /31 IPv4 subnets. Each leaf has an eBGP session with each spine for IPv4 unicast and L2VPN EVPN.

Tenant VLANs and VXLAN VNIs

VLAN 999 is an internal VLAN used to bind L3VNI 50000 to Vrf-lab; it is not an access VLAN for a VPCS endpoint. The host-facing gateways are anycast addresses configured on the appropriate leaf SVIs.

Endpoint addresses

How the configuration fits together

• Underlay: The spine–leaf /31 links and eBGP IPv4 unicast provide reachability between leaf loopbacks and VTEP source addresses. Each leaf peers with both spines. The spines do not terminate tenant VXLAN traffic.

   

• Overlay: The same BGP peers activate the L2VPN EVPN address family. Each leaf maps its local access VLANs to L2VNIs. All three leaves bind Vrf-lab to L3VNI 50000 for routed tenant traffic.

   

• Anycast gateways: LEAF-1 and LEAF-2 both configure 10.10.11.254/24 for VLAN 11 and 10.10.10.254/24 for VLAN 10. LEAF-3 configures 10.10.20.254/24 for VLAN 20. All three leaves use the same configured anycast MAC.

   

• EVPN multihoming: LEAF-1 and LEAF-2 use the same system-mac on PortChannel1 with evpn ethernet-segment auto-system-mac, creating a shared Ethernet Segment Identifier for the dual-attached MH-host. 

Use case scenarios

Scenario 1 - Extend one L2 segment across two leaves

Purpose: Show that PC1 and PC2 remain in one subnet and broadcast domain even though they attach to different leaves. EVPN advertises endpoint reachability; VXLAN carries the L2 traffic over the routed underlay.

Procedure:

1. Confirm PC1 is 10.10.11.11/24 and PC2 is 10.10.11.12/24, both with gateway 10.10.11.254.

2. From the PC1 VPCS console, run ping 10.10.11.12.

3. On LEAF-1 and LEAF-2, inspect show bgp l2vpn evpn summary, show vxlan vlanvnimap and show vxlan tunnel.

Expected result: PC2 replies. VLAN 11 maps to VNI 10011 on both leaves, and the EVPN peerings and VXLAN tunnel are present. Because PC1 and PC2 share 10.10.11.0/24, this test does not require a first-hop gateway for their mutual traffic. The highlighted spine path in the figure is illustrative; ECMP may select either spine.

Scenario 2 - Route between tenant subnets with L3 EVPN

Purpose: Show how a host in 10.10.11.0/24 reaches a host in 10.10.20.0/24 through the distributed gateway and Vrf-lab.

Procedure:

1. Confirm PC1 uses gateway 10.10.11.254 and PC3 uses gateway 10.10.20.254.

2. From PC1, run ping 10.10.20.10.

3. On LEAF-1 and LEAF-3, inspect show ip route vrf Vrf-lab, show vxlan vrfvnimap, show ip static-anycast-gateway and show bgp l2vpn evpn summary.

Expected result: PC3 replies. The tenant VRF maps to L3VNI 50000 on both leaves; VLAN 11 and VLAN 20 remain separate L2 segments. PC1 sends traffic for PC3 to its local anycast gateway before the traffic crosses the fabric. The highlighted path is illustrative; either spine can carry the underlay traffic.

Scenario 3 - Keep the MH-host reachable after one access-link failure

Purpose: Demonstrate the dual-attached MH-host, its shared Ethernet segment on LEAF-1 and LEAF-2, and the remaining path when one access link fails.

Procedure:

1. Before the failure, use show PortChannel summary on MH-host and show evpn es detail on both leaves. Confirm that both MH-host links are up and that LEAF-1 and LEAF-2 report the configured Ethernet segment.

2. From PC1, run ping 10.10.10.10 to check baseline reachability to MH-host.

3. In GNS3, disconnect the link between MH-host Ethernet0 and LEAF-1 Ethernet0. Leave MH-host Ethernet1 to LEAF-2 Ethernet0 connected, then repeat the ping.

4. Check show PortChannel summary on MH-host and show evpn es detail on LEAF-2. Restore the link after the test.

Expected result: The remaining PortChannel member through LEAF-2 stays available, and reachability to 10.10.10.10 resumes after convergence. Some ICMP packets may be lost during the transition; this guide does not assert a fixed convergence time or zero packet loss.

Verification checklist

• Two BGP neighbors are expected on each leaf and three on each spine: show bgp ipv4 unicast summary and show bgp l2vpn evpn summary.

• Confirm VLAN 10 → VNI 10010, VLAN 11 → VNI 10011 and VLAN 20 → VNI 10020 where configured: show vxlan vlanvnimap.

• Confirm Vrf-lab → L3VNI 50000 on all leaves: show vxlan vrfvnimap.

• Confirm PortChannel1 and the Ethernet segment on LEAF-1/2: show PortChannel summary, show evpn es and show evpn es detail.

Do You have more questions?

If you have any questions, encounter issues, or if any part of the configuration is unclear, please contact STORDIS Technical Support.

Our team will be happy to assist you.

You can reach us via the support portal: https://support.stordis.com/hc/en-us

For more free resources, visit: https://stordis.com/free-resources/