How to avoid error messages for non-RFC8950 peers

[Douglas Fischer]

Hello André!

First, I'm curious to know which BGP daemons and vendors exhibit the
behavior you mentioned.
When I read it, I assumed it was something quite old behavior.

Also, while reading, looking at the relationship between IPv6/IPv4 and MAC,
I had some intrusive thoughts like:
"Wouldn't EVPN have some use here?" But I quickly erased that from my mind.
#BaDumTis

Now thinking about a workaround, assuming the IPv4 MAC will be the same as
the IPv6 MAC, couldn't we force the rewriting of this next-hop with some
hard-police-routing enforcement?

Em qui., 21 de ago. de 2025 às 10:29, André Grüneberg <
andre.grueneberg at bcix.de> escreveu:

> Hi,
>
> We have lately enabled RFC8950 (BGP IPv4 routes with IPv6 nexthop) on (one
> of) our route servers. We did this for all the connected peers.
>
> This means two things: We added ipv4 channels to "protocol bgp"s with an
> IPv6 neighbor and we enabled "extended next hop" in these channels. This
> will announce IPv4 and the respective extended next hop capability in BGP
> OPEN.
>
> In an ideal world all existing peers would only have IPv6 AFI enabled on
> their IPv6 BGP sessions. Unfortunately some BGP implementations by default
> have proxy-arp^WIPv4 AFI enabled for all neighbors. So we ended up with
> some peers announcing IPv4 AFI but not "extended next hop".
>
> Obviously Bird now tries to send those peers all the IPv4 routes it has in
> the routing table. Since the route server is transparent, the routes have
> an IPv6 next-hop and thus we get the following error messages:
> 2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid NEXT_HOP attribute -
> mismatched address family (2001:7f8:19:1:0:3:48d2:1 for ipv4)
> 2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid route 45.91.12.0/24
> withdrawn
>
> Of course I'll try to educate people to correct their configuration to get
> closer to the ideal world above. At the same time, I'd love to avoid those
> error messages.
>
> So I've been thinking how to avoid the situation we are in and came up
> with two potential approaches:
>
>    1. Since all session are configured in passive mode, the neighbors
>    should send their BGP OPEN first. So upon receiving IPv4 AFI without
>    receiving "Extended next hop - IPv6 nexthop: ipv4" we will remove IPv4 AFI
>    from our BGP OPEN answer.
>    2. If we had the negotiated protocol capabilities available in the
>    export filter, we could filter IPv4 routes with IPv6 nexthop in case
>    extended next hop is not negotiated.
>
> Currently I only see "require extended next hop" switch, but to my
> understanding this will tear down the BGP session -- which is undesirable.
>
> Does anyone have other good ideas?
>
> BTW: It's not very intuitive to understand from the above error messages
> that the announcement is egress. :)
>
> Best wishes,
> André
>
> --
> André Grüneberg, Managing Director
> andre.grueneberg at bcix.de
> +49 30 2332195 42
>
> BCIX Management GmbH
> Albrechtstr. 110
> 12103 Berlin
> Germany
>
> Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg
> Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250821/03c79fcc/attachment.htm>