After the testing with a standalone User-Data handler, this feature was ported to the main cloud-init package in https://github.com/vyos/vyos-cloud-init/pull/27.
Currently, supported only set and delete commands processing. They must be provided as a list in the vyos_config_commands option.

https://github.com/vyos/vyatta-cfg-quagga/pull/59

Hi there,

vyatta-biosdevname:
https://github.com/vyos/vyatta-cfg-system/blob/ebbdfe44aa321a2de35ddccaa255d384a5fd99e4/scripts/vyatta_net_name#L96
Used for calculating initial interface order, to try getting a ordered list and not only the random init-order used by the kernel

Does it possible to cherry-pick to 1.3? Because in 1.3 rollings we have the same bug.

PR https://github.com/vyos/vyatta-wanloadbalance/pull/8

vyatta-webproxy: 80% done, @cpo grabbed it since I had no time to continue for a while and put it on hold. I removed obsolete options which implies the need of a migration script. Ldap, AD, IP and user/passwd auth works, I removed caches, squidguard, include domain filters (just a list) and so on, but I stopped it now since it's been taken away.

Kernel modules are pre-compiled and can be loaded.

I got this when several times change boot with

set system image default-boot

1.2.6 => 1.3 => 1.2.6 => 1.3

I successfully update the image from 1.2.6-s1 to VyOS 1.3-rolling-202012231522

Thanks for the feedback and telling us about how to solve this issue.

Successfully tested on 1.3-rolling-202012230217

The main problem is that you use the same name for different group types.

@tjh How you want to integrate it with CLI or use it as a separate pkg?

The issue turned out to be at the host level. By default SR-IOV VFs are not allowed to change their own mac addresses or send packets with a different mac address, and since this is required for LACP bonding the configuration would just fail.

@robertoberto Can you provide next commands?

show interfaces ethernet eth0 physical
sudo ethtool -k eth0 | grep offload

Put in a PR to add LDP ordered control operation for LDP.

@primoz What are the benefits?

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

https://github.com/vyos/vyatta-cfg-system/pull/134

This breaks with common configuration patterns/naming in Wireguard. Nobody will know what you're talking about when you say address and port in this context. And the CLI helpers adds documentation that would lead you to believe you are listening for connections, see line 105 in nterface-definitions/interfaces-wireguard.xml.in.

dhcpcd is a pretty good alternative. Well maintained and popularly used by many. I used it in a plain Linux router project and it was good enough for my use cases.

PR for crux https://github.com/vyos/vyos-build/pull/138

It still would be nice though. ANy other good IPv6 DHCP clients out there?

Yeah also it looks like wide is hardcoded to support only type 1 DUID (LLT) anyway.... so probably it wasn't accidentally "forgotten" in 1.3 migration that someone probably has realized it wasn't viable to support it... Thanks :)

Undortunately it only worked in 50% of the cases properly. Also there is only one global duid file so you can not have multiple duids (one per each interface).

@vagardx thank you for this rant.

Sorry I am confused. I took a brief look at the code of dhcp6c and it appears manually modifying the dhcp6c_duid file should be able to keep the change persistent: https://github.com/jinmei/wide-dhcpv6/blob/24ee2a4f0009bc6ac9bd0b7b737aef93a4aa9905/common.c#L992. Did I miss anything? Thanks :)

Accidentally deleted the comment. Is there plan to migrated to dhcpcd instead? dhcpcd has good ipv6 support and being actively maintained too. Thanks.

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

This breaks with standard configuration convention in Wireguard. Also, no documentation has been updated to reflect this breaking change.

I want to know the behavior of the implementation when upgrading the vyos version