January 2024 - Bird-users

freebsd mbuf cluster leak with bird 2.14
by Thomas Steen Rasmussen 07 Feb '24

07 Feb '24

Hello :) Yesterday I had one of my FreeBSD routers stop forwarding because it ran out of mbuf clusters. It usually operates far from the limit, but there is (was) something leaking mbuf clusters bad, and I suspect it might be bird. ---- Some background: Due to a missing/misconfigured kernel export filter bird was repeatedly trying to export some routes to the kernel which the kernel already knew (from statically configured blackhole routes). So these errors have been repeating in the logs for some time (more than a year): Jan 11 19:09:04 dgncr2a bird[30963]: KRT: Error sending route 2a09:94c0::/29 to kernel: File exists Jan 11 19:10:04 dgncr2a syslogd: last message repeated 1 times Jan 11 19:10:04 dgncr2a bird[30963]: KRT: Error sending route 85.209.116.0/22 to kernel: File exists Jan 11 19:11:04 dgncr2a syslogd: last message repeated 1 times Over the holidays I upgraded from bird 2.0.9 to bird 2.14, as well as upgrading FreeBSD from 13-STABLE-384a885111ad to 13-STABLE-2cbd132986a7. I suspect one of these two changes made this problem appear. I made no changes to bird or router config other than the upgrades. ---- The mbuf cluster leak was pretty bad, like 8-10 clusters per second at a pretty steady rate. The kern.ipc.nmbclusters limit on my routers was around 2 million and I raised it to 4 million now. Since I had no idea what was causing the leak and I was desperate for a fix I at one point tried adding the missing kernel export filter (as to at least silence the noisy warnings in the logs), and imagine my surprise when the mbuf cluster leak stopped. I tried removing the filers again, the leak started again, and stopped again when I re-added the filters. It appears some combination of bird 2.14 and exporting routes already found in the kernel means leaking mbuf clusters like crazy. I have no idea if this is a bird or a freebsd problem but I have to start somewhere :) I can to some extent test stuff, but the routers are in production (BGP with 1 ebgp and 1 ibgp peer and no full table) so nothing too wild. Thanks! :) Best regards, Thomas Steen Rasmussen / Tykling

3 3

[PATCH] birdc: Do not execute cmd on non interactive help request
by Inrin 06 Feb '24

06 Feb '24

Hi! A pal of mine noticed that `echo <cmd> ? | birdc` executes the command <cmd> after showing it's help text is shown. I later confirmed that `birdcl` in comparison to `birdc` does not show this behaviour. Since this is a non intuitive side effect on birdc's side, here a proposed patch to align birdc and birdcl's behaviour. Please advise if fixing it on another part might be preferred. I chose birdc.c, to minimize the changes needed. Below a full report: -------------------------------------------- # Scenario ## Setup ./bird -l ## birdcl no side effect bird (v2.14)> echo 'restrict ?' | ./birdcl -l BIRD v2.14 ready. bird> restrict ? restrict Restrict current CLI session to safe commands bird> bird (v2.14)> ## birdc side effect bird (v2.14)> echo 'restrict ?' | ./birdc -l BIRD v2.14 ready. bird> restrict ? restrict Restrict current CLI session to safe commands bird> restrict Access restricted bird (v2.14)> # Expected behaviour Like birdcl, just show help and exit # Actual behaviour Executes the <cmd> after showing the help # Tested version BIRD v2.14 (birdc.c last edited on 2017, so I guess this is on all versions the same) --------------------------------------------

2 1

Question about MPLS L3VPN
by Marcel Menzel 27 Jan '24

27 Jan '24

Hello List, I am doing a test setup with the new MPLS L3VPN feature (for background information: I am running IPsec with L2TP on top, with OSPF as IGP and iBGP between loopbacks) with one router receiving an IPv6 fulltable via eBGP and the other one establishing the BGP session through a tunnel described above, and I noticed periodic high CPU usage on the router receiving the routes at the end of the tunnel. It seems, that BIRD keeps exporting the whole table to the kernel every 30 seconds, as it is configured in the kernel protocol scan time with the "vrf" directive set: root@sendak ~ # ip monitor | grep --line-buffered 2001:1568::/33 | gawk '{ print strftime(), $0 }' Sat Jan 27 13:21:10 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:21:40 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:22:09 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:22:37 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:23:04 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:23:30 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:23:57 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium although there's no update for that route (I'm taking here the prefix to monitor where the bird webserver lies in) received from upstream: root@lotor ~ # ip monitor | grep --line-buffered 2001:1568::/33 <empty> I set different timers on the kernel protocols because trying to debug these was just too much noise in my logs. As I don't think that this is desired behavior, has anyone else noticed this? It might also be that systemd-networkd or strongswan keeps interfering here (at least systemd-networkd shows high CPU usage when the kernel RIB changes, strongswan did this aswell but I tweaked config for it to ignore BIRD routes), but I don't see the reason why. "ManageForeignRoutingPolicyRules=no" and "ManageForeignRoutes=no" is set in networkd.conf and the ip monitor above only shows inserts. The setup without MPLS but with separate XFRM tunnels per VRF (that's why I want to use L3VPN, to just have 1 Tunnel with MPLS on top) works flawlessly. The (I think) relevant parts for the config on the 2nd router with the tunnel are: ipv4 table master4; ipv6 table master6; mpls table mtab; mpls domain mdom { label range bgprange { start 2000; length 1000; }; } vpn4 table vpntab4; vpn6 table vpntab6; ipv4 table t_as207781_ipv4; ipv6 table t_as207781_ipv6; protocol device { scan time 5; } protocol kernel { scan time 60; mpls { table mtab; export all; }; } protocol kernel { scan time 30; <- this timer causes BIRD to re-export the whole table over and over again learn; vrf "vrf-as207781"; kernel table 1; ipv6 { table t_as207781_ipv6; import none; export accept; }; } protocol ospf v3 o_mclnet_ipv6 { vrf default; ipv6 { import all; export where source ~ [ RTS_DEVICE, RTS_STATIC ]; }; area 0 { interface "l2tp*" { hello 1; type pointopoint; }; interface "br*", "dummy*" { stub; }; }; } protocol l3vpn m_as207781 { vrf "vrf-as207781"; ipv4 { table t_as207781_ipv4; }; ipv6 { table t_as207781_ipv6; }; vpn4 { table vpntab4; }; vpn6 { table vpntab6; }; mpls { label policy vrf; }; rd 64512:1; import target [(rt, 64512, 1)]; export target [(rt, 64512, 1)]; } protocol bgp i_lotor { mpls { label policy aggregate; }; vpn4 mpls { table vpntab4; import all; export all; extended next hop on; next hop self on; }; vpn6 mpls { table vpntab6; import all; export all; extended next hop on; next hop self on; }; local fd00::3 as 64512; neighbor fd00::2 as 64512; } Kind regards, Marcel Menzel

2 3

Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)
by Job Snijders 25 Jan '24

25 Jan '24

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote: > a quick stab at generating the slurm file: why use SLURM though? SLURM doesn't have a 'maxLength' field like the regular JSON input formatted in this style has: https://console.rpki-client.org/rpki.json - which might help with aggregation. More importantly, a risk I perceive with overloading RTR functionality to load IRR data into routers is in the realm of fail-safes: For RPKI-derived data, most ISPs do something along the lines of: if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject; For IRR-derived data, you'd have to do: if (roa_check(irr, net, peerasn) != ROA_VALID) then reject; The above means that suddenly your EBGP routers/route servers have a very hard dependency on the IRR RTR session being up in order to accept routes (fail closed), whereas how the RPKI-derived data is used is in a 'fail open' fashion. The above friction goes back to RPKI ROAs being defined as "if ROAs exist, all BGP routes that do not match any of the ROAs are invalid" (following the RFC 6811 algorithm), but for IRR route/route6 objects such a definition was never established, those predate the RFC 6811 algorithm. Kind regards, Job

4 9

Defines for mixed IPv6/IPv4
by Nico Schottelius 25 Jan '24

25 Jan '24

Hello bird users, I am wondering how you handle matching both IPv6 and IPv4 prefixes efficiently. We have tons of blocks in our config like these: define net_genauso_v6 = [ 2a0a:5480::/29+ ]; define net_genauso_v4 = [ 185.203.113.0/24, 185.116.114.0/24 ]; And then later we have a function that combines them like this: function is_genauso() -> bool { if ((net ~ net_genauso_v6) || (net ~ net_genauso_v4)) then { return true; } return false; } And then much later, we have various filters utilising the function, the most simple one being: filter genauso { if(is_genauso()) then accept; reject; } Which is then used in both IPv4 & IPv6 channels: protocol bgp incoming_r2ge { ... ipv6 { import filter genauso; export none; }; ipv4 { import filter genauso; export none; extended next hop on; }; } Instead of writing a wrapper function for each peer/constellation, it would be great if we could do something like that: define net_genauso = [ 2a0a:5480::/29+, 185.203.113.0/24, 185.116.114.0/24 ]; ... filter genauso { if(net ~ net_genauso) then accept; reject; } ... However as of bird 2.14, this results in the following error: bridge:~nico# bird -f -c ./bird.conf bird: ./bird.conf:208:23 Mixed IPv4/IPv6 prefixes in prefix set. So my question is, how do you usually match on the two families? Do you also write a wrapper function like above? Or do you have a smarter way? BR, Nico -- Sustainable and modern Infrastructures by ungleich.ch

6 8

BIRD at CSNOG and NANOG
by Maria Matejka 24 Jan '24

24 Jan '24

Dear BIRD Users, during the next week, you may expect our presence at CSNOG in Zlin, Czechia, where also Ondrej Zajicek is going to present about upcoming EVPN and MPLS capabilities of BIRD. This talk is expected to be in Czech. I'm also going to attend NANOG 90 in Charlotte, NC, USA; if you wish to meet me there, just catch me … or send me an e-mail in advance to arrange a meeting. Please note that we probably aren't attending NANOG 91 in Kansas City in person. See you in Zlin or in Charlotte! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

5 6

Re: Bug in bfd implementation: Wrong TTL on bfd control packets (was: Re: BFD sessions with FFR (VyOS) won't establish)
by Alexander Zubkov 20 Jan '24

20 Jan '24

Hi Lukas, Actually I saw support for TTL security in BFD code: https://gitlab.nic.cz/labs/bird/-/blob/master/proto/bfd/packets.c#L496 And I see in your config example that you use multihop BFD, but RFC you refer is talking about single-hop BFD usage. So it does not seem like a bug here. Maybe the other side does not consider this BFD sessions multihop and thus applying the TTL security policy? Regards, Alexander On Sat, Jan 20, 2024 at 11:18 AM Lukas Haase <lukashaase(a)gmx.at> wrote: > > Hi, > > After long debugging I finally figured out why Bird's bfd cannot establish a session with FRR (VyOS): Packets are sent with TTL 64. However, according to https://datatracker.ietf.org/doc/rfc5881/, Section 5: "If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255". > > This is the reason why FRR just drops packets received from bird and the session never establishes. > > As a quick workaround, I could get it working with: > > sysctl -w net.ipv4.ip_default_ttl="255" > > However, bird should set TTL appropriately. > > Is this something that was missed or is there an setting I am missing? > > Thanks, > Luke > > > > > > > Gesendet: Mittwoch, 17. Januar 2024 um 01:24 Uhr > > Von: "Lukas Haase via Bird-users" <bird-users(a)network.cz> > > An: "Alexander Zubkov" <green(a)qrator.net> > > Cc: bird-users(a)network.cz > > Betreff: Re: BFD sessions with FFR (VyOS) won't establish > > > > Hi Alexander, > > > > Thanks. I have tried > > > > sysctl -w net.ipv4.ip_local_port_range="49152 65535" > > > > but unfortunately no change. > > What I do not understand is that Interval and Timeout is wrong on the non-working peer: > > > > # birdc show bfd sess > > BIRD 2.0.8 ready. > > bfd1: > > IP address Interface State Since Interval Timeout > > 172.20.215.130 --- Up 2024-01-16 0.100 0.500 > > 172.20.215.131 --- Init 2024-01-16 1.000 10.000 > > > > Do these parameters need to be identical among peers, similar as with OSPF? Note, they are identical to my knowledge but could there be any implicit setting that causes discrepancy between the peers and would cause a connection being stuck in "Up"? For example, in bird I have "idle tx interval 500 ms" but I could not find a corresponding option in VyOS/FFR. > > > > Could you think of any tcpdump/netcat debug? > > > > Thanks, > > Luke > > > > > > > > > Gesendet: Mittwoch, 17. Januar 2024 um 00:35 Uhr > > > Von: "Alexander Zubkov" <green(a)qrator.net> > > > An: "Lukas Haase" <lukashaase(a)gmx.at> > > > Cc: bird-users(a)network.cz > > > Betreff: Re: BFD sessions with FFR (VyOS) won't establish > > > > > > Hi, > > > > > > There were reports here in the list that some BFD peers do not allow > > > connections from non-standard ports and bird do not choose source port > > > specifically. So you might need to tune your sysctl like that: > > > > > > net.ipv4.ip_local_port_range = 49152 65535 > > > > > > Not sure if this is the case, but I would try that first. > > > > > > Regards, > > > Alexander > > > > > > On Tue, Jan 16, 2024 at 9:15 AM Lukas Haase via Bird-users > > > <bird-users(a)network.cz> wrote: > > > > > > > > Hello, > > > > > > > > My BFD session between bird work fine but the ones but the ones to VyOS (which uses FFR) just won't connect: > > > > > > > > # birdc show bfd sess > > > > BIRD 2.0.8 ready. > > > > bfd1: > > > > IP address Interface State Since Interval Timeout > > > > 172.20.215.131 --- Init 10:39:14.183 1.000 10.000 > > > > 172.20.215.130 --- Up 10:42:03.901 0.100 0.500 > > > > > > > > 172.20.215.131 is here a VyOS box and its FFR config looks like: > > > > > > > > ! > > > > bfd > > > > peer 172.20.215.129 multihop local-address 172.20.215.131 > > > > detect-multiplier 10 > > > > transmit-interval 100 > > > > receive-interval 100 > > > > exit > > > > ! > > > > exit > > > > ! > > > > end > > > > > > > > > > > > For reference, my bird config is trivially: > > > > > > > > protocol bfd > > > > { > > > > interface "local-ibgp" { > > > > min rx interval 100 ms; > > > > min tx interval 100 ms; > > > > idle tx interval 500 ms; > > > > multiplier 10; > > > > }; > > > > neighbor 172.20.215.130 local 172.20.215.129 multihop; > > > > neighbor 172.20.215.131 local 172.20.215.129 multihop; > > > > } > > > > > > > > > > > > I have turned off firewall. What else could go wrong? > > > > > > > > > > > > Thanks, > > > > Luke > > > > > > >

2 1

Dynamic routing for wireguard tunnels
by Julian Zielke 20 Jan '24

20 Jan '24

Hi, I have an issue with two machines connected via GRE exchanging routes via OSPF. Both server have wireguard tunnels to the same external endpoints, so a request from an endpoint may come in through tunnel 1 to server A, forwarded to wan and the reply may enter through server B and tunnel 2 back to the endpoint. All routes are exported to a custom kernel routing table by bird2. For example: * Server A’s wireguard network is: 10.100.0.0/24 * GRE IP of server A is 10.0.1.1 * GRE IP of server B is 10.0.1.2 The problem I’m facing is, that bird2 respects the local interface route of server A but on server B, while the wireguard interface also having the same subnet (10.100.0.0/24), bird2 adds a route which says the nexthop for this subnet is through 10.0.1.1 (the GRE tunnel). I only managed to solve this by excluding the wireguard subnet with an export filter. What I am expecting (or actually want) is bird respecting the local interface route on both servers and only, if a tunnel goes offline (no peer connected), changes the route through the GRE tunnel. I’m not sure, whether a part of this solution can be done solely by using bird. I know that wireguard tunnels do not have states, so post-up/post-down stuff is out of the question. Any solutions?

1 0

BFD sessions with FFR (VyOS) won't establish
by Lukas Haase 17 Jan '24

17 Jan '24

Hello, My BFD session between bird work fine but the ones but the ones to VyOS (which uses FFR) just won't connect: # birdc show bfd sess BIRD 2.0.8 ready. bfd1: IP address Interface State Since Interval Timeout 172.20.215.131 --- Init 10:39:14.183 1.000 10.000 172.20.215.130 --- Up 10:42:03.901 0.100 0.500 172.20.215.131 is here a VyOS box and its FFR config looks like: ! bfd peer 172.20.215.129 multihop local-address 172.20.215.131 detect-multiplier 10 transmit-interval 100 receive-interval 100 exit ! exit ! end For reference, my bird config is trivially: protocol bfd { interface "local-ibgp" { min rx interval 100 ms; min tx interval 100 ms; idle tx interval 500 ms; multiplier 10; }; neighbor 172.20.215.130 local 172.20.215.129 multihop; neighbor 172.20.215.131 local 172.20.215.129 multihop; } I have turned off firewall. What else could go wrong? Thanks, Luke

2 2

Version numbers
by Ray Bellis 15 Jan '24

15 Jan '24

Hi BIRD folks! Could you please consider using consistent semantic versioning in your release numbers? (see semver.org) Up until 2.13 all releases used the x.y.z format, with a trailing .0 for the first release in each minor release. However the the 2.13 and 2.14 releases did not - they just used x.y This broke our deployment code that uses semantic version aware checks to tell whether the running daemon is not the same as the available package. A formally adopted (and documented) version numbering policy would be of great use to system administrators. thanks, Ray

4 3