EVPN and BGP routing across Proxmox clusters

Why this matters in production

EVPN lets you build a single routed fabric that spans clusters, racks, and even data centres, while keeping VMs in familiar L2 segments. It is the most sophisticated network construct Proxmox offers, and the most operationally complex. Use it when simpler constructs (VLAN-aware bridges, plain VXLAN) cannot meet the requirement.

Mental model

EVPN is BGP + VXLAN + a control plane. BGP carries reachability information; VXLAN encapsulates L2 frames; the EVPN address family tells BGP how to advertise MAC/IP bindings.

flowchart LR
  subgraph DC1[Data centre 1]
    N1[pve-01]
    N2[pve-02]
  end
  subgraph DC2[Data centre 2]
    N3[pve-03]
    N4[pve-04]
  end
  N1 -->|VXLAN + BGP| N3
  N2 -->|VXLAN + BGP| N4

Each Proxmox node becomes a VTEP (VXLAN Tunnel Endpoint) with a routable IP. BGP sessions between VTEPs exchange reachability. The result: a VM on node 1 can be in the same L2 segment as a VM on node 4 across the WAN, as if they were on the same switch.

When EVPN is appropriate

Components

An EVPN deployment in Proxmox needs:

• EVPN controller — manages the FRR configuration for BGP/EVPN.
• EVPN zone — the zone that VNets use; declares the controller, exit nodes, anycast gateway.
• Fabric — provides the underlay (typically OpenFabric or OSPF). VTEP IPs come from the fabric’s loopback.
• BGP controller (optional) — for inter-fabric or external BGP.
• VNets inside the zone — they inherit the EVPN semantics.
• Subnets — IP ranges that get advertised.

Configuring an EVPN zone (high level)

1. Install FRR (apt install frr frr-pythontools).
2. Create a fabric (Datacenter → SDN → Fabrics) — this provides VTEP IPs.
3. Create an EVPN controller (Datacenter → SDN → Controllers) referencing the fabric.
4. Create an EVPN zone (Datacenter → SDN → Zones) referencing the controller, with exit nodes if you want external connectivity.
5. Create VNets inside the zone (Datacenter → SDN → VNet) and assign tags.
6. Apply the SDN configuration.

Anycast gateway

An EVPN zone can declare an anycast gateway IP. The same gateway IP exists on every node that hosts a VNet in the zone. From the VM’s perspective, the gateway is always “immediately local,” which is exactly what a stretched L2 network expects.

flowchart TB
  VM1[VM on pve-01] --> GW1[Gateway 10.10.100.1 on pve-01]
  VM2[VM on pve-03] --> GW2[Gateway 10.10.100.1 on pve-03]
  GW1 -. same IP .- GW2

This is what makes live migration across an EVPN fabric seamless: the VM keeps its IP and its gateway.

Type-2 and Type-5 routes, and why the distinction matters

EVPN carries several route types over BGP. Two of them account for almost everything a Proxmox operator sees, and telling them apart is what turns show bgp l2vpn evpn from noise into a diagnosis.

Type-2 — MAC/IP advertisement. One route per endpoint: “this MAC address, optionally with this IP, is behind this VTEP.” It is how a VM becomes reachable at layer 2 across the fabric, and it is how a live migration is absorbed — the VM arrives on a new node, that node advertises a new Type-2 route for the same MAC, and every other VTEP updates its forwarding.

Type-5 — IP prefix route. One route per subnet: “this prefix is reachable through this VTEP.” It carries layer 3 reachability without any layer 2 information, which is what you want for a routed segment that does not need stretched L2.

The operational differences follow directly:

vtysh -c 'show bgp l2vpn evpn summary'
vtysh -c 'show bgp l2vpn evpn route type macip'
vtysh -c 'show bgp l2vpn evpn route type prefix'
vtysh -c 'show evpn vni detail'

A Type-2 route that persists for a MAC that no longer exists — a deleted VM, a migration that did not withdraw cleanly — is a stale entry that blackholes traffic for that address. show evpn mac vni all lists them per VNI, and comparing that against the MACs your guests actually have is the reconciliation worth running after a messy migration.

Route targets and inter-DC

EVPN uses BGP route-targets (RTs) to constrain route advertisement. By default, an EVPN zone uses an auto-derived RT. To connect to external EVPN networks or to other zones, set Route-target Import on the zone.

Route filtering on top of the RTs — deciding which prefixes the fabric advertises outward and which it accepts — is the subject of the BGP policy lesson, and an EVPN fabric with an external peering is the case where it stops being optional.

CLI walkthrough

pvesh get /cluster/sdn/zones --type evpn --output-format yaml

vtysh -c 'show bgp l2vpn evpn summary' 2>/dev/null || journalctl -u frr --since '5 min ago' | tail -30

Production considerations

Common mistakes

• Using EVPN within a single cluster instead of a VLAN-aware bridge.
• Forgetting MTU adjustments for VXLAN.
• Crossing an untrusted WAN without an encrypted underlay.
• Letting BGP session drops go unnoticed. EVPN needs all VTEPs to be reachable; one dead session can blackhole VMs.

Key takeaways

• EVPN is BGP + VXLAN; great for multi-cluster and multi-DC.
• Within a single cluster, simpler constructs suffice.
• Type-2 routes carry MAC/IP bindings and scale with guest count; Type-5 routes carry prefixes and scale with subnet count. Prefer Type-5 designs unless stretched layer 2 is genuinely required.
• Plan MTU and encryption carefully.

Knowledge check