Re: /24s run amuck

["Stephen J. Wilcox" <steve () telecomplete co uk>]

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