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 86CAD1FF13A for ; Wed, 13 May 2026 18:21:04 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 63EB817677; Wed, 13 May 2026 18:21:04 +0200 (CEST) From: Stefan Hanreich To: pve-devel@lists.proxmox.com Subject: [PATCH pve-docs 2/2] sdn: route map: delete note about creating an empty deny entry Date: Wed, 13 May 2026 18:20:11 +0200 Message-ID: <20260513162013.456890-3-s.hanreich@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260513162013.456890-1-s.hanreich@proxmox.com> References: <20260513162013.456890-1-s.hanreich@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1778689215554 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.603 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. [frrouting.org] Message-ID-Hash: ZQWQECCM2BGZ7HEBQXHIXU3FH4NEBUCR X-Message-ID-Hash: ZQWQECCM2BGZ7HEBQXHIXU3FH4NEBUCR X-MailFrom: s.hanreich@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: When another route map is called from an entry, then the route is denied if it the called route map returns deny, even if the calling entry has permit as its matching policy. See FRR docs [1]: If the route-map called returns deny then processing of the route-map finishes and the route is denied, regardless of the Matching Policy or the Exit Policy. If the called route-map returns permit, then Matching Policy and Exit Policy govern further behaviour, as normal. This means that, even though MAP_VTEP_IN has permit as its matching policy, any route will be denied if the called route map denies it. [1] https://docs.frrouting.org/en/latest/routemap.html#term-Call-Action Signed-off-by: Stefan Hanreich --- pvesdn.adoc | 6 ------ 1 file changed, 6 deletions(-) diff --git a/pvesdn.adoc b/pvesdn.adoc index 9a3b6b8..3256e96 100644 --- a/pvesdn.adoc +++ b/pvesdn.adoc @@ -894,12 +894,6 @@ received from a peer before installing them; outgoing maps run against routes before announcing them. Both fields are optional and selected from the route maps configured in the SDN. -NOTE: For the EVPN controller, the user-provided route maps are invoked via -`call` from internal wrapper maps (`MAP_VTEP_IN` / `MAP_VTEP_OUT`) whose -trailing action is `permit`. As a result, a deny-only user route map will not -block routes that do not match any of its entries; finish such a map with an -explicit catch-all `deny` entry if you want a closed default. - The OSPF and OpenFabric xref:pvesdn_config_fabrics[fabrics] take a `Route Filter` option that references a prefix list. When set, only routes whose destinations pass the prefix list are installed in the kernel routing table. -- 2.47.3