Can you refer to some experience of other devices supporting DHCPv6 PD!

In T421#60928, @c-po wrote:

Maybe the VyOS fans in China can come up with something, too?

Maybe I'm simplifying a bit too much - but shouldn't this just be a binary on / off and an optional preferred prefix delegation size (normally between a /56 and /64)?

Well, I have been using EdgeMax routers for the past 7 years or so (from the day that the ER-3 Lite was released). I use dhcpv6-pd with them and I think the config is pretty solid. I would do it very similar, if not the same.

Maybe the VyOS fans in China can come up with something, too?

come on. I believe you can do it. The vyos fans in China are looking forward to you!

One of the open question is how the CLI should be designed. None of us found a proper solution yet.

Next rolling will have the definitive fix :)

Keep in mind that this bug was originally filed on 2013-12-31 - so I certainly wouldn't hold your breath ;)

Thank you very much! I hope to get the restored rolling image tomorrow or in the next few days. If it is repaired, can you reply me through this list?

I also want to ask, I expect it to get full support. I think the reason why the official may add features in vyos1.3 is that it is in the need triage category of vyos1.3, and it is not removed or marked as invalid, but just closed. Of course, I'm not official, but I want full support!

My fix for that was merged 7 hours ago so your 202004210117 image doesn't contain it. https://github.com/vyos/vyos-1x/commit/c7d8e39be10a59d64be643cade2213c97f1e3639

Execute sudo systemctl status isc-dhcp-server6 output:

So, what is the status of this ticket? It seems the fundamentals are available to make DHCPv6 PD work, but is someone working on this to add it to vyos?

https://github.com/vyos/vyos-1x/pull/364

I'm working on T2345, but the root issues probably aren't the same. Do you have service router-advert configured, and is it on a bridged interface? Then the cause is T2345. If not (if you have router-advert and dhcpv6-server on a eth interface) then this is a different issue.

This is due to the bridge missing a link-local address. The bridge members also don't need link-local addresses (currently they have them) and IPv6 can be disabled entirely on them.

When the GNS emulator is running, new errors are found. For details:

That fixed it for me. Thanks!

Just tested this using 1.3-rolling-202004201924 and it still happens, so that doesn't appear to have worked.

This is a pretty serious bug. Is there any progress?

https://github.com/vyos/vyos-1x/pull/363

@c-po can you please test if this now works, if so the task can be closed. My testing showed that it does.

https://github.com/vyos/vyos-1x/pull/361

Yeah, I missed that one. Thanks for fixing it c-po.

Fixed in https://github.com/vyos/vyos-1x/commit/f23b73fdd35551960dc958cd42c953fcf52a0e75

Weird - does not happen on my PPPoE test server. Please update us if you find the root cause on this odd behavior with your ISP. Closing this.

show dhcp server leases now works, but I've found show dhcp server statistics is broken as well:

vyos@cr01b-vyos:~$ show dhcp server statistics
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/show_dhcp.py", line 243, in <module>
    leases = len(get_leases(lease_file, state='active', pool=p))
TypeError: get_leases() missing 1 required positional argument: 'leases'

Tested latest rolling, hw-id works as expected again (albeit sometimes buggy, but that's nothing new).

If I execute the above command, it seems that IPv6 settings can't really take effect, and the PPPoE link will be broken every ten seconds. Of course, if I restart vyos, it will return to normal and obtain IPv6 normally! Of course, this is just a problem when I execute these commands in my situation. It doesn't mean that it's the only condition to reproduce this bug!

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

What do you mean by:

Thank you, but I think I found a new bug. After executing the following command, I found that PPPoE frequently relinked, and it seems to return to normal after restarting!

Hehe - the problem here is the upper case F in your IPv6 address - FRR migrates all IPv6 addresses to lowercase letters as per RFC and thus we can't grep for it properly - let me think for a fix.

Damn - I'm so sorry

My best bet is due to the missing set interfaces pppoe pppoe0 ipv6 address autoconf option.

Caused by T2273, issue is also in T2308: systemd uses a private /tmp dir. Should be moved to /run/openvpn or the systemd-private dir disabled (I prefer the 1st option)

I can take this on in conjunction with T1499 since there has been no activity on it for a long time and the issue still very much exists.

@c-po this is the commit that caused this issue. You renamed the config node but didn't include a migrator. https://github.com/vyos/vyos-1x/commit/021a2470bd67dccfac0a53c9f4ef511640c03101

I'll take this one.

I spent the last hour at the console trying to fix this mess. It left me with completely broken internet and also bridged the WAN and one of the LAN ports (several of which are in a bridge). I must've tried rebooting 10 times with both 202004191028 and 202004141515 until I could finally get things to work properly with 202004120117. Before this, I've had problems with 1.2 and 1.3 rolling for years where sometimes the interfaces would get mixed up, but usually one reboot fixed it. Now there is a 100% chance of them being completely mixed up every time.