January 2022 - Bird-users

Incomplete bgp connection can close a completed bgp connection
by 生. 10 Jan '22

10 Jan '22

Hello, I have found an issue in Bird 2.0.8. If the tcp connection is not completely, then a new bgp conntection is success. When the hold timer of the first tcp connection is expired, it will close both of the connection.              router1                                        router2            192.168.1.100                      192.168.1.200 first        <----------------------------------------(tcp syn)                 -----------------------------------------> (tcp syn ack)                <---------------------------------------------(tcp ack, open) second   <---------------------------------------------> (tcp )                <---------------------------------------------> (bgp established) first holdtime expire                <---------------------------------------------   (bgp close first)                    <---------------------------------------------   (bgp close second)       The full packet is in the attachment, is this a correct operation ?

1 0

BGP strict bind socket error
by Ben Tremblay 09 Jan '22

09 Jan '22

Hi all, I have encountered a problem with how BIRD opens the listening socket for strict bind BGP. In particular, BIRD sometimes tries to open the listening socket for the protocol when the configured local IP is not yet present on the interface. It seems that BIRD will try to bind the BGP socket to the configured IP if any address exists on the protocol interface that can be used to reach the neighbor. Let me give an example to clarify. I have a minimal reproducible example with the following BGP configuration: router id 192.168.0.1; protocol device { scan time 10; } protocol bgp bgp_01 { ipv4 { import all; export all; }; debug all; local 192.168.0.1 port 179 as 1; neighbor 192.168.0.2 port 179 as 1; interface "host1"; direct; strict bind yes; } Given this configuration, I can reproduce the problem behaviour by starting the protocol with no addressing on the host1 interface and then adding an address which includes the neighbor IP in its subnet, e.g. 192.168.0.3/24. Once this address/route is added, BIRD logs the following: Jan 07 12:09:31 router03 bird[57497]: bgp_01: Neighbor ready Jan 07 12:09:31 router03 bird[57497]: bgp_01: Socket error: bind: Cannot assign requested address Jan 07 12:09:31 router03 bird[57497]: bgp_01: Cannot open listening socket And the protocol enters an error state: BIRD 2.0.6 ready. Name Proto Table State Since Info device1 Device --- up 11:55:51.049 bgp_01 BGP --- down 12:09:31.264 Error: No listening socket The reason this error is so problematic for me is that the protocol cannot recover from this state without administrative intervention (e.g. configuring bird or restarting the protocol). So, I have two questions: 1. Is this correct behaviour? 2. Can I configure BIRD so that my protocol is able to recover after suffering a socket error like this? I should also mention I can actually observe this socket error occur when adding the 'correct' address to the protocol interface, but only in the context of a larger application and only some of the time. Thanks, Ben

4 12

[BIRD 2.0.x] Netlink: ignore dead routes
by Vincent Bernat 09 Jan '22

09 Jan '22

With net.ipv4.conf.XXX.ignore_routes_with_linkdown sysctl, a user can ensure the kernel does not use a route whose target interface is down. The route is marked with a "dead"/RTNH_F_DEAD flag. Currently, BIRD still uses and distributes this route. This patch just ignores such a route. This patch could be backported to 1.6.x. Signed-off-by: Vincent Bernat <vincent(a)bernat.ch> --- sysdep/linux/netlink.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index f85bcf35685b..c28126510e6e 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -1690,6 +1690,9 @@ nl_parse_route(struct nl_parse_state *s, struct nlmsghdr *h) if (i->rtm_flags & RTNH_F_ONLINK) ra->nh.flags |= RNF_ONLINK; + if (i->rtm_flags & RTNH_F_DEAD) + return; + neighbor *nbr; nbr = neigh_find(&p->p, ra->nh.gw, ra->nh.iface, (ra->nh.flags & RNF_ONLINK) ? NEF_ONLINK : 0); -- 2.28.0

5 15

netlink filtering to avoid clostly FNHE table dumps on Linux
by Tomas Hlavacek 09 Jan '22

09 Jan '22

Hi! This is not a direct follow-up on the thread "BIRD trying to reinsert existing kernel routes, netlink issue?" ( https://www.mail-archive.com/bird-users@network.cz/msg05429.html ) but I think that the cause of my issue can be the same. My scenario: I have a server in LAB that has a public IP on a GRE tunnel interface and the tunnel goes to a router in the Internet. BIRD receives full BGP feed over the GRE tunnel. The tunnel is terminated in a VRF and BIRD exports the BGP feed to the kernel RT associated with the VRF. I observed pretty much the same set of issues as Sasha and others described in the linked thread two years ago: BIRD starts normally, BGP session comes up but after 3 or 5 minutes it max-out one CPU, mostly in sys (doing the netlink I/O). Then BIRD stops responding normally over birdc - each command takes several minutes to complete and I also saw the log messages like: Jan 2 00:00:35 lab bird: Netlink: File exists Jan 2 00:00:35 lab bird: Netlink: File exists Jan 2 00:00:35 lab bird: ... Jan 2 00:00:35 lab bird: I/O loop cycle took 73127 ms for 11 events I realized that BIRD actually transfers huge amounts of data from kernel over netlink (several gigabytes of messages per minute or so, which translates to hundreds of millions of FIB records) in the beginning of each sync and it ultimately stalls BIRD I/O long enough to miss BGP keepalive deadlines and the sessions start flapping, which makes the situation hard to understand using the conventional profiling tools, tcpdump for netlink dump etc. FYI I am attaching my quick and dirty patch to BIRD that I used to collect stats from netlink interactions to understand the problem and finally to add experimental PoC fix - see nl_request_rt_dump() in the patch. The large table that BIRD pulled from the kernel was a FNHE table where Linux collects PMTU records for *all* destination IPs that are routed to the tunnel (which does not seem to be right and I will discuss it in LKML shortly). These records have (default) 600s expiration time and in my scenario I happen to receive some backscatter traffic that in most cases gets ICMP or TCP reset responses that could ultimately create millions of these records in a few minutes. The reason why this problem occured only in Linux ~5.2+ lies in the patch https://patchwork.ozlabs.org/project/netdev/patch/8d3b68cd37fb5fddc470904cd… that changed the semantics of netlink dump requests. Now the kernel dumps the FIB Next Hop Exceptions table (previously known as route cache) alongside the RT unless the requester sets sockopt NETLINK_GET_STRICT_CHK and clear the flag RTM_F_CLONED in the dump request. BIRD does not apply the filters so the kernel dumps everything. But iproute2 and other programs that use netlink utilize the filters, so no similar performance issue occurs unless I explicitly dump the FNHE table (ip route show cache). I believe that many different types of Linux tunnels create the PMTU records for all packets transmitted over the tunnel as well. And it works like that for a long time - the code that creates the route cache (at that time, now it is FNHE table) records has been introduced in Linux 3.10 (https://elixir.bootlin.com/linux/v3.10/source/net/ipv4/ip_tunnel.c#L591) Regardless of what may or may not happen on the kernel side I think that implementing the netlink filter in BIRD to avoid the described situation makes sense. I am almost certain that my experimental fix breaks other things (most likely OSPF) but I would be glad to help make it right. What do you think? Best regards, Tomas

2 2

fix reduce/reduce conflict for rpki remote
by Alexander Zubkov 03 Jan '22

03 Jan '22

Hi, There is a reduce/reduce conflict during build because in rpki proto it is possible to specify remote both as IP or text hostname. And both in place of both tokens there can be a named constant. I added a new token type that returns a union of IP and string to use in such cases where we need something like hostname.

1 0

OSPF Configuration Guidance
by Kevin P. Fleming 02 Jan '22

02 Jan '22

This may be the wrong place to ask for this guidance, as I suspect it's more related to OSPF than to Bird, but... I've got two systems running Debian Sid (kernel 5.15, Bird 2.08-2) which are connected to a 'transport' Ethernet with two other systems running OSPF. Each of these two systems has three 'dummy' interface with IPv4 and IPv6 addresses on them, which are used for binding services (SSH, NTP, and DNS recursor). The NTP and DNS addresses are 'anycast', both systems respond to the same addresses. All of the OSPF stuff is in area 0. I've pasted the Bird configuration below. While everything is working, I'm concerned I may have chosen non-optimal ways to achieve my goals :) Goals: * Broadcast routes for the three dummy interfaces, but don't export routes for anycast addresses into the kernel routing tables. * Don't export any routes into the kernel routing tables unless they came from OSPF. ' Don't broadcast a route for the 'transport' network, as every node which needs it is directly connected. Any guidance or advice/criticism very much welcome! ------------------ router id 192.168.120.2; protocol device { scan time 60; } filter f_kernel4 { if source !~ [RTS_OSPF, RTS_OSPF_EXT2] then reject; if net.ip ~ 192.168.255.0/24 then reject; accept; } protocol kernel kernel4 { scan time 60; ipv4 { import none; export filter f_kernel4; }; } filter f_kernel6 { if source !~ [RTS_OSPF, RTS_OSPF_EXT2] then reject; if net.ip ~ 2001:470:8afe:255::/64 then reject; accept; } protocol kernel kernel6 { scan time 60; ipv6 { import none; export filter f_kernel6; }; } protocol ospf v2 ospf4 { ipv4 { import where source != RTS_DEVICE; export all; }; area 0 { interface "transport" { }; interface "mgmt" { }; interface "ntp" { }; interface "dns" { }; }; } protocol ospf v3 ospf6 { ipv6 { import where source != RTS_DEVICE; export all; }; area 0 { interface "transport" { }; interface "mgmt" { }; interface "ntp" { }; interface "dns" { }; }; } protocol static static4 { ipv4; check link; route 192.168.120.2/32 via "mgmt" { ospf_metric1 = 0; }; route 192.168.255.1/32 via "ntp" { ospf_metric1 = 0; }; route 192.168.255.2/32 via "dns" { ospf_metric1 = 0; }; } protocol static static6 { ipv6; check link; route 2001:470:8afe:120::2/128 via "mgmt" { ospf_metric1 = 0; }; route 2001:470:8afe:255::1/128 via "ntp" { ospf_metric1 = 0; }; route 2001:470:8afe:255::2/128 via "dns" { ospf_metric1 = 0; }; }

1 0

bird bug: can not parse the full-length IPv6 address
by Alexander Zubkov 01 Jan '22

01 Jan '22

Hi, I found a funny bug, when made some tests. I found out that if you try to give bird a full-length IPv6-address, like: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 1111:2222:3333:4444:5555:6666:7777:8888 You will get an error: "syntax error, unexpected BYTESTRING". I find it happens in conf/cf-lex.l because of how BYTESTRING is defined before IP6, it is too liberal to the forms of bytestrings, allowing almost arbitrary mix of ':' and digits. I suspect the idea was it allow 32-digit strings without delimters or with groups of 2 digits delimited by ':'. See proposed changes in the patch. By the way, that possibility for string literals is not documented. :) IP6 definition is also too permissive and allows some really weird things. It might have been done so intentionally to catch IPv6 typos. But in that case, it probably could be silmlified.

2 2

Re: BIRD 2.0 on FreeBSD, multihop with multiple fibs
by Dominic Blais 01 Jan '22

01 Jan '22

Hi, I've had my load of issues with bird 2 on FreeBSD. I used BSDRP like 3 years ago and after an update I started having big issues related to bird. I think BSDRP released version 1.98 with a fix for that.. don't know if it's ok in 1.99. https://sourceforge.net/projects/bsdrp/files/BSD_Router_Project/1.98/ "bird2: Fix multi-FIB usage by reverting bird commit 318acb0f6cb77a32aad5d7f79e06f3c5065ac702" Maybe it's not related but just in case... please tell me if it worked! In reponse to: Hi everyone, I hope this is not too specific... I'm running into a bit of a pickle here. This is FreeBSD 12.2 with multi-fib enabled; BIRD exporting all its received routes to fib 1, basic kernel routing in fib 0. (The service on the box is in fib 1, of course). I need to configure a multihop session where the BGP partner is not on the same interface as the box's default, but on a pni, which is behind a VLAN-tagged subinterface (i.e., bge0.300) down on a switch somewhere. Also, I can only BGP connect to the partner via the PNI. The interface has no fib tags, so it "exists" in both fibs. Let's say we are bge0.300 5.6.7.7. The other side of the PNI is at 5.6.7.8. Our BGP partner is at 1.2.3.4, reachable through 5.6.7.8. protocol static { ipv4; route 1.2.3.4/32 via 5.6.7.8; } Now, netstat tells me that 1.2.3.4/32 shows up in fib 1, but not in fib 0. BIRD only puts it in fib 1. In this setup, BIRD does not connect to 1.2.3.4 unless I manually add that host route to fib 0. Adding a % 'bge0.300' to the static route line doesn't change a thing, route still only appears in fib 1. Two questions: - why does BIRD put the route in fib 1 when no fib is specified, and the interface is not bound to a fib? - Is there a canonical way of solving this? I have the fib 0 static route configured in the system setup now, which makes it work. It would be nicer to have it thrown in there by BIRD, so the config is self-contained. Any guidance would be highly appreciated. Elmar.

2 1