Date: Wed, 08 Sep 1999 12:48:45 -0400 From: Mitch Collinsworth <mkc@Graphics.Cornell.EDU> To: Chris Fedde <cfedde@fedde.littleton.co.us> Cc: "Mark Jones" <mjones@mco.net>, freebsd-questions@FreeBSD.ORG Subject: Re: multi-homed Message-ID: <199909081648.AA244489326@broccoli.graphics.cornell.edu> In-Reply-To: Your message of "Tue, 07 Sep 1999 16:49:20 MDT." <199909072249.QAA13309@fedde.littleton.co.us>
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? That's more or less how I understood his request. >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. Ok, this I didn't know and is why I phrased my initial response in the form of a question. To allow someone who knew for sure to either confirm or correct me. Thank you. Just out of curiosity, is there a source for a more definitive description of "most modern TCP clients"? >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. But if you bring both T1s into a single router you can eliminate the need for the internal routing protocol and static route everybody to the one router. (But which still doesn't eliminate the need for exterior routing with BGP.) >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. Still it's bound to avoid a lot of the far from optimal 'round-the-world' trips that will occur with random guess routing. >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. In other words, round-robin between entirely separate machines plugged into entirely separate power companies, not just multiple T1s to a single machine. Good thinking. And I would guess quite economically competitive with bringing T1s to your own location unless you have other reasons for needing them on site. -Mitch >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 th >e > >>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 order >s > >>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?199909081648.AA244489326>