How do I configure BIRD to support multiple Linux kernel routing tables?

Pre Script: I'm a BIRD n00b How do I configure BIRD to support multiple Linux kernel routing tables? I have found and tried a few different things on the web, but none seem to be doing what I want. I want to export routes from my "main" routing table (254) and an additional routing table "d

Re: How do I configure BIRD to support multiple Linux kernel routing tables?

On 02/25/2018 12:17 AM, Alexander Zubkov wrote: Hello, Hi, You need to use "kernel table" option in the kernel protocol to tell bird which table it should look into. Thank you for the suggestion. Unfortunately I'm getting "bird: /etc/bird.conf, line 9: syntax error" with the following con

Re: How do I configure BIRD to support multiple Linux kernel routing tables?

On 02/25/2018 06:01 AM, Ondrej Zajicek wrote: Hello Hi, protocol kernel { learn; export all; import all; # these are default values # table master; # kernel table 254; } table deftab; protocol kernel { learn; export all;

Re: How do I configure BIRD to support multiple Linux kernel routing tables?

On 03/07/2018 08:35 AM, Ondrej Zajicek wrote: The problem is not that 'default' is too long, but that it is a keyword, so it cannot be used as a table name. Thank you for the clarification. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature

Re: Bgp 4 peer problems, 2 peer stay in connect

On 03/07/2018 09:20 AM, Mattia Milani wrote: all external interface of the peer belong to the same network, and the address of the network is 10.0.0.0/8 that is unic. Okay. The addresses are in the same network. Are the routers connected to one common broadcast domain?

Re: Difference between loopback and dummy interfaces for use in Linux routing

On 04/27/2018 02:52 AM, Wilhelm Schuster wrote: Hi, Hi, I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. That's one of the reasons that loopbacks (or dummies) are used. Ano

Re: Difference between loopback and dummy interfaces for use in Linux routing

On 04/27/2018 10:26 AM, Wilhelm Schuster wrote: Thank you for the explanation. You're welcome. Can you give a scenario where I would want to use multiple dummy's instead of just adding/removing addresses to the loopback interface? I like the idea that lo is used exclusively by the localhost

Re: Automating BIRD configuration

On 06/19/2018 11:31 AM, Matthias Merkel wrote: We're trying to integrate BIRD with our automated DDoS detection and mitigation system. For this we need a way to have our software create static routes (to be more exact blackholes) and add BGP communities to announcements. Could you have your s

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

Re: Help with multiple routing tables.

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

Re: Help with multiple routing tables.

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 Lin

Re: Help with multiple routing tables.

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 fi

Re: Help with multiple routing tables.

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 bu

Re: generate default route and export to kernel if remote peer is up

On 09/07/2018 02:34 AM, Nikola Mitev wrote: Hi, Hi, I have a setup of ISP1 -- R1 -- LAN -- R2 -- ISP2 with BGP peerings from R1 to ISP1 and R2 to ISP2 Are your BGP neighbors advertising a default route to you? I would think that R1 and R2 would iBGP neighbors (or similar with other protoc

Re: generate default route and export to kernel if remote peer is up

On 09/08/2018 04:03 AM, Nikola Mitev wrote: Unfortunately no. I am creating the second peering now, the one which is live is through a Hurricane Electric 6in4 tunnel - it is a free service and I am not sure how much I can ask of them. Okay. I have found it's often worth while to politely ask.

Re: generate default route and export to kernel if remote peer is up

On 09/08/2018 10:11 AM, Grant Taylor wrote: If I were to try to script something like this today, I'd do it with a few timers.  The first being when the last outgoing traffic was sent and the second being when the last incoming traffic was received.  As long as the second (incoming) tim

(Re)export unreachable routes via BGP.

Is it possible to (re)export unreachable routes via BGP? I have established a pair of BGP neighbor sessions with Team Cymru Route Servers, both of which are receiving unreachable prefixes, namely bogons, like they should be. I would like to (re)export said prefixes to a different machine that

Re: (Re)export unreachable routes via BGP.

On 11/05/2018 04:55 AM, Ondrej Zajicek wrote: Hi Hi, I do not see a reason why unreachable routes would not be exported, works for me. Okay. Thank you for confirming that. It is likely something completely different. Aren't both incoming and outgoing (grant) sessions IBGP? In such case t

Re: (Re)export unreachable routes via BGP.

TL;DR: I got it working. On 11/05/2018 09:15 AM, Grant Taylor wrote: So I don't think my problem is that simple low hanging fruit. Well, you got me on the proper path. I did some more searching, found how to enable some more logging, and discovered "rejected by protocol". W

Quick yes / no question about BGP in Bird 1.x.

Does Bird 1.x support both IPv4 and IPv6 prefixes being advertised over the same BGP neighbor session, which happens to be IPv4 connected? I've not done any research about this specific question yet and I'm just hoping for a "yes it does" or "no it does not" answer. Thank you in advance. Now

Re: Quick yes / no question about BGP in Bird 1.x.

On 11/08/2018 09:39 AM, Grant Taylor wrote: Does Bird 1.x support both IPv4 and IPv6 prefixes being advertised over the same BGP neighbor session, which happens to be IPv4 connected? Thank you Ondrej and Toke. That is an exact answer to my question. I will look into a different solution, be

Re: Kernel protocol and different namespaces

On 6/7/19 12:14 PM, Maria Jan Matějka wrote: Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do. I thought, and my initial tests support, that Unix sockets are network namespace specific. # netstat

Re: Kernel protocol and different namespaces

On 6/7/19 1:19 AM, Jakub Nowacki wrote: I'm trying to figure out if it's possible to use protocol kernel to export routes to OS routing table that are in different Linux namespaces. Is this possible at all? Maybe indirectly. Do you need bidirectional synchronization of routes / routing tables

Re: Kernel protocol and different namespaces

On 6/7/19 2:33 PM, Maria Matejka wrote: It will work the same way as the BIRD control socket works. Hum. Very intriguing. Upon further investigation, it seems as if my test was flawed. I should have used -A, not -F. Thank you for the proof of concept. Aside: Unix sockets as a cross netw

Re: Kernel protocol and different namespaces

On 6/13/19 5:19 AM, Maria Matejka wrote: Yes, BIRD processes in distinct netns's are separated (in context of network) Other namespaces can influence things too. the suggested change is just to allow BGP session over Unix socket instead of TCP (to allow for route exchange without configuring

Re: Kernel protocol and different namespaces

On 6/13/19 12:52 AM, Jakub Nowacki wrote: Ok, now I have the whole picture. Having option to exchange routes between multiple BIRD processes on same box (but in different namespaces) would allow to simplify management of configuration. I don't understand what Unix sockets provide that a vEth p

Re: MultiBird on L2 - A crazy idea for Fail Over y and Load Balancing

On 1/19/21 6:48 AM, Alexander Zubkov wrote: You can use VRRP or alike protocol on L2 VRRP (and HSRP) are traditionally / inherently an Active / Passive configuration for any given instance. Conversely, GLBP is Active / Active. So, VRRP (HSRP) isn't a direct comparison for GLBP. Note: I'm

Re: MultiBird on L2 - A crazy idea for Fail Over y and Load Balancing

On 1/19/21 8:22 AM, Alexander Zubkov wrote: You can also try to bind several birds to a single address in linux (probably little patchin is required to set socket options) and linux will balance sessions between them. You might be able to get away with running the different instances of BIRD

Linux PBR and RIP

Hi, I'm facing a problem where RIP (v2) isn't originating a default route if it's not in the (kernel) table that RIP is using. The system itself is using Policy Based Routing and does have a default route in a different (kernel) table. PBR is searching multiple (kernel) tables in succession

Re: ip rule cannot match based on the source IPv4 address

On 3/19/23 4:06 AM, Brandon Zhi wrote: Hi guys, Hi, I'm doing a "split routing table" on my router, and I'm importing routes into specific kernel routing tables via bird. So I'm doing some strange routing by using ip rule. I've got systems doing similar. [root@archlinux ~]# ip -4 rule 0: