From: Jason Opperisano <opie@817west.com>
To: netfilter@lists.netfilter.org
Subject: Re: Iptables logs on High bandwidth traffic network
Date: Wed, 4 May 2005 12:39:48 -0400 [thread overview]
Message-ID: <20050504163948.GA19878@bender.817west.com> (raw)
In-Reply-To: <4278C3DE.7010403@au-kbc.org>
On Wed, May 04, 2005 at 06:15:18PM +0530, bharathi wrote:
> Hi all,
> I am planning to implement iptables log feature on a server
> machine(Dual xeon processor,Intel e100 cards,80GB SCSI and 2GB RAM)
> which is running in bridge mode (On RH 7.3).The average traffic on this
> machine is vary from 40-60Mbps.Hence I require some suggestion for some
> my questions like,
60Mpbs is not a ton of traffic, i'd be interested in what the expected
packets per second (pps) rate is, as that can be the
forwarding/filtering killer. in the extreme case, think about 60 Mbps
of 1250 byte UDP packets vs. 60 Mbps of 60-300 byte TCP traffic...big
difference.
i'd also be so bold as to suggest you'd be much better off with e1000
cards over e100 cards. in my experience, if you can get 80 Mbps
sustained out of a 100M card; you're kicking butt, and it's not
something you'd want to do indefinitely.
> 1) On this High traffic the kernel will be stable/crash ?
> 2) What would be the CPU Load and the server is able to do this job
> without any pain ?
it's possible that the NICs could peg the CPU servicing interrupts.
there are docs out there on how to nail a specific NIC to a specific
CPU, as you'll often see all your NICs being serviced by a single CPU.
i'd also note that in my experience, on both linux and the BSD's;
bridging is *much* more CPU intensive than routing; which is probably
counter-intuitive, since from a networking perspective bridging is a
simpler operation than routing. dunno if this has to do with
implementation issues or just that it's being done in software vs.
hardware.
> 3) Up to how much traffic the iptables/kernel can able to handle without
> any issue and what should I do additionally if I need the
> iptable-log should handle this much traffic?
if you want to do a lot of logging, add a 3rd NIC to the box; setup a
syslog server on that segment and let the syslog server deal with the
disk I/O.
-j
--
"Chris: So, what are you wearing? Wow. I bet you can see right through
that.
Lois: Chris, who are you talking to?
Chris: Grandma."
--Family Guy
next prev parent reply other threads:[~2005-05-04 16:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-04 12:45 Iptables logs on High bandwidth traffic network bharathi
2005-05-04 15:59 ` Taylor, Grant
2005-05-04 22:40 ` Mogens Valentin
2005-05-04 23:13 ` Taylor, Grant
2005-05-05 6:59 ` Jozsef Kadlecsik
2005-05-05 7:24 ` Taylor, Grant
2005-05-05 8:15 ` Jozsef Kadlecsik
2005-05-05 11:24 ` Mogens Valentin
2005-05-05 11:59 ` Jozsef Kadlecsik
2005-05-05 9:37 ` Mogens Valentin
2005-05-05 10:07 ` Jozsef Kadlecsik
2005-05-04 16:39 ` Jason Opperisano [this message]
2005-05-04 17:18 ` Steven M Campbell
2005-05-04 20:37 ` Jozsef Kadlecsik
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=20050504163948.GA19878@bender.817west.com \
--to=opie@817west.com \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox