|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: "Simple" Multi-Homing ? (was Re: CIDR Report)
[ On Monday, May 16, 1988 at 14:49:16 (-0400), Chris Williams wrote: ] > Subject: Re: "Simple" Multi-Homing ? (was Re: CIDR Report) > > Most SLAs I've seen, at least for smaller customers, are of the type "if > we're down for a day, you get a free week", which means in general your > maximum remedy for an outage is the cost of a T1 for a month. I think it > is pretty plausible that a company which only needed a T1 of bandwidth > could lose a lot more than $1500 worth of business if they were down for > a day or two. An SLA is like any other contract between two parties. If one of them doesn't negotiate what they really need but still signs off then who's to blame? If you really are in a position to loose a lot of hard cash business, but not enough to justify a more reliable setup, then perhaps you shouldn't be asking your ISP to be your insurance company too, but rather go to a real insurance company for such services instead. > All three were examples of miscommunication causing someone at the > provider to intentionally suspend or terminate service. It would hardly > matter how many links you had to the provider when they chose to shut > you down. Actually it would probably make a big difference. It could also make a big difference as to how quickly you would be able to get back up and running too. In any case all of the problems you've outlined are also greatly reduced if you forge a good business and working relationship with your provider. It's a lot less likely for a business "partner" to do nasty things to you, even by accident, if you do a bit more than just plug into their router and pay them anonymously every month or whatever. > I would hope that most reasonable providers would _not_ cut off a > customer immediately if they were found to be a source of misbehavior, > but first ask them politely to fix the problem (with the exception, of > course, of immediately blocking any traffic that was actively > interfering with someone else's operation). If you have discovered a way > to make a machine guaranteed and perfectly secure, I might reconsider > this position. ;P Like I said you do active and very regular testing. If you can't catch an open relay on your own servers before the spammers do (or a smurf amplifier) then something's not working right in your operations department! > Although I agree that this is a possible solution, I think at some point > it would become awefully hard to manage -- also, it only addresses a > subset of the situations requiring multihoming. It's one hell of a lot easier to "manage" physical multi-homing than it is to spoof the requirements necessary to have portable address space and an ASN! ;-) > Do you know of any software to help implement this type of solution? I > can imagine how to script up the default-route swapping pretty easily on > a Unix box, but AFAIK it would likely require a reboot under NT, and I'm > not sure how you would go about automating it even then.. I don't do NT and don't cater to those who do! ;-) > Maybe a good way to go about it would be to set up a box to do reverse > NAT for incoming connections to either set of server IPs, and then > round-robin between IP spaces for outgoing connections? I think this > could be set up with IPF under *BSD/Linux, I'm not familiar enough with > NAT under IOS to know how hard it would be to do with a Cisco router.. > This would have the advantage of simplifying the server configurations, > and there should really be something in the way of a firewall/filter in > front of them anyhow. Yes a carefully configured, multi-homed, NAT on your network's "edge" could do all of the redundancy tricks too.... (I don't know enough of the Cisco IOS NAT either to know if it could do this, but I'd bet it can for at least basic scenarios where only a few "well known services" are multi-homed.) The only problem with NAT is that you have to be DAMN careful about how you handle the non-TCP packets too otherwise all kinds of error-handling goes out the window and you may as well not have any redundancy in the first place (eg. if you send ICMP host-unreachable replies when one of the servers is down but they have an RFC-1918 source address and are filtered out before they can make it to the client, well...). Personally I'd just run both networks over the same "wire" (but with totally separate routers) and put interface aliases on all the necessary machines. Except for the redundant connection itself I already do this on my home network! ;-) Of course you could also set up completely twinned servers (perhaps with a private administrative LAN between them on the inside) and thus enjoy the benefits of physical redundancy all the way to the core. However if you do this then why not put one set of servers in SF and the other in NY and be truly dual-homed!?!?!? -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|