[NANOG] Multihoming for small frys?
Andy Dills
andy at xecu.net
Wed May 21 04:05:05 UTC 2008
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
---
More information about the NANOG
mailing list