/24s run amuck

Mailman List Mirror (Read Only)
1

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.

2

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.

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

3

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.

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

Shared belief: some reasonably small subset potentially functionally
justified/relevant, majority unlikely so.

and that a large driver is to
make your network look larger than it is...

What audience??

mh

4

Unfortunately, I've seen Peering Policies which require things like "Must announce a minimum of 5,000 prefixes". :frowning:

5

>> and that a large driver is to
>> make your network look larger than it is...
>>
>
> What audience??

Unfortunately, I've seen Peering Policies which require
things like "Must announce a minimum of 5,000 prefixes". :frowning:

Wonderful...

mh

6

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.

or just filter

randy

7

Unfortunately, most customers expect connecting to the entire Internet, not just the parts that are smart and courteous enough to aggregate. Since most networks are in business to make money, they do what their customers want. Unless all networks filter alike, customers will migrate to the ones with the "best" connectivity. Given that some networks cannot even aggregate properly, I submit it is impossible to get all networks to filter alike.

Deaggregation is annoying, rude, and silly, but it does not actually stop me my data getting from point A to point B. Disconnectivity between me and someone else on the Internet, whether they are aggregating properly or not, is not why I pay my transit provider. If I can't get there, you don't get paid.

This is a serious issue, since "Tier 1" networks have been huge deaggregation culprits in the past. I think China Telecom topped the latest CIDR report, and lots of people want to talk to the billion-plus end users over there.

So perhaps we should find a better way to encourage aggregation than hurting our business and customers? Anyone have a suggestion? Maybe public humiliation at NANOG? :slight_smile:

8

The only way I can see to do anything about this is for upstreams to educate
their customers and others to pressure their peers.

Educating customers... educating peers... I think enough had been tried and that is
just too much work for the most people with little effect.

The problem is the _upstreams_ are the general source of deaggs. If upstreams have policies
in place with well organized autonomous filtering system and routing policy, theirs customers
will most likely end up being having to justify deaggregation or else get filtered.

-J

9

>
>>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.
>
>or just filter

Unfortunately, most customers expect connecting to the entire Internet,
not just the parts that are smart and courteous enough to aggregate.
Since most networks are in business to make money, they do what their
customers want. Unless all networks filter alike, customers will
migrate to the ones with the "best" connectivity. Given that some
networks cannot even aggregate properly, I submit it is impossible to
get all networks to filter alike.

And given how desperate for business most companies selling IP transit to
multihomed customers are right now, do you really want to be the one not
carrying the ~ 30k more specifics that everyone else is? Only if you don't
like being picked as a best path...

So perhaps we should find a better way to encourage aggregation than
hurting our business and customers? Anyone have a suggestion? Maybe
public humiliation at NANOG? :slight_smile:

The problem is, most of the people involved wouldn't even understand the
humiliation...

P.S. Before you tell me the Internet will crash if we do not slow or
reverse the table growth, just don't. It might, it might not, but it
certainly will not happen tomorrow or even this year. After hearing
the doomsday prognostications over the table growth for close to a
decade now without the Internet falling over, it's just getting old.

If by crash you mean someone might have to upgrade their poorly designed
router or router-like device with a bizaare memory limit (hi MSFC1), then
yes it could happen. :slight_smile: Also, while syncing up one bgp feed might not be
that big of an issue, try bouncing a dozen bgp sessions at once (as in a
reboot) and time how long everything takes to converge...

You know, you would be hard pressed to find a $500 server with less than
1G of ram these days, but people are still routing with hardware which
can't take more than 128MB. Why vendors feel the need to design route
processors which are barely upgradable in RAM, not upgradable in
processing power, and at best 24-36 months behind the times of the
technology the Dell Interns are pushing for $499, is beyond me.

10

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?

11

The basic issue here is the huge difference between a nice, dense, slow
and relatively cool [cheap!] DRAM and very fast, not so dense, and pretty hot
[and very expensive] SRAM. That Dell server has DRAM. Your route processor
(if the router is at all fast) needs SRAM (and of the ultra-fast expensive
variety).

You're talking about the fib, I'm talking about the rib. Lets just assume
for the sake of argument that your 8mb of sram is enough to scale to a
million routes and is not a problem (or maybe not if you want to run a
bunch of seperate routing tables, but that is an unrelated issue :P).
There isn't really a reason why a route processor produced in the last 3
years needs sram at all.

And, oh by the way, for good performance the route processor usually
needs to share the same card as the link termination equipment -- those
nice lasers, and optical termination chips -- which eat board space and
generate heat you might otherwise budget for more route processor
memory.

Nah. Every modern routing device worth any kind of time or attention uses
something other than software lookups off the RP, even if it's just
hacking l3 info into a switch cam. Even if there does exist a slow path
through the route processor, it is assumed that if you hit it you're
already screwed. The bandwidth necessary to distribute the forwarding
information to the cards or other forwarding components is trivial.

As far as pricing for these things goes, let us take an example here...
The Juniper routing engine is actually a 6U blade server on it's side:

http://www.kontron.com/products/pdproductsubcategory.cfm?keyProductCategory=3&kps=681

I understand the need for compact components as space is limited, I
understand the performance limitations of using laptop components, and I
don't expect to see that kind of board upgradable to whatever processors
are out 3 years from now. But don't tell me that you can't sell the 2GHz
model that is available today instead of the p2 333mhz or the recently
introduced p3 600mhz, or that it costs anywhere near $20,000 for that
blade server. :slight_smile:

12

If you can't take the traffic from Site A to Site B, why are you announcing the /24s to the world? Why not just use a /24 from the upstream in each location and not force everyone else on the Internet to see your /24 which only has one path?

Your /24 will be covered by the larger CIDR from the upstream in each location. That's more stable anyway, announcing the /24 might get you dampened or something, and then you'd lose all connectivity.

13

Patrick W.Gilmore wrote:

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?

If you can't take the traffic from Site A to Site B, why are you announcing the /24s to the world? Why not just use a /24 from the upstream in each location and not force everyone else on the Internet to see your /24 which only has one path?

It doesn't have just one path. Multiple (different) ISPs at each location.

14

Easy to fix by changing to "covering N million IP addresses" - but, then,
that becomes an address space conservation issue.

--vadim

15

Then this is just two instances of the same problem: You have a site with a /24 and multiple upstreams. How do you aggregate?

Answer: You don't. This is the type of deaggregation which is a "necessary evil". And, IMHO, why filtering on /20 (or whatever) is a Bad Thing. You have just as much right to multiple upstreams as the "big guys". Again, IMHO. Many people on this list - all of them running large networks, you will notice - would argue otherwise. They seem to think that if you do not have a /16, you should not have multiple upstreams.

Fortunately, the market, and the Internet, has clearly spoken. Unfortunately, they may have spoken a little too loudly, and now we have "/24s run amuck". :slight_smile:

16

Yeah, that makes sense 'cause the utility of my network is directly related to the number of IPs in it.

Er, um, uh.... Maybe not.

17

Filtering on a /20 or whatever (up to /24) is a bad thing because
RIPE (and maybe APNIC) actually gives out /24 PI space, that comes out
of RIPE's /8's, not your upstream's /20 or /16 or /whatever...

Kind Regards,
Frank Louwers - on a /24 PI space...

18

And then there are the upstreams that filter legacy /24's
Seen that too...

19

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

Ok, my main dig is at the various people taking their /19 RIR allocation and
announcing 32x /24s. This may be justifiable.. but why do you want to be able to
control ingress in that way - are you trying to force your peers/upstreams to
carry traffic over their networks?

So just announce what you need to your upstreams as no-export, anything further
than their as-hop and the benefits are limited anyhow. If these are peers then
forcing them to carry your traffic is probably not a good thing.

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.

So what you're saying is you're really operating two networks so I dont see this
necessarily applies, you should treat each site as its own autonomous network
like any other pair of unconnected networks..

Steve

20

This was always a bad practice.

One of the major networks to do this is Gone. Another had rewritten their
policy to say something along the lines of "should advertise X amount of
address space in aggregate or the equivalent". I don't think anyone still
measures by prefixes alone. It was always the sign of cluelessness amongst
those setting peering requirements.

- Daniel Golding