Cheap LSN/CGN/NAT444 Solution

Tue Jul 1 00:28:51 UTC 2014

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.
>
>
>
>