- Bird-users - Mailing Lists

[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

Bird crash on interface disable
by Anes Mukhametov 01 Apr '21

01 Apr '21

Hi! Got an issue with 2.0.7. The daemon crashes on `ip link down`. Fix attached.

2 1

ignore max length as an argument of roa_check
by Pier Carlo Chiodi 31 Mar '21

31 Mar '21

Hello, first, thanks to the devs for 2.0.8! I see the option 'ignore max length' was introduced, and that it's possible to enable it at protocol configuration time. ignore max length switch Ignore received max length in ROA records and use max value (32 or 128) instead. This may be useful for implementing loose RPKI check for blackholes. Default: disabled. I was wondering what other people's feelings would be about having a similar option available at validation time, more specifically as an argument of roa_check. If my understanding is correct, being the current option available only at protocol level, it means that all the ROAs that are present inside the ROA table are used as if the maxLength attribute is not set. This means that it wouldn't be possible to configure a filter to perform a strict OV check (where the maxLength is also taken into account) using ROAs from that table. Having that option available at roa_check time, the same table could be used to perform both strict validation and also a loose validation, for example depending on the presence of the BLACKHOLE BGP community: (pseudo-code follows) # ... regular sanity checks done here... if BLACKHOLE { if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then { reject; } accept; } else { if (roa_check() = ROA_INVALID) then { reject; } accept; } (Assuming ignore_max_lenght has default value == False.) Does it make sense? Thanks Pier Carlo Chiodi

5 7