'Resolved for the rolling

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

https://github.com/vyos/vyos-1x/pull/5195

According to https://github.com/FRRouting/frr/issues/12834, FRR does not support Link-Local: 169.254.0.0 – 169.254.255.255 (Automatic private IP addressing)

To be noted that "Logical interface" (like dummy), and physical interfaces, do work. However, virtual interfaces (vif) don't.

dum0         192.168.100.1/24  c2:2b:d5:03:56:48  CUST-DEMO1   1500  u/u
eth0         -                 0c:b7:52:32:00:00  default      1500  u/D
eth1         -                 0c:b7:52:32:00:01  default      1500  u/u
eth1.504     10.208.91.11/31   0c:b7:52:32:00:01  default      1500  u/u    Peer1
eth1.999     169.254.10.1/24   0c:b7:52:32:00:01  CUST-DEMO1   1500  u/u
eth2         -                 0c:b7:52:32:00:02  default      1500  u/D
eth3         -                 0c:b7:52:32:00:03  default      1500  u/D
eth4         -                 0c:b7:52:32:00:04  default      1500  u/D
eth5         -                 0c:b7:52:32:00:05  default      1500  u/D
lo           127.0.0.1/8       00:00:00:00:00:00  default     65536  u/u
             10.208.90.5/32
             ::1/128

BGP table version is 1, local router ID is 10.208.90.5, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

In my opinion, the global state-policy should also trigger conntrack VRF zone mapping. Until we have other restrictions, I'd say it's a bug.

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

https://github.com/vyos/vyos-1x/pull/5005

PR:
https://github.com/VyOS-Networks/vyos-1x/pull/1666

https://github.com/vyos/vyos-build/pull/1109

Note that for 1.4.x there may be a separate cause of the false positive due to the older migration system (revised in 1.5); this is under investigation.

Note that this was fixed in https://vyos.dev/T7319 and backported for inclusion in 1.4.4. However, it will necessarily only apply to any upgrades from that version forward, e.g. 1.4.4 -> 1.4.5

Might be related:

In T4001#173519, @Viacheslav wrote:

Needs to re-check for 1.4/1.5

With nightly 2025.09.01-0023-rolling it is working (maybe the last kernel bump fixed it ?) :

I retriggered build
Both packages in the repo
https://packages.vyos.net/repositories/current/pool/main/r/radvd/

I did the same tests before updating this task, and it seemed like the code and build steps were fine.

Well, I'm stumped. Just to be sure the radvd developers didn't forget to change the string in the v2.20 version output, I tried manually compiling radvd v2.20 on a test Debian VM:

Hi @opswill, that is very strange. I'm not too familiar with the VyOS build process as far as dependencies go, but I'll look into it.

Has anyone tested this?

https://github.com/vyos/vyos-1x/pull/4420

MITRE has assigned CVE-2025-30095.

Did you have a chance to testing ?

Looks like it was assigned too restrictively before.

Hi there,

Is there anyone else we should tag on this ticket?

@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

@Viacheslav Yes, I will test it once it is included in the next rolling release.