net/frr: Bump to a newer version

[AndyX90]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
Starting with FRR 10.1, it is possible to specify both options point-to-multipoint and non-broadcast as network types in OSPFv2, which disables broadcast and multicast. See Docs
This would benefit of the neighbor implementation (#4694) and would open the possibility to use point-to-multipoint without broad-/multicast and make use of statically configured neighbors.
Another benefit starting with FRR 10.1 is the support for point-to-multipoint network type in OSPFv3, which supports static OSPFv3 neighbor configurations (PR prepared in AndyX90@3560fa3).

This ticket is intended to be used to identify issues on version upgrade.

Describe the solution you'd like
Bump frr to version a version >= 10.1.

Describe alternatives you've considered
none

Additional context
none

[AndyX90]

@fichtner Would it be practical to package a os-frr10 plugin containing frr10 and frr10-pythontools for testing compatibility?

[Monviech]

I'm currently taking a look at this. I have a test environment with a few VMs using all sorts of standard BGP / OSPF + BFD routing features. Two of these are also a CARP setup.

My configurations are quite basic though, just using the minimal feature set of each component.

So far I've upgraded the simplest VM to frr10 and it continued to "just work TM". If it will work for the whole routing mesh of VMs, that should be a good sign.

Though this is mostly just checking the sanity of vtysh and if things look like they work correctly.

Things like this watch-frr handling, they need a separate look too: #4712

[Monviech]

I have upgraded all of my VMs, and compared the frr.conf with vtysh show running-config, and there was no diff. This means everything I had configured was loaded correctly.

The service controls work correctly (e.g. configctl quagga stop - configctl quagga start).

All routes and neighbors are found correctly.

In sum this means, for setups without highly specialized configurations, the upgrade seems safe to me.

I will check some more details, but overall this looks promising to just offer as upgrade.

[Monviech]

Stuff to fix checklist:

• f009f68
  • mgmtd should start before zebra, or mgmtd did accidentally not start at all.
  • significant error log spam if a daemon is started before mgmtd FRRouting/frr#17931
  • I think somewhere the startup sequence of daemons might be wrong wrong

Things to consider checklist:

• Reboot required for a clean new frr state with the additional daemons running.