On 4/19/2010 14:07, Leo Bicknell wrote: > e a few problems with your data.... > > I know of no platform that does hardware NAT. Rather, NAT is a CPU > function. While this is another interesting scaling issue, it means > this data is not going in the FIB (hardware forwarding database), > but rather is stored in a CPU accessible database. > > It's not that you need 3.1G/254G of memory in the FIB (which would > be expensive) but rather that you need it in relatively cheap DRAM. > Even if use your larger memory number of 254G that's only $10-15k > of RAM cost these days, hardly a deal breaker. The FIB would hold > only one entry for the /17 (or similar) pointing it to the CPU.
Well thats true of some implementations now, but some others put it in hardware. I'd say to scale you need to have it in hardware. > Secondly, you're playing to both extremes. Yes, the point to point > user will use 3500 entries and grandma checking e-mail may use 42 > entries. Not everyone will run a point to point client, and not > everyone will be grandma. Using an average is a much better first > start. I suspect though the percentage of users using a point to > point client is small though, and thus drives the average number > even lower. Yes, but I was showing what a great DDOS attack method it would be too ;) The numbers were slightly better than something I pulled from my backside to demonstrate why we can't nat an entire PDSN worth of customers. > So, 3500 + 42 / 2 = 1751 entries on average per person. > > 250,000 users * 1751 entries * 312 bytes/entry = ~136G of data. > > 250,000 users * 1751 entries / 64000 ports/IP = 6939 IP's. > > So a /19 provides headroom. 10 servers, each with 16G of RAM > (160G total) could do the job with headroom. Yea, but this is more along the lines of a science experiment at this point. I can't expect a carrier to deploy this, even if it's the best solution. The average carrier is _dumb_ and stupidity takes care of stupidity at these places. They are not going to deploy something unless it's Blue or Green (or purple). > Not all users will be active at the same time, so 100k per user > probably translates into a 1Mbps/sec rate, given the old 10:1 rule on > end users. > > 250,000 users * 100,000 bytes/sec = ~186Gigabits/sec. Humm, > 10 servers won't do that (18Gbps/sec per server of NAT, no way!). > 40 servers though would be 4.65Gbps per box, which with 10GE seems > reasonable. But that also means each one only needs 1/4th the RAM > from above. > > In summary, to NAT 250,000 users: > > 40 servers, each with: > CPU capable of NATing 4.65Gbps > 4-8Gb of memory > 2x10GE interfaces > A /19 of address space. > > I think a server like that could be had for $10k each, easy. So > 400k of servers, depreciated over 3 years, divided by 250,000 users: > $0.53 per user per YEAR. Or, $0.04 per month per user. Even selling > $20 packages ISP's should be able to absorb four cents per user. This is a good example, but I really would like to do some work on testing how much a given nat solution can scale. > NAT scales just fine. I find that quite unfortunate, personally, > but I don't think there's a problem with the technology or economics. It's a damn shame is what it is :( -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
