From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Markus Wigge <wigge@bht-berlin.de>
Cc: netfilter@vger.kernel.org
Subject: Re: commit to kernel fails since Debian 12 (bookworm)
Date: Wed, 18 Oct 2023 14:05:21 +0200 [thread overview]
Message-ID: <ZS/KAY6Jss8TbOr/@calendula> (raw)
In-Reply-To: <0f294468-d7c5-477c-b95f-6a5ce68fd79e@bht-berlin.de>
On Wed, Oct 18, 2023 at 01:31:26PM +0200, Markus Wigge wrote:
> Hello,
>
> > So VLAN interfaces are distributed between nodes and, on failover, one
> > node picks up the VLAN interfaces of the node that is failing? I am
> > trying to understand if, in your setup, one node is active but is is
> > also at the same time a backup for the flows that are handled by the
> > other node.
>
> Yes, the VLAN interfaces are available on both nodes but only one nodes has
> configured IP addresses on the interface. The other nodes only takes over
> the address with keepalived if necessary.
>
> So could it be possible, that the kernel notices flows on the passive VLAN
> interface?
Then, I assume there is HA daemon that sets this IP on the VLAN
interface. From what you describe, disabling _loose connection pickup
should be safe.
> > This is how it works with net.netfilter.nf_conntrack_tcp_loose = 1,
> > that toggle enables "poor man" connection pickup, that is, the kernel
> > infers from the middle of the connection the current state.
>
> But why does the kernel see this connection at all when it flow over the
> other node?
>
> > > > Is your ruleset dropping invalid packets?
> > >
> > > Only for smurfs as far as I can see:
> > > > 203M 19G smurfs 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
> > >
> > > > Chain smurfs (7 references)
> > > > pkts bytes target prot opt in out source destination
> > > > 19M 6211M RETURN 0 -- * * 0.0.0.0 0.0.0.0/0
> > > > 0 0 smurflog 0 -- * * 0.0.0.0/0 0.0.0.0/0 [goto] ADDRTYPE match src-type BROADCAST
> > > > 0 0 smurflog 0 -- * * 224.0.0.0/4 0.0.0.0/0 [goto]
> >
> > This RETURN means you take back invalid packets to the chain where the
> > jump to smurfs happen.
>
> Yes and there are dedicated chains for the configured zones which each drop
> INVALID packets.
Yes, but _loose is disabled. And I suspect _be_liberal is disabled
too, invalid packets are unlikely with this configuration.
> > > Following the logs it appears to me that every single entry is getting
> > > late then. I doubt that and don't see where state should come from
> > > beforehand.
> >
> > From datapath itself, from the _loose mechanism that is enabled.
>
> What datapath? The passive node should not be involved with the flows of the
> other node?
As said, EBUSY means conntrackd is trying to update an existing entry
in the kernel.
How is all this going on, you have to diagnose in your setup.
There is `conntrack -E` which shows the tag [USERSPACE] for entries
that are created by conntrackd.
[NEW] tcp 6 10 ESTABLISHED src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0 [USERSPACE] portid=2149
prev parent reply other threads:[~2023-10-18 12:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 14:02 commit to kernel fails since Debian 12 (bookworm) Markus Wigge
2023-10-13 14:26 ` Kevin P. Fleming
2023-10-13 14:41 ` Pablo Neira Ayuso
[not found] ` <6289ae8d-7d8e-40a5-a012-3e6e32251942@bht-berlin.de>
[not found] ` <ZS0TvfCRySTWfdW6@calendula>
[not found] ` <43708702-0f37-4ea6-9b3d-4dc8ac2913a1@bht-berlin.de>
2023-10-16 21:24 ` Pablo Neira Ayuso
2023-10-18 11:31 ` Markus Wigge
2023-10-18 12:05 ` Pablo Neira Ayuso [this message]
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=ZS/KAY6Jss8TbOr/@calendula \
--to=pablo@netfilter.org \
--cc=netfilter@vger.kernel.org \
--cc=wigge@bht-berlin.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).