[j-nsp] CGN ob MX5?

[magno]

Hi Pavel, some corrections inline.

Ciao
Magno

On Sat, Apr 14, 2012 at 2:09 PM, Pavel Lunin <plunin at senetsy.ru> wrote:

> Hi,
>
> Until Juniper realizes MS-MIC (I have no idea when it will happen) MX5–80
> boxes really supports no NAT at all.
>
[MAGNO] Not dynamic NAT (or PBA), just static 1:1 nat

>
> 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.
>
[MAGNO] Not really. 1:1 static nat is not using TCAM, basically it is a
very basic form of NAT which won't require the maintenance of any
connection table.
Handling a connection table to support dynamic form of NAT is not suitable
for TRIO (or for any other forwarding asic) for both memory constraints and
processing time.

>
> 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.
>
> [MAGNO] LU may even be able to do NAT, it is really very flexible indeed,
but it can't maintain any session / connection table, for sure not at a
scale. MS-DPC has for instance 4 Gigabytes of RAM and a dedicated multicore
processor to do it. TCAM is not used in inline nat.


> 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.
>
> [MAGNO] the TCAM won't be enlarged on the new Enhanced MPCs, just a region
of LU memory will be doubled. TCAM is physicall present inside MPCs but it
is not used by any software as per today. TCAMs are not the most suitable
solution to scale and maintaining low power consumption for instance.

> --
> Pavel
>  _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>