November 2021 - Bird-users

Use presence of route to enable/disable BGP session
by bird21＠sensation.net.au 25 Nov '21

25 Nov '21

Hi all, I want to enable a backup BGP session (or perhaps, keep the session up and change the import/export filters) only when the main peer goes down (default disappears) Conceptually, I want to do something like this: if net = 0.0.0.0/0 then { if from = x.x.x.x then { # x.x.x.x = main peer disable backup_bgp_session; } else { enable backup_bgp_session; } } Obviously this doesn't work, since disable/enable cannot be used in the config. The logic is also a little flawed. I thought about setting a global variable in one filter, and using that variable in another to decide what to export to the backup peer, but it seems that BIRD only supports local variables? I can fudge it by using an external script to query "birdc show route 0.0.0.0/0" to check for the presense of default, and then "birdc enable backup_bgp_session" or "birdc disable backup_bgp_session" as appropriate, but I'd prefer to be able to do it within BIRD. Hope someone can give me some hints. Thanks.

3 3

bird-2.0.8 in Debian bullseye-backports
by Jakub Ružička 15 Nov '21

15 Nov '21

Hello Community, latest bird2-2.0.8 is now available from Debian bullseye-backports \o/ HOWTO get on Debian bullseye: echo "deb http://deb.debian.org/debian bullseye-backports main contrib" >> /etc/apt/sources.list apt update apt -t bullseye-backports install bird2 Cheers, Jakub Ružička CZ.NIC packager 📦

1 0

[PATCH] doc: bgp: remove "advertise ipv4"
by Simon Ruderich 13 Nov '21

13 Nov '21

The option was removed in d15b0b0a ("BGP redesign", 2016-12-07) but the documentation wasn't updated. --- doc/bird.sgml | 7 ------- 1 file changed, 7 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 39dadaf2..4e4804de 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2607,13 +2607,6 @@ using the following configuration parameters: disabled. Default: on, with automatic fallback to off when received capability-related error. - <tag><label id="bgp-advertise-ipv4">advertise ipv4 <m/switch/</tag> - Advertise IPv4 multiprotocol capability. This is not a correct behavior - according to the strict interpretation of <rfc id="4760">, but it is - widespread and required by some BGP implementations (Cisco and Quagga). - This option is relevant to IPv4 mode with enabled capability - advertisement only. Default: on. - <tag><label id="bgp-advertise-hostname">advertise hostname <m/switch/</tag> Advertise hostname capability along with the hostname. Default: off. -- 2.33.1 -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9

2 1

Contributing to BIRD
by Jan Prukner 13 Nov '21

13 Nov '21

Hello everybody, my name is Jan, I am a backend developer. I'd like to get to know BIRD's codebase. My main motivation is to improve my C language skills. I used BIRD some time ago and am interested in networking. I started reading the Coder's Doc 2.0. Do you accept contributions from people outside of CZ.NIC? If you do, what one can do to contribute? Any tasks suitable for newcommers? Cheers Jan

2 1

How to make OSPF routes not more important than "connected routes"
by Lukas Haase 13 Nov '21

13 Nov '21

Hello, This is probably fairly trivial but how can I tell bird (or Linux) that "connected routes" should have higher precedence than the routes from OSPF (even if they may be more specific)? I have the following issue: I have a bunch of connected routers, connected via /31 links. There is also a loop. Now a Mikrotik OSPF node sends me a route (that it can reach) for a station that's actually directly connected. Unfortunately the system takes the OSPF route. But of course, the directly connected interface route should always be preferred. Example: # birdc show ospf neigh BIRD 1.6.8 ready. edge1: Router ID Pri State DTime Interface Router IP 203.0.113.193 1 Full/PtP 00:36 gre1 203.0.113.255 203.0.113.194 1 Full/PtP 00:37 wg1 203.0.113.225 # birdc show route | grep '203.0.113.22\(4\|5\)' 203.0.113.224/32 dev wg1 [edge1 2021-11-12] * I (150/0) [192.168.164.183] 203.0.113.225/32 via 203.0.113.255 on gre1 [edge1 06:18:20] * I (150/110) [203.0.113.194] # ip route list | grep '203.0.113.22\(4\|5\)' 203.0.113.224/31 dev wg1 proto kernel scope link src 203.0.113.224 203.0.113.225 via 203.0.113.255 dev gre1 proto bird Here we can see that to reach 203.0.113.225 (my desired endpoint), there are two routes: 203.0.113.224/31 which is the "connected route" set up automatically by Linux when I create the interface. And "203.0.113.225 via 203.0.113.255" which I receive via OSPF from a Mikrotik router which can also see this node. Even if the OSPF one is more specific, of course, I want the local connected route to have preference. Thanks!

2 1

Bird 2.0.8 - Automatic RPKI reload behaviour
by Tiago Felipe Goncalves 05 Nov '21

05 Nov '21

Hello, I'm curious to understand how "Automatic channel reloads based on RPKI changes" works, as I've noticed that after I enabled RPKI reload, the daemon is constantly reloading the ingress policies/filters. I have set it up in the laboratory and observed that the ingress policies/filters are constantly re-processed even if the following: - We don't have RPKI RTR sessions flapping, being renegotiated, and/or changing state. - We don't have a refresh requested from/to the clients/neighbours BGP sessions. - We don't have BGP updates coming or going from/to BGP clients/neighbours at the moment that I see the ingress policy/filter being re-processed in bird2. - We don't have RPKI ROA update/changes for the specific prefix during this meantime. >From Bird doc: "BIRD offers crude automatic re-validating of affected routes after RPKI update, see option rpki reload. ... In contrast to to other filter operators, this status for the same route may change as the content of ROA tables changes. When this option is active, BIRD activates automatic reload of affected channels whenever ROA tables are updated (after a short settle time)." I sincerely expected that the automatic reload would be triggered after an event (RPKI RTR session flapping/changing state) or if the specific ROA changes (not any ROA changes). For small deployments, the extra load wouldn't be an issue, but I have deployments with 3k active clients/neighbours, and the extra load concerns me to use this function in production. The lab env is using as minimal configuration as possible, doing RPKI validation (one RTR session with routinator), and 2 clients/neighbours. I just added a "print" to ingress protocol filter to see each time that the daemon process it: Oct 26 07:21:19 bird_lab-01 bird: Reconfigured Oct 26 07:21:43 bird_lab-01 bird: Started Oct 26 07:21:48 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 07:21:48 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 07:26:43 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 07:26:43 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 07:47:21 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 07:47:21 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 08:07:52 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 08:07:52 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 08:20:39 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 08:20:39 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 08:43:35 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 08:43:35 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 09:04:07 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 09:04:07 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 09:26:56 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 09:26:56 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 09:47:28 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 09:47:28 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 10:08:00 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 10:08:00 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 10:28:36 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 10:28:36 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) Oct 26 10:51:29 bird_lab-01 bird: INGRESS FILTER => 192.168.0.0/24 => (path 65002) Oct 26 10:51:29 bird_lab-01 bird: INGRESS FILTER => 192.168.1.0/24 => (path 65003) ... bird> show proto Name Proto Table State Since Info device1 Device --- up 2021-10-26 07:21:43 kernel1 Kernel master4 up 2021-10-26 07:21:43 rpki1 RPKI --- up 2021-10-26 07:21:43 Established TEST BGP --- up 2021-10-26 07:21:47 Established TEST2 BGP --- up 2021-10-26 07:21:47 Established Configuration snippet(not production configuration): ... filter BGP_IN { RPKI_IPV4(65002); print "INGRESS FILTER => ", net, " => ", bgp_path; accept; } protocol bgp TEST from PEERS { neighbor 192.168.242.49 as 65002; ipv4 { import keep filtered on; import table yes; import filter BGP_IN; export all; next hop keep; }; } ... When/if I disable the automatic RPKI reload(comment out import table yes), this behaviour(constantly re-processing ingress filters) is gone. If possible, could you please help me to understand if this is the expected behaviour for the automatic RPKI reload? Thanks in advance! Best regards, Tiago Felipe Gonçalves PGP Fingerprint - A2:82:BD:48:EE:8D:C4:99:C2:4E:81:D4:C4:7B:1C:2E:C7:F3:04:C9

2 2

Configure BGP multihop with version 1.6.8 not working
by Wei Huang 04 Nov '21

04 Nov '21

I am testing with Bird 1.6.8 with the following setup Box 1 with interface VPP0 (192.168.1.6) ----------R--------Box 2 with interface VPP0 (192.168.2.6) Middle router R has IP address 192.168.1.1 and 192.168.2.1 The config for Box 1: table T0; # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } # Configure logging log "/home/talariuser/log/dynamic_routing.log" { debug, trace, info, remote, warning, error, auth, fatal, bug } ; router id 198.168.100.5; protocol static { table T0; check link; route 192.168.2.0/24 via 192.168.1.1; # Default route import all; export all; } protocol bgp bgp1 { table T0; import all; # Do not change this parameters without assistance gateway recursive; next hop self; local as 100; hold time 180; source address 192.168.1.6; default bgp_local_pref 100; igp metric on; neighbor 192.168.2.6 as 100; multihop 3; import all; export all; } protocol direct { table T0; interface "vpp0"; } Similar on box2. The BGP stay in connect state. When I try to do packet capture on interface "vpp0", I don't see any packets sent out. Anybody can point out what I did wrong in the config? Thanks in advance, Wei

1 0

unstable BGP sessions after debian 10 -> 11 upgrade
by Christoph 02 Nov '21

02 Nov '21

Hello, we upgraded our debian BGP routers from debian buster to bullseye. On debian 10 they used the repo https://bird.network.cz/debian/ now they use the bird2 package directly from the official debian repos, both repos contain BIRD version 2.0.7. After upgrading and rebooting we noticed that iBGP sessions are constantly dying every few minutes. The logs also show multiple of these log entries: <WARN> Kernel dropped some netlink messages, will resync on next scan. <WARN> Event ... took 31415 ms <WARN> I/O loop cycle took 31529 ms for 9 events <WARN> Netlink: File exists Especially the warning "Kernel dropped some netlink messages" was not new but we previously solved them with these sysctl.conf settings: # solves the "Kernel dropped some netlink messages, will resync on next scan." BIRD Warnings # https://bird.network.cz/pipermail/bird-users/2017-September/011542.html # (we did not change the wmem_default since this is apparently not needed) net.core.rmem_max=4194304 net.core.rmem_default=4194304 net.core.wmem_max=4194304 The most obvious change is the linux kernel version: 4.19.208 (buster) 5.10.70 (bullseye) To avoid constantly dying iBGP sessions we increased the keepalive and hold timers. Are you observing similar issues on your debian 11 systems? Does the newer kernel need higher rmem values? best regards, Christoph

3 3

BIRD 2.0 on FreeBSD, multihop with multiple fibs
by Elmar K. Bins 02 Nov '21

02 Nov '21

Hi everyone, I hope this is not too specific... I'm running into a bit of a pickle here. This is FreeBSD 12.2 with multi-fib enabled; BIRD exporting all its received routes to fib 1, basic kernel routing in fib 0. (The service on the box is in fib 1, of course). I need to configure a multihop session where the BGP partner is not on the same interface as the box's default, but on a pni, which is behind a VLAN-tagged subinterface (i.e., bge0.300) down on a switch somewhere. Also, I can only BGP connect to the partner via the PNI. The interface has no fib tags, so it "exists" in both fibs. Let's say we are bge0.300 5.6.7.7. The other side of the PNI is at 5.6.7.8. Our BGP partner is at 1.2.3.4, reachable through 5.6.7.8. protocol static { ipv4; route 1.2.3.4/32 via 5.6.7.8; } Now, netstat tells me that 1.2.3.4/32 shows up in fib 1, but not in fib 0. BIRD only puts it in fib 1. In this setup, BIRD does not connect to 1.2.3.4 unless I manually add that host route to fib 0. Adding a % 'bge0.300' to the static route line doesn't change a thing, route still only appears in fib 1. Two questions: - why does BIRD put the route in fib 1 when no fib is specified, and the interface is not bound to a fib? - Is there a canonical way of solving this? I have the fib 0 static route configured in the system setup now, which makes it work. It would be nicer to have it thrown in there by BIRD, so the config is self-contained. Any guidance would be highly appreciated. Elmar.

1 0

Redistribution from BGP protocol to OSPF is not working
by keyvan ghadimi 01 Nov '21

01 Nov '21

Hi, I have Three routers in my network like the below diagram. RTR01 has a BGP to RTR02 and RTR02 has an OSPF to RTR03. I wrote a filter to redistribute origin routes from BGP protocol to OSPF in RTR02 but it's not working. ┌───────┐ ┌───────┐ ┌─────┐ │ RTR01. ├──┤ RTR02 ├── ──┤ RTR03 │ └───────┘ └───────┘ └─────┘ 10.2.2.3 -BGP- 10.2.2.2 10.100.100.2 -OSPF- 10.100.100.3 RTR02 Bird config: protocol bgp bgp_to_rtr01{ local as 64513; neighbor 10.2.2.3 as 64512; source address 10.2.2.2; allow local as 64513; multihop; ipv4 { import all; export all; }; } protocol ospf my_ospf { rfc1583compat yes; tick 2; ecmp no; ipv4 { import where proto = "bgp_to_rtr01"; }; area 0.0.0.0 { stub no; interface "dummy0" { type ptp; }; interface "enp0s9" { type broadcast; }; }; } I did the same redistribution to OSPF to announce the default route via OSPF and it is working, but the same filter for redistribution BGP to OSPF is not. Best Regards, Keyvan

2 3