Not able to start frr routing deamon - Getting Started with IPFire - IPFire Community brought me to the right direction but the config samples mentioned seemed to be missing in the current implementation. However, it is quite straight forward from the official documentation to create files per daemon and the frr folder in /etc.
I would now like to update the manual, do you plan to reimplement the sample files or shall I include the steps in the manual?
frr removed the sample files a long time back. They were provided in the initial build with version 6.0 in 2018 but in 2021 when frr was updated from 6.0 to 8.0.1 they were no longer provided.
It would be really good to have the documentation updated by someone using the package so please go ahead and update the documentation.
As you wished, Adolf 
www.ipfire.org - frr - FRRouting
I will continue to update it over the course of our implementation with a mikrotik router as master. We want to use OSPF so it will be focused on that. If someone made experiences with BGP or the others I would be happy for input.
Cheers,
Alex
1 Like
The documentation states deprecation for multiple config files, but the intit script iterates through all options of DAEMON with individual configurations.
https://docs.frrouting.org/en/latest/vtysh.html#integrated-configuration-file
If we remove the iteration from /etc/init.d/frr and let the single config file frr.conf do it’s job starting the right daemons it would remove complexity and migrate to the current approach from the upstream. Furthermore, a single conf could be shipped again, where all protocols are commented out, to make initial configuration easier with a sample.
The only “downside” would be vtysh because it would need to run additionally with -b to process the frr.conf instead of each individual config.
I had seen that deprecation but I tried to test out the single conf file and I could not get it working but then I don’t use frr and am not familiar with the details of what it is trying to do.
If you can make the single config work, I suspect you will need to modify the existing initscript. If you can identify and confirm what needs to be done then you can submit a patch for any change to the development mailing list
https://www.ipfire.org/docs/devel/submit-patches
However, the initscript would need to be able to continue using the multiple conf files so that we don’t break any users setup.
If an initscript can be defined to use the single conf file if it is specified in the right location, or the multiple conf files if frr.conf does not exist then a message could be placed in the frr documentation to announce the deprecation of the multiple conf files and that existing users should change to the frr.conf approach.
That way existing users can update their systems to the frr.conf approach at their own timing and when eventually frr stops accepting the multiple conf files and will only work with the frr.conf file then hopefully all users will be converted.
If the above is something you don’t feel able to submit a patch for then if you can identify what the frr.conf file should contain and how the initscript should be defined to make frr work with the frr.conf approach then I could try and define a patch set for updating frr to work with both approaches based on the presence of frr.conf or not.
The migration is in theory relatively simple, from the docs:
frr.confis located in /etc/frr. All daemons check for the existence of this file at startup, and if it exists will not load their individual configuration files. Instead,vtysh -bmust be invoked to processfrr.confand apply its settings to the individual daemons.
That’s what I meant with, the only “downside” is vtysh since you need the b parameter to process frr.conf instead of individual files. I think this is what you mean with “a message could be placed in the frr docu”.
How many IPFire users use the addon and would be really impacted? I did not find much threads in the forum and the manual was sparse, a sign the usage was not so high or everyone using it knew exactly what to do… fireinfo?
Sum up: existing users will not encounter issues until they re-install the add-on, which would create on top a new frr.conf thus not loading their existing configurations, a certain breaking change to be mentioned in the release notes.
Yes, the diff would come close to
- edit init script and remove the loop to process the command for each protocol listed under
DAEMONsince this functionality is provided now by thefrr.conf. - add
frr.conffrom Basic Setup — FRR latest documentation to/etc/frrwith all protocols set to no and the rest commented out exceptvtysh
So far the theory.
Also, I found no logging yet to be activated and terminal monitor ospfd in vtysh did not show anything except that it is already monitoring the logs. I think particularly this add-on needs proper logging enabled by default plus a documentation how it can be lowered after implementation. A GUI could be nice, reading the neighbor state, learned routes and to allow config of domain, ID and passwords, but then surely 4 Fridays are not enough to implement all.
I am not sure if we not also need a firewall rule, OSPF uses protocol ID 89, nothing so far, I would have found to be configurable in the IPFire, however, I found in another thread that there might be a need for it: Allowing OSPF/EIGRP Through Transparent FTD - Security - KBITS Live Forum
Then I come to the question of security itself running automatic route reconfiguration protocols on a firewall and back to how can we make sure to allow the protocol on GREEN but also make sure to DROP it on RED and most probably on ORANGE/BLUE as well. Is having the FW as master enough to make sure it distributes but not receives rules, or is receiving even desired, etc. etc.
What I want to say: if we want to do it properly it’s not a quick Friday afternoon hack and we should maybe involve more experienced security experts from the core before we implement it.
I will try to implement suggested changes in a POC and let you know the progress. When the test finished successfully we can come to the code adaptions, security discussions, RN and file the patch.
Enjoy the weekend, sunny greetings from Prague,
Alex
2 Likes
This cannot be done like this. There must be no breaking change for users. We need to be able to cope with both situations and provide time and notification/communication to migrate from the multiple conf files situation to the single conf file situation.
That link only shows the contents of /etc/frr/daemons and not of frr.conf.
frr.conf is not mentioned anywhere on that page.
How do I find out what to put in frr.conf? or is it just a complete copy of what would have been in /etc/frr/daemons for the multiple conf approach?
You are right, I see now there seem to be different files, there is the daemons and additionally the frr.conf, I need to read a bit more what goes where and come up with correct config files.
Do you want to say during the migration we need to make sure the current split files per daemon are correctly joined and re-split for the user to daemons and frr.conf or how what do you have in mind for that migration? Can we find out how many people are using the addon, maybe we talk about a migration that is not even existing?
Basic Commands — FRR latest documentation mentions that reading from daemon independent config but writing back in case of changes to the single frr.conf file. Maybe we can use this to migrate by reading all params per daemon and writing same back. Let’s check when we are that far.
This is the mistake I made initially as well, I assumed all goes to frr.conf but I see it seems to need a split. daemons to start the needed protocols and frr.conf to configure the chosen protocol itself (e.g. passwords, ID, etc. in case of OSPF). Lastly, there are the port configurations for the deamons which should go to services, but I don’t know yet if it is needed, since it worked with vtysh out of the box and I was able to connect to the daemon.
Still struggling with logging on frr’s OSPF v2 itself, this is my first task to get at least the “neighbors” to see each other.