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

At the end with [PTT].

On 28/10/2014 12:00 PM, JF Tremblay wrote:
>
>> On Oct 27, 2014, at 9:22 PM, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
>>
>> 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.
>
> +1
> I believe it’s useful for a NAT operator to differentiate between these types of errors.
>
> As Tom mentioned, we shouldn’t dwelve* in implementation-specific details, but the MIB should provide enough flexibility to express real-life error conditions in a meaningful way. Where meaningful == clear enough for an operation person not to have to dig the MIB definition at 2:00 in the morning to figure out which problem needs fixing.
>
> This begs the question: are these objects sufficient and aptly named in the MIB to reach the goal above?
>
> 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)
>
> Note that natResourceErrors isn’t used above, but it’s probably useful to keep it as it is now.
>
> Possible corrective actions:
> a) Add addresses to currently configured pools: cases 3 and 4
> b) Review the administrative boundaries policies (long term action): cases 2 and 4
>
> In this light, Tom’s suggestion of adding natOutOfAddressesPortErrors is definitely useful, as it covers case 3 well and provides a way to differentiate it from case 1. However the current fields might not be sufficient to cover all cases, like differentiating cases 1 and 4 above. This might be left to implementation-dependant enterprise MIBs, but it would have been nice to have enough coverage in the standard MIB for most common cases.
>
> 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.
>
> My 2.302 cents (the exchange rate isn’t what it used to be)
>
> /JF
>
[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. Then a general "other 
resources" counter. 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).
>
> * I just learned that “dwelve” isn’t a real word after all. Interesting, I’ll go to sleep a little less idiot tonight (loose translation of a local expression).
>
[PTT] You've mingled two applicable words. You could have said "dwell on 
implementation details" or "delve into implementation details".
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>