惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

P
Proofpoint News Feed
AWS News Blog
AWS News Blog
L
Lohrmann on Cybersecurity
C
Cisco Blogs
W
WeLiveSecurity
NISL@THU
NISL@THU
C
CERT Recently Published Vulnerability Notes
大猫的无限游戏
大猫的无限游戏
The Hacker News
The Hacker News
J
Java Code Geeks
A
Arctic Wolf
WordPress大学
WordPress大学
B
Blog
I
Intezer
T
Threatpost
The Cloudflare Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
C
CXSECURITY Database RSS Feed - CXSecurity.com
V
V2EX - 技术
爱范儿
爱范儿
博客园 - 司徒正美
C
Cybersecurity and Infrastructure Security Agency CISA
E
Exploit-DB.com RSS Feed
美团技术团队
H
Heimdal Security Blog
Security Latest
Security Latest
博客园_首页
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Google DeepMind News
Google DeepMind News
N
News | PayPal Newsroom
F
Full Disclosure
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Blog — PlanetScale
Blog — PlanetScale
The Last Watchdog
The Last Watchdog
L
LangChain Blog
The GitHub Blog
The GitHub Blog
T
Threat Research - Cisco Blogs
U
Unit 42
GbyAI
GbyAI
人人都是产品经理
人人都是产品经理
The Register - Security
The Register - Security
P
Privacy & Cybersecurity Law Blog
P
Privacy International News Feed
Stack Overflow Blog
Stack Overflow Blog
P
Proofpoint News Feed
酷 壳 – CoolShell
酷 壳 – CoolShell
Scott Helme
Scott Helme
Recent Announcements
Recent Announcements
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
博客园 - 叶小钗

Proxmox Support Forum

[SOLVED] - Github Auth for Mirrors-Kernel Repo? [Automation] Mass migration tool for MS Win11/Server Proxmox GUI hang - not response is it possible to reject or quarantine spam based on conditions I set ? The PVENode task list in PVE9 is partially obscured due to the terminal font being too large. About 100% error reporting due to pveproxy.service hooks Kubernetes overlay networking breaks when upgrading from PVE 9.1 to PVE 9.2.3 Zentraler Speicher No space left on device Combine datastore and direct file archival to tape Kernel panic VFS: Unable to mount root fs on unknown-block (0,0) sobald ein 7.x Kernel verwendet wird. How to migrate disk of a VM from one ZFS to another Windows Server 2025 fails to boot after PVE 9.2 / Linux 7.0 Kernel upgrade Cannot Install Proxmox on T610 Poweredge with H700 PERC card sdn Config. gateway not reachable How to safely change domain/FQDN? Welche Filterquote erreicht ihr? NFS Share status unknown on 2 of 5 nodes Can't connect to PVE9 consoles [solved] Can't connect to PVE9 consoles [solved] [SOLVED] - Use secondary network for PVE commands Created cluster, one node storage gone BUG: proxmox mail gateway FROM = null bypass spam filtering Moving existing PBS from VMWare workstation to PVE cluster Does eBGP SDN fabric support external peering? Bug: PDM 1.1 not recognizing valid license status Proxmox GUI hang - not response PVE crashes unexpectedly Proxmox Backup Server 4.2 released! Advice ceph-osd crashes with kernel 6.17.2-1-pve on Dell system [META] Links on Proxmox Forum Website Hardwarer oder Software RAID Joining a cluster with already created guests VM PDM missing backup jobs from PVE / Log retention Remove VM.Monitor from all users/roles, PVE 9.2 Proxmox Freezing (new instalation) 9.2.2 - Intel 12700T No Web gui and random connection reset by peer [SOLVED] - i40e module for X710 Intel NIC Dutch Proxmox Day 2026 How pools use the space Corosync initiiert Reboot trotz Verfügbarkeit der Systeme Opt-in Linux 7.0 Kernel for Proxmox VE 9 available After PVE 8to9 upgrade, unable to check guest fs freeze status Problem with MegaRAID SAS3508 controller proxmox-kernel-7.0.2-6-pve failing network service Auto sync guest time after rollback of VM snapshot with RAM/state Broadcom BCM57504 (100G) bnxt_en TX timeout and NIC reset on Proxmox 8.1.5 — while BCM57414 (25G) works fine on same host QEMU 11.0 available on pve-test and pve-no-subscription as of now 350 MPM Solventless Lamination Machine for High-Speed Flexible Packaging Making sense of NVMe zfs and SMART errors [SOLVED] - PVE loses network connection after kernel upgrade to proxmox-kernel-7.0.0-3-pve [SOLVED] - Remove or reset cluster configuration. Proxmox 8.4.1 Fresh Install BCM57416 10G Ethernet Adapter Not Recognized PDM 1.1.1 unable to add AD realm with anonymous search [TUTORIAL] - Developer Workstation (Proxmox-VE 9) with cinnamon (LMDE7) SDN zone shows "pending" on peer nodes after node reboot (9.2.x) Cluster not quorate - extending auth key lifetime! Proxmox not rebooting properly (SOLVED) Proxmox 9 Stuck on loading initial ramdisk With new HA-Disarm Feature is there a Documentation for NUT Setup on Clusters? Proxmox 8.3 Installation Issue on ProLiant DL380 Gen9 Cluster networking setup LXC System images unavailable [SOLVED] - Fix: NVIDIA Drivers Failing after upgrade to Proxmox 9.2.2 (Kernel 7.0.2-6-pve) / NovaCore Conflict Install NUT directly on Proxmox VE and control guests from here driver usb for windows 7 System startup error and no network: Failed to start ifupdown2-pre.service - Helper to synchronize boot up for ifupdown. PBS backup space grow up constantly Proxmox Datacenter Manager 1.1 released! IPv4 not available in newly created VM Recommended Setup for Offsite Proxmox Backups? Hetzner Storage Box & Remote PBS Challenges duplicate, please delete this passthrought an USB device "by ID" to CT PDM Installer Freezes at 66% Tried PDM for the first time (version 1.1) - had issues PDM 1.1 automated install Suche Server-Provider für Proxmox connecting sdn to edge firewall SDN, IPAM & DHCP Migrating from read-only file system Ubuntu 26.04 installation fails for unknown reason Status Unbekannt nach Cluster Join Installing Proxmox Backup Server on Mac Mini (Late 2012) kernel 7.0 performance issue with zfs pools PVE becomes unreachable via ethernet but OS is running [SOLVED] - New 9.2 install - can't find 7.0.2-6-pve , not all the time [SOLVED] - Backup and dedupe a VM with LUKS Gibt es mit PVE 2.x ggf. Änderungen bei der RAM-Nutzung, bzw. deren Anzeige bei VMs? I need help for setting up backup solution Way more NAGware, very little functionality, bugs galore Root squashing virtiofsd with --uid-map Intel ixgbe Driver Update Fail Passkey Login (not 2FA) Roblox VM detection - can be overcome? [TUTORIAL] - ZFS-Autosnaptshot inkl. Rollback und Daten direkt recovern (Windows/Linux) How to stop PVE Kernel upgrade [SOLVED] - very long waiting to log in to lxc debian 11 ssh [TUTORIAL] - Configuring Fusion-Io (SanDisk) ioDrive, ioDrive2, ioScale and ioScale2 cards with Proxmox Increase maximum USB devices in vm.conf
SDN, EVPN and Multiple BGP Controllers Issue
invalid@exam · 2026-06-16 · via Proxmox Support Forum

I have a three node Promxox 9 cluster. Each node has a 1GbE NIC and a dual-25GbE NIC (Connect-X 4 Lx). I've been trying unsuccessfully for several days to use Proxmox's SDN capabilities to create a mesh network between the three nodes (by directly connecting the nodes with SFP28 cables) and get all of the following working:

  1. Ceph storage running on the mesh network at 25GbE
  2. Inter-VM communication running on the mesh network at 25GbE
  3. VMs can reach the LAN + WAN
  4. (e)BGP to my OPNsense router so that external clients can reach the VMs
  5. (e)BGP with multiple BGP controllers / Exit Nodes (for HA)
  6. VMs can talk to Ceph controller (e.g. for Kubernetes) at 25GbE

Creating a mesh network with an OpenFabric SDN Fabric is really easy, and I can get Ceph communicating on the Fabric without issue. I've read several guides (like this one) to run EVPN and VXLAN on the Fabric and I'm able to get VMs/containers running on different hosts to talk to each other at 25GbE. I can also add a single BGP controller pointing to my OPNsense router and announce my routes, so long as the BGP controller and the Exit Node for the EVPN zone are on the SAME node.

However, once I try to add multiple Exit Nodes and/or multiple BGP controllers, everything falls apart.

In the majority of my testing, I've been using a container 10.255.69.31 and VM 10.255.69.41 on prox01, and a container 10.255.69.34 and VM 10.255.69.44 on prox04 (all IPs within the VXLAN subnet).

The TL;DR is that no matter what I try, I will lose partial or all connectivity between my LAN and my VMs. The most consistent issue I run into is that e.g. I have VMs, 2x Exit Nodes and 2x BGP controllers running on prox01 and prox04 and on my OPNsense I'll receive routes that look something like:

ValidBestInternalNetworkNext HopMetricLocPrfWeightPathOrigin
yyn10.255.69.0/2410.4.10.310065430?
ynn10.255.69.0/2410.4.10.340065430?
yyn10.255.69.31/3210.4.10.340065430IGP
yyn10.255.69.41/3210.4.10.340065430IGP
yyn10.255.69.34/3210.4.10.310065430IGP
yyn10.255.69.44/3210.4.10.310065430IGP

The /32 routes are all for the wrong nodes, and I can't ping any of these IPs from my desktop. Depending on the config, I'll be able to get a single ping off and then they'll stop responding. If I stop the ping and wait ~5 mins, I'll be able to do a single ping again.

I've tried literally hundreds of configurations (including changes to SDN (BGP, EVPN Zone etc.), host networking, Linux tunables etc.) to get this to work, including:

  • EVPN controller + BGP controllers + OPNsense all same ASN
  • EVPN controller + BGP controllers same ASN and OPNsense different
  • EVPN controller + BGP controllers + OPNsense all different ASNs
  • BGP controllers + OPNsense same ASN and EVPN controller different
  • All BGP controllers unique ASNs, EVPN controller and OPNsense unique

There are several other posts (a handful are listed below) from the past couple of years where other people have reported seeing similar issues:

I'd really like to get multiple Exit Nodes + BGP controllers working for HA reasons, as well as for hopefully better networking performance. Has anyone been able to get a similar setup to work reliably?


For reference, here's my current (stable) setup that hits goals 1 through 4 (but not 5 and 6), using a single BGP controller + exit node:

  • OPNsense: 10.4.10.1
  • prox01: 10.4.10.31
  • prox03: 10.4.10.33
  • prox04: 10.4.10.34

Code:

# On prox01
> cat /etc/network/interfaces

auto lo
iface lo inet loopback

iface enx5847ca7b312c inet manual

iface enp1s0f0np0 inet manual
        mtu 9000

iface enp1s0f1np1 inet manual
        mtu 9000

auto vmbr0
iface vmbr0 inet static
        bridge-ports enx5847ca7b312c
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

auto vmbr0.10
iface vmbr0.10 inet static
        address 10.4.10.31/24
        gateway 10.4.10.1

Code:

# On prox01
> cat /etc/network/interfaces.d/sdn

auto vrf_evpnzone
iface vrf_evpnzone
        vrf-table auto
        post-up ip route del vrf vrf_evpnzone unreachable default metric 4278198272

auto vrfbr_evpnzone
iface vrfbr_evpnzone
        bridge-ports vrfvx_evpnzone
        bridge_stp off
        bridge_fd 0
        mtu 8950
        vrf vrf_evpnzone

auto vrfvx_evpnzone
iface vrfvx_evpnzone
        vxlan-id 10000
        vxlan-local-tunnelip 10.255.0.31
        bridge-learning off
        bridge-arp-nd-suppress on
        mtu 8950

auto vxlan_vxnet1
iface vxlan_vxnet1
        vxlan-id 10500
        vxlan-local-tunnelip 10.255.0.31
        bridge-learning off
        bridge-arp-nd-suppress on
        mtu 8950

auto vxnet1
iface vxnet1
        address 10.255.69.1/24
        post-up iptables -t nat -A POSTROUTING -s '10.255.69.0/24' -o vmbr0.10 -j SNAT --to-source 10.4.10.31
        post-down iptables -t nat -D POSTROUTING -s '10.255.69.0/24' -o vmbr0.10 -j SNAT --to-source 10.4.10.31
        post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
        hwaddress BC:24:11:D8:8F:70
        bridge_ports vxlan_vxnet1
        bridge_stp off
        bridge_fd 0
        mtu 8950
        ip-forward on
        arp-accept on
        vrf vrf_evpnzone

auto dummy_prox-of
iface dummy_prox-of inet static
        address 10.255.0.31/32
        link-type dummy
        ip-forward 1

auto dummy_prox-of
iface dummy_prox-of inet6 static
        address fc69:cefe:255::31/128
        link-type dummy
        ip-forward 1

auto enp1s0f0np0
iface enp1s0f0np0
        ip-forward 1

auto enp1s0f1np1
iface enp1s0f1np1
        ip-forward 1

Code:

> cat /etc/pve/sdn/*

evpn: proxevpn
        asn 65430
        fabric prox-of

bgp: bgpprox01
        asn 65430
        node prox01
        peers 10.4.10.1
        bgp-multipath-as-path-relax 1
        ebgp 1
        loopback dummy_prox-of

openfabric_fabric: prox-of
        csnp_interval 2
        hello_interval 1
        ip6_prefix fc69:cefe:255::/64
        ip_prefix 10.255.0.0/24

openfabric_node: prox-of_prox01
        interfaces name=enp1s0f0np0
        interfaces name=enp1s0f1np1
        ip 10.255.0.31
        ip6 fc69:cefe:255::31

openfabric_node: prox-of_prox03
        interfaces name=enp1s0f0np0
        interfaces name=enp1s0f1np1
        ip 10.255.0.33
        ip6 fc69:cefe:255::33

openfabric_node: prox-of_prox04
        interfaces name=enp65s0f0np0
        interfaces name=enp65s0f1np1
        ip 10.255.0.34
        ip6 fc69:cefe:255::34
{"zones":{"evpnzone":{"subnets":{"10.255.69.0/24":{"ips":{"10.255.69.1":{"gateway":1}}}}},"evpnPRD":{"subnets":{}},"epvnzone":{"subnets":{}}}}subnet: evpnzone-10.255.69.0-24
        vnet vxnet1
        gateway 10.255.69.1
        snat 1

vnet: vxnet1
        zone evpnzone
        tag 10500

evpn: evpnzone
        controller proxevpn
        vrf-vxlan 10000
        exitnodes prox01
        ipam pve
        mac BC:24:11:D8:8F:70
        mtu 8950

Code:

# On all nodes
> cat /etc/sysctl.d/zzz-network.conf

net.ipv4.ip_forward=1
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

Code:

# On prox01
> cat /etc/frr/frr.conf

frr version 10.3.1
frr defaults datacenter
hostname prox01
log syslog informational
service integrated-vtysh-config
!
!
vrf vrf_evpnzone
 vni 10000
exit-vrf
!
router bgp 65430
 bgp router-id 10.4.10.31
 no bgp default ipv4-unicast
 coalesce-time 1000
 bgp disable-ebgp-connected-route-check
 bgp bestpath as-path multipath-relax
 neighbor BGP peer-group
 neighbor BGP remote-as external
 neighbor BGP bfd
 neighbor 10.4.10.1 peer-group BGP
 neighbor VTEP peer-group
 neighbor VTEP remote-as 65430
 neighbor VTEP bfd
 neighbor VTEP update-source dummy_prox-of
 neighbor 10.255.0.33 peer-group VTEP
 neighbor 10.255.0.34 peer-group VTEP
 !
 address-family ipv4 unicast
  network 10.4.10.31/32
  neighbor BGP activate
  neighbor BGP soft-reconfiguration inbound
  import vrf vrf_evpnzone
 exit-address-family
 !
 address-family ipv6 unicast
  import vrf vrf_evpnzone
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor VTEP activate
  neighbor VTEP route-map MAP_VTEP_IN in
  neighbor VTEP route-map MAP_VTEP_OUT out
  advertise-all-vni
 exit-address-family
exit
!
router bgp 65430 vrf vrf_evpnzone
 bgp router-id 10.255.0.31
 no bgp hard-administrative-reset
 no bgp graceful-restart notification
 !
 address-family ipv4 unicast
  redistribute connected
 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
!
ip prefix-list loopbacks_ips seq 10 permit 0.0.0.0/0 le 32
ip prefix-list only_default seq 1 permit 0.0.0.0/0
!
ipv6 prefix-list only_default_v6 seq 1 permit ::/0
!
route-map MAP_VTEP_IN deny 1
 match ip address prefix-list only_default
exit
!
route-map MAP_VTEP_IN deny 2
 match ipv6 address prefix-list only_default_v6
exit
!
route-map MAP_VTEP_IN permit 3
exit
!
route-map MAP_VTEP_OUT permit 1
exit
!
route-map correct_src permit 1
 match ip address prefix-list loopbacks_ips
 set src 10.4.10.31
exit
!
ip protocol bgp route-map correct_src
router openfabric prox-of
 net 49.0001.0102.5500.0031.00
exit
!
interface dummy_prox-of
 ipv6 router openfabric prox-of
 ip router openfabric prox-of
 openfabric passive
exit
!
interface enp1s0f0np0
 ipv6 router openfabric prox-of
 ip router openfabric prox-of
 openfabric hello-interval 1
 openfabric csnp-interval 2
exit
!
interface enp1s0f1np1
 ipv6 router openfabric prox-of
 ip router openfabric prox-of
 openfabric hello-interval 1
 openfabric csnp-interval 2
exit
!
access-list pve_openfabric_prox-of_ips permit 10.255.0.0/24
!
ipv6 access-list pve_openfabric_prox-of_ip6s permit fc69:cefe:255::/64
!
route-map pve_openfabric permit 100
 match ip address pve_openfabric_prox-of_ips
 set src 10.255.0.31
exit
!
route-map pve_openfabric6 permit 110
 match ipv6 address pve_openfabric_prox-of_ip6s
 set src fc69:cefe:255::31
exit
!
ip protocol openfabric route-map pve_openfabric
!
ipv6 protocol openfabric route-map pve_openfabric6
!
!
line vty

I believe I've found the fix! It turns out that net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter don't work like you'd probably expect. It looks like this settings file is being read too late during startup - after most/all of the network interfaces have been created - so setting a "default" value doesn't really do anything.

Modifying my /etc/sysctl.d/zzz-network.conf to:

Code:

net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.*.rp_filter=0

fixes the issue - I can have multiple Exit Nodes and BGP controllers at the same time and everything works as expected!

There's still the issue where the BGP routes have the "Next Hop" as the node that the VM is NOT running on, but right now I don't care and I might just use a Prefix List in OPNsense to filter out the /32 routes, keeping only the /24 routes.


For anyone in the future: I've kept my SDN setup the same as the above post, just with all nodes as EVPN Zone Exit Nodes and (currently) two nodes with BGP Controllers. I have my OPNsense router using AS 65401, and my EVPN controller and all of the BGP controllers are using AS 65430.

Here's the output of cat /etc/pve/sdn/* for reference:

Code:

evpn: proxevpn
        asn 65430
        fabric prox-of

bgp: bgpprox01
        asn 65430
        node prox01
        peers 10.4.10.1
        bgp-multipath-as-path-relax 1
        ebgp 1
        loopback dummy_prox-of

bgp: bgpprox04
        asn 65430
        node prox04
        peers 10.4.10.1
        bgp-multipath-as-path-relax 1
        ebgp 1
        loopback dummy_prox-of

openfabric_fabric: prox-of
        csnp_interval 2
        hello_interval 1
        ip6_prefix fc69:cefe:255::/64
        ip_prefix 10.255.0.0/24

openfabric_node: prox-of_prox01
        interfaces name=enp1s0f0np0
        interfaces name=enp1s0f1np1
        ip 10.255.0.31
        ip6 fc69:cefe:255::31

openfabric_node: prox-of_prox03
        interfaces name=enp1s0f0np0
        interfaces name=enp1s0f1np1
        ip 10.255.0.33
        ip6 fc69:cefe:255::33

openfabric_node: prox-of_prox04
        interfaces name=enp65s0f0np0
        interfaces name=enp65s0f1np1
        ip 10.255.0.34
        ip6 fc69:cefe:255::34
{"zones":{"evpnzone":{"subnets":{"10.255.69.0/24":{"ips":{"10.255.69.1":{"gateway":1}}}}},"evpnPRD":{"subnets":{}},"epvnzone":{"subnets":{}}}}subnet: evpnzone-10.255.69.0-24
        vnet vxnet1
        gateway 10.255.69.1
        snat 1

vnet: vxnet1
        zone evpnzone
        tag 10500

evpn: evpnzone
        controller proxevpn
        vrf-vxlan 10000
        exitnodes prox03,prox04,prox01
        ipam pve
        mac BC:24:11:D8:8F:70
        mtu 8950

Finally, I have no idea if this is needed, but in OPNsense I have the tunable net.route.multipath set to 1.

Last edited:

There's still the issue where the BGP routes have the "Next Hop" as the node that the VM is NOT running on, but right now I don't care and I might just use a Prefix List in OPNsense to filter out the /32 routes, keeping only the /24 routes.

This is currently a known issue that we're looking into. The problem here is that all nodes, except the one the guest actually resides on, get an entry for the /32 of the guest in the VRF. With an exit node and BGP controller configured, the contents of the VRF then get leaked into the default routing table and announced via BGP. This is why you are seeing the wrong next-hops.

Since you're using Openfabric as the underlying routing protocol (if i'm interpreting your configuration correctly), what could work is using iBGP over that fabric to your router, since that should not overwrite the nexthop as opposed to eBGP.

With an exit node and BGP controller configured, the contents of the VRF then get leaked into the default routing table and announced via BGP.

This is what I had suspected. Glad to confirm that it's expected (if undesirable) behaviour.

Since you're using Openfabric as the underlying routing protocol (if i'm interpreting your configuration correctly), what could work is using iBGP over that fabric to your router, since that should not overwrite the nexthop as opposed to eBGP.

Are you suggesting setting OpenFabric, BGP and OPNsense to the same AS (and disabling eBGP on the Promxox BGP controllers)? If so, I've tried that (and double-checked now that I fixed the rp_filter issue) and unfortunately I'm seeing the exact same behaviour as eBGP with OpenFabric + BGP on AS 65430 and OPNsense on AS 65401.

unfortunately I'm seeing the exact same behaviour as eBGP with OpenFabric + BGP on AS 65430 and OPNsense on AS 65401.


I would suggest setting the BGP controllers, the EVPN controller AND OPNSense BGP to use the same ASN and then try again. I haven't had the time to test this locally - but I think it should work. There's another bug with the BGP controller that causes EVPN controllers to inherit the ASN of the BGP controller if there is one defined.

So basically:
do full-mesh between PVE nodes with EVPN controllers, with e.g. ASN 65000
do BGP with OPNSense with ASN 65000 on both ends as well (set BGP controller to ebgp 0)

We're currently working on untangling this - but it's a bit tricky without breaking backwards compatibility with basically every existing setup that uses BGP + EVPN controllers.

I realize my mistake now, of course that cannot work since the nodes are still sending themselves as next-hop, even if set up that way because you're peering via two different networks. You could use an EVPN-capable router instead that peers with the PVE nodes directly via the l2vpn evpn address family, e.g. VyOS, and then handle everything manually there - or live with the additional hop for now. We're currently working on improving the BGP situation right now, particularly for this scenario - I cannot give any guarantees or estimates on when this will land though.

Last edited: