This document describes the different types of Network Address
Translation (NAT), and maps each type of NAT to the relevant ONS 15454 software
version which supports that type.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
Technical Tips Conventions for more information on document
In many cases in the field, different NAT scenarios are in play and do
not work properly. You can identify most of these scenarios through the
symptoms. Most of the problems stem from the inability of the Network Element
(NE) to initiate a connection back to the Cisco Transport Controller (CTC)
Often, when CTC does not support a particular configuration of NAT, CTC
consistently drops and reconnects to nodes at specific intervals. In newer
versions, CTC can recover from disconnects without dropping from view. In such
versions, you can notice this issue during interaction with the node through
The same symptoms also occur due to incorrect configurations of the
external firewall where Access Lists dictate security. The Access Lists do not
allow the NE to initiate certain connections to or from defined IP addresses
and/or ports, back towards the CTC Workstation. Frequent disconnects can also
occur when the external firewall time-out settings are too short.
For sample firewall Access Lists that you can use with the ONS 15454,
refer to the
Firewalls section of
ONS 15454 Reference Manual, Release 5.0.
NAT allows a single device, for example, a router, to act as an agent
between the Internet and a local network. This section explains the various
types of NAT.
For more information, refer to
RFC 2663 - IP
Network Address Translator Terminology and Considerations
Traditional NAT allows hosts within a private network to transparently
access hosts in the external network. Traditional NAT initiates outbound
sessions from the private network.
This section briefly describes the two variations of Traditional
Basic NAT: Basic NAT sets aside a block of external
addresses. Basic NAT uses these addresses to translate addresses of hosts in a
private domain when the hosts initiate sessions with the external domain.
Network Address Port Translation (NAPT): NAPT
extends the notion of translation one step further. NAPT also translates
transport identifiers, for example, TCP and UDP port numbers, and ICMP query
identifiers. Such translation multiplexes the transport identifiers of a number
of private hosts into the transport identifiers of a single external address.
Note: NAPT is also called Port Address Translation (PAT).
A device on the outside network initiates a transaction with a device
on the inside. In order to permit this initiation, the basic version of NAT was
enhanced to include advanced capabilities. This enhancement is most commonly
known as Bi-directional NAT, but is also referred to as Two-Way NAT and Inbound
NAT. With a Bi-directional NAT, you can initiate sessions from hosts in the
public network and the private network. Private network addresses are bound to
globally unique addresses, statically or dynamically as you establish
connections in either direction.
Performance of NAT on inbound transactions is more difficult than
outbound NAT. The reason is that the inside network generally knows the IP
address of outside devices, because these devices are public. However, the
outside network does not know the private addresses of the inside network. Even
if the outside network is aware of the IP addresses of private networks, you
can never specify these IP addresses as the target of an IP datagram that you
initiate from outside, because they are not routable.
You can use one of these two methods to resolve the hidden address
Note: In this document, Bi-directional NAT implies Basic NAT, but Basic NAT
does not imply Bidirectional NAT.
Twice NAT is a variation of NAT. Twice NAT modifies both the source and
destination addresses when a datagram crosses address realms. This concept is
in contrast to Traditional NAT and Bi-Directional NAT, which translate only one
of the addresses (either source or destination).
This table shows the ONS 15454 and NAT compatibility:
Type of NAT
Gateway Network Element (GNE) Sees
Supported CTC Version
In case of a communication problem between the NE and CTC, the output
of the fhDebug command contains this error message:
OCT 27 18:35:37.09 UTC ERROR ObjectChange.cc:432 tEventMgr
CORBA::NO_IMPLEMENT/0x3d0004 updating [192.168.1.100:EventReceiver]. Marking c
OCT 27 18:36:17.09 UTC DEBUG AlarmImpl.cc:353 tEventMgr
Removing corba client [192.168.1.100:EventReceiver] from auton msg list
Several reasons can cause this error. However, if the error occurs at
regular predictable intervals (usually ~2 or ~4 minutes), the reason can be the
presence of either a type of NAT that CTC does not support, or a firewall
without the necessary port permissions.
Observe that 172.16.1.100 is the IP address of the CTC workstation and
10.1.1.1 is the NAT address (see Figure
Figure 1 – Topology
Here is the partial output of the
Active Internet connections (including servers)
PCB Typ Rx-Q Tx-Q Local Address Foreign Address (state)
------- --- ---- ---- ----------------- --------------- -------
2145984 TCP 0 0 10.10.10.10:1052 10.1.1.1:1029 SYN_SENT
21457f8 TCP 0 0 10.10.10.10:80 10.1.1.1:1246 TIME_WAIT
2145900 TCP 0 0 10.10.10.10:57790 10.1.1.1:1245 ESTABLISHED --- ISP assigned address
21453d8 TCP 0 0 10.10.10.10:80 10.1.1.1:1244 TIME_WAIT
2144f34 TCP 0 0 10.10.10.10:80 10.1.1.1:1238 TIME_WAIT
2144eb0 TCP 0 0 10.10.10.10:1080 10.1.1.1:1224 ESTABLISHED --- ISP assigned address
This output shows no evidence of this address. The output shows the
public address that the ISP uses, which is evidence of a Traditional NAT
In order to identify Bi-directional NAT and Twice NAT, you need a
sniffer trace from the same network segment as the CTC workstation. Ideally, a
sniffer that runs on the CTC workstation is most suitable.