Subject: Re: [BEHAVE] Comments on the NAT MIB

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Oct 2013 11:17:24 +0200

Le 2013-09-27 18:19, Tom Taylor a écrit :
>>>> 5. For logging purposes, it would be good to have a quota identifier.
>>>>  From the MIB point of view, would it make sense to have a quota table
>>>> presenting an SnmpAdminString identifier and a counter for the quota
>>>> violations?
>>>
>>> Maybe. Can you describe a little bit what those "quota identifiers" are?
>>> Maybe give an example?
>>
>> [PTT] Here's the text describing this in syslog-03, Section 3.13:
>>
>>     Table [proposed] in the
>>     NAT MIB lists quota identifiers and corresponding total counts of
>>     packets dropped because of quota violations.  This table may be
>>     extended to provide information on the configuration of the
>>     particular quota, depending on the implementation.
>>
>>
>> Here's a sketch of the table as I envision it, based on cut-and-paste
>> from the existing natPool table in the MIB. Maybe it would be useful to
>> have an additional SnmpAdminString quota identifier for more
>> human-friendly presentation. If we do have the drops counter, the global
>> counter natQuotaDrops is redundant and should be dropped itself.

...unless the table of quotas is very big. Do you think it could be?

My main question is: why would this be necessary? Is there anyone asking
for more details about quotas? If we have learned anything from RFC
4008, it's that less is more.

>> Number
>> of administrative denials is a new idea, providing a check on PCP
>> requests, maybe.
>>
>> BTW I note that natPoolIndex id read-only rather than not-accessible. Is
>> this correct? I copied it for natQuotaIndex.
>>
>>     -- textual conventions
>>
>>     NatQuotaId ::= TEXTUAL-CONVENTION
>>         DISPLAY-HINT "d"
>>         STATUS current
>>         DESCRIPTION
>>             "A unique ID that is assigned to each quota."
>>         SYNTAX Unsigned32 (1..4294967295)
>>
>>
>> -- quotas
>>
>>     natQuotaObjects OBJECT IDENTIFIER ::= { natMIBObjects xx }
>>
>>     natQuotaTable OBJECT-TYPE
>>         SYNTAX SEQUENCE OF NatQuotaEntry
>>         MAX-ACCESS not-accessible
>>         STATUS current
>>         DESCRIPTION
>>             "Table of quotas. May be extended by the implementation
>>              to include objects related to configuration."
>>         ::= { natQuotaObjects 1 }

Can you show examples of such quotas? I'm looking for something like
"quota 1 would stand for XYZ, quota 2 would stand for ABC, etc."

For a given implementation, would the size of this table be fixed or
could the admin define additional quotas?

> [PTT2] Thinking this through a bit further, I realize that the
> configuration table would be a separate table in which the index value
> would be created. This table just quotes the created value.
>>
>>     natQuotaEntry OBJECT-TYPE
>>         SYNTAX NatQuotaEntry
>>         MAX-ACCESS not-accessible
>>         STATUS current
>>         DESCRIPTION
>>             "Entry in the table of quotas."
>>         INDEX { natQuotaIndex }
>>         ::= { natQuotaTable 1 }
>>
>>     NatQuotaEntry ::=
>>         SEQUENCE {
>>             natQuotaIndex        NatQuotaId,
>>             natQuotaDrops        Integer32,
>>             natQuotaDenies       Integer32
>>         }
>>
>>     natQuotaIndex OBJECT-TYPE
>>         SYNTAX NatQuotaId
>>         MAX-ACCESS read-only
>>         STATUS current
>>         DESCRIPTION
>>             "Index of a quota."
>>         ::= { natQuotaEntry 1 }
>>
>>     natQuotaDrops OBJECT-TYPE
>>         SYNTAX Counter64
>>         MAX-ACCESS read-only
>>         STATUS current
>>         DESCRIPTION
>>             "Number of packets dropped due to application of this quota."
>>         ::= { natQuotalEntry 2 }
>>
>>     natQuotaDenies OBJECT-TYPE
>>         SYNTAX Counter64
>>         MAX-ACCESS read-only
>>         STATUS current
>>         DESCRIPTION
>>             "Number of administrative requests denied due to
>>              application of this quota."
>>         ::= { natQuotaEntry 3 }

I'm having difficulty understanding what this last item represents.
IMHO, quotas applying to PCP requests would go in a PCP server MIB, not
a NAT MIB.

Simon

---

From: Tom Taylor <[email-masked]>
Date: Mon, 07 Oct 2013 08:27:49 -0400

General summary: all I want is a way to identify the quota in the log. I 
have no idea what implementations provide, and was taking my hints from 
what you said at the meeting. Am I now right to think a quota index 
would exist, and I can assume it is available to the logging application 
without worrying about the MIB? A couple of points below.

>>>>> presenting an SnmpAdminString identifier and a counter for the quota
...
>>> this correct? I copied it for natQuotaIndex.

[PTT] Not sure if you missed this point.
...
> IMHO, quotas applying to PCP requests would go in a PCP server MIB, not

[PTT] OK.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Oct 2013 16:52:57 +0200

Le 2013-10-07 14:27, Tom Taylor a écrit :
> without worrying about the MIB?

At this point I think we need other people to weigh in. Personally I
still don't quite understand what a "quota index" really is concretely,
and I can't map it to a concrete aspect of any implementation I know of.

> [PTT] Not sure if you missed this point.

I thought I had replied in another email. The reason natPoolIndex is
read-only rather than not-accessible is that a notification includes it,
therefore it MUST NOT be not-accessible (according to smilint).

Simon

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 7 Oct 2013 15:04:08 +0000

Based on my read of what Tom is asking is he is asking for a general set
of counters to reflect
the packets(?) dropped and denied. I am not really sure if these counters
are useful as standalone counters,
without knowing what the quota that was applied that caused the packets to
be dropped or denied. For example,
if a user was denied access because he exceeded the per-user port limit,
then incrementing a global counter
is not very useful, IMO. I would think a per-quota counter might be a more
meaningful one. I am not an operator,
So I think someone with operational experience might have a valuable
opinion.

Thanks
Senthil

---

From: Tom Taylor <[email-masked]>
Date: Mon, 07 Oct 2013 12:49:34 -0400

No, I'm asking how you tell the craftsperson WHICH quota was violated.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Oct 2013 09:45:51 +0200

> No, I'm asking how you tell the craftsperson WHICH quota was violated.

Sounds to me like you and Senthil are saying the same thing.

How many such quotas would there be in that table? What would be the
granularity? There's a big difference in manageability between 10
entries and 10 million entries...

Simon

---

From: Tom Taylor <[email-masked]>
Date: Tue, 08 Oct 2013 06:11:17 -0400

> entries and 10 million entries...
....

[PTT] I can only tell you how I would design such a system. It would be 
insane to require the operator to configure more than maybe 20 quotas. I 
would hope that any per-subscriber or per-service quotas would be based 
on classing subscribers or services respectively and assigning the quota 
by class rather than individual.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Oct 2013 12:19:24 +0200

> by class rather than individual.

Makes sense.

Unless there is disagreement, this proposal will be in the next draft
revision.

Simon