I removed my comment as my issue was not a bug AFAIK, but rather a miss-configuration and operation.

Yeah I discovered the same in forums:

I was not aware that the nft implementation changes the kind of how groups are used.
We have implemented a blacklisting approach which heavily relates on using ipset because no one wants to have hundred thousand of addresses in the config file.
So I think this is essential, at least for us.

FRR match always mean logical AND

In T4350#123620, @c-po wrote:

Is the fix for DMVPN hub or spoke?

There is an issue with vrf device for LOCAL direction
Imagine if you have 50 interfaces in one VRF and you want to drop all traffic from one interface for example - eth2 and don't touch other interfaces
You set firewall on eth2 Local - drop all traffic for device vrf and it will be affected to another 49 interfaces as iifname VRF_DEVICE the same

Is the fix for DMVPN hub or spoke?

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

set firewall name FOO default-action 'accept'
set firewall name FOO description 'desc'
set firewall name FOO rule 10 action 'drop'
set firewall name FOO rule 10 source address '8.8.8.8'
set interfaces ethernet eth0 firewall local name 'FOO'
set interfaces ethernet eth0 vrf 'ONE'
set vrf name ONE table '150'

Check:

table ip filter {
	chain VYOS_FW_LOCAL {
		type filter hook input priority filter; policy accept;
		iifname "ONE" counter packets 63 bytes 6024 jump NAME_FOO
		jump VYOS_POST_FW
	}
...
	chain NAME_FOO {
		ip saddr 8.8.8.8 counter packets 79 bytes 6636 drop comment "FOO-10"
		counter packets 3 bytes 984 return comment "FOO default-action accept"
	}
}

https://github.com/vyos/vyos-utils/commit/5bbda46493d0c11c8a90e50a68c9788a7488345e
https://github.com/vyos/vyos-utils/commit/4aa302a05fad95f3d13eb2ff20bbfee88c32e7ff

@jjakob could you re-check it with new fix?

Draft PR here:
https://github.com/vyos/vyos-1x/pull/1328

PR https://github.com/vyos/vyatta-op-firewall/pull/3

PR https://github.com/vyos/vyatta-op-firewall/pull/3

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

Details of adding a query such as this (20 lines of meaningful code/50 of boilerplate):
https://github.com/vyos/vyos-1x/commit/b62f5df2c796d0567b370e27fcec2005a02a4cd3

An initial implementation has been provided to Andrew Moshensky for testing with the local UI.

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

@c-po, lets run with "system-as"

The current discussion has taken place in the vyos-api-discussion channel; results will be summarized here.

Need testing:

set service pppoe-server authentication mode 'radius'
set service pppoe-server authentication radius rate-limit attribute 'Mikrotik-Rate-Limit'
set service pppoe-server authentication radius rate-limit enable
set service pppoe-server authentication radius rate-limit multiplier '0.001'
set service pppoe-server authentication radius rate-limit vendor 'Mikrotik'
set service pppoe-server authentication radius server 192.0.2.1 key 'foo'
set service pppoe-server client-ip-pool start '192.0.2.5'
set service pppoe-server client-ip-pool stop '192.0.2.254'
set service pppoe-server gateway-address '192.0.2.1'
set service pppoe-server interface eth3

Or any live example

Firstly, is there any info in the logs ?

As discussed in the slack channel today, let us follow up here, as I'd like to run through some analysis, and set up a reproducer if possible.

The command works well.

I agree that having a smoketest for WLB will be great. But, there are certain limitations/considerations: