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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of woods@weird.com 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 <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>