I would not use cpu<numbe> but just <number> like is used for taskset for example, but it would be a real improvement for users.
An op command should be provided giving the affinity of CPU ( from lscpu ) and the documentation should warn about interrupt crossing numa domains (for the case where a network card is providing multiple interfaces).

I actually can not reproduce this issue after fixing T2740. Please retry with the latest rolling which was just uploaded: vyos-1.3-rolling-202008031114-amd64.iso

This configuration replicates the error:

I have to apologize here: While working on https://phabricator.vyos.net/T2653 I knew I must change this and did it on PPPoE but I totally forgot about this on all other interfaces as PPPoE has a special case here.

OK, I take that back. Even when the interface with prefix-delegation defined is dead last, it still has this error. The last IP address is not configured, although /run/dhcp6c/dhcp6c.ethN.conf is correctly created, and DHCPv6-PD works. But config parsing is broken, and the entire config node is missing when I query for it.

Please provide a full configuration for replication

It's actually a little worse than I'd initially realized; the interface that DHCPv6-PD is being requested on (the interface with the prefix-delegation stanza) has to be the very last interface, even if it doesn't refer to the ones after it. So, even if I don't delegate any addresses from eth2 to eth3, it still fails. I have to do the delegation from interface eth3 on a system with four ethernet interfaces. And preliminary testing suggests that it has to be eth5 on a system with 6, even if eth4 and eth5 aren't configured at all.

@c-po Change the task and add duplicate address detection option in force ARP

Hi Jack, the problem was solved in two VMs at OCI after I update the VyOS to version vyos-1.3-rolling-202007311330-amd64.iso.

I also propose migrating the CLI interface from a bitmask (which IMHO no user understands)

This was actually drafted as a PR (https://github.com/vyos/vyos-1x/pull/461) but this PR changed the general incluide file and added only a PPPoE server implementation and left out all the others.

I like the idea of adding our own implementation which mimics jmespath.search() so this definately a +1.

@moepman please checkout the next rolling ISO - at least it works as expected in my LAB

@thomas-mangin Maybe it's better to discuss it here

@thomas-mangin As mentioned in my comments, I refer to the configuration structure of H3C. In the original command structure, nptv6 does not support the division of SNAT and DNAT. In order to implement nat66, I separated it for the following reasons:

When connected via SSH to the router in question every command is run inside the VRF, thus a regular add system image will already run in the VRF. Nevertheless it would make sense to execute the command from another VRF.

It is hoped that this implementation can make the prefix translation work again. Refer to the relevant operation of H3C equipment and fully support nat66

I don't use this kind of tool to test his nftables policy, but I'm used to testing it by manually configuring nftables and replacing my nftables template file with that of the vyos system. Vyos did not report errors during its build configuration.

@c-po The related nftables policy in the local environment test did not find syntax problems, only need to be tested to verify the effectiveness of the function, so I call it experimental support.

I ask myself if it not would make more sense to get the prefix translation working again and then add new features here?

@c-po Can you take a look at this PR for me?

@c-po Can you take a look at this PR for me? At present, the command implementation of ndptool send has been canceled

This PR will provide experimental nat66 support, which needs to be tested

@SrividyaA I just upgraded to the latest rolling image (1.3-rolling-202007311330) and I can still reproduce the exact same issue with the config above. Here's output from show log.

Will do, working on it...let you know as soon as I finished this weekend.

Maybe I just didn't encounter it. In short, please try the latest version first. If this problem still exists, please provide the detailed configuration and environment information of the error to facilitate the recurrence and troubleshooting of community members

Please try the latest version of the image, I have not encountered similar problems at present

Jack, I' am aware regarding SSH protocol to manage it remotely, I work with, but the point is:

I don't understand what you mean. If you use the SSH protocol remotely, you should be able to automatically resume the connection within the allowable time of the protocol. However, if the time is exceeded, you may need to wait for the network connection to recover and reopen the SSH connection.

And there are some PR pending on that exact code ..

If anything this code could/should be extracted in an internal library and then a tool created to replace what we have so the behaviour is consistent in both cases.