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.

@Dmitry I can't reproduce it anymore VyOS 1.2.7

vyos@r2-lts:~$ touch tttt.txt
vyos@r2-lts:~$ ls
1.txt  foo.txt  ntp.conf  ntp.conf.2021-05-13-1945.pre-migration  ntp.conf.2021-05-13-2107.pre-migration  test.py  test.txt  tttt.txt  vyos@192.168.122.16
vyos@r2-lts:~$ 
vyos@r2-lts:~$ reset vpn remote-access user 
Possible completions:
  <text>        Terminate specified user's current remote access VPN session(s)

Default value https://github.com/vyos/vyatta-conntrack-sync/blob/7a8827e0d72cf771b0551915d738abe4838c0915/templates-cfg/service/conntrack-sync/mcast-group/node.def#L2

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?

thx for the fast feedback.

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 eeb9687.

@rherold, this was a known bug, fixed in 1.4, but missed in backports to 1.3. As a workaround, systemctl stop vyos-configd before the commit will reveal the errors; if I recall correctly, the error is a missing 'country-code' entry.

@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

the same is the case for GRE interfaces too (ip6gre in particular)

Frr itself doesn't allow to set longer-prefixes without "prefix"

r4-1.3# show ip route 1.1.1.1 
  <cr>           
  json           JavaScript Object Notation
  nexthop-group  Nexthop Group Information

I ran a packet capture on this BGP session and it appears that VyOS actually sends some packets out and they appear to go through the right gateway... I'm investigating with the provider and will post an update here shortly.