Anno domini 2021 Lukas Haase scripsit: Hi,

Assume the following toy example:

R1: R2: 10.1.1.0/24 <--- 10.1.1.1, 192.168.1.1 <---------> 192.168.1.2, 10.1.2.1 ---> 10.1.2.0/24

Net 10.1.1.0/24 has R1 as default route, net 10.1.2.0/24 R2. Since the network connectivity is known, 10.1.2.0/24 could reach 10.1.2.0/24 and vice versa. Of course, R1 and R2 need to exchange that information.

It was my understanding that OSPF would do this automatically. But this does not seem to be the case with Bird: Dynamic routes (10.1.1.0/24 and 192.168.1.0/24 for R1 and 192.168.1.0/24 and 10.1.2.0/24 for R2) do not land automatically in bird's routing table. I would like to understand exactly why and what is the "right" way to configure bird. Many protocols have flags to allow this but all say it would only be for "exceptional" purposes. But the above network is pretty much the most common one. Where else would routing information come from if not from the network connectivity? Note that this is not OSPF specific: My Mikrotik router automatically sends me all the routes of its connected networks, as I would expect it.

So, I think there are the following options:

1.) The direct protocol. But the doc makes it sound this is not the right path:

"[...] Although there are some use cases that use the direct protocol (like abusing eBGP as an IGP routing protocol), in most cases it is not needed to have these device routes in BIRD routing table and to use the direct protocol. [...]"

The direct protocols "learns" prefixes on interfaces. This is required for protocols like BGP. The OSPF protocol does not need this as it will learn prefixes by itself.

2.) The kernel protocol. But also here the docs have a strong bias importing dynamic routes (device routes):

"[...] Unfortunately, there is one thing that makes the routing table synchronization a bit more complicated. In the kernel routing table there are also device routes for directly connected networks. These routes are usually managed by OS itself (as a part of IP address configuration) and we don't want to touch that. They are completely ignored during the scan of the kernel tables and also the export of device routes from BIRD tables to kernel routing tables is restricted to prevent accidental interference."

The protocol can learn routers from the Kernel routing table which end up there by any other means than bird (ip route add ...) and is required to write routes learned by bird into the Kernel routint table. I guess the latter is what you want in your setup.

3.) The static protocol. I could add something like (for R1):

protocol static { export all; route 10.1.1.0/24 via 192.168.1.1; }

But then I would manually re-create the already known network connectivity in the config file.

Exactly.

Why does no protocol in Bird want to take responsibility for the router's own connectivity? How on earth is this supposed to work?

OSPF does that :) I would propose a configuration for R1 like protocol ospf { import all; # Learn all routes from OSPF export none; # Do not export (redistribute) any routes from # birds main table into OSPF area 0 { # Interface conncted to R2 should be part of OSPF and # "speak" OSPF (send hello packets) interface "eth0"; # Interface connected to the local network should be # part of OSPF but NOT "speak" OSPF (do NOT send hello # packets, so no machine there can join OSPF) interface "eth1" { stub yes; }; } } The config for R2 basically looks the same. Does that do what you expect? Best Max