Re: meter in 0.9.1 (nft noob question)

Re: meter in 0.9.1 (nft noob question)

[Duncan Roe]

On Wed, Aug 07, 2019 at 04:13:36PM +0200, Laura Garcia wrote:
> On Tue, Aug 6, 2019 at 8:21 PM Duncan Roe <duncan_roe@optusnet.com.au> wrote:
> >
> > I thought meters were unique in that the set underlying them gets added to
> > by incoming traffic. Can maps/sets do that?
[...]
>
> Sure, something like:
>
> table ip my_filter_table {
>     set my_connlimit {
>         type ipv4_addr
>         size 65535
>         flags dynamic
>         elements = { 192.168.56.1 counter packets 2 bytes 656 }
>     }
>
>     chain my_output_chain {
>         type filter hook output priority filter; policy accept;
>         ct state new add @my_connlimit { ip daddr counter } accept
>     }
> }
That works really well, thanks! Also I like that nowadays you get 2 addresses
per line instead of one long line with all addresses. I added a timeout to limit
the display length, here's a sample:

> 01:25:53# nft list ruleset
> table ip my_filter_table {
>         set my_connlimit {
>                 type ipv4_addr
>                 size 65535
>                 flags dynamic,timeout
>                 timeout 10m
>                 elements = { 10.255.255.3 expires 6m16s920ms counter packets 1848 bytes 173538, 13.55.50.68 expires 7m7s746ms counter packets 1 bytes 76,
>                              23.202.173.53 expires 3m8s953ms counter packets 5 bytes 300, 54.66.128.84 expires 8m10s639ms counter packets 1 bytes 60,
>                              54.230.243.55 expires 8m10s627ms counter packets 1 bytes 60, 103.126.53.123 expires 2m59s746ms counter packets 1 bytes 76,
>                              127.0.0.1 expires 1m36s898ms counter packets 4311 bytes 125298, 151.101.82.110 expires 8m10s632ms counter packets 1 bytes 60,
>                              162.247.242.20 expires 8m11s529ms counter packets 1 bytes 60, 172.217.25.36 expires 3m10s434ms counter packets 2 bytes 120,
>                              172.217.167.98 expires 8m10s89ms counter packets 3 bytes 180, 184.24.244.106 expires 8m10s425ms counter packets 2 bytes 120,
>                              216.58.196.138 expires 3m10s333ms counter packets 2 bytes 120, 216.58.199.33 expires 3m9s595ms counter packets 2 bytes 120,
>                              216.58.199.34 expires 3m9s590ms counter packets 2 bytes 120, 216.58.199.78 expires 8m10s1ms counter packets 1 bytes 60 }
>         }
>
>         chain my_output_chain {
>                 type filter hook output priority filter; policy accept;
>                 ct state new add @my_connlimit { ip daddr counter } accept
>         }
> }

After some post-processing and running under "watch":

> Every 2.0s: nft list ruleset|q -niu,/home/dunc/macros/nft1.qm^J^N^Z            dimstar: Mon Aug 19 13:43:51 2019
>
> table ip my_filter_table {
>  set my_connlimit {
>   type ipv4_addr
>   size 65535
>   flags dynamic,timeout
>   timeout 10m
>   elements = {
>    ec2-13-55-50-68.ap-southeast-2.compute.amazonaws.com expires 8m44s328ms counter packets 1 bytes 76,
>    syd15s01-in-f68.1e100.net expires 7m39s862ms counter packets 1 bytes 60,
>    syd09s17-in-f10.1e100.net expires 7m39s721ms counter packets 1 bytes 60,
>    syd15s04-in-f1.1e100.net expires 7m39s120ms counter packets 1 bytes 60,
>    syd09s13-in-f2.1e100.net expires 7m39s115ms counter packets 1 bytes 60,
>    syd09s14-in-f2.1e100.net expires 7m38s594ms counter packets 3 bytes 180
>    syd15s01-in-f14.1e100.net expires 7m38s512ms counter packets 1 bytes 60,
>    a23-202-173-53.deploy.static.akamaitechnologies.com expires 7m38s503ms counter packets 2 bytes 120,
>    localhost expires 6m3s123ms counter packets 1733 bytes 50381,
>    pauseq4vntp2.datamossa.io expires 4m52s328ms counter packets 1 bytes 76,
>    bam-8.nr-data.net expires 2m39s43ms counter packets 2 bytes 120,
>    syd15s02-in-f4.1e100.net expires 2m38s911ms counter packets 1 bytes 60,
>    ec2-54-66-128-84.ap-southeast-2.compute.amazonaws.com expires 2m38s158ms counter packets 2 bytes 120,
>    server-54-230-243-55.mel50.r.cloudfront.net expires 2m38s138ms counter packets 2 bytes 120,
>    151.101.82.110 expires 2m38s138ms counter packets 2 bytes 120,
>    a184-24-244-106.deploy.static.akamaitechnologies.com expires 2m37s944ms counter packets 4 bytes 240,
>    syd15s03-in-f2.1e100.net expires 2m37s619ms counter packets 3 bytes 180,
>    dullstar.local.net expires 44s23ms counter packets 4344 bytes 409775,
>   }
>  }
>
>  chain my_output_chain {
>   type filter hook output priority filter; policy accept;
>   ct state new add @my_connlimit { ip daddr counter } accept
>  }
> }

The elements are sorted by decreasing expiry times, as well as the obvious
changes (1 elemnt per line, nothing else on an element line, display narrowed to
canonical minimal indent, IP addresses resolved where possible).

*** 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.

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.

Was there a discussion on the list about this (possibility of reverting expiry
times) previously? Would there be much to it? I'm not especially familiar with
the kernel code but, supposing I figured it out, would a patch be acceptable?

IAC I'd be delighted to share the postprocessing software with anyone who's
interested,

Cheers ... Duncan.

Re: meter in 0.9.1 (nft noob question)

[Laura Garcia]

Hi Duncan,

On Mon, Aug 19, 2019 at 6:11 AM Duncan Roe <duncan_roe@optusnet.com.au> 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.

Re: meter in 0.9.1 (nft noob question)

[Duncan Roe]

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 <duncan_roe@optusnet.com.au> 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.