The problem is that there is no input validator for the mac address. Thank you for reporting this!

PR https://github.com/vyos/vyos-1x/pull/692

Will remove test case and rebase to create PR and merge for 1.4; will later backport to 1.3 pending any issue.

PR https://github.com/vyos/vyos-1x/pull/691

I have finished the test of nat66 in GNS lab

Two minor comments left out of the above:
(1) The script in question runs a check on all interface definitions, however, there is no measurable increase in compile time.
(2) lxml will escape characters '>', '<', however these are unescaped by build-command-templates, so the issue is mooted. One can see the single line changed in the XML by running the test case above; it is noted that some interface definitions already have a mixed use of, say, '>' and '&gt;'.

Feature was present in 1.2 and until now not possible with nftables, so we keep the old CLI and just replace the engine for now. Adding the prefix option simply feels more complicated in terms of validation logic and scripting.

Since the current branch uses the kernel Linux 5.10+, I began to pay attention to the implementation of NPT again. At present, I have completed the following features:

'nopmtudisc' option still not present

@c-po Why not consider dnat prefix to? Maybe it's more convenient

Preprocessing solution in testing here:
https://github.com/vyos/vyos-1x/compare/current...jestabro:override-default

Implemented on the 1.4 current branch, once the QAT issues are resolved for 5.10 Linux Kernel this can be backported after successful testing to 1.3 equuleus LTS branch.

Looks good. But maybe it is reasonable to change argument start-suppress-time to start-suppress because it is not a time, but penalty points

Bug with frr-reload.py script

Interesting. I agree, I think that defeats the purpose of VRRP if both have to be running. I guess we can go ahead and close this as not feasible at this time.

"the VRRP instance will only be able to come up if both VRRP instance are running, which somewhat defeats the purpose of VRRP. " ref https://manpages.debian.org/buster/keepalived/keepalived.conf.5.en.html

Fixed, VyOS 1.4-rolling-202101171022

vyos@r5-roll:~$ show vrrp 
Name    Interface      VRID  State      Priority  Last Transition
------  -----------  ------  -------  ----------  -----------------
GRP     eth1             99  MASTER           90

The neighbor interface section needs to be updated
It was in the old template.
https://github.com/vyos/vyos-1x/commit/570886631deae3de8c38ea4ff70710e7a4858cbd#diff-c8405ef7cc0b5938bde66328e60f83c3cdc8d47f26a59bf86d646a63d1d4e5a7R512

Still present in the 1.2.6-S1 release. Makes vyos unusable in environment with DHCP WAN IPs and using the DNS forwarder for specific domains. Those domain forwarders are lost every time the ISP renews the public IP.

Further debugging revelead it's a problem inserting the VRF BPF code, but I wonder why systemd does not restart the service one more time, then it works.

Can you provide the full configuration? Or re-test it on the latest rolling release?
What is the IP address 10.64.0.1?

Possible reason in "reload section" frr.py + rpki

PR https://github.com/vyos/vyatta-cfg-quagga/pull/63

On 1.3-rolling-202101061750 has changed to kernel 5.10,

Put in a PR for this request.

Fixed

vyos@r5-roll:~$ show ntp 
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*194.0.5.123     85.199.214.102   2 u    4   64    3   39.557   -2.748   2.504
+167.86.115.96   235.106.237.243  3 u   39   64    3   45.816    5.476   0.830
+195.128.100.150 131.188.3.222    2 u    4   64    3   43.219   -1.425   1.734
vyos@r5-roll:~$ 
vyos@r5-roll:~$ show version

I found a workaround (persists across reboots and upgrades):

cat <<'EOF' >/config/scripts/vyos-preconfig-bootup.script
#!/bin/bash