> On Oct 28, 2014, at 3:53 PM, Tom Taylor <[email protected]> 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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
