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
