From: Hugh Blandford <hughblandford@gmail.com>
To: pve-devel@lists.proxmox.com
Subject: Subject: Re: [PATCH access-control/cluster/network/proxmox{-ve-rs,-perl-rs} v2 00/34] Add support for route maps / prefix lists to SDN
Date: Sun, 12 Apr 2026 15:10:06 +1000 [thread overview]
Message-ID: <CAHCiZPTde90O8o4_Yqqu=mMUU3aB45TQdCyp1LH5t+BSe8RXtw@mail.gmail.com> (raw)
Hi Stefan and all,
I am new, so please forgive me if I am bringing up something that has
already been discarded.
I saw your thread referenced above supporting route maps / prefix lists in
SDN.
I believe my changes address a gap not covered by this particular series —
specifically, the ability to establish BGP peers inside a VRF rather than
in the default routing table, which ended up with asymmetric routing issues.
What I have done is not complete at this stage, but I believe it is useful
in solving an issue and wanted to see if there is any interest in
completing this as a patch.
I recently started experimenting with an EVPN setup and encountered an
asymmetric routing problem with pfSense as my gateway router using a
dedicated transit vlan to my SDN workloads. pfSense doesn't support ECMP
so I went with having a primary exit node, but traffic to my
existing management PC would shortcut the pfSense box and go via the
existing interfaces.
I patched three files:
/usr/share/perl5/PVE/Network/SDN/Zones/BgpPlugin.pm
/usr/share/perl5/PVE/Network/SDN/Zones/EvpnPlugin.pm
/usr/share/pve-manager/js/pvemanagerlib.js
1. I added a vrf_zone property to the peer configuration in BgpPlugin.pm
2. Changed EvpnPlugin.pm to use the vrf_zone property to define the BGP
session inside the vrf
3. Added an extra field to the web interface for the BGP controller option
to select a valid vrf from the dropdown box
4. Added additional fields to the web interface for the BGP controller to
specify a prefix list to pull in information from frr.conf.local. (Not
needed anymore thanks to this patch series)
5. I added the vmbrX interface for the transit vlan into my vrf by manually
adding vrf vrf_<vrfname) to the /etc/network/interfaces file and
reloading. I have not explored what would be required to handle this in
the web interface at this stage.
My frr.conf.local:
ip prefix-list EVPN_SUBNETS seq 10 deny 192.168.250.0/23 ge 24 le 24
ip prefix-list EVPN_SUBNETS seq 20 deny 192.168.252.0/22 ge 24 le 24
ip prefix-list EVPN_SUBNETS seq 30 permit 192.168.192.0/18 ge 24 le 24
!
route-map TO_PFSENSE permit 10
match ip address prefix-list EVPN_SUBNETS
exit
!
route-map TO_PFSENSE deny 20
exit
!
Result:
This allows you to have a BGP peering session running inside a VRF, with
prefix lists controlling the route distribution without requiring any route
leaking.
Traffic is routed into and out of the VRF via the specified transit vlan,
no shortcuts via other interfaces.
This has resulted in the following output which is what I intended at the
start:
Normal proxmox node routing table with no vrf entries in it:
root@prox1:/# ip route
default via 192.168.132.1 dev vmbr0 proto kernel onlink
10.10.20.0/24 dev vmbr20 proto kernel scope link src 10.10.20.7
10.10.21.0/24 dev vmbr21 proto kernel scope link src 10.10.21.7
192.168.132.0/24 dev vmbr0 proto kernel scope link src 192.168.132.7
Below is the vrf routing table for the SDN VRF with its respective entries:
192.168.222.0/24 an SDN subnet with VMs in it
192.168.254.0/24 a transit vlan between the SDN exit nodes and a pfSense VM
gateway to the internet, which is publishing a default route to the SDN
exit nodes and learning whatever routes are available in the range
192.168.192.0-192.168.249.255.
root@prox1:/# ip route show vrf vrf_public
default nhid 38 via 192.168.254.1 dev vmbr14 proto bgp metric 20
192.168.222.0/24 dev dmz proto kernel scope link src 192.168.222.1
192.168.254.0/24 dev vmbr14 proto kernel scope link src 192.168.254.7
With the BGP peer configuration automatically built for you on the exit
node in frr:
router bgp 65001 vrf vrf_public
bgp router-id 10.10.21.7
no bgp hard-administrative-reset
no bgp graceful-restart notification
neighbor BGP peer-group
neighbor BGP remote-as external
neighbor BGP bfd
neighbor 192.168.254.1 peer-group BGP
!
address-family ipv4 unicast
redistribute connected
neighbor BGP soft-reconfiguration inbound
neighbor BGP route-map TO_PFSENSE out
exit-address-family
!
address-family ipv6 unicast
redistribute connected
exit-address-family
!
address-family l2vpn evpn
default-originate ipv4
default-originate ipv6
exit-address-family
exit
Regards,
Hugh Blandford
reply other threads:[~2026-04-12 5:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHCiZPTde90O8o4_Yqqu=mMUU3aB45TQdCyp1LH5t+BSe8RXtw@mail.gmail.com' \
--to=hughblandford@gmail.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.