@lcrockett Add please a new bug report.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 3 2023
Mar 31 2023
Running '1.4-rolling-202303270317' i'm experiencing the opposite behaviour. A VRRP health-check script in a VRRP group that is a member of a VRRP sync group stops working (VRRP group immediately transitions to 'FAULT' state upon start of keepalived). If i take out the 'track_script' block in the produced '/run/keepalived/keepalived.conf' and restart keepalived (sudo systemctl restart keepalived) the health-check script functions as expected again. Any pointers ? Or shall I create a new issue containing the appropriate details ?
Aug 30 2022
Aug 26 2022
Aug 14 2022
Aug 11 2022
Aug 1 2022
Jul 31 2022
Jul 30 2022
@dongjunbo What do you mean?
Could you send a real example? I don't see any issues (VyOS 1.3-stable-202207280515).
Jul 25 2022
@NikolayP Try the next command:
Jul 18 2022
Jul 10 2022
Jul 6 2022
Jun 30 2022
Maybe it depends on the version of accel-ppp.
In 1.2.8:
Jun 28 2022
In T4457#124584, @NikolayP wrote:The problem seems to be in these lines:
set vpn l2tp remote-access authentication local-users username test static-ip '172.25.255.1' set vpn l2tp remote-access client-ip-pool start '172.25.255.1' set vpn l2tp remote-access client-ip-pool stop '172.25.255.14'Replacing "static IP" with 172.25.255.2 makes it work in VyOS 1.3.1
set vpn l2tp remote-access authentication local-users username test static-ip '172.25.255.2'Full corrected config for 1.3.1 from the first post:
set interfaces dummy dum4 address '4.4.4.4/32' set interfaces ethernet eth0 address 'dhcp' set interfaces ethernet eth1 address '192.168.6.31/24' set service ssh set vpn ipsec ipsec-interfaces interface 'eth1' set vpn ipsec nat-networks allowed-network 0.0.0.0/0 set vpn ipsec nat-traversal 'enable' set vpn l2tp remote-access authentication local-users username test password 'test' set vpn l2tp remote-access authentication local-users username test static-ip '172.25.255.2' set vpn l2tp remote-access authentication mode 'local' set vpn l2tp remote-access authentication require 'mschap-v2' set vpn l2tp remote-access client-ip-pool start '172.25.255.1' set vpn l2tp remote-access client-ip-pool stop '172.25.255.14' set vpn l2tp remote-access idle '1800' set vpn l2tp remote-access ipsec-settings authentication mode 'pre-shared-secret' set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret 'test' set vpn l2tp remote-access ipsec-settings ike-lifetime '3600' set vpn l2tp remote-access ipsec-settings lifetime '3600' set vpn l2tp remote-access outside-address '192.168.6.31'
Jun 22 2022
Jun 21 2022
Jun 12 2022
The problem seems to be in these lines:
Jun 11 2022
Jun 10 2022
Same as Viacheslav. No issues on my tests in Ubuntu.
Jun 6 2022
Don't have any issues with Ubuntu
set interfaces dummy dum0 address '192.0.2.1/32' set interfaces dummy dum4 address '203.0.113.1/24' set interfaces ethernet eth0 address '192.168.122.11/24' set interfaces ethernet eth0 description 'WAN' set vpn ipsec ipsec-interfaces interface 'eth0' set vpn l2tp remote-access authentication local-users username test password 'test' set vpn l2tp remote-access authentication mode 'local' set vpn l2tp remote-access client-ip-pool start '192.168.255.2' set vpn l2tp remote-access client-ip-pool stop '192.168.255.254' set vpn l2tp remote-access ipsec-settings authentication mode 'pre-shared-secret' set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret 'secret' set vpn l2tp remote-access outside-address '192.0.2.1'
Jun 5 2022
@NikolayP , Looks like MTU and MPPE issue. Stoping daemon does not related to this I think.
Jun 3 2022
Not sure if this is relevant to the task.
But once when shutting down a VM with VyOS 1.3.1-S1, it took a long time to shut down:
Jun 1 2022
May 16 2022
The current discussion has taken place in the vyos-api-discussion channel; results will be summarized here.
Firstly, is there any info in the logs ?
As discussed in the slack channel today, let us follow up here, as I'd like to run through some analysis, and set up a reproducer if possible.
The command works well.
vyos@vyos:~$ show version
May 13 2022
May 12 2022
May 10 2022
May 9 2022
It may be a good idea to cherry-pick this for 1.4.x branch.
May 5 2022
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1315
I've creatred a pull request for the above - https://github.com/vyos/vyos-1x/pull/1313
May 4 2022
May 3 2022
Also, these routes getting an administrative distance of 1, which is impossible to override. I believe the default route from DHCP normally has 210 which is manageable. So, the quick workaround could be increasing distance of these routes.
r24:/home/dtoubelis# cat /var/lib/dhcp/dhclient_eth4.leases lease { interface "eth4"; fixed-address 100.123.57.53; option subnet-mask 255.192.0.0; option relay-agent-information 1:4:0:0:4:cf:5:4:64:40:0:1:97:8:1:0:14:ed:0:0:14:ed:98:0; option dhcp-lease-time 300; option routers 100.64.0.1; option dhcp-message-type 5; option domain-name-servers 1.1.1.1,8.8.8.8; option dhcp-server-identifier 100.64.0.1; option interface-mtu 1500; option rfc3442-classless-static-routes 32,192,168,100,1,0,0,0,0,32,34,120,255,244,0,0,0,0,0,100,64,0,1; renew 2 2022/05/03 12:42:00; rebind 2 2022/05/03 12:44:26; expire 2 2022/05/03 12:45:04; } lease { interface "eth4"; fixed-address 100.123.57.53; option subnet-mask 255.192.0.0; option relay-agent-information 1:4:0:0:4:cf:5:4:64:40:0:1:97:8:1:0:14:ed:0:0:14:ed:98:0; option dhcp-lease-time 300; option routers 100.64.0.1; option dhcp-message-type 5; option domain-name-servers 1.1.1.1,8.8.8.8; option dhcp-server-identifier 100.64.0.1; option interface-mtu 1500; option rfc3442-classless-static-routes 32,192,168,100,1,0,0,0,0,32,34,120,255,244,0,0,0,0,0,100,64,0,1; renew 2 2022/05/03 12:46:34; rebind 2 2022/05/03 12:48:50; expire 2 2022/05/03 12:49:28; } lease { interface "eth4"; fixed-address 100.123.57.53; option subnet-mask 255.192.0.0; option relay-agent-information 1:4:0:0:4:cf:5:4:64:40:0:1:97:8:1:0:14:ed:0:0:14:ed:98:0; option dhcp-lease-time 300; option routers 100.64.0.1; option dhcp-message-type 5; option domain-name-servers 1.1.1.1,8.8.8.8; option dhcp-server-identifier 100.64.0.1; option interface-mtu 1500; option rfc3442-classless-static-routes 32,192,168,100,1,0,0,0,0,32,34,120,255,244,0,0,0,0,0,100,64,0,1; renew 2 2022/05/03 12:51:33; rebind 2 2022/05/03 12:53:25; expire 2 2022/05/03 12:54:03; } ... }
Could you also provide cat /var/lib/dhcp/dhclient_eth4.leases ?
no-default-route ignore just option routers and don't touch other options like classless-static-routes
https://github.com/vyos/vyos-1x/blob/2c29a3b3b46c7570f4a509f413b208348c0ce647/data/templates/dhcp-client/ipv4.tmpl#L18-L19
Below is a packet capture from DHCP exchange:
It seems that option 121 has more than one route. Could this be causing the abnormal behavior?
May 2 2022
Apr 29 2022
Apr 27 2022
Apr 26 2022
Apr 25 2022
Apr 22 2022
We can solve this problem in three ways.
Now the script (https://github.com/vyos/vyatta-op/blob/29703664633a20385a077083b4393738bdcb7409/scripts/tech-support-archive) creates up to 5 versions of support archives, after which it starts deleting the previous one. The problem is that each new version of the archives contains from 1 to 4 old archives. As a result, the archive can take up a lot of space.
Apr 20 2022
Apr 19 2022
Apr 14 2022
Apr 5 2022
@NceAirport do you have a minimum required configuration?
As I see it should be something like:
set service monitoring xxx prometheus authentication login xxx set service monitoring xxx prometheus authentication password xxx set service monitoring xxx prometheus port 9273 set service monitoring xxx prometheus network 192.0.2.0/24
Mar 30 2022
Thank you. I can confirm it works as expected in 1.3.1-S1.
Mar 29 2022
Hi @freelancer . PR mentioned by @Viacheslav was merged on February 17, so fix should be included in 1.3.1
Is this fixed in the released 1.3.1? It looks like it was merged into equuleus, but I don't see it in the 1.3.1 changelog at https://blog.vyos.io/vyos-1.3.1-release.