The issue here is that "set protocols ospf default-information originate" propagates a default route even if there is an inactive route for 0.0.0.0/0. It should only propagate if "always" is used. So, maybe the inactive route is not in the routing table (in the routing sense) but it seems to be taken into consideration for redistribution.

Imagine if you use for example BGP and don't have a default route or set it to blackhole.
Then you originate the default route for a neighbor.
Why it should not announce the default route to the neighbor?

It's normal behavior, so routes not installed in the routing table.

As discussed in Slack channel, these leftover processes should be cleaned up the next time configuration mode is entered (by UnionfsCstore::setupSession). In my limited testing, I can reproduce the leftover processes as above, but they are cleaned up the next time I enter config mode. There may well be corner cases where this mechanism is not successful, but I have not reproduced.

Issue is fixed in the latest rolling release. The IPv4 remote-host hostname in client mode works without adding the option '--proto udp4'.
Tested in VyOS 1.3-rolling-202011060217

PR for crux https://github.com/vyos/vyos-1x/pull/582

Once this task is solved, QoS documentation should include a subsection about NAT, explaining the procedure for both outbound and inbound traffic.

It looks good, I want to ask how other people in the community think about this?

1. If the user configures his cluster as a "pool" or a bunch of "server" they should work fine, he can also "allow" them to connect to him if he wishes. I would recommend connecting to a good pool myself, or a low stratum device hosted locally, instead of making some kind of cluster.
2. https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2016/03/msg00001.html

Does anyone understand the meaning of these performance data? I don’t know the unit of these data

1. 1. When the user's data source uses NTP cluster, whether switching to the new service may lead to the compatibility problem of NTP cluster network

Yes, absolutely, and if you visit the link in the post you'll see a comparison of them, and at the bottom is some explanation.

Can chronyd completely replace NTP?

Do we need it for "crux"?
This does not affect the work of VPN service.

It looks like this works, but when we don't have any connected user, it listed the current directory file

vyos@RTR1:~$ touch 1.txt
vyos@RTR1:~$ reset vpn remote-access user <tab>
Possible completions:
  1.txt         Terminate specified user's current remote access VPN session(s)

After a user connected, all works properly

vyos@RTR1:~$ reset vpn remote-access user <tab>
Possible completions:
  test1         Terminate specified user's current remote access VPN session(s)

@c-po @dmbaturin It can be safely cherry-picked to the "crux".
I tested this on 1.2.6-s1, it works.

It was fixed in the rolling T2573
https://phabricator.vyos.net/rVYOSONEXf812c5d1ce01efa8323bfb797c57f68f474665bb

@Robot82
It will be by default in the new BGP implementation.
https://github.com/vyos/vyos-1x/blob/current/data/templates/frr/bgp.frr.tmpl#L5