route filtering policies (from "split b" thread)
Pete Bowden
repete at cncx.com
Mon Jun 5 18:29:18 EDT 2000
- Previous message: route filtering policies (from "split b" thread)
- Next message: route filtering policies (from "split b" thread)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Not speaking on behalf of my company or any policies which may or may not exist :-) -- just to give a background on how some companies view traffic and why some providers choose to filter at the largest block size. This gets into the argument of peer vs. provider. Most peering relationships between larger ISP's require that each peer in the relationship advertise the SAME announcement everywhere where they peer. Additionally, peering relationships usually have requirements for a minimum number of locations at the public exchanges, or alternatively direct connections between the providers. "Peers" are also at times (by some providers) expected to have a sizeable number of announcements (comparable to between the 'peers'). There may be policies which restrict who some providers might concider to be peers based on the similar traffic volumes, similar number of prefixes, and the difference between the traffic flow in each direction. If you don't have a backbone sufficient to carry your own traffic and only announce regionally then some larger providers will concider that not to be a peer relationship--"why should I have to pay to carry your traffic on my backbone or purchased transit pipes" is what one might hear. Larger providers, especially, have different policies for customers than they do with peers, and pay close attention to their definition of peer. The logic is that people should always be announcing/anchoring their LARGE agregate block somewhere in case the more specifics are not accepted -- this allows them to not have to carry what they concider to be your traffic across their backbone -- even though it may be their customers which are trying to reach your server. If you don't announce your large agregates then you are risking the connectivity of parts of your network from others in the global internet. > > Our situation is that we are multihomed to a few providors at each location, > but not necessarily with a backbone-grade link between each physical > location. We do not resell connectivity, but use it all for our own > Internet application serving. > > So it's not really that irresponsible, in that we cannot just take blocks > from our providers. I know of providers that accept as small as /24s, and I > know of networks that announce /23s and /24s and have no aggregate to fall > back on. In fact in the case I described, we were able to affect a change, > which was prohibiting many cablemodem customers from accessing not only us, > but the network of a large ISP. > > But perhaps you can shed some light on the question asked by another on this > thread - why exactly would you filter on anything shorter than a /24? RAM > on your routers? CPU? On my network, I want to pick up as specific routes > (well, up to /24) as the other network wants to announce to me - chances are > I'll get a better connection using a more specific prefix. > > Follow up question - where do you come up with /20 as the magic length for > class A's and B's, but /24 for class C's? > > Additionally, ARIN is now handing out 64.0.0.0/8 in smaller blocks. Perhaps > someone on this list can speak to the smallest block being handed out in > 64.0.0.0/8. > > ---- > Dani Roisman > Verant Interactive > hostmaster at verant.com > (310) 840-8753 > > > > -----Original Message----- > > From: Paul A Vixie [SMTP:vixie at mibh.net] > > Sent: Monday, June 05, 00 2:04 PM > > To: Hostmaster, Verant > > Cc: 'arin-discuss at arin.net'; Network Operations > > Subject: Re: route filtering policies (from "split b" thread) > > > > > Thanks for the URL... hm.. /20 and shorter only in 64/8? That's a bit > > > strict, no? We have different networks off our 64.34.128/18 block, > > which we > > > would like to announce in /21 and /22 blocks. There's a good chance we > > > won't aggregate, since the networks might each have OC3 or OC12 links to > > the > > > Internet, but in some places as slow as T1 between the two networks, and > > I > > > wouldn't want to backhaul accross the T1. > > > > that's an incredibly irresponsible way to build a net. if you're going to > > be a transit aggregator, then by all means get small blocks your providers > > and pay them extra to get cutouts. the expectation we all have when you > > get > > an address block is that you intend to advertise it, not carve it up. > > > > > Who should I contact at Verio to discuss losening the filtering policy? > > > > won't help. see http://www.mibh.net/mibh-peering.html and know that if > > you > > tried to get us to loosen it we would definitely not. there are dozens if > > not hundreds of nets running with this policy. the thing to change is > > your > > plan, not the commonly implemented route filtering policy of the whole > > 'net.. > -- Pete Bowden, Internet Network Engineer, Internet & Data Center Engineering rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010
- Previous message: route filtering policies (from "split b" thread)
- Next message: route filtering policies (from "split b" thread)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the ARIN-discuss mailing list