Jon Carnes wrote:
On Sat, 2006-01-28 at 17:04, Aaron S. Joyner wrote:
You want something that allows you to have multiple paths to the
internet, and should one of those paths die, you want to switch to using
the alternate path. This is actually a very easy thing to do, and only
requires a second ethernet interface in the firewall in question (note
the word interface, not network card, as technically this could be done
with a managed switch, vlans, and some craziness if you want to keep
your existing hardware platform)
... detail snipped...
Come back and post again if you can't get it working correctly. :)
Good luck Greg,
Aaron S. Joyner
Hmmm, interesting but a bit complex. I prefer to simply have the
secondary take over the IP address of the primary - when the primary
goes down.
... detail snipped...
===
I like this because the Fail-over server does all the checking. It uses a
secondary network (192.168.10.0) that is shared with the Primary Firewall. All
testing is done across the secondary network. This lets you manipulate the
primary network (192.168.1.0) and move the gateway for that network anytime you
want, while still letting you test to see if the Primary Firewall comes back up.
It's elegant and it works great.
Good Luck - Jon Carnes
I don't disagree that your solution is elegant and effective, Jon. It
just solves a different problem. :) You're solving the problem of
firewall redundancy, and getting multiple internet paths as a sort of
bonus. In the scenario you describe, consider what happens if the
internet connection of the first server fails, but the internal
interface of the server is quite happy and responding to pings. This
isn't at all uncommon, for example when the ISP has issues, you have a
DSL modem die, there's a line cut outside your buliding and DSL or Cable
sync goes away, etc, etc. The failover test will not detect a failover,
and internet service for the internal network goes away, even though
there is a usable internet connection connected to the 'failover'
server. You could expand on your failover script by setting up a few
static routes on the failover server to route through the 192.168.10.1
IP address and ensure you can actually ping those remote IPs through the
first server, which would give you a better understanding of if the
actual "internet" connection is working. You'd also want to ensure that
the 'failover' ISP is working before you try and switch, or you'll end
up in a scenario where things constantly switch back and forth to no
effect, because neither ISP is functional. At this point, you will have
implemented the solution I suggested, minus a tiny bit of complexity
with iproute rules, because you used two seperate routing tables on two
seperate pieces of hardware, instead of two routing tables on one piece
of server. It also naturally requires throwing more hardware at the
problem, when in Greg's original case it sounds like he wants to keep
hardware to a minimum (fanless box, etc). I don't disagree that he
should consider the box as likely a point of failure as the internet
connection, though, so going in the over-all direction you describe is
still not a bad idea.
Aaron S. Joyner
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
