North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: "Simple" Multi-Homing ? (was Re: CIDR Report)
briefly speaking, there are two major solutions to the problem like this one, when the constantly increasing number of customers ask "please sell me x" (in our case, x is equal to multihoming of very small networks to two different isps) and you do not have x on-stock because you have y. the solutions are: 1) to tell the customers "you do not need x, you need y" (and yes, customers really need y, not x); 2) to work on getting x on-stock and to sell this x to customers. it is extremely obvious to me that in the free market environment the winners are those who use the second approach. -- dima. > -----Original Message----- > From: [email protected] [mailto:[email protected]]On Behalf Of > [email protected] > Sent: Tuesday, May 16, 2000 4:26 PM > To: North America Network Operators Group Mailing List > Cc: Todd Sandor > Subject: 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]> > >
|