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'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.

@jjakob It's not really relevant if you SIGHUP or SIGKILL as RAs have no status, they are just send. I was looking into rewriting it anyway and port it into frr as frr sends RAs reliably as well. (https://phabricator.vyos.net/T1831) So the above is just a quick fix to get it working again with buster using the original logic.

@kroy I think I found the issue, the script just called start every time when radvd was already running, please test with either tomorrows iso or: http://dev.packages.vyos.net/repositories/current/pool/main/v/vyatta-ipv6-rtradv/vyatta-ipv6-rtradv_0.38+vyos2+current1_all.deb

It sends it after a while, I was waiting around 5 minutes and captured 1 RA msg.
But it sends only on vlan 22, which is quite unusual since all vlans are setup and readable by radvd, at least when I check /proc/<pid> it has it setup.
After the restart it sends on all interfaces (Just sent a SIGHUP, so no systemd involved). Reboot fixes it then as well.

All right, I can reproduce it now, thanks for the detailed report. I see what I can find out.

Weird, afaik there was nothing to migrate yet.

That can't be the issue, what do you see if you do a grep radvd /var/log/messages?

I used your config and just changed to eth1, commit works and after reboot radvd runs and sends RAs as well. radvd has a very low priority, I think 999 or so to ensure all interfaces are up and running plus the fact that radvd runs with a flag which allows the config running on an offline interface. (IgnoreIfMissing on;) Could anything else x-fire?

@fcqpl any chance to test it in your environment?

@kroy can you please share your config? I used a minimal one and everything works without issues.

end: sudo sh -c "VYOS_TAGNODE_VALUE='$VAR(../../@)' ${vyos_conf_scripts_dir}/router-advert.py" would have to be in /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/ipv6/router-advert/node.def
I can set that statically, which removes then the benefit for the use of other passes, IPv6 RAs can be sent over quite some interfaces.

Turns out that it might not be a smart move to keep it under interfaces, as it would have to implemented within the ethernet script or if it's a separate one, it needs to be called with VYOS_TAGNODE_VALUE, otherwise there won't be a way to find out what interface needs to be configured. If placed under service or any other path, it can be integrated into the config itself e.g. set service ipv6-ra interface eth0 <more options>, set service ipv6-ra interface eth1 <more options> etc.
That would only required to parse and compare configs for 2 interfaces which can be determined from the config.

https://vyos.readthedocs.io/en/latest/services/pppoe-server.html

https://github.com/vyos/vyos-1x/commit/b55b68f6246329468b4ab3450e127d5bab683bff or tomorrows rolling release will have it included. I keept the default 'replace' and you can chose between deny or disable, while disable removes the option entirely from the accel config, which I wouldn't recommend to do.

@leacho Sorry, I didn't have the time to look deeper into that, as far as I know we currently have no workaround for it.

per default session=replace is set and if I understand correctly you'd like to have to have the option to change it to deny don't set it at all. Is that correct?

current hop limit is per default set to 64, but can't be set in frr while is was/is possible for radvd. I'd propose to use the the frr options only and not using the current existing ones, that way migration will become easier since the option 'current hop limit' could be just skipped and removed during migration.
Any ideas? Or should we stay with radvd for that purpose?
I would only do it for 1.3 and not backport into 1.2-rolling.

@sunser Can you please clarify if you still encounter that issue?

syslog is required by multiple targets and logs journald messages, stopping it works at the first commit, but the dependencies will start is automatically after reboot. the vyos config is being removed from rsyslog.d but the default rsyslog.conf will be used, which logs daemon, emerg (to console) and auth failures and would have to be changed in vyos-build if required.

Yeah I figured. vyos is being install into /dev/mdX, I can boot via live cd and mount mount it and it has everything in there, but there seems something wrong with writing the boot sector since I would see at least grub. Instead it is empty.

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1671
https://phabricator.vyos.net/T770
are all related to the same issue.

Looks like the vyos-1x images was not rebuilt from the crux branch before the new image was built. I manually checked out the crux branch and the commit ins backported in there, rebuilt the packages manually and everything needed is in there and working.

@kroy Please let me know if you still experience any issues (setting the port or migration).

tested with today rolling release. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912100217-amd64.iso)

@kroy please test with the latest rolling if https://phabricator.vyos.net/T1846 solves your issue.

@Dmitry Tested it with the latest 1.2 rolling, the issue is still present.

fixed in http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb

FRR will serve RAs in the future.

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912061907-amd64.iso and later include the fix

@kroy I can't really reproduce it if I disable the peer first when multiple peers are defined on the same wg interface.
Can you please do a touch /tmp/vyos.ifconfig.debug and then run your commands and post it here?
It will show you the commands execute for each step like:

vyos@wg01# set  interfaces wireguard wg0 peer wg02 disable 
[edit]
vyos@wg01# commit
[ interfaces wireguard wg0 ]
DEBUG/wg0    write '1420' > '/sys/class/net/wg0/mtu'
DEBUG/wg0    write 'wg0' > '/sys/class/net/wg0/ifalias'
DEBUG/wg0    cmd 'wg set wg0 peer G1aA2KkyFyC8xsCUeENvuIW8HC5yDxwi902nR20592Y= remove'
DEBUG/wg0    cmd 'wg set wg0 listen-port 12345 fwmark 0 private-key /config/auth/wireguard/default/private.key peer hbwJSCu6SGUKIReNhWxlDIFRNCl5L7PaUSYOo2BF+Rg=  preshared-key /dev/null  allowed-ips 10.100.100.3/32 endpoint 10.1.1.203:12345 persistent-keepalive 0'
DEBUG/wg0    cmd 'ip link set dev wg0 up'

https://github.com/vyos/vyos-1x/commit/fde531d3791a3d71aa27f99244d7cbb3b3625bf0

looks like i had an old version, newer iso doesn't show that issue.

What were the steps you used when you upated the pubkey?