I'll second damn near everything nate said, and hopefully add a tidbit or two.<br><br>If you're new to BSD, you may want to consider the pfsense project in the aforementioned active-active configuration.<br><br>It gives you a nice, intuitive gui to manage your failover firewalls, if you insist on putting a firewall in front of your web servers.<br>
<br>Better to secure the box, leave only the ports you need open on the public interfaces, and don't firewall them.<br><br>Also, I'd strongly consider running your firewalls with no disk at all.  A Live CD, CF card or USB Flash to boot off of, remote syslog and<br>
one less subsystem (disks) to buy/fail makes for some mighty cheap 1U servers.  A single dual-core with core speeds above 3.0Ghz<br>and 4GB of RAM is to pass Gb @ line rate - ethernet overhead.  Truth be told, it's already being done on much less<br>
than that.  You can also load balance your traffic, albiet somewhat primitively with it.  If you really want massive throughput, consider toying<br>around with extremely expensive 10G gear, size RAM appropriately, and see how PF performs under multi-processor, high-core speed.<br>
but if you're handling over a Gb of traffic and you can't split the application into multiple farms, that's the best move.  <br><br>Akamai, for instance, runs 10G to each rack, each rack has around 20-24 servers, and they run GB to the server.<br>
<br><a href="http://pfsense.org">pfsense.org</a> has extensive information about hardware requirements, features, and what you're looking to do.<br><br><a href="https://calomel.org/network_performance.html">https://calomel.org/network_performance.html</a> is an excellent BSD firewall performance site.<br>
<br>One thing to note, you are claiming to want to deploy this as a passive bridge.  You cannot do what you want to do<br>running anything in bridge mode.  The packets need to route somehow.  Get a /29 from your colo provider and ask<br>
to have your existing block routed through it once you've tested it.<br><br>Another option for a seamless failover, is to alias a different range of IP's to the server interfaces, put a /29 and whatever<br>netblock you want to end up being your public IP block on the PFSense hardware.  When you're convinced everything's<br>
working through rigorous testing, put a test domain up pointing to that block, modify virtualhost entries on the servers to<br>respond to that domain with your production web site, and test some more.  Once you're convinced that's working perfectly,<br>
make the changes in DNS to point your production domain at the IP's you want, and failover will happen with DNS convergence.<br><br>Peter<br><br><br><div class="gmail_quote">On Fri, Dec 18, 2009 at 9:06 AM, nate <span dir="ltr"><<a href="mailto:centos@linuxpowered.net">centos@linuxpowered.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">sadas sadas wrote:<br>
><br>
> Hi,<br>
>  I want to configure CentOS on powerful server with gigabit<br>
> adapters as transparent bridge and deploy it in front of server farm.<br>
> Can you tell how to optimize the OS for hight packet processing? What<br>
> configurations I need to do to achieve very hight speeds and thousands of<br>
>  packets?<br>
<br>
</div></div>iptables makes a TERRIBLE firewall, use pf instead<br>
<br>
<a href="http://www.openbsd.org/faq/pf/index.html" target="_blank">http://www.openbsd.org/faq/pf/index.html</a><br>
<br>
Also consider how your going to provide redundancy, if you have a web<br>
server farm you want to protect them with at least two firewalls, not<br>
one.<br>
<br>
<a href="http://www.openbsd.org/faq/pf/carp.html" target="_blank">http://www.openbsd.org/faq/pf/carp.html</a><br>
<br>
I haven't used CARP myself but did setup a pair of pf firewalls about<br>
5 years ago in a large network in bridging mode, the layer 3 fault<br>
tolerance was provided by OSPF on the core switches, the firewalls<br>
were active-active(with pfsync) since they were layer 2 only.<br>
<br>
Maybe someday linux will fix the overly complex iptables system to<br>
something that is more manageable, not holding my breath though.<br>
<br>
If you want really high speed(say multi GbE) though you'll want/need<br>
to go with an appliance based solution.<br>
<br>
Also since your referring to a web server farm, it is perfectly<br>
acceptable to not use firewalls these days, if you have a good<br>
load balancer that serves the same role as a firewall in that it<br>
only passes traffic that you specifically configure it to pass. Also<br>
in high traffic environments the performance of load balancers<br>
destroys most firewalls, making investing in a high end firewall<br>
a very expensive proposition.<br>
<br>
I've worked for the better part of the last 10 years with<br>
companies who did not have firewalls in front of their web servers<br>
for this reason, it didn't make sense $$ wise, because the benefit<br>
wasn't there, and the added complexity, and performance implications<br>
wasn't worth it either. Talk to most load balancing companies and<br>
they'll tell you this themselves.<br>
<font color="#888888"><br>
nate<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
CentOS mailing list<br>
<a href="mailto:CentOS@centos.org">CentOS@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos" target="_blank">http://lists.centos.org/mailman/listinfo/centos</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Peter Serwe<br><a href="http://truthlightway.blogspot.com/">http://truthlightway.blogspot.com/</a><br>