@jjakob if what you say is correct then the solution should look like. I can not test it tho (simply as I do not know how to setup OpenVPN and have no lab to make it work).

Thank you for the assignment but I have not looked at or touched the OpenVPN code (and never used OpenVPN myself).
This issue with the op_mode, not config mode, so so it must have been there for a while.
I could change the code to check that the file exist, and prevent this fault but I am not sure it would be the right thing todo.

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

It requires a migration of the VTI interface to python first.

Regarding the reference counter for changes. It can also be implemented by storing in an Interface specific class level dictionary the last know state of the interface.
However, should multiple instances of the class be run by multiple programs then this could become problematic and this limitation should be kept in mind.

The recent change in implementation have changed the code from "if/else" to data-driven.
For example, every class now has a "definition" dictionary which indicates what the interface can/cannot do, for example, be bonded or not or it it supports vlan.

There this three types of functions which as class can have:

• "normal" when the first argument is "self"
• classmethod (using the @classmethod decorator before the function). In that case self replaced from an instance of the class by a reference to the class itself (often called cls, in that case InterfaceClass)
• staticmethod (where the function does not need class data and is jus placed under the class) can be called with InterfaceClass.func()

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

Thanks - understood.

Hi jjakob, AFAICS the patch above should have fixed any problem with the ethtool. If not I will need to understand why.

was this was not already fixed ?
https://github.com/vyos/vyos-1x/commit/8f39784c847801c0b766a0c9289da0976ffd0604#diff-ca1457dc16e0b9a43de02cf08140b65aR123

let me try to put a quick patch for you.

we can fix it in two ways: undo the commit which check the return code of the program, hiding the issue and add a first BIG PRINT warning stage or find the root cause and fix it (harder).

also all calls to start-stop-daemon need to have a --oknodo option added

I believe your default settings are not bad as, in our case, we are part of the ntp pool and our kit will use our own NTP servers :-)

pushed https://github.com/vyos/vyos-1x/pull/261 which should fix the issue.
@lluu131 if you know how to use vi and only if you are sure you can run:

sudo vi /usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py +123

and you change CalledProcessError with RuntimeError

sorry for this oversight.

https://github.com/vyos/vyatta-op/pull/36

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

The changes are also part of the patch for T2057 which was merged.

All my apologies for this stupid bug.

The patch is ready for inclusion.

This work raised an issue with the current pattern of using Interface(..).remove() which is used in VLANIf as it requires Interface to know that EthernetIf can not be deleted (an implementation detail which should remain in EthernetIf).

This work overtakes T2046, as it implements the same _create/_delete interface. If merged it would replace it.

We could indeed create the VRF as we parse interfaces, and auto-allocate the VRF number, removing this control from the user.

should for multiple routing tables:
https://andir.github.io/posts/linux-ip-vrf/
http://www.allgoodbits.org/articles/view/24
https://patchwork.ozlabs.org/patch/546171/

initial patch released calling for a review / comments ( PR from github.com/thomas-mangin/vyos-1x T2028 branch) - show command not migrated yet.

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

In T31#53189, @rherold wrote:

Could be away. But from my experience most people use vrf to seperate managment from production, and as second prio seperate customers and so on.
But the managment vrf must not be the "default" vrf.

Here is a patch to implement VRF. Binding is set to work on all VRF for daemon so that BGP and other protocols will work on all VRF.
https://gist.github.com/thomas-mangin/7704c538d905190bd05cfe613bd9f4f5

while it would be quite nice to have a Cumulus 4.0+ like default management VLAN and make all services management aware (which would quite considerably increase the among of work to get something out), I am proposing instead make sure that all services running on the default VRF are available on VRF as a first step.

suggesting https://github.com/vyos/vyos-1x/pull/217

Identified configuration format change:

I have a use case for VRF / Linux namespace with VyOS and was wondering if there was a way to break this task down, first allowing the manual creation of VRF/namespace using the CLI (without linking the work to BGP). I will be able to contribute the required changes to the vyos-1x repository should I be given enough direction on how you would like to proceed.