Jann Haber <jann.haber@xxxxxxxxxx> wrote:
> - flags interval: We have some maps (e.g. for SNAT), which are supposed
> to contain IPv4-nets ( >= /31) as well as single ips ( = /32) as keys.
> If we make one named map out of both (with flags interval), the single
> IPs are not matched (even if /32 is explicitly given). It is however
> possible to load the set (no syntax errors or such).
Which kernel version is that?
Can't reproduce it after a quick test on 4.19.8 or nf-next development
tree.
It should work with a single map.
> - counters: In our iptables setup, we use the counters to count the
> traffic of our users. We want to do the same in nftables. We therefore
> created a bunch of named counters (it's about 22k of them) and a map
> mapping a certain subnet/ip to the counter name. When we load the rules
> with "nft -f", there seems to be a delay of some seconds, where no more
> packets are processed. Since we do this frequently, these are frequent
> outages of our entire network and this is unacceptable for us. When we
> comment the counters and the map, the delay is gone.
Could I ask why you need to re-load everything often?
The counters can be retrieved/reset individually without changing
ruleset:
nft list counters
table inet filter {
counter foobar { packets 102040 bytes 8571876 }
}
nft reset counter inet filter foobar
table inet filter {
counter foobar { packets 102040 bytes 8571876 }
}
nft list counter inet filter foobar
table inet filter { counter foobar { packets 0 bytes 0 }
}
(Even if you do do full reload: it should not impact packet flow like
this).
> Any suggestions, if this can be improved or where we go wrong, that we
> experience this delay?
The only major issue I see is that adding a lot of object doesn't scale
right now.
I will get to it next week, adding 20k named counters should not be a
problem.
