PR for 1.4: https://github.com/vyos/vyos-1x/pull/3806

In T6545#194997, @SrividyaA wrote:

@Viacheslav, For site-to-site or server/client mode, when used cipher option as none then also issue is noticed. When you commit, it gives this warning:

vyos@vyos# set int openvpn vtun1 encryption cipher none
[edit]
vyos@vyos# commit
Warning: "encryption none" was specified!
No encryption will be performed and data is transmitted in plain text over the network!

Logs:

Jul 10 14:51:39 openvpn-vtun1[12357]: Cipher NONE not supported

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

@Viacheslav, For site-to-site or server/client mode, when used cipher option as none then also issue is noticed. When you commit, it gives this warning:

In T6563#194972, @Viacheslav wrote:

Any idea for CLI?

Any idea for CLI?

Since loopback and dummy are fundamentally different in Linux, trying to pretend they are not would be misleading rather than helpful. Unless anything changes in the kernel, we should keep things as is.

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

Recovering gracefully and logging an error is a simple fix, and will be committed in the interim while the larger issue is addressed: namely, when running under vyos-configd, a ConfigError in a called dependency script should elicit a commit error in the originating config session. Here, however, we confront again the constraints of operating under the legacy commit algorithm. To address the matter, we will implement a partial solution to T5731 so as to catch verification errors in the (first instance of) sequential processing of the priority queue and cache the data for final processing of the activation stages (generate/apply); errors in the latter stages, as less common, will be logged. The sketch provided summarizes a design that balances the needs of early and correct (verify stage) error reporting with removing redundancy overhead when running under configd.

After spending more time handling VRFs within VyOS the answer from @Viacheslav is best

In T6211#194799, @stephenmcmahon wrote:

In T6211#189615, @Viacheslav wrote:

Probably the best way will be moving the config to the vrf section (not implemented)
For example:

set vrf name foo service dhcp-server shared-network-name eth1 option default-router '192.168.1.1'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 lease '300'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default start '192.168.1.10'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default stop '192.168.1.100'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 subnet-id '1'

In T6211#189615, @Viacheslav wrote:

Probably the best way will be moving the config to the vrf section (not implemented)
For example:

set vrf name foo service dhcp-server shared-network-name eth1 option default-router '192.168.1.1'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 lease '300'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default start '192.168.1.10'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default stop '192.168.1.100'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 subnet-id '1'

And start several instances, each with its configuration.

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

Bug fix in case of config file without component version string:
https://github.com/vyos/vyos-1x/pull/3788

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

task related : https://vyos.dev/T4025

https://github.com/vyos/vyos-build/pull/686

We should backport https://github.com/net-snmp/net-snmp/pull/785/commits/f5ae6baf0018abda9dedc368fe6d52c0d7a8ab8f to our net-snmp version

Upstream issue/bug

@SrividyaA what cipher should be selected instead if none is removed and migrated away?

@SrividyaA Does it work for site-to-site ciphers option?

CLI nodes already present under reset tree