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
