[Question] Quagga/BIRD support on upcoming release

[faisalusuf]

Hello,
I have seen the HOWTO on Quagga to support routing protocols highly encouraging. The routing protocol support is what broader OPNsense the deployment in complex network scenarios.

Is the web based management for Quagga or BIRD is in the roadmap of future releases?

Thanks
F.

[franco]

Hi Faisal,

Quagga is in the packages, but not in the plugins yet, right.

I've had one interested party for OSPF last year, but the project did not go through.

While these kinds of protocols are needed for larger deployments, we'll also need larger contributors in order to accommodate them in the first place.

Specifically -- in non-monetary terms -- this means we need:

1. A contributor willing to define requirements for a routing protocol implementation.
2. Allocating a spot in the roadmap for 17.1, assigning an core developer as maintainer from our side.
3. Testing and feedback coordination between the two until the project is completed.

With this in place I could see one or two routing protocols in the plugins section on our way to 17.1, which doesn't mean that these could not be available sooner, but probably no sooner that Q4 2016.

All very hypothetical. If anybody is interested drop us a line at project _A_T_ opnsense _D_O_T_ org


Cheers,
Franco

[faisalusuf]

Hi Franco,
Thanks for a positive response. In larger deployments mostly BGP or OSPF (failover scenarios) are used.
The protocol implementation is already done in Quagga or BIRD. The integration with WebUI is needed apparently.

What I was thinking by adding routing protocols will add value or can bring complication (in terms of project stability and reliability?) to the existing stable UTM engine.

Cheers
Faisal.

[franco]

Hi Faisal,

That's exactly right: GUI integration must be done from our side, which at the minimum requires code review, if not a developer doing the integration as we have the experience with our framework(s) and can get that done pretty fast. The other side is requirements modelling and integration testing. An external test site is a must in those cases to deliver a viable solution.

E.g. the HAproxy plugin was developed by an external contributor who does the developlment/testing in his company, and we've helped him to bring the GUI parts into the right shape. I don't know how long this took from both sides exactly, but it wasn't more than a month of part-time work to get it into a usable stage. Final release is still pending.


Cheers,
Franco

[ccesario]

Hi guys,

How is going this? We will have OSPF / BGP Gui in 17.1 ?

Best regards,

Carlos

[Nicolasb]

As mentioned by others, OSPF/BGP gui would be welcome, at least for basic configuration.

I'm using QUAGGA (BGP) right now with OPN and it works great, but there are some features that would be nice to have, even without the gui configuration part.
For example, the System/Routes/status page shows BGP routes with the Flag "UG1", static routes with "UGS", etc. This makes it hard to read where the routes are coming from and from what routing protocol. Would it be possible to use standardish flags ? ( Cisco example; L - local, C - connected, S - static, R - RIP, B - BGP ...)

Also a small help box directly on that page for the flags would be nice it took me a while to find it in the docs.

Back to GUI, if all that is needed for a basic GUI is a site for testing and development, i can obviously and happily test it any time for most routing protocols.

[franco]

Nicholas, I like the idea. Can you add a ticket over at https://github.com/opnsense/core/issues ? We like to keep ownership of features with the requesters to improve the result and simplify testing.

I'm talking to a quagga developer, we have plans to add OSPF first, later BGP, but we still need to allocate the funding.


Thank you,
Franco

[pingus]

+1