Still present in the 1.2.6-S1 release. Makes vyos unusable in environment with DHCP WAN IPs and using the DNS forwarder for specific domains. Those domain forwarders are lost every time the ISP renews the public IP.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 18 2021
Jan 17 2021
Fixed
vyos@r5-roll:~$ show ntp remote refid st t when poll reach delay offset jitter ============================================================================== *194.0.5.123 85.199.214.102 2 u 4 64 3 39.557 -2.748 2.504 +167.86.115.96 235.106.237.243 3 u 39 64 3 45.816 5.476 0.830 +195.128.100.150 131.188.3.222 2 u 4 64 3 43.219 -1.425 1.734 vyos@r5-roll:~$ vyos@r5-roll:~$ show version
Jan 16 2021
Jan 15 2021
CLI command will be: set interfaces tunnel tun10 parameters ip no-pmtu-discovery, Also PMTU can not be changed in IPv6 sourced tunnels, a validation check has been added.
Jan 14 2021
Jan 12 2021
Jan 10 2021
Jan 9 2021
Jan 8 2021
NTP doesn't work when you configure listen-address 0.0.0.0.
Jan 7 2021
@runar we also added no- in the 1.3 series, so I'd prefer: set interfaces tunnel tun0 parameters ip disable-pmtu-discovery or set interfaces tunnel tun0 parameters ip no-pmtu-discovery
Jan 6 2021
Very well.
@tuxis-ie we are running FRR 7.3 and can not easily upgrade to 7.4 due do changes in the FRR behavior and known bugs which we already faced in a rolling release which was running FRR 7.5.
I see it is in https://github.com/FRRouting/frr/releases/tag/frr-7.4 ..
Hmm. It has been merged here: https://github.com/FRRouting/frr/pull/5855
@tuxis-ie
FRR doesn't allow you to set that value. It's not a bug of VyOS.
In commands description allowed values (0-4294967295)
r12-1.2.6(config)# route-map FOO permit 100 r12-1.2.6(config-route-map)# set local-preference (0-4294967295) Preference value r12-1.2.6(config-route-map)# set local-preference (0-4294967295) Preference value r12-1.2.6(config-route-map)# set local-preference -10 % Unknown command: set local-preference -10
Jan 5 2021
As far as i know all our other "disable" commands starts wirh "disable-"
Jan 4 2021
I'd personally recommend "pmtu-discovery-disable", but either would be fine.
Proposed CLI
set interfaces tunnel tun0 parameters ip disable-pmtu-discovery
Jan 3 2021
Jan 1 2021
Dec 26 2020
Dec 24 2020
Dec 23 2020
I successfully update the image from 1.2.6-s1 to VyOS 1.3-rolling-202012231522
Dec 22 2020
Dec 16 2020
Dec 14 2020
Pull request submitted to change the permissions:
Dec 13 2020
Dec 4 2020
Nov 24 2020
Nov 23 2020
Nov 20 2020
Nov 14 2020
Nov 12 2020
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.
Nov 11 2020
Nov 9 2020
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.
Nov 7 2020
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
Nov 5 2020
Nov 4 2020
Nov 1 2020
Oct 27 2020
Oct 26 2020
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.
Oct 25 2020
Oct 22 2020
It looks good, I want to ask how other people in the community think about this?
- 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.
- 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. 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?
Oct 21 2020
Do we need it for "crux"?
This does not affect the work of VPN service.
Oct 20 2020
Oct 19 2020
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)
Oct 17 2020
Oct 16 2020
@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