From: Chris Wilson <chris@netservers.co.uk>
To: Peteris Krumins <newsgroups@lf.lv>
Cc: Netfilter <netfilter@lists.netfilter.org>
Subject: Re[2]: Interesting problems
Date: Wed, 6 Aug 2003 11:03:51 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.44.0308061053420.21531-100000@localhost> (raw)
In-Reply-To: <16160478015.20030805225428@lf.lv>
Hi Peteris,
> 266 isnt that slow, that's only connection tracking, is it (too slow)?
For 20000 connections, I'd say it was too slow.
> Most of the entries taking up conntrack table are:
> tcp 6 419547 ESTABLISHED src=X dst=Y sport=A dport=B [UNREPLIED] src=Y
> dst=X sport=B dport=A use=1 mark=0
>
> They would expire only after 419547 secs that is 4 days, but during those 4
> days the table grows 5 times that much entries..
>
> Is there some trick to kill UNREPLIED tcp conntrack entires if there
> is no reply after NN seconds.
In theory they should be killed automatically to make room for real
(ESTABLISHED) connections. So you may be able to reduce the size of the
conntrack table without impacting user experience, and make your system
run faster that way.
You could also try the patch that Daniel Chemko suggested,
> Also could it be done in software w/o much trouble? Monitoring
> conntrack table and removing dead entries like these.
> If it's not much trouble i can instruct our programmers instantly to
> work on such tool.
I believe that Harald is working on nfnetlink/ctnetlink which will allow
you to do this, but I think it's still experimental.
> I can instruct our programmers (I am the team leader) to do some work
> on iptables connection tracking code and after improvments i could
> send it as a patch for current iptables. So connection tracking would
> be as efficient as possible. I just need someone to tell me exactly
> what is inefficient in conntrack code.
Sorry, I'm really not the best person to ask about that, but Harald and
Rusty have some profiling and optimisations on their TODO lists which they
might be willing to hand off to your team.
Cheers, Chris.
--
___ __ _
/ __// / ,__(_)_ | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |
next prev parent reply other threads:[~2003-08-06 10:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-04 20:41 Interesting problems Peteris Krumins
2003-08-05 9:38 ` Chris Wilson
2003-08-05 10:34 ` tsh
2003-08-05 11:00 ` Chris Wilson
2003-08-05 19:54 ` Re[2]: " Peteris Krumins
2003-08-06 10:03 ` Chris Wilson [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-08-05 20:09 Daniel Chemko
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=Pine.LNX.4.44.0308061053420.21531-100000@localhost \
--to=chris@netservers.co.uk \
--cc=netfilter@lists.netfilter.org \
--cc=newsgroups@lf.lv \
/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