Huawei VXLAN Distributed Gateway with BGP EVPN Config

Distributed VXLAN gateways solve the two classic problems of centralized gateway designs: suboptimal forwarding paths and ARP entry bottlenecks. This article walks through a complete Huawei CloudEngine configuration — EBGP underlay, M-LAG dual-active gateways, EVPN as the VXLAN control plane, and VBDIF anycast gateways — with the full command sequence and verification output, so you can reproduce the design in your own data center.

The configuration below is unchanged from the original walkthrough. Around it this expanded guide adds the reasoning that makes the design defensible in a review: why anycast gateways are worth the complexity, what every identifier in the config actually means, how to verify each layer independently, what breaks when the tunnel refuses to come up, and the MTU arithmetic that VXLAN forces on the underlay.

Design Overview: Distributed Gateways with BGP EVPN

In this example, VMs on Server1 (VLAN 10) and Server2 (VLAN 20) live in different network segments, connected to the VXLAN fabric through Device2 and Device4. Those two devices are configured as Layer 3 VXLAN gateways in dual-active mode, while Device1 (AS 100) acts as the BGP EVPN route reflector for Device2/3/4. Key data: BD IDs 10/20, VNI IDs 10/20, VNI 5010 for the VPN instance, plus RDs and RTs for the VPN and EVPN instances.

Centralized vs Distributed Gateway

The trade is explicit: you accept configuration repetition and a stricter change process in exchange for removing a bandwidth bottleneck and an ARP scaling cliff. In Huawei terms the gateway is a VBDIF (VLAN-based distributed interface) bound into a VPN instance, with vxlan anycast-gateway enable making it answer for the subnet on more than one leaf.

1. EBGP Underlay and M-LAG Between Gateways

[~Device1] bgp 100
[*Device1-bgp] router-id 1.1.1.1
[*Device1-bgp] peer 192.168.2.1 as-number 200
[*Device1-bgp] peer 192.168.3.1 as-number 300
[*Device1-bgp] network 1.1.1.1 32
[*Device1-bgp] commit

Since Device2 and Device4 are both in AS 200, run peer 192.168.2.2 allow-as-loop on Device2 and peer 192.168.4.2 allow-as-loop on Device4 so they can exchange BGP routes. Then build the M-LAG: LACP static Eth-Trunks, V-STP, a DFS group with dual-active detection, and the peer-link between the gateways.

Why allow-as-loop Is Needed

Two devices in the same AS peering directly with each other is normally a loop, and BGP rejects it. In this design Device2 and Device4 are a single logical gateway, so they must exchange routes for the anycast gateway and for their shared M-LAG links; allow-as-loop tells BGP to accept its own AS number in the path for that specific peer. Without it the sessions come up but the EVPN and anycast gateway routes never appear, which presents as a tunnel that exists and a gateway that silently forwards nothing.

M-LAG Skeleton on the Gateway Pair

[~Device2] interface Eth-Trunk 1
[*Device2-Eth-Trunk1] mode lacp-static
[*Device2-Eth-Trunk1] peer-link
[*Device2-Eth-Trunk1] commit
[~Device2] dfs-group 1
[*Device2-dfs-group-1] priority 150
[*Device2-dfs-group-1] source ip 192.168.2.2
[*Device2-dfs-group-1] peer ip 192.168.4.2
[*Device2-dfs-group-1] commit
[*Device2-dfs-group-1] m-lag 1
[~Device2-dfs-group-1-m-lag-1] dfs-group 1 m-lag-id 1
[*Device2-dfs-group-1-m-lag-1] peer-link 1
[*Device2-dfs-group-1-m-lag-1] commit

The DFS group carries the dual-active detection heartbeat and the source/peer addresses used for synchronisation. The peer-link must be an Eth-Trunk with LACP static mode — a single member link is a design defect, because peer-link failure alone puts both halves into a split state that requires a manual decision about which side keeps forwarding.

2. EVPN as the VXLAN Control Plane

[~Device1] evpn-overlay enable
[*Device1] bgp 100 instance evpn1
[*Device1-bgp-instance-evpn1] l2vpn-family evpn
[*Device1-bgp-instance-evpn1-af-evpn] peer 2.2.2.2 reflect-client
[*Device1-bgp-instance-evpn1-af-evpn] undo policy vpn-target
[*Device1-bgp-instance-evpn1-af-evpn] peer 2.2.2.2 advertise irb
[*Device1-bgp-instance-evpn1-af-evpn] commit

Device1 is the RR for the EVPN address family; gateways peer with it over loopback IBGP. advertise irb propagates IRB routes so hosts behind different gateways learn each other's MAC/IP.

Two statements deserve a note. undo policy vpn-target on the reflector disables route-target filtering for the EVPN address family, so the RR reflects every EVPN route it receives instead of only those matching a locally configured RT — correct behaviour on a pure reflector that is not itself a VTEP or gateway. advertise irb makes the gateway originate the IRB/MAC-IP routes for the subnets it serves, which is what allows MAC and ARP learning to happen through the control plane rather than flooding.

Control Plane Roles in One Table

3. VPN/EVPN Instances and VBDIF Anycast Gateways

[~Device2] ip vpn-instance vpn1
[*Device2-vpn-instance-vpn1] vxlan vni 5010
[*Device2-vpn-instance-vpn1-af-ipv4] route-distinguisher 20:2
[*Device2-vpn-instance-vpn1-af-ipv4] vpn-target 100:5010 evpn
[*Device2] interface vbdif10
[*Device2-Vbdif10] ip binding vpn-instance vpn1
[*Device2-Vbdif10] ip address 10.1.1.1 255.255.255.0
[*Device2-Vbdif10] mac-address 0000-5e00-0102
[*Device2-Vbdif10] vxlan anycast-gateway enable
[*Device2-Vbdif10] arp collect host enable
[*Device2-Vbdif10] commit

Device2 and Device4 must use the same VBDIF IP and MAC — they form the dual-active anycast gateway, so hosts see one gateway while both switches forward traffic. Device3's VBDIF sits on a different subnet and needs no MAC.

What Each Identifier Means

The RD is the one identifier that must not be duplicated across leaves: if Device2 and Device4 both advertise with RD 20:2, the receiving devices see two routes for the same NLRI and treat them as a path comparison instead of two distinct MAC-IP advertisements, which produces asymmetric and hard-to-reproduce forwarding failures. Use a per-device RD (for example 20:2 on Device2 and 20:4 on Device4) and a shared RT.

Anycast Gateway MAC: The Rules That Matter

• Same IP, same MAC, per subnet, on every gateway. That is what makes a host's ARP cache valid no matter which leaf answers.
• Different subnets get different MACs. Two VBDIFs on the same leaf cannot share one anycast MAC, and the subnet-to-MAC mapping must be globally consistent.
• Never use a vendor-default MAC that could collide with real hardware in the same broadcast domain; the 0000-5e00-01xx range used here is deliberately syntactically local.
• Enable host ARP collection (arp collect host enable) so the gateway learns host addresses from ARP/ND rather than from data-plane flooding, which is the mechanism that removes the ARP scaling limit of centralized designs.

Verification

[~Device2] display vxlan tunnel
Number of vxlan tunnel : 1
Tunnel ID        Source       Destination  State  Type     Uptime
4026531841       2.2.2.210   3.3.3.3      up     dynamic  0032h21m

The tunnel only comes up after a server is connected (IRB routes must exist). Verify each layer separately rather than jumping to the data plane:

[~Device2] display bgp evpn peer
[~Device2] display bgp evpn all routing-table
[~Device2] display vxlan vni 5010
[~Device2] display dfs-group 1 m-lag
[~Device2] display eth-trunk 1
[~Device2] display mac-address vlan 10

The order matters. A healthy BGP EVPN peer list proves the underlay and the overlay session; a populated EVPN routing table proves the RR is reflecting and the RTs are correct; a up tunnel in display vxlan vni proves the data plane can reach the remote VTEP; a converged display dfs-group 1 m-lag proves the dual-active pair is intact; and a MAC address learned locally with a remote entry proves end-to-end learning. If the tunnel list is empty while the BGP session is up, the fault is almost always the underlay route to the remote loopback, not VXLAN.

Troubleshooting: When the Tunnel Stays Down

MTU: The Constraint VXLAN Adds to the Underlay

Every VXLAN-encapsulated frame carries the original Ethernet header plus a 50-byte tax: 20 bytes of outer IPv4, 8 bytes of UDP, 8 bytes of VXLAN header and 14 bytes of a second Ethernet header. A tenant frame of 1500 bytes therefore becomes 1550 bytes on the wire, so the underlay must carry at least 1600-byte frames between VTEP loopbacks — and more if the tenant itself uses jumbo frames.

The failure mode is subtle and worth designing against: small control traffic, ARP and pings all pass, so the fabric looks healthy, while large data transfers silently drop and stall. Set the underlay and all intermediate links to a configurable MTU of at least 1600 (9000 if tenants use jumbo frames), and validate with an end-to-end ping of the largest expected payload with the DF bit set before declaring the fabric ready. The arithmetic and the diagnosis path are covered in more depth in our VXLAN MTU and fragmentation guide.

Design Checklist

1. Underlay reachability to every VTEP loopback, verified before any overlay configuration.
2. Unique RD per leaf, shared RT per tenant or L3 VRF.
3. Consistent VNI, BD and anycast gateway MAC/IP across all leaves serving a subnet.
4. M-LAG peer-link as a multi-member Eth-Trunk with LACP static mode.
5. VBDIF bound to the correct VPN instance, with anycast gateway and host ARP collection enabled.
6. Underlay MTU sized for 50 bytes of encapsulation overhead end to end.
7. Verification scripted layer by layer: BGP, EVPN table, VNI, DFS group, MAC table.
8. Rollback tested — Huawei CE commits are transactional, so practise the rollback path before a change window.

For the control-plane theory, compare with our VXLAN MP-BGP EVPN design guide and the Junos EVPN-VXLAN CRB fabric config; config safety nets in Huawei CE configuration rollback.

原文链接：https://tech.pansolusi.com/2025/03/14/configure-vxlan-in-distributed-gateway-mode-using-bgp-evpn-huawei-fabric