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,

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.