natv2InstancePortMapFailureDrops

The cumulative number of packets dropped because the
packet would have triggered the creation of a new
port map entry, but no port could be allocated for the
protocol concerned.  The usual case for this will be
for a NAT instance that supports address pooling and
the 'Paired' pooling behavior recommended by RFC 4787,
where the internal endpoint has used up all of the
ports allocated to it for the address it was mapped to
in the selected address pool in the external realm
concerned and cannot be given more ports because
- policy or implementation prevents it from having a
  second address in the same pool, and
- policy or unavailability prevents it from acquiring
  more ports at its originally assigned address.
              
If the NAT instance supports address pooling but its
pooling behavior is 'Arbitrary' (meaning that
the NAT instance can allocate a new port mapping for
the given internal endpoint on any address in the
selected address pool and is not bound to what it has
already mapped for that endpoint), then this counter
is incremented when all ports for the protocol concerned
over the whole of the selected address pool are already
in use.
              
Finally, if no address pools have been configured for the
external realm concerned, then this counter is incremented
because all ports for the protocol involved over the whole
set of addresses available for that external realm are
already in use.
              
This value MUST be monotone increasing in the periods
between updates of the entity's
natv2InstanceDiscontinuityTime.  If a manager detects a
change in the latter since the last time it sampled this
counter, it SHOULD NOT make use of the difference between
the latest value of the counter and any value retrieved
before the new value of natv2InstanceDiscontinuityTime.

MIB

NATV2-MIB

OID

.1.3.6.1.2.1.234.2.1.1.16

Type

column

Access

readonly

Status

current

Parent

natv2InstanceEntry