- Bird-users - Mailing Lists

2.0.9 babel interfaces removed after configure
by Johannes Kimmel 27 Feb '22

27 Feb '22

Hi, with bird 2.0.9 previously configured babel interfaces are removed after `birdc configure`. To reproduce the issue I used the following config: router id 127.0.0.1; protocol device { } ipv4 table v4; ipv6 sadr table v6; protocol babel { randomize router id on; ipv4 { table v4; }; ipv6 sadr { table v6; }; interface "dummy0"; } And the following commands: # ip link add dev dummy0 type dummy # ip l set dummy0 up # birdc show babel interfaces BIRD 2.0.9 ready. babel1: Interface State Auth RX cost Nbrs Timer Next hop (v4) Next hop (v6) dummy0 Up No 96 0 2.132 :: fe80::a00c:c0ff:fe44:e43e # birdc configure BIRD 2.0.9 ready. Reading configuration from /etc/bird.conf Reconfigured # birdc show babel interfaces BIRD 2.0.9 ready. babel1: Interface State Auth RX cost Nbrs Timer Next hop (v4) Next hop (v6) # As you can see, without changing the config file, the babel interface disappears after reconfiguring bird. It was suggested to me (thanks nixxda!) that the bug may have been introduced in [1], specifically in line 1757: + if (ic && iface_is_valid(p, iface)) + ic = NULL; The issue might be a missing negation before `iface_is_valid`, though I have not confirmed it myself. Cheers, Johannes Kimmel [1]: https://gitlab.nic.cz/labs/bird/-/commit/c1511b92cc9c215224314be38c28ed8084…

2 3

2.0.9 protocol babel issue
by admin 27 Feb '22

27 Feb '22

Hi,there! I upgraded Bird to 2.0.9, but the Babel protocol could not find neighbors. my interface link is wireguard VPN. how to solve this problem? thank you! this is my configuration,bird 2.0.8 is work. protocol babel { ipv4 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; ipv6 { export where (source = RTS_DEVICE) || (source = RTS_BABEL); }; interface "gz-*"; }

4 4

Inserting fulltable into kernel FIB makes bird crazy
by Alarig Le Lay 20 Feb '22

20 Feb '22

Hello, Now that the IPv6 bug is supposed to be resolved since 5.8, I tried to upgrade a router from 4.14 to 5.10 Bird starts, however while inserting routes to FIB, I have long I/O loop cycles and at some point bird is unable to keep up. I already recompiled bird in case of a header change or something like that, and to switch to a pre-compiled kernel, neither have any effect. When bird begins to loose track of itself, I have this kind of messages: Sep 24 08:44:43 edge04-hostzealot bird: Netlink: File exists Sep 24 08:44:43 edge04-hostzealot bird: Netlink: File exists Sep 24 08:44:43 edge04-hostzealot bird: Netlink: File exists Sep 24 08:44:43 edge04-hostzealot bird: Netlink: File exists Sep 24 08:44:43 edge04-hostzealot bird: Netlink: File exists Sep 24 08:44:43 edge04-hostzealot bird: ... Sep 24 08:44:43 edge04-hostzealot bird: I/O loop cycle took 28703 ms for 1 events Sep 24 08:44:43 edge04-hostzealot bird: Kernel dropped some netlink messages, will resync on next scan. Sep 24 08:45:50 edge04-hostzealot bird: Netlink: File exists Sep 24 08:45:50 edge04-hostzealot bird: Netlink: File exists Sep 24 08:45:50 edge04-hostzealot bird: Netlink: File exists Sep 24 08:45:50 edge04-hostzealot bird: Netlink: File exists Sep 24 08:45:50 edge04-hostzealot bird: Netlink: File exists Sep 24 08:45:50 edge04-hostzealot bird: ... Sep 24 08:45:51 edge04-hostzealot bird: I/O loop cycle took 36201 ms for 1 events And then ospf begins to flap and routes are re-calculated based on remaining bgp ones. Sep 24 08:46:54 edge04-hostzealot bird: Next hop address 185.107.95.180 resolvable through recursive route for 185.107.92.0/22 (I have a way more specific route in OSPF) I activated the debug, and I can see that bird is re-scanning the entire kernel table when the “I/O loop” message appears Sep 24 09:07:30 edge04-hostzealot bird: kernel_grt_ipv4: 1.0.0.0/24: seen Sep 24 09:07:30 edge04-hostzealot bird: kernel_grt_ipv4: 1.0.4.0/24: seen And it tries to insert already inserted routes Sep 24 09:08:04 edge04-hostzealot bird: kernel_grt_ipv4: 122.76.248.0/23: installing Sep 24 09:08:04 edge04-hostzealot bird: Netlink: File exists And then OSPF is clearly going down Sep 24 09:08:04 edge04-hostzealot bird: ospf_ipv4: Inactivity timer expired for nbr 45.91.126.248 on gre4 Sep 24 09:08:04 edge04-hostzealot bird: ospf_ipv4: Neighbor 45.91.126.248 on gre4 changed state from Full to Down Sep 24 09:08:04 edge04-hostzealot bird: ospf_ipv4: Neighbor 45.91.126.248 on gre4 removed Here are some more detailed logs: https://paste.swordarmor.fr/raw/HX45 https://paste.swordarmor.fr/raw/oM9s This server isn’t the fastest one on the marked, but stuffed enough to handle full views. And with an older kernel it works very well. I have RRs running on 5.10 kernels, so it’s more likely a kernel issue, but I’m not able to determine if it’s caused by the kernel itself or by the way bird is using netlink. I’m using bird 2.0.8, I didn’t try an older version. Thanks a lot, -- Alarig Le Lay

2 3

Re: BIRD trying to reinsert existing kernel routes, netlink issue?
by Zhaofeng Li 18 Feb '22

18 Feb '22

I know this was an old thread, but would really appreciate if anyone is interested in digging in deeper. I can confirm the exact same behavior happens to me on NixOS with the 5.4.69 kernel but not on 4.19.149. BIRD 2.0.7 on 5.4.69 would incessantly attempt to insert the same routes, rendering birdc unusable as it was presumably taking up so much time in the main loop (it was receiving an IPv4 full table over iBGP as well). While it was doing that, it stopped announcing the prefixes of stub interfaces to OSPF neighbors. Thanks, Zhaofeng Li On Sun, Aug 2, 2020, at 17:36 PM, Sasha Romijn wrote: > Hello, > I’m running into a rather complex issue where BIRD tries to reinsert routes into the kernel routing table that are already in there. I’m at the point of suspecting a netlink bug in the 5.x linux kernel. However, I may be entirely off, and would like to hear what people with more BIRD and/or netlink expertise think about it. > My setup is bird 2.0.7 on Ubuntu 20.04. I’ve been able to reproduce this with the default 5.4.0-42-generic kernel as well as the ubuntu mainline 5.7.0-050700-generic kernel. This bird instance has an IBGP peering with another bird 2.0.7 instance, which sends an IPv4 full table. The IBGP peering is set up over a GRE tunnel. There is no other routing software running. I am seeing this issue on another server too, ubuntu 20.04 with 5.4.0-42-generic. A third one with ubuntu 18.04 and a 4.15.0-20-generic kernel, is fine.

3 2

BIRD incorrectly(?) detects whether a peer is directly connected
by Arsen Arsenović 17 Feb '22

17 Feb '22

Good evening! When configuring BGP on a site BIRD fails to recognize whether an IP is directly connected. It appears to scan over the list of interfaces and check whether their subnets contain the target IP instead of relying on the route table and checking whether the resulting route has a gateway attribute. This does not work in some edge cases (such as, in our case, the machine being configured for a /128 + a LAN route to avoid some Linux autoconfiguration) Perhaps a mechanism like [1] is preferable, where BIRD would query a route from the kernel and check if it has a gateway on it. This is, at least semantically, more correct, as the routing table (at least on Linux) reflects on how addresses are reached exactly, whereas the addresses associated with interfaces serve for autoconfiguration purposes. [1]: https://github.com/shemminger/iproute2/blob/a38d305d15c6a27084d5ebc1c79a831… PS: I'm unsure if my assessment of what currently happens is correct, I apologize if I got it wrong, but at any rate, it definitely fails to recognize that the peer is connected properly in our case. Thanks in advance, -- Arsen Arsenović

2 2

Debian 9, mips debian package
by Skyler Mäntysaari 17 Feb '22

17 Feb '22

Hi there, Could someone please fix up the mips branch so it could get merged someday sooner rather than later? I don't think I can do anything about the issue due to it missing the base image. https://gitlab.nic.cz/labs/bird/-/jobs/549543 Best regards, Skyler

1 0

Route Flapping and Bird - RFD and MRAI
by Douglas Fischer 16 Feb '22

16 Feb '22

Hello all. Last weeks I'm noticing the increase the increase of BGP messages on some routers that I have access to. Specially those connected to IXPs with a considerable number of participants. I Checked and the BGP process has increased a bit the use of CPU Also. So, I suspect that Route-Servers are receiving and forwarding Route Flaps from one or more participants... I know that the right place to fix that would be on the source of those flaps... But... Considering IXPs with one ou two thousand participants, there will always be someone flapping some routes. Bird is widely used as the BGP engine on IXP route-servers. And exactly because of that I came here to ask about Route Flap avoidance mechanisms on Bird. The discussion of methods to avoid Route Flapping in BGP is very controversial. - RFD - Route Flapping Dampening comes and goes. - MRAI is not a consensus, but there is a lot of effort on that, including som magic algorithms define some variable interval according to conditions. - I even saw some ultra-rigorous ideas like rate limiting the BGP messages... Before I come here to bore you with this, I searched a bit on mail list and documentation of Bird and I found the links bellow related to that: There is any work running to deal with that route-flapping question? https://bird.network.cz/ - 7.1 Future work <https://bird.network.cz/?get_doc&v=20&f=bird-7.html> Question about BGP advertisement-interval in BIRD <http://trubka.network.cz/pipermail/bird-users/2020-August/014786.html> [BGP] MRAI connection-based implementation review <http://trubka.network.cz/pipermail/bird-users/2020-April/014433.html> Route Flap Dampening <http://trubka.network.cz/pipermail/bird-users/2019-July/013589.html> [BGP] bird and RFD <http://trubka.network.cz/pipermail/bird-users/2020-May/014612.html> Thank you all! -- Douglas Fernando Fischer Engº de Controle e Automação

3 4

BIRD multithreaded progress
by Ross Tajvar 10 Feb '22

10 Feb '22

Hi BIRD team, I have been periodically checking the cz.nic blog for more posts in the "BIRD multithreading" saga, but the latest one was about 5.5 months ago ( https://en.blog.nic.cz/2021/06/14/bird-journey-to-threads-chapter-2-asynchr…) Has any more progress been made on this? I understand the team is busy and I'm not trying to push, but I enjoy reading these posts and keeping up with the work being done. Best, Ross

4 7

bird2 : announce loopack addresses in OSPFv3
by BASSAGET Cédric 08 Feb '22

08 Feb '22

Hello. I'm trying to reproduce a config which worked in bird1.6 (bird6) I need to announce the IPv4 and IPv6 loopback addresses of lo:1 protocol direct direct_lo { interface "lo"; ipv4; ipv6; } protocol ospf v3 OSPFv3_backbone { debug all; ipv6 { export where proto = "direct_lo"; }; area 0 { networks { ... }; interface "ens20" { ... }; }; } I don't know if it's normal but I have no prefixes in : bird> show protocols all direct_lo Name Proto Table State Since Info direct_lo Direct --- up 16:16:59.087 Channel ipv4 State: UP Table: master4 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 Channel ipv6 State: UP Table: master6 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 and no route exported to OSPF : bird> show route export OSPFv3_backbone bird> What am I doing wrong ? Regards

2 1

Address update causing infinite loop
by James Oakley 01 Feb '22

01 Feb '22

Hi, We've had an occasional issue where we found BIRD stuck using 100% CPU a few times over the past couple of years. Whenever it happened, all protocols stopped running and birdc was unable to communicate with the process. Unfortunately, it was usually in a situation where we could not quite see what was going so we ended up having to kill the process and restart it to get things working again. However, today it finally happened again, and I was able to grab the debug symbols for the build so I could inspect it in gdb. So here is the backtrace: (gdb) bt #0 if_recalc_preferred (i=0x56541cd48de0) at nest/iface.c:518 #1 0x000056541c662d55 in if_end_partial_update (i=i@entry=0x56541cd48de0) at nest/iface.c:359 #2 0x000056541c6b19cb in nl_parse_addr4 (new=1, scan=0, i=0x56541cc20700) at sysdep/linux/netlink.c:1020 #3 nl_parse_addr (h=h@entry=0x56541cc206f0, scan=scan@entry=0) at sysdep/linux/netlink.c:1128 #4 0x000056541c6b3127 in nl_async_msg (h=0x56541cc206f0) at sysdep/linux/netlink.c:1932 #5 nl_async_hook (sk=<optimized out>, size=<optimized out>) at sysdep/linux/netlink.c:1985 #6 0x000056541c6b74a0 in sk_read (s=s@entry=0x56541cc22700, revents=<optimized out>) at sysdep/unix/io.c:1896 #7 0x000056541c6b80ec in io_loop () at sysdep/unix/io.c:2345 #8 0x000056541c633f61 in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:939 If I keep hitting next, it appears to be stuck in a loop: (gdb) n 524 nest/iface.c: No such file or directory. (gdb) n 514 in nest/iface.c (gdb) n 517 in nest/iface.c (gdb) n 518 in nest/iface.c (gdb) n 524 in nest/iface.c (gdb) n 514 in nest/iface.c (gdb) n 517 in nest/iface.c (gdb) n 518 in nest/iface.c (gdb) n 524 in nest/iface.c (gdb) n 514 in nest/iface.c So here is what that code looks like: 510 struct ifa *a; 511 WALK_LIST(a, i->addrs) 512 { 513 /* Secondary address is never selected */ 514 if (a->flags & IA_SECONDARY) 515 continue; 516 517 if (ipa_is_ip4(a->ip)) { 518 if (!a4 || ipa_equal(a->ip, pref_v4)) 519 a4 = a; 520 } else if (!ipa_is_link_local(a->ip)) { 521 if (!a6 || ipa_equal(a->ip, ic->pref_v6)) 522 a6 = a; 523 } else { 524 if (!ll || ipa_equal(a->ip, ic->pref_ll)) 525 ll = a; 526 } 527 } OK, we are iterating over a linked link. Let's look at the list: (gdb) p i->addrs $30 = {{head_node = {next = 0x56541cd02b30, prev = 0x0}, head_padding = 0x56541cd02b30}, {tail_padding = 0x56541cd02b30, tail_node = {next = 0x0, prev = 0x56541cd02b30}}, {head = 0x56541cd02b30, null = 0x0, tail = 0x56541cd02b30}} (gdb) p i->addrs.head $31 = (struct node *) 0x56541cd02b30 (gdb) p *i->addrs.head $32 = {next = 0x56541cd02b30, prev = 0x56541cd02b30} So there is a single item, with next pointing to itself. Looking up the stack, it seems the only place here where this list is modified is when nl_parse_addr4() calls ifa_update() which then calls add_tail(), which looks like this: EXPENSIVE_CHECK(check_list(l, NULL)); ASSUME(n->prev == NULL); ASSUME(n->next == NULL); node *z = l->tail; n->next = &l->tail_node; n->prev = z; z->next = n; l->tail = n; So this is where I am stumped. How could it even be possible for the item next pointer to be set to it's own address, and not that of the static tail node? Any insights? -- James Oakley james(a)ttgi.io

2 2