|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: CIDR Report
In message <[email protected]>, "Roeland M.J. Meyer" writ es: > >> Owen DeLong: Saturday, May 13, 2000 3:35 PM >> >> > I actually agree with you here as well. relying on infinite >> router table growth is not a scalable strategy. We need >> something else. >> > >> Just a small technicality here, noone is talking about >> infinite routing >> table growth. There are only 4 billion (roughly) possible prefixes >> if you route every node as a /32. While 4 billion is a large number, >> it is far from infinity. > >Well, that statement was obviously not intended literally. But, since we're >throwing around numbers ... > >Simply taking addresses only, that comes out to ~16GB. At $100 per 64MB >this is about $25,000.00US in RAM, at current retail rates (prices may >vary by vendor). It's also about $16,000.00US of EMC disk-space. This >means that one full table would cost about $41KUS, just to store it. >But, what will this do to performance of such a router that's working >in a gig-E environment? The index table to access this puppy would be >larger than the prefix table. This could easily double the cost, say $82KUS? >Considering that I just paid $98KUS for a Cisco Catalyst 6509, I guess >this isn't too bad. However, this is only IPv4 and it is a bunch more than >the cost of the average BGP-capable router and every router on the backbone >would have to be upgraded. This is conservative since I have not yet allowed >for memory structure overhead. However, code-space would be relatively trivial >, >even Microsoft wouldn't be able to bloat it enough so anyone else would notice >. Of course, note that the real problem isn't the memory space, it's the CPU time to calculate the routing table updates. Note, too, that the more unaggregated prefixes in the net, the more changes will need to be propagated to every other router in the default-free zone, implying the need for more instances of a more expensive calculation. --Steve Bellovin
|