NAT Overview
This section
provides an overview of the NAT in-line service feature.
NAT translates non-routable
private IP address(es) to routable public IP address(es) from a
pool of public IP addresses that have been designated for NAT. This enables
to conserve on the number of public IP addresses required to communicate
with external networks, and ensures security as the IP address scheme
for the internal network is masked from external hosts, and each
outgoing and incoming packet goes through the translation process.
The
NAT in-line service works in conjunction with the following products:
NAT works by inspecting
both incoming and outgoing IP datagrams and, as needed, modifying
the source IP address and port number in the IP header to reflect
the configured NAT address mapping for outgoing datagrams. The reverse
NAT translation is applied to incoming datagrams.
NAT can be used to perform
address translation for simple IP and mobile IP. NAT can be selectively
applied/denied to different flows (5-tuple connections)
originating from subscribers based on the flows' L3/L4
characteristics—Source-IP, Source-Port, Destination-IP,
Destination-Port, and Protocol.
IMPORTANT:
IMPORTANT:
NAT is supported only
for TCP, UDP, and ICMP flows. For other flows NAT is bypassed. For
GRE flows, NAT is supported only if the PPTP ALG is configured.
For more information on ALGs, please refer to the NAT Application Level
Gateway section.
IMPORTANT:
IMPORTANT:
To get NATed, the private
IP addresses assigned to subscribers must be from the following ranges:
Class A 10.0.0.0 – 10.255.255.255, Class B 172.16.0.0 – 172.31.255.255,
and Class C 192.168.0.0 – 192.168.255.255
NAT supports the following
mappings:
Once a flow is marked
to use a specific NAT IP address the same NAT IP address is used
for all packets originating on that flow. The NAT IP address is
released only when all flows and subscribers associated with it
are released.
When all NAT IP addresses
are in use, and a subscriber with a private IP address fails to
get a NAT IP address for a specific flow, that specific flow will
not be allowed and will fail.
All downlink—inbound
from external networks—IP packets that do not match one
of the existing NAT bindings are discarded by the system.
Platform Requirements
The NAT in-line service
runs on a Cisco® ASR 5x00 chassis running StarOS. The chassis
can be configured with a variety of components to meet specific network
deployment requirements. For additional information, refer to the
Installation Guide for the chassis and/or contact your
Cisco account representative.
License Requirements
The NAT is a licensed
Cisco feature. A separate feature license may be required. Contact
your Cisco account representative for detailed information on specific licensing
requirements. For information on installing and verifying licenses,
refer to the Managing
License Keys section of the Software Management
Operations chapter in the System
Administration Guide.
NAT Realms
A NAT realm is a pool
of unique public IP addresses available for translation from private
source IP addresses. IP addresses in a NAT IP pool are contiguous,
and assignable as a subnet or a range that constitutes less than
an entire subnet. IP addresses configured in NAT IP pools within
a context must not overlap. At any time, within a context, a NAT
IP address must be configured in any one NAT IP pool. IP addresses
can be added to a NAT IP pool as a range of IP addresses. Based on the chosen
port chunk-size, the number of subscribers that can shared per IP
varies.
IMPORTANT:
The minimum number of
public IP addresses that must be allocated to each NAT IP pool must
be greater than or equal to the number of Session Managers (SessMgrs)
available on the system. On the ASR 5x00, it is >= 84 public
IP addresses. This can be met by a range of 84 host addresses from
a single Class C. The remaining space from the Class C can be used
for other allocations. Each address has available its port range
~64K ports.
Up to 2000 unique “IP
pools + NAT IP pools” can be configured per context.
A maximum of three NAT IP pools/NAT
IP pool groups can be configured in a Firewall-and-NAT policy.
At any time a subscriber can be associated with a maximum of three
different NAT IP pools/NAT
IP pool groups and can have NATed flows on three different
NAT IP addresses at the same time.
Allocation of NAT IP
addresses in NAT IP pools to subscriber traffic is based on the
L3/L4 characteristics—IP addresses, ports, and
protocol—of the subscriber flows. It is possible to configure
the system to perform or not perform NAT based on one or more L3/L4
parameters. This feature is also known as Target-based NAT. For
more information, see the Target-based NAT Configuration section.
The following table
lists the miminum requirements for configuring NAT pools.
| Card Type | No. of SMGRs | No. of NAT Translations per SMGR | No. of Active Cards | Total no. of NAT Translations | ||
|---|---|---|---|---|---|---|
|
PSC
|
7
|
317000
|
12
|
26628000 (26.628M)
|
||
|
PSC2
|
16
|
270000
|
12
|
51840000 (51.84M)
|
||
|
PSC3
|
24
|
400000
|
12
|
115200000(115.2M)
|
||
NAT IP pools have the
following configurable parameters. These parameters are applicable to
all IP addresses in a NAT IP pool.
-
NAT IP Address Allocation Mode: Specifies when to allocate a NAT IP address to a subscriber; either at call setup or during data flow based on the allocation mode.
-
Not-on-demand Allocation Mode: This is the default mode. In this mode, the NAT IP address is allocated to the subscriber at call setup. If there are three NAT IP pools/NAT IP pool groups (maximum possible) configured in the subscriber’s Firewall-and-NAT policy, the subscriber is allocated three NAT IP addresses, one from each NAT IP pool/NAT IP pool group based on rule matching.
-
On-demand Allocation Mode: In this mode NAT resources are assigned and allocated dynamically based on subscriber flows. The NAT IP address is allocated to the subscriber when the data traffic flows in and not at call setup.In case of on-demand pools, since the NAT IP address is not allocated to the subscriber at call setup, the subscriber may not have a NAT IP address allocated when the first packet is received. Until the successful allocation of a NAT IP address, based on the configuration, the packets can either be buffered or dropped. Once a free NAT IP address is available, it is allocated to the subscriber to be used for flows matching the pool.
-
-
NAT Binding Timer: Specifies the timeout period, in seconds, to deallocate NAT resources that were allocated to subscriber flows. When a subscriber flow stops the timer starts counting down, and on expiry the NAT resources are deallocated to be made available for other subscriber flows.
-
In many-to-one allocation, wherein subscribers are allocated port-chunks rather than individual ports, as long as a port-chunk is allocated to a subscriber, all ports from that port-chunk are reserved for that subscriber. When all flows using ports from that port-chunk get timed out/cleared, the NAT Binding Timer starts counting down. If any new flows come up before the NAT Binding Timer expires, ports are once again allocated from that port-chunk, and the NAT Binding Timer gets cancelled. As long as there are active flows using the port-chunk it cannot be deallocated. But, if no new flows come and the NAT Binding Timer expires, the port-chunk gets deallocated. In the case of on-demand NAT, if it is the last port-chunk for the NAT IP address, on NAT Binding Timer expiry, the NAT IP address gets deallocated along with the last port-chunk.
-
Maximum Port-chunks per User: Applicable only to many-to-one NAT IP pools. Specifies the maximum number of port-chunks allowed for an individual subscriber from the same NAT IP address. This will limit subscribers from dominating all the available ports in a many-to-one NAT IP. A maximum of 2016 port-chunks can be configured per subscriber.Consider a case where a single TCP flow is active in a port-chunk. When this connection gets cleared, the TCP NAT port goes to Time Wait state. Since it is the last flow of the port-chunk, the NAT Binding Timer also gets started. Assume NAT Binding Timer >= TCP 2MSL Timer. Once the 2MSL Timer expires, the TCP port would go to Free state. However, the NAT Binding Timer keeps running. On NAT Binding Timer expiry, the port-chunk is deallocated. If this was the last port-chunk for that subscriber, the NAT IP address is also deallocated along with this port-chunk.
NAT IP Pool Groups
Similar NAT IP pools
can be grouped into NAT IP pool groups. This enables to bind discontinuous
IP address blocks in individual NAT IP pools to a single NAT IP pool
group.
When configuring a
NAT IP pool group, note that only those NAT IP pools that have similar characteristics
can be grouped together. The similarity is determined by the NAT
IP pool Type (One-to-One / Many-to-One), users configured
per NAT IP address (applicable only to many-to-one NAT IP pools),
NAT IP Address Allocation Mode (On-demand/Not-on-demand),
and Port Chunk Size (applicable only to many-to-one NAT IP pools)
parameters. Dissimilar NAT IP pools cannot be grouped together.
It is recommended that
all the NAT IP pools in a NAT IP pool group be configured with the same
values for the other parameters, so that the NAT behavior is predictable
across all NAT IP pools in that NAT IP pool group.
The NAT IP pool from
which a NAT IP address is assigned will determine the actual values to
use for all parameters.
It is recommended that
in a Firewall-and-NAT policy all the realms configured either be NAT
IP pools or NAT IP pool groups. If both NAT IP pool(s) and NAT IP
pool group(s) are configured, ensure that none of the NAT IP pool(s)
are also included in the NAT IP pool group.
NAT IP Address Allocation and Deallocation
Cisco System’s
implementation of NAPT is Endpoint-independent Mapping, wherein
NAT reuses the same NAT source port mapping for subsequent packets
sent from the same private IP address and port, and with the same
protocol to any public destination host IP address and port.
That is, all flows
coming from the subscriber for the current session with the same
protocol and same source IP address and source port (X:x) would
get the same NAT IP address and NAT port (X:x) irrespective of the
destination IP address and port. NAT will not allow any inbound packets
to the NAT IP address and NAT port (X:x) from an external host IP
address and host port (Y:y), unless the internal host (MS) had previously
sent a packet of the same protocol type to that external IP address
and Port (Y:y). However, this behavior changes if NAT ALG is enabled.
The ALG creates pin holes / dynamic routes in the NAT and
allows downlink packets that match the pin holes / dynamic
routes towards the internal host (MS) given that there was already
a parent connection from MS towards the external host.
The advantage of endpoint-independent
mapping is that applications are unaffected by NAT translations.
Inbound connection
to the NAT IP address can be allowed in one-to-one pools based on configuration.
NAT IP Address Allocation
The NAT IP address
is allocated based on the following parameters:
-
Port-chunk Thresholds: The threshold is configured in percentage of total number of port-chunks. If the number of port-chunks already allocated from a given NAT IP address is less than the configured threshold limit of port-chunks, then the NAT IP address can be chosen for a new subscriber provided the “Maximum Users per NAT IP Address” is not reached. But if the number of chunks allocated is greater than or equal to the threshold limit of port-chunks, then the NAT IP address will not be chosen for a new subscriber. The remaining free port-chunks will be used for existing subscribers using the NAT IP address.
NAT Port-chunk Allocation and Deallocation
This section
describes the Port-chunk Allocation and Deallocation feature for
many-to-one NAT.
NAT Port-chunk Allocation
Subscribers sharing
a NAT IP address are allocated NAT ports in chunks. The ports in
a port-chunk are always used for the subscriber to whom that port-chunk
is allocated irrespective of the protocol.
Whenever a NAT IP address
gets allocated to a subscriber, the first port-chunk gets allocated
along with the NAT IP address. Thus, for not-on-demand pools, the
first port-chunk gets allocated during call setup, and for on-demand
pools during data flow.
A subscriber’s
TCP and UDP data traffic is NATed with ports chosen in a random
fashion from the port-chunk allocated to that subscriber. For other
protocol traffic, the first available port is allocated. When all
the ports in a port-chunk are in use, a free port-chunk is requested
for. A new port-chunk is only allocated if the “Maximum
Port-chunks Per User” limit is not reached.
NAT Port-chunk Deallocation
NAT Binding Timer
When all flows
using ports from a particular port-chunk get timed out/cleared,
the port-chunk gets freed. When the last port of that port-chunk
gets freed, the NAT Binding Timer starts counting. Before the NAT
Binding Timer expires, if any new flows come up, ports are reallocated
from the port-chunk, and the timer gets cancelled. The port-chunk
cannot be deallocated as long as there are active flows using that port-chunk.
But, if no new flows come and the NAT Binding Timer expires, the
port-chunk gets deallocated.
In case of not-on-demand
pools, the additional port-chunks that were allocated on demand
will be deallocated based on the NAT binding timeout. However, the last
port-chunk will not be deallocated even after the Binding Timer
expires. This last port-chunk will only be deallocated when the
NAT IP address is deallocated from the subscriber.
In case of on-demand
pools, the port-chunks are deallocated based on the NAT binding timeout.
When the last port-chunk gets freed, the NAT IP address also gets
deallocated from the subscriber.
It is ensured that
a port-chunk is associated with the subscriber as long as a valid
NAT IP address is allocated to the subscriber.
TCP 2MSL Timer
NAT does port
management only for many-to-one pools. Hence, The TCP 2MSL timer
is only available for many-to-one NAT. It is necessary to ensure
that a TCP NAT port in Time Wait state is not reused if there are
other free ports available for the subscriber. If such a reuse happens,
then there is a possibility that connections might get terminated
by the server. To avoid such issues, whenever a many-to-one NAT
TCP flow gets cleared, the NAT port goes to Time Wait state (2MSL
started for that port). Once 2MSL timer expires, the NAT port becomes
usable. The 2MSL timer is started for every TCP NAT port as soon
as the TCP connection gets cleared. This ensures that a NAT TCP
port gets reused only after expiry of the configured TCP 2MSL timer.
Consider a case where
a single TCP flow is active in a port-chunk. When this connection
gets cleared, the TCP NAT port goes to Time Wait state. Since this
is the last flow of the port-chunk, the NAT Binding Timer also gets
started. Assume NAT Binding timer >= TCP 2MSL timer. Once
the 2MSL timer expires, the TCP port becomes usable. However, the NAT
Binding Timer keeps counting, and on expiry, the port-chunk is released.
In case the NAT Binding
Timer < TCP 2MSL Timer, on NAT Binding Timer expiry, the TCP port
is forcefully moved to Free State (made usable) from Time Wait state
and the port-chunk released.
Flow Mapping Timer
The Flow Mapping
timer is a new timer implemented as an extension to the existing
idle-timeout in ECS, and is supported only for TCP and UDP flows.
This flow mapping applies only for NAT enabled calls.
The purpose of this
timer is to hold the resources such as NAT IP, NAT port, and Private
IP NPU flow associated with a 5-tuple ECS flow until Mapping timeout expiry.
If the feature is disabled, the Flow mapping timeout will not get
triggered for TCP/UDP idle timed out flows. The resources
such as NAT mapping will be released with the 5-tuple flow itself.
NAT Binding Records
Whenever a NAT
IP address or NAT port-chunk is allocated/deallocated to/from
a subscriber, NAT Binding Records (NBR) can be generated. Generation
of NBRs is configurable in the Firewall-and-NAT policy configuration.
NBRs are supported for
both on-demand and not-on-demand NAT IP pools. For a one-to-one
NAT IP pool, an NBR is generated whenever a NAT IP address is allocated/deallocated
to/from a subscriber. For a many-to-one NAT IP pool, an
NBR is generated when a port-chunk is allocated/deallocated
to/from a subscriber for a NAT IP address. It is also possible
to configure generation of NBRs only when a port-chunk is allocated,
or deallocated, or in both cases.
NBRs can now hold both
IPv4 and IPv6 addresses in case of an IPv4v6 subscriber. If the existing “ip
subscriber-ip-address” is used for IPV4 or IPv4v6 call,
IPv4 address will be generated and IPv6 address will be generated
for IPv6 only call.
The following is the
list of attributes that can be present in NBRs. You can configure
a subset of these attributes or all of them to be logged in NBRs.
If an attribute is not available, while logging records that field
is populated with NULL.
NAT Binding Updates
Whenever a NAT
IP address or NAT port-chunk is allocated/deallocated to/from
a subscriber, to update NAT binding information for that subscriber
in the AAA, a NAT Binding Update (NBU) can be sent to the AAA server.
Since port-chunk allocation/deallocation
happens on a per-call basis, this ensures that AAA messaging is
reduced to a great extent. NBUs are sent to the AAA server in accounting-interim messages.
To send or not to send NBUs to the AAA server is configurable in
the NAT IP pool configuration.
NBUs are supported for
both one-to-one and many-to-one NAT IP pools.
An NBU contains the
following attributes:
CoA NAT Query
If the NAT binding
information is not available at the AAA, the AAA server can query
the chassis for the information. This query uses the Change of Authorization
(CoA) format, wherein the AAA sends a one-to-one NAT IP address
as a query, and in the CoA query response the NBU is obtained if
available at the time of query.
Firewall-and-NAT Policy
Firewall-and-NAT
policies are configured in the CLI Firewall-and-NAT Policy Configuration
Mode. Each policy contains a set of access ruledefs with priorities
and actions, and the NAT configurations. On a system, multiple such
policies can be configured, however at any point of time only one
policy is associated to a subscriber.
IMPORTANT:
In release 8.x, NAT
for CDMA and early UMTS releases used rulebase-based configurations,
whereas in later UMTS releases NAT used policy-based configurations.
In 9.0 and later releases, NAT for UMTS and CDMA releases both use
policy-based configurations. For more information, please contact
your local service representative.
IMPORTANT:
New NAT IP pools/NAT IP pool
groups cannot be added to a policy if the maximum allowed is
already configured in it. However, a pool/pool group can
be removed and then a new one added. When a pool/pool group is
removed and a new one added, the pool/pool group that
was removed will stay associated with the subscriber as long as
the subscriber has active flows using that pool/pool group.
If the subscriber is already associated with three NAT IP pools
(maximum allowed), any new flows from that subscriber for the newly
added pool will be dropped. A deleted pool is disassociated from
the subscriber on termination of all flows from that subscriber
using that pool. The new pool/pool
group is associated with the subscriber only when the subscriber
sends a packet to the newly added pool.
In the Firewall-and-NAT
policy configuration, the NAT44/NAT64 policy
must be enabled. Once NAT is enabled for a subscriber, the NAT IP
address to be used is chosen from the NAT IP pools/NAT IP pool
groups specified in matching access rules configured in the
Firewall-and-NAT policy.
The Firewall-and-NAT
policy used for a subscriber can be changed either from the command
line interface, or through dynamic update of policy name in Diameter
and RADIUS messages. In both the cases, NAT status on the active
call remains unchanged.
The Firewall-and-NAT
policy to be used for a subscriber can be configured in:
-
APN/Subscriber Template: The Firewall-and-NAT policy configured in the APN/subscriber template overrides the default policy configured in the ECS rulebase. To use the default policy configured in the ECS rulebase, in the APN/subscriber configuration, the command to use the default rulebase policy must be configured.
IMPORTANT:
The Firewall-and-NAT
policy received from the AAA and OCS have the same priority. Whichever
comes latest, either from AAA/OCS, is applied.
The Firewall-and-NAT
policy to use can also be received from RADIUS during authentication.
Updating Firewall-and-NAT Policy in Mid-session
The Firewall-and-NAT
policy can be updated mid-session provided the policy was enabled during
call setup. Firewall-and-NAT policy
can also be updated during mid-session rulebase update if the Firewall-and-NAT
policy was previously assigned through rulebase.
IMPORTANT:
When the firewall AVP
contains “disable” during mid-session firewall
policy change, there will be no action taken as the Firewall-and-NAT
policy cannot be disabled dynamically. The policy currently applied
will continue.
IMPORTANT:
In a Firewall-and-NAT
policy, you can change the NAT enabled/disabled status
at any time. However, the updated NAT status will only be applied
to new calls, active calls using that Firewall-and-NAT policy will
remain unaffected.
Target-based NAT Configuration
A NAT IP pool
can be selected based on the L3/L4 characteristics of a
subscriber’s flows. NAT can be configured such that all
subscriber traffic coming towards specific public IP address(es)
always selects a specific NAT IP pool based on the L3/L4
traffic characteristics.
IMPORTANT:
This association is
done with the help of access ruledefs configured in the Firewall-and-NAT policy.
The NAT IP pool/NAT IP address to be used for a subscriber
flow is decided during rule match. When packets match an access
ruledef, NAT is applied using the NAT IP address allocated to the
subscriber from the NAT IP pool/NAT
IP pool group configured in that access ruledef.
If no NAT IP pool/NAT IP pool
group name is configured in the access ruledef matching the
packet, and if there is a NAT IP pool/NAT IP pool
group configured for “no ruledef matches”,
a NAT IP address from the NAT IP pool/NAT IP pool
group configured for “no ruledef matches” is
allocated to the flow.
If no NAT IP pool/NAT IP pool
group is configured for “no ruledef matches” and
if there is a default NAT IP pool/NAT
IP pool group configured in the rulebase, a NAT IP address
from this default NAT IP pool/NAT
IP pool group is allocated to the flow.
If a NAT IP pool/NAT IP pool
group is not configured in any of the above cases, no NAT will
be performed for the flow. Or, if bypass NAT is configured in a
matched access rule or for “no ruledef matches” then
NAT will not be applied even if the default NAT IP pool/NAT IP pool
group is configured. The order of priority is:
When a new NAT IP pool/NAT IP pool
group is added to a Firewall-and-NAT policy, it is associated
with the active subscriber (call) only if that call is associated
with less than three (maximum limit) NAT IP pools/NAT IP pool
groups. If the subscriber is already associated with three
NAT IP pools/NAT IP pool
groups, any new flows referring to the newly added NAT IP pool/NAT IP pool
group will get dropped. The newly added NAT IP pool/NAT IP pool
group is associated to a call only when one of the previously
associated NAT IP pools/NAT
IP pool groups is freed from the call.
NAT Application Level Gateway
Some network
applications exchange IP/port information of the host endpoints
as part of the packet payload. This information is used to create
new flows, by server or client.
As part of NAT ALGs,
the IP/port information is extracted from the payload,
and the flows are allowed dynamically (through pinholes). IP and
port translations are done accordingly. However, the sender application
may not be aware of these translations since these are transparent,
so they insert the private IP or port in the payload as usual.
For example, FTP NAT
ALG interprets “PORT” and “PASV reply” messages,
and NAT translates the same in the payload so that FTP happens transparently
through NAT. This payload-level translation is handled by the NAT
ALG module.
The NAT module will
have multiple NAT ALGs for each individual application or protocol.
Supported NAT ALGs
This release supports
NAT ALGs only for the following protocols:
For NAT ALG processing,
in the rulebase, routing rules must be configured to route packets to
the corresponding analyzers.
This
release now supports session recovery for SIP ALG. Only one contact
pinhole, and only one connected call and its associated media pinholes
will be recovered for a subscriber. Any subscriptions, ongoing transactions,
or unconnected calls will not be recovered. SIP ALG recovery data
will be check-pointed using the variable length micro checkpointing
mechanism.
H323 ALG Support
This release
provides support for H323 ALG that is designed to traverse NAT by
inspecting and altering information contained in existing H323 messages
as they pass through the NAT. It can alter address and port information
in registration, call signaling and automatically open pinholes
in the NAT to allow media flow.
H323 ALG performs the
following functions:
The following supplementary
services are currently supported in H323 ALG:
-
Call Diversion: Call Diversion supplementary service permits a served user to have incoming calls addressed to the served user's number redirected to another number; on busy service, it enables a served user to have calls redirected to another endpoint; on No Answer, it enables a served user to have calls addressed to the served endpoint's number and redirected to another endpoint if the connection is not established within a defined period of time.
NAT Aware H323 Clients
An application
layer gateway, at the Firewall/NAT, examines all the H323
packets and modifies the packet such that all the private addresses
are replaced by public addresses. It also opens all the pinholes
required for successful call establishment. A NAT aware endpoint
establishes end-to-end media session through FW/NAT without
the need of ALG. Any TCP connection or UDP packet sent from the
internal network through the firewall opens a pinhole dynamically
in the firewall. This pinhole allows incoming messages to be sent
from the destination of the TCP connection or the UDP packet. The
pinhole stays open as long as the network sends information through
the pinhole to the same destination.
If an end point supports
NAT traversal, H323 ALG disables itself so that end point directly
opens required pinhole and establishes media path between them.
The ALG will not manage any pinhole for media traversal across Firewall/NAT
for NAT aware clients. By default, the ALG will bypass all the clients
that support H460.18/19 and H460.23/24.
EDRs and UDRs
This section describes
the NAT-specific attributes supported in EDRs and UDRs.
Bulk Statistics
The NAT realms
are configured in a context and statistics are stored per context
per realm. These statistic variables, both cumulative and snapshot,
are available in the nat-realm schema.
Bulkstats are only generated
for the first 100 NAT IP pools from an alphabetical list of all
NAT IP pools, which is based on the context name and pool name. Therefore,
to generate bulkstats for a specific NAT IP pool it must be named
such that it gets selected in the first 100 bulkstats.
The following are cumulative
statistics that can be part of NAT bulkstats:
The following are snapshot
statistics that can be part of NAT bulkstats:
Alarms
Alert threshold
values can be specified to generate alarms for NAT IP pools. To
specify realm-specific threshold limits (pool-used, pool-free, pool-release,
and pool-hold) “alert-threshold” NAT IP pool parameter
can be used, or it can also be specified across context. These thresholds
can be specified to any number of NAT IP pools.
In case of many-to-one
NAT, it is possible to specify port-chunks usage threshold per NAT
IP pool. This threshold value is applicable to all many-to-one NAT
IP pools across the system. However, note that alarms are only generated
for the first 100 many-to-one NAT IP pools from an alphabetical
list of all NAT IP pools.
Session Recovery and ICSR
In session recovery,
as part of the Private IP assigned to the subscriber:
To be recovered the
NAT IP addresses need to be checkpointed. The checkpointing can be:
To recover the bypass
NAT flow, the bypass flow needs to be checkpointed. The checkpointing
of Bypass NAT flow can be:
In case of not-on-demand,
the NAT IP address being used by the subscriber is known after call
setup. This gets checkpointed as part of the normal full checkpoint.
In case of on-demand NAT, the NAT IP address being used by the subscriber
is known only in the data-path. This will be checkpointed as part
of micro checkpoint.
In case of many-to-one
NAT, the port-chunks being used will always be checkpointed as part of
micro checkpoint.
In case of bypass NAT
flow, in most cases the flow gets checkpointed as part of micro checkpoint.
Any information that
is checkpointed as part of full checkpoint is always recovered.
Data checkpointed through micro checkpoint cannot be guaranteed
to be recovered. The timing of switchover plays a role for recovery
of data done through micro checkpoint. If failover happens after
micro checkpoint is completed, then the micro checkpointed data
will get recovered. If failover happens during micro checkpoint,
then the data recovered will be the one obtained from full checkpoint.
Once NAT IP/and
Port-Chunks/Bypass NAT flow are recovered, the following
holds good:
All of the above items
is applicable for ICSR as well. SIP
ALG also supports ICSR and is applicable only to UDP flows.
In Firewall-and-NAT
policy, checkpointing and ICSR recovery for basic NAT, SIP and H323 flows
can be configured. A maximum of 100 basic flows can be checkpointed.
| Category | Event | Impacted | Details | ||
|---|---|---|---|---|---|
| One-to-One NAT | Session | No | Session recovered. | ||
| New Traffic | No | NAT will be applied. | |||
| Ongoing Traffic | Yes | Cannot differentiate between ongoing traffic and unsolicited traffic. A rule-match is done and if allowed, NAT will be applied accordingly on the packet. | |||
| Unsolicited Traffic (downlink packets) | Yes | Cannot differentiate between ongoing traffic and unsolicited traffic. Translation will be done and packet action taken based on the rule-match. | |||
| Many-to-One NAT | Session | No | Session recovered. | ||
| New Traffic | No | NAT will be applied. | |||
| Ongoing Traffic — TCP | Yes | Packet will be dropped. | |||
| Ongoing Traffic — UDP | Yes and No | If it is downlink packet, it will be dropped. If it is uplink packet, NAT will be applied with a new port. | |||
| Ongoing Traffic — ICMP | Yes and No | If it is downlink packet, it will be dropped. If it is uplink packet, NAT will be applied with a new port. | |||
| Unsolicited Traffic (downlink packets) | No | Packet will be dropped. | |||
| Bypass NAT | Session | No | Session recovered. | ||
| New Traffic | No | Traffic will be NAT bypassed. | |||
| Ongoing Traffic | No | Traffic will be NAT bypassed. | |||
| Unsolicited Traffic (downlink packets) | No | Traffic will be NAT bypassed. | |||
For more information,
in the System Administration
Guide, see the Session Recovery and Interchassis Session
Recovery chapters.
NAT64 Overview
Stateful NAT64
is a mechanism for translating IPv6 packets to IPv4 packets and
vice-versa. The IPv4 address of IPv4 server/host in an
IPv4 network is obtained to and from IPv6 addresses by using the
configured stateful prefix. The IPv6 addresses of IPv6 hosts are
translated to and from IPv4 addresses by installing mappings in
the usual NAT manner. The following figure illustrates the working
of NAT64 with DNS64.
NAT64 is applied on
traffic based on the rule match (Destination based NATing). If NAT64 has
to be applied, then the NAT64 will translate and forward them as
IPv4 packets through the IPv4 network to the IPv4 receiver. The
reverse takes place for packets generated by hosts connected to
the IPv4 network for an IPv6 receiver. If NAT64 is not applied on
the IPv6 packet, then the IPv6 packet will not be translated and
sent as is (NAT bypassed) and will be routed within the IPv6 network
to the destination.
NAT64 will not be applied
for packets whose destination IP address does not match a pre-defined
prefix. NAT64 will be applied only for packets whose destination
IP address matches a pre-defined prefix. The pre-defined prefix
is configurable and it is a single prefix.
NAT64 Translation
For NAT64, Network
address translation and Protocol translation are done on the packets. The
uplink IPv6 packets that are destined to hosts in the IPv4 network
must be protocol translated to IPv4 packets and forwarded. The downlink
IPv4 packets destined to hosts in IPv6 network must be protocol translated
to IPv6 packets and then forwarded.
The Network address
translation is done using the following ways:
-
One-to-One NAT: In the case of 1:1 NAT, the subscriber IPv6 address is uniquely mapped to a given NAT IPv4 address. Port translation is not done as the NAT IP address is associated with a single subscriber and not shared by many users.One-to-One NAT IP allocated to a subscriber can be simultaneously used for NATing IPv4 traffic and IPv6 traffic from a given subscriber. When downlink packets are received, firstly the NAT64 binding lookup is performed for NAT64 translation. If lookup is not successful, then the packet will be NAT44 translated.
-
Many-to-One NAT: In the case of N:1 NAT, the subscriber IPv6 address and source port is mapped to a given NAT IPv4 address and NAT port. Port translation must be done as the same NAT IPv4 address is shared by multiple users. Hence, the L4 ports must be translated to differentiate the connections originating from multiple users sharing the same NAT IPv4 address.
Limitations for One-to-One NAT64
Protocol Translation
This section describes
the Uplink and Downlink Packet translation.
-
Uplink Packet Translation: The uplink packets are translated from IPv6 to IPv4. The IP headers in the packet will be translated. The existing NAT APIs are enhanced to perform Protocol translation. Along with the NAT mapping, the prefix/suffix to be used for translation will also be passed. In case of fragmented packets, the packets need to be reassembled and then translated. The uplink packet translation includes:
-
Downlink Packet Translation: The downlink packets need to be translated from IPv4 to IPv6. The existing NAT APIs are to be enhanced to perform Protocol translation. Along with the NAT mapping, the prefix/suffix to be used for translation will also be passed. In case of fragmented packets, the packets need to be reassembled and then translated. The downlink packet translation includes:
