How to Filter BGP and EVPN Routes in Proxmox VE 9.2

If you use the Proxmox firewall, edit the cluster rules file. Because /etc/pve is shared, the rules reach all nodes:

Add these lines under the [RULES] section. Create the section if it does not exist:

If you turn on the firewall for the first time, keep SSH (port 22) and the web UI (port 8006) open, so you do not lock yourself out.

First, you must build EVPN without filters. Then, you must add the filters later. This order makes problems easy to find in your Proxmox BGP EVPN configuration with route maps.

In the web UI, go to Datacenter > SDN > Options > Controllers > Add > EVPN, and fill in:

The peer list must include every node, including the local one. Peers can also be external nodes or route reflectors.

If you prefer a CLI option, you can use the command below instead:

From the web UI, go to Datacenter > SDN > Zones > Add > EVPN, and fill in:

The VRF VXLAN ID must be different from the VXLAN IDs (tags) of the VNets. Exit nodes are the gateways to the real network, and they announce a default route inside EVPN. The primary exit node forces all outside traffic through pve1. This is needed when your upstream router does not support ECMP, or when you use SNAT. Advertise Subnets helps when a VM is silent, because it announces the full subnet.

If you prefer a CLI option, you can use the command below instead:

At this point, go to Datacenter > SDN > VNets > Create. VNet IDs can have up to 8 characters:

After you create a VNet, select it and add the subnet in the Subnets panel. In an EVPN zone, the gateway is deployed on the VNet on every node, so VMs can use it as an anycast gateway.

If you prefer a CLI option, you can use the command below instead:

SDN changes stay pending until you apply them. In the UI, go to Datacenter > SDN and click Apply. Or use the CLI:

To check the base fabric, run these on each node:

You should see two established neighbors in the EVPN summary, a web bridge, a vxlan_web device with MTU 1450, and a VRF named vrf_evpnz1.

You can also see the generated files with the following commands:

Create two VMs or containers. Put one on pve2 and one on pve3. Set their network bridge to web. Inside each guest, set a static IP and the right MTU. On Debian, edit /etc/network/interfaces in the guest:

Use 172.16.10.12/24 for the second guest. Restart the network, then test:

The last ping sends the biggest packet that fits: 1422 bytes of data plus 28 bytes of headers equals 1450. If it works, the overlay MTU is correct.

This is the main part of the Proxmox BGP EVPN configuration with route maps setup. You must create the prefix lists. Go to Datacenter > SDN > Prefix Lists > Add. Create three lists. 

The names only_default, only_default_v6, and loopbacks_ips are reserved. Proxmox creates them itself, so do not use them.

This first prefix list matches only the default route (0.0.0.0/0). We will use it later to accept nothing else from the upstream router. Create it with the values below:

With no ge or le, this matches exactly 0.0.0.0/0. It does not match other routes.

This second prefix list matches the web and db subnets. We will use it to control which networks we send to the upstream router. Leave the lab subnet out of this list:

This third prefix list matches the lab subnet and every smaller route inside it, such as host routes. We will use it later to block the lab network from remote EVPN peers. Create it with the values below:

Here ge 24 and le 32 match the /24 itself and also smaller routes inside it, such as /32 host routes. Proxmox checks that ge is not bigger than le, and that neither is smaller than the prefix length.

Leave gaps in the sequence numbers (10, 20, 30). This leaves room to add lines later.

Route maps use the prefix lists to decide what to do with each route. Go to Datacenter > SDN > Route Maps > Add. Each entry has an Order (0 to 65535), an Action, and optional Match and Set values. You must create these entries.

This map controls what we accept from the upstream router. Create it with the values below:

Only the default route passes. Every other route is dropped automatically. The route also gets a higher local preference.

This map controls what we announce to the upstream router. Create it with the values below:

Only 172.16.10.0/24 and 172.16.20.0/24 can leave. The lab subnet is dropped automatically, so it stays private.

This map controls what we accept from other EVPN peers. Create it with the values below:

An entry applies only when all of its match rules are true. Entry 10 drops only prefix routes (EVPN type-5) that match the lab network. Entry 20 lets all other routes pass. Without entry 20, every other EVPN route would be dropped, and the fabric would break.

This map blocks the lab prefix route from remote peers. VM-level routes (type-2) are not touched, so VMs in lab can still talk to each other.

Exit nodes talk to the upstream router with BGP. This part of the Proxmox BGP EVPN configuration with route maps guide adds that link. You must create one BGP controller per exit node.

Go to Datacenter > SDN > Options > Controllers > Add > BGP and fill in:

The ASN here is the local ASN of the node. EBGP is on because the upstream router has a different ASN (65001). The peer is directly connected, so you do not need ebgp-multihop.

If you prefer the CLI option, you can use the command below:

When a BGP controller exists, and the EVPN controller is in auto mode, the EVPN peers reuse the BGP session type. That makes the node-to-node sessions eBGP, and they will fail because all nodes use the same ASN. To avoid this, you must set the type manually.

Open Datacenter > SDN > Options > Controllers, edit evpnctl, and set:

The nodes now use iBGP between each other (same ASN 65000) and eBGP to the upstream router.

To apply the changes, go to Datacenter > SDN and click Apply. Or, run the command below:

To configure the upstream router, you can use a Linux router with FRR. Install it and turn on the BGP daemon:

Then, open the FRR shell and add the config:

The default-originate lines send a default route to both exit nodes. The line no bgp ebgp-requires-policy is for the lab only. Newer FRR blocks eBGP routes if no route map is set on the session. In production, use route maps on the router too.

Proxmox now has the full filter set. This is what each node does after you apply. The EVPN controller keeps its own built-in MAP_VTEP_IN and MAP_VTEP_OUT maps and calls your map from them.

On exit nodes, Proxmox also keeps a built-in rule that denies default routes inside EVPN. This stops traffic loops between exit nodes, and your map does not remove it.

Use the commands below to look at what Proxmox stored:

You should see the files prefix-lists.cfg and route-maps.cfg in that folder. Do not edit them manually. Use the UI or the API.

Now you must look at what FRR got. Run this on pve1:

If the lines are missing, you forgot to click Apply, or the map is not attached to a controller.

Now you must check that everything works as planned. In this step, you should look at the BGP sessions, the routes you accept and announce, and the EVPN routes. Also, you should confirm that your route maps are being used.

First, make sure the BGP sessions are up. If a session is down, no routes can move, and the route maps have nothing to filter. Run these commands on each node:

On the exit nodes, the neighbor 192.168.50.1 must be in the Established state, and it must show 1 prefix received. The two EVPN peers must be established too.

Next, check which routes the exit nodes accept from the upstream router. The from-upstream route map should let only the default route through. Run these commands on pve1 and pve2:

The first command shows routes before the incoming map. The second shows routes after it. Only 0.0.0.0/0 should be in the second list, with local preference 200.

Now check which routes the exit nodes send to the upstream router. The to-upstream route map should allow only the web and db subnets. Run this command on pve1 and pve2:

You should see 172.16.10.0/24 and 172.16.20.0/24 with metric 100. You must not see 172.16.30.0/24. On the upstream router, check the same:

At this point, you must look at the EVPN side. These commands show the routes shared between nodes, the routes inside the VRF, and the VNIs that are active. Run them on each node and compare the output:

Finally, you must confirm that FRR is really using your prefix lists and route maps. Each route map shows a counter that goes up every time it is used. Run these commands on each node:

The route map output has an Invoked counter. If a map is never invoked, it is not attached to the session.

From a guest in web, check outside access and that the lab subnet is not visible upstream:

Outside traffic needs the upstream router to know the way back to 172.16.10.0/24. If it does not, enable SNAT on the subnet, or add routes on the router.

When you change a map, you must apply the SDN, and then ask FRR to resend routes without resetting the session:

This guide builds one site on a private routed network. If your nodes are in different data centers and you need an encrypted link, you must build the tunnel first. You can check our guide on how to build a multi-site Proxmox SDN with a WireGuard fabric. In that setup, the tunnel is the underlay.

If you want to run this EVPN design over that tunnel, you must follow these rules:

• Use the WireGuard addresses as the EVPN controller peers.
• Use the tunnel MTU rule from that guide: 1370 in the zone and in the guests.
• Use different IP ranges for the tenant networks. Do not reuse the ranges of the tunnel.
• Do not open UDP 4789 on public interfaces. Allow it only on the tunnel interface.

Even with a good setup, things can go wrong. In this section, you can find the most common problems, such as missing routes, wrong ASNs, MTU issues, and one-way traffic. Each problem comes with simple checks and fixes.

Most Proxmox BGP EVPN configuration issues come from the session or the map. Start with the session, then the map.

Common causes and fixes include:

• You did not click Apply. Check with pvesh get /cluster/sdn/route-maps and vtysh -c "show running-config".
• The implicit deny drops the route. Add a final permit entry if you want everything else to pass.
• The prefix does not match. A line without ge or le matches one exact network. A /24 route does not match a /16 entry unless you set le 24 or ge 24.
• The sequence is wrong. The first match wins, so a deny with a low number can hide a later permit.
• The default route is missing inside EVPN. On exit nodes, Proxmox's built-in rule drops default routes from other EVPN peers on purpose. The default route comes from the exit nodes themselves.
• The session shows (Policy) in show bgp summary. FRR blocks eBGP routes when no route map is set. Attach a map to the session.
• The route was filtered in the past, and you changed the map. Run clear bgp ... soft in.

When a BGP session will not come up, the state and the last error usually tell you why. Run these commands to see both:

Common causes and fixes include:

• The state is Idle or Active. The peer is not reachable; the firewall blocks TCP 179, or the ASN does not match.
• The log says Bad Peer AS. The remote ASN on one side is wrong. Check the neighbor ... remote-as line on the router.
• All EVPN controllers on one node must use the same ASN.
• If a node has two iBGP sessions with different ASNs, Proxmox rejects the config. One FRR instance has only one local ASN.
• The EVPN peers are eBGP when they should be iBGP. Set BGP Mode to internal on the EVPN controller.
• You used a public ASN. Use private ASNs only.

Use this section to check for MTU problems when ping works but SSH, HTTPS, or file transfers hang. Test the network between the nodes, then test from inside a guest.

Common causes and fixes include:

• The zone MTU is bigger than the underlay MTU minus 50.
• The guest MTU is still 1500. Set it to the zone MTU in the guest network file.
• A switch or the provider network has a smaller MTU than you think.
• The MTU on the node bridge went back to default after a reload. Check ip link show vmbr0.

Use this section when traffic works in one direction, but replies do not return. Check the routes on both sides, then review the route maps, exit nodes, and firewall rules.

Run these on both nodes and compare. Common causes and fixes include:

• A route map filters routes on one node only. Check the maps on both sides with show route-map.
• You have two exit nodes, but the upstream router sends replies to the other one. Use a primary exit node, or make sure the upstream router uses ECMP.
• The upstream router has no route back to the tenant subnet. Check show bgp ipv4 unicast on it. Fix the to-upstream map, enable SNAT, or add a static route.
• A silent VM is not seen by the network. Turn on Advertise Subnets in the zone.
• A floating IP moves between VMs. Turn on Disable ARP ND Suppression in the zone.
• You want to reach a guest from an exit node itself. By default, exit nodes only forward. Turn on Exit Nodes Local Routing.
• A firewall sees only one direction of a flow and drops it. Check firewall rules on both nodes.

At this point, you have a Proxmox VE 9.2 EVPN fabric with BGP peers, VNets, and route filters. Prefix lists select the networks, and route maps control which routes you accept and announce. Before using the setup in production, check the BGP sessions, routes, MTU, and traffic in both directions.

Plan your ASNs, MTU, and exit nodes, then test each route map before going live. For this setup, you can use dedicated hosting for virtual networks.