However, there will still be other problems, such as those described in the comments above, and two small problems I have raised. For the moment, I can only guarantee that there will be no py syntax interpretation errors.

I have fixed the following error and submitted PR request for it, but it has not been passed yet.

Also related to T2088

I'll be building an image and testing this out today. Thanks Jack!

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

Not enough packages and dependencies.

Will be done as part of T2486

2 PR

PR created, https://github.com/vyos/vyos-1x/pull/431.

it will be converted by some CPE to regular old ethernet,

@gadams Therefore, in order to use SLAAC and DHCPv6 PD in this case, the router below should receive RA from the superior router or CPE device?

I'm sorry, to be honest, I don't understand this sentence. Maybe I don't understand the network in the United States. In China, ISPs use PPPoE for the last kilometer of user authentication.

Come on, I think I've got a patch for py error reporting ready before @c-po. I'll launch PR directly.

This bug exists for remote-host as well.

BGP Router ASN 65001 .
PeerGroup ipv4 & ipv6 ASN65002

I should note that in setups for some very large ISPs in the US, and probably elsewhere, there is no need for a DHCPv6 client at all, except for doing DHCPv6-PD. The directly-connected IPv6 network gets its assignment via RA, and IPv4 addresses may be assigned statically.

That great, and necessary. But then, once that's done (I've done it in my copy), then I seem to be missing the next step: It's not starting a DHCPv6 client. What is supposed to do this?

@gadams Strange, in my environment, delegation requests are successful when PPPoE is used for dialing. When setting delegation on the non PPPoE interface, do you need the superior router to set DHCPv6 PD delegation and issue operations on the interface (this is not required here, I mainly obtain prefix delegation when ISP dials PPPoE)?

@gadams I am ready to fix the following problems. If @c-po doesn't understand what happened and solve it, I may submit PR request.

You can consider submitting a PR request in a rolling branch that has requested a merge.

Essentially, that means that nothing happened. What you want prefix delegation to do on the client side (which is what we're talking about) is request a delegated prefix from the upstream router via DHCPv6, and then divide the delegated prefix into site-level aggregations and assign the resulting network numbers (delegated prefix + sla id) to other interfaces. None of that happened.

However, no prefix delegation request appears to be sent and no configuration of delegated interfaces appears to be done. Indeed, no dhcp client appears to be running.

Hmm. So, correcting that error did allow the configuration to apply and save successfully. However, no prefix delegation request appears to be sent and no configuration of delegated interfaces appears to be done. Indeed, no dhcp client appears to be running.

Incorporated the suggestions in the PR and pushed them up to github for review.

Ah! Yes, I see what you're referring to. I'll take a look at that in a few hours.

Usually this bug should reopen a bug report. The project management system can create subtasks, and you can usually consider opening a subtask

Of course, for the time being, I can only solve the specific code errors introduced by @c-po. Above, I have raised some of the existing minor problems of using delegation in pppoe. I think I may not know how to solve this problem for the time being. If you have this ability, you can consider solving it.

@gadams With regard to this question, I have specifically read the submission record of @c-po, and I think I have found out where the possible errors are (please read my comments above). Of course, I expect @c-po to solve the errors introduced by itself, because it seems very simple, if the problem @c-po is not resolved for a long time, I may consider submitting a pr request.

I'm trying to catch up on the comments. There are a lot.

This work is done by @c-po, but according to my experiment, the current scrolling version is a 20200523 image, and dhcpv6-pd works basically fine in my ISP environment. But there may be some minor problems. Please read the comments on this list.

Oh, wait, is this done, and completely working, now? I'm still trying to catch up on this long thread. If it's all working, now, I'll just have to try the latest build and see if it works.

What does it mean? I'm sorry, I may not understand.

Hello! I appologize tor being absent for so long, now. But I'm back, and ready to contribute again. It looks like I have a lot to catch up on.

In addition, please pay attention to the previous question of another user feedback. I have read the relevant code you submitted, and you may have written it wrong.

a) I know it's not supposed to be like this, but it does show up with me.

a) should not be the case

Hello @lawrencepan , can you explain, why you need different AS for route-reflector-client?
Can you add your route-maps ROUTE-V4 and 'ROUTER-V6?

@c-po In addition, I also feedback several questions (if this is not a problem, please tell me the correct understanding and use):

PR for this task https://github.com/vyos/libpam-radius-auth/pull/3
I propose to use always source-address as NAS-IP-Address if it defined

I added some comments on the PR. First I thought this is a duplicate of T2507 but technically it's not as pdns-recursor supports 2 types of lua file: lua-dns-script and lua-config-file. This task is for lua-dns-script while T2507 is for lua-config-file.

Upstream says this is normal behavior when DNSSEC is enabled, so the workaround that I'm working on (addNTA) is actually the proper fix.

Tested successfully on 1.3-rolling-202005250117

vyos@RTR1:~$ show sstp-server sessions 
 ifname | username |     ip     | ip6 | ip6-dp | calling-sid | rate-limit | state  |  uptime  | rx-bytes | tx-bytes 
--------+----------+------------+-----+--------+-------------+------------+--------+----------+----------+----------
 sstp0  | test     | 100.64.2.0 |     |        |   x.x.x.x.  |            | active | 00:01:16 | 27.9 KiB | 80.3 KiB

Tested on 1.3-rolling-202005250117, works as expected.

@jjakob, yes, thank you.
PR for 1.3: https://github.com/vyos/vyos-1x/pull/434
I will summit PR for 1.2 once 1.3 is released and tested.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/47
for 1.2 and 1.3.

I tried out DHCPv6-PD but so far no luck (but for a separate reason).

I'm would like to try out the new VyOS 1.3 DHCPv6-PD feature.

Prefix delegation is a very important function, which needs to be used to provide routable prefix segment allocation to users.

You can download 20200523 and later scrolling images to use this feature

Dhcpv6-pd can be used normally at present, and it works well in my ISP.

I have just done a bit of background research to understand this change, after I noticed that the level option was deleted from my VyOS config.

See also: https://phabricator.vyos.net/T2209 (Documentation has reference to the old 'user x level admin' option)

These pages also needs updating:

• https://support.vyos.io/en/kb/articles/adding-users-2
• https://support.vyos.io/en/kb/articles/vyos-user-privilege-levels-2

Here is a PR for the work: pull 425 for vyos-1x package

From comments, it looks like this feature is now available?

If this field is only the len, of prefix, there is no need to use prefix writing.

I replaced the distributed guest utilities (vyos-xe-guest-utilities) with the ones that come with xcp-ng. But this changed nothing regarding the packet loss. Tho, now they get properly recognized by xcp-ng :-)

I‘m asking myself if length should be specified as decimal number or as ::/60 prefix?

The "auto grep" could be added to show log indeed that it only displays you pppoe stuff.

In T2505#64896, @jjakob wrote:

If this can be solved by a kernel update, there was talk about maybe having different build "flavors" in the past - one with all the hardware nic drivers, one without. The minimal image could then have the latest (5.x) kernel.
There's T2085 which prevents us from testing any newer kernel ourselves as it's built by Jenkinsfiles in the CI, we'd need to manually do the steps the CI does to build a kernel. I proposed a shared script solution for these repositories in that task that could be called from both the CI and vyos-build, this would allow anyone to build all packages, including the kernel, through vyos-build, just for cases like this.

We probably should send this PoC script (vyos-build/scripts/build-packages.) to the graveyard as it causes more trouble then good I feel.

Note that it is now possible to set the pre-login banner to an empty string: T2099

Guess the CLI needs a change here as this requirement was overseen. It could look something like this (note that PPPoE can be replaced by any other interface), need to work out the details.

The called code can return 3 - in that case in that case _run should return an empty string

Thank you. Finally, RA was able to set and distribute all the new IPv6 64bits prefixes with the following instructions:

Just found this ticket after upgrading and wondering where the show interfaces pppoe pppoe0 log command had gone. I did find it useful to check why a PPPoE interface hadn't come up.

@jack9603301 Do you have a working RA on that interface? You can set service router-advert interface <if> prefix ::/64 for RA to advertise all prefixes on the interface. That way if the DHCPv6-PD prefix changes it will send advertisements for the new prefix automatically.

@Sonicbx @jjakob I also created https://phabricator.vyos.net/T2504 - I think we duplicated the issue here. You can close whichever issue you want.

@c-po At present, through DHCPv6 PD, IP can be obtained on the bridge, but cannot be distributed to the client through SLAAC. Is it my configuration error?

If this can be solved by a kernel update, there was talk about maybe having different build "flavors" in the past - one with all the hardware nic drivers, one without. The minimal image could then have the latest (5.x) kernel.
There's T2085 which prevents us from testing any newer kernel ourselves as it's built by Jenkinsfiles in the CI, we'd need to manually do the steps the CI does to build a kernel. I proposed a shared script solution for these repositories in that task that could be called from both the CI and vyos-build, this would allow anyone to build all packages, including the kernel, through vyos-build, just for cases like this.