|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Owen DeLong <owen@delong.com> In-Reply-To: <CAEUfUGPKSDz_62=+ay=VpgLYzCTb5jH1Arn+Rc8QoGAY=2j5dg@mail.gmail.com> Date: Mon, 30 Jun 2014 17:39:04 -0700 To: Skeeve Stevens <skeeve+nanog@eintellegonetworks.com> Cc: "nanog@nanog.org" <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org 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. >=20 > 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'. >=20 > 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. >=20 >=20 >=20 > ...Skeeve >=20 > *Skeeve Stevens - *eintellego Networks Pty Ltd > skeeve@eintellegonetworks.com ; www.eintellegonetworks.com >=20 > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >=20 > facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> > linkedin.com/in/skeeve >=20 > experts360: https://expert360.com/profile/d54a9 >=20 > twitter.com/theispguy ; blog: www.theispguy.com >=20 >=20 > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering >=20 >=20 > On Mon, Jun 30, 2014 at 10:06 PM, Stepan Kucherenko <twh@megagroup.ru> > wrote: >=20 >> On 30.06.2014 14:12, Roland Dobbins wrote: >>> I've seen huge problems from compromised machines completely killing >>> NATs from the southbound side. >>=20 >> 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. >>=20 >>=20 >> 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. >>=20 >>> I am looking at a Cisco ASR1001/2, pfSense and am willing to = consider >>> other options, including open source.... Obviously the cheaper the >>> better. >>=20 >> 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. >>=20 >> 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. >>=20 >> Both those options aren't really cheap though. >>=20 >> 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. >>=20 >> 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). >>=20 >>=20 >> BTW, I agree that you should speak in PPS and bandwidth instead of >> number of users, those are much better as a metric. >>=20 >>=20 >>> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>> 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. >>=20 >> 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. >>=20 >>=20 >>=20 >>=20
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |