Hi Sorry for late answer, some comments below. On Fri, Feb 20, 2026 at 01:24:07PM +0100, Pim van Pelt via Bird-users wrote:
Note that you should read IMET from etab too. EVPN protocol translate all IMETs from evpntab to etab, otherwise even our kernel-based setup would not work -- 'bridge' protocol that configures kernel bridge also reads just etab. I do not have multiple IMETs in etab, only one: root@vpp0-0:/etc/bird# birdc show route table evpntab | grep imet evpn imet 8298:100 0 2001:678:d78:200::3 [vpp0_3 12:12:38.484 from 2001:678:d78:200::3] * (100) [i] evpn imet 8298:100 0 2001:678:d78:200::2 [vpp0_2 11:18:21.821 from 2001:678:d78:200::2] * (100) [i] evpn imet 8298:100 0 2001:678:d78:200::1 [vpp0_1 11:18:21.253 from 2001:678:d78:200::1] * (100) [i] evpn imet 8298:100 0 2001:678:d78:200:: unicast [evpn1 11:18:07.285] * (120)
root@vpp0-0:/etc/bird# birdc show route table etab | grep 00:00:00: 00:00:00:00:00:00 vlan 100 mpls 10040 unicast [evpn1 12:12:38.484] * (80)
Perhaps I'm holding it wrong (see bird-example.conf). It would actually be super if I could rely /only/ on etab, as tracking both etab and evpntab was a fair amount of extra code.
Yes, the grep does not work, as the second route does not repeat NLRI in show route output: bird> show route 10.1.2.0/24 table master4 Table master4: 10.1.2.0/24 unicast [ospf4 01:50:45.246] * I (150/20) [10.0.1.2] via 10.1.21.2 on ve1 unicast [ibgp1 01:50:46.919 from 10.1.2.1] (100/20) [i] via 10.1.21.2 on ve1 bird> show route eth 00:00:00:00:00:00 table etab2 Table etab2: 00:00:00:00:00:00 mpls 12 unicast [evpn1 01:50:46.919] * (80) via 10.1.2.1 on vxlan2 mpls 200022 unicast [evpn1 01:50:47.001] (80) via 10.1.3.1 on vxlan2 mpls 30
I do not like using regular/immediate next hops here in EVPN table, as it does not fit well semantically and requires formal device. But seems to me that a reasonable alternative would be to just attach BGP_NEXT_HOP by EVPN protocol, similarly how BGP_PMSI_TUNNEL is attached. Wil do that. Any comments? If you were to attach a specific attribute like vxlan_nexthop or vxlan_vni to the etab table entry, I would simply read that and use it instead of the bgp nexthop. That's what happens already today for IMET, as it has the BGP.pmsi_tunnel attribute with the needed ingress-replication 2001:678:d78:200::2 mpls 10040 information. How do other vendors (say Arista, Cisco, Nokia, FRRouting) handle the Type-2 nexthop? My understanding is they use BGP next hop for that (in other words, the same as how Bird does it today). I think there is some confusion here. I am talking about evpntab entries, not about etab entries. And about your patch that sets router IP into their immediate next hop (nh.gw). I see - then maybe I can try a different approach. The patch, I thought, makes Bird behave the same as Nokia SRLinux {1], which also sets the router ip (the local VTEP) as nexthop but what you're saying is I should not set the /immediate/ nexthop, but rather leave that alone and set the /BGP Next Hop/? Although as a reminder, I need to be able to set an IPv4 BGP Next Hop on an IPv6 session only for some RTs, not all. See one more thought on that below ..
Look at the patch: https://gitlab.nic.cz/labs/bird/-/commit/b0ff170fbc70bfc978efe92257ca8b49dbd... EVPN originates routes already with BGP next hop based on configured router ip (in evpn_announce_mac() / evpn_announce_imet()) while bgp_use_next_hop() has a case to always keep such next hops. So if you have one EVPN proto with IPv4 router address and another with IPv6 router address, so BGP Next Hop would be set to the appropriate address in each case. (not yet a patch for dummy tunnel ifaces) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."