Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 07 Sep 1999 16:49:20 -0600
From:      Chris Fedde <cfedde@fedde.littleton.co.us>
To:        Mitch Collinsworth <mkc@Graphics.Cornell.EDU>
Cc:        "Mark Jones" <mjones@mco.net>, freebsd-questions@FreeBSD.ORG
Subject:   Re: multi-homed 
Message-ID:  <199909072249.QAA13309@fedde.littleton.co.us>
In-Reply-To: Your message of "Tue, 07 Sep 1999 13:47:14 EDT." <199909071747.AA232456435@broccoli.graphics.cornell.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
Let me see if I get the situation here.  You have a single server connected
to a lan with two links via T1 circuits to different back bone providers.
You are using DNS Round Robbin to load balance requests over the two links
into the host and the default router prefers one of the two T1s.
You have one service running on the host that binds addresses from each of
the T1 providers CIDR blocks.

Am I close enough?

DNS round robbin is good enough for this scenario.  Most modern
TCP clients follow the IETF recommendations and will try all addresses
listed in the DNS for a host before they give up.  So with one T1
down the client will wait only a short time before trying the other
host.  You must be using an A record round robbin to take advantage
of this.  CNAME round robbin configs are devil spawn.

When one of the T1's goes down then you have the caching behavior
of DNS to contend with anyway.  If the circuit will be down for
longer than your DNS TTL you might as well comment out the A record
for the failing circuit. That will eliminate half of the client delay.
Uncomment it again when things come back to normal.

If you really want to eliminate missed tries in this scenario then
you are talking about participating in backbone routing.  That is
not an action to take lightly.  The routers with the T1s must take
a full BGP4 route feed from their ISP's and the local network must
run a dynamic protocol such as OSPF to propagate route changes to
the clients.  Once you have this in place then the out bound packets
will take the "optimal" route back to the originating host.  

Unfortunately "optimal" has a strange definition here.  BGP routes
use "autonomous system hops" as their primary metric. For the most
part a whole ISP is one "autonomous system".  So while traceroute
may show that by hop count one path is better than another, BGP
will often show a different routing choice. 

Running backbone routing also means that you get to take part in all the
other interesting backbone internet events.  And all the administrative
load that entails.

If I were looking to optimize my uptime I'd settle for round
robbin, good administrative practice and place my production servers
in diverse colocation facilities.  But that is just my opinion.

chris

Mitch Collinsworth writes:
    
    Ok, but what about my 2nd question: about round-robin during a T1 outage?
    Have you thought about this?  Unless the round-robin feature is smart
    enough to detect the T1 outage and only give out the good address while
    the other one is down, you will still lose 50% of your hits.  Is this
    the elimination of downtime you were after?
    
    -Mitch
    
    
    >That would be great if they would take the fastest route. The main reason 
   we
    >want this is to help eliminate downtime if one t1 goes down.
    >-----Original Message-----
    >From: Mitch Collinsworth <mkc@Graphics.Cornell.EDU>
    >To: Mark Jones <mjones@mco.net>
    >Cc: freebsd-questions@FreeBSD.ORG <freebsd-questions@FreeBSD.ORG>
    >Date: September 7, 1999 1:08 PM
    >Subject: Re: multi-homed
    >
    >
    >>
    >>This is not the answer to the question you asked, but why wouldn't you
    >>want your packets to take the best/fastest/shortest path, rather than the
    >>one that came up heads this time even if it's much farther/slower than
    >>the other?  I don't know if you're aware but the difference can be orders
    >>of magnitude in some cases.
    >>
__
Chris Fedde	  <cfedde@fedde.littleton.co.us>
303 773 9134


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909072249.QAA13309>