On Mon, 19 Apr 2010 19:57:04 -0700 Owen DeLong <owen@delong.com> wrote:
On Apr 19, 2010, at 3:10 PM, Florian Weimer wrote:
* Leo Bicknell:
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.
If you NAT all traffic, the NAT database needs the same level of efficiency as the FIB.
You could probably even join the two (you should check that the corresponding RIB entry is still current, but that can probably be forced to be cheap).
More likely, if you're going to do this (and I would not wish it on my worst competitors), you would want to push smaller NATs out towards the customer aggregation point where you can get away with cheaper commodity hardware that can later be repurposed. Yes, more boxes, but, much less expensive and keeps the router doing what routers do best rather than NATing everything on the router.
Pushing functions as closer to the edge of the network usually makes them easier to scale and more robust and resilient to failure. There might be more chance of failure, but there is less consequence. Specific to CGN/LSN, I think the best idea is that if we can't have a 1 to 1 relationship between subscriber and global IPv4 address (in the ISP network that is), the next best thing is to try to keep as close to that as possible e.g. if you share a single IPv4 address between two customers, you've halved your IPv4 addressing requirements / doubled your growth opportunity, and allowed for e.g. 32K TCP or UDP ports for each of those customers. Regards, Mark.