Re: [j-nsp] CGN ob MX5?

2012-04-16 Thread magno
Hi Pavel, some corrections inline.

Ciao
Magno

On Sat, Apr 14, 2012 at 2:09 PM, Pavel Lunin plu...@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@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-15 Thread Xu Hu
Many thanks for your information.

Thanks and regards,
Xu Hu

On 13 Apr, 2012, at 21:52, Bill Blackford bblackf...@gmail.com wrote:

 This might also help.
 
 http://www.juniper.net/us/en/local/pdf/implementation-guides/8010076-en.pdf
 
 When testing CGN, there are some general things to keep in mind:
 
 1. Application/Functionality. How do standard applications function
 behind the double-nat?
 
 2. Performance and scale. What's the load on the service PIC? How many
 subs can you expect to nat behind a single, service PIC? At what point
 do you need to throw extra hardware at it?
 
 3. Placement. Where in your network do you place CGN? BNG/BRAS?
 Regional aggregation? Core aggregation? How do you separate dedicated
 Internet and business customers from subscribers? Depending on how far
 upstream your chosen placement might be, how do you handle dual
 egress?
 
 4. Logging/tracking subs. How can we log and track each individual
 subscriber all natting behind a single address? How verbose does that
 logging need to be? There are some nice knobs in 11.2 that
 specifically address some of theses issues.
 
 
 
 -b
 
 
 
 On Fri, Apr 13, 2012 at 12:20 AM, Xu Hu jstuxuhu0...@gmail.com wrote:
 Recently heard so many times about CGN, but i still don't understand what
 is the difference between NAT and CGN, can any expert explain what's the
 CGN.
 
 2012/4/12 Saku Ytti s...@ytti.fi
 
 On (2012-04-12 16:31 +0200), Matthias Brumm wrote:
 
 I would like to know, if no, some or all implementations of CGN will
 be working on a MX5?
 
 This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio.
 But if you know you will need CGN I would assume that MX5 will never get
 it, this way you'll avoid disappointment and possibly need for another box
 while waiting for needed feature to appear.
 
 NAPT (port based, nto1) is not possible as far as I understand on trio,
 then you'd need some service slot in the behind, which also I would assume
 never to exist when making purchase decision.
 
 --
  ++ytti
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 
 -- 
 Bill Blackford
 Network Engineer
 
 Logged into reality and abusing my sudo privileges.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-14 Thread Pavel Lunin
Hi,

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.

--
Pavel
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CGN ob MX5?

2012-04-13 Thread Xu Hu
Recently heard so many times about CGN, but i still don't understand what
is the difference between NAT and CGN, can any expert explain what's the
CGN.

2012/4/12 Saku Ytti s...@ytti.fi

 On (2012-04-12 16:31 +0200), Matthias Brumm wrote:

  I would like to know, if no, some or all implementations of CGN will
  be working on a MX5?

 This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio.
 But if you know you will need CGN I would assume that MX5 will never get
 it, this way you'll avoid disappointment and possibly need for another box
 while waiting for needed feature to appear.

 NAPT (port based, nto1) is not possible as far as I understand on trio,
 then you'd need some service slot in the behind, which also I would assume
 never to exist when making purchase decision.

 --
  ++ytti
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-13 Thread Saku Ytti
On (2012-04-13 15:20 +0800), Xu Hu wrote:

 Recently heard so many times about CGN, but i still don't understand what
 is the difference between NAT and CGN, can any expert explain what's the
 CGN.

That is good question :). I think it's just marketing for doing NAT in very
high scale, regardless how the NAT is done.
Usually with CGN it is implied that you are addressing problem of address
exhaustion.

And when ever it is 1-to-1, trio should be able to do it technically, but
n-to-1 isn't going to fly without additional hardware.
EVen IPv6 to IPV4 I think should be doable in Trio, like when IPv6 DADDR
has embedded IPV4 address of IPV4 only host, I think that could be
implementable in trio.
But never buy anything, if you can't deploy it today, in long-term
supported software release. Otherwise consider feature non-existing. Which
is the case for CGN and MX5.


-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-13 Thread Alex Arseniev

CGN used to be known/also known as Large Scale NAT (LSN)
Compare this  http://tools.ietf.org/html/draft-nishitani-cgn-01
and this http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05
Same IETF draft, different versions.


- Original Message - 
From: Xu Hu jstuxuhu0...@gmail.com

To: Saku Ytti s...@ytti.fi
Cc: juniper-nsp@puck.nether.net
Sent: Friday, April 13, 2012 8:20 AM
Subject: Re: [j-nsp] CGN ob MX5?



Recently heard so many times about CGN, but i still don't understand what
is the difference between NAT and CGN, can any expert explain what's the
CGN.

2012/4/12 Saku Ytti s...@ytti.fi


On (2012-04-12 16:31 +0200), Matthias Brumm wrote:

 I would like to know, if no, some or all implementations of CGN will
 be working on a MX5?

This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio.
But if you know you will need CGN I would assume that MX5 will never get
it, this way you'll avoid disappointment and possibly need for another 
box

while waiting for needed feature to appear.

NAPT (port based, nto1) is not possible as far as I understand on trio,
then you'd need some service slot in the behind, which also I would 
assume

never to exist when making purchase decision.

--
 ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-13 Thread Matthias Brumm
Hi!

We have bought our MX5, so this was rather a question to look, what
this box is also able to do. At the moment, we do not have the need
for CGN, and if we do, I now understand, that we have to look after a
new solution.

Regards,

Matthias

Am 13. April 2012 09:30 schrieb Alex Arseniev alex.arsen...@gmail.com:
 CGN used to be known/also known as Large Scale NAT (LSN)
 Compare this  http://tools.ietf.org/html/draft-nishitani-cgn-01
 and this http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05
 Same IETF draft, different versions.


 - Original Message - From: Xu Hu jstuxuhu0...@gmail.com
 To: Saku Ytti s...@ytti.fi
 Cc: juniper-nsp@puck.nether.net
 Sent: Friday, April 13, 2012 8:20 AM
 Subject: Re: [j-nsp] CGN ob MX5?



 Recently heard so many times about CGN, but i still don't understand what
 is the difference between NAT and CGN, can any expert explain what's the
 CGN.

 2012/4/12 Saku Ytti s...@ytti.fi

 On (2012-04-12 16:31 +0200), Matthias Brumm wrote:

  I would like to know, if no, some or all implementations of CGN will
  be working on a MX5?

 This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio.
 But if you know you will need CGN I would assume that MX5 will never get
 it, this way you'll avoid disappointment and possibly need for another
 box
 while waiting for needed feature to appear.

 NAPT (port based, nto1) is not possible as far as I understand on trio,
 then you'd need some service slot in the behind, which also I would
 assume
 never to exist when making purchase decision.

 --
  ++ytti
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-13 Thread Bill Blackford
This might also help.

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010076-en.pdf

When testing CGN, there are some general things to keep in mind:

1. Application/Functionality. How do standard applications function
behind the double-nat?

2. Performance and scale. What's the load on the service PIC? How many
subs can you expect to nat behind a single, service PIC? At what point
do you need to throw extra hardware at it?

3. Placement. Where in your network do you place CGN? BNG/BRAS?
Regional aggregation? Core aggregation? How do you separate dedicated
Internet and business customers from subscribers? Depending on how far
upstream your chosen placement might be, how do you handle dual
egress?

4. Logging/tracking subs. How can we log and track each individual
subscriber all natting behind a single address? How verbose does that
logging need to be? There are some nice knobs in 11.2 that
specifically address some of theses issues.



-b



On Fri, Apr 13, 2012 at 12:20 AM, Xu Hu jstuxuhu0...@gmail.com wrote:
 Recently heard so many times about CGN, but i still don't understand what
 is the difference between NAT and CGN, can any expert explain what's the
 CGN.

 2012/4/12 Saku Ytti s...@ytti.fi

 On (2012-04-12 16:31 +0200), Matthias Brumm wrote:

  I would like to know, if no, some or all implementations of CGN will
  be working on a MX5?

 This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio.
 But if you know you will need CGN I would assume that MX5 will never get
 it, this way you'll avoid disappointment and possibly need for another box
 while waiting for needed feature to appear.

 NAPT (port based, nto1) is not possible as far as I understand on trio,
 then you'd need some service slot in the behind, which also I would assume
 never to exist when making purchase decision.

 --
  ++ytti
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] CGN ob MX5?

2012-04-12 Thread Saku Ytti
On (2012-04-12 16:31 +0200), Matthias Brumm wrote:

 I would like to know, if no, some or all implementations of CGN will
 be working on a MX5?

This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio.
But if you know you will need CGN I would assume that MX5 will never get
it, this way you'll avoid disappointment and possibly need for another box
while waiting for needed feature to appear.

NAPT (port based, nto1) is not possible as far as I understand on trio,
then you'd need some service slot in the behind, which also I would assume
never to exist when making purchase decision.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp