Is your switch a single point of failure?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Is your switch a single point of failure?

Sam Vaughan
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

Reply | Threaded
Open this post in threaded view
|

Re: Is your switch a single point of failure?

Paul Suh-2
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]

Reply | Threaded
Open this post in threaded view
|

Re: Is your switch a single point of failure?

Stuart Henderson
In reply to this post by Sam Vaughan
On 2011-07-06, Sam Vaughan <[hidden email]> 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.