Routing

Hello,

I am required to implement CGNAT on Juniper MX-960 using MS-MPC. At the CGNAT best practice documentation it says that Pool should not exceed 256 i.e /24 subnet. But I have the following IP ranges.

Public IPs = more than 4000

Private IPs(subscribers)= 5000 and increasing.

Requird to do 1:2 napt

please not the configuration below:

 "Removed"

The problem I encountered last time was that some subscribers were facing more than 2000ms latency, and as a result slow Internet browsing.

Should i brake the public pool size to /24 network to follow the best practice scenario. and 1:2 would mean 64K/2 = 32K ports available with private pool /23 and public pool /24.

Hello,

MS-MPC NPU has 15M session scale so the max practical NAPT44 pool size PER NPU & WITHOUT PBA would be 15M/64512 = 233 public IP.

With PBA, this is calculated differently: ceiling(64512 / ${PBA block size, typical max 2016} ) = 32, this is number of PBA blocks per public IP. So, for 4K users  You need 4000/32=125 public IP across all pools. 

But You have gigantic PBA block sizes which is behaving NOT really different from basic-NAT44 without PAT.

Further comments below.

---

@Mannan wrote:

 

 

user@BNG-MX96-1-re0# show interfaces xe-0/2/0                    
description mx960-router;
unit 0 {
    family inet {
        service {
            input {
                service-set sp000;
            }
            output {
                service-set sp000;
            }
        }
        address 203.0.113.186/30;
    }
}

 

   

 

---

All traffic going across this interface will be directed to MS-MPC, You need to set up service-filters to allow only "interested" traffic to go there.

---

@Mannan wrote:

Hello,

 

 

 

nat {
    pool NAT_Pool_VALID_USER-01 {
        address 198.15.0.0/21;
        port {
            automatic;
            secured-port-block-allocation block-size 32768 max-blocks-per-address 1 active-block-timeout 0;
        }
        address-allocation round-robin;
        snmp-trap-thresholds {
            address-port low 75 high 95;
        }
    }

 

   

 

---

This pool has 8*256-2=2046 useable public IP (first and last won't be used.

This pool also has 2046 useable port blocks : with PBA, first usable port is 1024 and last 65535, and block of 32768 ports can fit only once into 65535-1023=64512 space. Please decrease the block size to sensible level, like 2K-8K ports. Or use basic-NAT44 without PAT, the users will have better experience with basic NAT-44 rather than with such PBA config.

If You absolutely require such config because of [whatever], make sure no more than 2046 unique private IPs are mapped into this pool. Which is not the case at the moment:

---

@Mannan wrote:

 

 

    rule sp000 {
        match-direction output;
        term NAT_ALG_1 {
            from {
                source-address {
                    172.25.0.0/20; ## 4096 IPs
                }
            }
            then {
                translated {
                    source-pool NAT_Pool_VALID_USER-01;## only 2046 blocks
                    translation-type {
                        napt-44;
                    }
                    address-pooling paired;
                }
                syslog;
            }
        }
  
    service-domain outside;
}

 

 

   

 

---

 Hope this makes sense.

HTH

Thx

Alex

Thanks for your insight into this Alex, I haven't been able to login due to site maintenance and for some reason my account also got reset, So I am finally here.

Pease note that these port calculations were made based on the CGNAT day one guide.

I now enderstand the problem with the port block size of 32768.

I would like to make one correction to my posted configuration. 

 PBA size of 32254 was used and not 32768.

Actually the purpose of one ration two is to save public IPs, the requirment is that one public be used against two private IPs, and thus achieving 1:2 combination.

The primary focus is that we do not want a public IP to be alloted to more than two subscrubers.

The posted configuration was done keeping in mind that unused port sessions/states will not occupy the system resourses unless utilized by subscribers. But if this is not the actual case then I may have to use port range command to to give limited ports (lets say 8K) and set the PBA size to half of that (4K) so that 1:2 is achieved. 

Would you like to add anyting to this?

Thanks,

Kind Regards,

Mannan

Hello,

I suggest You consider Deterministic NAT where Your private-to-public IP ratio will be exactly 2:1, and "free port block hunting" inherent to PBA is eliminated.

https://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/nat-deterministic-port-block-allocation.html

HTH

Thx

Alex

 Hi,

After going over the details about deterministic port allocation, i see that the only advantage is that Junos allocated ports When a block-size of 0 is specified, block size is calculated according to the formula:(64512 * Number of IP addresses in the NAT Pool) / Number of subscribers.

If we have 2046 public IPs and about 5000 subscribers, wouldn't that mean 64512*2046/5000 = 26399 ports per IP, which is alot.

By not specifying 0 but instead a certain # for block size, how would this be different from sequential port block allocation.

I am studying the adaptive layer services document in detial regarding deterministic port allocation, there are more variables to consider that are mentioned there, I will get back to you when I am done.

THNX

MANNAN

Hello there,

---

@Mannan wrote:

 Hi,

 

 

 

By not specifying 0 but instead a certain # for block size, how would this be different from sequential port block allocation.

 

 

---

There is a slight difference only in block-size because You inputted 5000 users versus 4096 users covered by 172.25.0.0/20 prefix (when used in PBA).

The allocation of PBA block to a newly seen private IP is done as follows:

- if "address-allocation round-robin" is configured, JUNOS picks a public IP from mapped pool at random and searches for a free block from the port 1024 upwards

- if there is a free block in that public IP, allocation is done

- if there are no free blocks in that public IP, another random public IP is picked and process repeats until free block is found.

- because of the requirement to have 2:1 private-to-public mapping, You have to use 2 gigantic blocks per public IP.

- this means if both blocks in public IP are taken, JUNOS potentially has to do a lot of random picks to find a free block especially at busy times when ratio of ACTIVE users to public IP approaches 2:1. This contributes to the latency as perceived by user.

- now, if You don't have "address-allocation round-robin", JUNOS simply does sequenial search for a free block initially from 1st public IP port 1024 upwards.

- all subsequent searches are done from where the previous search stopped.

- with time, blocks are allocated & released what looks like a completely random pattern, so again, JUNOS potentially has to do a lot of sequential searches until a free block is found especially at busy times when ratio of ACTIVE users to public IP approaches 2:1. This contributes to the latency as perceived by user.

- with Deterministic NAT, the free block searches are completely gone.

- what is left is only a free port search within the given block.

Hope this makes sense.

HTH

Thx
Alex 

Hi Alex,

Sorry to get back to you after so long. Last month I implemented CGNAT using the deterministic approach, and it worked like a charm, No Issues whatsoever. Thank you for your expert openion.

Regards,

Mannan Ahmed Abbasi

CCIE-SP, JNCIS-SP