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

[Ondrej Zajicek]

On Tue, Apr 19, 2022 at 04:06:57PM +0200, Toke Høiland-Jørgensen wrote:
> Ondrej Zajicek <santiago at crfreenet.org> writes:
> 
> > On Sat, Apr 16, 2022 at 07:28:59PM +0200, Toke Høiland-Jørgensen wrote:
> >> 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).
> >
> > I like the idea of scanning tables independently, but i suspected there
> > would be an issue on older kernels without NETLINK_GET_STRICT_CHK.
> > I will check how hard it would be to switch CONFIG_ALL_TABLES_AT_ONCE
> > in run-time.
> 
> The success/failure of the NETLINK_GET_STRICT_CHECK should be a
> predictor of whether the filtering will work; this is from the commit
> message that added the flag:

Hello

Finally i got around to finishing it:

https://gitlab.nic.cz/labs/bird/-/commit/534d0a4b44aa193da785ae180475a448f57805e2

It switches CONFIG_ALL_TABLES_AT_ONCE behavior run-time based on success
/ failure of the setsockopt for NETLINK_GET_STRICT_CHECK. Seems to work
correctly on both newer and older systems.

There were also some minor issues in the original patch, like not
handling table_id > 255, and not setting proper address family for scan.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."