On Wed, Feb 18, 2026 at 03:54:04PM +0100, Pim van Pelt via Bird-users wrote:
Hoi folks,
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.
Hi As others noted, the relevant branch is 'oz-evpn', the older 'evpn' branch fell victim to my needlesly strict adherence to "do not rebase public branch" rule. The patches in 'oz-evpn' are not only rebased on newer BIRD version, but also have fixes squashed in them, and there is newer development. I just pushed there rebase to 2.18. Please look at this branch first. Also note there are some minor changes to EVPN protocol configuration syntax.
On 14.02.2026 12:49, Pim van Pelt via Bird-users wrote:
I've started to toy with VPP and eVPN/VxLAN, and took a look at the evpn branch from a few years ago. 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 ? I've taken a stab at it (see attached patch) by replaying the 9 commits on top if HEAD (f1a7229d-evpn.diff).
It may not be correct, but it does compile and seemingly work 🙂 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:
(1) The evpn export are causing the following assertion failure: Assertion '!((a->flags ^ desc->flags) & (BAF_OPTIONAL | BAF_TRANSITIVE))' failed at proto/bgp/attrs.c:1269
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.
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.
Already fixed in oz-evpn. I would prefer not to use bgp_set_attr() outside BGP and we already have another approach to attribute handling in BIRD 3, so i kept the ea_set_attr_ptr() functions here.
*See bird2.18+evpn_use_bgp_set_attr.diff for a possible fix. * (2) BGP Next Hop for Type-2 should be the 'router address' from evpn protocol. 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).
Under the assumption that whatever 'router address' is in the evpn protocol context will determine: 1) the PMSI [already correctly added even if the nexthop is a different family, here it does not matter] 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]
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() *See bird2.18+evpn_use_routeraddr_as_bgp_nexthop.diff for a reasonable default.
Will look at this more.
(3) Setting BGP Next Hop clears MPLS Labelstack, filters cannot set this. 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.
Resetting MPLS label when changing next hop is intentional, as MPLS labels are (in general) specific to receiving routers. There is gw_mpls (and undocumented/semantically broken gw_mpls_stack) attribute that could be accessed in filters. I am not sure what is your use case here to change it with filters, can you describe it more? What about setting 'router address' in EVPN proto?
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.
Good to hear that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."