December 2019 - Bird-users

Best practices for redundant iBGP/eBGP route distribution? [bird 2.0.7]
by Nico Schottelius 16 Dec '19

16 Dec '19

Good morning, I was wondering, what is the best practice is for running 2 data centers, each with one uplink and a dark fiber in between them? I think it's pretty much a standard situation, but will show our setup and assumptions as well: upstream 1 upstream 2 | | dc1--darkfiber----dc 2 Additional each DC has 2 routers: dc1: dc2: |---router1 ------- router 1 | / | / | /--------/ | router2---------router2 | | |---------------------| (both routers are connected to each other and both routers are connected to each upstream) The objective is to stay online in each DC as long as possible, so in theory: - upstream 1 can die or - upstream 2 can die or - the darkfiber can die And in each of the situations, both DCs should still be reachable from outside and both be reaching itself. Question 1: Is "direct;" is the right protocol for all links? As all links are layer 2 connections, we have configured all links to be direct. However this causes the "Invalid NEXT_HOP attribute" in various situations. Question 2: Is "next hop self ebgp;" the correct answer to the Invalid NEXT_HOP attribute? This way we rewrote routes from upstreams and generally speaking it seems to work. However, this still fails iBGP routes: router1.dc1 cannot reach a network in dc2 that is configured to be statically routed to another host in dc2. My assumption is that this is the problem of the "gateway direct" resolution, even though the documentation kind of indicates that this should be resolved via the next hop of the dc2. Originally I'd have thought that not even "next hop self ebgp" is required, as the next hop attribute is coming from the peering router, so the route should be directly reachable. Question 3: Is "not direct" (aka multiphop) the right thing for iBGP? So our dcs are directly connected vi layer 2, but the default for iBGP is multihop. If we omit the "direct" keyword, the result is that no routes are in the end imported from the other DC and that we get various warnings like the following in syslog: Dec 16 00:58:35 router2 daemon.warn bird: Next hop address 2a0a:e5c0:1:8::5 resolvable through recursive route for 2a0a:e5c0:1:8::/64 So at this stage it's a bit unclear to me, how proper iBGP redistribution / next hop resolution should work with bird. Question 4: How to (not) announce umbrella networks? So both data centers are reachable within the 2a0a:e5c0::/29 prefix and all routers have a statement route 2a0a:e5c0::/29 unreachable; in the static protocol. However if the dark fiber goes down, it is not clear that / how the upstreams should / will propagate the smaller (per DC) /48s. If we remove the full /29 announcement, we might run into the problem that a packet is being sent out through one upstream and returns back to us and thus creates a routing loop. While the last question is eBGP specific, the main question of this thread still is: how do you correctly distribute internal and external routes via iBGP in your DCs? Thanks for any hints in the right direction. Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

2 10

Prefix not making it through two iBGP sessions
by Brooks Swinnerton 14 Dec '19

14 Dec '19

Hello, I'm having trouble understanding why certain routes aren't making it through to an iBGP session on BIRD 2.0.7. My network layout looks something like below. I have three BIRD instances running, *Router 1* is connected to *Upstream 1*, *Router 2* is connected to *Upstream 2*, and *Router 1* and *Router 2* are connected to each other via iBGP. This all works great. Upstream 1 Upstream 2 ▲ ▲ | | eBGP eBGP | | Router 1 ◀--iBGP--▶ Router 2 | iBGP | ▼ Router 3 The problem comes with *Router 3* not receiving routes from *Router 2*. The iBGP export filter on router1 looks like this: export filter { if is_v4_bogon() then reject; if is_v4_default() then reject; if is_v4_peering_net() then reject; if is_v4_own_net() then accept; if source = RTS_BGP then accept; reject; }; And if I test each of these functions out manually I can see the prefix should be allowed through: bird> show route filter { if is_v4_bogon() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_default() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_peering_net() then reject; } 174.202.0.0/16 bird> show route filter { if is_v4_own_net() then accept; } 174.202.0.0/16 bird> show route filter { if source = RTS_BGP then accept; } 174.202.0.0/16 Table master4: 174.202.0.0/16 unicast [cologuard4 21:17:56.850 from 169.254.3.3] * (100) [AS22394?] dev bdr-cologuard Unfortunately if I look at the session from *Router 1* to *Router 3* (core_nyiix_14), it is not let through: bird> show route export core_nyiix_14 174.202.0.0/16 bird> I've added all of the relevant configuration in this Gist <https://gist.github.com/bswinnerton/6b7527bc9d78215275c1ae75e64d34cd>. Any help would be much appreciated.

1 1

Making bulk CLI queries / CLI performance / bird-bulk tool in Python
by Baptiste Jonglez 12 Dec '19

12 Dec '19

Hi, For a research project, I need to query routes through the Bird CLI around 10k times per second. To do this, I wrote a small Python tool that talks to the Bird CLI over its Unix socket and parses CLI replies. For anyone interested, the first version of the code is here: https://github.com/jonglezb/bird-bulk The parsing code is not terribly efficient and it would be much faster in C or Go, but it's fast enough for my needs: it can perform 17k queries per second on a Bird daemon with a full BGP view. Out of curiosity, I started several instances of my benchmark script in parallel, and Bird maxed out at 50k queries per second. This is quite impressive considering that it is loaded with almost 800k routes. Conclusion: Bird *is* efficient :) Let me know if you are interested in re-using this code, I can package it properly in pip. Regards, Baptiste

1 0

rejected by protocol <prefix> unicast
by wax xitau 11 Dec '19

11 Dec '19

Hi, Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below. The prefixes are "added" and then get "rejected" by protocol. This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table). // logs 2019-12-10 21:15:00.774 <TRACE> pe1: BGP session established 2019-12-10 21:15:00.774 <TRACE> pe1: State changed to up 2019-12-10 21:15:00.774 <TRACE> pe1: Sending END-OF-RIB 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1: Got END-OF-RIB Tcp dump of the corresponding update message(s): // tcpdump 21:18:59.652705 IP (tos 0xc0, ttl 1, id 7035, offset 0, flags [none], proto TCP (6), length 177) *192.168.254.1*.bgp > 192.168.254.0.41073: Flags [P.], cksum 0x4356 (correct), seq 83:208, ack 73, win 16384, options [nop,nop,TS val 2249949122 ecr 1355158152], length 125: BGP Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: 192.168.254.1 0x0000: c0a8 fe01 Updated routes: 10.1.12.0/24 Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: Incomplete 0x0000: 02 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: *192.168.254.1* 0x0000: c0a8 fe01 Updated routes: 10.2.34.0/24 Update Message (2), length: 23 End-of-Rib Marker (empty NLRI) The bgp session is over directly connected interfaces and the NLRI prefix next hops are therefore directly connected. // Configuration: protocol bgp pe1 { debug all; description "ebgp"; hold time 90; local 192.168.254.0 as my_asn; neighbor 192.168.254.1 as peer_asn; direct; interpret communities off; ipv4 { table t_pe1; import all; export none; gateway direct; }; } protocol device { scan time 10; }; protocol direct { ipv4; }; protocol kernel { scan time 10; learn; persist; ipv4 { import filter { if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; }; }; } // relevant show results bird> *show route protocol pe1* Table t_pe1: *10.2.34.0/24 <http://10.2.34.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500?] via 192.168.254.1 on ens5 *10.1.12.0/24 <http://10.1.12.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500i] via 192.168.254.1 on ens5 bird> bird> *show route all* Table master4: 172.16.0.11/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.1 on ens5 Type: static univ 192.168.254.2/31 unicast [direct1 20:56:03.498] * (240) dev ens6 Type: device univ 192.168.254.0/31 unicast [direct1 20:56:03.498] * (240) dev ens5 Type: device univ 192.168.255.0/24 unicast [direct1 20:56:03.498] * (240) dev ens4 Type: device univ 172.16.0.33/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.3 on ens6 Type: static univ Thanks,

4 7

Show route across multiple route tables
by Logan Rawlins 09 Dec '19

09 Dec '19

Is there a way to utilize show route where statements to look for routes across many routing tables and return all matches ? Sent from my iPhone

3 2

Need some help
by keksbg 08 Dec '19

08 Dec '19

Hello, I need some help with my BIRD configuration file. I currently cannot figure out how to fix this issue (I'm a newbie!) and most of the other people that I know that use BIRD haven't been able to help me. So here I am. Error: /etc/bird.conf:19:1 Channel not specified (Line 19 is the closing bracket of protocol static) bird.conf: 1 router id 2.235.240.1; 1 2 protocol bgp as6939 { 3 local as 207764; 4 source address 2001:470:12:a6::2; 5 ipv6 { 6 import all; 7 export filter { 8 if net ~ [2a0f:85c0:920::/48] then accept; 9 reject; 10 }; 11 graceful restart on; 12 }; 13 neighbor 2001:470:12:a6::1 as 6939; 14 } 15 16 protocol static { 17 route 2a0f:85c0:920::/48 reject; 18 } 19 20 protocol device { 21 scan time 10; 22 } Thanks in advance.

2 1

How to determine when reconfiguration is complete?
by Kenth Eriksson 04 Dec '19

04 Dec '19

Hi! How can I tell when bird is done with reconfiguration? E.g. bird can respond: "Reconfiguration in progress", but how do you know when it is ready? Invoking configure again will trigger full re-configure again I guess? Thanks, Kenth

5 16

How to unset "gw" attribute when exporting
by Yousong Zhou 03 Dec '19

03 Dec '19

Hi list, I just tried running BGP over WireGuard link and noticed that routes were exported to kernel with "via x.x.x.x" attributes. It's a L3 point-to-point link. While routing works with or without this attribute, I am wondering if there is a way to eliminate it. 10.168.222.0/24 via 169.254.169.1 dev wg1 proto bird metric 32 vs. 10.168.222.0/24 wg1 scope link I tried setting "gw = 0.0.0.0" using an export filter, but bird will complain "Invalid gw address" because 0.0.0.0 is considered as IADDR_INVALID. I am relatively new with routing daemons and protocols at the moment, so any comments are welcome. Thanks in advance. Regards, yousong

3 3

Option to not open the server-port (179)
by Lars Ekman G 01 Dec '19

01 Dec '19

Hi, We have a use-case where we want to deploy multiple BIRD instances on the same machine. The BIRD instance would be a part of public applications with their own (virtual) addreesses. These BIRD instances shall announce the application addresses (only) but not set any local routes. The goal is to deploy applications independently of each other. A problem is that BIRD requires that a server port is opened (default 179). While the port is configurable the port numbers must be different for all applications which is hard to do (to assign each application a port is ... undesirable). Another alternative is to have a central BIRD instance and invent some way for applications to communicate their addresses. While this is certainly doable it adds an unwanted complexity, especially for testing. I would like an option to not open the server-port. As an alternative I disabled the check for setting the server port to 0 (any). It is a tiny code change and removes the coordination problem. BIRD will open an ephemeral server port which is of course useless, but we can take the waste of ports. Best Regards, Lars Ekman

3 3