[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiple T1's and debian router/firewall



On Mon, Nov 17, 2003 at 12:10:06PM -0600, William Sykes wrote:
> do you all know of a Linux solution that would allow me to multihome my
> office network for redundancy while maintaining www and mail presence?
> Some type of router/firewall with multiple WAN links.

Unless you want to go the whole hog and get and AS and play with the big
boys in the land of BGP, nothing except Linux can help you.  <g>

> For example I have 2 t1's(from different ISP's) and if one goes down I

It's that "from different ISPs" bit that makes it sooo much harder.  If
you had two from the same provider (but perhaps guaranteed diverse) you
could get them to help out with the shaping...

> Example 
> Provider 1 gives me 1.1.1.0/24 where DNS and mail for my domain is
> going.
> 
> Proveder 2 gives me 2.2.2.0/24

I presume that both of these address ranges are publically routable.

> Provider 1 goes down.
> 
> Some type of Router/Firewall open source device at the perimeter of my
> network identifies that the Provider1 link is failing and begins to
> forward in and outbound traffic down Providers pipes.

Metric fiddling will get you that.

> Question:
> If I have email and web services pointing to an ip on the Primary
> network, if that network fails and the secondary network takes over via
> some type of redundant Firewall/Device, how do I manage the DNS so that
> the redundant network will now answer to www and mail requests? 
> 
> Im mainly confused about the DNS stipulations.

Multiple DNS is the only way to fly in this situation, due to the inability
to get your "routing" changes published any other way.

Set up two DNS servers, with different zone files, listening on IP
addresses in both subnets.  Let's call your DNS server '20', and have it
listen on 1.1.1.20 and 2.2.2.20.

List those two addresses and associated hostnames as the DNS servers for
your domain.  People will (roughly) query those addresses randomly (which
also provides some measure of load balancing, for extra tastiness).

You setup the DNS servers so that any DNS requests that come in on 1.1.1.20
get answered with addresses in 1.1.1.0/24, and requests to 2.2.2.20 get
answered with 2.2.2.0/24.

Now, when one connection goes down, hopefully everyone will start getting
their answers from the "other" DNS server, which will give them addresses on
the still alive connection.

Problems with this include:

1) DNS caching.  You can set your TTL really low, but you'll chew
significant bandwidth and annoy people who care about those sorts of things.

2) Most resolvers that I've looked at only query one server at a time, so
for the ~50% of queries that get sent toward the dead server, they'll
timeout and annoy users.

3) After the dead link resurfaces, it'll take some time before the traffic
returns to symmetry (not exactly an earthshattering one, that one).

At any rate, that entire plan is what I'm looking at implementing as soon as
I get the go-ahead from TPTB at a gig I'm doing.

BTW: While you'll probably need to have two separate connections on the
firewall, all the other servers in the subnet can just have aliased
connections - unless you want to go hyper-redundant...

- Matt



Reply to: