Recent Table History
Date Prefixes CIDR Agg
04-02-05 151613 103143
05-02-05 152142 103736
06-02-05 152231 103721
07-02-05 152353 103830
08-02-05 152514 103966
09-02-05 153855 104090
10-02-05 154283 104246
11-02-05 154341 104240
<...>
~ +3000 routes in one week? Anyone else frightened by this?
Florian
~ +3000 routes in one week? Anyone else frightened by this?
Only people who have stock in vendors welcome it. Be prepared
for another huge glut of unnecessary outages, hardware and
memory upgrades soon folks!
FYI - at $job [AS8220] we have just completed a program
to fix the aggregation problem that we had. It took
about 10 weeks to complete and I will present a paper
on this at LINX 48 next week.
Regards,
Neil.
any thoughts on how to fix it? my peers keep sending these to me and i'll even
admit my customers do too. telling people its bad doesnt appear to have an
effect, at the small end networks seem to collect /24s and announce them freely,
at the large end i'm still without an explanation as to why large networks
require so many prefixes - none of them seem to comment?
if people arent self policing it seems the only other way is for the larger
transit providers to stop accepting prefixes and telling their customers to fix
their s**t. and i dont see them doing this.
Steve
any thoughts on how to fix it? my peers keep sending these to
me and i'll even admit my customers do too. telling people
its bad doesnt appear to have an effect, at the small end
networks seem to collect /24s and announce them freely, at
the large end i'm still without an explanation as to why
large networks require so many prefixes - none of them seem
to comment?if people arent self policing it seems the only other way is
for the larger transit providers to stop accepting prefixes
and telling their customers to fix their s**t. and i dont see
them doing this.
proxy aggregation if they don't fix it.
Neil.
Frotzler, Florian said the following on 11/02/2005 21:31:
Recent Table History
Date Prefixes CIDR Agg
04-02-05 151613 103143
05-02-05 152142 103736
06-02-05 152231 103721
07-02-05 152353 103830
08-02-05 152514 103966
09-02-05 153855 104090
10-02-05 154283 104246
11-02-05 154341 104240~ +3000 routes in one week? Anyone else frightened by this?
Yup.
glance shows that the vast majority of the increase comes from ASNs assigned by ARIN (the ASNs from the other three registry regions show minimal increase in announcements).
Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes.
philip
Actually, from a quick look at the following:
http://www.cidr-report.org/as4637/aggrweek.html
http://www.cidr-report.org/as4637/as-announce.txt
http://www.cidr-report.org/as4637/as-wdl.txt
either I'm misreading the data, or the script that generates the email is
broken and giving wrong numbers of total routes.
FWIW, my I'm not seeing any more than 152843 routes in the global
table...but I reject anything longer than /24.
According to the weekly agg in the first link, there are 151999 routes in
the table today and were 151889 on 11Feb05, which is the date the emailed
report goes up to.
According to the weekly add/withdraw data, 1732 routes were added and 1964
routes were withdrawn, a decrease of 232 routes in the week, and looking
at the aggrweek.html page gives a net decrease of 232 routes for the week
(12Feb05 - 05Feb05).
Time Warner apparently had some sort of deaggregation accident where they
went from 962 nets on 07Feb05 to 2238 routes 08Feb05, 2602 routes 09Feb05,
and finally back down to 1031 on 11Feb05. Anyone know what happened
there?
>
> > Recent Table History
> > Date Prefixes CIDR Agg
> > 04-02-05 151613 103143
> > 05-02-05 152142 103736
> > 06-02-05 152231 103721
> > 07-02-05 152353 103830
> > 08-02-05 152514 103966
> > 09-02-05 153855 104090
> > 10-02-05 154283 104246
> > 11-02-05 154341 104240
> <...>
>
> ~ +3000 routes in one week? Anyone else frightened by this?
>
> Florianany thoughts on how to fix it? my peers keep sending these to me and i'll even
admit my customers do too. telling people its bad doesnt appear to have an
effect, at the small end networks seem to collect /24s and announce them freely,
at the large end i'm still without an explanation as to why large networks
require so many prefixes - none of them seem to comment?if people arent self policing it seems the only other way is for the larger
transit providers to stop accepting prefixes and telling their customers to fix
their s**t. and i dont see them doing this.
It seems to me they get paid to carry prefixes by their customers.
And their peers listen to the prefixes because they make money by using
those prefixes.
So, to the extent you make money listening to them, use the routes.
And if they start to cause you problems you will have to take corrective
action to stablize your network, as was done a long time ago (internet
time):
http://www.merit.edu/mail.archives/nanog/1995-09/msg00047.html
(link grabbed at random from the archives, I'm sure there are better posts
that actually list the full old school sprint filters.)
However, if you are the one filtering and all your competitors figure out
how to handle 154,000 routes then you will be at a competitive
disadvantage.
Coincidentally, the largest networks also spend the most with their
vendors and get to tell the vendors what they want in the next generation
of boxes they buy.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
Hello Stephen,
any thoughts on how to fix it?
back to the "smallest allocation" per /8 that the RIRs have published and make it part of the MoU at the larger NAPs/exchange points.
at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment?
Commercial reasons? The traffic goes to the 32x/24 instead of the /19. Not to mention the BGP customer may go to another provider. You end up in discussions (if you get that chance at all) with your sales group and look like a dogmatic fool as "other companies do this".
Saving the world works best if the pain is no one's fault - at least "not my fault" 
Regards, Marc
>
> >
> > > Recent Table History
> > > Date Prefixes CIDR Agg
> > > 04-02-05 151613 103143
> > > 05-02-05 152142 103736
> > > 06-02-05 152231 103721
> > > 07-02-05 152353 103830
> > > 08-02-05 152514 103966
> > > 09-02-05 153855 104090
> > > 10-02-05 154283 104246
> > > 11-02-05 154341 104240
> > <...>
> >
> > ~ +3000 routes in one week? Anyone else frightened by this?
> >
> > Florian
>
> any thoughts on how to fix it? my peers keep sending these to me and i'll
> even admit my customers do too. telling people its bad doesnt appear to have
> an effect, at the small end networks seem to collect /24s and announce them
> freely, at the large end i'm still without an explanation as to why large
> networks require so many prefixes - none of them seem to comment?
>
> if people arent self policing it seems the only other way is for the larger
> transit providers to stop accepting prefixes and telling their customers to
> fix their s**t. and i dont see them doing this.It seems to me they get paid to carry prefixes by their customers.
the payment would be the same if it was a /19 or 32x/24 announced at source
And their peers listen to the prefixes because they make money by using
those prefixes.So, to the extent you make money listening to them, use the routes.
so the problem is noone wants to be the first to jump as it costs money? so
whats the suggestion for how to not be first? ie is it possible for a small
group of large operators to agree a consensus?
you dont even have to actively filter to start this, if a script were run to
advise customers daily when they were announcing routes incompliant to the
transits 'routing policy' it would have some effect. one thing i've found from
some of my customers is they're actually ignorant to the problems they cause,
they think its cool to announce 10 prefixes and can be educated otherwise.
Steve
Mike,
It seems to me they get paid to carry prefixes by their customers.
And their peers listen to the prefixes because they make
money by using those prefixes.
I'm sure this type of statement helps drug dealers to sleep at night! 
If the top 100 AS's de-aggregated and increased the routes they
announce by 6000 each would we be so content?
However, if you are the one filtering and all your
competitors figure out how to handle 154,000 routes then you
will be at a competitive disadvantage.
But its not just 154,000 routes though is it?! If we all start
doing this at a much increased rate [as we've seen in recent times]
then it will be more like 1,540,000 routes.
When we cleaned the issue from 8220 we found that a lot of the issues
were config issues and ancient history transient workarounds for
problems that were not fixed after the event. The issue we see is
bad aggregation - the root cause is bad practise and processes
that manifest into bad aggregation. I would argue that
networks with poor aggregation are also networks that will tend to
have more routeing issues and other outages although I have no
data to back that claim up.
Coincidentally, the largest networks also spend the most with
their vendors and get to tell the vendors what they want in
the next generation of boxes they buy.
And look how well that's worked out not notably on this issue.
Regards,
Neil.
Commercial reasons? The traffic goes to the 32x/24 instead of
the /19.
If that's the reason why the table is growing so much then we
are all in deep deep trouble.
Neil J. McRae said the following on 12/02/2005 21:06:
The issue we see is bad aggregation - the root cause is bad practise and processes that manifest into bad aggregation. I would argue that networks with poor aggregation are also networks that will tend to have more routeing issues and other outages although I have no
data to back that claim up.
I think it depends on which part of the world you look in. But I've visited enough ISPs in the last 7 years in my part of the world (outside US and Western Europe) to know that this is an accurate statement. Again, no data to back this experience up.
Neil J. McRae said the following on 12/02/2005 21:07:
>
>>Commercial reasons? The traffic goes to the 32x/24 instead of
>>the /19.
>
> If that's the reason why the table is growing so much then we
> are all in deep deep trouble.
Quite often many service providers are de-aggregating without knowing it. They receive their /20 or whatever from the RIR, but they consider this to be 16 Class Cs - I'm not joking - and announce them as such to the Internet. I spend a lot of time getting these folks to announce aggregates, but it is hard work convincing people that this will even work. Even if the RIR recommends that they announce their address block, they still consider it as Class Cs - even Class Bs for some big allocations. 
Solution is education, but the industry is such in many parts of the world that education is not desired but considered a negative reflection on people's abilities, whether they have the abilities or not. And the lack of educators - there are several of us on the worldwide NOG trail but it's very clear we are not enough. Nor do the NOGs cover the ISP industry, but just those who are interested in participating. We are not enough due to lack of time, lack of supportive employers, more focus on making profit in these leaner times, etc...
Where next I don't know...
philip
Hi Philip,
Quite often many service providers are de-aggregating without knowing it. They
receive their /20 or whatever from the RIR, but they consider this to be 16
Class Cs - I'm not joking - and announce them as such to the Internet. I spend
a lot of time getting these folks to announce aggregates, but it is hard work
convincing people that this will even work. Even if the RIR recommends that
they announce their address block, they still consider it as Class Cs - even
Class Bs for some big allocations.
this is getting into what i was implying earlier.. you have wider experience
than me - would you agree that most of the poor deaggregating is not intentional
ie that they're announcing their '16 class Cs' or historically had 2 /21s and
dont even realise they could fix it.. that applies to medium and large providers
too reading this list - how often do they actually check what prefixes they are
sourcing, from my recent work at a couple of european IXes i had a number of
folks email me offlist as they hadnt realised til I sent out an email they had
deaggregation and once it was pointed out they just fixed it.
so to repeat my earlier suggestion - if transit providers, particularly the
larger ones setup scripts to notify their customers daily/weeks of routing
deaggregation do you think we might gain some traction in educating and fixing
this?
Steve
Why does it have to be transit providers (customer relationship, so it's
not spam? Anyone could look at the global table (or just take the CIDR
Report data) and automate emailing the ASN contacts for each ASN a list of
what they're announcing and a list of the routes they probably should be
announcing instead.
I've personally dealt with a customer not too long ago who when we turned
them up was announcing 2 /20s, a /21, a /22, and several /23s and /24s all
deaggregated as /24s. Sprint and Qwest (their other upstreams at the
time) apparently had no problem with this. I saw what they were doing and
asked them why. "That's how our router consultant set it up." There was
no technical reason for it. I helped them reaggregate their BGP
announcements.
I'll bet there are at least hundreds of similar AS's that just need to
be prodded (or maybe even some hand holding or config help) in order to
clean up their announcements.
From my own Routing Report (due out in a couple of hours), a quick
glance shows that the vast majority of the increase comes from ASNs
assigned by ARIN (the ASNs from the other three registry regions show
minimal increase in announcements).
Duh! No suprise there. ARIN just gives IP space and only offers some
measly online training:
http://www.arin.net/library/training/index.html
RIPE on the other hand, has 3-6 course a month, throughout Europe:
http://www.ripe.net/training/lir/index.html
http://www.ripe.net/cgi-bin/courselist.pl.cgi
APNIC also has a number of courses and goes out to where it is needed:
http://www.apnic.net/training/schedule.html
As long as ARIN just doles out IP space with no education, the routing
table will continue to grow.
-Hank
I've personally dealt with a customer not too long ago who when we turned
them up was announcing 2 /20s, a /21, a /22, and several /23s and /24s all
deaggregated as /24s. Sprint and Qwest (their other upstreams at the
time) apparently had no problem with this. I saw what they were doing and
asked them why. "That's how our router consultant set it up." There was
no technical reason for it. I helped them reaggregate their BGP
announcements.I'll bet there are at least hundreds of similar AS's that just need to
be prodded (or maybe even some hand holding or config help) in order to
clean up their announcements.
It would appear that ARIN education is somehow lacking in regards to their
paying membership.
-Hank
[see my previous post]
From: "Stephen J. Wilcox" <steve@telecomplete.co.uk>
[...] - would you agree that most of the poor deaggregating is not intentional
ie that they're announcing their '16 class Cs' or historically had 2 /21s and
Think about someone putting in a Null0 route and re-
exporting stuff unconditionally, now after he originates
his /19 he is then adding a /24 here, and a /25 there.
Lack of experience, when you suggest to them they should
remove these announcements they are afraid to change it,
not understanding the implications, etc.
Not to mention ppl using cisco and prefix lists, it is
way too easy with cisco to say '/19 le 24', and then they
use outbound prefix lists to their transit supplier
(different, but related as I see it). Some transit ISPs
use that a lot, and encourage the table growth.
Also I think a further problem is (from experience) some
content hosters wanting to bleed (right word?) /24's to
their providers, even though their ratio is 10:1 or more and
inbound traffic is not exactly relevant. Too often it makes
no sense, and I am speaking of the '32* /24 is a /19'
version, mind you, sometimes not even announcing the
supernet...
Seeing the larger DSL prefixes in Europe then in Europe
what do we conclude? See for 3352 or 3269 (sorry)... But
when we try to measure (de-) aggregation by continent it
gets tricky... (and I believe I know winner and loser)
I am not sure doing it the Swisscom way (they filter a lot)
is the way to go, yet I would be curious how many routes
they currently carry for a full route set. Ah, here it is:
->
route-views.oregon-ix.net>sh ip bg su | incl 3303
164.128.32.11 4 3303 3351176 140593 74037481 0 0 2w2d 69713
<-
I have a hard time argueing this topic with customers, and I
have the feeling I am not the only one. We are past that
already, I feel.
so to repeat my earlier suggestion - if transit providers, particularly the
larger ones setup scripts to notify their customers daily/weeks of routing
deaggregation do you think we might gain some traction in educating and fixing
this?
That may be a way to go actually. Like the mail for what
prefixes are lacking a route: object that one might just send
to customers, not to peers... (5430 peers surely remember)
Alexander
Alexander Koch wrote:
I am not sure doing it the Swisscom way (they filter a lot)
is the way to go, yet I would be curious how many routes
they currently carry for a full route set. Ah, here it is:->
route-views.oregon-ix.net>sh ip bg su | incl 3303
164.128.32.11 4 3303 3351176 140593 74037481 0 0 2w2d 69713
<-
Since you mentioned it:
http://www.ip-plus.net/technical/route_filtering_policy.en.html
Additionally you might want to see the slides of Andr� Chapuis' presentation held at SwiNOG #7:
http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
Pro's and con's, of course. But I guess Swisscom is still living with 128 Meg
Fredy Kuenzler
Init Seven AG / AS13030
If that list is current, they're also living without connectivity to many networks on the Internet (entire /8's missing).
Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN
There are 10 kinds of people in the world. Those who understand binary and those that don't.
I split my Routing Analysis based on registry region so that the constituents of each region know what is going on in their area.
As you know registries offer training if their membership ask for it. APNIC and RIPE NCC membership seem to ask for training other than just how to be an LIR.
But how to be an LIR doesn't cover every single ASN who is announcing address space. For example, APNIC has an extensive region wide programme, but there is still large deaggregation here in the AP region...
So I really don't see what RIR training has to do with this. It helps, but it isn't the complete solution. If the industry is worried, the industry has to do something about it.
philip