On Thu, Aug 22, 2019 at 01:14:40PM +0200, Laura Garcia wrote:
> Hi Duncan,
>
> On Mon, Aug 19, 2019 at 6:11 AM Duncan Roe <[email protected]> wrote:
> >
>
> [...]
>
> >
> > *** I had expected or at least hoped that an element's expiry would revert
> > *** to the timeout interval if it was re-added, but this doesn't happen.
> >
>
> You'd have to use "element update" instead of "element add", but it's
> not supported yet for this case.
>
> > Was that possibility discussed on the list previously? Not having it leads
> > to at least 2 undesirable consequences when watching:
> >
> > 1. Frequently-accessed sites drop off the bottom and re-appear at the top.
> > The lower part of the display would be more stable if expiry times
> > reverted: frequently-accessed sites would stay near the top while others
> > would percolate through.
> >
> > 2. Counters reset when these elements are destroyed and re-created.
> >
>
> As a workaround you can set the expiration time manually until the
> "element update" solution is in place.
>
> Cheers.
Hi Laura,
Many thanks for the suggestion!
I am finding that update *does* appear to work (nftables v0.9.2 (Scram),
kernel 5.2.0), assuming this is what you meant:
> #!/usr/sbin/nft -f
> flush ruleset
> table ip my_filter_table {
> set my_connlimit {
> type ipv4_addr
> size 65535
> flags dynamic
> timeout 10m
> }
>
> chain my_output_chain {
> type filter hook output priority filter; policy accept;
> ct state new update @my_connlimit { ip daddr counter } accept
> # ^^^^^^
> }
> }
Sample o/p:
> a23-202-173-53.deploy.static.akamaitechnologies.com expires 9m57s655ms
> counter packets 214 bytes 12840,
> a184-24-244-106.deploy.static.akamaitechnologies.com expires 7m46s412ms
> counter packets 15 bytes 900,
> bam-9.nr-data.net expires 7m45s462ms counter packets 6 bytes 360,
> syd09s12-in-f36.1e100.net expires 7m45s283ms counter packets 2 bytes 120,
> syd09s15-in-f10.1e100.net expires 7m45s170ms counter packets 3 bytes 180
> ec2-54-66-128-84.ap-southeast-2.compute.amazonaws.com expires 7m44s611ms
> counter packets 9 bytes 612,
Cheers ... Duncan.
