On Fri, Feb 27, 2026 at 06:15:25PM +0000, Tomáš Matuš via Bird-users wrote: > 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. > ----- > 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.
Hello Thanks for the thorough report. Yes, it is a bug, as the RFC 8950 encoding is used while EVPN says just plain IPv4 (or IPv6) should be used. Fixed as a part of this patch (changes in bgp_encode_next_hop_ip()): https://gitlab.nic.cz/labs/bird/-/commit/b0ff170fbc70bfc978efe92257ca8b49dbdbaf92 > PS: Thank you Ondřej for including my previous bug report in the latest > rebase of the oz-evpn branch! Yes, i forgot to ack that, sorry. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) "To err is human -- to blame it on a computer is even more so."
