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@crfreenet.org) "To err is human -- to blame it on a computer is even more so."