Until Juniper realizes MS-MIC (I have no idea when it will happen) MX5â€“80
boxes really supports no NAT at all.
What they call Inline NAT on Trio (recently realized) is by nowâ€¦ ummâ€¦ sort
of a patch for a particular customer or something like. It only supports
1:1 bidirectional static mapping, which in no way has any relation to CGN.
If you take the license price into account, you'll understand what my
"ummâ€¦" really means.
AFAIK, the idea behind real inline NAT (not just static mapping) on Trio is
using the embedded TCAM memory. Something like what NetScreen/ISG firewalls
did. This approach processes first packets though the 'long cycle' in
software and than offloads the session state to TCAM, though which the
subsequent packets are switched.
Two challenges arise here:
1. The need for a flexible and powerful CPU for 'long cycle' processing.
I'm afraid, the LU-chip inside Trio is not the best thing here.
2. TCAM update speed bottleneck.
If you take a look at the new session per second rate of any TCAM-based
flow-device, you'll see it's quite not much in the context of CGN.
However, as of what I know, Juniper mobile team, which develops GGSN from
MX, is going this way and they even have special MPCs with extended TCAM.
In mobile world, though, where session lengths are usually longer on
account of the lower access rates and, consequently, the new sps rates a
also lower, theoretically, this can be a solution.
juniper-nsp mailing list firstname.lastname@example.org https://puck.nether.net/mailman/listinfo/juniper-nsp