There’s also the issue of what a customer who needs something like GRE or IKE to work does from behind a CGNAT where there aren’t port numbers available for multiplexing.
Owen > On Feb 27, 2018, at 2:42 PM, Lee Howard <l...@asgard.org> wrote: > > > > On 02/27/2018 12:52 PM, Aaron Gould wrote: >> Thanks >> >> >> For #2 – what if the ports allocated aren’t enough for the amount of inet >> traffic the customer site uses ? …is the customer denied service based on >> insufficient port range ? …or are they assigned another block within that >> some ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take >> that before there aren’t anymore port blocks left on that single ip ? …and >> if you have to allocate that customer another port block from a *different* >> ip, then we are in the situation of the bank website not liking the fact >> that the session is bouncing to a different ip maybe ? > > > Yes, common problem, and the session just fails (TCY SYN dropped) because of > insufficient ports. > Most CGNs allow you to configure a range of ports for a customer, and reserve > an additional range if they need more ports. Yes, if you allocate 1000 ports > for one IPv4 address to each of 50 customers and they all need hundreds more > ports than that, you're going to run out of ports and connections fail. > > This is why you have IPv6. Even while many web sites and apps don't support > IPv4, enough do that it relieves some pressure on your CGN. > > Lee >> >> - Aaron >> >> >> From: Michael Crapse [mailto:mich...@wi-fiber.io] >> Sent: Tuesday, February 27, 2018 11:19 AM >> To: Mike Hammett >> Cc: Aaron Gould; NANOG list >> Subject: Re: cgnat - how do you handle customer issues >> >> >> For number 2, I'm a fan of what mike suggests. I believe the technical term >> is MAP-T. >> For number 1, anyone who wants one, gets one. We provide free public static >> IP to any customer who asks for one. Another solution, using above solution >> is to ask them which ports they need, and forward those to them using a port >> within their assign range. i.e. teach them how to access their home web >> server using a different port(say 32424, or similar). This won't solve all >> the issues, which is why we use solution 1. >> >> >> On 27 February 2018 at 09:32, Mike Hammett <na...@ics-il.net> wrote: >> >> I'm a fan of nailing each customer IP to a particular range of ports on a >> given public IP. Real easy to track who did what and to prevent shifting IPs. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> >> Midwest Internet Exchange >> >> The Brothers WISP >> >> ----- Original Message ----- >> >> From: "Aaron Gould" <aar...@gvtc.com> >> To: Nanog@nanog.org >> Sent: Tuesday, February 27, 2018 10:30:21 AM >> Subject: cgnat - how do you handle customer issues >> >> >> Couple questions please. When you put thousands of customers behind a cgnat >> boundary, how do you all handle customer complaints about the following. >> >> >> >> 1 - for external connectivity to the customers premise devices, not being >> able to access web servers, web cameras, etc, in their premises? >> >> >> >> 2 - from the premise natted device, when customers go to a university or >> bank web site, how do you handle randomly changing ip addresses/ports that >> may occur due to idle time and session tear-down in nat table such that the >> bank website has issues with seeing your session ip change? >> >> >> >> >> >> -Aaron >> >> >> >> >>
