Netgate SG-1000 microFirewall

Author Topic: 2.4.2: FRR shows empty status output  (Read 108 times)

0 Members and 1 Guest are viewing this topic.

Offline owczi

  • Newbie
  • *
  • Posts: 18
  • Karma: +1/-0
    • View Profile
2.4.2: FRR shows empty status output
« on: December 03, 2017, 10:57:30 am »
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


Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21404
  • Karma: +1437/-26
    • View Profile
Re: 2.4.2: FRR shows empty status output
« Reply #1 on: December 04, 2017, 10:03:59 am »
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.
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!

Offline owczi

  • Newbie
  • *
  • Posts: 18
  • Karma: +1/-0
    • View Profile
Re: 2.4.2: FRR shows empty status output
« Reply #2 on: December 08, 2017, 02:57:47 pm »
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

Offline jimp

  • Administrator
  • Hero Member
  • *****
  • Posts: 21404
  • Karma: +1437/-26
    • View Profile
Re: 2.4.2: FRR shows empty status output
« Reply #3 on: December 12, 2017, 10:42:56 am »
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.
Need help fast? Commercial Support!

Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.

Do not PM for help!