Multihoming for small frys?

[William Herrin]

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?

Who should I talk to? Certain well-known companies seem incapable of
discussing service that isn't cookie-cutter.

Thanks,
Bill Herrin

[david raistrick]

Post by William Herrin
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

....that part isn't required. Generally any /24 will do in my
experience except for specific cases.

Other than that, you've got it about right.





---
david raistrick http://www.netmeister.org/news/learn2quote.html
***@icantclick.org http://www.expita.com/nomime.html

[Holmes,David A]

If the same /24 is announced from 2 different sites, the problem we have
run into is that using the longest prefix method is the only way to
guarantee that some ISPs will not use some method such as private
peering to cause asymmetric routing back to the small fry.

-----Original Message-----
From: david raistrick [mailto:***@icantclick.org]
Sent: Tuesday, May 20, 2008 12:32 PM
To: William Herrin
Cc: ***@nanog.org
Subject: Re: [NANOG] Multihoming for small frys?

Post by William Herrin
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

....that part isn't required. Generally any /24 will do in my
experience except for specific cases.

Other than that, you've got it about right.





---
david raistrick http://www.netmeister.org/news/learn2quote.html
***@icantclick.org http://www.expita.com/nomime.html

[Andy Dills]

Post by William Herrin
Hi folks,
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
---

[Tony Varriale]

AFAIK, ARIN doesn't give out /22s anymore.

Last time I went to the well...it's was a /20 or better.

tv
----- Original Message -----
From: "Andy Dills" <***@xecu.net>
To: "William Herrin" <herrin-***@dirtside.com>
Cc: <***@nanog.org>
Sent: Tuesday, May 20, 2008 11:05 PM
Subject: Re: [NANOG] Multihoming for small frys?

Post by Andy Dills

Post by William Herrin
Hi folks,
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
http://mailman.nanog.org/mailman/listinfo/nanog

[Nathan Ward]

Post by Tony Varriale
AFAIK, ARIN doesn't give out /22s anymore.
Last time I went to the well...it's was a /20 or better.

Interesting..

I've had /24s for customers before, with APNIC's multi-homing
assignments.

http://www.apnic.net/info/faq/multihoming_faq.html

<snip>
There is no absolute maximum or minimum assignment size, but please
note that APNIC cannot guarantee the routability of any assignment it
makes. Assignments less than /24 are not practical and will generally
be filtered. If you are close to meeting the minimum allocation size (/
21), you may find it more economical to become an APNIC member and
apply for a portable allocation using the APNIC IPv4 ISP request form.
</snip>

Note that you must be the end user of the space, as it is assigned not
allocated.

--
Nathan Ward

[Andy Dills]

Post by Tony Varriale
AFAIK, ARIN doesn't give out /22s anymore.
Last time I went to the well...it's was a /20 or better.

Nah, it's /22 for multi-homed networks, /20 for single-homed.


http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html

4.3.2.2 Multihomed Connection
For end-users who demonstrate an intent to announce the requested space in
a multihomed fashion, the minimum block of IP address space assigned is a
/22. If assignments smaller than a /22 are needed, multihomed end-users
should contact their upstream providers. When prefixes are assigned which
are longer than /20, they will be from a block reserved for that purpose.




Are there really networks who can justify a /20 that aren't multi-homed?
The mind boggles.

Andy

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

[Tony Varriale]

Thanks for the info. We needed larger than /22 anyways.

I am a bit surprised that they will hand out a small allocaiton for
multihomers. These days it's very easy to do. And, could be a easy way to
horde some v4.

Notice the caveats:

To qualify under the IPv4 Multi-homing policy, your organization must prove
an intent to multi-home, demonstrate utilization for at least a /23-worth of
IP addresses assigned by upstream providers, and provide 3-, 6-, and
12-month utilization projections.

In addition, your organization must agree to use the requested IPv4 address
space to renumber out of your current address space, and to return the
original address space to your upstream provider(s) once the renumbering is
complete. Additional space will not be allocated until this is completed.
Organizations that qualify under this policy may also qualify and request
space under ARIN's general IPv4 allocation policy.

Of course, this could be smoke and mirrors. Not sure.

tv

----- Original Message -----
From: "Andy Dills" <***@xecu.net>
To: "Tony Varriale" <***@comcast.net>
Cc: <***@nanog.org>
Sent: Wednesday, May 21, 2008 1:53 AM
Subject: Re: [NANOG] Multihoming for small frys?

Post by Andy Dills

Post by Tony Varriale
AFAIK, ARIN doesn't give out /22s anymore.
Last time I went to the well...it's was a /20 or better.

Nah, it's /22 for multi-homed networks, /20 for single-homed.
http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html
4.3.2.2 Multihomed Connection
For end-users who demonstrate an intent to announce the requested space in
a multihomed fashion, the minimum block of IP address space assigned is a
/22. If assignments smaller than a /22 are needed, multihomed end-users
should contact their upstream providers. When prefixes are assigned which
are longer than /20, they will be from a block reserved for that purpose.
Are there really networks who can justify a /20 that aren't multi-homed?
The mind boggles.
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

[Deepak Jain]

Can we all agree that while renumbering sucks, a /24 (or less) is a
pretty low-pain thing to renumber (vs. say, renumbering a /20 or shorter
prefix?) In an ideal world, you never have to renumber because your
allocations were perfect from the get-go.

We've all been to the other, more realistic place, no?

While we all feel pain for folks who have to do renumbers, even if EVERY
single host in there is a MAJOR dns server (which is my personal worst
case) for MAJOR sites, even *that* has become much easier to address
than it used to be.

This is probably rhetorical, but I feel like some threshold of
materiality should be roughly described so Operators don't get whipsawed
over variable length renumbers longer than a certain length.


DJ

[David Coulson]

Post by Deepak Jain
Can we all agree that while renumbering sucks, a /24 (or less) is a
pretty low-pain thing to renumber (vs. say, renumbering a /20 or
shorter prefix?) In an ideal world, you never have to renumber because
your allocations were perfect from the get-go.

Depends - If you're an Enterprise where 90% of the equipment is managed
by people who work in the same building, it's not horrible. I renumbered
a bunch of /20s onto a /18 where 75% of the equipment was not in my (or
the company's) control. That sucked big time.

David

[Jack Bates]

Post by David Coulson
Depends - If you're an Enterprise where 90% of the equipment is managed
by people who work in the same building, it's not horrible. I renumbered
a bunch of /20s onto a /18 where 75% of the equipment was not in my (or
the company's) control. That sucked big time.

I had the same issue. Add to that recursive DNS servers and the support issues
of everything that depends on them in and not in your direct control. While
mostly taken care of within a year, I've seen small side effects of the renumber
over 5 years later. Small things that work under normal conditions but still
have mention of the old IPs which cause problems when rare conditions occur (ie,
outages under specific circumstances).

Jack Bates

[David Coulson]

Post by Jack Bates
I had the same issue. Add to that recursive DNS servers and the
support issues of everything that depends on them in and not in your
direct control.

Indeed. I recall Proxy ARP and a lot of NAT was involved :) At least you
can keep track of the people who didn't update their configs, even
though they said they did.

David

[Deepak Jain]

Post by David Coulson

Post by Deepak Jain
Can we all agree that while renumbering sucks, a /24 (or less) is a
pretty low-pain thing to renumber (vs. say, renumbering a /20 or
shorter prefix?) In an ideal world, you never have to renumber because
your allocations were perfect from the get-go.

Depends - If you're an Enterprise where 90% of the equipment is managed
by people who work in the same building, it's not horrible. I renumbered
a bunch of /20s onto a /18 where 75% of the equipment was not in my (or
the company's) control. That sucked big time.

Right, but a /20 is a /lot/ more space than a /24. I think I'd say that
shorter than a /21 is certainly a decent threshold of pain (personally).
Even if its all in-house.

There are ways to make it less painful and special painless cases (an
all NAT space), but as a shot-in-the-dark, that's a pretty good bet [you
almost certainly have a decent mix of network and server gear, different
authorities, different topologies, etc]

DJ

[McMasters, Jeremy]

I worked for an ISP that was bought by another ISP and had to assign all
new IP's roughly a /16 worth. Good times. Only one ASN thank goodness

-----Original Message-----
From: Deepak Jain [mailto:***@ai.net]
Sent: Wednesday, May 21, 2008 4:09 PM
To: nanog list
Subject: Re: Renumbering, was: [NANOG] Multihoming for small frys?


Can we all agree that while renumbering sucks, a /24 (or less) is a
pretty low-pain thing to renumber (vs. say, renumbering a /20 or shorter

prefix?) In an ideal world, you never have to renumber because your
allocations were perfect from the get-go.

We've all been to the other, more realistic place, no?

While we all feel pain for folks who have to do renumbers, even if EVERY

single host in there is a MAJOR dns server (which is my personal worst
case) for MAJOR sites, even *that* has become much easier to address
than it used to be.

This is probably rhetorical, but I feel like some threshold of
materiality should be roughly described so Operators don't get whipsawed

over variable length renumbers longer than a certain length.


DJ

[Pete Templin]

Post by Tony Varriale
Thanks for the info. We needed larger than /22 anyways.
I am a bit surprised that they will hand out a small allocaiton for
multihomers. These days it's very easy to do. And, could be a easy way
to horde some v4.

Nope, you can horde a /24 for a single device, but it's
provider-assigned. If you can't justify a /23 -now-, you don't qualify
for an ARIN multihomers' /22.

pt

[Robert E. Seastrom]

It's always been possible to get resources by lying or committing
fraud - the common law crime of obtaining property by false pretenses
predates the Internet by a substantial margin.

---rob

Yup. You can horde.
You can easily justify a /23 these days and not be multihomed still
get a /22.
tv
----- Original Message -----
Sent: Wednesday, May 21, 2008 3:32 PM
Subject: Re: [NANOG] Multihoming for small frys?

Post by Pete Templin

Post by Tony Varriale
Thanks for the info. We needed larger than /22 anyways.
I am a bit surprised that they will hand out a small allocaiton for
multihomers. These days it's very easy to do. And, could be a
easy way to horde some v4.

Nope, you can horde a /24 for a single device, but it's
provider-assigned. If you can't justify a /23 -now-, you don't
qualify for an ARIN multihomers' /22.
pt

[Tony Varriale]

Yup. You can horde.

You can easily justify a /23 these days and not be multihomed still get a
/22.

tv
----- Original Message -----
From: "Pete Templin" <***@templin.org>
To: "Tony Varriale" <***@comcast.net>
Cc: <***@nanog.org>
Sent: Wednesday, May 21, 2008 3:32 PM
Subject: Re: [NANOG] Multihoming for small frys?

Post by Tony Varriale
Thanks for the info. We needed larger than /22 anyways.
I am a bit surprised that they will hand out a small allocaiton for
multihomers. These days it's very easy to do. And, could be a easy way
to horde some v4.

Nope, you can horde a /24 for a single device, but it's provider-assigned.
If you can't justify a /23 -now-, you don't qualify for an ARIN
multihomers' /22.
pt

[William Mullaney]

I got a /22 in January, and was told by someone from ARIN that the
policy below only applied to allocations to ISP's, not to assignments
for end customers. At the time, they said an end user must show at
least 25% immediate usage (so a /24) and that there was no requirement
for future usage. In my experience, if you can show you have some
semblance of ability, two real peers, and an existing and established
business, you should be able to get the request through easily in about
a week, start to finish. When you're ready, fill out the request form,
the worst that can happen is they reject you or defer you until you can
provide more info. If you have questions for/about ARIN, call them
(number is on the website) and talk to one of their people, they've been
pretty knowledgeable, friendly, and helpful in my experience.

-Will

-----Original Message-----
From: Tony Varriale [mailto:***@comcast.net]
Sent: Wednesday, May 21, 2008 3:03 PM
To: Andy Dills
Cc: ***@nanog.org
Subject: Re: [NANOG] Multihoming for small frys?

Thanks for the info. We needed larger than /22 anyways.

I am a bit surprised that they will hand out a small allocaiton for
multihomers. These days it's very easy to do. And, could be a easy way
to
horde some v4.

Notice the caveats:

To qualify under the IPv4 Multi-homing policy, your organization must
prove
an intent to multi-home, demonstrate utilization for at least a
/23-worth of
IP addresses assigned by upstream providers, and provide 3-, 6-, and
12-month utilization projections.

In addition, your organization must agree to use the requested IPv4
address
space to renumber out of your current address space, and to return the
original address space to your upstream provider(s) once the renumbering
is
complete. Additional space will not be allocated until this is
completed.
Organizations that qualify under this policy may also qualify and
request
space under ARIN's general IPv4 allocation policy.

Of course, this could be smoke and mirrors. Not sure.

tv

----- Original Message -----
From: "Andy Dills" <***@xecu.net>
To: "Tony Varriale" <***@comcast.net>
Cc: <***@nanog.org>
Sent: Wednesday, May 21, 2008 1:53 AM
Subject: Re: [NANOG] Multihoming for small frys?

Post by Andy Dills

Post by Tony Varriale
AFAIK, ARIN doesn't give out /22s anymore.
Last time I went to the well...it's was a /20 or better.

Nah, it's /22 for multi-homed networks, /20 for single-homed.
http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html
4.3.2.2 Multihomed Connection
For end-users who demonstrate an intent to announce the requested space in
a multihomed fashion, the minimum block of IP address space assigned is a
/22. If assignments smaller than a /22 are needed, multihomed

end-users

Post by Andy Dills
should contact their upstream providers. When prefixes are assigned which
are longer than /20, they will be from a block reserved for that purpose.
Are there really networks who can justify a /20 that aren't

multi-homed?

Post by Andy Dills
The mind boggles.
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

[rar]

I have tried everything I can think of to get good technical support
from Hughesnet. I sent a Fed Ex package outlining a problem to the
President. Never heard a word. The people in India where a nightmare.
I worked with one of their sales reps and no satisfaction.

If you find anyone who can help with technical issues, and they are
willing to help another soon to be ex-customer with an issue in Haiti,
let me know.

Bob Roswell
System Source
***@syssrc.com
[phone] ext 4336



-----Original Message-----
From: Joe Blanchard [mailto:***@uplogon.com]
Sent: Thursday, May 22, 2008 10:38 AM
To: ***@nanog.org
Subject: Hughes Network



Pardon the request,

Is their anyone on the NANOG list from Hughesnet? I'm facing an
issue with reverse DNS (RFC1912) that
is difficult at best to resolve in India. ;)
Please contact me off list.

Regards,
Joe Blanchard

[Jason J. W. Williams]

Has anyone else noticed that the [NANOG] prefix has been missing
intermittently from the list traffic over the last couple of days?

-J
---
Jason J. W. Williams
COO/CTO, DigiTar
http://www.digitar.com

E: ***@digitar.com
V: 208-343-8520
M: 208-863-0727
F: 208-322-8520
XMPP: ***@digitar.com

-----Original Message-----
From: rar [mailto:***@syssrc.com]
Sent: Thursday, May 22, 2008 10:04 AM
To: Joe Blanchard; ***@nanog.org
Subject: RE: Hughes Network

I have tried everything I can think of to get good technical support
from Hughesnet. I sent a Fed Ex package outlining a problem to the
President. Never heard a word. The people in India where a nightmare.
I worked with one of their sales reps and no satisfaction.

If you find anyone who can help with technical issues, and they are
willing to help another soon to be ex-customer with an issue in Haiti,
let me know.

Bob Roswell
System Source
***@syssrc.com
[phone] ext 4336



-----Original Message-----
From: Joe Blanchard [mailto:***@uplogon.com]
Sent: Thursday, May 22, 2008 10:38 AM
To: ***@nanog.org
Subject: Hughes Network



Pardon the request,

Is their anyone on the NANOG list from Hughesnet? I'm facing an
issue with reverse DNS (RFC1912) that
is difficult at best to resolve in India. ;)
Please contact me off list.

Regards,
Joe Blanchard


!SIG:48359a1571591351813437!

[Michael Holstein]

Post by Jason J. W. Williams
Has anyone else noticed that the [NANOG] prefix has been missing
intermittently from the list traffic over the last couple of days?

Different SMTP servers, it appears (looks like they might have been
using an Ironport box to do anti-spam, and it was probably doing the
subject re-writes as well)

With the [NANOG] in subject :

received: from linuxbox.org ([24.155.83.21])
by thor.merit.edu with ESMTP; 20 May 2008 10:27:41 -0400

Without the subject tag :

Received: from nameserver2.ttec.com ([64.95.32.37] helo=smtp.ttec.com)
by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD))
(envelope-from <***@ttec.com>) id 1JzEFp-0006tP-1S
for ***@nanog.org; Thu, 22 May 2008 17:07:01 +0000


Cheers,

Michael Holstein
Cleveland State University

[david raistrick]

Post by Tony Varriale
AFAIK, ARIN doesn't give out /22s anymore.

It's a recent change in the past couple of years.

Still current:

"However, for multi-homed organizations, the minimum allocation size is a
/22"


http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html


Now, if you're not multihomed you still have the /20 as the longest
prefix.


---
david raistrick http://www.netmeister.org/news/learn2quote.html
***@icantclick.org http://www.expita.com/nomime.html

[Owen DeLong]

For multihomed, /22 is still the rule.

Owen DeLong
ARIN AC

I got a /22 from ARIN last year; ASN 36516. Is the /20 only rule
relatively new?
Not multi-homed yet because my 2nd provider does not support it yet.
Best Regards,
Edward Ray
-----Original Message-----
Sent: Tuesday, May 20, 2008 9:32 PM
To: Andy Dills
Subject: Re: [NANOG] Multihoming for small frys?
AFAIK, ARIN doesn't give out /22s anymore.
Last time I went to the well...it's was a /20 or better.
tv
----- Original Message -----
Sent: Tuesday, May 20, 2008 11:05 PM
Subject: Re: [NANOG] Multihoming for small frys?

Post by Andy Dills

Post by William Herrin
Hi folks,
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
http://mailman.nanog.org/mailman/listinfo/nanog

_______________________________________________
NANOG mailing list
http://mailman.nanog.org/mailman/listinfo/nanog
--
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.com
--
This mail was scanned by BitDefender
For more informations please visit http://www.bitdefender.co

[Joe Warren-Meeks]

Post by Owen DeLong
For multihomed, /22 is still the rule.

Over here in RIPE-land, I just got a /23 for AS44947, announced as two
/24's. Seems to work fine.

-- joe.

[Heather Schiller]

Post by William Herrin
Hi folks,
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.

Yes, but the order is wrong..

- Order service from 2 providers
- Request an ASN from ARIN, show them your documentation that you are
getting service from 2 providers to justify your need for an ASN
- If you don't meet the utilization requirements for getting a /24,
request a /24 for multihoming under ARIN 4.2.3.6. from ONE of your
providers (not both).

At UUnet/VZB we ask customers to provide their ASN as documentation that
they have demonstrated their intent to multihome.

If you have existing IP space, and it's less than /24 don't be surprised
if someone asks you to renumber. If you have existing IP space /24 or
larger, don't be surprised if someone turns you down under the
multihoming policy.


http://www.arin.net/policy/nrpm.html#four236

4.2.3.6. Reassignments to multihomed downstream customers

Under normal circumstances an ISP is required to determine the prefix
size of their reassignment to a downstream customer according to the
guidelines set forth in RFC 2050. Specifically, a downstream customer
justifies their reassignment by demonstrating they have an immediate
requirement for 25% of the IP addresses being assigned, and that they
have a plan to utilize 50% of their assignment within one year of its
receipt. This policy allows a downstream customer's multihoming
requirement to serve as justification for a /24 reassignment from their
upstream ISP, regardless of host requirements. Downstream customers must
provide contact information for all of their upstream providers to the
ISP from whom they are requesting a /24. The ISP will then verify the
customer's multihoming requirement and may assign the customer a /24,
based on this policy. Customers may receive a /24 from only one of their
upstream providers under this policy without providing additional
justification. ISPs may demonstrate they have made an assignment to a
downstream customer under this policy by supplying ARIN with the
information they collected from the customer, as described above, or by
identifying the AS number of the customer. This information may be
requested by ARIN staff when reviewing an ISP's utilization during their
request for additional IP addresses space.

Post by William Herrin
Is that still the way to make it happen? Are there alternate
approaches (besides DNS games) that I should consider?
Who should I talk to? Certain well-known companies seem incapable of
discussing service that isn't cookie-cutter.

It's really pretty straightforward and common actually... but I wouldn't
be surprised if sales folks don't know ARIN and/or routing policy.

Post by William Herrin
Thanks,
Bill Herrin

[Sean Figgins]

Post by William Herrin
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.

Now, I have a question about this... Is the customer using the sites
for redundancy, and will have both upstream providers in each site?

Honestly, a small operation like this may be better served by multiple
connections to the same provider. Such a setup can usually be done to
multiple routers, through redundant circuit paths, and done at
substantially less cost that two different providers. And, in my
experience, using one provider can often be more reliable than multiple
providers, given how many providers transport facilities ride the same
fiber path, and sometimes the same bundle.

-Sean

[Seth Mattinen]

Post by Sean Figgins
Now, I have a question about this... Is the customer using the sites
for redundancy, and will have both upstream providers in each site?
Honestly, a small operation like this may be better served by multiple
connections to the same provider. Such a setup can usually be done to
multiple routers, through redundant circuit paths, and done at
substantially less cost that two different providers. And, in my
experience, using one provider can often be more reliable than multiple
providers, given how many providers transport facilities ride the same
fiber path, and sometimes the same bundle.

I have to disagree...

About two years ago, maybe less, Sprint was doing some maintenance in
California and was moving stuff through an alternate path in Arizona.
However, while the CA path was off, someone took a backhoe to the AZ
path. Neither the planned outage, the cut, nor myself were in the same
state (I'm in Nevada). It didn't matter how many circuits I had with
Sprint, because none of them worked, including my Sprint cell phone.
However, I was still on the air because my other providers were unaffected.

Locally, yeah, the path in the ground are probably the same. But beyond
that, it can matter, and I strongly recommend multihoming if the story
above is something their organization would like to be protected from.

~Seth

[Sean Figgins]

Post by Seth Mattinen
About two years ago, maybe less, Sprint was doing some maintenance in
California and was moving stuff through an alternate path in Arizona.
However, while the CA path was off, someone took a backhoe to the AZ
path. Neither the planned outage, the cut, nor myself were in the same
state (I'm in Nevada). It didn't matter how many circuits I had with
Sprint, because none of them worked, including my Sprint cell phone.
However, I was still on the air because my other providers were unaffected.

I've been in a situation before where circuits with two different
providers were both taken out by the same fiber cut. These were large
long-haul circuits.

I've had another situation where two circuits out of Charlotte, NC ended
up in the same bundle in Virginia, even though they were one was going
to Atlanta, and another was headed to DC, through two different
providers. One provider bought the bundle from someone, and leased part
of it to another company, who sublet it to another company, that
provided service to the the carrier that provided us the service.
Kicker was that I think it was originally our fiber.

Of course, these are circuits, not internet traffic. With todays' large
networks, it's really hard to completely isolate any given city. Oh
sure, it can happen, and some cities are unpopular, and don't hardly
qualify for IP service, so diversity is hard to justify, but most cities
have at least two, if not three or more paths out.

-Sean