Differences

This shows you the differences between two versions of the page.

--- en:dpi:faq:cgnat:start [2024/09/04 07:30] – elena.krasnobryzh
+++ en:dpi:faq:cgnat:start [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== CG-NAT and NAT (Service 11)======
-{{indexmenu_n>4}}
-<note>[[en:dpi:opt_cgnat:start|Product Description]]</note>
-<accordion autoclose>
-<accordion-item title="1. Why is it Recommended to Create a Pool of at Least 2 or 4 Addresses?">
-The non-blocking dispatch algorithm in DPI, which distributes sessions across worker threads, imposes a limitation on which public IP address can be assigned to a subscriber from the pool:
-  - To ensure that a subscriber receives their designated public address, the pool must contain at least as many addresses as there are worker threads (typically 2 for SSG-6 and 4 for SSG-10 and higher). You can determine the number of worker threads with the command <code bash>expr $(ps -p `pidof fastdpi` H -o comm | grep wrk | wc -l) / $(ps -p `pidof fastdpi` H -o comm | grep rx | wc -l)</code>
-  - If the pool contains only one address, it may not be assigned to all subscribers but only to those who fit the load balancing algorithm.
-</accordion-item>
-<accordion-item title="2. How to Determine Which Public Address from the Pool a Subscriber Will Get?">
-You can see which public address has been assigned to a private one with the command <code bash>fdpi_ctrl list status --service 11 --ip 192.168.4.20</code>. In NAT 1:1, the public address is allocated immediately upon service assignment; in CG-NAT, it is allocated at the start of the session. The assigned public address is also reported in Radius Accounting for billing logging purposes.
-Predicting the exact address that will be assigned to a subscriber from the pool in advance is impossible; it depends on various factors, particularly the current pool load.
-</accordion-item>
-<accordion-item title="3. Inactive SSH Sessions are Closed After Enabling NAT">
-<note>Parameter descriptions [[dpi:opt_cgnat:сgnat_settings:start#параметры_и_возможные_значения|at this link]]</note>
-Indeed, the session lifetime in NAT is limited because the number of sessions per subscriber is a limited resource, and a large number of inactive sessions in the pool reduces NAT and overall performance.
-NAT cannot distinguish whether a session became inactive due to an accident or simply because there is no activity, and it closes such long-hanging sessions by inactivity timeout. This behavior is standard and supported by most CG-NAT manufacturers.
-In SSG, session lifetimes can be adjusted with the following parameters:
-  * ''lifetime_flow_long=600'' — lifetime in seconds of inactive TCP sessions
-  * ''lifetime_flow=60'' — lifetime in seconds of other sessions
-<note warning>These parameters should not be set to excessively large values, as the session table may grow too large, impacting CG-NAT performance, and the subscriber may run out of session limits (set in the nat pool parameters).</note>
-To maintain long inactive connections, it is recommended to use the ''tcp keep-alive'' mechanism, where an empty packet is periodically sent in the session, signaling that the session is still active.
-You can configure ''tcp keep-alive'' both individually for the application on the server or client side and at the operating system level for all applications.
-**Example** configuration on the ssh server: add the line to the ''/etc/ssh/ssh_config'' file:
-<code bash>
-ServerAliveInterval 60
-</code>
-**Example** configuration on the ssh client: add the lines to the ''~/.ssh/config'' file:
-<code bash>
-Host *
-  ServerAliveInterval 60
-</code>
-or in the command line:
-<code bash>
-ssh -o TCPKeepAlive=yes -o ServerAliveInterval=60 user@example.com
-</code>
-**Example** configuration for all applications in CentOS: add the lines to the ''/etc/sysctl.conf'' file:
-<code bash>
-net.ipv4.tcp_keepalive_time = 600
-net.ipv4.tcp_keepalive_intvl = 60
-net.ipv4.tcp_keepalive_probes = 20
-</code>
-</accordion-item>
-<accordion-item title="4. How Many Private IP Addresses Can Be Hidden Behind One Public IP in CG-NAT?">
-<note important>It is recommended to maintain a ratio from 1:10 (better) to 1:100 (worse).</note>
-Details:
-By default, 64512 ports (65535-1023, as the first 1024 ports are not used because they are system ports) are available for CG-NAT on one public IP. Each port represents one TCP session and one UDP. The number of sessions created by subscribers varies: individuals create fewer sessions, while corporate users create more (thus, corporate users should use a separate pool with different session limits). A subscriber with torrents can create up to 1000 sessions at peak.
-On average, an individual creates 50-60 simultaneous sessions, meaning 64512/60=1075 individuals can be hidden behind one private IP. However, such significant oversubscription is not recommended in practice, as many popular services (mail, video, search) use IP address-based botnet attack protection. If too many requests come from one address, they may be considered an attack and block some requests or enable captcha, causing inconvenience to subscribers.
-Also, consider the feature of port release mechanism in the NAT Pool:
-  - When Service 11 is enabled for a subscriber, [[dpi:faq:cgnat:start#how_to_determine_which_public_address_from_the_pool_a_subscriber_will_get|a Public IP is assigned based on the distribution algorithm]]
-  - When a subscriber starts establishing sessions, ports are taken from the common SSG DPI queue and [[dpi:faq:cgnat:start#inactive_ssh_sessions_are_closed_after_enabling_nat|assigned with certain timeouts]]
-  - If a specific Public IP has many subscribers competing for free ports, subscribers may experience access issues.
-Recommendations for creating and operating NAT Pools:
-  - Subscribers under blocking (Service 5 + policing) should be placed in a separate NAT Pool to avoid impacting active subscribers. For instance, an iPhone may establish many sessions searching for an active service.
-  - Create sparse pools and separate clients into different NAT Pools by type: individuals and corporate users.
-  - Monitor clients generating high load and work with them. For receiving, processing, and storing NetFlow from DPI, we suggest using the [[dpi:dpi_components:qoestor:start|QoE Store software product for statistics collection]] and the [[dpi:dpi_components:dpiui:start|DPIUI2 graphical interface]]. You can analyze subscriber traffic and conclude that their PC is infected.
-</accordion-item>
-<accordion-item title="5. How to Change the Parameters of an Existing and Used Pool?">
-<note>Parameter descriptions [[dpi:opt_cgnat:сgnat_settings:start#параметры_и_возможные_значения|at this link]]</note>
-  - Changing the session limit:<code bash>fdpi_ctrl load profile --service 11 --profile.name test_nat_2000 --profile.json '{ "nat_ip_pool" : "111.111.111.0/24", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000, "nat_type" : 0 }'</code>Use the pool creation command identical to the previous one but with different ''nat_tcp_max_sessions'' and ''nat_udp_max_sessions'' settings.
-  - Adding additional addresses to the pool:<code bash>fdpi_ctrl load profile --service 11 --profile.name test_nat_2000 --profile.json '{ "nat_ip_pool" : "111.111.111.0/24,222.222.222.0/25", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000, "nat_type" : 0 }'</code>Use the pool creation command identical to the previous one but with an additional pool specified by a comma.
-  - Reducing the pool
-<note important>The current version does not support dynamic pool size reduction and address exclusion.
-In this case, you will need to free the pool, delete it, and create it with new parameters.</note>
-For convenience, install jq (a utility for working with JSON data):
-<code bash>
-yum install epel-release yum-utils
-yum-config-manager --disable epel
-yum --enablerepo epel install jq
-</code>
-Then save the information about the subscribers of the current pool, delete and recreate the pool, and reconnect the subscribers:
-<code bash>
-fdpi_ctrl list all --service 11 --profile.name test_nat_4000 --outformat json | jq '.lservices[] | .login | select(. != null)' > save_users.txt
-fdpi_ctrl list all --service 11 --profile.name test_nat_4000 --outformat json | jq -r '.lservices[] | .ipv4 | select(. != null)' >> save_users.txt
-fdpi_ctrl del all --service 11 --profile.name test_nat_4000
-fdpi_ctrl del profile --service 11 --profile.name test_nat_4000
-fdpi_ctrl load profile --service 11 --profile.name test_nat_4000 --profile.json '{ "nat_ip_pool" : "111.111.111.0/30", "nat_tcp_max_sessions" : 4000, "nat_udp_max_sessions" : 4000, "nat_type" : 0 }'
-fdpi_ctrl load --service 11 --profile.name test_nat_4000 --file save_users.txt
-</code>
-Do not forget to change the pool name and its new parameters in the commands to the ones you need.
-</accordion-item>
-<accordion-item title="6. How to Assign a Specific Address to a Subscriber with NAT 1:1?">
-If a subscriber has only one private address and it is necessary to assign a specific public address to the subscriber, the dependency between the private and public addresses must be considered, which is imposed by the non-blocking address dispatching algorithm in DPI.
-<code>subscriber_public_address & mask = subscriber_private_address & mask</code>
-where the mask depends on the number of working threads:
-  * with 4 working threads, mask=3 (typical for SSG >= 10)
-  * with 2 working threads, mask=1 (typical for SSG <= 6)
-In fact, for older versions of SSG, subscribers with even private addresses should be assigned even public addresses, and subscribers with odd private addresses should be assigned odd public addresses. Only the last byte NNN in the IP address XXX.YYY.ZZZ.NNN needs to be considered.
-Accordingly, for newer versions, the equality of the 2 least significant bits of the IP address should be considered.
-With one working thread, the dependency between the addresses disappears.
-The exact mask value can be found in the DPI log:
-<code>grep nat_hash_mask /var/log/dpi/fastdpi_alert.log</code>
-If the service has been running for a long time, perform a reload:
-<code>service fastdpi reload</code>
-<note important>Thus, this partially deterministic distribution scheme essentially assumes that private addresses will also be statically assigned to the subscriber. In cases where a specific public IP address is specified in the contract and the current private address of the subscriber does not fit the formula mentioned above, it will be necessary to change the subscriber's private address to one that matches the formula.</note>
-**Example for SSG-20:**
-A subscriber with a private address of 10.0.0.15 needs to be assigned a public address of 188.99.99.27\\
-mask=3\\
-&3=3 equals 27&3=3 - this means that the address can be assigned (otherwise, either the private address assigned to the subscriber or the public address intended for the subscriber would need to be changed).
-**Assign the address to the subscriber with the command:**
-<code>fdpi_ctrl load profile --ip 10.0.0.15 --service 11 --profile.json '{ "nat_ip_pool" : "188.99.99.27/32", "nat_type" : 1 }'</code>
-<note>Parameter description [[dpi:opt_cgnat:cgnat_settings:start#parameters_and_possible_values|via this link]]</note>
-</accordion-item>
-<accordion-item title="7. NAT Diagnostics">
-<note>Parameter description [[dpi:opt_cgnat:cgnat_settings:start#parameters_and_possible_values|via this link]]</note>
-. The pools in the profile must be of the same size ((The requirement is not relevant if ''rx_dispatcher=1'' or ''rx_dispatcher=2'')).
-Correct:
-<code>
-type_profile=1, ref_cnt=0       d3      { "nat_ip_pool" : "1.1.2.0/28,1.1.3.0/28", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000, "nat_type" : 0 }            11      (0x400)
-</code>
-Incorrect:
-<code>
-type_profile=1, ref_cnt=0       d3      { "nat_ip_pool" : "1.1.2.0/28,1.1.3.0/26", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000, "nat_type" : 0 }            11      (0x400)
-</code>
-. For subscribers who are blocked, a different profile with different pools should be applied. Many network devices, when blocked, can generate a large number of requests, leading to the consumption of free ports on the public address.
-. Check the uniformity of the distribution of private addresses across public addresses in the profile.
-<code>
-fdpi_ctrl list all status --service 11 --profile.name nat_pool |grep whiteip|cut -f7|sort|uniq -c|sort -n
-</code>
-. Check the number of subscribers using ports beyond the value of the $P variable. On average, a subscriber uses about 600 ports.
-<code>
-fdpi_ctrl list all status --service 11 --profile.name nat_pool | awk 'BEGIN {FS="[=| }\t]+"}  $15>$P {print $1, $14, $15}' | wc -l
-</code>
-. Check how the addresses are distributed across pools (subnets) in the profile.
-<code>
-fdpi_ctrl list all status --service 11 --profile.name nat_pool |grep whiteip|cut -f7|cut -d"." -f1,2,3|sort|uniq -c|sort -n
-</code>
-</accordion-item>
-</accordion>

Profile

Settings

Differences