March 2026 - Bird-users - Mailing Lists

[PATCH] Nest: correct aspa_check() implementation
by Evann DREUMONT 15 Mar '26

15 Mar '26

Hello, Earlier this week, while building a BGP lab I've discovered a weird behavior with aspa_check() that was rejecting routes that should be correct. It seems to be the same bug as https://trubka.network.cz/pipermail/bird-users/2026-February/018611.html. I discover that the previous implementation of the verification algorithm was not fully compliant with the current internet draft (draft-ietf-sidrops-aspa-verification-24) and could incorrectly filter routes when the up-ramp and down-ramp apex were apart by exactly one hop. In practice, this caused legitimate routes to be dropped, such as routes involving Tier-1 peering while having an AS0 ASPA record. One of my test sample was the following AS_PATH: 10846, 7018, 174, 29075, 208627 with the following ASPA records: - AS208627 => AS29075 - AS174 => 0 - AS7018 => 0 - AS10846 => 7018 If you manually compute the upstream and downstream bounds, you get - max_down = 5 - 3 + 1 = 3 - min_down = 5 - 4 + 1 = 2 - max_up = 2 - min_up = 2 Using the downstream algorithm: - max_up + max_down = 5 >= N, so the route is not invalid and we continue - min_up + min_down = 4 < N, so the route is unknown If you draw this on paper, it makes sense. However, BIRD reports this route as invalid, which is unexpected. Given this issue, I tried to implement a patch. With a bit of help of Alarig, I managed to get a working version that still passes the existing unit tests (except one) as well as our corner case. While I tried to understand the initial logic, it was quite hard to follow. Therefore, I tried, as much as possible, to follow the algorithm from the I.D. Something not trivial since the AS_PATH is reversed compared to the draft. This patch also contains few documentation comments. While I am not usually a big fan of comments, I think these are needed to highlight the differences between our implementation and the algorithm specified in the Internet-Draft. To improve unit test coverage, I have added the missing test cases from the official list (https://raw.githubusercontent.com/ksriram25/IETF/main/ASPA_path_verificatio…) They all passed successfully. However, one of the existing custom unit tests did not pass. In this test, the path consists of two ASes: 65544, 65541. AS65544 declare an AS0 ASPA and AS65541 declare AS65545 as a provider. The test expects the route to be invalid. However, I believe this expectation is incorrect. Manual computation gives: - min_up = 1 - max_up = 1 - max_down = 2 - 2 + 1 = 1 - min_down = 2 - 2 + 1 = 1 Using the downstream algorithm: - max_up + max_down = 2 >= N, so the route is not invalid and we continue - min_up + min_down = 2 >= N, so the route is not unknown, and therefore the route is valid. This actually makes sense: although there is no explicit valid ASPA, from a downstream perspective, this can be interpreted as a peering relationship between AS65544 and AS65541 (with the up-ramp and down-ramp apexes separated by exactly one hop), and the route should therefore be considered valid (see: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-…) Don't hesitate to discuss the patch if needed, -- Evann

4 3

evpn rebase to HEAD
by Pim van Pelt 13 Mar '26

13 Mar '26

Hoi folks, I've started to toy with VPP and eVPN/VxLAN, and took a look at the evpn branch from a few years ago. For my network, I'll need the OSPFv3 'unnumbered' features we built, so I thought I'd ask - would it be possible to rebase the evpn branch ? I've taken a stab at it (see attached patch) by replaying the 9 commits on top if HEAD (f1a7229d-evpn.diff). It may not be correct, but it does compile and seemingly work :) root@vpp0-0:/etc/bird# birdc show proto BIRD 2.18+branch.evpn.1efd115564ea ready. Name Proto Table State Since Info device1 Device --- up 12:20:01.347 direct1 Direct --- up 12:20:01.347 kernel4 Kernel master4 up 12:20:01.347 kernel6 Kernel master6 up 12:20:01.347 static4 Static master4 up 12:20:01.347 static6 Static master6 up 12:20:01.347 bfd1 BFD --- up 12:20:01.347 ospf4 OSPF master4 up 12:20:01.347 Running ospf6 OSPF master6 up 12:20:01.347 Running bridge1 Bridge etab up 12:45:13.450 evpn1 EVPN --- up 12:45:13.450 I have a few further changes, notably a new 'vpp protocol' to handle communication with the VPP dataplane for eVPN/VxLAN (and possibly later, GENEVE and MPLS). Before I get too far down the rabbit hole though, I'm also wondering: is releasing eVPN in the cards? groet, Pim -- Pim van Pelt <pim(a)ipng.ch> PBVP1-RIPE https://ipng.ch/

4 17

[EVPN] BIRD leaks internal address representation in BGP next hop
by Tomáš Matuš 06 Mar '26

06 Mar '26

Hello BIRDs! I am trying out EVPN in a multi-vendor environment (namely against Arista and Huawei CE6881E) on an IPv4 underlay and I noticed that neither of these vendors are considering EVPN routes received from BIRD as valid. When I inspect EVPN routes on Huawei it shows that the next-hop address is an IPv4 mapped to IPv6 on all routes from BIRD. To keep it short I'll only include one IMET route from Arista (10.10.10.1) and one from BIRD (10.10.10.3) where the route from Arista has IPv4 next-hop and route from BIRD does not. ----- [~vx-4]displ bgp evpn all routing-table inclusive-route Local AS number : 65000 BGP Local router ID is 10.10.10.2 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete Route Distinguisher: 10.10.10.1:10010 Network(EthTagId/IpAddrLen/OriginalIp) NextHop *>i 0:32:10.10.10.1 10.10.10.1 Route Distinguisher: 10.10.10.3:10010 Network(EthTagId/IpAddrLen/OriginalIp) NextHop i 0:32:10.10.10.3 ::FFFF:10.10.10.3 ----- I also checked with Wireshark and BIRD really sends an IPv6 next hop. I am using the following config for BGP: ----- template bgp evpn_peer { local as 65000; source address 10.10.10.3; ipv4 { import none; # routed by ospf in underlay export none; }; evpn { import all; export all; }; } protocol bgp bgp_Huawei from evpn_peer { neighbor 10.10.10.2 as 65000; }----- Looking at the BIRD BGP docs I also tried explicitly setting "next hop address 10.10.10.3" in the evpn block but the result was the same. I understand that this could technically fall under RFC 8950 and the "extended next hop <switch>" option in which case it would be okay to send the next hop as IPv6 however by default this option should be disabled in BIRD and even if I explicitly disable it I still see the next hop as IPv6. I looked over how the BGP packets are constructed and I think this comes down to the bgp_encode_next_hop_ip() function where the bgp_channel_is_ipv4(s->channel) only checks for BGP_AFI_IPV4 and returns false for EVPN AF so it falls through and sets the next-hop address as IPv6. I've attached a patch which fixes this behavior but I'm certain it is far from perfect. I also went back to my BIRD-only lab and I can see the same behavior. In this case however I think either the kernel is smart enough to figure out it is an IPv4 mapped to IPv6 and therefore treats it as IPv4 or BIRD handles it because the internal representation is the same. Am I right to consider this as a bug or is there something I missed? I don't have any experience with other Address Families in BGP with BIRD so I am not sure how bird behaves there when setting the next-hop address. With my patch applied I am happy to share that the EVPN control-plane works and I don't see any other issues. Received IMET and MAC routes are imported and get propagated into the linux bridge interface and routes exported by BIRD are also installed by the other two vendors. So far I'm only using L2 VNIs and I haven't yet configured Huawei/Arista to include IP address in the Type 2 routes, I expect that BIRD does not support this yet but I am at least curious if it can handle without crashing, or, when used as Route Reflector, if it can reflect such routes. If you have any other ideas what would be worth trying out, please let me know! PS: Thank you Ondřej for including my previous bug report in the latest rebase of the oz-evpn branch! Thank you and have a nice day! Tomáš

2 1

bgp template inheritance
by BASSAGET Cédric 03 Mar '26

03 Mar '26

Hello, I'm trying to simplify my old bird 1.6 config, the aim is migrating to v2 then v3. I have a config like : template bgp private_peering_ipv4 { local as my_ans; path metric 2; ipv4 { import all; import filter { if (net.len > 24 ) then reject; bgp_large_community.add((my_asn, 1, 1003)); accept; }; export filter export_my_routes_ipv4; import keep filtered; }; } protocol bgp PEER_v4_peer1 from private_peering_ipv4 { router id 195.42.145.x; neighbor 195.42.144.104 as 6939; } protocol bgp PEER_v4_peer2 from private_peering_ipv4 { router id 195.42.145.x; neighbor 195.42.144.104 as 6939; ipv4 { import filter { bgp_large_community.add((my_asn, 1, 1009)); accept; }; }; } the problem here is that as soon as I define a new import filter for my second peer, the filter from the template is omitted. Is there a way to add inheritance between the templates, or anything else that wouldn't overwrite the template filters ? Regards, Cédric

3 2

[PATCH 0/4] BGP unnumbered automatic peering based on IPv6 ND
by Matteo Perin 02 Mar '26

02 Mar '26

Dear BIRD dev-team and community, This is a patch proposal spawned from the discussion in a previous mailing list thread [0], regarding how to achieve automatic BGP peering establishment using the IPv6 Neighbor Discovery mechanism. Over the last few weeks, I worked on implementing the feature with the outline Maria Matejka kindly provided. As expected, it proved to be quite challenging, especially when it came to integrate the peer discovery approach with the current dynamic BGP implementation. To briefly summarize the implemented automatic peering mechanism and added capabilites: - The ability for the RAdv protocol to receive and read incoming ICMPv6 RAs was added. - Route-like objects, containing RAs data are created, based on advertisments detections. These are stored in a new kind of routing table. - Lifetime of the objects in the table is determined by the ICMPv6 RA Router Lifetime field. RA expiration will remove the object from the table. - The discovery process is enabled only if a new neighbor discovery option is enabled in the RAdv protocol configuration. - A new channel was added to the BGP protocol called peers. - When present in the BGP configuration, an export to this BGP channel (allowed only in dynamic BGP) will trigger the spawn of a new session. - Withdrawal the object from the peers routing table will trigger the corresponding BGP session shutdown. - An automatic BGP session can be made permanent via configuration with a persist option in the peers channel. To test the main functionality of this feature it I used multiple VMs linked by a bridge with BIRD setup on all of them. BGP session establishment is successful between all routers even with a very minimal configuration. I will provide an example, so you can also see the new configuration parameters in action: protocol device { } peer table nd_peers; protocol radv radv1 { peer { table nd_peers; }; interface "enp5s0" { max ra interval 60; min ra interval 20; # Enable neighbor discovery on this interface # When enabled, BIRD will parse incoming RAs and store router info neighbor discovery yes; }; } protocol bgp bgp1 { dynamic name "bgp_peer"; dynamic name digits 3; local as 65000; neighbor range fe80::/12 external; # Link-local range for BGP unnumbered # Peers channel for importing peer discoveries and spawning sessions peers { # Interface for BGP session establishment from "enp5s0"; # Persist sessions on route withdrawal persist yes; table nd_peers; import all; export all; }; ipv4 { import all; export all; }; ipv6 { import all; export all; }; } Of course, I have some concerns about some design choices and code optimization, I tried to find the best solution that did not involve major refactorings or moving code around and some comments on how to improve rough edges from people more experienced on the current codebase would be really appreciated. Mostly, the two main points I am not entirely happy about are: - How I handled the RAs staleness mechanism based on router lifetime. I looked for it but there does not seem to be a per-route staleness mechanism already in place, so I resorted to adding a check for expired entries when the RAdv protocol timer is triggerd, which is not ideal. - The mechanism to avoid spawning multiple sessions when both dynamic BGP and this new feature are both configured. For now, I try looking for BGP session with the same remote peer address and give precedence to the ones spawned by the dynamic BGP mechanism, but I am quite sure it is possible to find a better solution for this. I tried to make the commit messages both informative and concise, but please ask if something is unclear or missing. I am still working on adding documentation and automated testing, but since I think the discussion about the implemetation is more useful with actual code in hand, I decided to send the main bulk of the patch right now and amend this later along with changes addressing incoming reviews. I hope you will appreciate the work done. Best Regards, Matteo [0] https://bird.network.cz/pipermail/bird-users/2025-November/018482.html Matteo Perin (4): Nest: Add net_peer route type to track discovered peers RAdv: Add neighbor discovery based on incoming RAs to RAdv proto BGP: Move postponed socket reloop logic from start to start_locked to achieve locking requirements BGP: Add peers channel and sessions spawn on export to achieve automatic peering lib/net.c | 16 ++++ lib/net.h | 31 ++++++- nest/config.Y | 3 +- nest/proto.c | 2 +- proto/bgp/attrs.c | 57 +++++++++++++ proto/bgp/bgp.c | 187 +++++++++++++++++++++++++++++++++++++++---- proto/bgp/bgp.h | 28 ++++++- proto/bgp/config.Y | 15 +++- proto/bgp/packets.c | 11 +++ proto/radv/config.Y | 3 +- proto/radv/packets.c | 41 +++++++++- proto/radv/radv.c | 163 ++++++++++++++++++++++++++++++++++++- proto/radv/radv.h | 4 + 13 files changed, 533 insertions(+), 28 deletions(-) -- 2.43.0

2 15