- Bird-users - Mailing Lists

Bird 2.0 Install
by Jason Kopacko 03 Aug '20

03 Aug '20

I am beginning to give up. As a very inexperienced Ubuntu user, I am trying to install bird 2.x. But cannot seem to figure out how to use apt-get to install anything above bird 1.6. What am I doing wrong and why is this sooooo hard? Sent from my Verizon Wireless 4G LTE Droid Turbo 2.

2 2

BIRD trying to reinsert existing kernel routes, netlink issue?
by Sasha Romijn 02 Aug '20

02 Aug '20

Hello, I’m running into a rather complex issue where BIRD tries to reinsert routes into the kernel routing table that are already in there. I’m at the point of suspecting a netlink bug in the 5.x linux kernel. However, I may be entirely off, and would like to hear what people with more BIRD and/or netlink expertise think about it. My setup is bird 2.0.7 on Ubuntu 20.04. I’ve been able to reproduce this with the default 5.4.0-42-generic kernel as well as the ubuntu mainline 5.7.0-050700-generic kernel. This bird instance has an IBGP peering with another bird 2.0.7 instance, which sends an IPv4 full table. The IBGP peering is set up over a GRE tunnel. There is no other routing software running. I am seeing this issue on another server too, ubuntu 20.04 with 5.4.0-42-generic. A third one with ubuntu 18.04 and a 4.15.0-20-generic kernel, is fine. The problem presents as follows: a few thousand routes fail insertion into the kernel routing table, marked by bird as ‘!’: ------------------------- # birdc show route table master4|grep \!|wc -l 5838 ------------------------- The number varies, but is in the order of a few thousand. However, all routes seem to be in the kernel table: ------------------------- # birdc show route count BIRD 2.0.7 ready. 788748 of 788748 routes for 788747 networks in table master4 0 of 0 routes for 0 networks in table master6 Total: 788748 of 788748 routes for 788747 networks in 2 tables # ip route|grep bird|wc -l 788748 ------------------------- When I wait a few minutes and check again, the set of failed prefixes is almost entirely different. Apparently, the previously failed prefixes have been “fixed”, but now the same problem appears with different ones. When I check a particular sample, the route really is in the kernel routing table already: ------------------------- # birdc show route 81.200.176.0/20 BIRD 2.0.7 ready. Table master4: 81.200.176.0/20 unicast [fra1 14:47:20.892] ! (100) [AS50664i] via 10.195.6.1 on tun-fra1 # ip route|grep 81.200.176.0/20 81.200.176.0/20 via 10.195.6.1 dev tun-fra1 proto bird metric 32 # birdc show route 81.200.176.0/20 BIRD 2.0.7 ready. Table master4: 81.200.176.0/20 unicast [fra1 14:47:20.892] ! (100) [AS50664i] via 10.195.6.1 on tun-fra1 ------------------------- The logs are repeats of: ------------------------- Aug 01 09:50:23 fra2 bird[83586]: Netlink: File exists Aug 01 09:50:23 fra2 bird[83586]: Netlink: File exists Aug 01 09:50:23 fra2 bird[83586]: Netlink: File exists Aug 01 09:50:23 fra2 bird[83586]: Netlink: File exists Aug 01 09:50:23 fra2 bird[83586]: Netlink: File exists Aug 01 09:50:23 fra2 bird[83586]: ... Aug 01 09:50:23 fra2 bird[83586]: I/O loop cycle took 5110 ms for 1 events ------------------------- Seemingly, bird thinks routes are not yet in the kernel routing table, tries to insert them, which fails because they are already there. Later scans move the problem to different prefixes. If I remove the tunneled IBGP peering, and set up an upstream peering on a directly connected non-tunneled peer, everything works fine. If I enable both the tunneled IBGP peering and the non-tunneled upstream, the issue does appear. The routes that are affected by the failed insertion attempts are then from both peers. The prefixes that are affected are almost entirely cases where multiple prefixes exist in the DFZ with the same network address, but different lengths. Above I mentioned seeing 81.200.176.0/20 at some point, and 81.200.176.0/24 is also in the DFZ. From two samples of failed prefixes at different points in time, about 98% are prefixes of this kind, where the DFZ contains the same network address with a different length too. This distribution is not reflected in the whole v4 full table, suggesting that routes that meet this case, are most likely to fail insertion. I have done some deeper digging with strace. https://p.6core.net/p/RtQ7xSSYd560i7FioG78ebsi is an strace of BIRD starting and loading the v4 full table from the IBGP peer. I have filtered this for “45.189.104.0” “GETROUTE” to trim down. I have the full strace, but it’s 8GB: 1. Initially, bird does GETROUTE a few times, before the BGP session is established. 2. Near the start, at 09:06:33.208648 and 09:06:33.209003, the BGP session seems established, and 45.189.104.0/24 and 45.189.104.0/22 are inserted correctly. (Acknowledgement not in paste as it does not contain the prefix.) 3. At 09:06:39.774454 bird sends to birdc that 45.189.104.0/24 is best route and inserted correctly. 4. At 09:06:49.915838, bird sends a GETROUTE. Only the reply lines that contain “45.189.104.0” are in the paste. Apparently, only 45.189.104.0/24 is included in the reply. 45.189.104.0/22 does not seem to appear in the reply to GETROUTE. 5. At 09:07:08.455767, bird tries to insert 45.189.104.0/22 into the kernel routing table. This fails, because it already exists. 6. At 09:07:43.144207 bird replies to birdc that 45.189.104.0/22 failed to insert. 7. At 09:07:49.874282, bird does another GETROUTE. Both the /22 and the /24 are included in the response. 8. At 09:08:25.623269, bird tries to update 45.189.104.0/22 which succeeds. Note the different flags from 09:07:08.455767, specifically NLM_F_EXCL vs NLM_F_REPLACE, presumably because bird is aware there is an existing route. 9. Future GETROUTEs return both the /24 and /22, bird does nothing. Working theory: netlink GETROUTE in at least some 5.x kernels may not return all routes, when at least some routes in the table have a next hop that is a tunnel interface, and this is almost entirely contained to cases where multiple prefixes exist with the same network address. Thoughts? And if that theory is correct, can we work around it in BIRD? A few things I’ve changed that had no effect: - Changing the tunnel type. - Changing the peering from IBGP to EBGP. - Using IPv6 addresses for the tunnel endpoints, and removing the static route in the config below. This is the full config I’m currently using: ------------------------- log syslog all; router id 141.98.136.36; protocol kernel { scan time 20; ipv4 { export all; import none; }; } # never route the tunnel through the tunnel protocol static tunnel_endpoints { ipv4; route 45.12.69.14/32 via 141.98.136.33; } protocol device { } # ibgp peering over GRE tunnel, ipv4 full table protocol bgp fra1 { local as 213279; source address 10.195.6.2; neighbor 10.195.6.1 as 213279; direct; ipv4 { import all; export none; }; } ------------------------- Sasha

3 3

Improper exports with BGP6 over IPv4
by Ave 31 Jul '20

31 Jul '20

Hello, I believe I stumbled upon a bug in BIRD 2.x while doing something that can only be summed up as "testing things on someone else's network with limited access provided to me". When peering over IPv4 yet exporting a full table, I am noticing that all exports, withdraw or update, are exported as withdrawals. Export side: Routes: 0 imported, 85839 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 85840 0 0 --- 85840 Export withdraws: 0 --- --- --- 0 Import side: Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 85823 0 --- 85823 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 I've also tested with an instance where there were both updates and withdrawals exported, and as a result a sum of both were displayed as imported withdrawals. The configurations I've tested with are quite simple: Full import config (seems to import "correctly", but as exports seem to be faulty it all gets recorded as withdrawals): > log syslog all; > router id 192.168.4.22; > protocol device { > scan time 5; > } > > protocol bgp bird1 { > local 192.168.4.22 as 65529; > neighbor 192.168.4.1 as 65530; > multihop; > > ipv6 { > import all; > export none; > }; > } Trimmed export config that doesn't export correctly: > protocol bgp bird2 { > local 192.168.4.1 as 65530; > neighbor 192.168.4.22 as 65529; > multihop; > > ipv6 { > import none; > export all; > }; > } Things I've so far: - Doing BGP4 over IPv4 (renaming "ipv6" blocks to "ipv4" in configs). This had no issues, exports and imports were correct. - Doing BGP4 over IPv6 (doing same change as last point, plus changing IPv4 addresses to IPv6 ones in configs). This had no issues, exports and imports were correct. - Switching from IPv4 to IPv6 (changing IPv4 addresses to IPv6 ones in configs). This resulted in proper imports, hinting that problem only happens on BGP6 over IPv4. - Exporting to a non-bird2 BGP daemon. Specifically, I exported to a mikrotik router running ROS v6.46.6. It also classified these as withdrawals ("Withdrawn Received 85 979", with empty "Prefix Count" and "Updates Received"). Thanks and I hope I'm not just doing something wrong and wasting your time as a result, Ave

2 1

Binary Bird2 for EdgeRouter (EdgeOS, Debian 9, mips)
by Skyler Mäntysaari 31 Jul '20

31 Jul '20

Dear list, Is there somewhere a repository where I can find a mips version of Bird2? SID debian repository does not support mips architecture. Best regards, Skyler Mäntysaari

3 10

Re: Bird 1.6 support for CentOS 8
by Serhii Slipenko 31 Jul '20

31 Jul '20

Hello, Sorry for reply the mail. Does anybody know plans for Bird 1.6 and Centos 8 ? My bests, Serhii Slipenko From: Serhii Slipenko <serhii.slipenko(a)open-xchange.com> Date: Monday, 27 July 2020 at 09:39 To: <bird-users(a)network.cz> Subject: Bird 1.6 support for CentOS 8 Hello, I would like to ask you about BIRD 1.6 and support of that version on Centos 8 / Debian 10. Is there some notice in the “news” section? Does it going to be supported or there is some plans to drop the support for BIRD 1.6 in Centos 8? my bests, Serhii Slipenko

1 0

suse repository for bird 2.0.7
by Farhad 29 Jul '20

29 Jul '20

Hello, Is there bird version 2 in any public repository for suse linux? Regards, Farhad

2 4

syntax error
by Farhad 27 Jul '20

27 Jul '20

Dears, I am new to bird. I am trying to follow the examples here: https://bird.network.cz/?get_doc&v=16&f=bird-6.html#ss6.2 I get syntax errors for these lines: route 10.17.3.0/24 via 10.17.3.215 bfd; table testable; in the 'protocol static' section. protocol bfd { interface "eth1" { min rx interval 20 ms; min tx interval 50 ms; idle tx interval 300 ms; }; } protocol static { table testable; export all; import all; check link; route 10.17.3.0/24 via 10.17.3.215 bfd; } Regards, Farhad

2 2

avoid transit because of default route
by Julien Sansonnens 27 Jul '20

27 Jul '20

Dear list, I only export three prefixes I own to my peers and upstreams. In theory, nothing prevents one of my peers to choose my router as default route (without my consent), and to pass his packets through my network (only in output, therefore). How to prevent this abuse? It doesn't depend on the BGP layer, but on the IP kernel isn't it ? Is it common to filter incoming IP packets according to their destination? Cheers, julien

2 1

Bird 1.6 support for CentOS 8
by Serhii Slipenko 27 Jul '20

27 Jul '20

Hello, I would like to ask you about BIRD 1.6 and support of that version on Centos 8 / Debian 10. Is there some notice in the “news” section? Does it going to be supported or there is some plans to drop the support for BIRD 1.6 in Centos 8? my bests, Serhii Slipenko Solution Engineer

1 0

export filter matches, but not announced
by micah anderson 27 Jul '20

27 Jul '20

Hi, I have a peer configured with an export filter called 'bgp_nullroute', and if I do 'birdc show route filter bgp_nullroute' i see a netblock there. I thought that would mean that this netblock would be exported/announced to the peer, but its not being exported, but there is something that I do not understand, I would appreciate a nudge in the right direction! protocol bgp nullroute { description "nullroute server"; local as ASN; source address 199.254.238.1; neighbor 192.168.1.1 as 64512; multihop 255; import filter bgp_in_nullroute; export filter bgp_nullroute; } protocol static static_nullroute { import filter static_nullroutes; include "static_nullroutes.conf"; } file static_nullroutes.conf has: route 204.13.164.220/32 blackhole; define ASN = 16652; filter bgp_nullroute { if (ASN,666) ~ bgp_community && net.len = 32 && our_network() then { accept; } else reject; } bird> show route all filter bgp_nullroute 204.13.164.220/32 blackhole [static_nullroute 09:11:08] (200) Type: static unicast univ BGP.community: (16652,666) bird> show protocols all nullroute name proto table state since info nullroute BGP master up 2020-07-23 10:01:28 Established Description: nullroute server Preference: 100 Input filter: bgp_in_nullroute Output filter: bgp_nullroute Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 802145 134 802011 --- 0 Export withdraws: 71 --- --- --- 0 BGP state: Established Neighbor address: 192.168.1.1 Neighbor AS: 64512 Neighbor ID: 192.168.1.220 Neighbor caps: refresh AS4 Session: external multihop AS4 Source address: 199.254.238.1 Hold timer: 159/180 Keepalive timer: 3/60 -- micah

3 5