From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Date: Fri, 09 Jan 2004 23:10:16 +0000 Subject: Re: [LARTC] High speed traffic filtering Message-Id: <3FFF34D8.8000507@trash.net> List-Id: References: <1073672927.23676.102.camel@tatooin.kelkoo.net> In-Reply-To: <1073672927.23676.102.camel@tatooin.kelkoo.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Vincent Jaussaud wrote: > Hi; >=20 > First, sorry if this question is mostly netfilter related, than lartc, > but I think you guys may have a your opinion about this. You should post this question to the netfilter-devel list, people there can give you very good advice. >=20 > I'm using Linux 2.4.x with netfilter packet filtering / NAT on our > front-end firewalls (P500 with 1Gb RAM), which are filtering traffic > going to our Public Web Sites. >=20 > The traffic is growing very fast since several months.. The average > traffic filtered by our firewalls, is around 30/40 Mbits/s, with peaks > around 70 Mbits/s sometimes, so that we had to switch to gigabit > technologies, to keep a good safe margin. >=20 > Our firewalls are not so high speed machines (P500 with 1Gb RAM), but > are doing good so far. >=20 > It seems, however, that we are reaching the limits, when approaching 70 > Mb/s... cpu utilization is then near 100%, and the machines start > dropping packets. >=20 > So, my question is, is netfilter able to handle, let's say gigabit > traffic filtering ? What kind of hardware would be necessary to handle > such traffic ? >=20 > Have you guys any experience with filtering such high speed traffic ? Netfilter sure is able to handle 1gbit, but it doesn't depend that much on the raw speed. The number of conntracks and simultaneos active connections matters much more. > I also thought of two possible solutions, to optimize our current > firewalls, on which you may have an opinion. >=20 > 1) Disabling statefull inspection, by unloading connection tracking > modules.=20 > I believe netfilter without connection tracking, might be much more > efficient (We don't need connection tracking actually, since we are only > filtering HTTP traffic from the others traffics at this point) That might help, although without stateful filtering the rules have to be evaluated for each single packet. > 2) Replace iptables by nf-hipac for packet filtering. Have you guys any > experience with nf-hipac ? (http://www.hipac.org/) nf-hipac is very good with a large number of rules, for just http filtering I suspect iptables will do equally good or better. >=20 > I would be really thanksfull to hear of any solutions / workarounds / > optimization to keep our linux firewalls handling growing traffic :-) Try without conntrack if you don't need it, otherwise start with increasing the hash table size and limit ip_conntrack_max to 2 times the hash size. There was a thread about optimizing iptables on netfilter-devel 1-2 month ago, it was started by Herv=E9 Eychenne, search the archives. Best regards, Patrick >=20 > Thanks ! > Vincent. >=20 > --- >=20 > Vincent Jaussaud > Kelkoo.com Security Manager=20 > email: tatooin@kelkoo.com >=20 > "Those who desire to give up freedom in order to gain security will not > have, nor do they deserve, either one." > -- President Thomas Jefferson. 1743-1826 >=20 >=20 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/