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.