[EVPN] BIRD leaks internal address representation in BGP next hop

[Ondrej Zajicek]

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: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."