This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to bgp-stats@lists.apnic.net
For historical data, please see http://thyme.apnic.net.
If you have any comments please contact Philip Smith <pfs@cisco.com>.
Routing Table Report 04:00 +10GMT Sat 14 Oct, 2006
Analysis Summary
Shall we all have a moment of silence for 200K prefixes in the global table.
Maybe reboot all our routers at once or something?
I'm buying more stock in ram producers!!!!
Patrick W. Gilmore said the following on 14/10/06 04:16:
BGP routing table entries examined: 200339
Prefixes after maximum aggregation: 108814Shall we all have a moment of silence for 200K prefixes in the global
table.
My view actually hit 200k on Wednesday morning, then dipped back under
by a few hundred on Thursday.
I was kinda hoping that it would hit 200K on Tuesday, then I could have
added the announcement to my aggregation recommendations lightning talk!
Bit sad that a 200K table can be aggregated down to 109k prefixes
with no loss of path information (in my BGP table view).
Maybe reboot all our routers at once or something?
Who wants to go first...? Then again, maybe better not...
philip
I find this interesting.
Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info?
If there were a way to guarantee certain prefixes are completely superfluous, we could make a hit list of just those providers, then ridicule or filter or cause them pain in some way to make them stop causing us pain. I haven't seen that type of report posted publicly, just "this CIDR can fit in that one" without actual guarantees that _paths_ are equivalent. (Usually the origin AS is matched as well as the prefixes, but that's not the same as guaranteeing the path is equivalent.)
Of course, this is non-trivial. But then neither is aggregating the global table. 
how much of this could be mitigated if people properly announced
aggregates and used a provider-local no-export to balance their links
with them? it does make those policies more complicated than the
simple cut+paste examples that they've likely used in the past, but
could possibly allow the "traffic-eng" with their upstream without
the global pollution.
- jared
Sorry if I wasn't clear before, but I consider path info _just for your first hop upstream_ superfluous for the rest of the Internet. Does anyone think this is an unreasonable restriction?
More important question: How many people are doing TE or something and not applying no-export when they could? If you need help fixing that, or even figuring out if you need to fix it, I guarantee you several people on this list would help you, many for free.
This is one of the reasons things become "non-trivial". How do you prove that a disgregate prefix is useless to anyone except that one network?
I do not think it is impossible. But it certain ain't easy.
How many routers carry a full routing table? Let's say 100K of them, and
you can sell 128M more memory for each one.
Now how many boxes is Dell going to sell with 1G and 2G of RAM so Vista runs?
I suspect consumers sales in Topeka, Kansas alone will sell more RAM than
the worldwide market for routers that do full routing tables.
Let's keep some perspective here.
I think you have seriouisly under estimated that. think of the routers with distributed line cards then all the boxes that are soon to be a trash can job because they can't be upgraded. We deployed a load of prp2 cards and decided to max the ram out as the aggrevation of a mid production upgrade when we hit 300k isn't worth not doing it.
Cheers
Neil
Thanks for reminding me to change my neighbor maximum-prefix 250000 80 statements to something more "reasonable" before I started getting warnings to my pager! I'm still a few thousand routes shy of 200K as of today......
I like that second line that you included. Maximum aggregation isn't always possible, but I think there are a lot of operators out there that don't aggregate as much as they could. They cite various reasons for chewing up router memory ( "Oh, it's technically impossible....". or my favorite.... "because someone could announce more specifics and steal our traffic, so we have to announce 842 /24s all separately, ALL THE TIME" ) while the rest of the net doesn't seem to have those issues, (or they deal with them as they happen... "uh, oh, someone's blackholing our traffic, let's announce our space as /24s until we can get that other operator to correct their stupidity... we'll withdraw the /24s as soon as it's fixed 22 hours later....")
You should have put a difference number there too, just so everyone didn't have to get out their calculators to figure out how many extra routes there are (91525). So since my calculator is out, I did some more numbers. Of those 91,525 routes that are extra routes in the table, 14,444 of those are the dirty-30.
So of those top 30 ASes that I refer to as the "Dirty Thirty", represent .13% (POINT ONE THREE PERCENT!) of the ASes, but they contribute 15.7% of the amount of route-bloat on the net!! .13%,=15.7%.
The dirty-thirty is a shameful list. But apparently there isn't enough pressure from within the routing community to not be on it. At least not yet. 
Hmm. <looks around AS1312> 2 /16s, I'll be *generous* and say 100 interfaces
that have full routing tables (it's actually probably closer to a dozen).
But I have *at least* 30K user machines on my network that will all either
be stuck on XP or buying a gigabyte or two each for Vista. Even if my 100K
is off by a factor of 5 or even 10, that's still just a *pimple* on the RAM
sales that will happen even if Vista *flops*.
RAM's cheap. Buy stock in cisco and/or juniper. forklift router upgrades are not so cheap. A whole lot of NPE/RSP/SUP boards will be unsuitable for core router use (without route filtering) in the next year or two.
Sorry, I got several questions emailed to me, so I'll save my own bandwidth at the expense of everyone else's, and hopefully answer some people that didn't take the time/effort to ask...
The Dirty-Thirty is what I called the list of "Aggregation Summery" in the cidr report (cidr-report.org) that gets posted to the NANOG list. They put the top 30 ASes that have the most to gain through aggregation in their report for all to see. When discussing this in the past I referred to it as the dirty thirty.
In the past, I suggested giving out "I'm the dirty thirty" t-shirts at NANOG meetings to those attending from the networks listed. Require them to be worn to attend. Put slogans on them like "Aggregate is what you put in concrete, right?" Have a cute picture of a stick person on it with a concrete block for a head, next to a router or something.
More affective, less funny, and also somewhat discussed in the past, was my suggestion of the creation of a route-server style of distribution of filters (like the cymru bogon servers) that would filter routes to the top 5 people on the list, essentially black holing the absolute worst of the worst.
It basically would be similar to email RBL, except that it would break the entire net, not just SMTP. While it may be sacrilegious to discuss such things like purposely breaking parts of the net on the NANOG list, it's for the greater good. So hear me now, and belive me later.........
It would work like this:
Step 1) Read the cidr report
2)Contact those top 5 networks with a simple message. "Congratulations! You're in the top 5 of the dirty thirty! Aggregate now, because if you're still on the dirty-thirty list 60 days from now, and your entry can gain more than a 30% reduction size through aggregation, we're going to add you do the black hole server. Have a nice day."
3)Do this weekly.
3a)Shrug off threats of lawsuits.
4)In the mean time, a few crazy network operators would actually subscribe to the "Aggregation Route Server." It might be a guy with an ASN and a /24 in his apartment, or a small company with an underpowered router that's facing an upgrade and wants to try to change the world, maybe a small host or ISP, or whatever. Or maybe a larger organization might actually be insane enough to apply this to all of their border routers.
"Crazy" is the key operator here. And I mean that in a good way. It's crazy that the net even works... just announce some routes, and the world accepts them? Now *THAT'S* crazy!
The whole idea is a terror tactic like weapons of mass destruction and mine fields. And email RBLs. Remember when some through RBLs to be crazy? Who would block email and cause collateral damage for themselves just to stop a few spams? Turned out that the answer to that question was "Everybody." Getting blacklisted had quite an affect on people, and that alone closed a lot of open relays. Being responsible, and working to fight spam wasn't enough. It took a terror weapon like RBLs to get people to close their relays. I maintain that we are at the same point with the routing table. It would provide motivation to aggregate,to stay as far away from that top 30 list as possible. And because the rest of the world wouldn't actually know WHO is subscribed, or what impact it might actually have, or if say, a large tier-1 nsp might actually subscribe to it just to be belligerent (tired of needing more RAM for their core routers, and can make a crazy business case for it [didn't Sprint do something like that a long time ago or something?] ) or actually just plan crazy.
Maybe no one would join. That's OK too. The dirty thirty participants don't get to know that information. No one would know except for the operators of the (free) service. Because while you may have to be crazy to subscribe to it, you'd have to be equally crazy to sit on the top of the dirty thirty, and ignore the warnings that you might be black holed. Maybe a single tier-1 nsp decides to use it. That's pretty significant. Fight crazy with more crazy!
5)After 60 days, if the network that was in the top 5 to qualify hasn't moved out of the dirty thirty all together, actually go add all their un-aggregated space to the route server. Because we only really want to block the more specifics that are causing the bloat....
5a)Continuously monitor the actually global routing table, in somewhat real time... when they get aggregated, stop the madness immediately, and automagically.
6)Avoid lawsuits. Or get sued. Or fold and comply with the lawyers' demands. Whatever.
(I don't have a solution to this.... it's just a general requirement... I didn't say this would be easy, or even possible to operate in a sustainable manor.... I'm just saying that it is technically possible. Logic would dictate that RBL operators *shouldn't* be liable to lawsuits from spammers, but this is a pretty messed up world....)
7)Check to see if there routing suddenly becomes more aggregated. At some point, of the table as aggregated enough, it's not worth continuing. The point is maximize gains (go after the worst offenders, and scare everyone else in to being responsible too) with minimal effort. It's not possible to max aggregate everything, and that's not the point. The point is to get the worst of the worst to be more responsible.
Unfortunately, experience has taught me that there will always be plenty of irresponsible and/or clueless people to go around. So it very well may be a never ending process.
8)Return to step 1.
I've got some old routers sitting around, and a network to host them on..... I've wanted to do this now for quite some time, but don't have the time resources to make it all work. Anyone game to help me out with this? It's just crazy enough to work. Or am *I* just crazy for thinking so?
patrick@ianai.net ("Patrick W. Gilmore") writes:
Obviously the table contains kruft. But I know we could not shrink
it to 109K prefixes without losing something from where I sit. Are
you sure there's no additional path info?
before we could be sure that an aggregation proposal was nondestructive,
we'd have to model it from where a lot of people sit, not just patrick.
on the one hand this seems to be a useful endeavour. in addition to
measuring the total number of routes, we probably ought to measure the
number of non-TE-related routes, and focus our attention on those routes
and also the ratio ("global TE cost borne by the routing system.")
on the other hand i dispair of finding a set of observation posts and
metrics that will abstract TE out of the observed routes in a way that
wouldn't be seen as controversial or useless by most of the community.
patrick@ianai.net ("Patrick W. Gilmore") writes:
Obviously the table contains kruft. But I know we could not shrink
it to 109K prefixes without losing something from where I sit. Are
you sure there's no additional path info?before we could be sure that an aggregation proposal was nondestructive,
we'd have to model it from where a lot of people sit, not just patrick.
I do believe that was the point of my second & third sentence.
on the one hand this seems to be a useful endeavour. in addition to
measuring the total number of routes, we probably ought to measure the
number of non-TE-related routes, and focus our attention on those routes
and also the ratio ("global TE cost borne by the routing system.")
I'm not sure you could separate "TE routes" from "$FOO routes" externally. Unless you classify everything that doesn't go the way -you- think it should go as "TE". (Possibly a valid assumption.)
on the other hand i dispair of finding a set of observation posts and
metrics that will abstract TE out of the observed routes in a way that
wouldn't be seen as controversial or useless by most of the community.
Since we are discussing putting pressure on people who do stupid thing, not shooting them in the head, we do not need to be 100% accurate. A list of provider who most likely are filling the table, and then allowing people to filter, prod, annoy, e-mail, call, etc., those providers is enough. Right now we just have "these people could -theoretically- aggregate", without actually knowing if path info is lost.