Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: juniper

CGN ob MX5?

 

 

nsp juniper RSS feed   Index | Next | Previous | View Threaded


matthias at brumm

Apr 12, 2012, 7:31 AM

Post #1 of 10 (1701 views)
Permalink
CGN ob MX5?

Hi!

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

Regards,

Matthias
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


saku at ytti

Apr 12, 2012, 7:56 AM

Post #2 of 10 (1648 views)
Permalink
Re: CGN ob MX5? [In reply to]

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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jstuxuhu0816 at gmail

Apr 13, 2012, 12:20 AM

Post #3 of 10 (1646 views)
Permalink
Re: CGN ob MX5? [In reply to]

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 <saku [at] 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 [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


saku at ytti

Apr 13, 2012, 12:26 AM

Post #4 of 10 (1647 views)
Permalink
Re: CGN ob MX5? [In reply to]

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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


alex.arseniev at gmail

Apr 13, 2012, 12:30 AM

Post #5 of 10 (1643 views)
Permalink
Re: CGN ob MX5? [In reply to]

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" <jstuxuhu0816 [at] gmail>
To: "Saku Ytti" <saku [at] ytti>
Cc: <juniper-nsp [at] puck>
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 <saku [at] 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 [at] puck
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

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


matthias at brumm

Apr 13, 2012, 2:05 AM

Post #6 of 10 (1666 views)
Permalink
Re: CGN ob MX5? [In reply to]

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.arseniev [at] gmail>:
> 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" <jstuxuhu0816 [at] gmail>
> To: "Saku Ytti" <saku [at] ytti>
> Cc: <juniper-nsp [at] puck>
> 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 <saku [at] 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 [at] puck
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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


bblackford at gmail

Apr 13, 2012, 6:52 AM

Post #7 of 10 (1650 views)
Permalink
Re: CGN ob MX5? [In reply to]

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 <jstuxuhu0816 [at] gmail> 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 <saku [at] 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 [at] puck
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp [at] puck
> 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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


plunin at senetsy

Apr 14, 2012, 5:09 AM

Post #8 of 10 (1650 views)
Permalink
Re: CGN ob MX5? [In reply to]

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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


jstuxuhu0816 at gmail

Apr 14, 2012, 11:08 PM

Post #9 of 10 (1633 views)
Permalink
Re: CGN ob MX5? [In reply to]

Many thanks for your information.

Thanks and regards,
Xu Hu

On 13 Apr, 2012, at 21:52, Bill Blackford <bblackford [at] gmail> 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 <jstuxuhu0816 [at] gmail> 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 <saku [at] 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 [at] puck
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp [at] puck
>> 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 [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp


massimo.magnani at gmail

Apr 16, 2012, 6:32 PM

Post #10 of 10 (1659 views)
Permalink
Re: CGN ob MX5? [In reply to]

Hi Pavel, some corrections inline.

Ciao
Magno

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

> Hi,
>
> Until Juniper realizes MS-MIC (I have no idea when it will happen) MX580
> 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
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

nsp juniper RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.