The config in VyOS is stored in /config/config.boot as json-file.

Would be handy if a config replace would accept both show config and show config commands as inputs.

I think most implementations in VyOS regarding source-interface is referencing physical or logical interfaces and not VRF's even if VRF's is an "interface" in Linux (which can be seen if you do ip a in bash mode).

Why does it phone home like this?

Again, VRF is selected through both bindacqdevice and binddevice so having "asymmetric incoming/outgoing VRF binding" works perfectly fine.

@L0crian: When you did that test did you try to reboot in between?

Its worsen the situation since selecting source-address wont work if thats in a different vrf so that smoketest will fail where it shouldnt.

Is this the same (exists in Stream 2026.03)?

Also currently missing in Stream 2026.03:

It seems that this change occurs behind the scenes as in not a configurable option. Being dealt with by adjusting buffers so jumboframes are still properly supported (even if DPDK documentation claims this is NOT compatible with jumbo frames!?).

How will it work if I got 2 different VRFs?

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:

Is this also true for multiple users so they not all end up with vyos:users?

Will chmod and chown be preserved on the directories and files being copied?

This issue remains in july 2026 using VyOS Stream 2026.03.

A workaround for NTP and DNS-server is to use containers and allow-host-networks in case the container itself have support for VRF (aka SO_BINDTODEVICE seen through "ss -atulpn" that the process listens to for example 192.0.2.1%PROD:123 instead of just 192.0.2.1:123).

Perhaps time for VyOS to overall move to Debian 13 (trixie) as base?

Related: https://vyos.dev/T8940

Why not use already existing prebuild FIPS edition of OpenSSL available in Debian?

According to:

Current kernel config available at:

Just guessing.

I want to have a 2nd opinion on that following this forum post:

I found this as a workaround but again would be handy if things would work out of the box :-)

Another option/workaround would be if something like "config replace" would be supported where the input could be a "config.cmd".

A workaround to using a custom private registry is to manually preload the images.

Probably related:

I agree.

There do currently exist an authoritive DNS server in VyOS.

Might be related:

Since its a generate command, could the output also include the maths behind selected values?

My €0.05 in this topic is if the "ipv6 address autoconf" should instead be named "ipv6 address slaac" since after all the feature is named "stateless address autoconfiguration" aka slaac and not necessary "autoconf". But I think its a matter of taste if it should be called "autconf" or "slaac".

Regarding "how others do this":

Also relevant refs:

Comparing to other vendors this setting should be set on interface level and not in bgp settings.

Im also getting a 404 for the commit link posted at 2025-03-23 11:50.

In T6821#217838, @evgmol wrote:

Are we happy with the above patch (fixing the terminal)?

This error is still in progress over at: https://github.com/vyos/vyos-nightly-build/releases

Care to elaborate on why this was denied?

I would prefer if both disabled, all, rx-only and tx-only setting could be applied.

Dunno how this is done for IPv6 but for IPv4 we got these kernel parameters to play with:

"Failed to listen on syslog.socket" doesnt look good if you ask me ;-)

Probably related:

It looks like this commit wasnt properly tested before pushed to the public tree according to:

Wouldnt be surprised if it turns out to be the same root cause as this is related to:

"blackhole" is a common term in regards of dropping traffic.

Personally I would still prefer the later that is with DebianBanner no.

This task can remain closed - I have created a new task instead:

The new package exists at: https://github.com/vyos/vyos-build/tree/current/scripts/package-build/xen-guest-agent

For KEA6 its defined as "The IPv6 address of a TFTP server" with example of IPv6-address:

If its common of this misuse of option66 I would suggest that VyOS would allow for URI characters (@, :, / and what else) but type a warning during re/config like:

@syncer Yeah, it was at the forum:

According to https://old.reddit.com/r/vyos/comments/1ggzxye/setting_forward_error_correction_in_vyos/lv09d09/ using eth-tool to both set (and show) current fec-setting(s) should be doable (tested on Intel and Mellanox nics using transceivers from FS.com, Flexoptix and Mikrotik):

Thanks - resolved means its implemented as the blog post stated :-)

The blog post over at https://blog.vyos.io/vyos-project-october-2024-update claims this have been implemented, there is a merge from 10th sept 2024 claiming to be merged - yet this task have been closed with "not applicable - out of scope for VyOS".

@marekm: Bugfixes will be towards current (aka 1.5-rolling as of writing) which then is being cherrypicked and backported by VyOS Networks to whatever older releases that needs that and are compatible with the change/fix/added feature.

Im guessing this one is behind that all modules must now be signed in VyOS:

Technically according to IEEE autoneg is mandatory when doing 1Gbps and above using RJ45.

Also probably related:

I would expect the line of CLI being used to be in any of these files?

As the message currently states over at https://sourceforge.net/projects/e1000/

Here are my €0.05:

https://vyos.io currently works from Sweden when I tested it at about 2024-08-31 11:30 local time.

Might be related patches (no idea if they have anything to do with the kernel panics seen in 6.6):

From IRC, could this be related?

Are the in-tree or out-of-tree drivers for your Intel NICs being used?

I sure hope this custom waagent build will be removed once the upstream (debian packages) have been updated with this fix.

Personally I thing there should be a difference between setting PKI manually like set pki certificate and set pki ca vs whatever the command is to utilize letsencrypt or acme or whatever they might be called automatically through VyOS (lets say set pki letsencrypt and set pki acme etc).

Care to elaborate some on that "data integrity issues" claim since you will have integrity changed by all sort of writes (atomic or not)?

There are 2 usecases of option82 when it comes to DHCP:

The suggested change as in matching number of "x" with number of characters in each octet/hextet in the IPv4/IPv6 address will be less anonymizing than todays method.