EPVN MPLS label parsing error
William
bird at is.unlawful.id.au
Fri Oct 10 09:52:28 CEST 2025
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.
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.
root at eve-deb:~# bridge vlan show
port vlan-id
br1 1 PVID Egress Untagged
vxlan100 40
root at eve-deb:~# bridge vni show
dev vni group/remote
root at eve-deb:~#
checking evpntab and etab:
bird> sh route table evpntab
Table evpntab:
evpn mac 1004003:10040 0 fe:40:19:7e:2a:79 * unicast [SPINE1_EVPN
18:21:59.435 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i]
via 2001:db8:ffff:1f3::8 on ens4 mpls 627
evpn imet 5001:10040 0 2001:db8:ffff:1ad::501 [evpn1 18:11:30.067] * (120)
evpn imet 1004003:10040 0 2001:db8:ffff:1ad::401 [SPINE1_EVPN
18:07:31.985 from 2001:db8:ffff:1aa::1] * (100) [AS4201004001i]
evpn imet 1004003:10040 0 2001:db8:ffff:1ad::403 [SPINE1_EVPN
18:07:31.987 from 2001:db8:ffff:1aa::1] * (100) [AS4201004003i]
evpn mac 1004003:10040 0 00:50:00:00:12:01 * unicast [SPINE1_EVPN
18:21:43.590 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i]
via 2001:db8:ffff:1f3::8 on ens4 mpls 627
bird> sh route table etab
Table etab:
00:00:00:00:00:00 vlan 40 unicast [evpn1 18:11:30.067] * (80)
via 2001:db8:ffff:1ad::403 on vxlan100 mpls 10040
42:a5:d1:11:88:4b unicast [bridge1 16:58:39.461] * L (0)
dev vxlan100
fe:40:19:7e:2a:79 vlan 40 unicast [evpn1 18:21:59.434] * (80)
via 2001:db8:ffff:1ad::401 on vxlan100 mpls 627
00:50:00:00:12:01 vlan 40 unicast [evpn1 18:21:43.590] * (80)
via 2001:db8:ffff:1ad::401 on vxlan100 mpls 627
06:06:4f:2b:a5:e6 unicast [bridge1 16:54:40.358] * L (0)
dev br1
bird>
Where's it coming from? On the single (so far) attached Arista spine we
see this:
dc1-spine-1#sh bgp evpn
BGP routing table information for VRF default
Router identifier 192.168.1.10, local AS number 4201003001
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e -
ECMP
c - Contributing to ECMP, % - Pending best path
selection
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL
Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref
Weight Path
* > RD: 1004003:10040 mac-ip 0050.0000.1201
2001:db8:ffff:1ad::401
- 100
0 4201004001 i
* > RD: 1004003:10040 imet 2001:db8:ffff:1ad::401
2001:db8:ffff:1ad::401
- 100
0 4201004001 i
* > RD: 1004003:10040 imet 2001:db8:ffff:1ad::403
2001:db8:ffff:1ad::403
- 100
0 4201004003 i
* > RD: 5001:10040 imet 2001:db8:ffff:1ad::501
2001:db8:ffff:1aa::501
- 100
0 4201005001 i
dc1-spine-1#
2001:db8:ffff:1ad::501 is the loopback that the vxlan interface is using.
Something going on weird with the RT processing.
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.
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).
Config:
filter SPINE_LO {
if net.len = 128 then accept;
reject;
}
evpn table evpntab;
protocol bgp SPINE1_BGP {
ipv6 {
import all;
export filter SPINE_LO;
};
local 2001:db8:ffff:1f3::9 as 4201005001;
neighbor 2001:db8:ffff:1f3::8 as 4201003001;
}
protocol bgp SPINE1_EVPN {
evpn {
import all;
export all;
};
local 2001:db8:ffff:1aa::501 as 4201005001;
neighbor 2001:db8:ffff:1aa::1 as 4201003001;
multihop;
}
eth table etab;
protocol bridge {
eth {
table etab;
export all;
};
bridge device "br1";
debug all;
};
protocol evpn {
eth {
table etab;
};
evpn { };
rd 5001:10040;
import target (rt, 1004001, 10040);
import target (rt, 1004003, 10040);
export target (rt, 5001, 10040);
tunnel device "vxlan100";
router address 2001:db8:ffff:1ad::501;
vni 10040;
vid 40;
debug all;
};
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.
Regards,
William
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
More information about the Bird-users
mailing list