PR for this task https://github.com/vyos/vyos-1x/pull/198

In 1.3 default-route 'force' works as expected, for 1.2.x (crux) we need merge patch which was proposed by @hagbard

This was tested on a different VyOS install, so I will test again and confirm.

I just did a build of Crux 1.2.4. The issue that appeared in 1.2.3 did not occur in 1.2.4.

Hi @rherold , I can't create this behaviour in LAB.
I have clear vyos-1.2.3 installed and do next steps:

1. sudo nano /config/scripts/vyos-postconfig-bootup.script

#!/bin/sh
# This script is executed at boot time after VyOS configuration is fully applie$
# Any modifications required to work around unfixed bugs
# or use services not available through the VyOS CLI system can be placed here.
/config/scripts/rcs/rcs-mgnt-vlan.sh 2>/dev/null 1>/dev/null

2. sudo mkdir /config/scripts/rcs/
3. Create file sudo nano /config/scripts/rcs/rcs-mgnt-vlan.sh with following commands

#!/bin/bash

Tested successfully on VyOS 1.3-rolling-202001060217

Hi @max1e6 , can you please share the relevant openvpn config, so I can try to reproduce the issue? Thx.

@kroy thx for testing, glad it is working for you since I'm not really satified with it.

@hagbard Confirmed your hack takes care of the issue.

Yup, https://phabricator.vyos.net/T1831 is pending. FRR RAs will fix the issue entirely or going with set service ipv6-ra interface... would fix that too regardless what daemin is being used at the backend which would also make it interchangeable.

I was hoping you have some input here.

As I can remember there is no objection about FRR for RAs - its only the CLI structure.

I actually suggested using reload/SIGHUP. The problem is the very rapid reloads sent by the vyos script to systemd. start-stop-daemon is handled by systemd in Debian Buster, in Jessie it was still handled by sysvinit so it didn't have any limits. I suppose it uses some default restart limits/timeouts that can otherwise be adjusted in unit/service files. I suppose it could be converted to a native systemd service so the limits can be set if there is a corresponding setting that would fix the issue. Otherwise it'd be better if we don't use systemd to send SIGHUP at all and send the signal direclty to the daemon w/ pid read from pid file. Or switch to using frr for RAs - what's the progress on that?

That's what it does but using the init script.

Why not check if radv is running and sent a HUP signal instead?

My system takes 6 minutes to boot, and it only has two DHCP servers and about 12 interfaces.

Let's see if it does the job, it's more a hack than a fix. The real problem is that you will have reloads for each interface which has router-advert configured during boot.
Systemd doesn't like the quick restarts during boot and limits that.

I'll wait to test until the reload fix is merged

Definitely confirmed as of yesterday's rolling. Still occurs on three different VMs.

Confirmed fixed in a newer rolling.

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

By the way, may I say there are several bugs of stop function in vyos-router?

Why not use WantedBy instead of RequiredBy in vyos-hostsd.service like:

This is already fixed in latest rolling by T1921 - please recheck ltest rolling

PR for this task https://github.com/vyos/vyatta-cfg-system/pull/116 which rename (masked) VF interface to vf_ethX

I'm going to change the node.def to reload if radvd is running already, not sure if it fixes that since the issue appears to be systemd related.
Also if you just disable a vif, radvd won't be restarted and has an invalid interface it tries to announce on, that's why I want to move it out of the interfaces and set it as it's own service.

Hmm, I can't reproduce the issue, looks good when I test it with your config and reboot few times.

@c-po, it not possible to reproduce in 1.2.4 and 1.3 latest rolling.
I tried also delete system console on deployed 1.2.3, and it also works without issues, syslog clear.

As asked on slack and to be clear. This issue was never present in any of the 1.2 LTS releases (crux branch) - not in 1.2.0, 1.2.1, 1.2.2, 1.2.3 and 1.2.4.

Already in 1.2.4

I got this on two production systems on the next two I migrated I changed my workflow to:

My original thoughts was quite straight forward, modify /usr/libexec/vyos/init/vyos-router as below:

We should inform Debian Team about this error and use a fix provided by them if possible.

I have built the current branch this evening, version is 1.3.0-rolling because i named it that way.

@Merijn, which exactly version are you using? Provide please show version output.

Tested by installing the new package
https://packages.debian.org/bullseye/amd64/iperf

Most of the times when i try a second time it just works.