Re: Cheap LSN/CGN/NAT444 Solution

[Owen DeLong <owen () delong com>]

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