This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
xxxxxxxxxx
{{tag>Services "Service 11" NAT CG-NAT}}
====== Settings and management ======
{{indexmenu_n>2}}
This service is managed at the separate subscriber level using ''[[en:dpi:dpi_components:platform:subscriber_management:subsman_cmd|fdpi_ctrl]]''.
Command format:
<code bash>fdpi_ctrl command --service 11 [options list] [IP_list or login]</code>
The command syntax and ways of setting IP addresses are described in [[en:dpi:dpi_components:platform:subscriber_management:subsman_cmd|the Management of policing and services]] section.
<note important>Activation of address translation for subscribers is carried out with service 11.</note>
===== CG-NAT=====
Create named profile that defines CGNAT IP pool parameters:
<code bash>fdpi_ctrl load profile --service 11 --profile.name test_nat --profile.json '{ "nat_ip_pool" : "5.200.43.0/24,5.200.44.128/25", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000 }'</code>
A description of the parameters can be found in the [[en:dpi:opt_cgnat:сgnat_settings#parameters_and_possible_values|table]] below.
<note important>In case a ''login'' is bound to several IPs, the session counter is separate for each IP address.</note>
<note>When specifying a range of external IP addresses, you can specify one or more ranges separated by commas; [[en:dpi:faq:cgnat|also you can dynamically add additional ranges to a previously created pool]].\\
You can exclude reserved addresses from the range (according to the classless addressing convention, these are gateway and broadcast addresses) by adding the "~" symbol to the range definition at the end of the ''cidr'' definition, for example ''5.200.43.0/24~''.</note>
===== NAT 1:1 =====
Create profile for service NAT 1:1((:!: operators sometimes use broadcast 1:1 as an alternative to routing white IPs to subscriber CPEs, but it is important to understand that although this scheme simplifies administration a bit, it is unequal both from the subscriber's point of view, who usually pays money for the white address service, and from the network point of view, as some client software knows about private addresses and behaves differently than in the case of public addresses, for example, messengers WhatsApp/Viber/Skype/SIP instead of direct P2P connections start using stun-proxy servers, which are often overloaded, which can seriously degrade the quality of voice and video calls, IPSEC VPN without NAT-T support or with certificate authorization does not work, a subscriber cannot use his public IPv4 as an IPv6 address through the mechanism [[https://en.wikipedia.org/wiki/6to4|6to4]], autodetection of local tracker stops working in torrents, trackers often give less number of peers to subscribers with gray addresses, which affects download speed, etc. For L2-connected subscribers the best alternative to NAT1:1 is to use unnumbered addresses, which are natively supported by SSG BRAS. Besides, when moving to IPv6/Dual Stack, the operator will still have to learn how to route public IPv6 addresses)), where specify the range of IP addresses within the pool:
<code bash>