set system ipv6 disable can be used to globally disable IPv6 address assignment

I agree this should be killed.

Problem is there are several modules that depend on IPv6 e.g. bridge and wireguard thus it can't be removed anymore.

@rps Great idea. A summary of some brainstorming that we had on Slack with @runar, @rps and @dmitry:

The question is if this is the right place for the fix or if it should rather be moved and made part of the vyos-build ISO build process

Here is the vyos config.

service cloudflare {
    host-name example.com
    login [email protected]
    password password
}

@wcktklwn Can you provide vyos config for dynamic service and config ddclient.conf
Which lines do you add manually?

It fixed in 1.3 version. With "next-hop-interface "

@jjakob for equuleus too, wait for merge PR. We have also some ideas how we can improve net naming, and fix issues with renameX interfaces after boot.

Is this only for crux or also for equuleus? There is also
https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1584
https://phabricator.vyos.net/T291

I guess it has been auto-fixed by https://github.com/vyos/vyos-1x/commit/85349b54ab4de42f81d4c8c4dc84901d1313025f

In the latest VyOS 1.3-rolling-201912261106 all work fine.

Successfully tested on 1.3. PR for current branch https://github.com/vyos/vyatta-cfg-system/pull/113

Note: If we have interfaces with description on device panel, like WAN, DMZ, etc, we can use predefined alias in this case.

vyos@QAT-R1:~$ sudo cat /lib/udev/rules.d/64-vyos-SAF51003I-net.rules 
ATTR{[dmi/id]board_name}!="SAF51003I", GOTO="end_ec_nic"

PR for CRUX branch https://github.com/vyos/vyatta-cfg-system/pull/112

This appears to be a moving target in at least one sense:
The package lists I now see differ from what is listed in the files above; one notable difference is a missing 'systemd-sysv':

A reboot seems to have fixed it.

Can confirm. Problem seems to be fixed now.

I'm also experiencing this for the latest rolling versions eg. https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-201912181733-amd64.iso. This is causing issues when trying to create Packer image builds - total first reboot wait time extended to over 2mins for a successful image build.

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

If this is the issue I would replace the init.d call with systemctl since in 1.3 init.d/radvd is redirected to systemd anyway (maybe the bugs are present in this redirection so it's best to completely avoid it).
1.2 and earlier would still need to call init.d as-is.

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

So I guess the key to duplication here is to:

Maybe even just the action of sudo systemctl restart radvd.service is enough to fix it? It seems to maybe be the case

It seems like maybe something doesn't exist, or permissions aren't working right on a freshly upgraded system, until you manually do something to create it?

So the problem went away until I upgraded to the latest rolling. VyOS 1.3-rolling-201912211124

VyOS 1.3 (rolling/equuleus) is now based on Debian Buster so has isc-dhcp-client 4.4.1.
According to the manual dhclient now has a command line option

--prefix-len-hint
When used in conjunction with -P, it directs the client to use the given length to use a prefix hint of, "::/length", when requesting new prefixes.

It was added in 4.3.6:
https://ftp.isc.org/isc/dhcp/4.4.1/dhcp-4.4.1-RELNOTES

Confirmed on 1.3-20191213, tcpdump on the router shows no advertisements until radvd is restarted with sudo systemctl restart radvd.

This is a known fault, and is not easily fixable in the current implementation. This fault is because the vuos cli manually configures the frr process after it's started, and when the process dies/restarts it will read its config from the saved config file. This makes the process restart into an empty config as we have no way to save the config from the prior process.

According to https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html#474 some more packages are required.

Weird, afaik there was nothing to migrate yet.

Also tried that:

My output there basically matches yours.

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

My guess would be missing live-tools in the recommends=false case; live-tools replaces update-initramfs with its version. I'm building to check ...

And I don't know if it's relevant, but the syslog output is definitely different depending on whether I restart it, or it gets restarted on boot

Upgraded to lastest official rolling:

Tried almost all packages via CI, looks very good.

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?