- Bird-users - Mailing Lists

PATCH: IO: Avoid calling SO_BINDTODEVICE if not needed
by Christian Svensson 30 Jul '24

30 Jul '24

Since Linux 5.7 (see linux/c427bfec18f21) non-root users are allowed to bind a socket using SO_BINDTODEVICE as long as the socket is not already bound. When using BGP with VRFs, BIRD correctly binds the listening socket to the VRF but also re-binds the accept()'d socket to the same VRF. This is not needed as the interface bind is inherited in this case, and indeed this redundant bind causes an -EPERM if BIRD is running as non-root making BIRD close the connection and reject the peer. We change the behaviour of the generic sk_setup to first query the socket and see if the socket is already correctly bound, and call setsockopt(SO_BINDTODEVICE) iff it is truly needed. In addition, since the getsockopt(SO_BINDTODEVICE) was implemented in Linux 3.8 or otherwise might be blocked in existing installations, we quietly fall back to the previous behavior if the getsockopt call fails. Test case: Run BIRD as a non-root user (and no extra capabilities) using passive BGP inside a VRF. Before the patch observe the error: "<ERR> SOCK: Incoming connection: SO_BINDTODEVICE: Operation not permitted" protocol bgp AS1234_1 { [..] vrf "VrfTest"; passive on; } After the patch this works as expected. Patch is attached to this message but if it falls off it can also be found at: https://github.com/sonix-network/bird/blob/33a0ac4b5af38d3bf75c78ca62472fff… There is also a simple utility to test the behavior of rebinding sockets at: https://github.com/sonix-network/bird/blob/33a0ac4b5af38d3bf75c78ca62472fff… Thanks for your consideration,

3 7

Bird 1.6 Debian 10 update to Debian 12
by Jakub Osuch 28 Jul '24

28 Jul '24

Hi Now I use Debian 10 with Bird 1.6 Can I upgrade Debian 10 to 12 ? -- Jakub Osuch mobile +48501203739 www.techgroup.pl

2 4

Re: [Babel-users] Babel RTT settings for low and high latencies
by Juliusz Chroboczek 18 Jul '24

18 Jul '24

>> Some of the VM's are in the same data center (latency < 1ms) and some >> are very far away (Germany <-> Hong Kong 300ms-400ms). Which rtt-min, >> rtt-max and rtt-cost/max-rtt-penalty would be suitable for such >> a network? rtt-min should be chosen so that all links below rtt-min are local -- the idea is that below rtt-min, it's not worth optimising the path. The default value (10ms) should be fine in most networks. rtt-max should be larger than all good links in your network -- the idea is that above rtt-max, it's no longer worth optimising the path. In your case, you might want to increase the value to 350ms or so. > we are running re6st a mesh network based on babel. We have almost the > same setup as you: around 400 machines connected worldwide. Our default > options for babel are: > max-rtt-penalty 5000 > rtt-max 500 > rtt-decay 125 That's a little bit extreme, but since Nexedi's network is uncongested, Babel should be fairly stable even with such extreme parameters. -- Juliusz

3 6

Babel RTT settings for low and high latencies
by Marek Küthe 17 Jul '24

17 Jul '24

Hello, I have (once again) [1] some questions about babel's rtt: I have a network with several servers, which are distributed worldwide and connected via WireGuard tunnels. I run Babel as the routing protocol between them. Some of the VM's are in the same data center (latency < 1ms) and some are very far away (Germany <-> Hong Kong 300ms-400ms). Which rtt-min, rtt-max and rtt-cost/max-rtt-penalty would be suitable for such a network? I would be very happy to receive ideas and suggestions! Greetings Marek Küthe [1] https://www.mail-archive.com/bird-users@network.cz/msg07641.html -- Marek Küthe m.k(a)mk16.de er/ihm he/him

1 0

EVPN IRB - RFC 9135 support
by Erik Stomp 13 Jul '24

13 Jul '24

Dear BIRD community, I plan to use the BIRD EVPN beta implementation (https://gitlab.nic.cz/labs/bird/-/tree/evpn?ref_type=heads) for a private Lab. I use EVPN in my employer's data center (based on FRR), so I am already quite familiar with EVPN. If I don't miss anything, the current EVPN implementation does't support EVPN IRB as described in RFC 9135. Since I only want to use BIRD EVPN in a lab, this is not a big problem for me. Of course I could use FRR, which supports IRB, but since I use BIRD everywhere, it would be nice if I could also use it in the EVPN lab. So my question is: Are there any plans to implement RFC 9135 in the foreseable future? I know, this isn't a 5 minute task and fully understand if it's not planned due to low priority. Maybe I can use the new L3VPN feature as an alternative then. Has anyone tried it yet? Otherwise, I'll have a look at it, as soon as I find some time. Best regards, Erik

3 3

Limit of numbers of BGP communities
by Ponikierski, Grzegorz 13 Jul '24

13 Jul '24

Hello all! How many standard communities, extended communities and large communities, user can apply on a route using Bird? BGP UPDATE message has finite size so I guess that there must be a limit somewhere. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940 and AS21342

4 6

What is the expected iBGP behaviour for routes with different local_pref?
by Nico Schottelius 06 Jul '24

06 Jul '24

Hello everyone, I was wondering how bird *should* behave if within one AS a route is received from outside multiple times but with different local_pref set? My expectation would be that using iBGP, the lower local_pref route would show up on all routers, but the higher one is selected. What I observe is that seems the router who initially receives the lower local_pref route does not export it via iBGP, even though it matches the export filter. Example: - server145 has a non-preferable uplink and imports all routes with local_pref = 80 - server137 has a preferable uplink and imports all routes without local_pref modification, thus local_pref = 100 - server145 has both routes - server137 only has the preferable route - It seems that server145 is not exporting its lower local_pref routes, even though they match the export filter Excerpt from server145, importing 2600:: route from outside, with setting local_pref to 80: -------------------------------------------------------------------------------- bird> show route all for 2600:: Table master6: 2600::/48 unicast [ibgp_server137 14:34:07.078 from 2a0a:e5c0:0:b::89] * (100/96) [AS1239i] via fe80::3eec:efff:fed2:d1e4 on eth0 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 39040 1299 174 1239 BGP.next_hop: 2a0a:e5c0:31:2::1 BGP.local_pref: 100 BGP.community: (1299,20000) (39040,100) (39040,109) (39040,1000) BGP.otc: 209898 unicast [outgoing_server120 14:33:56.123] (100) [AS1239i] via 2a0a:e5c0:31:4::1 on tun1 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 39040 1299 174 1239 BGP.next_hop: 2a0a:e5c0:31:4::1 fe80::897b:493f:bd44:ec60 BGP.local_pref: 80 BGP.community: (1299,20000) (39040,100) (39040,109) (39040,1000) BGP.otc: 209898 unicast [outgoing_server121 14:34:41.137] (100) [AS1239i] via 2a0a:e5c0:32:4::1 on tun0 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 174 1239 BGP.next_hop: 2a0a:e5c0:32:4::1 fe80::fa84:82d2:a117:43c BGP.local_pref: 80 BGP.community: (3356,2) (3356,22) (3356,86) (3356,505) (3356,601) (3356,666) (3356,903) (3356,2074) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898 unicast [ibgp_server138 14:34:56.416 from 2a0a:e5c0:0:b::8a] (100/96) [AS1239i] via fe80::3eec:efff:fed2:d0c4 on eth0 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 174 1239 BGP.next_hop: 2a0a:e5c0:32:2::1 BGP.local_pref: 100 BGP.community: (3356,2) (3356,22) (3356,86) (3356,505) (3356,601) (3356,666) (3356,903) (3356,2074) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898 -------------------------------------------------------------------------------- And on server137, this route is not visible, only the local_pref = 100 are visible: -------------------------------------------------------------------------------- bird> show route all for 2600:: Table master6: 2600::/48 unicast [outgoing_server120 14:41:16.420] * (100) [AS1239i] via 2a0a:e5c0:31:2::1 on oserver120 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 39040 1299 174 1239 BGP.next_hop: 2a0a:e5c0:31:2::1 BGP.local_pref: 100 BGP.community: (1299,20000) (39040,100) (39040,109) (39040,1000) BGP.otc: 209898 unicast [ibgp_server138 14:42:17.052 from 2a0a:e5c0:0:b::8a] (100/96) [AS1239i] via fe80::3eec:efff:fed2:d0c7 on eth5 Type: BGP univ BGP.origin: IGP BGP.as_path: 209898 15576 3356 174 1239 BGP.next_hop: 2a0a:e5c0:32:2::1 BGP.local_pref: 100 BGP.community: (3356,2) (3356,22) (3356,86) (3356,505) (3356,601) (3356,666) (3356,903) (3356,2074) (15576,100) (15576,102) (15576,1000) BGP.otc: 209898 -------------------------------------------------------------------------------- On the iBGP session we import/export everything that is either static or BGP,excerpt from server137: -------------------------------------------------------------------------------- Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 3 imported, 206002 exported, 2 preferred Route change stats: received rejected filtered ignored accepted Import updates: 211444 0 0 70 211374 Import withdraws: 230070 0 --- 24038 206032 Export updates: 645070 137427 98 --- 507545 Export withdraws: 64508 --- --- --- 96296 BGP Next hop: 2a0a:e5c0:0:b::89 fe80::3eec:efff:fed2:d1e4 IGP IPv6 table: master6 -------------------------------------------------------------------------------- But it seems server145 is not exporting them from how it looks: -------------------------------------------------------------------------------- Channel ipv6 State: UP Table: master6 Preference: 100 Input filter: ACCEPT Output filter: static_and_bgp Routes: 206011 imported, 3 exported, 206008 preferred Route change stats: received rejected filtered ignored accepted Import updates: 503843 0 0 445 503398 Import withdraws: 91701 0 --- 78 91623 Export updates: 927807 684226 97 --- 243484 Export withdraws: 33627 --- --- --- 230240 BGP Next hop: 2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c IGP IPv6 table: master6 -------------------------------------------------------------------------------- Even though a lot more routes match the filter: -------------------------------------------------------------------------------- bird> show route count filter static_and_bgp 3803744 of 3803746 routes for 950939 networks in table master4 824133 of 824170 routes for 206080 networks in table master6 Total: 4627877 of 4627916 routes for 1157019 networks in 2 tables bird> -------------------------------------------------------------------------------- So is this a misconfiguration or a bug or intended behaviour? Because *if* the upstream of server137 goes down, it starts receiving routes from server145, so failover works, but it seems wrong to me to not have the routes by default. Best regards, Nico p.s.: the config for server145 that does not export the routes is: -------------------------------------------------------------------------------- define pref_tunnel_fiberstream = 80; # used filter static_and_bgp { if source ~ [ RTS_STATIC, RTS_BGP ] then accept; reject; } protocol bgp outgoing_server120 { local as myas; direct; password "..."; bfd on; neighbor 2a0a:e5c0:31:4::1 as 209898; local role customer; default bgp_local_pref pref_tunnel_fiberstream; ipv6 { import filter allow_all; export filter p5_to_world; }; ipv4 { import filter allow_all; export filter p5_to_world; extended next hop on; }; } protocol bgp ibgp_server137 { local as myas; neighbor 2a0a:e5c0:0:b::89 as myas; direct; bfd on; ipv6 { import all; export filter static_and_bgp; gateway recursive; }; ipv4 { import all; export filter static_and_bgp; gateway recursive; extended next hop on; }; } -------------------------------------------------------------------------------- -- Sustainable and modern Infrastructures by ungleich.ch

4 4

Extended communities ASN wildcard, extraction of eclist.
by Ochalski, Radoslaw 03 Jul '24

03 Jul '24

Since we are missing a way to apply a wildcard on ASN for extended community, is there a way to extract value from ec list? Like for lc list. 2024-07-02 11:00:05.579 <INFO> Ext community(eclist (ro, 20940, value)) I would like to match all ASNs by value, not by ASN. Kind Regards, Radoslaw Ochalski Network Engineer Senior MON - FRI 08:00AM to 4:00 PM UTC [cid72*image015.png@01DA1C68.FE26C0A0] Connect with Us: [cid72*image009.png@01DA1C68.FE26C0A0]<https://community.akamai.com/> [cid72*image016.png@01DA1C68.FE26C0A0] <http://blogs.akamai.com/> [cid72*image017.png@01DA1C68.FE26C0A0] <https://urldefense.com/v3/__https:/twitter.com/akamai__;!!GjvTz_vk!XMttgAB4…> [cid72*image018.png@01DA1C68.FE26C0A0] <https://urldefense.com/v3/__http:/www.facebook.com/AkamaiTechnologies__;!!G…> [cid72*image019.png@01DA1C68.FE26C0A0] <https://urldefense.com/v3/__http:/www.linkedin.com/company/akamai-technolog…> [cid72*image020.png@01DA1C68.FE26C0A0] <https://urldefense.com/v3/__http:/www.youtube.com/user/akamaitechnologies?f…>

2 3

IPv6 BFD interop with Huawei, checksum 0 UDP
by Ville O 27 Jun '24

27 Jun '24

Hello, At least some Huawei devices use a checksum of 0 for all IPv6 BFD UDP packets after finishing Poll/Final. All packets sent with states other than Up or with flags other than C have the correct checksums. IPv6 checksum issues with UDP seem to be rather common with network vendors, for example Cisco has very relevant problems in IPv6 BFD [1] and has added a command around this issue [2]; other vendors have articles around various problems with the mandatory checksums. Following the RFCs this should be a bug on the Huawei side since the checksum is mandatory. But getting Huawei to fix this could be difficult or impossible and I personally do not have options to pursue that. These problem devices are not under my control. I have no relationship with Huawei. This issue could be worked around on the BIRD side at least on the Linux platform. RFC6936 allows [3] for hosts to enable accepting IPv6 UDP with a checksum of 0 and this is implemented in Linux kernels from 3.16 with sockopt "UDP_NO_CHECK6_RX". I have tested that this indeed works: checksum 0 packets are received to AF_INET6, SOCK_DGRAM sockets when it is enabled. I wonder if it would be acceptable to enable this option on the IPv6 socket(s) used for BFD in BIRD, if supported by the platform? I understand this idea may be controversial given it is not portable and the reason for the workaround. At minimum I hope this post may be informative for others failing to setup IPv6 BFD with Huawei. Regards, VO [1] https://bst.cisco.com/quickview/bug/CSCtb33440 [2] https://bst.cisco.com/quickview/bug/CSCtb87599 [3] https://datatracker.ietf.org/doc/html/rfc6936#section-4

4 8

bird2.15.1 - FreeBSD14
by Torsten Wilms 21 Jun '24

21 Jun '24

I am using FreeBSD 14 with FIBs. With bird2.14 I get routes via BGP and anything is fine. With bird2.15.1 I get routes, but the daemon doesn’t put them into the kernel routing table. Same configuration work with older version. Does something change which has an effect on it? template bgp general_bgp { debug { states, routes, interfaces }; strict bind on; enable route refresh on; graceful restart time 300; hold time 15; keepalive time 5; med metric on; password "*************"; } ipv4 table table_SLICE1 protocol direct direct_SLICE1 { interface "vtnet2"; ipv4 { table table_SLICE1; }; } protocol kernel kernel_SLICE1 { kernel table 1; scan time 10; ipv4 { table table_SLICE1; import all; export all; }; } ### br1 protocol bgp br1_SLICE1 from general_bgp { description "[SLICE1][br1] - BGP Transit Services"; local 100.64.1.185 as 64521; neighbor 100.64.1.7 as 64521; ipv4 { table table_SLICE1; import keep filtered; import all; export none; }; } ### br2 protocol bgp br2_SLICE1 from general_bgp { description "[SLICE1][br2] - BGP Transit Services"; local 100.64.1.185 as 64521; neighbor 100.64.1.8 as 64521; ipv4 { table table_SLICE1; import keep filtered; import all; export none; }; } -------------------- ~ # birdc show route table table_SLICE1 BIRD 2.14 ready. Table table_SLICE1: 0.0.0.0/0 unicast [br1_SLICE1 2024-06-10 09:02:07] * (100) [i] via 100.64.1.7 on vtnet2 unicast [br2_SLICE1 2024-06-10 09:02:02] (100) [i] via 100.64.1.8 on vtnet2 100.64.21.0/24 unicast [br1_SLICE1 2024-06-10 09:02:07] * (100) [i] via 100.64.1.7 on vtnet2 unicast [br2_SLICE1 2024-06-10 09:02:02] (100) [i] via 100.64.1.8 on vtnet2 100.64.1.0/24 unicast [direct_SLICE1 2024-06-10 09:01:05] ! (240) dev vtnet2 unicast [br2_SLICE1 2024-06-10 09:02:02] (100) [i] via 100.64.1.8 on vtnet2 unicast [br1_SLICE1 2024-06-10 09:02:07] (100) [i] via 100.64.1.7 on vtnet2 ~ # setfib 1 netstat -rn Routing tables (fib: 1) Internet: Destination Gateway Flags Netif Expire 100.64.1.0/24 link#3 U vtnet2 100.64.1.185 link#15 UHS lo0 127.0.0.1 link#15 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 link#15 URS lo0 ::1 link#15 UHS lo0 ::ffff:0.0.0.0/96 link#15 URS lo0 fe80::%lo0/10 link#15 URS lo0 ff02::/16 link#15 URS lo0 Any idea? Thanks. BR Torsten

4 4