April 2021 - Bird-users - Mailing Lists

All BFD sessions are handled on single thread?
by Sema Boyko 20 Apr '21

20 Apr '21

Hi, I have the following configuration on one of my servers ("10.1.0.1"): *protocol bfd { interface "eth0" { min rx interval 200 ms; min tx interval 1000 ms; idle tx interval 1 s; multiplier 5; }; neighbor 10.1.0.2; neighbor 10.1.0.3; neighbor 10.1.0.4; ** ..... (here about 1000 records)* * neighbor 10.1.3.251;* * neighbor 10.1.3.252;* * neighbor 10.1.3.253;* * neighbor 10.1.3.254;* *}* And I configured the second server ("10.1.0.2") as a neighbor with the following config: *protocol bfd { interface "eth0" { min rx interval 200 ms; min tx interval 1000 ms; idle tx interval 1 s; multiplier 5; }; neighbor 10.1.0.1;}* For some reason I have random session expire events on the second server and BFD sessions get UP -> DOWN, DOWN -> UP events. *bird: bfd1: Session to 10.1.0.1 expiredbird: bfd1: Session to 10.1.0.1 changed state from Init to Downbird: bfd1: Session to 10.1.0.1 changed state from Down to Initbird: bfd1: Session to 10.1.0.1 expiredbird: bfd1: Session to 10.1.0.1 changed state from Init to Downbird: bfd1: Session to 10.1.0.1 changed state from Down to Init* This happens only if I specify a lot of neighbors in the config. For example the following config on first server ("10.1.0.1") works fine: *protocol bfd { interface "eth0" { min rx interval 200 ms; min tx interval 1000 ms; idle tx interval 1 s; multiplier 5; }; neighbor 10.1.0.2; neighbor 10.1.0.3;}* Looks like all BFD sessions are handled on a single thread. Could someone, please, confirm that BIRD isn't designed to handle a huge amount of BFD sessions simultaneously? Or possibly I can enable some options to handle this case in my env?

4 4

[PATCH] babel: Drop check for IF_MULTICAST interface flag
by Toke Høiland-Jørgensen 19 Apr '21

19 Apr '21

The babel protocol code was checking interfaces for the IF_MULTICAST flag and refusing to run if this isn't present. However, there are cases where this flag doesn't correspond to the actual capability of sending multicast packets. For instance, Wireguard interfaces on FreeBSD doesn't set the required flags, but Babel will run just fine over such an interface given the right configuration. Since we're also checking for the presence of a link-local addresses right below the flag check, we don't really need it. So let's just drop the check and trust that users will only configure Babel on interfaces that can handle the traffic. Reported-by: Stefan Haller <stefan.haller(a)stha.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4b6b9d7f9f6f..297b86b06a46 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1658,10 +1658,6 @@ babel_if_notify(struct proto *P, unsigned flags, struct iface *iface) if (!(iface->flags & IF_UP)) return; - /* We only speak multicast */ - if (!(iface->flags & IF_MULTICAST)) - return; - /* Ignore ifaces without link-local address */ if (!iface->llv6) return; @@ -1736,10 +1732,6 @@ babel_reconfigure_ifaces(struct babel_proto *p, struct babel_config *cf) if (!(iface->flags & IF_UP)) continue; - /* Ignore non-multicast ifaces */ - if (!(iface->flags & IF_MULTICAST)) - continue; - /* Ignore ifaces without link-local address */ if (!iface->llv6) continue; -- 2.31.1

2 4

CI: distro releases coverage
by Jakub Ružička 19 Apr '21

19 Apr '21

Hello, I was pleased to discover BIRD has a very good distro coverage in its [CI] (~25 different releases). [CI] https://gitlab.nic.cz/labs/bird/-/pipelines However, some latest releases are missing so I suggest adding support for following currently officially supported distros when opportunities arise: * Ubuntu 20.04 Focal Fossa - latest LTS * Ubuntu 20.10 Groovy Gorilla - latest release * Fedora 32 * Fedora 33 - latest release * Fedora 34 (optional) is already branched in preparation for release soon, you can consider enabling it too already * openSUSE 15.2 (optional) * openSUSE 15.3 - latest release * openSUSE Tumbleweed - rolling release (optional) Also, following distros are either at End of Life or close and can be removed: * Fedora 25 - 31 EOL * Ubuntu 14.04 EOL (16.04 soon) * Debian 8 is two releases and 6 years old with Debian 11 releasing soon There is nothing wrong with testing older releases as long as they don't slow down development by requiring backports and hacks. In such case it might be a better choice to simply drop support/disable CI for that EOL distro as opposed to wasting time backporting to dead platforms. Cheers, Jakub Ružička CZ.NIC packager 📦

2 1

[PATCH] BSD: Fix invalid pointer derefence in logging code
by Stefan Haller 19 Apr '21

19 Apr '21

For logging purposes a stack allocated net_addr struct was passed by value as vararg (instead of the expected pointer). This resulted in a segfault when the specific error condition got logged. --- sysdep/bsd/krt-sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index c2faa23d..ea0cc4d9 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -453,7 +453,7 @@ krt_read_route(struct ks_msg *msg, struct krt_proto *p, int scan) net_fill_ip4(&ndst, ipa_to_ip4(idst), pxlen); if ((flags & RTF_GATEWAY) && ipa_zero(igate)) - { log(L_ERR "%s (%N) - missing gateway", errmsg, ndst); return; } + { log(L_ERR "%s (%N) - missing gateway", errmsg, &ndst); return; } u32 self_mask = RTF_PROTO1; u32 alien_mask = RTF_STATIC | RTF_PROTO1 | RTF_GATEWAY; -- 2.31.1

2 1

Bird 2.0.7 and Bird 2.0.8 config comparability
by Skyler Mäntysaari 19 Apr '21

19 Apr '21

Hi there, Is it just me or does 2.0.8 bring breaking changes to config structure? The following function does not appear to work anymore. -------------------------------------------------------------- function prefix_is_bogon() { if net.type = NET_IP4 then if net ~ BOGONS_4 then return true; if net.type = NET_IP6 then if net ~ BOGONS_6 then return true; return false; } ------------------------------------------------------------- Neither does: ------------------------------------------------------------- # --- RPKI --- roa4 table RPKI4; roa6 table RPKI6; protocol rpki { roa4 { table RPKI4; }; roa6 { table RPKI6; }; remote "<snip>" port 8083; retry keep 90; refresh keep 900; expire keep 172800; } ------------------------------------------------------------------ The RPKI one complains about the roa tables.

1 1

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