This includes but not limited to:
- Updating the CI workflows
- Troubleshooting the upstream provider changes
- Fixing failing tests
- Assisting contributors with their PRs, reviewing their PRs
- Updating branches
This includes but not limited to:
It was available in 1.4 but with different variable name WLB_SCRIPT_IFACE-
The only requirement I have for this change is that the MTU versus performance conflict should be resolved completely on our side and be transparent to users. Maybe by tuning buffers data-size so they fit Jumbo frames when needed, if this solves the problem.
Do you know the version where it worked at all?
I believe we didn't pass those info to the health check scripts. If so, it should be a feature request and not a bug report.
Companion PR for the CLI side: https://github.com/vyos/vyatta-cfg/pull/153
i report them on github security advisor
About point 2.
I observe that traffic that matches peer policies is encrypted. BUT this peer is disabled.
If I execute sudo swanctl -L , it shows nothing. But if I execute sudo ip xfrm policy, it shows polices, that were disabled in the configuration.
I think the root cause is rtradv = conf.get_config_dict(base, key_mangling=('-', '_'), get_first_key=True) in service_router-advert.py ,not sure why need key_mangling .
The real cause is in the PKI/ACME pipeline. When an ACME cert is issued, pki.py imports the intermediate as pki ca AUTOCHAIN_<cert> and triggers dependent services (HAProxy included) to regenerate within the same commit. But that regeneration reuses an in-memory config object whose cache was already populated before the import happened, so it never sees the new CA. HAProxy's chain logic then has nothing to find.
On Stream 2026.03 (runned virtualized in Proxmox, the virtual drive is configured with discard and ssd in VM-guest settings i Proxmox and the host drive is using ZFS) it do seem to be working when running with sudo but not without sudo:
Bug reproduced on image 2026.07.21-1151-rolling and proposed patch tested.
Forgot to mention that lacking proper FS trimming has a very negative impact when running VyOS virtualised and having the filesystem sitting on a thin provisioned volume, like for instance LVM thin. The absence of discard commands coming from the virtual node does not allow the cleaning of unused blocks.
A PR was submitted:
https://github.com/vyos/vyos-1x/pull/5353/changes
@RubenNL thanks for looking into this
I believe the module is misused, that is why the result is not as expected.
Hi @syncer @sever and @dmbaturin !
Can we discuss the need in this feature.
JunOS has never implemented it (despite the PR above), yet vyos.vyos seems to use ActonNetworkModule from netcommon Galaxy collection - it is maintained, patched and works well.
Having own action plugin will mean we will need to build it separately and maintain to meet Ansible version.