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.

There is now some python XML code to parse the XML. m4 is not a nice tool. If better pre-processing is required, which I would not argue for, please explain the issue you are trying to solve.

@c-po According to H3C, the relevant operations are as follows:

@c-po According to H3C and the third-party information on the Internet, NPT is also called nat66. Nat66 is actually the SNAT and DNAT implementation of IPv6, and implements 1-to-1 mapping and prefix address translation. Since there is no separate configuration directory for these two directions in the configuration, this draft implements two directions. Tomorrow, we will try to modify the configuration path according to the document of H3C device, add the diff of the draft, and then propose Submit merger request.

@c-po It has been revised as follows:

Well I would just have plumbed up the commands locally before doing any templating. Please keep us updated if it works.

I didn't get any specific help. The modified pudding was set up based on the trial and limited third-party data here, and it needs to be fully tested.

@c-po This is a simple draft of my current implementation of NPT. At present, I haven't tested it, and I haven't applied for merger. I can send it here for some discussion.

No I didn't, sorry. I'll test it and see :)

Have you tested the latest codebase? It more or less follows your design for the member ports.

This is not enough, bridge and bond members also didn't get IPv6 link-locals in the previous implementation. To have them is incorrect and a security risk.

The last bug mentioned could be due to: https://phabricator.vyos.net/T2746

TSM support has been droppen in 1.3

related to T1699