Seems like this might be VRF related

@daniil that would work of course. You tested it manuslly that this works?

Can use systemd module file override?

Changed this around a bit to load the modules automatically if necessary. Only adds about half a second to initial execution

@jjakob. to clarify two points (for my sake as well), there are cases where config fails to the point where the config session can not be initialized, such that one can not enter a config session: here's an example --- say. during development, someone forgets to import a module in an early conf_mode script; config initialization is completely screwed --- this had occurred ages ago, and the only way I found it was that I had happened to be looking at their code a few moments previously and noticed ... that's what vyos-config-debug is for, and why it is hidden on a boot flag. You are talking about a much more reasonable case, where (I imagine) a specific configuration causes a partial failure, but one can still enter a config session. The checks in subtask T2568 may help restore the ability to debug by config/load/commit. Those checks are needed anyway.

https://github.com/vyos/vyos-1x/compare/current...jestabro:config-checks.patch

I think we can safely remove it indeed.

A Serial/IPMI interface would be much more suited for kernel debugging.

This has been on my extended todo list for a long time now, but there were always higher priority issues. I'm glad someone is working on it!

PR https://github.com/vyos/vyos-1x/pull/446
Note: gw-ip-address necessary define for [radius] or [chap-secrets] sections.

@c-po I have not tried this previously, but if it works well, I would like to keep it for kernel debugging on bare-metal devices.

I think the old interface sequence number can confuse on this device

@c-po these changes will take effect only for the newly installed system, HW-ID in config has more priority.

Overview of the effort:

T2551 has now been fixed and confirmed working.

@c-po I can now confirm that as of vyos-1.3-rolling-20200607117 this issue is now fixed!

This will move eth0 to eth7 - is there a config migrator? Or is it yet not used in "production"?

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

@dmbaturin @syncer @jestabro @thomas-mangin @UnicronNL

It will be in the next rolling (any rolling newer then vyos-1.3-rolling-202006070117-amd64.iso)

Ah, nice! I will update to the rolling release and give it is go soon.

@njh you have been right that command can be quiet handy, but instead of using a logfile we query "journalctl" for the appropriate logs.

Idea: do not generate empty node.def file if there is no <properties> statement.

@mrozentsvayg look at https://community.openvpn.net/openvpn/ticket/360 (this is documented in the code comment right above your change as well). OpenVPN on Linux in server mode with standard protocols doesn't listen on IPv6, just IPv4. We need to force it to bind to a IPv6 socket using these undocumented *6 protocols, then it'll listen on both IPv4 and IPv6. This wouldn't be necessary if OpenVPN listened on IPv6 with the default protocols or autodetected whether the local or remote IPs are v4 or v6 and chose the correct socket type, but it doesn't. Complain to the above ticket 360. We're just working within the limitations imposed by OpenVPN.

In T2550#66208, @jjakob wrote:

What happens when one remote-host is IPv4 and one is IPv6? The proposed fix would leave the protocol as udp6 in that case and the error would still be there.