Glossary

VXLAN

Virtual Extensible LAN

What is VXLAN

VXLAN (Virtual Extensible LAN) is a network virtualization technology that lets a Layer 2 network be built as an overlay on top of an existing Layer 3 network, encapsulating Ethernet frames inside UDP packets so they can be tunneled across routed infrastructure. It's the technology behind two of the most common problems in modern data centers: multi-tenant network expansion, and letting a virtual machine move from one physical server to another without losing its Layer 2 identity.

Traditional VXLAN, on its own, has real limits. Tunnels are set up manually, with no control plane to automate anything, and MAC address learning happens through multicast-based flooding — which generates a lot of flood traffic and doesn't scale well on large networks. EVPN (Ethernet VPN) solves both problems using a mechanism borrowed from BGP/MPLS IP VPN: it automatically establishes VXLAN tunnels and synchronizes MAC and IP address information using MP-BGP (Multiprotocol Extensions for BGP), giving VXLAN a real control plane instead of relying on flooding. In an EVPN deployment, MP-BGP handles the control plane — announcing routing information about hosts and tunnels — while VXLAN encapsulation still handles the data plane, actually forwarding packets.

How VXLAN Works

Every VXLAN network is identified by a VNI (VXLAN Network Identifier) — the Layer 2 equivalent of a VLAN ID, but with a far larger namespace, which is part of what makes VXLAN suitable for large multi-tenant environments. The device that performs encapsulation and decapsulation at the edge of the overlay is called a VTEP (VXLAN Tunnel Endpoint) — typically a leaf switch, identified by a loopback IP address that both ends of a tunnel use to reach each other.

EVPN extends BGP's NLRI (Network Layer Reachability Information) to carry several distinct types of routing information relevant to VXLAN:

  • Type-2 routes (MAC/IP Advertisement): carry a host's MAC address, and optionally its IP address too (effectively an ARP entry), letting EVPN peers learn about downstream hosts directly through BGP instead of through flooding. When carrying a Layer 3 VNI, this same route type also advertises host IP routes, enabling Layer 3 reachability across subnets.

  • Type-3 routes (Inclusive Multicast Ethernet Tag): used for VTEP auto-discovery and dynamic VXLAN tunnel establishment. When a VTEP announces a Layer 2 VNI along with its own IP, and a peer with a matching VNI receives it, a VXLAN tunnel is automatically built between them.

  • Type-5 routes (IP Prefix Advertisement): carry either a host address or a full network-segment prefix, used to let hosts inside the VXLAN network reach external networks, or to build ARP proxy behavior at the network edge.

Tunnel establishment and traffic forwarding follow directly from this route exchange. When a VM comes online and sends a gratuitous ARP, its local leaf switch learns the MAC and IP, updates its own tables, and advertises a Type-2 route. Remote leaf switches receiving that route establish the necessary VXLAN tunnel and populate their own forwarding and ARP tables — all without any manual tunnel configuration. From there, Layer 2 forwarding between hosts on different leaf switches happens by encapsulating the original frame inside a VXLAN packet addressed to the remote VTEP, while Layer 3 forwarding between hosts on different subnets follows the same tunnel but routes based on the destination VRF, using a distributed-gateway model called symmetric IRB (Integrated Routing and Bridging) — where each gateway only needs to know about the VNIs its own local hosts use, plus a small set of ARP entries for the other distributed gateways, rather than every host across the whole network.

A few enhancements build on this base mechanism. ARP suppression replaces broadcast-based ARP resolution with a local ARP proxy at each leaf — since the leaf already learned every local host's MAC/IP through EVPN, it can answer ARP requests directly rather than flooding them across the fabric, which matters once a network has enough VMs that ARP broadcast alone becomes a real bandwidth and stability concern. VM migration support means that when a host moves to a different leaf, its gratuitous ARP triggers a new Type-2 route carrying an incrementing sequence number, letting remote leaves recognize the newer route and immediately redirect traffic to the host's new location. And a Border device — a network edge node — synchronizes routes configured in its VRF into the VXLAN network via Type-5 routes, giving hosts in different VRFs distinctly controlled access to networks outside the overlay.

Why VXLAN is Beneficial

  • Removes VLAN scale limits for multi-tenant networks: The VNI namespace is dramatically larger than what 802.1Q VLANs alone can offer, letting a data center support far more independently isolated tenant networks.

  • Enables true Layer 2 mobility across a Layer 3 fabric: A virtual machine can migrate between physical servers on entirely different leaf switches while keeping its MAC and IP identity, because the overlay abstracts away the underlying routed topology.

  • EVPN eliminates flood-based learning at scale: Automatic tunnel discovery and MAC/IP synchronization through MP-BGP replace multicast flooding, which is what makes VXLAN actually practical on large networks rather than just theoretically possible.

  • Distributed gateways scale cleanly: Symmetric IRB means each gateway's ARP and MAC tables only need to grow with its own local hosts plus other gateways — not with the total host count across the whole fabric.

  • Reduces broadcast overhead as VM count grows: ARP suppression keeps ARP resolution local to each leaf, avoiding the broadcast storms that would otherwise come with flooding ARP requests across an increasingly large virtualized environment.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements both EVPN-based dynamic VXLAN and simpler static VXLAN, configurable entirely through the CLI, with full symmetric IRB support for distributed gateway deployments.

  • Complete EVPN control-plane configuration: A documented, end-to-end workflow covers VLAN and VRF setup, VTEP IP configuration via Loopback interfaces, underlay BGP (router bgp <asn>, network <A.B.C.D/M>), and overlay BGP (address-family l2vpn evpn, advertise-all-vni) — everything needed to stand up automatic tunnel discovery and MAC/IP synchronization between leaf switches.

  • Straightforward Layer 2 and Layer 3 VXLAN mapping: vni <vni-id> inside a VLAN binds a Layer 2 VNI, while vni <vni-id> vxlan <vxlan-id> inside a VRF configures the Layer 3 VNI that identifies tenant traffic across distributed gateways — directly implementing the symmetric IRB model AsterNOS uses.

  • Built-in ARP proxy modes: arp proxy mode evpn enables EVPN-aware ARP suppression on a VLAN interface once EVPN is running, while a separate default mode handles simpler, non-EVPN ARP proxy needs — giving operators the right tool depending on whether they're running dynamic or static VXLAN.

  • Static VXLAN for simpler deployments: Where a full EVPN control plane isn't needed, AsterNOS supports static VXLAN using directly configured peers and static MAC entries (vni <vni-id> peer <ip>, mac-address static <mac> vlan <id> vxlan vni <id> peer <ip>) for both Layer 2 and Layer 3 scenarios — including static host routes with vxlan-vni <id> onlink for Layer 3 reachability between VRFs without BGP.

  • Configurable VTEP scale on supported hardware: On CX308P-48Y-N-V2 and CX532P-N-V2 platforms, multiple VXLAN instances (0–9) are supported per device, rather than the single-instance limit on other models — relevant for deployments needing more granular tunnel separation.

  • Full visibility for verification: show vxlan map, show vxlan tunnel, and show vxlan remotemac let operators confirm VNI-to-VLAN mappings, established tunnels with their remote VTEP and VRF association, and synchronized remote MAC entries — everything needed to verify an EVPN or static VXLAN deployment is actually working as designed, directly from the CLI.