Arista EOS EVPN-VXLAN Symmetric IRB Configuration

In an EVPN-VXLAN fabric, the choice between asymmetric and symmetric integrated routing and bridging decides how inter-subnet traffic is encapsulated and how many VRFs every leaf must know about. Symmetric IRB routes on both the ingress and egress leaf using an L3 VNI mapped to a VRF, which keeps the fabric scale-friendly: a leaf only needs the VLANs and VRFs it actually serves. This is the EOS configuration for a symmetric IRB leaf, plus the verification that proves traffic is taking the intended path.

What symmetric IRB means in practice

• Every VLAN that needs inter-subnet routing is mapped to a Layer 2 VNI (one VNI per VLAN, the L2 domain).
• Every VRF is mapped to a Layer 3 VNI, so routed traffic between VRFs or subnets is carried in the L3 VNI.
• The ingress leaf routes the packet into the destination VRF (or the shared VRF for inter-VRF routing) and encapsulates with the L3 VNI; the egress leaf decapsulates and forwards in the target VLAN.

Because both ends route, the MAC-VRF and IP-VRF tables are separate and the fabric does not need to carry every tenant VLAN on every leaf.

Global preparation

switch(config)# ip routing
switch(config)# vrf instance RED
switch(config-vrf-RED)# rd 10.255.0.0:501
switch(config-vrf-RED)# exit
switch(config)# ip routing vrf RED
switch(config)# interface Loopback1
switch(config-if-Lo1)# ip address 10.255.0.11/32
switch(config-if-Lo1)# exit

Loopback1 is the VTEP source address: it must be reachable across the underlay and identical in function on every leaf. Using the same loopback for BGP and the VTEP is common; keeping the VTEP address stable across hardware replacements is what makes it worth separating them.

The VXLAN interface

switch(config)# interface Vxlan1
switch(config-if-Vx1)# vxlan source-interface Loopback1
switch(config-if-Vx1)# vxlan udp-port 4789
switch(config-if-Vx1)# vxlan vlan 10 vni 10010
switch(config-if-Vx1)# vxlan vlan 20 vni 10020
switch(config-if-Vx1)# vxlan vrf RED vni 50001

Each vxlan vlan … vni line creates the L2 mapping; the vxlan vrf … vni line creates the L3 mapping for the tenant VRF. Keep VNI numbers in a documented scheme - for example 100xx for L2 VNIs derived from the VLAN and 50xxx for L3 VNIs per VRF - because the mapping is the first thing you will need to read during an incident.

EVPN control plane

switch(config)# router bgp 65001
switch(config-router-bgp)# neighbor 10.255.0.1 remote-as 65001
switch(config-router-bgp)# neighbor 10.255.0.1 update-source Loopback0
switch(config-router-bgp)# neighbor 10.255.0.1 description spine-rr
switch(config-router-bgp)# !
switch(config-router-bgp)# vlan 10
switch(config-mac-vrf-10)# rd 10.255.0.11:10
switch(config-mac-vrf-10)# route-target both 65001:10010
switch(config-mac-vrf-10)# redistribute learned
switch(config-mac-vrf-10)# exit
switch(config-router-bgp)# vrf RED
switch(config-mac-vrf-RED)# rd 10.255.0.11:501
switch(config-mac-vrf-RED)# route-target both 65001:50001
switch(config-mac-vrf-RED)# redistribute connected
switch(config-mac-vrf-RED)# exit
switch(config-router-bgp)# address-family evpn
switch(config-router-bgp-af)# neighbor 10.255.0.1 activate
switch(config-router-bgp-af)# exit
switch(config-router-bgp)# address-family ipv4
switch(config-router-bgp-af)# no neighbor 10.255.0.1 activate

Two details cause most of the "it builds but does not route" problems. First, the EVPN address family must be activated towards the spine; if the spine is acting as a route reflector for EVPN, next-hop-unchanged is required so the VTEP address survives reflection. Second, disabling the IPv4 address family for an EVPN-only neighbour prevents the fabric from learning and preferring underlay routes over the EVPN overlay paths.

First-hop gateway on a multihomed leaf pair

switch(config)# interface Port-Channel100
switch(config-if-Po100)# switchport mode trunk
switch(config-if-Po100)# switchport trunk allowed vlan 10,20
switch(config-if-Po100)# evpn ethernet-segment
switch(config-evpn-es)# identifier 0033:3333:3333:3333:3333
switch(config-evpn-es)# route-target import 00:03:00:03:00:03
switch(config-evpn-es)# lacp system-id 1234.5678.0123

The Ethernet Segment identifier plus the LACP system ID make a pair of leaves look like one LAG to the server or downstream switch, with the route-target import providing split-horizon filtering so the two leaves do not forward the same frame to each other. Servers are then served by MLAG or by ESI multihoming depending on whether the host supports LACP across the pair. For the SVI, use a VARP IP and a globally configured VARP MAC so both leaves answer for the gateway address - the same active/active first-hop model used with MLAG.

Verification

switch# show vxlan vtep
switch# show vxlan address-table
switch# show bgp evpn summary
switch# show bgp evpn route-type mac-ip
switch# show bgp evpn route-type imet
switch# show bgp evpn route-type ip-prefix
switch# show interfaces vxlan 1
switch# show ip route vrf RED

The sequence to check is: is the remote VTEP known (show vxlan vtep), is the remote MAC or IP in the EVPN tables, and does the VRF routing table have the prefix pointing at the correct next hop. If the L2 entry exists but the IP prefix route is missing, the L3 VNI mapping or the VRF route-target is the problem.

Operational notes

• Verify the underlay MTU end to end before troubleshooting the overlay; VXLAN encapsulation plus a 1500-byte payload requires a larger underlay MTU, and the symptom is small pings working while large transfers stall.
• Keep the RD scheme unique per VTEP and per VRF, and document it - duplicate RDs create confusing route collisions.
• Check show bgp evpn for duplicate MAC or IP advertisement before adding new segment IDs, and always confirm the flood list (IMET) entries match the expected VLAN-to-VNI pairs.
• Validate with real traffic between VRFs, not only pings inside one VLAN; that is where routing and route-target mistakes surface.

Related: Arista EOS MLAG configuration guide, EVPN multihoming vs MLAG: ESI and DF election, and EOS VLAN, trunk and SVI examples.

原文链接：https://arista.com/um-eos/eos-sample-configurations