From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 300DA1FF13F for ; Thu, 07 May 2026 13:58:21 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 60F6415BF3; Thu, 7 May 2026 13:58:20 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 07 May 2026 13:57:37 +0200 Message-Id: Subject: Re: [PATCH access-control/cluster/manager/network/proxmox{-ve-rs,-perl-rs} v5 00/46] Add support for route maps / prefix lists to SDN From: "Lukas Sichert" To: "Stefan Hanreich" , References: <20260505153720.412180-1-s.hanreich@proxmox.com> In-Reply-To: <20260505153720.412180-1-s.hanreich@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1778154949552 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.580 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Message-ID-Hash: QXTKPWMPDGCWIPNAA2DP6SJWCSLS2YHY X-Message-ID-Hash: QXTKPWMPDGCWIPNAA2DP6SJWCSLS2YHY X-MailFrom: l.sichert@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2026-05-05 17:36, Stefan Hanreich wrote: > ## Introduction > > This patch adds support for managing route maps and prefix lists to the S= DN > stack. With this patch series, route maps can be applied to the BGP and E= VPN > controller for incoming / outgoing route filtering. Additionally, prefix = lists > can be used to filter routes that should be installed by a fabric into th= e > kernel routing table, overriding the default behavior of only installing = routes > from the configured IP prefix. There are currently some other features in > development that would make use of route maps as well, namely: > > * VRF route leaking > * Route Redistribution for Fabrics On my host there are two SimpleZones configured. In the first SimpleZone there is a VM, which shall be called tm1 from now on. In the VNet there is a cluster consisting of the nodes cl1, cl2 and cl3. All the nodes can reach each other. On the cluster I configured an EVPN with an OpenFabric underlay, configured cl1 as the exit node and enabled 'Advertise Subnets'. In the EVPN Zone I created the 10.0.10.0/24 subnet. Then on cl1 I added a bgp controller with EBGP and 'ebgp-multihop' set to 10 and the ip of tm1 set as peer. On tm1 I also added a bgp controller with the same configuration, but with cl1 as peer and a different ASN. In both cases I ran into a problem where 'delete' was not defined in the schema, but this could be resolved by applying [1]. EBGP multihop was enabled here, because the traffic between the SimpleZones was routed via my host, which did not have a BGP controller configured. I could then verify, that the 10.0.10.0/24 subnet was correctly adveritsed from cl1 to tm1. After configuring prefix lists and route-maps on both cl1 and tm1 I could verify that both incoming and outgoing route-maps work, as the 10.0.10.0/24 was not advertised anymore. Here I ran into a problem though. I configured a prefix list with Prefix: 10.0.10.0/22 Prefix<=3D:21 This is of course wrong, but it is not checked, so applying it is possible. Here maybe a check in the frontend would be useful. After applying I got a warning and even after correcting the prefix list the warning did not go away. After deleting and reconfiguring the list it worked again, but apparently, when adding Prefix<=3D:, it is only possible to alter the value, not delete it. Deleting will just be ignored. Also one other small nit: In the beginning I was very confused by the naming in the prefix list configuration box. 'Permit' and 'Deny' standing for match all and match everything except follows the frr config naming scheme, but for me it seemed like the prefix list directly would block these prefixes. Maybe putting (Match all) after 'Permit' would make it clearer. Also Prefix<=3D is a bit confusing as this really stands for prefix length not prefix value. Maybe CIDR<=3D or Prefix Length<=3D could be used here. Tested-by: Lukas Sichert [1] lore.proxmox.com/pve-devel/20260506102301.220990-1-g.goller@proxmox.com= /T/#u