North American Network Operators Group
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: /24s run amuck
- From: Steve Francis
- Date: Tue Jan 13 14:20:45 2004
Stephen J. Wilcox wrote:
Deaggregation is at an all time high, I have raised this publically in some
forums and IXP ops lists. Response is poor, action is non-existent.
The only way I can see to do anything about this is for upstreams to educate
their customers and others to pressure their peers.
I'll take some education - given two POP's, different upstream ISPs at
each POP, and a desire to have traffic for specific networks (/24) enter
a specific POP, can that be done without de-aggregation?
We are not doing this ourselves - we're not yet big enough to have our
own aggregate blocks, but if we did, we could not just announce a /20 at
each POP, and transit the traffic back to the appropriate datacenter
ourselves. We're an ASP, and do not have real links between POP's, only
VPN's.
If we used consistent upstreams at each POP, we could do it by
announcing specific /24's with no-export communities, but a consistent
set of ISPs are not available at each of the colo's we are in.
Is there some other trick I'm missing?
Two primary reasons are given, one is for traffic engineering purposes to either
control the ingress of traffic or to allow a network to function with critical
links down and the other is to allow blocks to be dropped to mitigate the
effects of a DDoS, I dont believe either justify the deaggregation of large
aggregates into Nx/24s and that a large driver is to make your network look
larger than it is...
Steve
On Sat, 10 Jan 2004, Richard A Steenbergen wrote:
Ok, I realized I haven't done one of these since 2001, so it's time for an
updated list of /24 polluters. With /24s accounting for over 50% (more
than 71k) of the announcements on the Internet, it seems reasonable to try
and take a look at why there are so many.
One of the patterns which quickly becomes evident is the announcing of
"almost all" of a larger block, but with enough gaps that traditional
scripts which look for CIDR aggregation can miss it. For example, someone
who owns a /16 and announces it as 250 /24s might not show up in other
CIDR aggregation scripts because of the missing 5 /24s, or if 1 of the
/24s has a different AS Path.
So, solely for the purpose of looking for this pattern, I have written a
script which counts the number of /24s announced within a /16 (an
admittedly arbitrary range, but one which happens to work) with a
consistant AS Path, and sorts by the highest count. This of course doesn't
mean for certain that the netblock listed doesn't have a good reason for
their deaggregation, but odds are they don't or could otherwise take steps
to limit announcement to the general internet (for example a cable modem
provider with 250 individual routes /24s but only a single upstream
provider, who could announce a /16 globally and use no-export on the more
specifics).
This is done from the point of view of a Global Crossing (AS3549) transit
feed, so things may look slightly different fromy our corner of the
Internet. You have been warned.
A summary of the top 250 netblocks by count:
http://www.e-gerbil.net/ras/projects/ipaddr/24summary
Detailed list of the netblocks and AS Path by count:
http://www.e-gerbil.net/ras/projects/ipaddr/24dump
A sorted list of the origin ASs contributing the /24s in the above lists:
http://www.e-gerbil.net/ras/projects/ipaddr/24asn
If you are on the list or know someone who is, please encourage them to
take steps to clean up their act. You may now return to your regularly
scheduled complaining about Verisign.
|