Re: [j-nsp] CGN ob MX5?
Hi Pavel, some corrections inline. Ciao Magno On Sat, Apr 14, 2012 at 2:09 PM, Pavel Lunin 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?
Many thanks for your information. Thanks and regards, Xu Hu On 13 Apr, 2012, at 21:52, Bill Blackford 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 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 >> >>> 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?
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?
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 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 > >> 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?
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 : > 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" > To: "Saku Ytti" > Cc: > 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 >> >>> 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?
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" To: "Saku Ytti" Cc: 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 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?
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?
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 > 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?
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
[j-nsp] 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp