Interesting post: https://serverfault.com/questions/152363/bridging-wlan0-to-eth0

Resolved via https://github.com/vyos/vyos-1x/commit/d1c9ee33f25e45cea0d01f9685f99c960ed4d7f8

I also take into account the specific situation of the ndp proxy, the configuration of this link prompts, the configuration format of the ndp proxy is like this.

No arp proxy option is found in the configuration path, ndp proxy can manage multiple address rules under one interface

vyos@vyos# set interfaces ethernet eth0 ip 
Possible completions:
   arp-cache-timeout
                ARP cache entry timeout in seconds
   disable-arp-filter
                Disable ARP filter on this interface
   enable-arp-accept
                Enable ARP accept on this interface
   enable-arp-announce
                Enable ARP announce on this interface
   enable-arp-ignore
                Enable ARP ignore on this interface
   enable-proxy-arp
                Enable proxy-arp on this interface
 > ospf         Open Shortest Path First (OSPF) parameters
   proxy-arp-pvlan
                Enable private VLAN proxy ARP on this interface
 > rip          Routing Information Protocol (RIP)
   source-validation
                Policy for source validation by reversed path, as specified in RFC3704

Although I intended to think that it is easier to write scripts under the protocol, but from an intuitive point of view, it seems that this path is also a good choice (users can use the same command line as the arp proxy to configure) I have written it A sample, then only need to decide how to modify the cli

In T2898#75670, @Cheeze_It wrote:

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I...really would like to not put it under "protocols" but to put it under the interface. It's *much* easier and more intuitive to see it under the interface/sub-interface than to see it in its' own stanza under "protocol" node.

Also, I'd argue it would be reasonable to separate ARP proxy and NDP proxy. That way one can pick and choose. Of course ARP proxy can't work without an IP address configured. NDP proxy can't be configured without an IPv6 address configured (those could be used as checks against configuring it on an empty interface).

If possible, give your suggested cli path for my reference

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I can't find how to enable ipv6 connection tracking. Recompiling and modifying the linux kernel switch does not seem to see the module loaded. I think the current nat66 has completed 90%, and only need to implement ndp proxy to make it work normally.

set interfaces ethernet eth0 ip proxy-arp

I think we do need it, we can’t let users manage all IP manually unless we implement stateful NAT66

set interfaces ethernet eth0 ip proxy-arp. Isn‘t the Kernel sysctl interface enough? Do we really need a daemon?

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.

@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?