Resolved via T2653

Yes, I have migrated this a long time ago

Problem confirmed fixed as of 2020-07-24.

I have tested the steps as mentioned in the description in VyOS 1.3-rolling-202007220117 and the issue did not reproduce.
Please try to create a new user in the latest version and share your feedback.

It does param "verbose" in the check.
https://github.com/vyos/vyatta-cfg-quagga/blob/current/templates/protocols/static/route6/node.def#L4

Fixed, VyOS 1.3-rolling-202007240117

It reproducible in VyOS 1.3-rolling-202007240117

Fixed, VyOS 1.3-rolling-202007240117

Fixed, VyOS 1.3-rolling-202007240117

Fixed, VyOS 1.3-rolling-202007240117

A workaround is in place for this

https://github.com/FRRouting/frr/issues/6797 Opened an issue with FRR.

@thomas-mangin Thanks. I've joined the channel yesterday. It'll be fine for asking around every now and then.

PR for crux https://github.com/vyos/vyatta-cfg-quagga/pull/53

@efficiosoft understood. We tend to all hangout there to help each other. If you have another way I/we can relate to you to support you (but here) let us know.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/52

I thought the problem could be related to VyOS, but now I have found the same behavior when using directly tc hfsc.

VyOS 1.3-rolling-202007240117

Fixed.

VyOS 1.3-rolling-202007240117

https://phabricator.vyos.net/T2653

Well I think its not necessary to change this back - we rather should extend the smoketests to detect those errors!

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.