- Bird-users - Mailing Lists

annoying log, received route with strange next hop, Netlink File exists
by LIU Chris 08 Jan '25

08 Jan '25

Classified as: {Hitachi Rail - Public} Basically configured bird as below protocol device { scan time 10; } protocol kernel { scan time 10; learn; ipv4 { export filter XXXX; } } bgp and bfd are established, everything is fine. But only have some annoying log: Every 10 seconds to print below bird log, assuming this is caused by kernel protocol scan time 10. But why Netlink : File exists, it would write to kernel ??? KRT: Received route xx.yy.zz.0/24 with strange next-hop 10.0.0.1 Netlink: File exists Chris {Hitachi Rail - Public}

2 2

first (?) bird 3.0.0 bug report
by Radu Anghel 08 Jan '25

08 Jan '25

Hi, Using a slightly modified version of the config from the 2.15.1 (just some {} inside case structures), but probably unrelated. If bird gets killed/not shut down properly and routes remain in the kernel then bird 3.0.0 is unable to restart and just segfaults when trying to refresh kernel routes. I can reproduce it by just kill -9 bird && restarting bird. daemon.debug bird: KERNEL6.ipv6: route refresh begin: rr 1 set 1 valid 0 pruning 0 pruned 0 kern.info kernel: [75645.964935] bird[4162]: segfault at 0 ip 000000000045d47b sp 00007ffcb9f9f2c0 error 4 in bird[403000+a8000] likely on CPU 1 (core 0, socket 1) kern.info kernel: [75645.970115] Code: 5d 41 5c 41 5d 41 5e 41 5f c3 55 53 48 89 fb 48 83 ec 38 80 bb 79 02 00 00 04 48 8b 7f 30 75 46 48 89 d5 31 d2 e8 63 a4 ff ff <83> 38 00 49 89 c0 75 07 31 c0 e9 9d 00 00 00 48 8b 40 10 48 8d 7b The kernel protocol config is: protocol kernel KERNEL6 { debug { events, states }; scan time 3600; merge paths on; metric 0; ipv6 { import filter KERNEL_IN; export filter KERNEL_OUT; }; } Cheers, R

4 11

Bird 2.16 ASPA issue
by Jelle Luteijn 08 Jan '25

08 Jan '25

Hoi, Yesterday I tried to implement the validation of ASPA in my router filters. I have generated the ASPA table via the mainline version of RPKI-Client, docker image rpki/rpki-client:edge to be precise. For Bird I use version 2.16 provided from https://pkg.labs.nic.cz/. When loading the bird configuration with the new table I get the following error: /etc/bird/rpki2/bird:642145:17 syntax error, unexpected PROVIDERS this line is: route aspa 945 providers 174, 6461, 6939, 7018, 9002, 32097, 401111; (full table provided below) I tested this yesterday with Job Snijders. He told me that when bird 2.16 is compiled from source it does work, and he was able to replicate the issue with the packages from the repository. I prefer not to compile the software myself and to use vendor provided packages. Does somebody know what’s going on? Regards, Jelle Luteijn --- define force_roa_table_update = 1736147917; aspa table ASPAS; #ROAs are removed from snippet due to size protocol static { aspa { table ASPAS; }; route aspa 945 providers 174, 6461, 6939, 7018, 9002, 32097, 401111; route aspa 970 providers 54874; route aspa 11358 providers 835, 924, 6939, 20473, 34927; route aspa 13852 providers 6939, 20473, 34927, 52025, 209533; route aspa 15562 providers 2914, 8283, 51088, 206238; route aspa 16909 providers 20473, 21738, 34927, 47272, 53356, 53667, 152900, 209643, 212477; route aspa 19330 providers 393577; route aspa 21957 providers 970; route aspa 28584 providers 28605; route aspa 33733 providers 174, 6939, 12186, 47787, 200454; route aspa 40544 providers 924, 6939, 12186, 52025; route aspa 41720 providers 174, 1299, 9002, 50877, 60068, 203446, 212508; route aspa 44324 providers 945, 955, 1299, 3204, 6939, 7720, 8772, 8849, 15353, 18041, 20473, 29632, 32595, 34465, 34927, 41051, 43426, 47272, 48266, 51087, 53667, 53808, 59105, 59538, 61112, 134823, 134835, 138997, 139317, 150452, 151364, 199545, 199765, 200105, 206499, 207656, 207841, 209554, 209735, 212483, 213856; route aspa 44355 providers 207841; route aspa 47272 providers 174, 835, 924, 1299, 6830, 6939, 20473, 21738, 25759, 34927, 35133, 41051, 48605, 50391, 50917, 52025, 52210, 58057, 210667, 212514, 212895; route aspa 47689 providers 924, 1299, 6939, 21738, 34465, 34549, 34927, 395823; route aspa 48070 providers 174, 1299; route aspa 48606 providers 30893, 54681, 57974, 59678, 210691, 212276; route aspa 50224 providers 6939, 15353, 26930, 34465, 37988, 50104, 52025, 52210, 59920, 60841, 210475, 400304; route aspa 50391 providers 6939, 20473, 48070; route aspa 50555 providers 970; route aspa 51019 providers 6939, 34549, 34927, 52025, 207841; route aspa 51396 providers 6939, 30823, 35133, 44066, 44592, 49581, 60223, 64457, 203446, 214497, 214995, 215436; route aspa 52025 providers 174, 835, 906, 917, 924, 1299, 3257, 6204, 6939, 7720, 8860, 12186, 18041, 20473, 21700, 21738, 25369, 29802, 32097, 34549, 34927, 35133, 35661, 36369, 37988, 39409, 47787, 48070, 48605, 50917, 51519, 52210, 56655, 57695, 61138, 64289, 197216, 199545, 208453, 209022, 209533, 394177, 396998, 397423, 400304, 400587; route aspa 52210 providers 174, 835, 6939, 52025, 62513, 210667; route aspa 54148 providers 835, 924, 6939, 20473, 21738, 34927, 37988, 47272, 50917, 53616, 53667, 207841, 209022, 209735; route aspa 54218 providers 917, 16509, 35487, 37988, 53667, 57196, 59678; route aspa 56762 providers 47689; route aspa 57984 providers 8283, 48112, 206763; route aspa 59678 providers 6939, 34927, 54218, 55081; route aspa 60223 providers 945, 49581; route aspa 60431 providers 34927, 41495, 50917; route aspa 60841 providers 30456, 400304; route aspa 149301 providers 20473, 61138; route aspa 151642 providers 20473, 61138; route aspa 198136 providers 0; route aspa 199310 providers 44324, 134835, 138997, 139317, 202662, 204844, 212895, 215828; route aspa 199376 providers 47311, 61112, 150249, 151544, 199762, 209533, 215379; route aspa 199762 providers 945, 6939, 8849, 15353, 34927, 44817, 47311, 48605, 140731, 150249; route aspa 200242 providers 835, 6939, 21738, 34465, 34927, 52025, 52041, 59678, 60841, 208453, 210475; route aspa 200351 providers 34927, 47272, 209022, 210475; route aspa 200454 providers 174, 6424, 6939, 9186, 12186; route aspa 202076 providers 207960; route aspa 202359 providers 30740, 33920, 41495; route aspa 202881 providers 205329; route aspa 203236 providers 20473, 44324, 53667, 53808, 200105, 201217, 203314, 213856; route aspa 203619 providers 200454; route aspa 203843 providers 6939, 20473, 53667; route aspa 204857 providers 50224, 59920, 60841, 400304; route aspa 204931 providers 34927, 44103, 207656; route aspa 205329 providers 945, 983, 6939, 7720, 8894, 9409, 20473, 34927, 41051, 131657, 134823, 151364; route aspa 205603 providers 38008, 38074, 59105; route aspa 205663 providers 20473, 61138; route aspa 205789 providers 200242, 207960; route aspa 205848 providers 1299, 6939, 34549, 34927, 52025, 209022; route aspa 207487 providers 20473; route aspa 207841 providers 6939, 137409; route aspa 207960 providers 6939, 20473, 34854, 34927, 136620, 202359, 207968; route aspa 209735 providers 6939, 207841; route aspa 210561 providers 207960; route aspa 212068 providers 6939, 13237, 62240, 207960; route aspa 212245 providers 917, 57695, 212068; route aspa 212516 providers 3204, 6939, 41720; route aspa 212934 providers 835, 6939, 34927, 52210, 53667, 61138, 62513, 209533, 210667; route aspa 213915 providers 215147, 215828; route aspa 214498 providers 16276, 207841; route aspa 215085 providers 35133, 42093, 52025; route aspa 215131 providers 8283, 34927, 212477; route aspa 215147 providers 34927, 41108, 47263, 207252, 213915, 215828; route aspa 215368 providers 207841; route aspa 215436 providers 6762, 6939, 51396, 60223; route aspa 215664 providers 1299, 3204, 6939, 34549, 41720, 56382, 203446, 212508; route aspa 215778 providers 8772, 29632, 39249, 41051, 207656, 209533; route aspa 215828 providers 6204, 6939, 8772, 29390, 29632, 34465, 34927, 39249, 41051, 44592, 48752, 50917, 51019, 51202, 58057, 62403, 152726, 197071, 199524, 203686, 207656, 209533, 210464, 211358, 215147, 216324, 216360, 393577; route aspa 215849 providers 215828; route aspa 216107 providers 924, 6939, 16509, 20473, 21738, 34927, 63473, 209022, 211588; route aspa 216265 providers 202673, 215051; route aspa 216311 providers 6939, 13852, 20473, 34927, 52025; route aspa 267386 providers 6939, 25933, 28220, 28649, 267613; route aspa 270470 providers 53062; route aspa 393577 providers 1299, 6939, 32097, 40676, 137409; route aspa 401111 providers 1012, 2497, 17676; route aspa 401507 providers 53356, 212477; }

4 8

[patch] update documentation
by Job Snijders 07 Jan '25

07 Jan '25

RFC 8203 was replaced by RFC 9003; BIRD supports 9003 since 2019. While there add Send Hold Timer to the list. diff --git doc/bird.sgml doc/bird.sgml index d1b90a1d..54c7d207 100644 --- doc/bird.sgml +++ doc/bird.sgml @@ -2169,8 +2169,9 @@ avoid routing loops. <item> <rfc id="7911"> - Advertisement of Multiple Paths in BGP <item> <rfc id="7947"> - Internet Exchange BGP Route Server <item> <rfc id="8092"> - BGP Large Communities Attribute -<item> <rfc id="8203"> - BGP Administrative Shutdown Communication <item> <rfc id="8212"> - Default EBGP Route Propagation Behavior without Policies +<item> <rfc id="9003"> - Extended BGP Administrative Shutdown Communication +<item> <rfc id="9687"> - Border Gateway Protocol 4 (BGP-4) Send Hold Timer </itemize> <sect1>Route selection rules diff --git proto/bgp/bgp.c proto/bgp/bgp.c index b26e5e87..b74239b4 100644 --- proto/bgp/bgp.c +++ proto/bgp/bgp.c @@ -97,8 +97,8 @@ * RFC 7911 - Advertisement of Multiple Paths in BGP * RFC 7947 - Internet Exchange BGP Route Server * RFC 8092 - BGP Large Communities Attribute - * RFC 8203 - BGP Administrative Shutdown Communication * RFC 8212 - Default EBGP Route Propagation Behavior without Policies + * RFC 9003 - Extended BGP Administrative Shutdown Communication * draft-ietf-idr-bgp-extended-messages-27 * draft-ietf-idr-ext-opt-param-07 * draft-uttaro-idr-bgp-persistence-04 @@ -1623,7 +1623,7 @@ bgp_shutdown(struct proto *P) bgp_store_error(p, NULL, BE_MAN_DOWN, 0); p->startup_delay = 0; - /* RFC 8203 - shutdown communication */ + /* RFC 9003 - shutdown communication */ if (message) { uint msg_len = strlen(message); diff --git proto/bgp/packets.c proto/bgp/packets.c index 2b7ee1d0..e3dec2e4 100644 --- proto/bgp/packets.c +++ proto/bgp/packets.c @@ -2946,7 +2946,7 @@ bgp_error_dsc(uint code, uint subcode) return buff; } -/* RFC 8203 - shutdown communication message */ +/* RFC 9003 - shutdown communication message */ static int bgp_handle_message(struct bgp_proto *p, byte *data, uint len, byte **bp) { @@ -2995,7 +2995,7 @@ bgp_log_error(struct bgp_proto *p, u8 class, char *msg, uint code, uint subcode, goto done; } - /* RFC 8203 - shutdown communication */ + /* RFC 9003 - shutdown communication */ if (((code == 6) && ((subcode == 2) || (subcode == 4)))) if (bgp_handle_message(p, data, len, &t)) goto done;

1 1

IPV6 connectivity issue
by Julien Sansonnens 06 Jan '25

06 Jan '25

Dear all, I'm experincing a nasty problem with IPV6 for some time. I'm certainly missing something obvious, don't blame me, I'm still learning :) I'm using bird 2.0.12 under debian 12 as a router. This router (VPS) has a working IPV6 connectivity via the VPS provider. I own an ipv6 prefix in the form 2a06:xxxxxxxxxx/44 This prefix is correctly exported to the rest of the world, so my network is reachable from the outside. I've assigned a /128 address from this range to the lo interface, and when I ping from outside, it works. I now want my router to use the IPs of my own prefix, rather than those belonging to my VPS provider. to do this, I set the “krt_prefsrc” parameter in bird. Now here is the issue: - If bird isn't running, I can ping IPV6 nodes outside my network. Fine. The source address belongs to the VPS provider prefix - When I run bird using my own IP as source, pinging TO the outside no longer works. But pinging FROM the outside still works. I receive a full IPV6 table from my upstream and the routes are correct. So it's (probably ?) not a routing problem. Everything is routed to the ipv6 gateway (my BGP neighbor) The ping also produces no error messages. I just have to cancel it with CTRL-C, and it shows 100% lost packets. I don't know where the packets get lost. I have no firewall configured. Could the problem be that my source IP address (which comes from my own prefix) is not in the same network as the IPV6 gateway (which comes from the VPS provider)? Thanks for your help Julien

2 1

doc: flow6 label should be numeric op, not bitmask
by Eric Long 31 Dec '24

31 Dec '24

Hi, In User's Guide Section 6.6 (Protocol :: Static) [0], IPv6 flowspec's flow label component is documented as: > label bitmask-match > > Set a 20-bit bitmask for matching Flow Label field in packets (e.g. > label 0x8e5/0x8e5). However in RFC 8956 (Dissemination of Flow Specification Rules for IPv6) as well as earlier drafts it should be followed by numeric operators instead of bitmasks. Source code seems to be correct [2], though. p.s. Could BGP's "supported standards" replace RFC 5575 with 8955/8956? Cheers, Eric [0]: https://bird.network.cz/?get_doc&v=30&f=bird-6.html#ss6.16 [1]: https://www.rfc-editor.org/rfc/rfc8956.html#name-type-13-flow-label-new [2]: https://gitlab.nic.cz/labs/bird/-/blob/96dc63d602016c38f43677b2f95705aee9dc…

1 0

second (?) bug in 3.0.0
by Job Snijders 30 Dec '24

30 Dec '24

Second bug? :-) bird: 2024-12-18 15:01:29.251 [0001] <INFO> Started bird: 2024-12-18 15:01:34.615 [0001] <BUG> Trying to lock in a bad order: 00007fff17afd6e0 000079af687be298 seems to trigger when peers connect config: router id 10.10.255.254; protocol device { } protocol direct { disabled; } protocol kernel { ipv4 { import none; export none; }; } log stderr all; protocol bgp everything { local as 1000; neighbor range 10.0.0.0/8 external; connect delay time 1; ipv4 {import all; export all; next hop self; import table on;}; }

2 3

freebsd : how to allow loopback nexthop in OSPFv3-IPv4 ?
by benoitc＠enki-multimedia.eu 26 Dec '24

26 Dec '24

Hi all, I would like te to use the new feature "allow loopback nexthop in OSPFv3-IPv4 " on freebsd but I am not sure about the configuration. Let say 2 machines are linked to each others via a vlan. Should I pass the vlan as ptp or stub on freebsd ? Or is there any other way to have unnumbered interfaces on freebsd? Eg for the interface vlan330: protocol ospf v3 ospfv4 { ipv4 { import filter ospf_import; export filter ospf_export; }; area 0 { interface "lo1" { stub yes; }; interface "vlan330" { type ptp; cost 25; }; }; } Is this configuration correct? Benoît

2 2

another bug
by Radu Anghel 19 Dec '24

19 Dec '24

Another one: Since killing bird is now safe-ish, I added one more bird3 to the party. Then I tried killing the first bird again. This caused the new bird3 to get stuck with BGP into Flush: BGP_IPv4 BGP --- flush 2024-12-19 16:35:08 Flush Socket: Connection reset by peer BGP_IPv6 BGP --- flush 2024-12-19 16:35:06 Flush Socket: Connection reset by peer No errors are logged on this second bird after the "Connection reset by peer" stuff, the first bird is retrying to connect, I see that with tcpdump. birdc restart BGP_IPvx does nothing birdc [dis|en]able BGP_IPvx also changes nothing Some more info about this new bird: - it is a RR so iBGP - has MD5 enabled for the sessions - import/export tables on - extended messages on - add paths on Tried it with killing multiple bird2s instead of bird3-bird3: - the ones with low number of routes (in my case <10k) do not get stuck Flushing - the ones with one (or more) full tables get stuck Flushing on the RR Killing birds looks like a theme since I have to kill the Flushing bird3 to get it to reconnect those sessions. The template from the Flushing bird RR (looks the same for v6): template bgp BGP_v4_t { debug { events }; disabled off; local as ASN; enable extended messages on; igp metric off; prefer older on; rr client; rr cluster id 0.0.0.1; ipv4 { add paths on; import limit 3000000 action warn; import filter BGP_IN4; export filter BGP_OUT4; import table on; export table on; }; } Cheers, Radu

1 0

Bug Report: Unaligned Access in BGP Code on ARMv7 Platforms
by nick 19 Dec '24

19 Dec '24

Dear BIRD Community, I am writing to report a bug observed in the BGP implementation on ARMv7 platforms, which results in a SIGBUS error due to unaligned memory access in the NEON assembler code. I debugged this issue on version 2.15.1 of BIRD. ### Problem Description When running BIRD on ARMv7, the application crashes with a `SIGBUS` signal. The issue stems from an unaligned memory access instruction in the NEON assembly: ``` vst1.8 {d16-d17}, [r0 :64] ``` This instruction requires the address in `r0` to be 64-bit (8-byte) aligned. However, in some cases, `r0` is not correctly aligned, leading to a bus error. Here is an excerpt from the kernel logs showing the alignment trap: ``` kern.err kernel: [90636.175853] Alignment trap: not handling instruction f4400a1f at [<00056fbc>] kern.alert kernel: [90636.182044] Unhandled fault: alignment exception (0x801) at 0xb6dec01c kern.alert kernel: [90636.184946] pgd = 190a2833 kern.alert kernel: [90636.191494] [b6dec01c] *pgd=82e91835, *pte=8502b75f, *ppte=8502bc7f ``` ### Backtrace The crash occurs in the `bgp_get_prefix` function due to the misaligned memory address: ``` Program received signal SIGBUS, Bus error. 0x00057504 in bgp_get_prefix (path_id=0, net=0xb6f3e030, c=0xb6f27420) at proto/bgp/attrs.c:1710 1710 proto/bgp/attrs.c: No such file or directory. (gdb) bt #0 0x00057504 in bgp_get_prefix (path_id=0, net=0xb6f3e030, c=0xb6f27420) at proto/bgp/attrs.c:1710 #1 bgp_rt_notify (old=0x400, new=0x64, n=0x4, C=0xb6f27420, P=0xb6f27850) at proto/bgp/attrs.c:1966 #2 bgp_rt_notify (P=0xb6f27850, C=0xb6f27420, n=0x4, new=0x64, old=0x0) at proto/bgp/attrs.c:1936 ... ``` The exact crashing line is this instruction: ```c px->path_id = path_id; ``` You can view it here: https://github.com/CZ-NIC/bird/blob/0b684a43bd7ce4a32c9cd7754b88286bcd1815b… ### Root Cause The root cause appears to be insufficient alignment of memory allocated for structures, specifically in this line: ```c px = mb_alloc(c->pool, sizeof(struct bgp_prefix) + net->length); ``` The allocated memory may not be properly aligned for structures containing 64-bit data types, which is mandatory on ARMv7 when using NEON instructions. ### Temporary Workaround To mitigate the issue, we are currently using the GCC compiler flag `-mno-unaligned-access`. This flag ensures that the compiler avoids generating code that assumes unaligned access is supported, thereby preventing the `SIGBUS` error. https://github.com/freifunk-berlin/falter-packages/commit/fcce390fc57b44593… ### Request for Feedback I would like to hear the community's thoughts on the best approach to resolve this issue permanently. If needed, I can provide further logs or test configurations to reproduce the problem. Bests, Nick

2 12