Arista EOS VXLAN Configuration: VTEP and Bridging

VXLAN on Arista EOS is deceptively simple to configure and notoriously hard to debug, because most failures are silent: the tunnel interface comes up, MAC addresses simply never appear. This guide builds a complete VXLAN bridging overlay step by step on EOS — VTI creation, VTEP source selection, VLAN-to-VNI mapping, and the choice between head-end replication and multicast — then shows the exact command sequence that proves traffic is actually tunnelling. If you already run BGP EVPN as the control plane, jump to the EVPN section; if not, start here, because the data plane is identical.

How VXLAN works on EOS

EOS uses a single logical tunnel interface, interface Vxlan1 (the VTI), rather than per-tunnel interfaces. The VTEP identifier is the IP address of a loopback assigned with vxlan source-interface. Every VNI maps to a VLAN, and that mapping determines which local VLAN is bridged onto which remote segment.

There are two control planes: static/head-end replication (no protocol, each VTEP floods to every peer) and BGP EVPN (MAC/IP routes learned dynamically). The encapsulated packet format is the same; Genève is a related but separate option, compared in Genève vs VXLAN overlay encapsulation.

Prerequisites

Underlay reachability to all VTEP loopbacks (OSPF/IS-IS or eBGP)
MTU 9214 end-to-end, or 1550+ in the underlay path
Loopback0 addresses unique per VTEP
On R-series, VXLAN routing needs: hardware tcam profile vxlan-routing

Step 1 — Create the VTI and set the source interface

switch(config)# interface Loopback 0
switch(config-if-Lo0)# ip address 10.10.0.11/32

switch(config)# interface Vxlan 1
switch(config-if-Vx1)# vxlan source-interface Loopback0
switch(config-if-Vx1)# vxlan udp-port 4789
switch(config-if-Vx1)# no shutdown

UDP 4789 is the IANA-assigned VXLAN port; leave it alone unless the peer explicitly uses 8472 (older Linux implementations).

Step 2 — Map VLANs to VNIs (head-end replication)

switch(config)# vlan 110
switch(config)# interface Vlan110
switch(config-if-Vl110)# vxlan vni 10110
switch(config-if-Vl110)# exit

switch(config)# interface Vxlan 1
switch(config-if-Vx1)# vxlan vlan 110 vni 10110
switch(config-if-Vx1)# vxlan flood vtep 10.10.0.12 10.10.0.13

The same VNI value must be configured on every VTEP that should share that L2 segment. vxlan flood vtep lists all remote VTEPs for head-end replication — every unknown unicast, broadcast and multicast frame is replicated to this list, so it must be complete.

Access ports and the uplink stay completely normal VLAN config; see EOS VLAN configuration for the basics.

Step 3 — Optional: multicast underlay

switch(config-if-Vx1)# vxlan vlan 110 vni 10110 multicast group 239.1.1.1
! underlay must run PIM-SM with a reachable RP, transport 224.0.0.9 will
! leave the source, and enable PIM on the loopback and uplinks

Multicast avoids maintaining a static peer list but requires a working PIM-SM domain with an RP — more moving parts, less operational risk of a stale flood list.

Step 4 — Bridging over EVPN (recommended at scale)

switch(config)# router bgp 65001
switch(config-router-bgp)# neighbor SPINES peer group
switch(config-router-bgp)# neighbor SPINES remote-as 65001
switch(config-router-bgp)# neighbor SPINES update-source Loopback0
switch(config-router-bgp)# address-family evpn
switch(config-router-bgp-af)# neighbor SPINES activate
switch(config-if-Vx1)# vxlan vlan 110 vni 10110    ! no flood list needed

With EVPN, the flood list is replaced by MAC/IP advertisement (Type-2 routes) and IMET (Type-3). The full symmetric IRB design with MLAG — the mainstream data-centre pattern — is documented in Arista EOS EVPN VXLAN symmetric IRB.

Verification

show vxlan config-sanity                 ! first stop: flags missing pieces
show vxlan config-sanity detail          ! per-VLAN checks
show interfaces Vxlan1                   ! VTI up, source interface resolved
show vxlan address-table                 ! remote MAC -> VTEP bindings
show vxlan vtep                          ! learned remote VTEPs
show mac address-table vlan 110          ! local + remote MACs
show bgp evpn summary                    ! when using EVPN
show interfaces Vxlan1 counters errors

show vxlan config-sanity is the single most valuable command: it explicitly reports missing source-interface resolution, missing VNI mappings, MTU problems and MLAG-related inconsistencies.

Troubleshooting

Symptom                              Check
No remote MACs learned               flood vtep list complete? underlay MTU?
Ping fails, ARP resolves             MTU on the underlay path, UDP 4789 filtered
Works locally, fails cross-VTEP      Same VNI number on both ends
EVPN routes missing Type-2           EVPN AF not activated on the peer group
Sporadic drops under load            burst of flooded traffic (no EVPN control plane)

FAQ

Q: Do I need a dedicated loopback per VNI? No — one loopback per VTEP is standard; VNIs are distinguished by the 24-bit VNI field in the packet, not by the source address.
Q: Can VXLAN and MLAG coexist? Yes, and it is the standard leaf design: MLAG for the access side, VXLAN/EVPN for the fabric side.
Q: What about IPv6 underlay? EOS supports VXLAN bridging over an IPv6 underlay; set the loopback to an IPv6 address and the source interface resolves accordingly.

原文链接：https://www.arista.com/en/um-eos/eos-vxlan-configuration