EPVN MPLS label parsing error
Ondrej Zajicek
santiago at crfreenet.org
Tue Nov 4 16:57:48 CET 2025
On Tue, Nov 04, 2025 at 09:48:29PM +1100, William via Bird-users wrote:
> Hi Ondrej,
>
> Apologies on the delay, I'm testing when I have the brain space and my lab
> is powered up.
Hi
Thanks for your feedback!
> > There are some configuration changes in this branch, encapsulation-specific options are in its own subblock:
> >
> > protocol evpn {
> > eth { table etab2; };
> > evpn;
> >
> > encapsulation vxlan {
> > tunnel device "vxlan2";
> > router address 10.1.1.1;
> > };
> >
> > rd 1:12;
> > route target (rt, 1, 0);
> >
> > tag 2;
> > vni 12;
> > };
> I wonder if there is something different in the way the IMET routes are put
> together there? The "encapsulation vxlan" stanza doesn't exist in the main
> evpn branch which is making me think that might be causing another issue...
The "encapsulation vxlan" stanza is just for encompassing
encapsulation-specific options, to future-proof for possible
implementations of multiple encapsulations, but that should not matter
now.
Note that 'oz-evpn' is the main EVPN branch, while 'evpn' is more-less an old
snapshot.
There are some more changes in 'oz-evpn', like fix for BGP_PMSI_TUNNEL attribute
flags (that is used in IMET routes) or announcing encapsulation extended communities.
> I've got mac-ip and imet routes floating around now, but the next issue is
> that the wrong next-hop is being set on the imet (and mac-ip) routes.
Seems like a deviation on our side. EVPN protocol does not attach the
bgp_next_hop attribute, and such attribute is attached by BGP when
announced to BGP neighbor, based on BGP session endpoint address.
We should fix that, meanwhile you can workaround it by setting 'next hop address'
BGP channel option (in BGP EVPN channel) to the VNI address:
https://bird.nic.cz/doc/bird-2.17.2.html#bgp-next-hop-address
> Here's the evpn protocol definition:
> protocol evpn {
> eth {
> table etab;
> import all;
> };
> evpn { };
> rd 1005001:10040;
> import target (rt, 1004001, 10040);
> import target (rt, 1004003, 10040);
> export target (rt, 1005001, 10040);
Note that setting multiple 'import target' options just replace the previous ones with the last one.
You need to use a set syntax:
import target [(rt, 1004001, 10040), (rt, 1004003, 10040)];
That is likely a bit confusing and at least should generate a warning.
> For what it's worth, 'bridge vlan add dev vxlan100 vid 40 tunnel_info id 40'
> errors out. The readme on
> https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp has
> typos in the commands too.
You mean typo del->add ?
instead of: bridge vlan del dev $TUNNEL vid $VID tunnel_info id $VNI
should be: bridge vlan add dev $TUNNEL vid $VID tunnel_info id $VNI
Note that with the latest 'oz-evpn' branch, BIRD configures VLANs on
VXLAN device automatically, but currently only for tagged vlans
(as in https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-evpn-bgp-tags/bird_m12.conf )
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
More information about the Bird-users
mailing list