Cheap LSN/CGN/NAT444 Solution

Tue Jul 1 00:39:04 UTC 2014

Greenfield or not, unless you can expect that 100% of the users have never
had internet access anywhere else before, you may be up against expectations
you are not meeting with NAT444.

Owen

On Jun 30, 2014, at 17:28 , Skeeve Stevens <skeeve+nanog at eintellegonetworks.com> wrote:

> Great advice Stepan.
> 
> Re user support.  It is a greenfield environment so we're in the position
> to say 'this is how it is and what you get'.
> 
> Re usage profile. No idea what to expect from users as there is nothing to
> measure.  I've actually not designed a NAT444 solution for residential
> profiles before so never had to worry about what they did.
> 
> 
> 
> ...Skeeve
> 
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> skeeve at eintellegonetworks.com ; www.eintellegonetworks.com
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellegonetworks ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
> 
> experts360: https://expert360.com/profile/d54a9
> 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> 
> 
> On Mon, Jun 30, 2014 at 10:06 PM, Stepan Kucherenko <twh at megagroup.ru>
> wrote:
> 
>> On 30.06.2014 14:12, Roland Dobbins wrote:
>>> I've seen huge problems from compromised machines completely killing
>>> NATs from the southbound side.
>> 
>> It depends on CGN solution used. Some of them will just block new
>> translations for that user after reaching the limit, and that's it.
>> 
>> 
>> On 30.06.2014 09:59, Skeeve Stevens wrote:
>>> I am after a LSN/CGN/NAT444 solution to put about 1000 Residential
>>> profile NBN speeds (fastest 100/40) services behind.
>> 
>>> I am looking at a Cisco ASR1001/2, pfSense and am willing to consider
>>> other options, including open source.... Obviously the cheaper the
>>> better.
>> 
>> ASR1k NAT is known to be problematic (nat overload specifically), don't
>> know if they fixed it yet. I recommend to check this with the vendor first.
>> 
>> New Juniper MS-MIC/MS-MPC multiservices cards can be used but
>> feature-parity with MS-DPC isn't there yet. For example, you can have a
>> working CGN with most bells and whistles, but you can't use IDS. You can
>> (probably) use deterministic nat with max ports/sessions per user, but
>> sometimes it's not enough. Again, ask the vendor for
>> details/roadmaps/solutions.
>> 
>> Both those options aren't really cheap though.
>> 
>> Cheaper would be something like Mikrotik but I wouldn't touch that sh*t
>> with a ten-foot pole. It might work but you'll pay for that with your
>> sanity and sleep hours.
>> 
>> Speaking of cheap and open-source, I know several relatively large
>> implementations using Linux boxes. One Linux NAT box can chew on at
>> least 1Gb/s of traffic, or even more with a careful selection of
>> hardware and even more careful tuning, and you can load-balance between
>> them, but it's much more effort and it isn't robust enough (which is the
>> reason why they all migrate to better solutions later).
>> 
>> 
>> BTW, I agree that you should speak in PPS and bandwidth instead of
>> number of users, those are much better as a metric.
>> 
>> 
>>> This solution is for v4 only, and needs to consider the profile of the
>>> typical residential users.  Any pitfalls would be helpful to know -
>>> as in what will and and more importantly wont work - or any
>>> work-arounds which may work.
>> 
>> Try to pair a user IP with a public IP, that way you'll workaround most
>> websites/games/applications expecting publicly visible user IP to be the
>> same for all connections.
>> 
>> Start with selected few active customers, check how much connections
>> they use with different NAT settings. Double/triple that. Then do the
>> math of how many ports/IPs you need per X users, don't just guess it.
>> Then try to limit it and see if anything breaks.
>> 
>> By working with them you can also workaround some of the problems you
>> didn't think about before. Seriously. Fix it before you roll it out.
>> 
>> What anyone implementing CGN should expect is complaints from users for
>> any number of reasons, like their IPSEC or L2TP tunnel stopped working,
>> or some application behaves strangely and so on. Prepare your
>> techsupport for that.
>> 
>>> This solution is not designed to be long lasting (maybe 6-9
>>> months)... it is to get the solution going for up to 1000 users, and
>>> once it reaches that point then funds will be freed up to roll out a
>>> more robust, carrier-grade and long term solution (which will include
>>> v6). So no criticism on not doing v6 straight up please.
>> 
>> Heh. Nothing lasts longer than temporary solutions. You should implement
>> it like you're going to live it for years (probably true) or you'll
>> create yourself a huge PITA very soon.
>> 
>> 
>> 
>> 