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

[Tom Taylor <[e-mail]>]

Response with [PTT2].

On 28/10/2014 4:34 PM, JF Tremblay wrote:
>
>> On Oct 28, 2014, at 3:53 PM, Tom Taylor <[e-mail]> wrote:
>> At the end with [PTT].
>>
>> On 28/10/2014 12:00 PM, JF Tremblay wrote:
>>>
>>>
>>> Let’s take a few examples of real-life CGN error cases (they are fairly common in my experience, but your-experience-may-vary-of-course):
>>> 1. Out-of-ports because an administrative limit of port-per-user is reached.
>>> 2. Out-of-ports because a single address doesn’t have enough available ports and address “pairing” is enforced.
>>> 3. Out-of-ports/addresses because all addresses in all configured pools do not have enough available ports.
>>> 4. Out-of-addresses because an administrative limit of users per address is reached on all addresses of all configured pools.
>>> (in the above, “user” is loosely used as meaning a single inside source address)
>>>
...>>>
>> [PTT] Looks to me like the solution might be to have a counter per administrative limit, plus one each for can't allocate an address mapping, can't allocate an address-port mapping.
>
> Is that 4 counters? {admin | !admin} x { addresses | addresses-ports }
>
> For example:
> natAdminOutOfAddressesDrops
> natAdminOutOfAddressesPortsDrops
> natOutOfPortsDrops
> natOutOfAddressesPortsDrops
>
> Not sure natAdminOutOfAddressesPortsDrops above makes any sense. An administrative policy will be on ports only. No implementation will specify a limit in address-ports (even if this is what it is, actually).
>
> Suggestion:
> natAdminOutOfAddressesDrops
> natAdminOutOfPortsDrops
> natOutOfPortsDrops
> natOutOfAddressesPortsDrops
> natResourceErrors
>
> Then the MIB behavior according to the scenarios above become:
>
> 1. natAdminOutOfPortsDrops++
> 2. natOutOfPortsDrops++
> 3. natOutOfAddressesPortsDrops++
> 4. natAdminOutOfAddressesDrops++
>
> Makes sense?
>
[PTT2] It works. If we keep to the MIB in its current form, we need two 
more administrative counters because we have two more limits: on 
fragments, and on number of subscribers with active mappings.

>> Then a general "other resources" counter.
>
> Ok. (added above)
>
>> That's not distinguishing your cases 2 and 3, but based on what Simon was saying this seems less tied to implementation than trying to make that distinction. Case 3 should make itself evident in other ways (resource pool utilization).
>
> Agreed, “utilization” information would provide an indication of a problem, but it will not provide an indication of how severe the problem is or has been. By looking at a counter, an operator can get additional information (how many drops actually happened).
>
> JF
>
>
>