Leaving aside the notification question for research, the discussion
below suggests that the boundary between port exhaustion and address
exhaustion is somewhat indeterminate. The MIB currently has two counters
(showing up in various tables, another issue), OutOfPortErrors and
ResourceErrors, with the latter supposedly picking up address
exhaustion. I'd suggest we make the first one OutOfAddressPortErrors and
thereby eliminate the ambiguity. I'd also call these Drops rather than
Errors to make the consequences clearer.
Tom Taylor
On 27/10/2014 9:35 AM, Simon Perreault wrote:
On Sun, Oct 26, 2014 at 6:35 PM, Tom Taylor <[email protected]>
wrote:
...
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.
Well, yes, but I don't see how this is a problem.
Keep in mind that some NATs don't bother with ports and allocate full
addresses. That is supported with the current pool and mapping models.
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?)
It depends on what you mean by "cannot". A "paired" NAT may decide to
allocate a mapping from any other available address and not even consider
this an exhaustion condition. It may decide to replace the current address
mapping with this new address. Or it may consider this a "temporary address
mapping" to be reverted eventually. Or it may not record this new mapping
at all, and just allocate mappings from any random address as long as the
primary address is exhausted. Or it may refuse to create a new mapping, as
you seem to imply.
We should not "think" too much about NAT implementation... What matters is
observable behaviour, and in particular observable behaviour that is
general enough that it can be usefully modelled in a MIB. Whatever triggers
an exhaustion event is not absolutely important. We just need to be able to
report it. It will be up to the NAT administrator to determine, based on
the particular NAT implementation, what exactly exhaustion means. Some NATs
are very configurable in this matter.
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.
...
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
