A little terminology to start with:
1) A realm defines an addressing space. Simple NATs may support just two
realms: internal and external. This is all that RFC 4008 supports. In
more complex situations the NAT will support several or many realms.
Individual realms in that case can be internal from the point of view of
some hosts served by the NAT and external from the point of view of others.
2) An address mapping is an assignment of an address in a selected
external realm to the address of a host in its internal realm.
3) An address and port mapping is a mapping between the address and port
of a host in its internal realm for a given protocol to an address and
port in a selected external realm. For mappings triggered by packets
outgoing from the internal host, the external realm is selected based on
the packet destination. For mappings triggered by packets incoming from
an external realm, the external realm is the one from which the packet
originated.
4) An address pool is a separately-managed set of addresses and
ports/ICMP identifiers in a particular realm, available for assignment
to the 'external' portion of a mapping. Pools can be used to ration the
available external addresses to different realms and classes of
subscribers. Where more than one pool has been assigned to the realm,
policy determines which subscribers and/or services are mapped to which
pool.
The NAT MIB (draft-ietf-behave-nat-mib-11) currently has five
notifications, which can be enabled and disabled through their
respective threshold settings:
- Address pool low threshold undershot
-- reports under-utilization of an address pool
- Address pool high threshold exceeded
-- reports potential over-utilization of an address pool
- Address mapping threshold exceeded
-- reports potential exhaustion of addresses
for the NAT instance as a whole
- Address and port mapping threshold exceeded
-- reports potential exhaustion of address plus port
combinations for the NAT instance as a whole
- Per-subscriber address and port mapping threshold exceeded
-- can be used for troubleshooting (enabled for specific
subscriber) or provisioning (enabled for all subscribers)
Just as a preliminary, my personal view is that the notification
relating to low pool utilization should not be there, and if the
information is needed, it should be handled by the management
application. Hence this one should be omitted from the discussion which
follows.
David Harrington in his review was concerned that these notifications
involved calculations at the agent that were excessively demanding of
processor capacity. This is especially true of the MIB's current
algorithm for address pool utilization. More on that in a moment.
Just for background, the MIB supports the following read-write hard
limits, beyond which incoming packets are dropped rather than translated:
- Maximum number of active address mappings
- Maximum number of active address and port mappings
- Maximum number of fragments awaiting reassembly
- Maximum number of subscribers with active address and port mappings
The resources that need monitoring in the NAT are NAT memory, address
pool utilization, and processor capacity. The only item in the above
list of notifications and limits that at least partially addresses
processor capacity is the last limit, on number of active subscribers.
Possibly, a notification and limit could be introduced based on the rate
of change of the number of active mappings.
The problem with NAT pool monitoring is that the pool actually contains
two resources, addresses and ports, and how they get used up depends on
RFC 4787 pooling behaviour.
For the RECOMMENDED pooling behaviour of 'paired', port exhaustion
occurs when all the ports for the desired protocol available to the
subscriber on a mapped external address are used up, the NAT cannot (for
reasons of policy or availability) assign additional ports to that
subscriber on that same address, and the NAT cannot assign an additional
address containing free ports to that subscriber. (This last condition
is subject to discussion: is it port exhaustion or address exhaustion?)
For a pooling behaviour of 'arbitrary', port exhaustion occurs when
there is no available port for the desired protocol at any of the
addresses in the pool. Clearly port exhaustion will be a rarer event in
the 'arbitrary' case.
draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio
of active address and port mappings using a given pool to the total
number of address-port combinations made available by the pool,
expressed as a percentage. As David Harrington pointed out, this makes a
lot of demands on the agent processor. We have some alternatives:
1) No notification: leave any processing to the management application.
2) Trigger the high usage notification based on the rate of occurrence
of out-of-port events, with the same threshold value for all pools. This
is reasonably valid statistically for a low threshold (i.e., taking the
view that any port exhaustion at all is actionable), but not terribly
reliable in the 'paired' case, in that a single subscriber can dominate
the results.
3) Trigger the high usage notification based on the rate of occurrence
of out-of-port events, with a higher threshold value based on pool size
(addresses x ports) and sharing ratio. This requires some mathematical
analysis and per-pool configuration.
What do people recommend?
Tom Taylor
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
