The new design introduced with https://phabricator.vyos.net/T2653 does not show any pitfalls and infact increased the code maintenance in an unimaginable way.

Confirmed working

This is actually a "wontfix" b/c it depends on the users hardware

Proper handle OS exceptions for the user:

Try to port NDP Proxy to the NAT66 code of T2518 and automatically generate it

Note that because the test requirements are not met for the time being (vyos does not use the linux kernel with a kernel version of 5.8+ for the time being), it cannot be tested well. The merged code has not undergone any testing. Please upgrade the vyos linux kernel to 5.8+ , Let me know that I can perform related tests, and merge after testing

It looks like this issue is already present in 1.3-rolling-202010270217, before the OpenVPN rewrite to get_config_dict():

We will deal with the compat-names warning once starting on VyOS 1.4 ;)

Work with latest rolling release:

Put in a PR for refactor of LDP template, MPLS python handler, addition of global MPLS parameters (via Linux kernel config changes), and separation of MPLS interfaces from LDP interfaces. *PLEASE* know I did do testing but I want more people to test as well. I have uploaded the package file for this PR here so that people can test my work.

See subtask T3082 for origin and details of this issue.

@Viacheslav Thanks a lot, I'll give it a go, hopefully sometime next week.

@bbs2web, oh don't you worry. I've had my eyes on it after I get LDP done. I'm almost done with it too.

Layer 2 mpls functions were merged in to the kernel on the 3rd of October, this should hopefully allow BGP signalled VPLS and static LDP pseudowire tunnels. Support still appears to be missing in FRR and it will probably be a while until VyOS is based on this newer kernel, but hoorray!

Device-type tap option works incorrectly

set interfaces openvpn vtun20 device-type 'tap'
set interfaces openvpn vtun20 local-address 10.0.0.0
set interfaces openvpn vtun20 local-host '100.64.0.1'
set interfaces openvpn vtun20 local-port '22222'
set interfaces openvpn vtun20 mode 'site-to-site'
set interfaces openvpn vtun20 remote-address '10.0.0.1'
set interfaces openvpn vtun20 remote-host '100.64.0.2'
set interfaces openvpn vtun20 remote-port '22222'
set interfaces openvpn vtun20 shared-secret-key-file '/config/auth/foo.key'

@Dataforce @fetzerms
ip rule "from" already in CLI T439

Okay, then I can merge this service into NAT66

That we can deal with later on when it‘s needed

@pasik Can you check if it solves your expectation?

I can consider migrating to the implementation of nat66, but I'm not sure if there is a case where the nat66 feature does not need to be enabled, but NDP proxy needs to be enabled

I still have the opinion that NDP proxy should be automatically configured when configuring nat66 as by then all interfaces and directions of the translation are known and the user must not configure any additional daemon.