route filtering policies (from "split b" thread)
Pete Bowden
repete at cncx.com
Mon Jun 5 18:29:18 EDT 2000
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
More information about the ARIN-discuss
mailing list