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
>> 
>> 
>> 
>>  
>> 

Reply via email to