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-RIPEhttps://ipng.ch/