@c-po I didn't find out where to call using wide DHCP. I intend to analyze the reason why restart can't automatically start allocating prefix in the 20200523 image.

Additional information, it also appears to be broken in 1.2.5 (self built image) - seems to be the same problem.

Show ip route without prefix don't work.

VyOS added those during the 2nd boot after upgrade. I would assume bug related to the fact that my config doesn't include eth0.

set policy community-list COM01 rule 10 action permit 
set policy community-list COM01 rule 10 regex 65001:0
commit
[edit]
vyos@r-roll#

commit without errors

vtysh -c "show run"
!
bgp community-list expanded COM01 permit 65001:0
!

Why 2 times hw-id for eth1 eth2 eth3

In T2523#65310, @c-po wrote:

Why is there no eth0 on VyOS 1.2.5?

I included all the bits I thought were relevant in T421#65109 (you'll need to click "Show older changes" at this point to see it).

@gadams, please describe use case where wide does not start and include config with expected result and VyOS version. Sure config can be adjusted, luckily its an open Git repo so just send a PR.

@c-po @gadams In 20200523, I found several bug, although it will not affect my use too much (anyway, it can be restarted). For example, when pppoe is rebooted many times, the prefix will be reassigned, but the old prefix that has been assigned has not been deleted. Although I can keep it working, I still don't know how to solve it. I wonder whether restarting its interface can solve the problem when the current prefix allocation request is restarted.

I will track and test whether the dhcpv6-pd is functioning properly to see if the previous problems still exist in my environment.

Thanks for the response.

dhclient is not used, wide-dhcp client is started on demand. Also prefixes are properly assigned to interfaces, using this at home for pppoe. Specific prefix size request is implemented as of T2506.

Hey, @c-po, thanks for getting this moving again. As you may recall, I did a lot of development work on this some time ago that I never pushed to get merged. (I dropped the ball.) Unfortunately, you've had to re-do a lot of what I did, I'm sure. I'm happy to incorporate any of that past work or do some fresh development to polish this feature up.

Windows 10 works with SLAAC like a charm.

I tried mocking with your configuration and thus needed to delete the policy statement as I have no policy installed. Maybe you can boot your system with the vyos-config-debug option and share the output? Or send the full config.boot.

Why is there no eth0 on VyOS 1.2.5?

fixed, in https://github.com/vyos/vyos-documentation/pull/259

https://github.com/vyos/vyatta-conntrack/commit/02c29a9f1f6ddb3c04aee948781e765a7ca2c829

Successfully tested on 1.3-rolling-202005261512, propose to backport it to CRUX.

vyos@r-roll:~$ show ip 
  Invalid command: show [ip]

Need to remove from Makefile 2 strings

Does anyone have some idea on how to test with different kernels? For now this is a deal breaker while using the 1.3.x branch. Tho I would really love to keep using bleeding edge in order to help testing things :-)

One other question -- looks like SLAAC is working with the router-advert, but I believe Windows clients need DHCPv6 to receive addresses. I believe that the auto-config of DHCPv6 based on assigned prefix is not included yet, correct? Is that the 'Assisted' or 'Managed' modes that pfSense/Opnsense has?

Thank you @c-po. It's very good. I fully understand you. Like you, most of the open-source contributors are amateurs. I don't mean anything else. I think you may have misunderstood my remarks. Please don't be too sensitive. Anyway, thank you. In addition, you can take a look at the comments above and the two questions I raised. I don't know how to solve it for the time being. If you or someone else has a good solution, thank you.
Thanks again

@jack9603301 please note that this is currently a beta implementation which of course contains bugs. Also the CLI will change in the near future to support requesting specific prefix sizes (T2506)

The ethernet TypeError is fixed in the upcoming rolling release

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):