Velocity Reviews - NAT Entries In Translation Table / XLATE Table

In article <d1h6tu$b6s$1@titan.btinternet.com>,
Darren Green <darrenfgreen@nospam-btopenworld.com> wrote:
:I was looking at the Cisco WWW site a few minutes ago for some NAT reference
:material. One of the articles I review stated:

:'With static NAT, translations exist in the NAT translation table as soon as
:you configure static NAT command(s), and they remain in the translation
:table until you delete the static NAT command(s)'. NB This referred to a
:router not a PIX.

I don't know what happens in IOS, with or without Reflexive ACLs
or the Firewall Feature Set. I can, though, say that on the PIX that
static translations do no get an entry in the xlate table until the first
time they are used, after which they stick until they are cleared.

I have seen hints that the operation of "local-host" on the PIX
may not work the same way, or perhaps was not expected to work the
same way. A "local-host" is the PIX mechanism for dealing with the
10 or 50 user license agreement found only in the PIX 501 model
(PIX 4 and early PIX 5 supported -connection- limits on some models,
which wasn't the same.) A "local-host" may be built before first
use of the static involving that host... and whether it does or not
might depend on the exact software release. It is also not documented
as to what the interaction is between local-host counts and policy nat
or policy static.

:In the Sybex book for exam 642-521 one of the test questions states that
:configuring static mapping does not automatically use a slot in the table.
:The XLATE table holds only active entries.

:I take it that the translation table and XLATE table mentioned above are
:either:

:Two different tables

The static table is a table of -potentials-. Such-and-such an IP
is allowed to communicate as such an such an IP [under such and
such a condition?]. However, a static is not a connection. The
translate table is largely connection based: such and such an IP
and such and such a port is to be translated to this other
IP and port *for this particular connection*. If interior port 1038
is currently mapped to a global IP at port 1433 because that's what
got randonly assigned by PAT, then that doesn't mean that any
system anywhere that happens to be probing for port 1433 will
get connected to the interior port 1038: it is restricted by context.
[See, though, the PIX documentation on the 'established' command for the
ways in this can be surprising.]

It -could- all be implimented in a single table, but it's probably
easier not to.
--
"Mathematics? I speak it like a native." -- Spike Milligan