In T8496#264157, @vvmsq wrote:

This was after building kernel + modules myself - end result was much larger than expected - it's definitely possible/probable I did something wrong and included packages that weren't needed without noticing if regular builds are coming out fine. Apologies for the mistake.

PR https://github.com/vyos/vyos-1x/pull/5149

@c-po I see that you've been updating kernels recently, do you happen to know an answer to point b) from above?

@Viacheslav Sure, can do. Currently already building it, so I can as well just share the modifications.

Relevant:
https://github.com/FRRouting/frr/pull/21450
https://github.com/FRRouting/frr/pull/21406
https://github.com/FRRouting/frr/pull/21486

Working on this and pretty much done, but blocked by https://vyos.dev/T8443 and https://vyos.dev/T8442

<Ignore what was here before, I completely misread your report>

Related: https://vyos.dev/T5189#248930

Update February 3rd, 2026
I noticed that this config path DOES exist, but is also not documented in VyOS!

It seems to be possible to configure the required MACVLAN / pseudo-ethernet interface on the bridge (despite not offered by the autocompletion):

pseudo-ethernet peth1 {
    address 10.255.11.1/24
    description "Anycast Gateway for VNI 1001"
    mac f6:54:73:26:5e:1f
    source-interface br1.1001
}

I suppose something like this could be sufficient:

protocols {
     bgp {
         address-family {
             l2vpn-evpn {
                 advertise-all-vni
             }
         }
         parameters {
             router-id 10.255.2.120
         }
         system-as 65000
     }
 }
 vrf {
     name vrf_Elim01 {
         protocols {
             bgp {
                 address-family {
                     l2vpn-evpn {
                         advertise-all-vni
                     }
                 }
                 parameters {
                     router-id 10.255.2.120
                 }
                 system-as 65000
             }
         }
         table 10001
         vni 10001
     }
 }

Interesting interpretation of the standard. Guess it's time to go bare metal again

This is not a bug, this is according to RFC

In T6281#185620, @c-po wrote:

You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)

In T6281#185394, @c-po wrote:

Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.

There is no possibility to source the wireguard interface from

• Another VRf
• A discrete source IP
• A discrete source interface

This can only be handled by applying fwmark values and policy based routing - this is a WireGuard design thing.

Running into this issue on VyOS 1.5-rolling-202404280021

set protocols static route xxx.xxx.74.149/32 dhcp-interface eth1.999