Is your switch a single point of failure?
I'm currently looking at growing my simple co-located setup of a single OpenBSD web server to add a separate firewall and a second web server. This would make regular upgrades much less stressful and add some welcome high availability and capacity improvements. I'm considering running dual OpenBSD firewalls on e.g. ALIX.2d3 boards with CARP and pfsync. My question relates to linking the firewalls to the servers via switches in a sensible way. I should be able to avoid the need for a switch on the upstream side by getting the ISP to provide me with two links from the rack router, one for each firewall board. These links would be CARP'd to share one external static IP. The second ethernet port on each board would be linked to the other board in the pair for pfsync. My question relates to the third port on each board, making up the CARP'd internal interface on the DMZ side. How can I avoid plugging these two ports straight into the same switch, thereby adding a really obvious single point of failure to the entire setup? I can see a couple of options but I'm thinking I must be missing something obvious. 1. Rather than CARPing the interfaces on the DMZ side, they could simply be treated as two separate gateways. Each would connect to its own switch and the servers on the inside would select between them as per RFC816. I'm not even sure this would work because if a switch failed, the firewalls would have to somehow transfer master/slave status to match. 2. Set up a couple of RSTP switches and somehow connect the CARP'd internal interface to both of them. Connect the web servers to both switches and configure just the one gateway on them. I can find heaps of good information on CARP but the described setups always show just one switch in the DMZ. Do people really just accept that single point of failure? Regards, Sam
Re: Is your switch a single point of failure?
Sam, On Jul 6, 2011, at 3:31 AM, Sam Vaughan wrote: I should be able to avoid the need for a switch on the upstream side by getting the ISP to provide me with two links from the rack router, one for each firewall board. These links would be CARP'd to share one external static IP. I'd be really careful about this. The rack router may not expect to see the same IP address move between ports, and act funny if it does. Most CARP/pfsync setups put a switch in between the upstream router and the two boxes for this reason. Check with your service provider -- they may just be giving you two drops to a switch, in which case you have other single points of failure in your system already. My question relates to the third port on each board, making up the CARP'd internal interface on the DMZ side. How can I avoid plugging these two ports straight into the same switch, thereby adding a really obvious single point of failure to the entire setup? While you can use a pair of switches to do switch-level failover, it gets *expensive*. Nortel has the SMLT, DSMLT, and RSMLT protocols. Cisco has something sort of similar with their Virtual Switching System technology. http://en.wikipedia.org/wiki/Split_Multi-Link_Trunking Given the relatively high reliability of switches as well as the costs involved, most people don't bother. Of course, if you have the kind of budget that will support things like this... :-) Hope this helps. --Paul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Is your switch a single point of failure?
On 2011-07-06, Sam Vaughan samjvaug...@gmail.com wrote: I should be able to avoid the need for a switch on the upstream side by getting the ISP to provide me with two links from the rack router, one for each firewall board. These links would be CARP'd to share one external static IP. For carp to work these two interfaces need to be able to see each other (L2). On separate router interfaces (rather than switchports) this won't be the case. This is probably the side you need to think about more.. My question relates to the third port on each board, making up the CARP'd internal interface on the DMZ side. How can I avoid plugging these two ports straight into the same switch, thereby adding a really obvious single point of failure to the entire setup? I can see a couple of options but I'm thinking I must be missing something obvious. Simplest way is probably: one firewall to one switch, one to a second switch, crossconnect the switches, connect servers to both switches with a failover trunk.
