Date: Wed, 19 Apr 2000 10:08:18 +0100 From: Tim Priebe <tim@polytechnic.edu.na> To: bill@bilver.com Cc: freebsd-isp@freebsd.org Subject: Re: Failover question/idea/hint Message-ID: <38FD7782.C9791923@polytechnic.edu.na> References: <200004190548.BAA01467@mail.wanlogistics.net>
next in thread | previous in thread | raw e-mail | index | archive | help
bill@bilver.com wrote: > Reply to: bill@bilver.com > X-Mailer: ELM [version 2.4ME+ PL61 (25)] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > I had said: > > > > An old client of mine is bringing up a portal site. They current have > > > a T1 to their location, but the site is going to be put on a server > > > at our co-location facility - which is inside an OC-48 connected facility. > > > > > > They are going to keep theri T1 and the current site as a development > > > site, but they want to be able to use that site as a fail-over site > > > in case the main site goes down. > > ... > > > I can't t see that the round-robin DNS approach would work, but if the > > > primary DNS (located at tha main site) goes down, would that be enough > > > to force it to the secondary name server - which I'm thinking could > > > point to the backup site. > > > One apporoch to automatic fail over is to bind the same ip address to the > > loopback interface of 2 or more systems, at different locations, and to route > > to them with a dynamic routing protocol. In your situation, it sounds like you > > would have to use a tunnel from the one site to the other. You would then have > > redundancy for server failure, but not if your network went down, unless you > > can have the tunnel implemented some distance from the co-location facility. > > Hm. I don't know if this is possible. We ( a friend and myself) are buidling > a 'virtual ISP' (I don't know how to actually describe it - but all our > equipment is inside a major transport facility where we have leased > rack space - and then we are locating customers sites/machines inside > our racks - makes sense because big-pipes have 0 mileage distance charges) > > The idea is a smallish (in comparison to the big guys) ISP with > focus only on commercial/industrial type service with people who > will respond to calls and keep things running. > > And what is 'distance' in this era? They are physically located about > 50 miles from here but a traceroute goes from Orlando to Dallas to > south Florida to East coast Florida. 10 hops at 70ms isn't too bad > in this day and age -particulary when you look at the average > delays seen at such places at internettrafficreport.com. > > The current plan is to have redundant servers in the next couple of > months if the site gets popular. Given the backbone connections > I'm more worried about server failure than network failure. > > I'm looking for any idea/directions at all. > > One other reply mentioned about having low times in the DNS so > things expire quickly - but that doesn't sound like a proper approach. > > One of these days I will understand this mess. Do you have any sort of router(s) between you and your "upstream", that are under your control? If so put the tunnel(s) on them. If not will your "upstream" accept dynamic routes from you? If so put 2 or more routers/FreeBSD boxes between thier routers and your clients box(es) (in parrallel for redundancy), add the tunnels from each back to the router or server at the client site, and configure your dynamic routing. If you can not do something like this, then you will have to use DNS. The basic idea of binding the same ip address to the loopback interface of different computers in different locations is used by some isp's to give a single address for proxy servers, no matter which pop you dial in to. If you use dynamic routing for failover in such a case, you just must be certain that you can never have any load balancing happening. Tim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38FD7782.C9791923>