Arista EOS BGP EVPN VXLAN: Complete Run Book for Leaf-Spine Data Center Fabrics

Introduction to BGP EVPN VXLAN on Arista EOS

BGP EVPN (Ethernet VPN) over VXLAN (Virtual Extensible LAN) is the industry-standard control plane for modern data center fabrics. Where older overlay technologies relied on flood-and-learn for MAC address discovery, BGP EVPN distributes MAC, IP, and routing information through a standards-based control plane — eliminating BUM (Broadcast, Unknown unicast, Multicast) flooding at scale and enabling seamless multi-tenancy across large environments.

Arista EOS provides a mature, full-featured BGP EVPN VXLAN implementation supporting L2 VNI bridging, L3 VNI routing with symmetric IRB, ARP suppression, and VTEP redundancy via MLAG or EVPN multihoming. This run book walks through a complete production deployment across a two-spine, two-leaf topology using Arista EOS 4.28 or later. Every configuration block is production-oriented and immediately deployable.

Topology and Design Overview

The reference topology uses a standard leaf-spine architecture with eBGP as the underlay routing protocol. Spines share a common ASN and act as BGP EVPN route reflectors for the overlay. Each leaf has a unique ASN. Point-to-point /31 links connect every leaf to every spine, and loopback addresses provide stable peering anchors for both underlay reachability and VTEP tunnel endpoints.

• sw-infrarunbook-01 — Spine-1, ASN 65100, Loopback0 10.0.0.1/32
• sw-infrarunbook-02 — Spine-2, ASN 65100, Loopback0 10.0.0.2/32
• sw-infrarunbook-03 — Leaf-1, ASN 65001, Loopback0 10.0.0.3/32, VTEP Loopback1 10.1.0.3/32
• sw-infrarunbook-04 — Leaf-2, ASN 65002, Loopback0 10.0.0.4/32, VTEP Loopback1 10.1.0.4/32

Underlay P2P addressing is allocated from 10.100.0.0/24. Two tenant VLANs (10 and 20) are stretched across the fabric using L2 VNIs, and both are routed within VRF TENANT-A using a shared L3 VNI for symmetric IRB.

Underlay Configuration — eBGP Leaf-Spine

The underlay is responsible for transporting VXLAN-encapsulated packets between VTEPs. Arista recommends eBGP for leaf-spine underlay because it provides fast convergence, per-prefix loop prevention, and straightforward policy control — without requiring a separate IGP. Each leaf advertises its Loopback0 (BGP router-id) and Loopback1 (VTEP source) into the underlay so remote VTEPs can establish tunnels.

Spine-1 (sw-infrarunbook-01) Underlay

! sw-infrarunbook-01 — Spine-1 Underlay Configuration
!
hostname sw-infrarunbook-01
!
interface Loopback0
   ip address 10.0.0.1/32
!
interface Ethernet1
   description P2P_to_sw-infrarunbook-03_Eth1
   no switchport
   mtu 9214
   ip address 10.100.0.0/31
!
interface Ethernet2
   description P2P_to_sw-infrarunbook-04_Eth1
   no switchport
   mtu 9214
   ip address 10.100.0.2/31
!
router bgp 65100
   router-id 10.0.0.1
   no bgp default ipv4-unicast
   !
   neighbor LEAVES peer group
   neighbor LEAVES send-community extended
   neighbor LEAVES maximum-routes 12000
   !
   neighbor 10.100.0.1 peer group LEAVES
   neighbor 10.100.0.1 remote-as 65001
   neighbor 10.100.0.3 peer group LEAVES
   neighbor 10.100.0.3 remote-as 65002
   !
   address-family ipv4
      neighbor LEAVES activate
      network 10.0.0.1/32

Spine-2 (sw-infrarunbook-02) Underlay

! sw-infrarunbook-02 — Spine-2 Underlay Configuration
!
hostname sw-infrarunbook-02
!
interface Loopback0
   ip address 10.0.0.2/32
!
interface Ethernet1
   description P2P_to_sw-infrarunbook-03_Eth2
   no switchport
   mtu 9214
   ip address 10.100.0.4/31
!
interface Ethernet2
   description P2P_to_sw-infrarunbook-04_Eth2
   no switchport
   mtu 9214
   ip address 10.100.0.6/31
!
router bgp 65100
   router-id 10.0.0.2
   no bgp default ipv4-unicast
   !
   neighbor LEAVES peer group
   neighbor LEAVES send-community extended
   neighbor LEAVES maximum-routes 12000
   !
   neighbor 10.100.0.5 peer group LEAVES
   neighbor 10.100.0.5 remote-as 65001
   neighbor 10.100.0.7 peer group LEAVES
   neighbor 10.100.0.7 remote-as 65002
   !
   address-family ipv4
      neighbor LEAVES activate
      network 10.0.0.2/32

Leaf-1 (sw-infrarunbook-03) Underlay

! sw-infrarunbook-03 — Leaf-1 Underlay Configuration
!
hostname sw-infrarunbook-03
!
interface Loopback0
   ip address 10.0.0.3/32
!
interface Loopback1
   description VTEP_Source
   ip address 10.1.0.3/32
!
interface Ethernet1
   description P2P_to_sw-infrarunbook-01_Eth1
   no switchport
   mtu 9214
   ip address 10.100.0.1/31
!
interface Ethernet2
   description P2P_to_sw-infrarunbook-02_Eth1
   no switchport
   mtu 9214
   ip address 10.100.0.5/31
!
router bgp 65001
   router-id 10.0.0.3
   no bgp default ipv4-unicast
   !
   neighbor SPINES peer group
   neighbor SPINES send-community extended
   neighbor SPINES maximum-routes 12000
   !
   neighbor 10.100.0.0 peer group SPINES
   neighbor 10.100.0.0 remote-as 65100
   neighbor 10.100.0.4 peer group SPINES
   neighbor 10.100.0.4 remote-as 65100
   !
   address-family ipv4
      neighbor SPINES activate
      network 10.0.0.3/32
      network 10.1.0.3/32

Leaf-2 (sw-infrarunbook-04) Underlay

! sw-infrarunbook-04 — Leaf-2 Underlay Configuration
!
hostname sw-infrarunbook-04
!
interface Loopback0
   ip address 10.0.0.4/32
!
interface Loopback1
   description VTEP_Source
   ip address 10.1.0.4/32
!
interface Ethernet1
   description P2P_to_sw-infrarunbook-01_Eth2
   no switchport
   mtu 9214
   ip address 10.100.0.3/31
!
interface Ethernet2
   description P2P_to_sw-infrarunbook-02_Eth2
   no switchport
   mtu 9214
   ip address 10.100.0.7/31
!
router bgp 65002
   router-id 10.0.0.4
   no bgp default ipv4-unicast
   !
   neighbor SPINES peer group
   neighbor SPINES send-community extended
   neighbor SPINES maximum-routes 12000
   !
   neighbor 10.100.0.2 peer group SPINES
   neighbor 10.100.0.2 remote-as 65100
   neighbor 10.100.0.6 peer group SPINES
   neighbor 10.100.0.6 remote-as 65100
   !
   address-family ipv4
      neighbor SPINES activate
      network 10.0.0.4/32
      network 10.1.0.4/32

Both Loopback0 and Loopback1 are advertised into the underlay. Loopback0 anchors the BGP EVPN overlay session. Loopback1 is the VTEP source address used for VXLAN encapsulation and must be reachable from all remote leaf VTEPs.

VXLAN VTEP Interface Configuration

Arista EOS uses a dedicated Vxlan1 logical interface to configure VXLAN encapsulation. This interface defines the VTEP source, the VLAN-to-VNI mappings for L2 bridging, and the VRF-to-VNI mapping for L3 routing. Apply the same configuration on every participating leaf, substituting the correct Loopback1 address. The Vxlan1 interface itself has no IP address.

Leaf-1 VTEP Interface (sw-infrarunbook-03)

! sw-infrarunbook-03 — Vxlan1 Interface
!
interface Vxlan1
   description VXLAN_Overlay
   vxlan source-interface Loopback1
   vxlan udp-port 4789
   vxlan vlan 10 vni 10010
   vxlan vlan 20 vni 10020
   vxlan vrf TENANT-A vni 50001

Leaf-2 VTEP Interface (sw-infrarunbook-04)

! sw-infrarunbook-04 — Vxlan1 Interface
!
interface Vxlan1
   description VXLAN_Overlay
   vxlan source-interface Loopback1
   vxlan udp-port 4789
   vxlan vlan 10 vni 10010
   vxlan vlan 20 vni 10020
   vxlan vrf TENANT-A vni 50001

Key parameters explained:

• source-interface Loopback1 — sets the outer IP source address for all VXLAN-encapsulated frames leaving this VTEP
• udp-port 4789 — IANA-assigned VXLAN destination UDP port; the default on EOS and should not be changed unless interoperating with legacy implementations using 8472
• vlan X vni Y — statically maps a local VLAN to a VXLAN Network Identifier for L2 stretch; all leaves participating in the same VLAN must use the same VNI
• vrf NAME vni Z — binds a VRF instance to an L3 VNI; used for symmetric IRB to route packets between VLANs across different VTEPs

BGP EVPN Overlay Configuration

The EVPN overlay uses iBGP-style peering between leaves and spines sourced from Loopback0. Because these peering addresses are not directly connected,

ebgp-multihop

is required even though this is technically an eBGP session in the eBGP underlay model. Spines act as route reflectors and must not alter the BGP next-hop — if they did, leaves would build VXLAN tunnels toward the spine instead of directly toward the originating leaf VTEP.

Spine-1 EVPN Overlay — Route Reflector (sw-infrarunbook-01)

! sw-infrarunbook-01 — BGP EVPN Route Reflector
!
router bgp 65100
   !
   neighbor EVPN-LEAVES peer group
   neighbor EVPN-LEAVES next-hop-unchanged
   neighbor EVPN-LEAVES update-source Loopback0
   neighbor EVPN-LEAVES bfd
   neighbor EVPN-LEAVES ebgp-multihop 3
   neighbor EVPN-LEAVES send-community extended
   neighbor EVPN-LEAVES route-reflector-client
   neighbor EVPN-LEAVES maximum-routes 0
   !
   neighbor 10.0.0.3 peer group EVPN-LEAVES
   neighbor 10.0.0.3 remote-as 65001
   neighbor 10.0.0.4 peer group EVPN-LEAVES
   neighbor 10.0.0.4 remote-as 65002
   !
   address-family evpn
      neighbor EVPN-LEAVES activate

Critical:

next-hop-unchanged

must be configured on the spine's EVPN peer group. Without it, the spine rewrites the BGP next-hop to its own Loopback0 when reflecting routes to other leaves. This causes leaves to try to establish VXLAN tunnels to the spine — which does not have a VTEP — instead of the originating leaf's Loopback1.

Apply the same configuration on sw-infrarunbook-02 (Spine-2) substituting its Loopback0 address (10.0.0.2) as the update-source. Both spines must be configured as route reflectors so that leaf EVPN sessions remain stable if one spine fails.

Leaf-1 EVPN Overlay — VLAN BGP Stanzas (sw-infrarunbook-03)

! sw-infrarunbook-03 — BGP EVPN Overlay and VLAN Route Advertising
!
router bgp 65001
   !
   neighbor EVPN-SPINES peer group
   neighbor EVPN-SPINES update-source Loopback0
   neighbor EVPN-SPINES bfd
   neighbor EVPN-SPINES ebgp-multihop 3
   neighbor EVPN-SPINES send-community extended
   neighbor EVPN-SPINES maximum-routes 0
   !
   neighbor 10.0.0.1 peer group EVPN-SPINES
   neighbor 10.0.0.1 remote-as 65100
   neighbor 10.0.0.2 peer group EVPN-SPINES
   neighbor 10.0.0.2 remote-as 65100
   !
   address-family evpn
      neighbor EVPN-SPINES activate
   !
   vlan 10
      rd auto
      route-target both 10010:10010
      redistribute learned
   !
   vlan 20
      rd auto
      route-target both 10020:10020
      redistribute learned

The

vlan

stanzas under

router bgp

control how EOS originates EVPN routes for each VLAN:

• rd auto — generates a unique Route Distinguisher derived from the VTEP Loopback1 address and the VNI, ensuring routes from different VTEPs for the same VNI are distinguished in the BGP table
• route-target both X:Y — sets both the import and export extended community for this VNI; all leaves participating in the same VLAN must use the same route-target value to import each other's routes
• redistribute learned — instructs EOS to originate EVPN Type-2 (MAC/IP) routes for hosts learned on local access ports, and EVPN Type-3 (IMET/inclusive multicast) routes announcing VTEP membership for this VNI

Apply the same EVPN overlay stanzas on sw-infrarunbook-04 substituting ASN 65002 and the correct Loopback0 peer addresses.

VLAN, SVI, and Anycast Gateway Configuration

VLANs must be created locally on each leaf where they are active. SVIs configured with

ip address virtual

act as a distributed anycast gateway — the same IP and MAC address is present on every leaf in the fabric, so hosts always route locally without traffic hairpinning to a central gateway device.

! sw-infrarunbook-03 and sw-infrarunbook-04 — VLAN and Anycast Gateway
!
vlan 10
   name WEB_TIER
!
vlan 20
   name APP_TIER
!
vrf instance TENANT-A
!
ip routing vrf TENANT-A
!
ip virtual-router mac-address 00:1c:73:aa:bb:cc
!
interface Vlan10
   description WEB_TIER_Gateway
   vrf TENANT-A
   ip address virtual 192.168.10.1/24
!
interface Vlan20
   description APP_TIER_Gateway
   vrf TENANT-A
   ip address virtual 192.168.20.1/24

The virtual MAC address (configured globally with

ip virtual-router mac-address

) is shared across all leaves. Hosts use this MAC as their default gateway MAC regardless of which leaf they are attached to. The virtual MAC prevents gratuitous ARP storms when hosts move between leaves, since the gateway MAC never changes.

L3 VNI and VRF Configuration — Symmetric IRB

Symmetric IRB is the preferred inter-VLAN routing model for large-scale VXLAN fabrics. In symmetric IRB, the source leaf routes incoming traffic from a local VLAN into the VRF, encapsulates it with the L3 VNI, and forwards it across the underlay. The destination leaf decapsulates, routes within the VRF, and delivers to the destination VLAN. Both leaves perform a routing operation — hence "symmetric."

The key advantage over asymmetric IRB is that every leaf only needs the VRF and L3 VNI configured. Leaves do not need local VLAN and SVI entries for every remote VLAN, which significantly reduces configuration complexity and MAC table size in large multi-tenant fabrics.

! sw-infrarunbook-03 — VRF BGP Stanza for L3 VNI (Symmetric IRB)
!
router bgp 65001
   !
   vrf TENANT-A
      rd 10.1.0.3:50001
      route-target import evpn 50001:50001
      route-target export evpn 50001:50001
      redistribute connected

On sw-infrarunbook-04 the RD changes to use its own VTEP address:

! sw-infrarunbook-04 — VRF BGP Stanza for L3 VNI (Symmetric IRB)
!
router bgp 65002
   !
   vrf TENANT-A
      rd 10.1.0.4:50001
      route-target import evpn 50001:50001
      route-target export evpn 50001:50001
      redistribute connected

The RD must be unique per VTEP (use the VTEP loopback address as the first octet). The route-targets must match on all leaves that participate in the same VRF.

redistribute connected

generates EVPN Type-5 IP prefix routes for connected subnets (the SVI /24 networks), allowing remote leaves to learn and route toward those prefixes.

ARP Suppression

ARP suppression reduces BUM traffic by allowing the local VTEP to answer ARP requests on behalf of remote hosts whose MAC/IP bindings have already been learned via BGP EVPN Type-2 routes. Without ARP suppression, every ARP request from a host is flooded across all VTEPs participating in that VNI — a significant overhead in large fabrics with many endpoints.

! sw-infrarunbook-03 and sw-infrarunbook-04 — Enable ARP Suppression
!
interface Vxlan1
   vxlan arp proxy

Once enabled, EOS builds an ARP suppression table from EVPN Type-2 MAC/IP routes received from remote peers. When a locally attached host sends an ARP request for a host whose binding is known, the VTEP responds directly without flooding the request into the VXLAN fabric. Verify the suppression table with

show vxlan arp-table

.

Verification Commands

Use the following show commands to validate each layer of the BGP EVPN VXLAN stack from the underlay through to the forwarding table.

Underlay Reachability

! Verify eBGP underlay sessions are established
sw-infrarunbook-03# show bgp summary

! Confirm VTEP loopback of remote leaf is in the routing table
sw-infrarunbook-03# show ip route 10.1.0.4

! Ping remote VTEP sourcing from local VTEP loopback
sw-infrarunbook-03# ping 10.1.0.4 source Loopback1

! Verify MTU is consistent on underlay links
sw-infrarunbook-03# show interfaces Ethernet1 | grep MTU

EVPN Overlay Sessions

! Verify EVPN BGP overlay sessions to spines
sw-infrarunbook-03# show bgp evpn summary

! Show all EVPN routes in the BGP table
sw-infrarunbook-03# show bgp evpn

! Show EVPN Type-2 MAC/IP routes for a specific VNI
sw-infrarunbook-03# show bgp evpn vni 10010

! Show all EVPN Type-2 (MAC/IP) routes
sw-infrarunbook-03# show bgp evpn route-type mac-ip

! Show EVPN Type-3 (IMET) routes — confirms VTEP membership
sw-infrarunbook-03# show bgp evpn route-type imet

! Show EVPN Type-5 IP prefix routes — L3 VNI routing
sw-infrarunbook-03# show bgp evpn route-type ip-prefix ipv4

VXLAN Data Plane

! Verify Vxlan1 interface is up and VNI mappings are correct
sw-infrarunbook-03# show vxlan interface

! Show all discovered remote VTEPs
sw-infrarunbook-03# show vxlan vtep

! Show flood list for BUM traffic (should contain remote VTEPs)
sw-infrarunbook-03# show vxlan flood vtep

! Show MAC address table with VXLAN tunnel entries
sw-infrarunbook-03# show vxlan address-table

! Verify VLAN-to-VNI and VRF-to-VNI mappings
sw-infrarunbook-03# show vxlan vni

! Show ARP suppression table
sw-infrarunbook-03# show vxlan arp-table

VRF Routing Table

! Verify routes inside the tenant VRF
sw-infrarunbook-03# show ip route vrf TENANT-A

! Verify BGP routes within the VRF
sw-infrarunbook-03# show bgp vpn-ipv4 vrf TENANT-A

Troubleshooting Common Issues

EVPN Overlay Sessions Not Establishing

If EVPN sessions are idle or active while the underlay is fully up, check these areas in order:

• Loopback0-to-Loopback0 reachability:

  ping 10.0.0.1 source Loopback0

  from the leaf
• Confirm

  send-community extended

  is present on both ends of the EVPN peer group — without it, the session forms but EVPN NLRI is silently dropped
• Verify

  ebgp-multihop 3

  is configured — the EVPN session uses Loopback0 addresses that are not directly connected
• Confirm

  address-family evpn

  activates the correct peer group on both spine and leaf
• Check BFD: if

  bfd

  is configured on the peer group, ensure BFD is also running on the underlay path

Remote MAC Addresses Not Appearing

If

show vxlan address-table

shows no remote entries:

• Verify

  redistribute learned

  is present in the VLAN BGP stanza on the remote leaf
• Confirm route-targets match exactly on both leaves for the same VNI — a single digit mismatch prevents route import
• Check that the VLAN exists locally with

  show vlan

  and that the Vxlan1 interface maps it to the correct VNI
• Confirm the EVPN Type-2 route appears in

  show bgp evpn route-type mac-ip

  — if not, the originating leaf is not advertising it

Inter-VLAN Routing Failures

If hosts in VLAN 10 on one leaf cannot reach hosts in VLAN 20 on another leaf:

• Confirm the VRF-to-VNI binding is present on both leaves:

  show vxlan vni

• Verify

  ip routing vrf TENANT-A

  is enabled on both leaves
• Check that EVPN Type-5 prefix routes are being received:

  show bgp evpn route-type ip-prefix ipv4

• Confirm route-targets in the VRF BGP stanza match on both leaves (import and export values must be identical)
• Verify the SVI is in the correct VRF and

  ip address virtual

  (not

  ip address

  ) is used

MTU and Fragmentation Issues

VXLAN encapsulation adds 50 bytes of overhead: 14-byte outer Ethernet, 20-byte outer IP, 8-byte outer UDP, and 8-byte VXLAN header. If the underlay MTU is left at the default 1500 bytes, inner frames above approximately 1450 bytes will be fragmented or silently dropped depending on the DF bit. Set all underlay-facing interfaces and system MTU to at least 9214 bytes to support jumbo frames end-to-end:

! Set system jumbo MTU — apply on all leaf and spine switches
sw-infrarunbook-03(config)# system l1
sw-infrarunbook-03(config-l1)# unsupported speed action error
!
! Or set per-interface MTU on underlay links
sw-infrarunbook-03(config)# interface Ethernet1
sw-infrarunbook-03(config-if-Et1)# mtu 9214

---

Frequently Asked Questions

Q: What is the difference between symmetric and asymmetric IRB in VXLAN?

A: In asymmetric IRB, the source leaf routes the packet from the source VLAN to the destination VLAN locally, then bridges it across the VXLAN fabric using the destination VLAN's VNI. The destination leaf only bridges — it does not route. This means every leaf must have every VLAN and SVI configured, which does not scale. In symmetric IRB, both the source and destination leaves route: the source routes into a shared L3 VNI, the destination routes out to the destination VLAN. Only the VRF and L3 VNI need to be present everywhere — not every VLAN. Symmetric IRB is the production standard for large fabrics.

Q: Why must next-hop-unchanged be configured on the spine's EVPN peer group?

A: When a spine reflects an EVPN route from Leaf-1 to Leaf-2, it would normally rewrite the BGP next-hop to its own Loopback0. This causes Leaf-2 to build a VXLAN tunnel toward the spine, which has no VTEP interface and cannot decapsulate VXLAN traffic. With

next-hop-unchanged

, the spine preserves the original next-hop (Leaf-1's Loopback1), ensuring Leaf-2 establishes a direct VTEP-to-VTEP tunnel. This is a mandatory configuration on all EVPN route reflectors in a leaf-spine fabric.

Q: What is the purpose of Loopback1 separate from Loopback0?

A: Loopback0 is used as the BGP router-id and as the source for EVPN overlay peering sessions. Loopback1 is the VTEP source interface — the outer IP address stamped on all VXLAN-encapsulated frames. Keeping them separate allows for VTEP redundancy: when two leaf switches are configured as an MLAG pair, both can share a common Loopback1 address (the MLAG VTEP anycast address), while retaining unique Loopback0 addresses for individual BGP management sessions.

Q: What happens if the route-target values do not match between leaves?

A: BGP EVPN uses import route-targets to determine which routes a leaf will accept into its local EVPN RIB. If the route-target on the exporting leaf does not match the import route-target on the receiving leaf, the receiving leaf silently discards the route. The EVPN session stays up and the BGP table may show routes as received, but

show vxlan address-table

will be empty for remote hosts. Always use a consistent route-target naming scheme — a common convention is to use the VNI value in both octets (e.g., 10010:10010 for VNI 10010).

Q: Can I use OSPF instead of eBGP for the underlay?

A: Yes, Arista EOS supports OSPF, IS-IS, or eBGP as the underlay routing protocol. However, eBGP is strongly preferred in leaf-spine fabrics for several reasons: it provides built-in loop prevention without the need for tuning, scales linearly as leaves are added, and supports per-prefix policy control. OSPF can be used in smaller environments where simplicity is more important than scalability, but requires careful area design and ECMP tuning to avoid suboptimal forwarding.

Q: What is ARP suppression and when should it be enabled?

A: ARP suppression allows the local VTEP to answer ARP requests on behalf of remote hosts by using the MAC/IP bindings learned from EVPN Type-2 routes. Without it, every ARP request floods across all VTEPs in the VNI via VXLAN BUM replication. In large environments with thousands of endpoints, this BUM flood traffic consumes significant underlay bandwidth and generates CPU overhead on all VTEPs. ARP suppression should always be enabled in production EVPN VXLAN deployments. It requires no additional configuration beyond

vxlan arp proxy

on the Vxlan1 interface.

Q: How do I add a new VLAN and stretch it across the fabric?

A: Three steps are required on each participating leaf: (1) create the VLAN locally with

vlan X

, (2) add the VLAN-to-VNI mapping to the Vxlan1 interface with

vxlan vlan X vni Y

, and (3) add the corresponding VLAN stanza to

router bgp

with an

rd auto

, a matching

route-target both

, and

redistribute learned

. If the VLAN requires inter-VLAN routing, also create an SVI with

ip address virtual

inside the correct VRF. No changes to the spine configuration are required when adding new VLANs.

Q: What EVPN route types does Arista EOS use, and what does each one do?

A: EOS uses four main EVPN route types in a standard VXLAN deployment. Type-2 (MAC/IP Advertisement) carries host MAC and optionally the host IP address, allowing remote leaves to populate their MAC tables and ARP suppression tables without flooding. Type-3 (Inclusive Multicast Ethernet Tag) announces VTEP membership for a VNI, establishing the BUM flood list used before ARP suppression eliminates most flood traffic. Type-5 (IP Prefix Route) advertises IP prefixes from within a VRF and is used for inter-VLAN routing with symmetric IRB. Type-1 (Ethernet Auto-Discovery) is used for EVPN multihoming and fast convergence when dual-homed hosts move or a link fails.

Q: How do I verify that VXLAN tunnels are actually forwarding traffic, not just established?

A: Use

show vxlan vtep

to confirm remote VTEPs are discovered. Then use

show vxlan address-table

to verify remote MAC addresses are being learned via VXLAN tunnels (entries show the remote VTEP IP as the next-hop). For a live traffic test, generate traffic between hosts in the same VNI on different leaves and check interface counters on the Vxlan1 interface with

show interfaces Vxlan1

— the input and output packet counters should increment. You can also use

show platform fwd vxlan

on supported platforms for hardware-level VTEP statistics.

Q: What MTU should I set on underlay interfaces for VXLAN?

A: Set all underlay-facing physical interfaces to at least 9214 bytes. VXLAN adds 50 bytes of encapsulation overhead per frame. If your environment carries standard 1500-byte inner Ethernet frames, a 1550-byte underlay MTU would technically suffice, but 9214 is the standard recommendation to support jumbo frames end-to-end (9000-byte inner payload + 50-byte VXLAN overhead + Ethernet framing). Mismatched or insufficient MTU is one of the most common causes of intermittent VXLAN connectivity issues, as oversized frames may be silently dropped by hardware without generating an ICMP error.

Q: Does BGP EVPN VXLAN on Arista EOS support multi-tenancy?

A: Yes, multi-tenancy is a core design goal of BGP EVPN VXLAN. Each tenant is assigned its own VRF instance with a dedicated L3 VNI. Traffic between tenants is completely isolated in the data plane — packets in different VRFs never share the same VNI. Route leaking between VRFs requires explicit configuration using BGP route-import policies. On the control plane, each VRF uses distinct EVPN import and export route-targets, so routes from one tenant's VRF are never installed into another tenant's routing table unless explicitly configured. This model supports hundreds of tenants on a single physical fabric.

Q: Can Arista VXLAN interoperate with other vendors implementing BGP EVPN?

A: Yes. BGP EVPN (RFC 7432) and VXLAN (RFC 7348) are open standards, and Arista EOS follows the IETF specifications closely. Interoperability with other standards-compliant implementations (such as Cisco NX-OS, Juniper Junos, and Nokia SR OS) is achievable, but requires careful alignment of route-type support, route-target formats, and VTEP encapsulation behavior. The most common interoperability friction points are differences in Type-5 route handling, ARP suppression implementation details, and EVPN multihoming signaling. Always validate interoperability in a lab environment before deploying a multi-vendor EVPN fabric in production.