<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body><div dir="auto">Hello Pim,<br><br>please check the oz-evpn branch first. I suppose (but may be wrong) that Ondřej will eventually rebase that one to master and we'll merge it.<br><br>If I remember correctly, the "evpn" branch is about to be dropped later on, but for definite word, you'll have to wait for Ondřej who actually drives the EVPN development.<br><br>Thank you for your understanding and patience.<br><br>Maria<br></div><br><br><div class="gmail_quote"><div dir="auto">On February 18, 2026 3:54:04 PM GMT+01:00, Pim van Pelt via Bird-users <bird-users@network.cz> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hoi folks,<br>
<br>
Bird folk, can I ask you to take a look at the rebase patch I sent?
I'd love for the 'evpn' branch to be rebased.<br>
<br>
<div class="moz-cite-prefix">On 14.02.2026 12:49, Pim van Pelt via
Bird-users wrote:<br>
</div>
<blockquote type="cite" cite="mid:462a3fd4-1c50-460a-acc5-9cc2b8a456cb@ipng.ch">I've
started to toy with VPP and eVPN/VxLAN, and took a look at the
evpn branch from a few years ago.
<br>
For my network, I'll need the OSPFv3 'unnumbered' features we
built, so I thought I'd ask - would it be possible to rebase the
evpn branch ?
<br>
I've taken a stab at it (see attached patch) by replaying the 9
commits on top if HEAD (f1a7229d-evpn.diff).
<br>
<br>
It may not be correct, but it does compile and seemingly work 🙂</blockquote>
I have played around with this 2.18+evpn rebase and created a
working eVPN/VxLAN with VPP. I stumbled across a few specifics which
I'd like to share:<br>
<br>
(1) The evpn export are causing the following assertion failure:<br>
Assertion '!((a->flags ^ desc->flags) & (BAF_OPTIONAL |
BAF_TRANSITIVE))' failed at proto/bgp/attrs.c:1269<br>
<br>
evpn_announce_mac() and evpn_announce_imet() were using
ea_set_attr_ptr() with flags=0 to set BGP attributes
BA_EXT_COMMUNITY and BA_PMSI_TUNNEL. Those attributes have
descriptor flags BAF_OPTIONAL | BAF_TRANSITIVE, and when BGP's
bgp_export_attr() processes those attributes during update encoding,
it trips the assertion.<br>
<br>
This patch switches to bgp_set_attr_ptr() which automatically
normalizes flags from the descriptor table, ensuring the stored
attribute flags always match what the descriptor expects. Compare to
l3vpn.c which correctly passed BAF_OPTIONAL | BAF_TRANSITIVE
explicitly, this feels cleaner.<br>
<b>See bird2.18+evpn_use_bgp_set_attr.diff for a possible fix.<br>
</b><br>
(2) BGP Next Hop for Type-2 should be the 'router address' from evpn
protocol.<br>
When announcing an IPv4 vxlan evpn on an IPv6 BGP session, default
behavior is to set the next hop using the BGP session. This means
the MAC nexthops will be IPv6, not 'router address'. More-over,
changing this with 'next hop address X' is not possible, because
overriding the next-hop will remove the MPLS label (which carries
the VNI).<br>
<br>
Under the assumption that whatever 'router address' is in the evpn
protocol context will determine:<br>
1) the PMSI [already correctly added even if the nexthop is a
different family, here it does not matter]<br>
2) the BGP next hops for Type-2 (MAC) announcements [where it
matters if the evpn vxlan address family differs to the BGP session
address family]<br>
<br>
This patch fixes the latter: setting the BGP next hop to the 'router
address' field for evpn_announce_mac() and for consistency also for
evpn_announce_imet()<br>
<b>See bird2.18+evpn_use_routeraddr_as_bgp_nexthop.diff for a
reasonable default.<br>
</b><br>
(3) Setting BGP Next Hop clears MPLS Labelstack, filters cannot set
this.<br>
When the BGP Next Hop is changed by an export filter, we lose the
MPLS labelstack. There is no way to add MPLS labelstack in filters
(at least, that I could find), so we cannot use 'next hop address X'
to determine the Type-2 MAC VxLAN endpoint. Note: IMET updates do
not use the BGP Next Hop, but rather a PSMI attribute with the
'router address' already.<br>
<br>
This patch ensures that the MPLS labelstack (the first label carries
the VNI in the case of eVPN/VxLAN) is put back for L2VPN MPLS BGP
updates.<br>
<b>See bird2.18+evpn_ensure_mpls_labelstack_is_set.diff for a
durable fix.<br>
</b><br>
Otherwise, I found that the evpn branch, rebased on 2.18, works a
treat, noting that I am not using 'bridge' protocol, but instead
reading eVPN information directly from the 'eth table' for my
application.<br>
<br>
groet,<br>
Pim<br>
<br>
<pre class="moz-signature" cols="72">--
Pim van Pelt <a class="moz-txt-link-rfc2396E" href="mailto:pim@ipng.ch"><pim@ipng.ch></a>
PBVP1-RIPE <a class="moz-txt-link-freetext" href="https://ipng.ch/">https://ipng.ch/</a></pre>
<br>
</blockquote></div><div dir="auto"><div class='k9mail-signature'>-- <br>Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</div></div></body>
</html>