From: Bernhard Bock <mailinglists@bock.nu>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter@vger.kernel.org
Subject: Re: conntrackd failover works partially
Date: Mon, 21 Jul 2008 16:22:54 +0200 [thread overview]
Message-ID: <48849BBE.5060403@bock.nu> (raw)
In-Reply-To: <4883DA4D.4080906@netfilter.org>
Pablo,
Pablo Neira Ayuso wrote:
> As you're using the Alarm mode, the time required to resynchronize the
> backup and the master is RefreshTime (which is 15 seconds in your config
> files). Are you probably triggering the fail-over before that amount of
> time?
No, I always waited longer. My keepalived has a pre-emption delay of
30sec before becoming master, and I always did wait at least a minute or
so before triggering a failback.
> Basically, you must to find the same
> set of flows in the master's internal-cache and the backup's
> external-cache if everything goes fine.
That's exactly what I can observe. They are consistent when the failover
goes fine, and they're not when I have INVALID packets.
I also see 'conntrack -E' working with 100 parallel TCP connections, and
dying with "Operation failed: No buffer space available" with 1000
connections. Maybe this is related?
As written in my last mail, I increased the SocketBufferSize to 256M and
the SocketBufferSizemaxGrown to 1024M in conntrackd.conf.
> Until we reach conntrack-tools-1.0, which I expect to reach soon since
> most of the pending work is already done, I suggest you to upgrade to
> lastest (as for now, it is 0.9.7). This release includes important
> improvements, fixes and features. The alarm mode is a bit spamming, I
> also suggest you to give a try to the ft-fw and the notrack approaches.
Let me give you a short update after upgrading:
I upgraded to conntrack-tools 0.9.7, libnflink 0.0.39 and
libnetfilter_conntrack 0.0.96. Basically, I took already available
Fedora 10 source RPMs and compiled them for Fedora 9.
Without failover, it seems to work at the first glance. In 'conntrackd
-s' I see plausible numbers of entries in internal and external caches.
Unfortunately, it still breaks on many failovers with 1000 parallel TCP
connections.
Now I get a lot of the following entries in syslog in addition to the
INVALID packets:
conntrack-tools[21319]: cache_wt crt-upd: Invalid argument
conntrack-tools[21319]: cache_wt update:Invalid argument
After a failed failover, I have to flush the connection table and
stop/restart both conntrackd processes in order to make it work again.
In FT-FW mode, the failover always fails, and it produces log entries like:
conntrack-tools[25448]: The other node says HELLO
conntrack-tools[25448]: sending bulk update
--- failover here ---
conntrack-tools[25515]: committing external cache
conntrack-tools[25515]: commit: Invalid or incomplete multibyte or wide
character
conntrack-tools[25448]: cache_wt update:Invalid or incomplete multibyte
or wide character
conntrack-tools[25515]: Committed 28224 new entries
conntrack-tools[25515]: 8 entries can't be committed
conntrack-tools[25448]: resync with master table
conntrack-tools[25448]: cache_wt update:Timer expired
conntrack-tools[25448]: cache_wt update:Timer expired
I haven't tried the notrack mode yet.
best regards
Bernhard
next prev parent reply other threads:[~2008-07-21 14:22 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 ` Bernhard Bock [this message]
2008-07-23 8:51 ` conntrackd failover works partially 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
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=48849BBE.5060403@bock.nu \
--to=mailinglists@bock.nu \
--cc=netfilter@vger.kernel.org \
--cc=pablo@netfilter.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.