@lcrockett Add please a new bug report.

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 ?

@dongjunbo What do you mean?
Could you send a real example? I don't see any issues (VyOS 1.3-stable-202207280515).

@NikolayP Try the next command:

Maybe it depends on the version of accel-ppp.
In 1.2.8:

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'

The problem seems to be in these lines:

Same as Viacheslav. No issues on my tests in Ubuntu.

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'

@NikolayP , Looks like MTU and MPPE issue. Stoping daemon does not related to this I think.

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:

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.

It may be a good idea to cherry-pick this for 1.4.x branch.

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

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.

Prometheus server pulls information correctly

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:

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

https://github.com/vyos/vyatta-op/pull/55

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.

It should exclude it https://github.com/vyos/vyatta-op/blob/dfbfeafb1362a2c6934575a984a78fd2524d5720/scripts/tech-support-archive#L54

@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

Thank you. I can confirm it works as expected in 1.3.1-S1.

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.