freebsd-src
freebsd-src copied to clipboard
freebsd
Preserve pf table timers during counters cleanup
Normal behavior for clearing up statistics is preserved: call DIOCRCLRTSTATS with PFR_FLAG_ADDRSTOO Preserve timers (only clear packets/bytes counters): call DIOCRCLRTSTATS with PFR_FLAG_ATOMIC
Example - In my case - "counters" table with ~900k entries (throughout the day). When the timer is not zeroed, it becomes an "entry" timer - when the IP was initially added to the table. Counters are zeroed with ATOMIC, then only the entries within a time period (here's where not zeroing the timer comes into play) are checked - if they have or not have any new packets/bytes (i.e. - are currently active/inactive), while the rest remain untouched. This is then used to determine if an IP should remain in the table or be removed / placed into another table, etc.
Maybe this could be done in a more elegant way, it's just the way I've been using it on my servers for more than 5-6 months w/o any issues whatsoever. Could be extended to pfctl, if desired.
Feel free to rework.
@mjguzik any chance of getting this checked (reworked if needed) / committed?
@kprovost mind weighing in on this? :) Its not breaking the default behavior, just enhancing it a bit.
As far as a "generic" use case - I've explained what I'm using it for - expiring (removing) only inactive blocked addresses - i.e. addresses that are not sending any traffic after a X amount of minutes being added to a "block" counters table. It's a way of tracking how much time the IP has spent in the table. I'm only checking if it's not sending any traffic after it's already being 30 minutes in the table.
As I said - it costs nothing to implement, it doesn't break the normal usage of DIOCRCLRTSTATS - it just adds an additional flag that alters the behavior of DIOCRCLRTSTATS in a predictable way.
I'll let @Onepamopa and @kprovost work this out offline. Our new pull request policy discourages pull requests where there are open issues that haven't been resolved. Please work elsewhere to build consensus for this patch and resubmit... or better yet, have @kprovost commit it. I'm sorry it took the project so long to provide this feedback. We recognized that we weren't doing a good job and have a new pull request policy to try to address lingering issues without feedback like this.
