EPVN MPLS label parsing error

[Ondrej Zajicek]

On Fri, Oct 10, 2025 at 06:52:28PM +1100, William via Bird-users wrote:
> Hi BIRDians,
> Been tinkering with EPVN in (built from git on Debian 13.1) hooked into an
> Arista vEOS-LAB network, with an IPv6 underlay.

Hi

I am glad to hear someone is playing with it. Do you use the 'evpn' branch?


> Have all the BGP sessions up and running, pushing MACs and their next hops,
> receiving traffic on the VXLAN interface, all good.
> 
> But I'm not seeing the traffic coming out of the linux bridge to the
> respective VLAN subinterface for processing.  Digging round I see this in
> the bridge FDB:
> 
> <snip>
> 00:50:00:00:12:01 dev vxlan100 vlan 40 extern_learn master br1
> 42:a5:d1:11:88:4b dev vxlan100 vlan 40 master br1 permanent
> 42:a5:d1:11:88:4b dev vxlan100 master br1 permanent
> 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:ffff:1ad::403 vni 10040 self
> extern_learn permanent
> 00:50:00:00:12:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni 627 self
> extern_learn permanent
> 
> 
> 627?  the VNI is 10040.

Also note that on IMET route, the VNI is decoded correctly, only for
MAC route it is decoded incorrectly.


> Having a look at a packet dump of an EVPN update on the wire:
> 18:21:59.434664 IP6 (class 0xc0, flowlabel 0x59dd9, hlim 3, next-header TCP
> (6) payload length: 151) 2001:db8:ffff:1aa::1.40949 >
> 2001:db8:ffff:1aa::501.179: Flags [P.], cksum 0x107d (correct), seq
> 4225498746:4225498865, ack 3651948816, win 498, options [nop,nop,TS val
> 3223710250 ecr 3856730090], length 119: BGP
>         Update Message (2), length: 119
>           Origin (1), length: 1, Flags [T]: IGP
>             0x0000:  00
>           AS Path (2), length: 10, Flags [T]: 4201003001 4201004001
>             0x0000:  0202 fa66 37f9 fa66 3be1
>           Multi-Protocol Reach NLRI (14), length: 56, Flags [OE]:
>             AFI: VPLS (25), SAFI: EVPN (70)
>             no AFI 25 / SAFI 70 decoder
>             0x0000:  0019 4610 2001 0db8 ffff 01ad 0000 0000
>             0x0010:  0000 0401 0002 2100 0200 0f51 e327 3800
>             0x0020:  0000 0000 0000 0000 0000 0000 0030 fe40
>             0x0030:  197e 2a79 0000 2738
>           Extended Community (16), length: 16, Flags [OT]:
>             target (0x0202), Flags [none]: 1004003:10040
>             encapsulation (0x030c), Flags [none]: Tunnel type: VXLAN
>             0x0000:  0202 000f 51e3 2738 030c 0000 0000 0008
> 
> The RT there is showing correctly.
> 
> Hang on... 627 HEX is 273... looks like the 2 bytes of the latter half of
> the RT is being trimmed by 4 bits.

First, note that the VNI is not decoded from RT, but from the MPLS field
of Multi-Protocol Reach NLRI (14) - last 24 bits (00 2738). It is just a
convention for RT to use the same value as VNI.

IIRC there is a confusion about this field w.r.t. EVPN, as EVPN can use both
MPLS and VXLAN as underlying transport, VXLAN VNIs are 24 bit long, but
MPLS labels are 20 bit long and unfortunately padded from the LSB side.
So it si read as MPLS label, ignoring the last four bits.


> I couldn't get a hang of the code to try and ID where it's playing up so
> sorry, no patch.
> 
> Also, I'm not able to use 4-byte ASNs in the first part of the RT.  The docs
> indicate that we should be able to, but the config barfs with out-of-range
> (was trying to use 1005001 - a subset of the ASNs being used).

In which context? From the config file below i see 'import target (rt, 1004001, 10040)',
so 32bit ASN.


> Took a bit to work it all out based on a previous thread and the testing
> config, but got there in the end, then found this :(
> 
> If you're able to spin up a patch I can re-compile with it and test.

Will look on both issues and make a fix, probably during weekend.

-- 
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."