Ah! ok, I will close this. Looking at the man pages, seems like open nhrp doesn't have a no-unique registration feature?

We don’t use frr nhrpd, more details T2326
We use opennhrp

I just realize it's getting more complicated as python/vyos/firewall.py will later write out the rules for these empty groups and when reading-them in, nftables will complain (again) when trying to resolve them, e.g.

Pythonic reimplementation complete. Now only the XML op-mode definition and the auto-complete script remain.

To my understanding, the template data/templates/firewall/nftables.tmpl is probably the culprit, as it doesn't check whether group_conf.address (and similarly the others) has any elements at all and introduces the offending white-space:

In ISC dhcpd this corresponds to the boot-size option http://www.ipamworldwide.com/ipam/isc-dhcpv4-options.html

Package upgraded

Filtering tested on version 1.4-rolling-202201060842

I revisited this in: https://github.com/vyos/vyos-1x/pull/1147

@Viacheslav Yes, You're right.
in.tftpd got started (but only a few seconds).

Scenario proposed by @NikolayP gives next content in table ip filter:

A simple check works fine:
Set 20% quota for snmpd
And check it with script:

#!/usr/bin/env bash

https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html

It was fixed in above commits, wrong testing form my site.

@aha As I see tftp can't bind ipv6 link local address:

Cherry-pick PR https://github.com/vyos/vyos-1x/pull/1146

It requires checking for 1.3 as it was changed and it uses the old backend on Perl (links above).

It seems -V option:

PR for 1.3 https://github.com/vyos/vyos-nhrp/pull/7

PR for 1.4 https://github.com/vyos/vyos-1x/pull/1145

Check a real generated firewall iptables/nftables config
As 10000 it is the latest default rule, so your rules can be applied after default action with seq 10000

Could you also create a pr for 1.4?
Or 1.4 doesn’t have such limits?

Does it work with vlan bridges T3115?

Some notes:

1. The old syntax is quite terrible. It breaks if an image is named disk-install or running or any remote protocol. There needs to be a cleaner syntax for it, such as copy file from image My-Image/usr/local/foo to path /tmp/foo or show file in remote ftp://ftp.example.net/foo.
2. 'Image tools' isn't exactly a descriptive name for it. It does four operations:
   • show: List files in a directory, or spit information about a file followed by its contents (hexdump if it's binary).
   • copy: Copy a file or directory from one place to another (it can merge directories).
   • delete: Deletes a file or directory (doesn't work remotely).
   • update and updateone: Updates an image's config directory with rsync (the only part directly related to image manipulation). This is actually called clone in the CLI.
3. show, copy and delete should probably be moved to a separate (new) module related to file operations (and coupled with vyos.remote) whilst update needs to become its own thing (a helper script, perhaps).

Tested in VyOS 1.3-rolling-202201030317 & 1.4-rolling-202201070726

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

@NikolayP Could you test if all works fine?
Check the real generated firewal rules.

Is it an actual task? If yes, can someone explain which configuration you expect from keepalived.conf or radvd.conf?
As I see PR 9aad6f was merged.

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

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

It requires option -6
For example:

sudo ip -6 rule add prio 10 from de:de::1 lookup 5

Show v6 rules:

vyos@r11-roll# sudo ip -6 rule show
0:	from all lookup local
10:	from de:de::1 lookup 5
32766:	from all lookup main
[edit]
vyos@r11-roll#

The situation has not changed in VyOS 1.4-rolling-202201070726

Tested in VyOS 1.4-rolling-202201060842
Works

@rps this did not make it into 1.3.0, but was discussed recently and will be addressed; it is, as you point out, a regrettable omission in functionality