North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: "Simple" Multi-Homing ? (was Re: CIDR Report)

  • From: Dmitri Krioukov
  • Date: Tue May 16 17:05:44 2000

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.

> -----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]>