search

FRRouting / frr

The FRRouting Protocol Suite
https://frrouting.org/
Other
3.27k stars 1.24k forks source link

FRR / ability to reference file in vtysh.config file #2128

Open pguibert6WIND opened 6 years ago

pguibert6WIND commented 6 years ago

The need is to be able to execute a vtysh.conf and all the file references that one could have in that file. example:

service integrated-vtysh-config
file /tmp/client1.conf
file /tmp/client2.conf
file /tmp/client3.conf

As you see, that configuration means that it will load the configuration contained in file /tmp/client.1conf.

The need obviously, is to easily add or delete specific sub set of the configuration file.

donaldsharp commented 6 years ago

It might be better to have file only allow the loading of files in the --sysconfdir. Other than that it's an good idea. How do you plan to make this work with reload?

pguibert6WIND commented 6 years ago

I just read the reload.py script. It seems running configuration is read and slurp it into internal memory I suppose that the reload.py script should be improved to make it wiser. right ?

but this script is only for systemd users .?

donaldsharp commented 6 years ago

The script is for anyone who wants to use it. It still can be used for init.d style setups.

the reload script looks at the current running config -vs- the specified file to reload against and figures out which lines need to have a no XXX issued and which lines need to be added to the running config.

toreanderson commented 5 years ago

The possibility to include/source other files directly or via an frr.conf.d directory is sorely missed. Almost every other daemon/service on a regular Linux system has the possibility of doing so, e.g., ifupdown2 on Cumulus Linux comes by default with source /etc/network/interfaces.d/*.intf that does exactly what you'd think.

One use case is where you have different systems that are responsible for writing different parts of the frr.conf file. In my case, mostly-static config (BGP neighbours and so on) are templated out of Ansible, while more dynamic config (IP prefix filters for eBGP peers) are generated based on routing registry data using a tool like bgpq3 running periodically from cron.

Being able to have the main mostly-static frr.conf file include dynamic prefix filters from another file would be extremely convenient.

ITJamie commented 1 year ago

+1 on being able to include other config files

qlyoung commented 1 year ago

Was this actually done?

qlyoung commented 1 year ago

Gonna leave it open, might be obsoleted by mgmtd but we need to check on that

ITJamie commented 1 year ago

I was soo excited for a moment there...

qlyoung commented 1 year ago

Sorry, we're just doing some housekeeping 😅

choppsv1 commented 1 year ago

There is at least one big issue with adding the unix daemon standard include foo.d/* functionality here.. Unlike most unix daemons whose configs are read-only to the daemon, FRR allows for changing the configuration (e.g., CLI, netconf, ...) at runtime, and then critically, writing said configuration back out to the file system. Doing this while supporting include files is probably not worth the complexity in getting that right unfortunately.

ITJamie commented 1 year ago

It could easily be handled by comment spacers in the code when imported. A comment before and after each file designating the source and destination.

In my usecase i wouldnt actually even want it to write out the "extra" files, only include them as a source of data on load

qlyoung commented 1 year ago

I don't think it's that simple. Suppose your BGP configuration is in /etc/frr/config.d/asdf.conf, and then in vtysh you define a route map and then use the route map in a new bgp router block and then write it out. Where does the routemap go? Where does the new BGP config go?

It's possible I am not understanding the easy solution fully. Maybe I don't completely understand what you mean by the comment idea.

The read only case is relatively easy; the write case, which we unfortunately do have to support, is much harder.

toreanderson commented 1 year ago

write already munges the configuration file, so I'm guessing that folks that use config file(s) created by something else than FRR itself (i.e., config terminal) simply never use write to begin with. Personally I would be completely fine with write just writing back a monolithic file without any include statements (i.e., no change from today). To me, the include feature would only be valuable during the initial config load and reload operations.