FRR files location (and lock down)

Started by senseivita, May 21, 2023, 04:45:17 PM

Previous topic - Next topic
Hi everyone :)


So... I have had this set of routers running OSPF: 1x switch, 1x OPNsense, 2x pfSense; they were all fully adjacent. Then I switched one of the pfSenses for OPNsense (new setup: 1x switch, 2x OPNsense, 1x pfSense) which happened to be the only one that wasn't directly connected to area zero and things went south fast. It's across an L2 tunnel, thus it's broadcast and should have no problems, on the other hand there's so little in the UI to set this up so I could never get it to work. About 40 or so hours in I thought "f**k it, I'm going on the CLI" I was already a little familiar with it (vtysh) because it used it to make pfSense form adjacency with the switch-router which doesn't have FRR, just "OSPF", As it turns out, the CLI for these areas is nearly if not identical on each vendor (found it too in Ubiquiti and VyOS proper).


Anyway, first I tried FRR8 so the changes I had already done in the GUI wouldn't overwrite things back but there was some conflict so I went back; I shook it a little, wiggled the thingy, put it against my ear and repeated until it sprung to life, forming full adjacency with the nearest peer.


It's done. It works. However, since pfSense is the closest to OPNsense to where guide myself from, I took a significant(just 1% more of 99%) amount from there, pfSense stores data in /var/etc/frr/ and /usr/local/etc/frr/. The official FRR documentation focuses more on the Linux side only /etc/frr so it's clear as saying "see you at seven", without following it by "hours" or "am/pm" and neither pfSense nor OPNsense have the most extensive documentation on this or at least some that unlike the official FRR documentation is targeted at their respective user bases — y'know, one or two(thousand) levels below "network engineer", referred to by their tribes as He or She Who Runs Not With Cisco.  ;D


/var/etc/frr wasn't on OPNsense, so I assumed this was a temporary location on pfSense to save configuration, it seems to have a ton of these little pockets.


I modified vtysh.conf (because using vtysh the first time around printed something about it being jsut for show) and frr.conf, followed by service frr restart. It didn't seems to make a difference, it printed a lot of stuff of how misconfigured it was. I copied the files I had created on /var/etc/frrto /usr/local/etc/frr next to several other config files already there. vtysh.conf and frr.conf weren't. service frr restart and this time it only printed one warning. It seems like that was the place except when I tried getting information on vtysh, no interface was actually configured.


FRR docu's does say that daemons need to be started and the daemons file was the one missing from OPNsense. I added it and enabled a few daemons (zebra, ospfd, staticd, bfdd), restarted. Nothing.


But, after retrying vtysh with the modifications I had done, write now worked. I'm sorry I made it this long but I wanted to describe the places (paths) I touched to hopefully get a better answer to: where does OPNsense actually stores the files? (because) From another terminal, I saw the modifications being written by vtysh were where I initially thought the were going to be, but as I mentioned, I had already done this before I repeated them on vtysh and when not done via vtysh they were ignored.


Also, what do I need to do to lock the configuration down? So it's not overwritten by an update or a restart or just checking out its status from the GUI. In pfSense the GUI easily overrules the CLI/configfiles all the time, I'm not sure if OPNsense differs in there yet.


I'll just leav--um.. Thanks.
I'm a bit dyslexic and it makes me forgo letters at the end of words. What gets written is written correctly though, I have good orthography in one or two languages, ironically. It's messed up, I know, I'm sorry. Just pretend you're my auto-complete. :)

/usr/local/etc/frr

You can install pkg without plugin so you can do it CLI only. If you install the plugin it always gets overwritten