Setting bgp_next_hop in EVPN resets VNI
Hi all, Yesterday I was partying that I was able to inject static MAC-IP routes into EVPN on Bird 3.3.0 with the correct VNI using the mpls_label attribute. The joy was disturbed today, when I tried to set a different bgp_next_hop than the local host. As soon as I set the bgp_next_hop this forces the VNI/mpls_label to be encoded as 0. While the local export table shows the configured mpls_label, the remote side receives VNI=0.
From reading the code, I suspect that https://gitlab.nic.cz/labs/bird/-/blob/v3.3.0/proto/bgp/packets.c#L1321 is triggering this behaviour. I have no real clue how to get values into nhloc->labels (statically).
I found a workaround in explicitly setting next hop address in the BGP protocol's evpn channel. Yet my expectation would be that explicitly setting bgp_next_hop does not have any influence on treating the VNI/mpls_label. Abbreviated config: evpn table t_evpn; protocol static { evpn { table t_evpn; }; route evpn mac 172.25.110.202:100 0 c0:12:34:56:78:9a 2001:db8::1 drop; } filter export_evpn { if ( net.evpn_type = NET_EVPN_MAC ) then { bgp_ext_community.add((generic, 0x30c0000, 0x8)); bgp_ext_community.add((rt, 10, my_vlan)); bgp_ext_community.add((generic, 0x6000000, 0x0)); mpls_label = 100100; bgp_next_hop = 10.49.0.0; } accept; } protocol bgp core01 { local as my_asn; evpn { table t_evpn; import none; export filter export_evpn; next hop address 10.49.0.0; }; neighbor 172.25.110.201 as my_asn; } With this configuration the VNI in outbound UPDATE is set to 0. Without bgp_next_hop in the filter the BGP UPDATE contains VNI 100100. Best wishes, André -- André Grüneberg, Managing Director andre.grueneberg@bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
On Thu, May 28, 2026 at 04:29:36PM +0200, André Grüneberg wrote:
Hi all,
Yesterday I was partying that I was able to inject static MAC-IP routes into EVPN on Bird 3.3.0 with the correct VNI using the mpls_label attribute.
The joy was disturbed today, when I tried to set a different bgp_next_hop than the local host. As soon as I set the bgp_next_hop this forces the VNI/mpls_label to be encoded as 0. While the local export table shows the configured mpls_label, the remote side receives VNI=0.
From reading the code, I suspect that https://gitlab.nic.cz/labs/bird/-/blob/v3.3.0/proto/bgp/packets.c#L1321 is triggering this behaviour. I have no real clue how to get values into nhloc->labels (statically).
I found a workaround in explicitly setting next hop address in the BGP protocol's evpn channel.
Yet my expectation would be that explicitly setting bgp_next_hop does not have any influence on treating the VNI/mpls_label.
Hi Well, there are in fact three attributes for MPLS/VNI labels in BIRD. For one flow : mpls_label - label for the flow on the local system bgp_mpls_label_stack - label(s) on the bgp_next_hop system gw_mpls - label(s) on the immediate next hop (gw) system (unfortunately bgp_mpls_label_stack is internal and not really accessible from filters, gw_mpls is pseudoattribute associated with the next hop, but accessible by filter) BGP behavior is to announce MPLS label consistent with BGP next hop. So if it uses its own address in outgoing BGP next hop, it uses mpls_label. If it uses existing (third-party) bgp_next_hop, it uses bgp_mpls_label_stack. If it creates BGP next hop from gw attribute, it uses gw_mpls label. You can see the EVPN protocol behavior when it converts ethernet route to EVPN route (which has both mpls_label and BGP.mpls_label_stack): bird> show route table etab all Table etab: 4a:55:7b:73:f7:1c vlan 30 unicast [bridge1 18:37:40.738] * D (0) dev m32-ve1 Type: bridge univ Bridge.source: dynamic bird> show route table evpntab all Table evpntab: evpn mac 1:22 3 4a:55:7b:73:f7:1c * mpls 23 [evpn1 18:37:40.738] * (120) Type: EVPN univ mpls_label: 23 BGP.next_hop: 10.1.2.1 BGP.ext_community: (generic, 0x30c0000, 0x8) (rt, 1, 0) BGP.mpls_label_stack: 23 You can either use static ethernet routes and use EVPN proto to translate them, or you can set next hop as a BGP channel option instead of as a route property, to trick BGP thinking it is its own address and use mpls_label. -- 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."
Dear Ondrej, On Thu, 28 May 2026 at 18:59, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Thu, May 28, 2026 at 04:29:36PM +0200, André Grüneberg wrote:
The joy was disturbed today, when I tried to set a different bgp_next_hop than the local host. As soon as I set the bgp_next_hop this forces the VNI/mpls_label to be encoded as 0. While the local export table shows the configured mpls_label, the remote side receives VNI=0.
I found a workaround in explicitly setting next hop address in the BGP protocol's evpn channel.
So if it uses its own address in outgoing BGP next hop, it uses mpls_label. If it uses existing (third-party) bgp_next_hop, it uses bgp_mpls_label_stack. If it creates BGP next hop from gw attribute, it uses gw_mpls label.
You can see the EVPN protocol behavior when it converts ethernet route to EVPN route (which has both mpls_label and BGP.mpls_label_stack):
You can either use static ethernet routes and use EVPN proto to translate them,
As far as I can see, static eth routes do not support the IP part in mac-ip. As you can see from my example, I want to set real mac-ip routes -- because this is what I need for our distributed ARP/ND sponge: route evpn mac 172.25.110.202:100 0 c0:12:34:56:78:9a 2001:db8::1 drop;
or you can set next hop as a BGP channel option instead of as a route property, to trick BGP thinking it is its own address and use mpls_label.
Well, that's definitely a workaround for as long as I only need one next-hop. So maybe you have a good idea for modifying/fixing this in future.
Yet my expectation would be that explicitly setting bgp_next_hop does not
have any influence on treating the VNI/mpls_label.
... especially so when a show route export <proto> all shows the VNI set in the filter. IMO show route export should not differ from what goes onto the wire. Best wishes, André -- André Grüneberg, Managing Director andre.grueneberg@bcix.de +49 30 2332195 42 BCIX Management GmbH Albrechtstr. 110 12103 Berlin Germany Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B
participants (2)
-
André Grüneberg -
Ondrej Zajicek