- Bird-users - Mailing Lists

BIRD 2.0.8
by Ondrej Filip 14 Apr '21

14 Apr '21

Hello! I have great news for you! My colleagues did a fantastic job and after a while we can present a new BIRD release - 2.0.8. Here is a list of changes: o Automatic channel reloads based on RPKI changes o Multiple static routes with the same network o Use bitmaps to keep track of exported routes o Per-channel debug flags o CLI commands show info from multiple protocols o Linux: IPv4 routes with IPv6 nexthops o Filter: Optimized redesign of prefix sets o Filter: Improved type checking of user filters o Filter: New src/dst accessors for Flowspec and SADR o Filter: New 'weight' route attribute o Filter: BGP path mask loop operator o Filter: Remove quitbird command o RIP: Demand circuit support (RFC 2091) o BGP: New 'allow as sets' and 'enforce first as' options o BGP: Support for BGP hostname capability o BGP: Support for MD5SIG with dynamic BGP o BFD: Optional separation of IPv4 / IPv6 BFD instances o BFD: Per-peer session options o RPKI: Allow build without libSSH o RPKI: New 'ignore max length' option o OSPF: Redesign of handling of unnumbered PtPs o OSPF: Allow key id 0 in authentication o Babel: Use onlink flag for routes with unreachable next hop o Many bugfixes Notes: Automatic channel reloads based on RPKI changes are enabled by default, but require import table enabled when used in BGP import filter. BIRD now uses bitmaps to keep track of exported routes instead of re-evaluation of export filters. That should improve speed and accuracy in route export handling during reconfiguration, but takes some more memory. Per-channel debug logging and some CLI commands (like 'show ospf neighbors') defaulting to all protocol instances lead to some minor changes in log and CLI output. Caution is recommended when logs or CLI output are monitored by scripts. So please test it, run it and write your feedback! Cheers Ondrej

15 62

Re: BIRD 2.0.8
by Jakub Ružička 14 Apr '21

14 Apr '21

On 4/14/21 4:24 PM, Ondrej Zajicek wrote: > On Wed, Apr 14, 2021 at 12:45:28PM +0200, Jakub Ružička wrote: >> Oh, I see! I checked history and this versioned requirement was added as >> part of "Bump the dephelper compatibilty level to 12" in Debian package >> which is a change specific to latest debian release. It's quite likely >> that this specific version isn't in fact required so I removed the (>= >> 1.56~) part - it's always worth a try with default available system >> init-system-helpers. I see overly strict requires like this often when >> doing cross-distro packaging. Sometimes they are introduced to dodge >> specific bug but older version might still work. > Hi, some time ago i built Debian packages for older Debians (8, 9) and > did some modifications (including decreasing debhelper compatibility > level) in order to work with unmodified system (without upgrading > init-system-helpers from Backports). It worked without problems (with > init-system-helpers >= 1.22~ requirement), but needed some modifications > to Debian control files. I've also carried out these modifications, see my other thread "BIRD 2.0.8 packaging update", specifically the opened MR: https://gitlab.nic.cz/labs/bird/-/merge_requests/25 These changes would be even more useful if scripts/make-dev-archive.sh (or equivalent script in bird repo) was adjusted to generate same archive from current git repo that is used for official tarballs - maybe you know how that's done? > > So it seems to me that in order to build packages for multiple Debian > versions the simplest way is to have multiple Debian control files. That initially looks like the simplest way but it turns out to be quite the contrary in the long run. If we maintained one branch for each currently active Fedora, Debian, and Ubuntu release we would already be at ~12 branches and that's not counting other distros and their releases. Downstream packaging is already maintained that way and it introduces noticeable burden so for upstream packaging it's easier to have shared packaging sources if possible. Knot DNS and Knot Resolver projects (as well as many others in the wild) have been using shared packaging sources successfully for quite some time and apkg is my effort to create universal standard and format for upstream cross-distro packaging. Using shared packaging files for multiple distros is certainly challenging but I assure you it's *significantly* more manageable than juggling tens of separate diverging packaging branches for each distro release(!). That work is already done by downstream packagers and duplicating it centrally in upstream brings no benefits, only huge amount of overhead. In addition to downstream packaging which is targeted and specialized for individual distro releases, upstream packaging should IMHO be as general as possible in order to work everywhere. It should allow developers to easily build and test packages from source at any point of development and on any system as well as easily provide users with fresh packages when needed (i.e. when when downstream packages aren't available yet). Cheers, Jakub

1 0

[BUG] BMP memory leak
by Macek, Dawid 14 Apr '21

14 Apr '21

Hello, We’ve built Bird from origin/bmp branch and found out that BMP most likely introduces memory leak. In the experiment, the device has 4 BGP peers (see attached bird.conf). The device is flooded with massive number of routes from each peer. Memory-usage snapshots are taken: before flooding with routes, after flooding with routes, after dropping BGP sessions and waiting for routes to be removed for Linux. The experiment was performed twice: with and without BMP configured. Case 1: With BMP configured: Before flooding: BIRD memory usage Routing tables: 20 kB Route attributes: 6224 B Protocols: 33 kB Total: 123 kB After flooding (about 1150000 routes in Linux): BIRD memory usage Routing tables: 412 MB Route attributes: 11 kB Protocols: 1473 MB Total: 1885 MB After dropping BGP sessions and waiting for routes to be removed from kernel: BIRD memory usage Routing tables: 284 kB Route attributes: 10 kB Protocols: 1018 MB Total: 1019 MB Case 2: Same config, but without protocol bmp {…}: Before flooding: BIRD memory usage Routing tables: 20 kB Route attributes: 6224 B Protocols: 26 kB Total: 112 kB After flooding (about 1130000 routes in Linux): BIRD memory usage Routing tables: 381 MB Route attributes: 11 kB Protocols: 163 MB Total: 544 MB After dropping BGP sessions and waiting for routes to be removed from kernel: BIRD memory usage Routing tables: 284 kB Route attributes: 10 kB Protocols: 795 kB Total: 1153 kB We would like to ask about code examination and pointing us towards probable cause of the issue, because we are unable to find it ourselves. Thanks in advance and regards, Dawid Macek

3 2

[BUG] stack smashing in mrt_open_file & tm_format_real_time
by Wydrych, Piotr 12 Apr '21

12 Apr '21

Hello, I think I found a bug in mrt_open_file & tm_format_real_time. On some of my systems, mrt dump crashes if the filename pattern is longer than 42B. Daemon dies with "*** stack smashing detected ***: <unknown> terminated" and no other fail messages are displayed. I'm attaching gdb's bt full. I took a look at the code and I found something that worries me. First, mrt_open_file uses 4kB buffers for path pattern and final name while tm_format_real_time uses only 32B buffer for pattern. Second, in call to strfusec, it specifies 32B buffer and length of output buffer. But please take my findings with a grain of salt, I'm not a C expert :-) Could you please verify that? Thanks, Piotr -- Piotr 'GhosT' Wydrych ........ Engineering Manager, SDN ......... Akamai ........................................................................ A: Because it messes up the order in which people normally read text. .. Q: Why is top-posting such a bad thing? ................................

2 1

Re: BIRD 2.0.8
by Jakub Ružička 12 Apr '21

12 Apr '21

Hello, On 4/10/21 3:09 PM, Benjamin Drung wrote: > Hi, > > Am Samstag, den 10.04.2021, 11:56 +0200 schrieb Vincent Bernat: >> ❦ 10 avril 2021 11:00 +02, Kees Meijs | Nefos: >> >>> Over the weekend I'll try to further prepare a .dsc that gets through >>> lintian. >>> >>> Formally only packages (and versions) in testing are allowed in >>> Backports. That is: 2.0.7-4.1 and not 2.0.8. >> You can still upload 2.0.8 in unstable. Add autopkgtest to be allowed to >> migrate. The hard freeze has not been announced yet. Maybe upstream can >> tell us if they would prefer a 2.0.7 or a 2.0.8 to be in Debian for 3 to >> 5 years. > Please don't upload 2.0.8 to unstable at this point. Debian is in hard > freeze. Only small, targeted fixes should be uploaded to unstable now. > See https://release.debian.org/bullseye/freeze_policy.html Yay, I interpreted the policy correctly \o/ > You can prepare the new version and upload to experimental if you want. Now that is a great idea, I don't know why I didn't think of that. I used experimental for knot 2.x -> 3.x migration and it was nice so I'll push my 2.0.8 changes into experimental shortly if I have rights to do that. Thanks for the suggestion! Cheers, Jakub 📦

2 2

1 out of 2 BGP sessions down, all routes become unreachable
by Dez C 12 Apr '21

12 Apr '21

Hello, First message here, although a long-time bird user (not an expert in any way). We're using bird as a bgp speaker for all our VMs that either need to announce routes or import routes from VRFs etc. The setup is pretty straight forward I'd guess. The VM has 2 IPv6 BGP sessions with 2 L3 switches (one per switch). The VM announces one /128 route and imports all routes learned from the BGP sessions. The same routes are learned from both sessions, so whenever I do a 'ip -6 r' I see 2 entries for each route (with different next hops) like: 2a02:xxxx:d00d::/45 via 2a02:xxxx:yyyy:zz::a dev eth2 proto bird metric 32 pref medium 2a02:xxxx:d00d::/45 via 2a02:xxxx:yyyy:zz::b dev eth2 proto bird metric 32 pref medium At some point, both BGP sessions went down and one of them did not recover for an hour. Normally, this should not be a problem but in this specific case, I could no longer see 2 routes in the kernel table, one reachable and another unreachable, just an unreachable one, so even though the anycast route was being announced and traffic was reaching the VM, it couldn't send the packets to their destination as all routes were unreachable in the kernel table: unreachable 2a02:xxxx:d00d::/45 dev lo proto bird metric 32 error -113 pref medium . I'm running 2.0.7 (upgrading soon) on centos7 and here's the relevant part of my config: protocol device { } protocol direct direct_v6_lo { interface "lo*"; # announce loopback ipv6; } protocol direct direct_v6_eth { interface "eth*"; ipv6; } protocol bgp bgp_v6_a { local 2a02:xxxx:yyyy:53::37 as 66666 neighbor 2a02:xxxx:yyyy:53::a as 66666; # switch A ipv6 { export where proto = "direct_v6_lo"; }; } protocol bgp bgp_v6_b { local 2a02:1388:4000:53::37 as 66666; neighbor 2a02:1388:4000:53::b as 66666; # switch B ipv6 { export where proto = "direct_v6_lo"; }; } protocol kernel { ipv6 { export filter { if proto = "direct_v6_eth" then reject; accept; }; }; merge paths limit 2; } any ideas? thanks in advance and regards, Yannis

3 4

Re: BIRD 2.0.8
by Kees Meijs | Nefos 11 Apr '21

11 Apr '21

Hi Benjamin, Thank you for your reply and good work! Don't worry: I won't break protocol in terms of the freeze. For now I focus on the testing / unstable version that you commited for a backports basis. Regards, Kees On 10-04-2021 15:09, Benjamin Drung wrote: > Hi, > > Am Samstag, den 10.04.2021, 11:56 +0200 schrieb Vincent Bernat: >> ❦ 10 avril 2021 11:00 +02, Kees Meijs | Nefos: >> >>> Over the weekend I'll try to further prepare a .dsc that gets through >>> lintian. >>> >>> Formally only packages (and versions) in testing are allowed in >>> Backports. That is: 2.0.7-4.1 and not 2.0.8. >> You can still upload 2.0.8 in unstable. Add autopkgtest to be allowed to >> migrate. The hard freeze has not been announced yet. Maybe upstream can >> tell us if they would prefer a 2.0.7 or a 2.0.8 to be in Debian for 3 to >> 5 years. > Please don't upload 2.0.8 to unstable at this point. Debian is in hard > freeze. Only small, targeted fixes should be uploaded to unstable now. > See https://release.debian.org/bullseye/freeze_policy.html > > You can prepare the new version and upload to experimental if you want. >

3 2

iproute2 identifiers >256
by Patrick Hemmer 07 Apr '21

07 Apr '21

Right now it looks like the functionality of Bird that allows using iproute2 named identifiers (e.g. /etc/iproute2/rt_table as ipt_*) is restricted to values <=256 (https://gitlab.nic.cz/labs/bird/-/blob/master/sysdep/unix/main.c#L197) However the linux kernel supports much larger values. I know it supports table identifiers up to 0xffffffff (https://github.com/torvalds/linux/blob/master/include/uapi/linux/rtnetlink.…) but I'm not sure about the others like rt_protos. Can we get Bird to allow these larger values? Thanks -- Patrick Hemmer

2 1

Minor docs issue
by Matt Corallo 03 Apr '21

03 Apr '21

Under IPv4 Flowspec, the example provided for dscp is bogus, quoted below (it mentiones lengths). dscp numbers-match Set a matching DiffServ Code Point number (e.g. length > 1500;).

2 1

Exporting routes to kernel fail with EHOSTUNREACH
by Joachim Desroches 02 Apr '21

02 Apr '21

G'morning people, I've been fighting a problem all day and thought I'd ask here out of desperation. I'll describe my setup, the problem I'm facing and what I've figured out. Setup: I have an APU running Alpine called edge1 serving as a router. It has three interfaces, a bunch of VLANs and is dual-stacked, with IPv6 as the main backbone for everything. It runs bird with OSPF and BGP in v4 and v6; each address family has it's own BGP session. Lil' edge1 is connected directly to my upstream's router over copper, the interface has an IPv4 and an IPv6 transfer address. The BGP sessions connect and the routes are correctly synced. As a multihomed customer AS, I simply import all routes and only export a few hand-picked prefixes. I import no routes from the kernel and export all routes to the kernel. Problem: I noticed my logs were filling up with warnings from bird telling me that netlink gave Host unreachable errors. I confirmed with strace that messages sent to netlink with IPv6 routes via my upstream's transfer address were replied to with an EHOSTUNREACH error msg by netlink. Trying to add the same routes by hand using `ip(8)` also fails with the same error code. Trying to add by hand using `ip(8)` routes that bird has sucessfully put in the table **also** fails with EHOSTUNREACH. What I've checked: * The upstream is up, pings, routes, etc... * Bird has the proper routes in the master6 table: it really is only the kernel that refuses to install the route. * I've rebooted the router (who knows...) * master6 contains 113338 routes, but `ip -6 r | wc -l` gives me only 8172 routes. * The kernel routing table size is big enough. If anyone has an idea, I'm starting to run out of things to try here... and I don't understand what's going on. Ave atque vale, -- Joachim Desroches

2 2