From owner-freebsd-questions Tue Sep 7 15:51:16 1999 Delivered-To: freebsd-questions@freebsd.org Received: from fedde.littleton.co.us (fedde.littleton.co.us [207.204.248.149]) by hub.freebsd.org (Postfix) with ESMTP id 3FF1114D67 for ; Tue, 7 Sep 1999 15:51:09 -0700 (PDT) (envelope-from cfedde@fedde.littleton.co.us) Received: from fedde.littleton.co.us (localhost.fedde.littleton.co.us [127.0.0.1]) by fedde.littleton.co.us (8.9.3/8.9.3) with ESMTP id QAA13309; Tue, 7 Sep 1999 16:49:20 -0600 (MDT) Message-Id: <199909072249.QAA13309@fedde.littleton.co.us> To: Mitch Collinsworth Cc: "Mark Jones" , freebsd-questions@FreeBSD.ORG From: Chris Fedde Subject: Re: multi-homed In-reply-to: Your message of "Tue, 07 Sep 1999 13:47:14 EDT." <199909071747.AA232456435@broccoli.graphics.cornell.edu> Date: Tue, 07 Sep 1999 16:49:20 -0600 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 >To: Mark Jones >Cc: 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 303 773 9134 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message