Smallest netblock that providers will accept?

Mailman List Mirror (Read Only)
1

Hello All,

I am curious as to the routing polices of the bigger providers such as
ATT, L3, Internap, Qwest, Etc Etc... Is there a standard size
netblock that these providers will accept? For instance, if customer
"A" gets a /22 from ARIN and his upstream provider is ATT and L3, what
would the smallest block be that those providers would accept from
customer "A"? Would they accept something as small as a /24?

Thanks,
Mike

2

a lot of providers have their bgp/routing policy published somewhere
online/in their community guide

for instance, you can find L3's policy in their irr objects ( whois -h
whois.radb.net as3356)

there are also plenty of community guides available here -
http://www.onesc.net/communities/

Christian

3

Your assumption is generally true with most any provider. They may
even accept something smaller, but it won't make it very far if less
than /24. It's also a good idea to announce a covering prefix in case
some peer network filters on IRR minimums.

4

The part that Kevin spares you from reading is the "please don't"
part. If your goal is to provide HA or DR-like aspects to some
$single_application end-site and all you can justify is a one-time
allocation of a /24, consider other options. There are already enough
/24's in the DFZ both from end-site multihomers and wreckless
deaggregation (and those who refuse to build a backbone and/or insist
that POP-level convergence towards their network is everyone elses
problem, not theirs).

Instead of going down this road, I would suggest that you:

-call up cisco and purchase a GSS (global dns lb with application
availability probes, etc)

or

-attach your site to a pair of willing upstreams who already have a
larger prefix aggregate set aside (say a /18 or something) for
end-site multihoming, in which it is expected that the prefix will be
originated from disparate AS's (neither of which is the actual
end-site).

-Tk

5

The part that Kevin spares you from reading is the "please don't"
part. [...] Instead of going down this road, I would suggest that you:

-call up cisco and purchase a GSS (global dns lb with application
availability probes, etc)

Anton,

By the time many folks consider redundant network links for
reliability they've already made design decisions which preclude this
path. My employer is in such a situation. They'd pay the $8k or so
annual systemic cost of a prefix if only there was someone they could
pay. But there isn't and even if we could afford the manpower to alter
our system to rely exclusively on DNS, our customers and the other
vendors involved have long since built systems that expect to
reference ours by IP address.

-attach your site to a pair of willing upstreams who already have a
larger prefix aggregate set aside (say a /18 or something) for
end-site multihoming, in which it is expected that the prefix will be
originated from disparate AS's (neither of which is the actual
end-site).

Does someone offer such a service? Who?

Regards,
Bill Herrin