From: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
To: hbchen <hbchen@lanl.gov>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: Some questions about using heavy iptables rules in a Linux box ....
Date: Tue, 09 May 2006 19:14:09 -0400 [thread overview]
Message-ID: <1147216449.2848.44.camel@localhost> (raw)
In-Reply-To: <4460B502.4080903@lanl.gov>
On Tue, 2006-05-09 at 09:28 -0600, hbchen wrote:
> Hi,
> I have some questions about using heavy iptables rules in a Linux box.
> 1. Has anyone done a comparison of latency and throughput on traffic
> through an
> Linux node with and without IPtables (using lots of filtering rules)?
> 2. How much CPU time is spending on iptables (heavy filtering rules)?
> 3. Any significant impact (latency and throughput) on 10G ethernet link?
<snip>
I cannot help you much with measurements but I can relate some
production experiences we have had using the ISCS network security
management project with iptables to implement intra-perimeter security.
In these cases, we needed to deal with massive rule sets (>150,000
rules). As a result, we are successfully running this installation on
low end, off-the-shelf iptables appliances from CyberGuard (SG series).
Obviously, these are not handling 10Gbps traffic streams!
The ISCS (http://iscs.sourceforge.net) paradigm uses standard iptables
in a slightly different way to reduce the overhead associated with very
large rule sets such as those needed for interior security. We still
answer the question who has access to what but evaluate who separately
from what. The result is a modular rather than monolithic rule set.
Instead of needing a separate rule for every possible combination of who
and what, we need a single rule for each who and a single rule for each
what and then mix and match them.
In this particular installation, the 150,000 monolithic rules were
reduced to about 13,000 modular rules. I suppose we could do much
better if we implemented ipset. Not only that, but the traversal of the
rules is effectively indexed by "who" thus dramatically improving
performance. And the entire rule set took only a few hours to
automatically create and distribute using ISCS.
Hopefully, you can use a similar approach to reduce the load and
increase processing efficiency in your environment - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com
Financially sustainable open source development
http://www.opensourcedevel.com
next prev parent reply other threads:[~2006-05-09 23:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-09 15:28 Some questions about using heavy iptables rules in a Linux box hbchen
2006-05-09 23:14 ` John A. Sullivan III [this message]
2006-05-09 23:59 ` Carl-Daniel Hailfinger
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=1147216449.2848.44.camel@localhost \
--to=jsullivan@opensourcedevel.com \
--cc=hbchen@lanl.gov \
--cc=netfilter-devel@lists.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.