Help with multiple routing tables.
Hi, I need a second set of eyes on the following config. I feel like I've made a mistake and I'm too tired to see it. - main_rib is Linux kernel table #254 and has all locally attached interfaces. There is no default gateway in kernel table #254. - default_rib is Linux kernel table #253 and only has the default gateway. - I have a series of ip rules that cascade across multiple Linux kernel tables, 254, others, and finally 253. I want BIRD to: 1 Advertise the following routes via RIP: - Locally attached - Default learned from default_rib (253) 2 Learn routes from RIP and update main_rib (254) Currently bird is not doing #2. I'm not completely sure when I want to learn or not. I think "learn" is for BIRD to learn about the routes from the routing table. I don't know if I need to "learn" in the kernel protocol for table 254 or not. I thought the locally attached routes were picked up via the direct protocol. BIRD is learning about the single default route in default_rib (253) and advertising it via RIP to other systems on the network. Any help would be greatly appreciated. Thank you in advance. ipv4 table main_rib; ipv4 table default_rib; protocol device { } protocol kernel { ipv4 { export all; import all; table main_rib; }; kernel table 254; #learn; } protocol kernel { ipv4 { export none; import all; table default_rib; }; kernel table 253; learn; } protocol direct { ipv4; interface "*"; } protocol rip { interface "eth0", "eth1", "eth2", "eth3" { version 2; }; ipv4 { export all; import all; table main_rib; table default_rib; }; } -- Grant. . . . unix || die
Grant Taylor <gtaylor@tnetconsulting.net> writes:
Hi,
I need a second set of eyes on the following config. I feel like I've made a mistake and I'm too tired to see it.
- main_rib is Linux kernel table #254 and has all locally attached interfaces. There is no default gateway in kernel table #254. - default_rib is Linux kernel table #253 and only has the default gateway. - I have a series of ip rules that cascade across multiple Linux kernel tables, 254, others, and finally 253.
I want BIRD to: 1 Advertise the following routes via RIP: - Locally attached - Default learned from default_rib (253) 2 Learn routes from RIP and update main_rib (254)
Currently bird is not doing #2.
I'm not completely sure when I want to learn or not. I think "learn" is for BIRD to learn about the routes from the routing table. I don't know if I need to "learn" in the kernel protocol for table 254 or not. I thought the locally attached routes were picked up via the direct protocol.
BIRD is learning about the single default route in default_rib (253) and advertising it via RIP to other systems on the network.
Any help would be greatly appreciated. Thank you in advance.
ipv4 table main_rib; ipv4 table default_rib;
protocol device { }
protocol kernel { ipv4 { export all; import all; table main_rib; }; kernel table 254; #learn; }
protocol kernel { ipv4 { export none; import all; table default_rib; }; kernel table 253; learn; }
protocol direct { ipv4; interface "*"; }
protocol rip { interface "eth0", "eth1", "eth2", "eth3" { version 2; }; ipv4 { export all; import all; table main_rib; table default_rib;
A protocol instance can only be attached to a single routing table; so you'll need to use the same Bird table and steer routes into the different kernel tables using export filters instead... -Toke
On Mon, Aug 20, 2018 at 11:10:39PM -0600, Grant Taylor wrote:
Hi,
I need a second set of eyes on the following config. I feel like I've made a mistake and I'm too tired to see it.
- main_rib is Linux kernel table #254 and has all locally attached interfaces. There is no default gateway in kernel table #254. - default_rib is Linux kernel table #253 and only has the default gateway. - I have a series of ip rules that cascade across multiple Linux kernel tables, 254, others, and finally 253.
I want BIRD to: 1 Advertise the following routes via RIP: - Locally attached - Default learned from default_rib (253) 2 Learn routes from RIP and update main_rib (254)
Currently bird is not doing #2.
I'm not completely sure when I want to learn or not. I think "learn" is for BIRD to learn about the routes from the routing table. I don't know if I need to "learn" in the kernel protocol for table 254 or not. I thought the locally attached routes were picked up via the direct protocol.
Hi You are right that you should use the direct protocol, kernel 'device' routes are not learned anyway even with 'learn' option.
BIRD is learning about the single default route in default_rib (253) and advertising it via RIP to other systems on the network.
As Toke wrote, protocol (or more precisely channel) could be connected to one table. You should use a pipe to propagate routes between table and connect the RIP to one of the tables. -- 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 08/21/2018 06:44 AM, Ondrej Zajicek wrote:
Hi
Hi,
You are right that you should use the direct protocol, kernel 'device' routes are not learned anyway even with 'learn' option.
Thank you. I'll do some more reading on what "learn" does (not) do in the kernel protocol context.
As Toke wrote, protocol (or more precisely channel) could be connected to one table. You should use a pipe to propagate routes between table and connect the RIP to one of the tables.
Thank you, both of you, for your answers. It sounds like I will likely need to use a pipe to "leak" (is that the proper term?) the default route from kernel table 253 into RIP and filter the default out so that it doesn't get populated into kernel routing table 254. Please stop me if that's not the track that I should be going down. -- Grant. . . . unix || die
On 08/22/2018 04:34 PM, Grant Taylor wrote:
I'll do some more reading on what "learn" does (not) do in the kernel protocol context.
So it looks like learn is a way for BIRD to detect changes to the routing table /if/ it can identify the source of the change. I think that Linux provides the information about the source.
It sounds like I will likely need to use a pipe to "leak" (is that the proper term?) the default route from kernel table 253 into RIP and filter the default out so that it doesn't get populated into kernel routing table 254.
After (re)reading the Pipe documentation (https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.8) it seems as if I'm going to logically have three different RIBs (if that's the proper term). One for each kernel routing table (253 & 254) and the view that RIP has. I think that I will need to import from the default_rib (253) into RIP -and- filter said default from RIP so that it doesn't get into the main_rib (254). Or am I going to need a 3rd table inside of BIRD which does the following: - Imports all from main_rib (254) - Exports all to main_rib (254) EXCEPT the default. - Imports all from default_rib (253) - Exports none to default_rib (253) Please stop me if that's not the track that I should be going down. -- Grant. . . . unix || die
On Wed, Aug 22, 2018 at 05:25:33PM -0600, Grant Taylor wrote:
One for each kernel routing table (253 & 254) and the view that RIP has.
I think that I will need to import from the default_rib (253) into RIP -and- filter said default from RIP so that it doesn't get into the main_rib (254).
Or am I going to need a 3rd table inside of BIRD which does the following:
- Imports all from main_rib (254) - Exports all to main_rib (254) EXCEPT the default. - Imports all from default_rib (253) - Exports none to default_rib (253)
Hi You can do it that way, or you can have just two tables, one for main_rib+RIP and another for default_rib, connect them with pipe that allows export in the direction from default to main but not in the other one, and have export filter for kernel protocol attached to main_rib (254) configurured to accept everything EXCEPT the default route. -- 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 08/23/2018 04:42 AM, Ondrej Zajicek wrote:
Hi
Hi Ondrej,
You can do it that way, or you can have just two tables, one for main_rib+RIP and another for default_rib, connect them with pipe that allows export in the direction from default to main but not in the other one, and have export filter for kernel protocol attached to main_rib (254) configurured to accept everything EXCEPT the default route.
Thank you for your reply. Do you, or any other BIRD users, have any guidance / ProTips to suggest which method might be better long term? Does one method (two tables vs three tables) potentially run into more problems or otherwise paint me into a corner down the road? -- Grant. . . . unix || die
First: Thank you for your help Toke and Ondrej. On 08/23/2018 04:42 AM, Ondrej Zajicek wrote:
Hi
Hi,
You can do it that way, or you can have just two tables, one for main_rib+RIP and another for default_rib, connect them with pipe that allows export in the direction from default to main but not in the other one, and have export filter for kernel protocol attached to main_rib (254) configurured to accept everything EXCEPT the default route.
So I've done some more reading and thinking. I have come to the following conclusion: · Bird (routing) tables (i.e. ipv4 table main_rib) are independent of kernel (routing) tables (254). · The RIP protocol only connects to one (bird) table. · The kernel protocol (channel) connects one bird table with one kernel table through import and export filters. · The pipe protocol (channel) connect two bird tables through import and export filters. I believe I had misconstrued the bird (routing) table as being an interface to the kernel (routing) table. As such treated it like a singular entity. Now I understand that the two are separate and distinct things. All in all, I believe things are now working the way that I want them to. Here's my bird.conf file. I'm curious if anyone has any comments or ProTips. --8<-- ipv4 table bird_main; ipv4 table bird_default; filter accept_default { if net = 0.0.0.0/0 then accept; reject; } filter reject_default { if net = 0.0.0.0/0 then reject; accept; } protocol device { } protocol direct { ipv4; interface "*"; } protocol kernel { ipv4 { table bird_main; export filter reject_default; import all; }; kernel table 254; learn; } protocol kernel { ipv4 { table bird_default; export none; import filter accept_default; }; kernel table 253; } protocol rip { interface "eth0", "eth1", "eth2", "eth3" { version 2; }; ipv4 { export all; import all; table bird_main; }; } protocol pipe { table bird_main; peer table bird_default; export none; import filter accept_default; } -->8-- -- Grant. . . . unix || die
participants (3)
-
Grant Taylor -
Ondrej Zajicek -
Toke Høiland-Jørgensen