@c-po @zsdc can we consider this task as done or not yet?

configure
set interface eth0 address '192.0.2.1/24'
for vid in $(seq 1 1000); do set interfaces ethernet eth0 vif $vid address 10.$((vid/256)).$((vid%256)).1/24; done
time commit

BTW, I run the setup from the reply above on a VRRP pair: fe80::1 is a VRRP virtual address, and both routers send RAs with source-address fe80::1, so only the router holding it advertises.

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

Fixed in the https://vyos.dev/T8329 for the rolling
https://github.com/vyos/vyos-build/pull/1249
https://github.com/vyos/vyos-1x/pull/5338

I stumbled across the same issue and as far as i could debug it, its due to usb/hid devices being outosuspended by the current vyos kernel/config.

PR https://github.com/vyos/vyos-build/pull/1249

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

Regarding (1) above: form-POST requests are preprocessed by overriding the route handler before delivery to the endpoint, hence managed by background operations as any JSON formatted request. Regarding (2), thanks for the offer to open a separate task; that would be helpful.

For clarification.
I have created a lab

We hit a related but possibly distinct failure on VyOS 1.5 Circinus rolling (2026-07-06) and would like to confirm the scope of the background-operations fix (https://github.com/vyos/vyos-1x/pull/4953):

Just bumped into the fact appearently this wasn't implemented for all groups, getting an "include is not valid" for a domain-group.

I found it with some help of claude ... It was a problem with conntrack in this setup. I could fix it on 1.4 only manual with this commands:

Good to know 1.3.8 is not affected, so having been denied access to later versions saved me from this vulnerability - thanks @syncer !
BTW, please also check out Dirty Frag while you're at it, no CVE yet. Mitigation (disallow loading of modules: esp4, esp6, rxrpc) breaks ipsec.

PR https://github.com/vyos/vyos-build/pull/1176

Versions up to v1.3.8 are not affected. However, from v1.4.x onwards, including v1.5.0 and Rolling releases, all versions are affected.

Probably related:

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

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

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

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

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

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

The PR that adds background operations is now merged so I suppose we can close the task.

FRR PR: https://github.com/FRRouting/frr/pull/20947

some information added which is related to SH filters as well :

There is an unexpected / for the template https://github.com/vyos/vyos-1x/blob/d6fdf9db8497164921afb28abc22f1c7bcd18f52/data/templates/telegraf/telegraf.j2#L48
Should be rewritten to process this case

PR which contains an in-memory background operation manager that queues full configure operations as a single job:

• https://github.com/vyos/vyos-1x/pull/4953

Thank you. I see my mistake now. When I read under step 3, "Optionally, the user can attach a CDROM with an ISO as a cloud-init data source", it left me with the impression this was *optional*—that skipping this would not cause problems. I didn't realize that it would mean no default username/password would be set.

If you use the official proxmox image, you have to use cloud-init to set login/pass for the proxmox flavors.
Feel free to improve the documentation.
Thanks.