/24s run amuck

Stephen J. Wilcox steve at telecomplete.co.uk
Tue Jan 13 21:48:59 UTC 2004


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




More information about the NANOG mailing list