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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
