You can create /use your own images

vyos@r4:~$ generate container image foo path 
Possible completions:
  <filename>            Path to Dockerfile

It looks fixed by the upstream

64 bytes from 8.8.8.8: icmp_seq=18 ttl=116 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=20.0 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=116 time=20.3 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=116 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=116 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=116 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=116 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=116 time=20.1 ms

It is not backported to 1.4
So for 1.3, it won't be backported

It was implemented around a year ago https://github.com/vyos/vyos-1x/commit/e201454f073c9a92fb56b65f497eae55fc634521
Just need to check if it works as expected.

In T6222#183247, @Chrisc-c-c wrote:

Wouldn’t your suggested fix to https://vyos.dev/T6223 also apply here? If the plan is to validate interface name lengths and allow custom names this would be a non-issue.

After considering, we decided that reset is the same as terminate.
If you want to add a feature start manual initialization, please create a feature request.

Here is an example of a perferctly valid vyos vpn config that will never recover a child SA when resetting it.

In 1.4 and 1.5 command reset vpn ipsec has a termination meaning.

No, it says reset, both the command, and auto complete output. It does not say terminate or clear. If you run a reset you do expect it to restart or re-populate in one way or another, not just stop working completley.

Just to make sure: This change is part of the current nightly build, right?

CPU Quota and ipt_netflow are different tasks.
CPU limits could be part of this task https://vyos.dev/T3706

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

In 1.4 and 1.5 command reset vpn ipsec has a termination meaning.

Offending driver is intel_qat - try disabling QAT first.

Can't edit this task to add a relation, but - https://vyos.dev/T6230

Is there any way to get this ported to 1.3?

Thanks Apachez, I’ve seen that. Unfortunately the NIC is OEM (part of a networking appliance) so no firmware available.

Wouldn’t your suggested fix to https://vyos.dev/T6223 also apply here? If the plan is to validate interface name lengths and allow custom names this would be a non-issue.

According to https://community.intel.com/t5/Ethernet-Products/XXV710-V2-NIC-doesn-t-support-quot-ethtool-m-quot-Is-this-a-bug/m-p/730841 you need to:

Propose to add names for the interfaces:

set interfaces ethernet eth2 vif-s 100 vif-c 300 name if9999

An additional found old dhcp-client issue, does not properly support interface names with length > 13
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858580
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704072

Editing config.boot.default has addressed this. Pull request opened for comments/integration here: https://github.com/vyos/vyos-build/pull/559

Editing config.boot.default has addressed this. Pull request opened for comments/integration here: https://github.com/vyos/vyos-build/pull/559

Editing config.boot.default has addressed this. Pull request opened for comments/integration here: https://github.com/vyos/vyos-build/pull/559

You can use the next type of configuration

set protocols bgp 4200010000 neighbor 2001:db8::2 address-family ipv6-unicast peer-group 'CUST_CR_IPV6'
set protocols bgp 4200010000 parameters default no-ipv4-unicast
set protocols bgp 4200010000 peer-group CUST_CR_IPV6 address-family ipv6-unicast
set protocols bgp 4200010000 peer-group CUST_CR_IPV6 remote-as '65500'

But we recommend to check the result in FRR configuration.