Re: commit to kernel fails since Debian 12 (bookworm)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



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.

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?

Kind Regards
Markus



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux