Hoi,
On 10.03.2026 15:23, Pim van Pelt via
Bird-users wrote:
However,
the issue that only one such IMET makes it from evpntab to etab
remains, I would expect three for each VNI.
In evpn_receive_imet(), struct rte_src *s =
rt_get_source(&p->p, rd_to_u64(n0->rd)); which
makes all IMET routes share the same rte_src (for these routes in
VNI 20040, the RD is a constant 8298:200), so all three remote IMETs
for ::1 ::2 and ::3 will get the same value of s. Is that
intentional?
The way I understand it, each call to rte_update2() overwrites the
previous (net, rte_src), so the last IMET received wins, the earlier
two ones are discarded, and we end up with always one etab entry. I
don't see how
One possible fix is to use the originator IP (n0->rtr) or perhaps
the BGP router-id (ref->src->proto->remote_id) as the
source key instead of the RD, so each remote IMET speaker gets its
own rte_src? Perhaps something like evpn_imet_multipath.patch [as an
example, not something I expect you to merge], which when applied
does give me the desired outcome:
root@vpp0-0:~# birdc show route eth 00:00:00:00:00:00 vlan 100 table
etab
BIRD 2.18+branch.oz.evpn.2adc66776d5d ready.
Table etab:
00:00:00:00:00:00 vlan 100 mpls 10040 unicast [evpn1 21:52:04.008] *
(80)
via 2001:678:d78:200::1 on vxlan0 mpls 10040
unicast [evpn1 21:52:05.449] (80)
via 2001:678:d78:200::2 on vxlan0 mpls 10040
unicast [evpn1 21:52:11.849] (80)
via 2001:678:d78:200::3 on vxlan0 mpls 10040
root@vpp0-0:~# birdc show route eth 00:00:00:00:00:00 vlan 200 table
etab
BIRD 2.18+branch.oz.evpn.2adc66776d5d ready.
Table etab:
00:00:00:00:00:00 vlan 200 mpls 20040 unicast [evpn2 21:52:04.008] *
(80)
via 192.168.10.1 on vxlan0 mpls 20040
unicast [evpn2 21:52:05.449] (80)
via 192.168.10.2 on vxlan0 mpls 20040
unicast [evpn2 21:52:11.849] (80)
via 192.168.10.3 on vxlan0 mpls 20040
groet,
Pim
--
Pim van Pelt <pim@ipng.ch>
PBVP1-RIPE https://ipng.ch/