New device: Bird routing daemon

[ipspace]

It might be fun to add more routing daemon support. Bird seems to be an obvious choice, we might also try out OpenBGPd and GoBGP. These daemons should be able to run as pure control-plane daemons on hosts (devices without loopback interfaces).

OSPF and IS-IS implementations seem like a no-brainer (assuming the daemons support them), BGP implementation will require changes in the core BGP module if we want to have IBGP sessions with the physical interface (not loopback interfaces).

Any other ideas along these lines @steffann @ssasso @jbemmel?

[ssasso]

I guess the scope is to have them as "off path" route reflectors/route servers?

Is there any other specific reason you want to treat them differently than frr (which is not a "host")?

[steffann]

This is exactly what I was thinking

[ipspace]

Yes, we need "off path host" control-plane-only implementation. Some of those daemons might not interact with the kernel forwarding tables, and in some cases you'd want to have a route reflector that is not running OSPF. That's impossible to implement with the current code.

We would, however, have to enforce that a host running an IBGP daemon has a single (external) interface.

[ssasso]

So why not adding the same capability also to frr? (Also frr can be configured to avoid installing kernel routes)

I mean, if we find a way to treat them in the same way, then we can also have a single "way" to control kernel routes insertion?

Or - but maybe it's a bad idea - should we add a new role like "off-path-rr", which can be applied to the frr+others, including also other vendors? Then we can control links and addressing rules based on that (in a similar way you did for "host")

[ipspace]

As always, trying to keep things (somewhat) simple:

• We have devices that run dynamic routing protocols and insert those routes into forwarding tables. Most devices are in this category.
• Next, we have devices that have no way of influencing the forwarding tables. We use role: host to tell netlab it has to configure static routes on them or they have no chance to reach other devices.

Then there are grey areas like BGP RRs not running OSPF, or a routing daemon running OSPF but not inserting OSPF routes into the kernel forwarding table. They need some way to reach destinations beyond the local subnet, and static routes seem to be the only simple mechanism. We'd get them with a node that has role: host.

[ipspace]

Control-plane daemons and BIRD device have been implemented.