os-frr: Add GUI options for conditional advertisement

[BCurrell]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
I would like GUI elements adding to the FRR settings to allow conditional advertisement to be configured on a peer. I believe this should also be supported on a peer-group.

https://docs.frrouting.org/en/latest/bgp.html#bgp-conditional-advertisement

The first route-map defined in the config line is what you want to advertise to the peer if the second route-map defined in the config either exists, or does not exist, depending on the option used. The FRR sample should be clear enough.

Describe alternatives you've considered
I've considered using vtysh to manually configure this, but I'm pretty sure this will be overwritten during bootup or config change when the FRR config is built from the OPNsense config. I've also considered using a script that monitors the existence of routes in the FIB and then stopping / starting the BGP peer based on that state, however this defeats the purpose of a dynamic routing daemon.

Additional context
N/A

[Monviech]

I feel like we are starting to get to a point in the current GUI where it could make sense to offer a generic manual import path.

There are just far too many options to ever reasonably implement.

I want a generic solution for users who just want to use vtysh on their own.

The current import structure should make this possible quite easily here:
https://github.com/opnsense/plugins/blob/master/net/frr/src/opnsense/service/templates/OPNsense/Quagga/frr.conf

Just like KEA in core, such a manual config flag would skip the existing GUI generated config files and gives users free reign over a custom configuration file ( global, not per routing daemon)

@fichtner opinions?

[fichtner]

Sure why not. But this would be per daemon?

[Monviech]

Yeah I think per daemon.

Could also be a per daemon import thats additional.

On load vtysh merges/skips double and invalid config options. So could simply be file imports without much more glue and the standard banner for that.

[fichtner]

The other approach is a .local file for overrides if merges work... might have more use cases if we can make sure to render empty files in the default setting so they can be used as complete overrides?

Cheers,
Franco

[BCurrell]

Hi both,

I’m all for a local overrides file of some sort, but I’m not sure how FRR will handle the overlapping config sections. I assume you wouldn’t use any sort of parser to merge the configs.

Mentioning KEA is interesting. Doesn’t that get configured using an API? FRR has mgmtd that might allow for something similar but I’ve not really looked too much into it.

[fichtner]

In Kea an option simply turns off the config file generation so you're free to put your own instead of it being overwritten with GUI settings. The rest of the integration remains intact.

Cheers,
Franco

[Monviech]

vtysh reads the frr.conf file.

So the cleanest way while adhering to upstream schematics would be a global "manual config" option inside the general settings.

That disables all the config generation around frr.conf and allows manual configuration only.

https://docs.frrouting.org/en/latest/vtysh.html#integrated-configuration-file

Doing it per daemon or additive or some other way would allow some crazy combinations between GUI and manual configs which will be impossible to troubleshoot. A single manual file has a clear ownership contract.