NEW counter missed in statistics conntrack -S

The kernel part displaying such statistics in the /proc filesystem method is there:

  if (v == SEQ_START_TOKEN) {
      seq_puts(seq, "entries  searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error  expect_new expect_create expect_delete search_restart\n");
      return 0;
  }

  seq_printf(seq, "%08x  %08x %08x %08x %08x %08x %08x %08x "
          "%08x %08x %08x %08x %08x  %08x %08x %08x %08x\n",
         nr_conntracks,
         0,
         st->found,
         0,
         st->invalid,
         st->ignore,
         0,
         0,
         st->insert,
         st->insert_failed,
         st->drop,
         st->early_drop,
         st->error,

         st->expect_new,
         st->expect_create,
         st->expect_delete,
         st->search_restart
      );

as can be seen, fields searched (replaced by an other field in later kernels), new, delete, delete_list always display 0: nothing feeds these fields.

As I suspected in my previous answer ("or might have been obsoleted") there is no statistic about this with the older method or the newer method.

Here is the commit from 2016 that removed them (probably for kernel 4.9):

netfilter: conntrack: remove packet hotpath stats

These counters sit in hot path and do show up in perf, this is especially true for 'found' and 'searched' which get incremented for every packet processed.

Information like

searched=212030105
new=623431
found=333613
delete=623327

does not seem too helpful nowadays:

• on busy systems found and searched will overflow every few hours (these are 32bit integers), other more busy ones every few days.

• for debugging there are better methods, such as iptables' trace target, the conntrack log sysctls. Nowadays we also have perf tool.

This removes packet path stat counters except those that are expected to be 0 (or close to 0) on a normal system, e.g. 'insert_failed' (race happened) or 'invalid' (proto tracker rejects).

The insert stat is retained for the ctnetlink case. The found stat is retained for the tuple-is-taken check when NAT has to determine if it needs to pick a different source address.

Signed-off-by: Florian Westphal [email protected]
Signed-off-by: Pablo Neira Ayuso [email protected]

Alternative

You can use the conntrackd tool (packaged on Ubuntu there) that can be configured to log events to provide only logs and statistics (instead of its main use for transparent failover between multiple firewalls in a high availability cluster). Ubuntu might be providing a configuration for statistics by default (or in documentation). Here's an example on a system where the conntrackd service is running:

# conntrackd -s ct; sleep 5; conntrackd -s ct
[Fri Oct 15 08:34:08 2021] (pid=3443753) [warning] deprecated unix backlog configuration, ignoring.
cache stats:
current active connections:           65
connections created:              121807    failed:            0
connections updated:              116158    failed:            0
connections destroyed:            121742    failed:            0

traffic processed:
                   0 Bytes                         0 Pckts

[Fri Oct 15 08:34:13 2021] (pid=3443756) [warning] deprecated unix backlog configuration, ignoring.
cache stats:
current active connections:           68
connections created:              121811    failed:            0
connections updated:              116163    failed:            0
connections destroyed:            121743    failed:            0

traffic processed:
                   0 Bytes                         0 Pckts

The tool tells connections created: went from 121807 to 121811. I believe that's the equivalent of the new field removed from kernel.

Note: traffic processed: is certainly for firewall-to-firewall communication between two conntrackd daemons (so will always be 0 here).