Hi Ondrej, Apologies on the delay, I'm testing when I have the brain space and my lab is powered up. On 14/10/2025 3:02 am, Ondrej Zajicek wrote:
On Sat, Oct 11, 2025 at 08:46:00AM +1100, William via Bird-users wrote:
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. You could also try more recent branch 'oz-evpn' (although the following patch related to VNIs is also not included there).
There are some configuration changes in this branch, encapsulation-specific options are in its own subblock:
protocol evpn { eth { table etab2; }; evpn;
encapsulation vxlan { tunnel device "vxlan2"; router address 10.1.1.1; };
rd 1:12; route target (rt, 1, 0);
tag 2; vni 12; }; I wonder if there is something different in the way the IMET routes are put together there? The "encapsulation vxlan" stanza doesn't exist in the main evpn branch which is making me think that might be causing another issue... <snip>
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? No, not really. It is just that EVPN/MPLS (RFC 7432) uses high 20 bits out of 24, while EVPN/VXLAN uses full 24 bits. But the BIRD EVPN BGP does not really care about whether it is MPLS or VXLAN (it could be any encapsulation if it is just an EVPN route reflector).
The attached patch switches BGP code to use full 24 bits. Patched my code and it works nicely! Thank you :) <snip> rd / route distinguisher? It works for me even there:
protocol evpn { ... # rd 1:13; rd 1005001:10040; route target (rt, 1, 0); ... } I've set the RD and RT back and it's working fine, not sure what was going on there
I've got mac-ip and imet routes floating around now, but the next issue is that the wrong next-hop is being set on the imet (and mac-ip) routes. Here's the evpn protocol definition: protocol evpn { eth { table etab; import all; }; evpn { }; rd 1005001:10040; import target (rt, 1004001, 10040); import target (rt, 1004003, 10040); export target (rt, 1005001, 10040); #encapsulation vxlan { tunnel device "vxlan100"; router address 2001:db8:ffff:1ad::501; #}; vni 10040; vid 40; debug all; }; vxlan100 is tied to lo100 with IP 2001:db8:ffff:1ad::501, but the EVPN session is tied to lo10 which has 2001:db8:ffff:1aa::501/128 (distributed via BGP IPv6 sessions to the spines). Here's the vxlan interface under the hood: # ip -d link show vxlan100 13: vxlan100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 42:a5:d1:11:88:4b brd ff:ff:ff:ff:ff:ff promiscuity 1 allmulti 1 minmtu 68 maxmtu 65535 vxlan id 0 local 2001:db8:ffff:1ad::501 srcport 0 0 dstport 4789 ttl auto ageing 300 external nolearning <snip> # bridge vlan show port vlan-id br1 1 PVID Egress Untagged vxlan100 40 vl40 40 PVID Egress Untagged # However when I look at the Arista vEOS Lab nodes, I see this ('sh bgp evpn vni 10040 detail', just the relevant portions pertaining to bird): BGP routing table entry for mac-ip 42a5.d111.884b, Route Distinguisher: 1005001:10040 Paths: 1 available 4201003001 4201005001 2001:db8:ffff:1aa::501 from 2001:db8:ffff:1aa::1 (192.168.1.10) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, best Extended Community: Route-Target-AS4:1005001:10040 VNI: 10040 ESI: 0000:0000:0000:0000:0000 BGP routing table entry for mac-ip 7e59.8de3.ed71, Route Distinguisher: 1005001:10040 Paths: 1 available 4201003001 4201005001 2001:db8:ffff:1aa::501 from 2001:db8:ffff:1aa::1 (192.168.1.10) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, best Extended Community: Route-Target-AS4:1005001:10040 VNI: 10040 ESI: 0000:0000:0000:0000:0000 <snip> BGP routing table entry for imet 2001:db8:ffff:1ad::501, Route Distinguisher: 1005001:10040 Paths: 1 available 4201003001 4201005001 2001:db8:ffff:1aa::501 from 2001:db8:ffff:1aa::1 (192.168.1.10) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, best Extended Community: Route-Target-AS4:1005001:10040 VNI: 10040 PMSI Tunnel: Ingress Replication, MPLS Label: 10040, Leaf Information Required: false, Tunnel ID: 2001:db8:ffff:1ad::501 Looking at other imet and mac-ip routes I can see that the next hop is correct for those nodes. Here's another example for one of the Arista leafs: BGP routing table entry for mac-ip 0050.0000.2c01, Route Distinguisher: 1004003:10040 Paths: 2 available 4201003001 4201004003 2001:db8:ffff:1ad::403 from 2001:db8:ffff:1aa::1 (192.168.1.10) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, ECMP head, ECMP, best, ECMP contributor Extended Community: Route-Target-AS4:1004003:10040 TunnelEncap:tunnelTypeVxlan VNI: 10040 ESI: 0000:0000:0000:0000:0000 4201003001 4201004003 2001:db8:ffff:1ad::403 from 2001:db8:ffff:1aa::2 (192.168.1.11) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, ECMP, ECMP contributor Extended Community: Route-Target-AS4:1004003:10040 TunnelEncap:tunnelTypeVxlan VNI: 10040 ESI: 0000:0000:0000:0000:0000 BGP routing table entry for imet 2001:db8:ffff:1ad::403, Route Distinguisher: 1004003:10040 Paths: 2 available 4201003001 4201004003 2001:db8:ffff:1ad::403 from 2001:db8:ffff:1aa::2 (192.168.1.11) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, ECMP head, ECMP, best, ECMP contributor Extended Community: Route-Target-AS4:1004003:10040 TunnelEncap:tunnelTypeVxlan VNI: 10040 PMSI Tunnel: Ingress Replication, MPLS Label: 10040, Leaf Information Required: false, Tunnel ID: 2001:db8:ffff:1ad::403 4201003001 4201004003 2001:db8:ffff:1ad::403 from 2001:db8:ffff:1aa::1 (192.168.1.10) Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, external, ECMP, ECMP contributor Extended Community: Route-Target-AS4:1004003:10040 TunnelEncap:tunnelTypeVxlan VNI: 10040 PMSI Tunnel: Ingress Replication, MPLS Label: 10040, Leaf Information Required: false, Tunnel ID: 2001:db8:ffff:1ad::403 It shows the proper next-hop IP for remote hosts. That information is happily put into the bridge FDB: 00:50:00:00:12:01 dev vxlan100 vlan 40 extern_learn master br1 00:50:00:00:2c: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:50:00:00:2c:01 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 10040 self extern_learn permanent 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:ffff:1ad::403 vni 10040 self extern_learn permanent 7e:59:8d:e3:ed:71 dev vl40 vlan 40 master br1 permanent 7e:59:8d:e3:ed:71 dev vl40 master br1 permanent 33:33:00:00:00:01 dev vl40 self permanent 01:00:5e:00:00:01 dev vl40 self permanent bird> sh route table etab Table etab: 7e:59:8d:e3:ed:71 vlan 40 unicast [bridge1 18:45:27.117] * L (0) dev vl40 00:00:00:00:00:00 vlan 40 unicast [evpn1 18:58:54.908] * (80) via 2001:db8:ffff:1ad::403 on vxlan100 mpls 10040 42:a5:d1:11:88:4b vlan 40 unicast [bridge1 18:45:27.117] * L (0) dev vxlan100 06:06:4f:2b:a5:e6 vlan 1 unicast [bridge1 18:45:27.117] * L (0) dev br1 00:50:00:00:2c:01 vlan 40 unicast [evpn1 21:41:13.227] * (80) via 2001:db8:ffff:1ad::403 on vxlan100 mpls 10040 00:50:00:00:12:01 vlan 40 unicast [evpn1 21:43:01.278] * (80) via 2001:db8:ffff:1ad::401 on vxlan100 mpls 10040 bird> sh route table evpntab Table evpntab: evpn imet 1005001:10040 0 2001:db8:ffff:1ad::501 [evpn1 18:58:54.908] * (120) evpn imet 1004003:10040 0 2001:db8:ffff:1ad::401 [SPINE1_EVPN 17:52:18.800 from 2001:db8:ffff:1aa::1] * (100) [AS4201004001i] evpn imet 1004003:10040 0 2001:db8:ffff:1ad::403 [SPINE1_EVPN 17:52:18.800 from 2001:db8:ffff:1aa::1] * (100) [AS4201004003i] evpn mac 1005001:10040 0 42:a5:d1:11:88:4b * mpls 10040 [evpn1 18:58:54.908] * (120) evpn mac 1005001:10040 0 7e:59:8d:e3:ed:71 * mpls 10040 [evpn1 18:58:54.908] * (120) evpn mac 1004003:10040 0 00:50:00:00:2c:01 * unicast [SPINE1_EVPN 21:41:13.227 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004003i] via 2001:db8:ffff:1f3::8 on ens4 mpls 10040 evpn mac 1004003:10040 0 00:50:00:00:12:01 * unicast [SPINE1_EVPN 21:43:01.278 from 2001:db8:ffff:1aa::1] * (100/?) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 mpls 10040 bird> bird> sh route table master6 Table master6: 2001:db8:ffff:1aa::1/128 unicast [SPINE1_BGP 17:52:15.287] * (100) [AS4201003001i] via 2001:db8:ffff:1f3::8 on ens4 2001:db8:ffff:1ad::501/128 unicast [direct1 17:52:13.958] * (240) dev lo100 2001:db8:ffff:1aa::401/128 unicast [SPINE1_BGP 17:52:15.287] * (100) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 2001:db8:ffff:1ad::401/128 unicast [SPINE1_BGP 17:52:15.287] * (100) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 2001:db8:ffff:1aa::501/128 unicast [direct1 17:52:13.958] * (240) dev lo10 2001:db8:ffff:1aa::402/128 unicast [SPINE1_BGP 17:52:15.287] * (100) [AS4201004001i] via 2001:db8:ffff:1f3::8 on ens4 2001:db8:ffff:1ad::403/128 unicast [SPINE1_BGP 17:52:15.287] * (100) [AS4201004003i] via 2001:db8:ffff:1f3::8 on ens4 2001:db8:ffff:1f3::8/127 unicast [direct1 17:52:13.958] * (240) dev ens4 2001:db8:ffff:1aa::2/128 unicast [SPINE1_BGP 17:52:15.331] * (100) [AS4201003001i] via 2001:db8:ffff:1f3::8 on ens4 2001:db8:ffff:1aa::403/128 unicast [SPINE1_BGP 17:52:15.287] * (100) [AS4201004003i] via 2001:db8:ffff:1f3::8 on ens4 bird> I don't know if it's something weird I've done or if my implementation is just whacked out but this seems to be the last hurdle I'm seeing BUM coming through from one of the hosts attached to a leaf: 21:43:47.974972 IP6 2001:db8:ffff:1ad::401.60846 > 2001:db8:ffff:1ad::501.4789: VXLAN, flags [I] (0x08), vni 10040 ARP, Request who-has 100.64.40.254 tell 100.64.40.18, length 46 21:43:47.976451 IP6 2001:db8:ffff:1ad::401.60846 > 2001:db8:ffff:1aa::501.4789: VXLAN, flags [I] (0x08), vni 10040 ARP, Request who-has 100.64.40.254 tell 100.64.40.18, length 46 but it's going to both loopback addresses (the BGP one and the vxlan terminator) For what it's worth, 'bridge vlan add dev vxlan100 vid 40 tunnel_info id 40' errors out. The readme on https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp has typos in the commands too. Feel free to bug me off-list for more detail, this is getting long-winded... Regards, William -- This email has been checked for viruses by Avast antivirus software. www.avast.com