In T7215#217255, @c-po wrote:

Hi @MPStudyly,

can it be the case that your system you're running the test son already has a VRF named red?

FRR changed this behavior several times https://github.com/FRRouting/frr/commit/322462920e2a2c8b73191c6eb5157d64cf4a593e
Sometimes it is disabled by default, sometimes enabled :)
So, depending on the FRR version, the behavior could be different.

Should be fixed in https://vyos.dev/T7123
And/Or https://github.com/vyos/vyos-1x/commit/23477683cea2777f570ac0d98098aa2c6f041661
Can you try the latest rolling?

can it be the case that your system you're running the test son already has a VRF named red?

Hello! Any news regarding this issue?

Just to add to the argument: Using the build_type to determine if the banner gets shown or not would allow individual/custom builds to have it disabled as well (we know what we are doing). Obviously I can just speak for my use case, where we roll our own builds to get back qemu-guest-agent. I can't tell if this would go against the intention of introducing this banner in the first place.

In T7206#216891, @danielr1996 wrote:

I tried adding

[[includes_chroot]]
  path = "opt/vyatta/etc/config/config.boot"
  data = ""

to the build flavor, and now it seems to work.

I still get warning in the cloud init log, but so far I haven't noticed anything not working. This works as a workaround for me, but I still think that this is a bug.

@treo Could you check the latest rolling to confirm if everything works as expected?

With T6641 implemented and a discussion with @jestabro and @dmbaturin this would be a perfect addition.

@daniel.arconada can you check this? The latest rolling has these modules.

vyos@vpp-left:~$ zcat /proc/config.gz | grep -i vdpa
CONFIG_VIRTIO_VDPA=m
CONFIG_VDPA=m
# CONFIG_VDPA_USER is not set
# CONFIG_MLX5_VDPA_NET is not set
# CONFIG_MLX5_VDPA_STEERING_DEBUG is not set
# CONFIG_VP_VDPA is not set
# CONFIG_ALIBABA_ENI_VDPA is not set
# CONFIG_SNET_VDPA is not set
CONFIG_VHOST_VDPA=m
vyos@vpp-left:~$ 
vyos@vpp-left:~$ show ver
Version:          VyOS 1.5-rolling-202503020018

@pasik Hi mate! Were you the original reporter of this bug please?
If so, can you clarify a few questions I asked above?
thank you

I don't think the original work around would work with Kea becuase how the Jinja is formatted, but expanding on this for Kea specifically, a couple of things that would need to be implemented would be client classes that match have some type of match

Not reproduced anymore

In T7213#217158, @freebsdjlu wrote:

sorry , I thought the function should be "match mark 2 and use route table 200" , there is some misunderstanding , but if I only want route based on the mark ,not to change it , how to do it ?

https://github.com/vyos/vyos-vpp/pull/23

btw , could we add a feature to support tproxy when do pbr ?

sorry , I thought the function should be "match mark 2 and use route table 200" , there is some misunderstanding , but if I only want route based on the mark ,not to change it , how to do it ?

set policy route tproxy rule 100 mark '2'
set policy route tproxy rule 100 set table '200'

Add set of commands to reproduce.

Can we close it?

I cannot see the virtual interface names are supported in 1.3-1.5 -