route filtering policies (from "split b" thread)

[Charles Winter]

Dani,

At present there are about 40,000 some-odd CIDR routes being propagated.
This takes just shy of 64meg. on a Cisco router - you can go to a publicly
available route server to check this out - so we all order border routers
with a minimum of 128 Meg. If no agriagation was done, it would be very easy
to exceed the maximum available memory a Cisco router can handle - at
present 256Meg. It does not take a lot of CPU to forward and receive route
updates.

EBGP - Exterior BGP (vs. IntereiorBGP) does not like to announce subnetted
/24 - thank goodness. Good policy is to aggrigate as much as possible, and
this is the force driving Router Arbiter Data Bases. To try to keep the
Internet from "flyingh apart" as one company put it.

A /20 is the smallest usuall allocation ARIN will make - there are a few
exceptions ...

Charles Winter
cwinter at communicationnation.com


----- Original Message -----
From: Hostmaster, Verant <hostmaster at verant.com>
To: 'Paul A Vixie' <vixie at mibh.net>
Cc: <arin-discuss at arin.net>
Sent: Monday, June 05, 2000 2:30 PM
Subject: RE: route filtering policies (from "split b" thread)


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