nanog mailing list archives
Re: Address allocation stats
From: Jeremy Porter <jerry () fc net>
Date: Wed, 12 Jun 1996 15:10:02 -0500 (CDT)
[initial stuff deleted]
They are much improved. When address reclaimation was started over this space, BBN had eight (8) blocks. And there are efforts in progress to recover more of this space. You will note that none of these blocks are for BBN-Planet but for BBN internal and BBN contracts for US Military nets. However, this is not the real problem. The largest concern is the so-called toxic-waste-dump of the 192.0.0.0/8 range. This is due to the fact that the critical path component is not address space but routing table entries. Efforts to get people to reduce the number of 192.0.0.0/8 entries in the global routing space will provide the most "bang for the buck" until (with a nod to Noels excellent arguments) better routers are on the market. So lets not pick on BBN while the real problem is chomping on our respective hindends.
Hm... perhaps I need a better chart at Nanog, anyway, here the summary: Todays total announce prefixes: ~36,000 Average aggregation on a prefix for currently unannounced space (not including RFC- space reserved for private networks) For a /20:
650,000
For a /19:
325,000
For a /18:
150,000
For a /17:
75,000
For a /16: <50,000 Now from my other chart " Your favority router vendor BGP memory usage" At /16 level of AVERAGE aggregation, plus legacy prefixs, we will be eating about 18megs of memory for Cisco BGP data with 4 full views (4 NAP/MAEs) At /17 (4.0 views): 30M of memory At /18 (4.0 views): 50M of memory At /19 (4.0 views): 100M of memory At /20, my chart won't fit on my screen. For those companies that are creating multiple private interconnections we can look at data for 8.0 views: (fractional View number are common in real world data since, there are legacy private interconnects and multi-home customers count differently, thew "view" number is the ratio of prefixes to path, since cisco's use about 135 bytes per prefix, plus 35 bytes per path, this is fairly constant). /17 (8.0): ~45M /18 (8.0): ~55M /19 (8.0): ~125M /20 (8.0): >225M At 16 paths per prefix (16 major exchanges) /17 (16.0): ~60M /18 (16.0): ~115M /19 (16.0): ~240M /20 (16.0): >370M Of course this is "end state" after all possible addresses have been assigned. Now if you just look at it on a total prefixes basis, you can see with 8 peering points and 75,000 prefixes, a Cisco 7000 is just going to die. And most of us know that route flap will kill is first, if we don't dampen. If any has any clear ways to gather data of route flap cpu utilization, I'd like to tal to them. Some people have done this, it just isn't very easy to gather data and do best fit function like the memory data was. -- Jeremy Porter, Freeside Communications, Inc. jerry () fc net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094 http://www.fc.net - - - - - - - - - - - - - - - - -
Current thread:
- Re: Address allocation stats, (continued)
- Re: Address allocation stats Paul Ferguson (Jun 04)
- Re: Address allocation stats Bill Manning (Jun 04)
- Re: Address allocation stats Ehud Gavron (Jun 05)
- Re: Address allocation stats Bill Manning (Jun 05)
- Re: Address allocation stats Ehud Gavron (Jun 05)
- Re: Address allocation stats Bill Manning (Jun 04)
- Re: Address allocation stats Paul Ferguson (Jun 04)
- Re: Address allocation stats Kai Alexander Scharwacht (Jun 11)
- Re: Address allocation stats bmanning (Jun 07)
- Re: Address allocation stats @NANOG-LIST (Jun 07)
- Re: Address allocation stats Jeremy Porter (Jun 12)
- Re: Address allocation stats Havard . Eidnes (Jun 18)
- Re: Address allocation stats Frank T Solensky (Jun 18)
- Re: Address allocation stats Mark Kosters (Jun 19)
- Re: Address allocation stats Daniel W. McRobb (Jun 18)