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 C25AF1FF13B for ; Wed, 25 Feb 2026 16:51:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C9483AF27; Wed, 25 Feb 2026 16:52:30 +0100 (CET) Date: Wed, 25 Feb 2026 16:52:24 +0100 From: Gabriel Goller To: Stefan Hanreich Subject: Re: [PATCH pve-network 10/10] test: add test for frr.conf.local merging Message-ID: Mail-Followup-To: Stefan Hanreich , pve-devel@lists.proxmox.com References: <20260203160246.353351-1-g.goller@proxmox.com> <20260203160246.353351-22-g.goller@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20241002-35-39f9a6 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1772034727378 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.466 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_ASCII_DIVIDERS 0.8 Email that uses ascii formatting dividers and possible spam tricks KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 1.113 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.358 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.659 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 4KCHLMBBHQTI2IKS4AR4U7S34NXHTMEL X-Message-ID-Hash: 4KCHLMBBHQTI2IKS4AR4U7S34NXHTMEL X-MailFrom: g.goller@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 CC: pve-devel@lists.proxmox.com 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 24.02.2026 14:27, Stefan Hanreich wrote: > I've scoured the forum for posts of users utilizing frr.conf.local to > override the generated FRR configuration. The following additional > features / snippets would be interesting to include as well imo: > > > interface sections for fabrics, e.g.: > > interface vmbr0 > no ip ospf passive > exit > ! > interface iface2 > ip ospf area 192.0.2.0/24 > exit > ! > > > OSPF router additons: > > router ospf > passive-interface default > exit > > > Zebra nexthop options: > > ip nht resolve-via-default > > > Override route-map completely: > > router bgp 65000 > address-family l2vpn evpn > no neighbor VTEP route-map MAP_VTEP_IN in > neighbor VTEP route-map MAP_VTEP_IN_CUSTOM in > exit-address-family > exit > > > Custom routes: > > ip route 192.0.2.0/24 198.51.100.1 > > > IP protocol route-map setting: > > ip protocol bgp route-map correct_src > > > Set additional options for existing peer-groups: > > neighbor BGP prefix-list MY_PREFIX_LIST out > neighbor BGP allowas-in 1 > > > remove existing peer-group: > > no neighbor VTEP peer-group > > > Override ASN: > > neighbor BGP remote-as 64600 > > > > The OSPF / interface additions might even be worth a second test case? > > Not sure if all the others can be condensed into one test case, or would > require specific ones as well... > > For some of those, ordering is quite important - so it would make sense > to double-check proper ordering after mergin as well for stuff that > overrides with no explicit 'no' statement. Added all these options and also a ISIS-controller to the frr_conf_local_test. When running the test with the current state (no templates) of pve-network, we get the following failure, which is imo fine: # +----+--------------------------------------------------------+----+--------------------------------------------------------+ # | Ln|Got | Ln|Expected | # +----+--------------------------------------------------------+----+--------------------------------------------------------+ # | 4|log syslog informational | 4|log syslog informational | # | 5|service integrated-vtysh-config | 5|service integrated-vtysh-config | # | 6|! | 6|! | # * 7|! * | | # | 8|vrf vrf_myzone | 7|vrf vrf_myzone | # | 9| vni 1000 | 8| vni 1000 | # | 10|exit-vrf | 9|exit-vrf | # | 11|! | 10|! | Here the previous merging algorithm moves all the interfaces to the top. This is not really feasable (or would be difficult) with the template-approach that we chose. AFAICS this does not change the behavior of a config (or a override config). # * 12|interface ens19 * | | # * 13| no ip ospf passive * | | # * 14|! * | | # * 15|interface eth0 * | | # * 16| ip router isis isis1 * | | # * 17|! * | | # * 18|interface eth1 * | | # * 19| ip router isis isis1 * | | # * 20|! * | | # * 21|interface iface2 * | | # * 22| ip ospf area 0 * | | # * 23|! * | | # | 24|router bgp 65000 | 11|router bgp 65000 | # | 25| bgp router-id 192.168.0.1 | 12| bgp router-id 192.168.0.1 | # | 26| no bgp hard-administrative-reset | 13| no bgp hard-administrative-reset | # +----+--------------------------------------------------------+----+--------------------------------------------------------+ Here the address-family ipv4 unicast and the neighbor VTEP prefix-list (allowas- in + remote-as) is added in the frr.conf.local. We can't sort this nicely as in the old merging algorithm, but it shouldn't change anything in the behavior. # | 35| neighbor 192.168.0.3 peer-group VTEP | 22| neighbor 192.168.0.3 peer-group VTEP | # | 36| neighbor 192.168.1.1 remote-as 65001 | 23| neighbor 192.168.1.1 remote-as 65001 | # | 37| neighbor 192.168.1.1 description "External Peer" | 24| neighbor 192.168.1.1 description "External Peer" | # | | * 25| address-family ipv4 unicast * # | | * 26| neighbor VTEP activate * # | | * 27| exit-address-family * # | 38| neighbor VTEP prefix-list MY_PREFIX_LIST out | 28| neighbor VTEP prefix-list MY_PREFIX_LIST out | # | 39| neighbor VTEP allowas-in 1 | 29| neighbor VTEP allowas-in 1 | # | 40| neighbor VTEP remote-as 64600 | 30| neighbor VTEP remote-as 64600 | # | 41| no neighbor VTEP peer-group | 31| no neighbor VTEP peer-group | # | 42| ! | 32| ! | # * 43| address-family ipv4 unicast * | | # * 44| neighbor VTEP activate * | | # * 45| exit-address-family * | | # * 46| ! * | | # | 47| address-family l2vpn evpn | 33| address-family l2vpn evpn | # | 48| neighbor VTEP activate | 34| neighbor VTEP activate | # | 49| neighbor VTEP route-map MAP_VTEP_IN in | 35| neighbor VTEP route-map MAP_VTEP_IN in | # +----+--------------------------------------------------------+----+--------------------------------------------------------+ Below is some other small stuff that is moved up and down, this shouldn't matter too much. # | 68| log-adjacency-changes | 54| log-adjacency-changes | # | 69|exit | 55|exit | # | 70|! | 56|! | # * 71|router ospf * 57|interface eth0 * # * 72| passive-interface default * 58| ip router isis isis1 * # | 73|exit | 59|exit | # | 74|! | 60|! | # * 75|ip prefix-list PL_ALLOW seq 10 permit 10.0.0.0/8 le 24 * 61|interface eth1 * # | | * 62| ip router isis isis1 * # | | * 63|exit * # | | * 64|route-map MAP_VTEP_IN permit 2 * # | | * 65| set community 65000:200 * # | | * 66|exit * # | 76|! | 67|! | # * 77|bgp community-list standard CL_LOCAL permit 65000:200 * 68|ip prefix-list PL_ALLOW seq 10 permit 10.0.0.0/8 le 24 * # * 78|! * 69|route-map CUSTOM_MAP permit 10 * # * 79|route-map CUSTOM_MAP permit 1 * | | # | 80| match ip address prefix-list PL_ALLOW | 70| match ip address prefix-list PL_ALLOW | # | 81|exit | 71|exit | # | 82|! | 72|! | # * 83|route-map MAP_VTEP_IN permit 1 * 73|bgp community-list standard CL_LOCAL permit 65000:200 * # | | * 74|interface iface2 * # | | * 75| ip ospf area 0 * # | 84|exit | 76|exit | # | 85|! | 77|! | # * 86|route-map MAP_VTEP_IN permit 2 * 78|interface ens19 * # * 87| set community 65000:200 * 79| no ip ospf passive * # | 88|exit | 80|exit | # | 89|! | 81|! | # * 90|route-map MAP_VTEP_OUT permit 1 * 82|router ospf * # | | * 83| passive-interface default * # | 91|exit | 84|exit | # | 92|! | 85|! | # * 93|route-map MAP_VTEP_OUT permit 2 * 86|! * # * 94| set community 65000:100 * | | # * 95|exit * | | # | 96|router ospf | 87|router ospf | # | 97| ospf router-id 172.20.30.1 | 88| ospf router-id 172.20.30.1 | # | 98|exit | 89|exit | # +----+--------------------------------------------------------+----+--------------------------------------------------------+ # | 108|! | 99|! | # | 109|access-list pve_ospf_test_ips permit 172.20.30.0/24 | 100|access-list pve_ospf_test_ips permit 172.20.30.0/24 | # | 110|! | 101|! | # | | * 102|route-map MAP_VTEP_IN permit 1 * # | | * 103|exit * # | | * 104|! * # | | * 105|route-map MAP_VTEP_OUT permit 1 * # | | * 106| set community 65000:100 * # | | * 107|exit * # | | * 108|! * # | 111|route-map pve_ospf permit 100 | 109|route-map pve_ospf permit 100 | # | 112| match ip address pve_ospf_test_ips | 110| match ip address pve_ospf_test_ips | # | 113| set src 172.20.30.1 | 111| set src 172.20.30.1 | # | 114|exit | 112|exit | # | 115|! | 113|! | # | 116|ip protocol ospf route-map pve_ospf | 114|ip protocol ospf route-map pve_ospf | # * 117|! * | | # | 118|! | 115|! | # | 119|line vty | 116|line vty | # | 120|! | 117|! | # +----+--------------------------------------------------------+----+--------------------------------------------------------+ Let me know if this is fine or if there are some problems in the above diff that would change the behavior! Another snag that we ran into is that with the old merging algorihm, commands which are not in a "block" (e.g. "ip nht", "ip route" etc.) will not get copied to the frr.conf. So having a "ip route xx" in the frr.conf.local will not do anything. We decided to mirror this behavior, so with the new templating version, we still won't copy any top-level commands (except the "bgp community-list", which is a special case) to the final frr.conf. Thanks for the review!