Beeing stateless or statefull both should work. We can add a CLI node for the proxy.ndp option like we have for proxy arp on ipv4, no big deal.

Let's check and table "local"
PR for rolling https://github.com/vyos/vyatta-cfg-vpn/pull/37

@Viacheslav, I am unsure if you're able to finish the template and/or work on it more but if you guys ever choose to complete it and add it into rolling then I can test it out in my lab.

In T2518#75586, @c-po wrote:

Beeing stateless or statefull both should work. We can add a CLI node for the proxy.ndp option like we have for proxy arp on ipv4, no big deal.

Beeing stateless or statefull both should work. We can add a CLI node for the proxy.ndp option like we have for proxy arp on ipv4, no big deal.

This is a milestone, which means we have to decide whether to use stateful or stateless

I worked with @jack9603301 and discovered [1] that stateless NAT66 depends on IPv6 neighbor proxy, otherwise VyOS will not respond to IPv6 neighbor discovery broadcasts.

Tested in LTS 1.2.5 and latest rolling release, where it is not allowing to add the AA:NN along with Additive

It is confirmed that there is a bug in the implementation, but no solution has been found yet. In the nat66 rule, the prefix translation is indeed performed in the expected behavior, but the upstream device cannot return the data packet from the specific prefix. If the community has a good solution, please let me know

Marked as resolved

Thanks, let's merge it only after 1.2.6 release

No objection as its a minor enhancement

Can we add this implementation for crux in the old style?
https://github.com/DmitriyEshenko/vyatta-cfg-system/commit/0adc41a62b6d532da7c4b47cb5da920d1ed39664

The main reason for such issues is missing a good one instructions on how to build a proper one image.

@jack9603301 Here is R1

Please give the configuration of R1 so that I can immediately test your topology in the simulation environment

Hey guys, I am testing nat66 from @jack9603301 which @c-po provided the ISO for me today (VyOS 1.3-nat66-202009161808)

Duplicate T2539

Add a smoketest to check if the required config options are present in the kernel configuration to prevent this in the future.

Yeah - its a bug when used in EVE-ng - closing

While i appreciate that you have an opinion of what's "best," i'm not re-summarizing 10+y of Linux out-of-tree history to spoon feed someone data they can, and should (like good engineers do), acquire on their own. Several of those patches are simply in-tree integrations for things currently built and packaged as kmods by VyOS on an LTS tree, the rest are well documented long running projects of their own which one must research and review the source code for anyway to properly understand their function and benefit.

It’s best to provide links to related descriptions instead of asking everyone to search for the related details and patch implementations you describe

@querubin thanks for the info; that requirement should not persist, as current work should lessen the overhead. I'll link the task back here when defined.

I think it was a bug with virtio drivers and bonding.

I can't reproduce it

Tried the latest rolling. It boots/runs if you give it 768MB of memory.
At 512MB it hangs as before. I guess minimum requirements will be
changing.

@querubin Thank you for the detailed results --- firstly, these issues may be overdetermined due to several updates earlier this month; one notable issue is that we had moved to a 5.x series kernel, which showed several problems re QAT support, and an identified kernel bug. We have reverted to 4.19 as of yesterday until the next LTS kernel is available. I would suggest trying the most recent rolling, and then we will diagnose any persistent issues.

In failover mode only one active channel with "best parameters" can be used for connections

@banditos13 Can you describe more details?
What is the bug and how to reproduce it?

Was fixed with https://phabricator.vyos.net/R6:0ecfe5a6d11065388714b0ef21de532f88774357 and T1241