# Frr addon and initial configuration samples **URL:** \ **Category:** Add-Ons\ **Created:** [21 March 2025 12:41 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817 "2025-03-21T12:41:00Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![nodeejay](https://community.ipfire.org/user_avatar/community.ipfire.org/nodeejay/32/12964_2.png) [@nodeejay](https://community.ipfire.org/u/nodeejay)\ **Post date:** [21 March 2025 12:41 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/1 "2025-03-21T12:41:00Z")
[Not able to start frr routing deamon - Getting Started with IPFire - IPFire Community](https://community.ipfire.org/t/not-able-to-start-frr-routing-deamon/5356) 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? ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [21 March 2025 12:50 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/2 "2025-03-21T12:50:11Z")
> [@nodeejay](#): > > but the config samples mentioned seemed to be missing in the current implementation. 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. > [@nodeejay](#): > > 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? It would be really good to have the documentation updated by someone using the package so please go ahead and update the documentation. ---
**Author:** ![nodeejay](https://community.ipfire.org/user_avatar/community.ipfire.org/nodeejay/32/12964_2.png) [@nodeejay](https://community.ipfire.org/u/nodeejay)\ **Post date:** [21 March 2025 13:22 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/3 "2025-03-21T13:22:52Z")
As you wished, Adolf 🙂 [www.ipfire.org - frr - FRRouting](https://www.ipfire.org/docs/addons/frr) 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 ---
**Author:** ![nodeejay](https://community.ipfire.org/user_avatar/community.ipfire.org/nodeejay/32/12964_2.png) [@nodeejay](https://community.ipfire.org/u/nodeejay)\ **Post date:** [21 March 2025 13:52 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/4 "2025-03-21T13:52:29Z")
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](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. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [21 March 2025 14:08 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/5 "2025-03-21T14:08:17Z")
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](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. ---
**Author:** ![nodeejay](https://community.ipfire.org/user_avatar/community.ipfire.org/nodeejay/32/12964_2.png) [@nodeejay](https://community.ipfire.org/u/nodeejay)\ **Post date:** [21 March 2025 14:48 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/6 "2025-03-21T14:48:17Z")
The migration is in theory relatively simple, from the docs: > `frr.conf` is 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 -b` must be invoked to process `frr.conf` and 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 `DAEMON` since this functionality is provided now by the `frr.conf`. - add `frr.conf` from [Basic Setup — FRR latest documentation](https://docs.frrouting.org/en/latest/setup.html) to `/etc/frr` with all protocols set to _no_ and the rest commented out except `vtysh` 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](https://forum.kbits.live/t/allowing-ospf-eigrp-through-transparent-ftd/1425) 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 ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [23 March 2025 13:38 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/7 "2025-03-23T13:38:03Z")
> [@nodeejay](#): > > 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. 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. > [@nodeejay](#): > > add `frr.conf` from [Basic Setup — FRR latest documentation](https://docs.frrouting.org/en/latest/setup.html) to `/etc/frr` with all protocols set to _no_ and the rest commented out except `vtysh` 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? ---
**Author:** ![nodeejay](https://community.ipfire.org/user_avatar/community.ipfire.org/nodeejay/32/12964_2.png) [@nodeejay](https://community.ipfire.org/u/nodeejay)\ **Post date:** [24 March 2025 11:16 UTC](https://community.ipfire.org/t/frr-addon-and-initial-configuration-samples/13817/8 "2025-03-24T11:16:13Z")
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. > [@bonnietwin](#): > > […] This cannot be done like this. There must be no breaking change for users. 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](https://docs.frrouting.org/en/latest/basic.html#integrated-config-file) 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. > [@bonnietwin](#): > > […] 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? 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.