[PATCH] krt: Dump routing tables separetely on linux to avoid congestion

[Toke Høiland-Jørgensen]

Daniel Gröber <dxld at darkboxed.org> writes:

> When dumping the routing table bird currently doesn't set the rtm_table
> netlink field to select any particular one but rather wants to get all at
> once.
>
> This can be problematic when multiple routing daemons are running on a
> system as the kernel's route modification performance goes down
> drasticly (by a factor of 20-200ish) when the table is being modified while
> it's being dumped.
>
> To avoid this situation we make bird do dumps on a per-kernel-table
> basis. This then allows the administrator to have multiple routing daemons
> use different kernel tables which sidesteps the problem.
>
> See also this discussion on the babel-users mailing list:
>   https://alioth-lists.debian.net/pipermail/babel-users/2022-April/003902.html

Note that this only works with the strict netlink filter checking is
enabled (i.e., if the setsockopt for NETLINK_GET_STRICT_CHK succeeds).
Bird currently doesn't check this at runtime at all, so just applying
this patch as-is will not work correctly on older kernels (<4.20).

One option could be to add a compile-time check for the presence of the
NETLINK_GET_STRICT_CHK definition in system headers, and set
CONFIG_ALL_TABLES_AT_ONCE based on whether it is present. This should do
the right thing in most cases, and even if it fails (i.e., if bird is
compiled on a newer system than it will run on), this will only lead to
redundant scans, not missed routes, so this could be an acceptable
trade-off?

Otherwise, CONFIG_ALL_TABLES_AT_ONCE would have to be made a run-time
parameter set based on whether the setsockopt call succeeds...

-Toke