[28798] in North American Network Operators' Group
RE: "Simple" Multi-Homing ? (was Re: CIDR Report)
daemon@ATHENA.MIT.EDU (Dmitri Krioukov)
Tue May 16 17:03:52 2000
From: "Dmitri Krioukov" <dima@dimension.net>
To: <nanog@merit.edu>, <chris.williams@third-rail.net>,
<woods@weird.com>
Cc: "Todd Sandor" <tsandor@home.com>
Date: Tue, 16 May 2000 17:15:15 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFGEGEEKAA.dima@dimension.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20000516202627.5A103E3@proven.weird.com>
Errors-To: owner-nanog-outgoing@merit.edu
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>
>
>
