Even on Kernel 5.4 this is not supported.

The command works on the experimental Kernel 5.9.9 VyOS ISO, but not using a 4.19 series Kernel. looks like it's not yet supported in nftables.

We actually need this:
http://git.nftables.org/nftables/commit/?id=35a6b10c1bc488ca195e9c641563c29251f725f3

Fixed.

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

@jjakob can you check the latest rolling?

https://github.com/vyos/vyatta-cfg-qos/pull/8
https://github.com/vyos/vyos-1x/pull/621

The root cause here is that there is yet no nftables map support in our template.

This one is holding us back from some great 1.3 features... would love to get it looked at!

PR https://github.com/vyos/vyatta-cfg-system/pull/132

+1

PR https://github.com/vyos/vyatta-cfg-firewall/pull/19

@Dmitry I dont really know if this is a good idea.
The reason for this is that the configuration synchronisation between frr daemons depends on the daemons started at the same time, and always running when global configuration is applied.. this is also one of the reasons why frr-daemons starts prior to vyos starting on bootup and not when a daemon is configured. I do not know if this will be a issue with PIM, so i'm not sure what will happen with this daemon.
as an example for such synctonization is a prefix-list.
If you start bgp and ospf and then create a prefix-list, the list will be created in both ospf and bgp.
If you start bgp , then create the prefix-list and then start ospf, ospf will not automatically add the prefix-list but when you show the combined configuration is is still show'ed as a global prefix-list.. to get the prefix-list into ospf you need to manually add the commands to the daemon to get in sync.

This probably happens at this stage.
https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-image-existing#L217-L224

It seems a wrong logic.
We want that option to have an effect on "local" and "forward" directions, so we use table mangle and "PREROUTING" and VYATTA_FW_IN_HOOK hook
Generated rules

Following this issue request https://sourceforge.net/p/opennhrp/support-requests/3/ we need to use transport mode instead of a tunnel. Was tested on AWS node and it looks working even with selector remote_ts = dynamic[gre]

it stop at

AR      crypto/built-in.a
  LD [M]  crypto/crypto_simd.o
make[2]: *** [debian/rules:6: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
make: *** [Makefile:1464: bindeb-pkg] Error 2
vyos_bld@7f2a9dc49956:/vyos/vyos-build-5.4.78/packages/linux-kernel$

T490

@olofl Can you check the latest rolling release? Are all logs sent correctly?

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

Put in a PR to enable ethernet sub interface MPLS enablement

@bbs2web, I figured it out. I know what's not working.

I just did some testing, and @bbs2web, you're right. Sub interfaces to not get enabled. However main interfaces *DO* get enabled.

Let's run pimd only if IGMP or PIM configured.
https://github.com/vyos/vyos-1x/pull/618
https://github.com/vyos/vyos-build/pull/134

Try the new rolling by the way. There was a problem initially that we had to fix. Do like the rolling from 11/25 or tomorrow of 11/26.

If I remove the manual sysctl lines it surprisingly still appears to work but proc net mpls is not flipped on as I would have expected.

@bbs2web, yessir, this is a new changed behavior. In the past when you configured an LDP interface it also enabled MPLS on the same interface.

PR https://github.com/vyos/vyos-build/pull/133

So once a bigger disk is added on system boot the filesystem should be automatically repartitioned and resized to the maximum available space?

Is it expected that 'cat /proc/sys/net/mpls/platform_labels' yields '0' unless one defined 'set protocols mpls interface X'?

• https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels/#erspan
• http://vger.kernel.org/lpc_net2018_talks/erspan-linux-presentation.pdf
• https://www.youtube.com/watch?v=DItjNsku9zY

Created a GitHub PR against 5.4.78 with the core functions listed above, ixbe and QAT in-tree as well as wireguard (avoids the convoluted module builds and permits LTO/CFI passes)

@c-po This task has been completed for so long, can the PR be reviewed?
PR: https://github.com/vyos/vyos-1x/pull/508

I took a brief look, the ip command seems to support the relevant tunnel type

TYPE := { vlan | veth | vcan | vxcan | dummy | ifb | macvlan | macvtap |
           bridge | bond | team | ipoib | ip6tnl | ipip | sit | vxlan |
           gre | gretap | erspan | ip6gre | ip6gretap | ip6erspan |
           vti | nlmon | team_slave | bond_slave | bridge_slave |
           ipvlan | ipvtap | geneve | vrf | macsec | netdevsim | rmnet |
           xfrm }

Another bug that the following configuration doesn't configure vtysh level debug

Perfect. Thanks.

The main reason is frr code for placing log files in a separate file.
https://github.com/FRRouting/frr/blob/master/tools/etc/rsyslog.d/45-frr.conf

That is the idea.

So if one uses

set system ntp server <server>

it will render on ntp.conf

server <server> iburst

Why not introduce a new pool option like: set system ntp server <server> pool ?

Its not a bug of VyOS. The net-snmp linux package we utilize does not support more OIDs.

Vtun interfaces are now created prior to starting OpenVPN to always ensure there is a kernel interface available