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: [email protected]) "To err is human -- to blame it on a computer is even more so."
