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+na...@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 > ske...@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 <t...@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. >> >> >> >>
