All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Bernhard Bock <mailinglists@bock.nu>
Cc: netfilter@vger.kernel.org
Subject: Re: conntrackd failover works partially, was Re: conntrack performance test results in INVALID packets
Date: Tue, 02 Sep 2008 11:56:38 +0200	[thread overview]
Message-ID: <48BD0DD6.9000803@netfilter.org> (raw)
In-Reply-To: <48BD09B6.5010905@bock.nu>

Bernhard Bock wrote:
> Pablo Neira Ayuso wrote:
>> I think that I have reproduced your problem in my testbed. Say you have
>> two nodes: A and B. Initially, A is primary and B is backup.
>>
>> 1) you generate tons of http traffic: A succesfully replicates states to B.
>> 2) you trigger the fail-over: B becomes primary and A becomes backup. B
>> successfully recovers the connections. Moreover, if you do `conntrack -L
>> -p tcp' in A, you see lots of entries.
>> 3) Just a bit later - 30 seconds later or so - you trigger the fail-over
>> again from B to A. In this case, A fails to recover the entries showing
>> tons of INVALID messages.
> 
> Well, not exactly. My problem occurs already in step 2.
> 
> Before starting the test, I stop conntrackd on both nodes, clear the
> connections from the table with 'conntrack -F' and start conntrackd
> again. Both nodes have empty connection tracking tables at this point in
> time. Then I start the HTTP traffic and trigger the fail-over.
> 
> I see the INVALID messages on the first fail-over, as soon as I have
> more than about 500 (with NAT) to 750 (without NAT) parallel TCP
> sessions, built up and teared down rapidly.

That's exactly the test that I do in my testbed and it works fine here,
the problem must be elsewhere. The following line should help to see how
the connection tracking is marking the traffic as invalid:

echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid

However, please see the comment below before doing this and repeating
the test.

> I'm not sure where the bottleneck is in this case. CPU of the nodes and
> bandwith of the "node interconnect" (dedicated interfaces) are not busy
> at all.

Are you using a sane stateful rule-set similar to the described in the
conntrack-tools website? What kernel version are you using? If your
kernel is < 2.6.22 you have to disabled TCP window tracking on both nodes.

echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

>> This problem is fixed in the git repository. Now, we purge the entries
>> in A once this node becomes backup after 15 seconds - this parameter is
>> tunable via PurgeTimeout. Thus, the old entries does not clash with the
>> brand new.
> 
> I compiled the current version from git. Unfortunately, it does not
> change the results for me.

There is a new script `primary-backup.sh' that replaces the old
script_master.sh and script_backup.sh. Although this is not directly
related it would be worth to use that instead as it will be the standard
in the upcoming release.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

  reply	other threads:[~2008-09-02  9:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-18  9:39 conntrack performance test results in INVALID packets Bernhard Bock
2008-07-18 10:13 ` Jan Engelhardt
2008-07-18 10:52   ` Bernhard Bock
2008-07-18 12:14     ` Pablo Neira Ayuso
2008-07-18 14:20       ` conntrackd failover works partially, was " Bernhard Bock
2008-07-21  0:37         ` Pablo Neira Ayuso
2008-07-21 14:22           ` conntrackd failover works partially Bernhard Bock
2008-07-23  8:51             ` Bernhard Bock
2008-07-23 12:50             ` Pablo Neira Ayuso
2008-07-23 15:20               ` Bernhard Bock
2008-08-08  8:47         ` conntrackd failover works partially, was Re: conntrack performance test results in INVALID packets Pablo Neira Ayuso
2008-08-08 12:58           ` Bernhard Bock
2008-09-02  9:39           ` Bernhard Bock
2008-09-02  9:56             ` Pablo Neira Ayuso [this message]
2008-09-02 12:34               ` Bernhard Bock
2008-09-02 12:48                 ` Pablo Neira Ayuso
2008-09-02 15:18                   ` Bernhard Bock
2008-09-02 16:22                     ` Pablo Neira Ayuso
2008-09-02 16:55                       ` Bernhard Bock
2008-09-03  9:13                         ` Pablo Neira Ayuso
2008-09-03 11:26                           ` Bernhard Bock
2008-09-04 12:29                             ` Pablo Neira Ayuso
2008-09-04 13:27                               ` Bernhard Bock
2008-09-05 10:55                                 ` Pablo Neira Ayuso
2008-09-04 11:40                 ` Pablo Neira Ayuso

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=48BD0DD6.9000803@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=mailinglists@bock.nu \
    --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.