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

[JF Tremblay <[e-mail]>]

> 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)
>> 
>> MIB behaviour (in my opinion):
>> 1. natQuotaDrops incremented
>> 2. Is natQuotaDrops or natOutOfPortErrors incremented? The MIB prohibits incrementing both. natOutOfPortsError would probably be preferable.
>> 3. natOutOfAddressPortErrors incremented
>> 4. natQuotaDrops incremented (probably)
>> 
>> Suggestion:
>> natQuotaDrops could be split in natAddressQuotaDrops and natPortsQuotaDrops. It would make it somewhat clearer that a "per port” or a “per address” policy is involved.
>> 
> [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?

> 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