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?

This is expected 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

https://forum.vyos.io/t/limit-bandwith-for-indivindual-ips-on-1-2-5/5947/30?u=s.lorente

OK, thank you. I will test this. This should probably be made as default.

This has come up multiple times before, see https://phabricator.vyos.net/T1698 for the solution.

https://forum.openwrt.org/t/ingress-traffic-shaping-with-snat/40226

Note: New xl2tpd package does not work with the followings params in options.xl2tpd

crtscts
lock

At this stage, I can't realize the automatic configuration of NDP proxy. On the other hand, although I don't know what additional application scenarios will be in addition to nat66, I hope to give full play to the full potential of NDP proxy, so I don't want to bind it to nat66 artificially.

Still wondering why ndp-proxy can not be part of the nat66 tree.
When a NAT66 translation is added we know the prefix (src and dst), the in/out-bound interface - so another CLI option (ndp-proxy) could probably be added to not open up an additional service node.

@c-po Request merge https://github.com/vyos/vyos-1x/pull/556

In T2943#76739, @runar wrote:

as a workaround you could add this to a post-boot script on the device.

This is disallowed by design by the VyOS team. the reason for this is partly because of the configuration order done by VyOS and how the dns lookup is handled by Wireguard.
Yes, the wg configuration utillity DOES handle DNS lookups, but NO, Wireguard does not handle them. This means that the DNS lookups is done once (and only once) when the wg command is executed on creation of the tunnel and then the resulting ip result is stored in wireguard. this results in the dns lookup will fail after a reboot of the VyOS device because it cant resolve the dns of the endpoint at that point (this is done before routing is enabled on the device)

PR for Rolling https://github.com/vyos/vyos-1x/pull/559

Already basically ready to merge

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

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

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

Write redundant and intrusive code for all interface types, which may introduce unknown errors (I can’t guarantee 100% accuracy without testing)

@c-po I am thinking about a problem. Placing proxy-ndp under the child node of interface may generate redundant implementation code and is intrusive. In fact, for proxy-ndp, only one configuration file is needed. Is this Reasonable? I don't even know how to fully test whether the intrusive code affects the basic functions of the router.

It looks like this problem is around here
https://github.com/vyos/vyatta-cfg/blob/current/etc/bash_completion.d/vyatta-cfg#L280-L290

Yes that's correct. And there is already some sort of check implemented for the node traffic-policy, so it does not fail when the pppoe interface does not exist yet. It just shows a warning: https://github.com/vyos/vyatta-cfg-qos/blob/bbf2b2f06b7a0f883f7134df5e2b3e089015738e/scripts/vyatta-qos.pl#L198

I think I know what's happening here.

https://forum.vyos.io/t/limit-download-and-upload-on-wan-for-every-vlan/5608/51

PR for rolling https://github.com/vyos/vyatta-cfg-vpn/pull/38

It declared 2 times, because there is 2 checks

PR https://github.com/vyos/vyatta-ravpn/pull/16

This is the output of this line