InfraRunBook
    Back to articles

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

    Arista
    Published: Mar 28, 2026
    Updated: Apr 13, 2026

    A production-ready guide to deploying BGP EVPN VXLAN on Arista EOS, covering eBGP underlay, EVPN overlay, L2/L3 VNIs, symmetric IRB, ARP suppression, and full verification.

    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

    Related Articles

    Frequently Asked Questions

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

    In asymmetric IRB, the source leaf routes the packet to the destination VLAN locally and bridges it across VXLAN using the destination VNI — every leaf must have every VLAN and SVI. In symmetric IRB, both source and destination leaves perform a routing step using a shared L3 VNI, so leaves only need the VRF configured, not every remote VLAN. Symmetric IRB is the production standard for large fabrics.

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

    Without next-hop-unchanged, the spine rewrites the BGP next-hop to its own Loopback0 when reflecting EVPN routes to other leaves. This causes leaves to build VXLAN tunnels toward the spine, which has no VTEP and cannot decapsulate VXLAN traffic. Preserving the original next-hop ensures leaves establish direct VTEP-to-VTEP tunnels to the originating leaf.

    What is the purpose of Loopback1 separate from Loopback0?

    Loopback0 is used as the BGP router-id and EVPN peering source. Loopback1 is the VTEP source interface — the outer IP address on all VXLAN frames. Separating them allows MLAG leaf pairs to share a common anycast Loopback1 (VTEP address) while keeping unique Loopback0 addresses for individual BGP sessions.

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

    BGP EVPN uses import route-targets to decide which routes a leaf accepts into its EVPN RIB. A mismatch causes the receiving leaf to silently discard routes — the session stays up but show vxlan address-table will be empty for remote hosts. Use a consistent convention such as matching the VNI value in both octets (e.g., 10010:10010 for VNI 10010).

    Can I use OSPF instead of eBGP for the underlay?

    Yes, OSPF or IS-IS can be used as the underlay, but eBGP is strongly preferred. eBGP provides built-in loop prevention, scales linearly as leaves are added, and supports per-prefix policy without area design complexity. OSPF is workable in smaller environments but requires careful tuning for ECMP and convergence.

    What is ARP suppression and when should it be enabled?

    ARP suppression lets the local VTEP answer ARP requests using MAC/IP bindings learned from EVPN Type-2 routes, preventing ARP floods from crossing the VXLAN fabric. It should always be enabled in production deployments. Configure it with vxlan arp proxy on the Vxlan1 interface, with no additional changes required.

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

    On each participating leaf: (1) create the VLAN with vlan X, (2) add the VLAN-to-VNI mapping on the Vxlan1 interface, and (3) add the VLAN stanza to router bgp with rd auto, a matching route-target both, and redistribute learned. For routed access, also add an SVI with ip address virtual in the correct VRF. No spine changes are needed.

    What EVPN route types does Arista EOS use?

    EOS primarily uses Type-2 (MAC/IP Advertisement) for host reachability and ARP suppression, Type-3 (IMET) for VTEP BUM flood list membership, Type-5 (IP Prefix) for inter-VLAN routing via symmetric IRB, and Type-1 (Ethernet Auto-Discovery) for EVPN multihoming fast convergence. Types 2, 3, and 5 are active in a standard leaf-spine deployment.

    How do I verify that VXLAN tunnels are forwarding traffic and not just established?

    Use show vxlan vtep to confirm remote VTEP discovery, show vxlan address-table to see remote MACs learned via tunnels, and show interfaces Vxlan1 to check packet counters incrementing under live traffic. The show platform fwd vxlan command provides hardware-level VTEP statistics on supported platforms.

    What MTU should I set on underlay interfaces for VXLAN?

    Set all underlay-facing interfaces to at least 9214 bytes. VXLAN adds 50 bytes of overhead per frame (8-byte VXLAN header, 8-byte UDP, 20-byte IP, 14-byte outer Ethernet). Using 9214 bytes supports 9000-byte inner jumbo frames end-to-end. Insufficient MTU is one of the most common causes of intermittent VXLAN issues, as oversized frames may be silently dropped.

    Related Articles