Response with [PTT2].
On 28/10/2014 4:34 PM, JF Tremblay wrote:
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)
...>>>
[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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
