How to avoid error messages for non-RFC8950 peers

[André Grüneberg]

Hi Douglas,

Since I am talking about an IXP route server, the system has no data-plane
for forwarding packets, so we do not care about MACs at all. Thus also no
EVPN.

The list of BGP daemons who have IPv4 AFI enabled by default spans all
those imitating Cisco IOS CLI. Those either need "no bgp default
ipv4-unicast" or "no neighbor X activate" (in ipv4 address family). I would
not call all of those BGP implementations "old".

André

On Thu, 21 Aug 2025 at 16:43, Douglas Fischer <fischerdouglas at gmail.com>
wrote:

> 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
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250821/7abe2ccd/attachment.htm>