This PR should address this simple usability enhancement

I found that it was due to set_vrf which uses the same master/nomaster commands that bridge uses. I'm adding checks and conditions to all interfaces to prevent that - raise ConfigError if both are set, and only set_vrf if vrf is set. The prior idea I had with re-adding the interface to the bridge at the end isn't necessary in this case, but for other interface types, where the interface itself is deleted and recreated, re-adding it is still necessary. The PR should be ready for initial review tomorrow.

This PR should built proper images

Resolved with T2393

This has a dependency on python3-flask-restx, which will need to be added using, for example, T2396.

This is solved in both the current LTS and rolling releases.

I had already reported before my refactor of the code that DHCPv6 does not work.
https://phabricator.vyos.net/T2268

http://man7.org/linux/man-pages/man8/start-stop-daemon.8.html

EXIT STATUS

https://vincent.bernat.ch/en/blog/2017-ipv6-route-lookup-linux

Marek Isalski Today at 6:31 PM

We've got full IPv4 and IPv6 routing tables on our VyOS boxes, and we *definitely* needed to increase net.ipv6.route.max_size (we picked 256k to give us some headroom).

Some statistics from ipv6 bgp summary

@thomas-mangin the sessions are still stable, for 7 days now. The only thing changed was that max_size limit. Also no packetloss on the IPv6 connections has been observed during this time.

Wrong location of status file - it was moved to /run/openvpn

@jjakob sorry for wasting your time here :-( I will try to replicate.

Nice catch - I was not aware of that show command.

The issue has been solved by the above merge.

They're still broken here. Maybe a different bug. It would be nice to switch to 'status-version' 2 or 3 too for more info.

vyos@rt-home:~$ show openvpn server

@Merjin is trying this:

sudo sysctl -w net.ipv6.route.max_size=131072

https://serverfault.com/questions/902161/linux-host-randomly-stops-answering-ipv6-neighbor-solicitation-requests
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115

How I reproduce it.

To explain the permission for the user/group/world are expressed in octal (3 bits) so 755 is binary for 111 101 101

Successfully tested on 1.3-rolling-202004270117

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

@jjakob can we close this task ?

That's unfortunate. I get that we need vyos.ifconfig to abstract interface management, but I thought pyroute2 could at least be used to replace all the calls to 'ip'. I guess that's not the case. I searched for pyroute2 and I see you already tried it, so I'm closing this.

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

Should a iproute.py wrapper be considered to prevent having calls to "ip" everywhere in the code?
Therefore if at a later date a better solution comes along the calls to binary would not be everywhere in the code ?

Fair enough. I have gone thought the bug tracker of pyroute2 and indeed it does not inspire confidence!

@c-po errors in latest rolling VyOS 1.3-rolling-202004270117

$ show poweroff
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 193, in <module>
    main()
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 188, in main
    check_shutdown()
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 74, in check_shutdown
    dt = datetime.strptime(output['DATETIME'], '%Y-%m-%d %H:%M:%S')
TypeError: 'NoneType' object is not subscriptable

Nope. Before I‘ve invented vyos.ifconfig it was actually based on pyroute2. The problem with pyroute2 was that it lacked required functionality for VyOS which let me to developing our own lib.

any L2/L3 issue affecting TCP between the BGP speaker will cause this message. Looking forward to a TCP dump of the traffic when it occurs.