Smallest netblock that providers will accept?
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
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 On Mon, Aug 18, 2008 at 9:32 PM, Mike Lyon <mike.lyon@gmail.com> wrote:
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
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. On 8/18/08, Mike Lyon <mike.lyon@gmail.com> wrote:
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
-- Sent from Gmail for mobile | mobile.google.com
On Mon, Aug 18, 2008 at 10:05 PM, Kevin Blackham <blackham@gmail.com> wrote:
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.
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
On Tue, Aug 19, 2008 at 1:26 AM, Anton Kapela <tkapela@gmail.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (5)
-
Anton Kapela -
Christian Koch -
Kevin Blackham -
Mike Lyon -
William Herrin