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
If you have any comments please contact Philip Smith <pfs@cisco.com>.
Routing Table Report 04:00 +10GMT Sat 08 Jan, 2005
Analysis Summary
Routing Table Analysis wrote:
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.netIf you have any comments please contact Philip Smith <pfs@cisco.com>.
Routing Table Report 04:00 +10GMT Sat 08 Jan, 2005
Analysis Summary
----------------BGP routing table entries examined: 153319
Prefixes after maximum aggregation: 89967
Should it matter that in six months its gone from 140k to 153k?
At this rate it might crack 200k in less than two years.
I think that's a matter that seems to be already decided. People
want multihoming, redudnancy and such and are willing to put the burden
on the global routing table as a result.
The result, people are upgrading router memory to the max, lots
of people have been asking recently about how much memory for a full
routing table, etc..
I think the simple answer is:
If you're using anything "recent" (ie: since 2001) you're going
to want to use 256m at minimum and ideally 512m-1g of dram in your system
with a reasonable cpu to process updates quickly.
This is something that the market has really demanded (multihoming)
so the result is a global impact. The statement "think globally, act
locally" comes to mind, but it's a tough problem as everyone depends on
their internet connectivity these days, so they want it to be
as reliable as possible.
- jared
Analysis Summary
----------------BGP routing table entries examined: 153319
Prefixes after maximum aggregation: 89967Should it matter that in six months its gone from 140k to 153k?
At this rate it might crack 200k in less than two years.
This was about the weekly routing table report, but I'm going to bring in some numbers from the CIDR report.
It would be back down to 140k if the "dirty 30" top offenders in the CIDR Report would aggregate their routes.
Someone's going to have to draw a line in the sand at some point, and someone thinking locally and acting globally is going to be punished by the globe. Don't ask me how this could work, because I don't have an answer.
Maybe "I'm the Dirty 30" T-Shirts could be made up and handed out. (I wonder if a couple of major routing venders, who profit from routing table growth, would sponsor the creation of the t shirts.... snicker...)
-Jerry
This was about the weekly routing table report, but I'm going to bring in
some numbers from the CIDR report.It would be back down to 140k if the "dirty 30" top offenders in the
CIDR Report would aggregate their routes.Someone's going to have to draw a line in the sand at some point, and
someone thinking locally and acting globally is going to be punished by
the globe. Don't ask me how this could work, because I don't have an
answer.
Yeah I've been noticing this problem myself too...I'm between 150k and 151k at my various peers. Most of the gear at my edges should be fine well past the 250,000 mark or so, but I know of people who are having problems right now, even if they don't know it.
What, really, could be done to curtail these offenders?
How much has the second number changed? Is this the result of worsening
aggregation or simply more address space being advertised?
Core routers won't even blink at 200k routes. I wonder how many enterprise
3x00/7x00 routers will fall over due to memory issues.
Also, as we have learned previously, past routing table growth (especially
for a short period) is an extremely poor predictor of future growth.
- Dan
[snip]
I think that's a matter that seems to be already decided.
People want multihoming, redudnancy and such and are willing
to put the burden on the global routing table as a result.
The matter was not strictly (not even primarily) multihoming
when the last serious look at the data was made, and it doesn't
appear to be the matter today. CAIDA's older data matches my
current anecdotal day-to-day experience.* (No one has offered
more current analysis in the wake of continuing threads here
and elsewhere. If you've got more recent data + analysis then
then please share.)
The largest growth element I see is deaggregation of 'classical'
space which may have perfectly valid purpose within an AS, or in
a provider-customer relationship, but not N hops away in the DFZ.
The reasons vary from putting the burden of traffic engineering
on the rest of the world to handwaving about applying security
band-aids by reducing the visibility into the the target space.
Trivial example pulled off the top: 136.223.0.0/16 sourced as
raft of same as-path deaggregates by 7018. Are there IRR entries
to indicate a conscious decision rather than error? Surely you
jest.
Yes, growth happens and the memory addition Jared cites has been
going on and continues to go on (multihoming enterprises, other
edge customers now get to feel the pain). There are some
interesting observations as part of the current 'atom' work**
previously discussed in the nigh-weekly related threads here.
Joe
* specifically, see para 2 in conclusions of "Complexity of global
routing policies" CAIDA Resource Catalog
** section 6 in Atoms - CAIDA
The largest growth element I see is deaggregation of 'classical'
space which may have perfectly valid purpose within an AS, or in
a provider-customer relationship, but not N hops away in the DFZ.
The reasons vary from putting the burden of traffic engineering
on the rest of the world to handwaving about applying security
band-aids by reducing the visibility into the the target space.
Joe,
If I was visiting your home and I happened to toss
a rock through your livingroom window on my way out,
would you send me a bill for the repairs? We have
no existing business relationship, no contracts in
place, so would you send me a bill?
Sometimes there are technical solutions to problems
but if my actions increase your costs there is also
a non-technical solution. One could argue that this
whole "CIDR reports" issue should not even be discussed
on this list because it is a non-technical issue. If
someone else is causing your network increased costs,
send them a bill, talk to your lawyer, whatever.
But keep it off NANOG.
--Michael Dillon
(with only half of my tongue in cheek)