[BEHAVE] Out of port errors, resource errors in NAT MIB

[Tom Taylor <[e-mail]>]

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 <[e-mail]>
> 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.
>>
>
...