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/b0ff170fbc70bfc978efe92257ca8b49dbdbaf92
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: [email protected])
"To err is human -- to blame it on a computer is even more so."
