Allowing multiple instances of kernel protocol to use same table
Hi, Is there any specific reason why each instance of kernel protocol must use unique table? What I want to achieve is to export different protocols (OSPF, BGP etc) to different kernel tables, but the only way I can do this currently is to use pipe, instead of export filter only. My concern is duplication of data - BGP table has over 500k routes, so keeping this in master *and* piping to another one for kernel export is a waste of resources (both RAM and CPU). Thank you! -- With best regards, Alexander.
Hi,
Is there any specific reason why each instance of kernel protocol must use unique table?
What I want to achieve is to export different protocols (OSPF, BGP etc) to different kernel tables, but the only way I can do this currently is to use pipe, instead of export filter only.
My concern is duplication of data - BGP table has over 500k routes, so keeping this in master *and* piping to another one for kernel export is a waste of resources (both RAM and CPU).
Thank you!
Try attached patch. It only removes checks for multiple kernel syncers attached to the single BIRD routing table, but does not touches checks for creating multiple kernel syncers attached to the single kernel routing table. Patch is against upstream 1.4.4 version of BIRD, but I only had tested this for BIRD 1.3.11 on Linux 3.2.x. Tested with up to 5 kernel syncers attached to the single BRT and protocols (BGP, static, direct, etc.) seems work correctly. Also tested with 2 kernel syncers attached to the single BRT with import/export set to "all" (transparent pipe between two kernel routing tables). -- SP5474-RIPE Sergey Popovich
В письме от 18 августа 2014 17:52:30 пользователь Sergey Popovich написал:
Hi,
Is there any specific reason why each instance of kernel protocol must use unique table?
What I want to achieve is to export different protocols (OSPF, BGP etc) to different kernel tables, but the only way I can do this currently is to use pipe, instead of export filter only.
My concern is duplication of data - BGP table has over 500k routes, so keeping this in master *and* piping to another one for kernel export is a waste of resources (both RAM and CPU).
Thank you!
Try attached patch.
It only removes checks for multiple kernel syncers attached to the single BIRD routing table, but does not touches checks for creating multiple kernel syncers attached to the single kernel routing table.
Patch is against upstream 1.4.4 version of BIRD, but I only had tested this for BIRD 1.3.11 on Linux 3.2.x.
Tested with up to 5 kernel syncers attached to the single BRT and protocols (BGP, static, direct, etc.) seems work correctly.
Also tested with 2 kernel syncers attached to the single BRT with import/export set to "all" (transparent pipe between two kernel routing tables).
V2: Do not flush kernel routes learned from the protocol itself. Note that it is still possible to uninstall route imported from one KRT and installed in another KRT. This needs to be handled more carefully. -- SP5474-RIPE Sergey Popovich
On Mon, Aug 18, 2014 at 02:00:16PM +0200, Alexander Demenshin wrote:
Hi,
Is there any specific reason why each instance of kernel protocol must use unique table?
Yes, because BIRD keeps some bits of data related to export of routes to the kernel table directly with routes in routing tables (flags KRF_INSTALLED, KRF_SYNC_ERROR, see krt_notify() and krt_replace_rte()). If you just force multiple tables, these bits for different kernel protocols would be mixed. E.g.: You have two kernel protocols K1 and K2 and route R whose export to K1 is accepted but to K2 is filtered. You get: 1) R appeared 2) R is exported to K1, KRF_INSTALLED flag is set for R 3) R is filtered to K2, KRF_INSTALLED flag is unset for R 4) R is removed 5) R withdraw is exported to K1, but because KRF_INSTALLED is not set, K1 do not try to remove R from the kernel and it stays here. So the modification would most likely break proper synchronization when multiple tables are used. Although periodic scans of routing tables may fix it, i wouldn't rely on that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On 2014-08-19 00:28, Ondrej Zajicek wrote:
Yes, because BIRD keeps some bits of data related to export of routes to the kernel table directly with routes in routing tables (flags KRF_INSTALLED, KRF_SYNC_ERROR, see krt_notify() and krt_replace_rte()). If you just force multiple tables, these bits for different kernel protocols would be mixed.
I see, thank you for the explanation. Then, what would be the proper way to avoid duplication of huge tables when using pipes? Sure it is (mostly) avoidable when there is only one big table, but if there are many? /Al
participants (3)
-
Alexander Demenshin -
Ondrej Zajicek -
Sergey Popovich