It will be enough to add a quote here?

"\`"

https://github.com/vyos/vyatta-cfg/blob/fa2b172512aa024a9853166528c9e6601fde94d8/src/cli_new.c#L1886-L1888

Can be "cherry picked" to 1.3 and 1.2

PR https://github.com/vyos/vyatta-op-vpn/pull/27

Did you read the error description? It doesn't look like.

Well yeah kinda :) The driver VYOS is using is reporting wrong information to ethtool about autoneg support. No idea if it's fixed in a newer driver. Can't really play around much and I only have this type of nic in a single server. Let's hope someone comes along later with a X710 and can try more.

PR https://github.com/vyos/vyos-1x/pull/840
Can be "cherry-picked" to "equuleus" and "crux"

vyos@r6-roll# load ntp.conf
Loading configuration from 'ntp.conf'
Load complete. Use 'commit' to make changes effective.
[edit]
vyos@r6-roll#

Well then somehow this feels to me NIC related as I can not see it here.

Yes. Tried before posting the above comment.

I tried reproducing this issue on VyOS 1.3.0-rc4 but I see no link flaps on my IGB card connected to a Cisco Catalyst 1000.

upd. on vyos-1.4-rolling-202105051111 it's still there eve after reboot

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

Hi. Tried it (IPv4) on vyos-1.4-rolling-202103251004 in eve-ng
It reacts to set protocols static route 0.0.0.0/0 next-hop 195.7.0.102
After reboot it's still there
Screens added. It shows static route

Please use the following op-mode command to check:

Also bug for config "vyos" set mode clientset remote-port 12345

vyos@r6-roll# run show remote-config openvpn vtun0 remote-platform vyos 
NOTE: authentication options are deliberately left out,
since we cannot know file paths on a remote system

@zsdc Can we close it?

@krox2 The next rolling release will be with keepalived 2.1.5. Can you check?

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

PR https://github.com/vyos/vyos-build/pull/165

This task was superseded by T3411, hence was not backported; however that missed the bug fix in the final commit. cherry-pick rVYOSONEXeeb9687bb9aa.

@ernstjo

set policy route-map ASxxx-CUS-IN6 rule 10 action 'permit'
set policy route-map ASxxx-CUS-IN6 rule 10 set large-community '65:23:1 additive'

Yes the point of "longer-prefixes" is to find smaller routes within a bigger netmask, so if you're leaving out prefix, it doesn't make sense.

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

OK, it seems that this problem doesn't need any repair and will be closed

I agree with @c-po, no warning is needed inbthis case

Why should a warning be printed?

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

@runar I just checked the current implementation. It seems that the current configuration is replacing "allowed VLAN" with "native VLAN", but there is no warning. I add a warning!

Please make it so when both are present the native-vlan command is used.. do not throw an exception as this would make configuration much harder, as a eg. allow-vlan 1-4096, native-vlan 50 will be impossible to configure... Splitting up the allow-vlan and redoing it just to change native-vlan is work that the scripts should do in the backend and not have the user do it