[NANOG] Multihoming for small frys?

Mailman List Mirror (Read Only)
1

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

2

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

3

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.

4

The /24 address block has to be portable, an assignment, or the owner needs
to grant the secondary advertiser an LOA to readvertise that block. The LOA
is pretty common, but some ISPs may require you to renumber to get into
address space they will permit you to use and multihome. As always your
mileage may vary.

Robert D. Scott Robert@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services 352-392-2061 CNS Receptionist
University of Florida 352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL 32611

5

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

6

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

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

tv

7

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.

8

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

9

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.

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.

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.

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.

10

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

11

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.

12

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

13

For multihomed, /22 is still the rule.

Owen DeLong
ARIN AC

14

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

15

Deepak Jain wrote:

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

16

William Herrin wrote:

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

17

David Coulson wrote:

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

18

Tony Varriale wrote:

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

19

David Coulson wrote:

Deepak Jain wrote:

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

20

Jack Bates wrote:

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 :slight_smile: At least you can keep track of the people who didn't update their configs, even though they said they did.

David