All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Antonio Ojea <antonio.ojea.garcia@gmail.com>
Cc: netfilter@vger.kernel.org
Subject: Re: Confirming conntrack behavior on environments with multiple network namespaces
Date: Fri, 26 Sep 2025 16:03:19 +0200	[thread overview]
Message-ID: <aNadJ2EiPn6pMQ1E@strlen.de> (raw)
In-Reply-To: <CABhP=ta4Rxf-TUa9YU2dAM5zgpkL7sqNHaTSAiHDR_5cXh1hTA@mail.gmail.com>

Antonio Ojea <antonio.ojea.garcia@gmail.com> wrote:
> > Or add 'notrack' rules in init_net for the netns originating traffic.
> > Or create a netns, enable conntrack and then only create connections
> > to addresses reachable via loopback. In all these cases init_net won't
> > be affected by the net namespace.
> 
> It will be hard to disable conntrack in init_net, a lot of
> functionality relies on NAT in kubernetes and is not owned by the same
> component

Sure, I understand that no-conntrack-in-init-but-in-another-namespace
is atypical.

> > That will only monitor that namespace, I'm not aware of a global counter.
> >
> 
> Can this be a feature request? having a global counter can easily
> monitor the load factor of the system, but I'm not familiar with
> kernel conventions and having some global counter may be discouraged

Not sure we should add one, it will result in some overhead for no good
reason.  Maybe /proc/slabinfo is enough for your use case?

nf_conntrack has its own (global) memory pool, it should provide a
reasonably good estimate across all netns.

  reply	other threads:[~2025-09-26 14:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-22  9:38 Confirming conntrack behavior on environments with multiple network namespaces Antonio Ojea
2025-09-23 17:07 ` Florian Westphal
2025-09-26 13:10   ` Antonio Ojea
2025-09-26 14:03     ` Florian Westphal [this message]
2025-09-26 14:41       ` Antonio Ojea
2025-09-30 19:13         ` Florian Westphal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aNadJ2EiPn6pMQ1E@strlen.de \
    --to=fw@strlen.de \
    --cc=antonio.ojea.garcia@gmail.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.