I will check next couple of days

This is expected as disabling an ethernet interface is different than any other interface, they're still present but just put admin down. All other interfaces get deleted and thus throw this error.

Oh - I'm sorry - I mixed up the lines in the kernel. The patch is actually in VyOS.

@c-po Thank you for clarifying. I guess I misinterpreted what i read on patchwork. I'd be eager to test a kernel with the patch!

@fetzerms the mentioned patch is not included in the mainline kernel!

Also happens with 4.19.131-amd64-vyos - I guess that patch mentioned by @Viacheslav is either not included or not solving the problem.

@elbandi can you check it on the latest rolling release?

With ethernet works fine, VyOS 1.3-rolling-202007230117

vyos@r1-roll:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             192.168.122.11/24                 u/u  
eth1             -                                 A/D

Fixed, VyOS 1.3-rolling-202007230117

@suuei Can you try the lateset Rolling release?

Currently, we don't have the option "link" in vxlan which was provided in config.

As workaround

Fixed.

vyos@r1-roll:~$ show vpn remote-access 
No active remote access VPN sessions
vyos@r1-roll:~$ 
vyos@r1-roll:~$ show version

Fixed, VyOS 1.3-rolling-202007230117

Fixed, VyOS 1.3-rolling-202007230117

set interfaces tunnel tun16 encapsulation ip6ip6
set interfaces tunnel tun16 local-ip 2001:db8:aa::16
set interfaces tunnel tun16 remote-ip 2001:db8:aa::26
set interfaces tunnel tun16 address 2001:db8:bb::6/64
commit

@c-po Request merge

@c-po Request merge

@c-po Request merge

With that replace I see this is an error in each commit

PR https://github.com/vyos/vyatta-cfg-system/pull/126

I replace

my $cmd = "curl -#";

to

my $cmd = "curl --insecure -#";

No, not yet. But generally I don't like it too much because I'm blind and their desktop client isn't very accessible, and writing things like code examples on a smartphone, well, is something I try to avoid ;-).

@efficiosoft are you on our slack channel ?

Yes, it would be a solution. However the behaviour the daemon should really be "fixed" when loaded. It may be simpler to have a reload feature on SIGHUP. This would allow changing the file on disk when developing, testing it without breaking things, and only when confident that it is right, then asking for the reload.

Well, it would be trivial to add an --auto-reload switch to the daemon for development purposes which could enable an inotify watcher over the XML files.

Fixed

It's impossible without re-adding network driver (modprobe -r xxx; modprobe xxx)

Fixed.

One thing to keep in mind however when sticking with the XML definitions are the nodes that exist twice, once as tag and once as non-tag node, as @dmbaturin mentioned.

@efficiosoft asking users to fire a daemon is not really user-friendly :-) Once a daemon is loaded, whatever change is done to any initialisation data on the disk will not affect it. Should a tool exist loading the same data each time, then changes can be tested without affecting the running daemon.

In VyOS 1.3-rolling-202007220117 works fine.

@efficiosoft asking users to fire a daemon is not really user-friendly :-) Once a daemon is loaded, whatever change is done to any initialisation data on the disk will not affect it. Should a tool exist loading the same data each time, then changes can be tested without affecting the running daemon.

Providing a way to run the op. code without the daemon would allow people to design their own XML add it to the router, test it without reloading "the stable" code in the daemon, and only when happy that it is working cause a restart of the daemon.

Thanks @thomas-mangin for sharing your thoughts on this.

Thank you for the offer, having read your patch it seems you are indeed fluent in Python and as there is lots to do so I am sure you will be able to help :-)
As @dmbaturin started this, I will let him come back to you about what could be done.

I like this idea of building a vyos-opd daemon in Python.

Pull request to revert that changed line: https://github.com/vyos/vyos-1x/pull/516

Issue only happens if a user is defined without a password, otherwise the correct field gets set:

# Encrypted password
if conf.exists(['authentication', 'encrypted-password']):
    user['password_encrypted'] = conf.return_value(['authentication', 'encrypted-password'])

https://github.com/vyos/vyos-1x/commit/a07e22377ab83104ac925e13d1824f241f0f8d4a#diff-38def27d6150350cf8bd539da90de66b (T2492) seems to have changed the initialization:

Fixed in the latest rolling release.

Fixed in latest rolling release and T2658

Fixed in the latest rolling release

vyos@r1-roll:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             192.168.122.11/24                 u/u  Huawei is secondary home router Telecom special edition switching and AP mode
lo               127.0.0.1/8                       u/u  
                 ::1/128                                
vyos@r1-roll:~$ show version

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

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

Of course :)

@hammerstud that would work for you - but it will break everyone elses implementation ;)

Perhaps I'm one of the minority. but BGP is our predominant DMVPN routing protocol.

As i remember the lack of multicast replication was the reason this stopped up last time it was discussed... And as ospf and eigrp is the most used protocols run over dmvpn i think this is a showstopper for implementimg nhrpd

FRR nhrpd do not support multicasting over GRE tunnels so OSPF or EIGRP don't work since they use multicast addresses to discover neighbors

It will break everything when in use ;)

show interfaces vrrp

I assume this will break 'system static-host-mapping host-name' and other places where tagnodes are used to carry string values as well

Must be fixed after T2653 - then there is only a single truth for all interfaces

I have tried the above scenario in the VyOS 1.3-rolling-202007200117 which is the latest version and the issue did not reproduce. So I would request you to try in the latest version and share your feedback.

Option set! Kernel rebuilding