From: Gabriel Goller <g.goller@proxmox.com>
To: Stefan Hanreich <s.hanreich@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-network 10/10] test: add test for frr.conf.local merging
Date: Wed, 25 Feb 2026 16:52:24 +0100 [thread overview]
Message-ID: <ddr5jbfnamip3mazhnwlx4ugycfmoufptswhzbywe4s24q33le@yzbyva2oejkv> (raw)
In-Reply-To: <fb6bf0bb-371f-4c8a-b776-24d67184b15f@proxmox.com>
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!
next prev parent reply other threads:[~2026-02-25 15:51 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 16:01 [PATCH docs/manager/network/proxmox{-ve-rs,-perl-rs} 00/23] Generate frr config using jinja templates and rust types Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 1/9] ve-config: firewall: cargo fmt Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 2/9] frr: add proxmox-frr-templates package that contains templates Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 3/9] ve-config: remove FrrConfigBuilder struct Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 4/9] sdn-types: support variable-length NET identifier Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 5/9] frr: add template serializer and serialize fabrics using templates Gabriel Goller
2026-02-25 13:43 ` Stefan Hanreich
2026-02-25 16:29 ` Gabriel Goller
2026-02-25 17:03 ` Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 6/9] frr: add isis configuration and templates Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 7/9] frr: support custom frr configuration lines Gabriel Goller
2026-02-19 12:17 ` Hannes Laimer
2026-02-19 15:01 ` Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 8/9] frr: add bgp support with templates and serialization Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-ve-rs 9/9] frr: store frr template content as a const map Gabriel Goller
2026-02-25 9:23 ` Stefan Hanreich
2026-02-25 10:08 ` Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-perl-rs 1/2] sdn: add function to generate the frr config for all daemons Gabriel Goller
2026-02-03 16:01 ` [PATCH proxmox-perl-rs 2/2] sdn: add method to get a frr template Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 01/10] sdn: remove duplicate comment line '!' in frr config Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 02/10] sdn: tests: add missing comment " Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 03/10] tests: use Test::Differences to make test assertions Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 04/10] sdn: write structured frr config that can be rendered using templates Gabriel Goller
2026-02-19 13:52 ` Hannes Laimer
2026-02-19 15:36 ` Gabriel Goller
2026-02-19 15:44 ` Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 05/10] tests: rearrange some statements in the frr config Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 06/10] sdn: adjust frr.conf.local merging to rust template types Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 07/10] cli: add pvesdn cli tool for managing frr template overrides Gabriel Goller
2026-02-19 12:39 ` Hannes Laimer
2026-02-19 15:49 ` Gabriel Goller
2026-02-24 14:05 ` Stefan Hanreich
2026-02-03 16:01 ` [PATCH pve-network 08/10] debian: handle user modifications to FRR templates via ucf Gabriel Goller
2026-02-03 16:01 ` [PATCH pve-network 09/10] api: add dry-run endpoint for sdn apply to preview changes Gabriel Goller
2026-02-24 13:53 ` Stefan Hanreich
2026-02-03 16:01 ` [PATCH pve-network 10/10] test: add test for frr.conf.local merging Gabriel Goller
2026-02-24 13:27 ` Stefan Hanreich
2026-02-25 15:52 ` Gabriel Goller [this message]
2026-02-03 16:01 ` [PATCH pve-manager 1/1] sdn: add dry-run view for sdn apply Gabriel Goller
2026-02-24 12:49 ` Stefan Hanreich
2026-02-03 16:01 ` [PATCH pve-docs 1/1] docs: add man page for the `pvesdn` cli Gabriel Goller
2026-02-23 16:09 ` [PATCH docs/manager/network/proxmox{-ve-rs,-perl-rs} 00/23] Generate frr config using jinja templates and rust types Hannes Laimer
2026-02-24 11:09 ` Stefan Hanreich
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=ddr5jbfnamip3mazhnwlx4ugycfmoufptswhzbywe4s24q33le@yzbyva2oejkv \
--to=g.goller@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.hanreich@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox