<div dir="ltr"><div>Hi Douglas,</div><div><br></div><div>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.<br></div><div><br></div><div>The list of BGP daemons who have IPv4 AFI enabled by default spans all those imitating Cisco IOS CLI. Those either need "<span style="font-family:monospace">no bgp default ipv4-unicast</span>" or "<span style="font-family:monospace">no neighbor X activate</span>" (in ipv4 address family). I would not call all of those BGP implementations "old".</div><div><br></div><div>André</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 21 Aug 2025 at 16:43, Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello André!<br><br>First, I'm curious to know which BGP daemons and vendors exhibit the behavior you mentioned.<br>When I read it, I assumed it was something quite old behavior.<br><br>Also, while reading, looking at the relationship between IPv6/IPv4 and MAC, I had some intrusive thoughts like:<br>"Wouldn't EVPN have some use here?" But I quickly erased that from my mind. #BaDumTis<br><br>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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 21 de ago. de 2025 às 10:29, André Grüneberg <<a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>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:</div><div></div><div>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)<br>2025-08-21 08:14:24 <ERR> pb_0359_asXXXX: Invalid route <a href="http://45.91.12.0/24" target="_blank">45.91.12.0/24</a> withdrawn<br></div><div><br></div><div>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.</div><div><br></div><div>So I've been thinking how to avoid the situation we are in and came up with two potential approaches:</div><div><ol><li>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.</li><li>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.</li></ol><div>Currently I only see "require extended next hop" switch, but to my understanding this will tear down the BGP session -- which is undesirable.</div><div><br></div><div>Does anyone have other good ideas?</div><div><br></div><div>BTW: It's not very intuitive to understand from the above error messages that the announcement is egress. :)</div><div><br></div><div>Best wishes,</div><div>André</div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div>