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 < [email protected]> 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 > [email protected] > +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
