opnsense / plugins

OPNsense plugin collection
https://opnsense.org/
BSD 2-Clause "Simplified" License
832 stars 620 forks source link

net/frr: Additional redistribute options #607

Closed ShaRose closed 6 years ago

ShaRose commented 6 years ago

Right now the redistribute options available for each daemon is a bit mixed: each one has different options available, but none of them support everything that FRR is capable of. I was actually going to do a PR adding in everything missing to each option, but I'm adding this issue instead so there can be some discussion about which selections should be added.

For example, one of the options that BGP and RIP support is redistributing IS-IS: Should this be implemented in each daemon, even though the FRR plugin itself doesn't support IS-IS? How about NHRP, which FRR doesn't even have implemented yet?

I'm personally leaning towards "Just fire in everything", but there are some arguments for not including things like VNC or NHRP, at least until FRR supports these protocols itself.

mimugmail commented 6 years ago

The code for redistrubtion was shifted from Quagga which supports some less protocols than FRR. Redistribution to a protocol which is not supported by the plugin is indeed something to debate. IMO less is better to not get more question why X is not working :)

I have no experience with IS-IS and NHRP .. are they stable with FRR?

ShaRose commented 6 years ago

IS-IS I haven't used: NHRP is on the roadmap for support, but isn't supported yet.

Some things that I do think should be added to everything include things like Kernel routes: That in particular was the cause of me starting at this, because for OSPFv3 there isn't an option to advertise as a default gateway. Normally, you redistribute static routes, but if you create a gateway for something like Tunnelbroker (which I did), it is actually added as a kernel route and thus isn't advertised.

The main reason I was leaning towards just add everything was if later on someone does implement IS-IS into the plugin, they don't need to add IS-IS to each protocol. Or if FRR finishes up support for NHRP and DMVPN, it lowers the changes needed.

Even if a user selects them without knowing, it's not like it would cause any problems anyways (Since there would be no routes to redistribute).

mimugmail commented 6 years ago

Are you sure this is really an acceptable value? I'm quite sure I imported all of them, but I also can easily add it.

ShaRose commented 6 years ago

Yeah, there's lots that haven't been added. Here's a list for each daemon copied from vtysh using redistribute ?, with the missing options bolded: RIP

bgp Border Gateway Protocol (BGP) connected Connected routes (directly attached subnet or host) isis Intermediate System to Intermediate System (IS-IS) kernel Kernel routes (not installed via the zebra RIB) nhrp Next Hop Resolution Protocol (NHRP) ospf Open Shortest Path First (OSPFv2) pim Protocol Independent Multicast (PIM) static Statically configured routes table Non-main Kernel Routing Table vnc Virtual Network Control (VNC)

Note for this one babel is not a supported option in FRR, but is still in the plugin for RIP.

ospf (OSPF)

bgp Border Gateway Protocol (BGP) connected Connected routes (directly attached subnet or host) isis Intermediate System to Intermediate System (IS-IS) kernel Kernel routes (not installed via the zebra RIB) nhrp Next Hop Resolution Protocol (NHRP) ospf Open Shortest Path First pim Protocol Independent Multicast (PIM) rip Routing Information Protocol (RIP) static Statically configured routes table Non-main Kernel Routing Table vnc Virtual Network Control (VNC)

ospf6 (OSPFv3)

bgp Border Gateway Protocol (BGP) connected Connected routes (directly attached subnet or host) isis Intermediate System to Intermediate System (IS-IS) kernel Kernel routes (not installed via the zebra RIB) nhrp Next Hop Resolution Protocol (NHRP) ripng Routing Information Protocol next-generation (IPv6) (RIPng) static Statically configured routes table Non-main Kernel Routing Table vnc Virtual Network Control (VNC)

bgp (BGPv4)

connected Connected routes (directly attached subnet or host) isis Intermediate System to Intermediate System (IS-IS) kernel Kernel routes (not installed via the zebra RIB) nhrp Next Hop Resolution Protocol (NHRP) ospf Open Shortest Path First (OSPFv2) pim Protocol Independent Multicast (PIM) rip Routing Information Protocol (RIP) static Statically configured routes table Non-main Kernel Routing Table vnc Virtual Network Control (VNC) vnc-direct VNC direct (not via zebra) routes

Again for babel not being an option.

mimugmail commented 6 years ago

Table seems to be linux specific; vnc is new, whats this? PIM and NHRP are not supported, IS-IS also. I'm not really sure if it's a good idea to add everything, no matter if supported or not .. perhaps some other opinions? @fabianfrz ? @fichtner ?

fichtner commented 6 years ago

in general it's better to only add what is being asked for because it gets real world testing if we can't cover the topics ourselves

ShaRose commented 6 years ago

In that case, why don't we restrict each option to connected, kernel, static, bgp, ospf, and rip (where valid)? We can add in IS-IS / RIPng / NHRP if and when these protocols are supported by the plugin.

fabianfrz commented 6 years ago

The plugin code for IS-IS should not be hard to write but I do not know the protocol. This is the reason why it is a stub in the code as a ready to contribute code for anyone interested.

IS-IS is a widely used protocol and I think it should be added some day. Maybe I find some time to read some docs for it.

I have never heard of NHRP and PIM before. They are probably not widely used. For RIPng: I do not have (native) IPv6 which is sad fact. I hope that will change in the future. But for RIPng I could probably add a page as it will probably not harder than RIP. The only thing is that I do not have much time at the moment.

ShaRose commented 6 years ago

NHRP is mostly designed for DMVPN, which is currently only a Cisco thing (Dynamic VPN configuration essentially for site to site communication between many sites). It's only in an alpha state at the moment. PIM I have no idea, but it's also not fully implemented. Neither are widely used, and since they aren't really production ready as far as I know in the upstream project we can leave them out at the moment.

If IS-IS and RIPng are being looked at, I figure it's just as well to include those options into redistribute in that case. The plugin can have those options enabled later: Worst case, if someone wants to use them they can still get a root shell and use vtysh manually.