[pve-devel] [RFC network/ve-rs 0/8] Template-based FRR config generation

[Stefan Hanreich]

On 10/4/25 2:13 PM, Thomas Lamprecht wrote:
> Am 19.09.25 um 11:41 schrieb Gabriel Goller:
>> The third and probably most popular way (Vyos and Sonic both use jinja
>> templates as well) to generate frr config is to use templates. So you basically
>> have rust-structs that look similar to the frr config and implement derive or
>> implemennt serialize. Then we can use template files, which contain the whole
>> configuration with every option wrapped in a `if` block and lists/blocks
>> wrapped in `for` loops. Finally, we can use the rust structs to insert them into
>> the templates and get the full frr config. The major downside of this approach
>> is that the frr template files get quite complicated and can be a major source
>> of config generation errors. A positive thing though, is that we don't need to
>> model the whole frr config with every option and every property, we can easily
>> wrap a few options into a single (e.g.) bool, and then maybe split it out later
>> when we add a ui option for each property.
> 
> I mean, that should be possible in any representation, just needs separation of
> types for the API and types to generate the (dumped) FRR config from.> One drawback is. that you loose type checks with templates, but that
can be
> made up by a regression test system (which is a necessity either way), so your
> approach can be OK to me in general, but this needs to be Ack'ed also by Stefan.

Imo some type-safety can still be upheld by e.g. using enums instead of
simply Strings for fields in the templates that only accept certain
keywords - same for fields that accept certain formats (IPs / CIDRs /
...). Nevertheless, a working and comprehensive integration / regression
test system should accompany any approach we choose.


One big upside of this approach, that hasn't really been mentioned yet,
is imo the handling of FRR configuration overrides.

What we currently do in pve-network is try and parse the FRR
configuration into a Perl hash format with a implementation that
supports only a subset of FRR (some examples for users running into
limitations [1] [2]). Then we merge that parsed hash with a hash
generated by the EvpnController and serialize everything out again.

Getting this to work *properly* would basically require re-implementing
and maintaining a full FRR configuration parser, which is no small feat
[3]. Then add some custom merging logic on top, which brings its
additional challenges. This problem will imo also worsen the more our
generated FRR configuration grows.

Providing templates as overrides makes that whole process much simpler
for the users and for us and it is more in line with how we handle
overrides e.g. in PMG or the notification system where that approach
seems to work quite well afaict.

Of course there's also drawbacks associated with that approach, like
managing updates to the templates when overrides exist seems to crop up
in PMG quite a few times. So I'd be interested to hear your opinions /
experiences on that approach particularly wrt template overrides and if
we have any learnings from that.


Aside from that, templates seem to be the sanest option from my pov as
well, particularly when compared to implementing a serde Serializer /
Deserializer. That seemed quite tricky due to some quirks from the FRR
configuration for. I don't remember the specific issues @Gabriel
encountered but maybe @Gabriel can elaborate more on the issues he
encountered when trying to go down that route. Part of that was why I
suggested that Gabriel might want to look at using templates instead.


Alternatively, there's the Northbound API [4] which uses YANG for its
configuration language, but it doesn't seem ready yet and lacks support
for e.g. bgpd.

> The third option of using two template engines is naturally also one, but actively
> and knowingly planing a schism is not something I'd promote much either tbh.

Fully agree that using one templating engine across all our codebase
instead of using FOTM templating language seems far better. I don't
think minijinja could bring any upside that would outweigh that.



[1]
https://forum.proxmox.com/threads/sdn-frr-conf-local-extcommunity-list.161977/
[2]
https://forum.proxmox.com/threads/sdn-with-evpn-controller-routing-loop-when-using-multiple-exit-nodes.137362/#post-696569
[3] https://docs.frrouting.org/projects/dev-guide/en/latest/cli.html
[4]
https://docs.frrouting.org/projects/dev-guide/en/latest/northbound/northbound.html