Re: [NANOG] Multihoming for small frys?

[Andy Dills <andy () xecu net>]

On Tue, 20 May 2008, William Herrin wrote:

> Hi folks,
>
> An administrative question about multihoming:
>
> I have a client who needs to multihome with multiple vendors for
> reliability purposes, currently in the Northern Virginia area and
> later on with a fail-over site, probably in Hawaii. They have only a
> very modest need for bandwidth and addresses (think: T1's and a few
> dozen servers) but they have to have BGP multihoming and can afford to
> pay for it.
>
> The last I heard, the way to make this happen was: Find a service
> provider with IP blocks available in ARIN's set of /8's that permit
> /24 announcements (networks 199, 204-207), buy a circuit and request a
> /24 for multihoming. Then buy circuits from other providers using that
> ISP's /24 and an AS# from ARIN.
>
> Is that still the way to make it happen? Are there alternate
> approaches (besides DNS games) that I should consider?

They should just get their own /22 from ARIN.

If the future fail-over site doesn't help them show a /23's worth of 
justification, break out the ultimate fudge factor: SSL.

Yes, I know, some would argue this isn't responsible usage of community 
resources. 

However, if I was representing the interests of a company whose existence 
relies on working connectivity, my biggest concern would be provider 
independance. Altruism is something I encourage my competitors to indulge 
in. In fact, the increasing value and decreasing pool of prefixes should 
motivate any proper capitalist to air on the side of being greedy: just as 
they aren't making any more land, they aren't making any more IP(v4) 
space. 

My gut instinct has been telling me for half a decade that prefixes will 
get commoditized long before IPv6 settles in, and if I was representing 
the interests of a company who was in the situation you describe, I would 
certainly want to prepare for that possibility.

ARIN really should allow direct allocation of /24s to multi-homed 
organizations. It wouldn't increase the table size, and it would reduce 
the wasteful (best common) practice I describe above.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

_______________________________________________
NANOG mailing list
NANOG () nanog org
http://mailman.nanog.org/mailman/listinfo/nanog