As the mtu on an ip network could exceed 1500b it is not so strange to allow larger than 1500b frames on the tunnel. But this could be adjusted to follow the max mtu values on ethernet interfaces. As taken from my head max mtu on ethernet is about 9000b

https://github.com/vyos/vyos-build/pull/95

I'm looking forward to this feature, especially that I want to dynamically update the NPT policy through the DHCPv6 PD feature, rather than manually reset the nptv6 address translation policy every time I dial

It's a good idea to use OVS as Linux bridge, which means that vyos can use OVS to provide better management and more support features in bridge management, or even use vyos as an excellent switch to run and manage its complex functions, or provide a docking interface with SDN to transform the network!

Yes, @jjakob, I run docker as indicated in the vyos-build README, which includes --privileged. I am not that concerned with the docker issue here; rather I want the script to work, and am adding in the necessary ingredients to the script itself. Compare the older prescription:
https://wiki.vyos.net/wiki/Building_images_using_vyos-build_Docker_container#Building_Google_Cloud.2FGCE_image

just note. our fw is using own dns forwarder for resolv, because the internal ip reverse addresses are redirected to local dns server.
so plase handle this situation too.

We hope to provide better support for DHCPv6 PD in the future version of vyos

The discussion says the container should be started with --privileged, as is documented in the vyos-build readme. Did you test it with --privileged?

Duplicate of T421

Still present in 1.3-20200319

The above commit fixes value help on tab (it displays correct quoted values, the script doesn't error any more) but the completion itself is still broken.

@hagbard
Another bug:

@alien Can you please test the issue with the latest rolling release?

This should be made consistent with other usage: paths should be lists, not strings. I will make the change, and any other details needed for consistency with model.

I opened the PR for our custom build of the package in vyos-build as well: https://github.com/vyos/vyos-build/pulls. I was waiting on testing results from anyone, but I went and tested it myself. The basic functionality works, I couldn't test the above bug. If it's merged and the new package build is added to CI, the above debian PR isn't needed (or our custom build isn't).

I ran into this today after upgrading to latest 1.3 rolling image. All interfaces were added and appeared to have the correct macs (the output of ip link matched what was in the config), but the physical interfaces to which they corresponded weren't right. I found this by looking at the link state of each interface and saw that two if them were swapped. The interface that should be eth2 was physically eth4 and vice versa, but the macs it was showing in ip link was wrong for that physical card, as if it were set to the other interface's mac erroneously.
I got the cards to detect properly after 2 reboots.

I installed 1.3-rolling-202003190217 today and verified that it contains the following lines now:

I seem to experience the same in a VRRP setup using VyOS 1.3-rolling-202003110613. I will try to gather more information along with a sample config file.

Some tests results

vyos@R8:~$ show configuration commands | match mpls
set protocols mpls ldp discovery transport-ipv4-address '2.2.2.2'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'eth2'
set protocols mpls ldp router-id '2.2.2.2'
vyos@R8:~$ show mpls ldp neighbor 
AF   ID              State       Remote Address    Uptime
ipv4 10.0.0.1        OPERATIONAL 10.0.0.1        00:00:22
ipv4 3.3.3.3         OPERATIONAL 10.0.255.2      00:00:33
vyos@R8:~$ show mpls ldp interface 
AF   Interface   State  Uptime   Hello Timers  ac
ipv4 eth1        ACTIVE 00:00:51 5/15           1
ipv4 eth2        ACTIVE 00:00:52 5/15           1

2 PR for basic MPLS implementation
https://github.com/vyos/vyos-build/pull/90
https://github.com/vyos/vyos-1x/pull/247

Could you describe your "dream syntax" for it?
The op mode node.def's simply don't have a concept of value help in vyatta-cfg, only comp_help (<completionHelp> in XML terms).

https://salsa.debian.org/pkg-netfilter-team/pkg-conntrack-tools/-/merge_requests/1
if he merge the PR, we can use it!

There is yet no intention to add such command. Usually all description strings are rendered into the appropriate configuration file or are added to the interface as alias used by SNMP monitoring. What you wish to do is actually commenting on your configuration. Please refer to the user-guide about the comment command.

A description field is required to understand what this is for.

https://github.com/vyos/vyos-documentation/pull/220

What exactly do you mean with "description"?