Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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: Greg A. Woods
  • Date: Tue May 16 14:06:01 2000

[ On Tuesday, May 16, 2000 at 12:09:16 (-0400), Chris Williams wrote: ]
> Subject: Re: "Simple" Multi-Homing ? (was Re: CIDR Report)
>
> Although I agree that co-locating is probably the right solution in this
> There is a whole class of human-error and miscommunication problems
> which can cause an interruption of service from one provider, regardless
> of how technically redundant your links to that provider are. Examples
> I've directly experienced in the past year:
>   -- The provider finds a cancellation for an old circuit floating
> around in their DB, and confusing it with your current service, shuts
> down your connection (I had this happen with a prominent tier-1 provider
> -- these kinds of mistakes are not just made by small no-name ISPs)
>   -- The provider sends your bill to the wrong address, and so your
> accounting dept doesn't pay it, and they suspend your service.

Those are examples of contingencies that should be covered in your
service level agreement.  The SLA should hold the provider responsible
for any loss of income, recovery costs, or whatever, should they be the
ones to screw up.  Assuming you trust the provider to honour the SLA
you've worked out with them then your level of risk is mitigated even if
it's not done exactly in the way you might prefer under ideal
circumstances -- we are talking about (hopefully exceptional) events
here, after all!  If you don't trust your provider to honour their
agreements then I'd humbly suggest you find one you can trust!  ;-)

All but the last are also examples where basic link-level redundancy
will help to avoid total outages.  You don't need an ASN and full BGP
route peering just to remain connected when your T1 goes down!  Please
let's solve the right problem here!

>   -- A box on your network is cracked and used to send SPAM. The
> providers shuts you down for spamming without warning, or with warnings
> sent to the wrong address.

If such action is specified in your contract then you've accepted that
risk and you should mitigate it appropriately (eg. by regularly testing
and securing your servers!).  I'd hope that if you did have redundant
routing then your other provider would also cut you off for the same
reason and at approximately the same time!

> In any case, it seems to me we've veered significantly from the original
> topic. I thought we had pretty well established that "there are some
> legitimate needs for multihomed /24s" -- the question brought to the
> list was really "will my /24 work if I multihome it?", not "please tell
> me I don't know what I want".

I'm not entirely sure I agree yet.  There are lots of excuses flying
around, but few real reasons.  Sure you can concoct fake requirements
until they add up to this being the only alternative but I don't think
they'll weigh out in the long run.

I think there's another alternative that's being missed here too that'll
satisfy the majority of needs of quite a few people, if not most.  It
should be trivial to obtain only the minimum necessary address space
from both providers and truly multi-home the servers requiring
redundancy!  For outgoing connections you simply flip the default route
on each server as necessary (perhaps using automated tools) and for
incoming connections you just put multiple A RRs in your DNS for each
service requiring redundancy.  Load balancing opportunities spring to
mind here too!

I.e. please let's solve the right problem!

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





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.