EPVN MPLS label parsing error

[William]

Hi Ondrej,

Thanks for the fast reply!  Just noticed the assorted typo's in the email.

On 10/10/2025 11:42 pm, Ondrej Zajicek wrote:

> 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?

Yes I'm using the evpn branch:

BIRD v2.13.1-161-gc5c9bd81-x ready.

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

Gotta love standards!  So that brings an interesting side case I wouldn't have
thought of - the "usable" VNI range is trimmed due to this?

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

That was one of my typo's - I meant route descriptor, not route target.

>
>> 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.
>
Thank you!

Regards,

William


-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20251011/b82ae145/attachment.htm>