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

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.

On Jan 13, 2004, at 6:33 AM, Michael Hallgren wrote:

...

...

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". :(

Wonderful... mh

-- TTFN, patrick

On Jan 13, 2004, at 4:04 PM, Vadim Antonov wrote:

On Tue, 13 Jan 2004, Michael Hallgren wrote:

...

...

On Jan 13, 2004, at 6:33 AM, Michael Hallgren wrote:

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

Wonderful...

mh

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

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. -- TTFN, patrick

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 On 1/13/04 6:52 AM, "Patrick W.Gilmore" <patrick@ianai.net> wrote:

On Jan 13, 2004, at 6:33 AM, Michael Hallgren wrote:

...

...

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". :(

On Jan 13, 2004, at 9:58 AM, Randy Bush 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.

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. 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? :) -- TTFN, patrick 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.

Sadly, the type of person that public shame would work on, is the type of person that is already taking care of the problem, or will be soon. There is one mechanism for helping to solve this. Is there an RFC, informational or otherwise that clearly specifies that BGP announcements to peers and transit providers must be aggregated to the greatest extent possible? If not, someone should write one. If yes, they lets publicize it. This is a wonderful tool for network engineers to take to their managers, so they can say "look, we have to do this, the RFC says so, and we MUST be RFC complaint or #insert-horrible-thing will happen to us". We live in a world of PHBs (Point Haired Bosses - see dilbert) - Dan On 1/13/04 12:26 PM, "Patrick W.Gilmore" <patrick@ianai.net> wrote:

On Jan 13, 2004, at 9:58 AM, Randy Bush 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.

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.

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

--On Wednesday, January 14, 2004 3:36 PM -0500 Daniel Golding <dgolding@burtongroup.com> wrote:

There is one mechanism for helping to solve this. Is there an RFC, informational or otherwise that clearly specifies that BGP announcements to peers and transit providers must be aggregated to the greatest extent possible?

Just want to clarify that BGP announcements to peers should by default be aggregated as far as possible, but can be completely deaggregated if both parties agree. For example, if you have a BGP session with my employer and we haven't mentioned it recently, we would *love* deaggregation. Send us /32s, MEDs, communities and we'll chew it up and ask for more. But we're special - we don't have a network and we don't sell transit.

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.

Patrick W.Gilmore wrote:

On Jan 13, 2004, at 2:19 PM, Steve Francis 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.

On Tue, Jan 13, 2004 at 04:12:13PM -0500, Patrick W. Gilmore wrote:

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

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... -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium

...

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

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.