2.4.2: FRR shows empty status output
-
Hi All,
I recently moved from 2.3 + OpenBGPd to 2.4 + FRR + OSPF + BGP. Looks stable enough over IPSEC+GRE. One issue though.
FRR config seems to be stored in /var/etc/frr. There is /usr/local/etc/frr that only keeps the sample configs from default install. Vtysh expects the latter and I always need to run it with –config_dir. I am not sure if this is related, but status output in the Web UI always shows nothing. Gathering data... wait... empty tables, although routing works fine. Makes me wonder how this was tested for the release.
Thanks,
owczi -
Status works fine, here. Must be something in your configuration tripping it up.
Are you sure you enabled FRR both in the main FRR settings option as well as for individual daemons such as BGP?
vtysh shouldn't need the config dir set to run. It doesn't when I use it, and vtysh doesn't read the configs directly it contacts the daemons if they are running.
-
Hey Jimp,
Thank you for your reply.
I found out what it was. Special characters in the FRR master password. Looks like you have either some quoting or escaping to do, or some validation in the UI form otherwise.
On another note, why resort to telnet to the individual daemons while checking the status and passing the password around if vtysh can be used for all of this?
And on yet another note while I have your attention, are there any plans for official support for FRR's qpimd? Not sure how much demand there is for multicast routing, but has this even come up? I have been using pimd FreeBSD binaries without issues for years, but qpimd is part of FRR.
…and also, I was not able to add a/the loopback to OSPF interfaces, which is a rather basic IGP/EGP scenario practice. I can, of course, and I did add the network statement for the loopback, but I cannot set it to passive like one usually does, without modifying the raw config.
At least loopbacks are somewhat manageable with alias IPs, I heard better support for loopbacks is coming.
Thanks,
Owczi -
I found out what it was. Special characters in the FRR master password. Looks like you have either some quoting or escaping to do, or some validation in the UI form otherwise.
The UI validation is almost entirely missing yet, that's still on my todo list.
On another note, why resort to telnet to the individual daemons while checking the status and passing the password around if vtysh can be used for all of this?
At the time the status code was made, it was the best way. And now it's still a good way to make sure the status is isolated. I haven't seen a compelling argument that warrants rewriting it all to use vtysh.
And on yet another note while I have your attention, are there any plans for official support for FRR's qpimd? Not sure how much demand there is for multicast routing, but has this even come up? I have been using pimd FreeBSD binaries without issues for years, but qpimd is part of FRR.
Not at the moment, maybe in the future.
…and also, I was not able to add a/the loopback to OSPF interfaces, which is a rather basic IGP/EGP scenario practice. I can, of course, and I did add the network statement for the loopback, but I cannot set it to passive like one usually does, without modifying the raw config.
At least loopbacks are somewhat manageable with alias IPs, I heard better support for loopbacks is coming.
I'll look into adding that next time I work on the code.
-
Hi Jim,
Again thank you for your reply, all understood. I noticed that in the latest frr update (0.0.7->0.1.2), frr is configured with the correct config dir now so I can run vtysh without specifying it - nice one. My argument for using vtysh is that it is a single interface to access all FRR components, with no need for telnet and passing the password. "vtysh -c 'sho ip bgp sum'", etc. I use it because I am used to this type of interface. But if it ain't broke…
Thanks,
owczi -
This is still an issue. Is there a redmine issue for this? Should I create one?
-
This thread is 2.5 yrs old and doesn't even have a well-defined problem. There are no issues with FRR status on current versions. Start a new thread with a lot more detail about what you are seeing, it's highly unlikely it's a bug.
-
@owczi said in 2.4.2: FRR shows empty status output:
I found out what it was. Special characters in the FRR master password.
I removed the "_" from my password and it started working so I just assumed this was still an open issue. Sorry.
