routing table size

Off your network, your legal rights are pretty limited. I (and I'm sure
lots of other admins) block at the /24 boundry. Anything you announce
from /25 to /32 will be ignored on my network. Some providers choose to
block according to RIR allocation sizes. To me, that's not worth the
maintenance hassle. To them, it may mean the difference between having to
upgrade or replace large numbers of routers last year or sometime in the
next few years.

I've never suggested accepting /25's thru /32's. I'm wondering if the
people saying I should not de-aggregage my /20 actually practice what they
preach and filter /24's and don't globally announce /24's from their
customers.

-Ralph

I've never suggested accepting /25's thru /32's. I'm wondering if the
people saying I should not de-aggregage my /20 actually practice what they
preach and filter /24's and don't globally announce /24's from their
customers.

-Ralph

  What's wrong with announcing routes from your customers? Even /32s if you
want. Only those people who choose to accept them will be affected by them
and anyone who you have a BGP session with can insist you filter them out.
Treating different situations as if they were the same is not practicing what
you preach.

  DS

I've a feeling that the fact that everyone shares at least the view that a /24
is minimum helps to contain the routing table. (even if there are still
thousands of /24 announcements)

If a significant number of providers starting accepting any prefix then the
others would need to follow (else they'd get no transit traffic as it will
always prefer the most specific). This really would lead to route explosion!

I guess the counter argument is that you'd still get the same number of
announcements at longer prefixes as there are only lots of /24s as its the
current shortest (if you catch my drift here). But I doubt it is quite that
straight forward and there would be a growth in announcements..

Steve

My point is simply that only those who felt the /32s were worth carrying
would carry them. And those who chose to announce them would have to factor
the effects of selective carrying into their decisions. But nobody would be
imposing any unwanted costs on anyone else.

  That's the difference. Nothing you can possibly do with a customer can
impose unwanted costs on you or the customer. If you don't want the costs,
don't do it. If the customer won't pay you the cost of doing it, don't do it.
it's only in the relationship between ISPs and non-customers that there's a
pollution and inequitable cost distribution issue.

  Practicing what you preach does not require treating fundamentally different
situations as the same.

  DS

>I've a feeling that the fact that everyone shares at least the view that a
>/24
>is minimum helps to contain the routing table. (even if there are still
>thousands of /24 announcements)
>
>If a significant number of providers starting accepting any prefix then the
>others would need to follow (else they'd get no transit traffic as it will
>always prefer the most specific). This really would lead to route explosion!
>
>I guess the counter argument is that you'd still get the same number of
>announcements at longer prefixes as there are only lots of /24s as its the
>current shortest (if you catch my drift here). But I doubt it is quite that
>straight forward and there would be a growth in announcements..
>
>Steve

  My point is simply that only those who felt the /32s were worth carrying
would carry them. And those who chose to announce them would have to factor
the effects of selective carrying into their decisions. But nobody would be
imposing any unwanted costs on anyone else.

Yes, you said that before and my above comments still apply!

  That's the difference. Nothing you can possibly do with a customer can
impose unwanted costs on you or the customer. If you don't want the costs,
don't do it. If the customer won't pay you the cost of doing it, don't do it.
it's only in the relationship between ISPs and non-customers that there's a
pollution and inequitable cost distribution issue.

But it costs me nothing to accept my customers announcements.... ?

  Practicing what you preach does not require treating fundamentally different
situations as the same.

How is it different? The cash (customer) bit isnt relevant.. its how many
providers allow it which is.

Steve

the large quantity of /24 announcements is, I suspect, from comapnies just
large enough to want the benefits of multihoming. You know, 2 t1s on a
small router, and stuff like that..

  Bri

Everyone and their mother says they "suspect" that, but noone ever proves
it. Ever wonder why?

Let's take it by the numbers:
Total ASes present in the Internet Routing Table: 13448
Origin-only ASes present in the Internet Routing Table: 11641
Origin ASes announcing only one prefix: 5154
Transit ASes present in the Internet Routing Table: 1807

Even if every origin-only AS was a smalltime company with just enough IPs
for a /24, it would take around 6-7 /24s each to account for the number of
/24s announced.

If someone has done an actual study of where these /24s (and probably /23s
too) come from, please point it out. Until then, my money is on clueless
redist connected/statics, large cable/dsl providers who announce a /24 per
pop/city/whatever to their single transit provider, and general ignorance.

Why attribute to functionality what can easily be explained by
incomptence. :slight_smile:

To ease my own curiousity I kludged together a script to look at how
much of /24 land is taken up by smalltimers announcing few prefixes, and
larger networks announcing many. My last snapshot of the routing table is
from the end of june, so may be (very slightly) outdated.

Data from June 29, 2002

Total /24's: 61931
ASN's announcing /24's: 8645

Number of /24's announced by AS breakdown

/24's ASN Count
======= =========
1 3474
2 1662
3 740
4 533
5 377
6 236
7 203
8 164
9 113
10-14 421
15-19 184
20-29 199
30-39 101
40-49 57
50-59 41
60-69 29
70-79 21
80-89 12
90-99 11
100-149 20
150-199 17
200+ 29

Those "basement multihomers" announcing 1-5 /24's only account for ~20% of
the total number of /24's out there. Multihomers with slightly larger
basements (6-10 /24's) account for 10% of the total. That leaves the
remaining 70% of /24's in the DFZ announced by people pushing out over 10
/24's from their AS. Interpret however you will (I tend to lean
towards Richard's take on the situation.)

- Paul

Until then, my money is
on clueless
redist connected/statics, large cable/dsl providers who
announce a /24 per
pop/city/whatever to their single transit provider, and
general ignorance.

Why attribute to functionality what can easily be explained by
incomptence. :slight_smile:

--
Richard A Steenbergen <ras@e-gerbil.net>

You forgot one of my favorite frustrations - slow start.

Try this:

a) start an ISP and tell your upstream you want a /21. They will tell
you that you can only have a /24.

b) Tell them that you understand they can't give you a /21 based on ARIN
guidelines but you would like them to reserve it for you. Listen to
them laugh.

c) Keep requesting more space as you need it while you grow. Tell them
you want contiguous space. Listen to them laugh. Your choice is take a
new discontinuous block or renumber the whole network.

This would be why we announce 2 /22's and 2 /23's even though given
contiguous space we could make a single announcement.

Add in the $2500 cost of obtaining a ARIN allocation versus what are
'free' addresses from our upstreams and we will probably continue as-is
for a while. Why does ARIN need $2500 for an entry in a database
anyway?

End result is we would like to make a single announcement. By being
truthful in requesting address space based on the guidelines we end up
with address space that is fragmented - so we make the extra
announcements.

I have not seen a statistic for non-transit AS's announcing multiple
discontinuous prefixes - I suspect that there are a lot of them for the
same reason we do it.

Obviously you can't keep leaving big 'reserved' holes in your
allocations to downstreams for potential growth. You can't expect a
network to renumber everytime they need more space.

I don't have a good answer to this problem nor do I expect one - it's
just another reason why we have additional growth in the routing tables.

Mark Radabaugh
Amplex
(419) 833-3635

Now the question is, of that 70% figure, how much of that is
aggregateable?

--Phil

The slow-start scenario is valid, but only to a certain extent. My
company was a "slow-start" company, requesting and validating to
Management, ARIN, ISPs, and the guy working at the Quickie Mart. And
although we've managed to get to the point of a /19 at a time, we still
have a couple legacy /24s. What is one to do? Now, one network, one
contiguous AS, has 15 network advertisements ranging from /24 to /18
when it could be one /15 with another year or two to grow. But we can't
just pop off /15s to everyone who's promises to use it up, and I'm
certainly not going to persuade thousands of customers to migrate their
IPs to a new block.

But why I say it is only valid to a certain extent is that you only have
to "validate" a certain percentage of your existing IPs, that affords
larger companies to have more flexibility and thus get away from adding
/24s rather quickly.

Does someone have some perl script handy that can aggregate from a
hashlist dumped from router bgp output using NET::NETMASK?

(I'd do it myself, but ...well, I suk!)

JNULL PGP: 0x54B1A25C

"There are 10 types of people:
those that understand binary,
and those that do not.

I've seen RIPE allocate /20s under the proviso that the customer use
the first /23 now and apply to use the rest of the space as they grow.