Subject: More error-status codes on SNMPv1?

From: "Abhishek Bagchi" <[email-masked]>
Date: Thu, 30 Mar 2000 13:51:09 +0530

Hi all,

 We are working on SNMP interfaces for a product named Flash600 ( ADX,
Layer2 switching, ATM) for FNC Inc. We are using SNMPv1 framework , but,
unfortunately SNMPv1 supports only following error-status codes:

noError(0): no error in the requested PDU.
toobig(1): The get-response message is bigger than that the local
implementation can handle.
noSuchName(2): one of the requested objects does not match anything in
the relevant MIB view that can be returned.
badValue(3): The set-request asked the agent to write an inappropriate
value.
readOnly(4): A set-request tried to write a value that the operator is
not allowed to write.Either the access specified is
READ-ONLY or the the variable MIB definition does not permit write
access.
genErr(5): A variable cannot be retrieved for reasons outside the ones
listed above.

This provides very little granularity for the User to decide what went
wrong.

Is there any other way we can add more error-status codes without
violating v1
compliance?
We don't want to move over to SNMPv2 ,but, still want to add more
error-status codes?
Can we add more error-status codes? If so, how?

Thanks & regards,
Abhishek

********************************************************************
Abhishek Bagchi
Wipro Technologies-Telecom Solutions
#72,Electronics City,Bangalore-29,
India
Tel:91-80-8520408/0416 Ext-2108
Fax:91-80-8520478
---------------------------------------
Applying  Thought
********************************************************************

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 30 Mar 2000 03:22:34 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Thu, 30 Mar 2000 13:51:09 +0530
> From: "Abhishek Bagchi" <[email-masked]>
> To: [email-masked]
> Subject: More error-status codes on SNMPv1?
...
> Is there any other way we can add more error-status codes without

At the level of the protocol, no.

> Can we add more error-status codes? If so, how?
...

I would suggest using SNMPv3.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: "Abhishek Bagchi" <[email-masked]>
Date: Fri, 31 Mar 2000 14:29:35 +0530

Hi,
Thanks for your valuable comments.Please find my comments inline.

Beecher Adams wrote:

> Although the error-status codes may not be extended in v1, what you could do
> is implement an error details table under your private mib.  When you issue
> one of the standard error codes, the manager could then go query the error
> details table to find out more specific information on why the error
> occurred.  The error-index field which is part of the get-response PDU could
> be used as the index into the error table.  This allows an unambigous
> correlation between the error PDU and the corresponding details in the
> table.

This seems to be a good idea.Do you mean to say that an entry in this table will
be created whenever the agent implementation populates the error index  field of
the response PDU with a varbind index?I feel the columner objects in this table
can be the v1 specific error-status and the value of the columner object can
indicate to the specific error condition .
But, the questions that come to my mind are:
1.If the index to the table entry is the error-index in the response PDU , some
other  response PDU may have the same error-index value for a different
varbind.So, there is a problem with unique indexing for the table entries. The
solution to this could be to include the request ID also in the index
information as the request ID is unique to any request PDU.

2.Assuming that the above problem is solved how does the mgmt entity querry this
table? The most obvious way seems to be a next operation as the stn doesn't know
which particular object to query in that entry.What do you feel?

3.Since every time the error-index is populated an entry is created the number
of entries can swell up at times. So we have to devise a way of periodically
deleting entries from this table.How do you think we decide upon this?

There could be a number of other questions that may come to one's mind but right
now I'm not able to think beyond these. Your valuable opinions can surely open
it up a lot more.

Thanks

>
>
> Beecher Adams
> Metro OptiX
> 2201 Avenue K
> Plano, TX 75074
> Email: [email-masked]
> Phone: 214.299.4214  Fax: 214.299.4289
>
> -----Original Message-----
> From: Abhishek Bagchi [mailto:[email-masked]]
> Sent: Thursday, March 30, 2000 2:21 AM
> To: [email-masked]

--

---

From: Beecher Adams <[email-masked]>
Date: Fri, 31 Mar 2000 07:49:36 -0600

See below,

-----Original Message-----
From: Abhishek Bagchi [mailto:[email-masked]]
Sent: Friday, March 31, 2000 3:00 AM
To: Beecher Adams; [email-masked]
Cc: Shivendra Kumar; [email-masked]; Amit Srivastava
Subject: Re: More error-status codes on SNMPv1?

Hi,

> correlation between the error PDU and the corresponding details in the

This seems to be a good idea.Do you mean to say that an entry in this table
will
be created whenever the agent implementation populates the error index
field of
the response PDU with a varbind index?

Yes

I feel the columner objects in this table
can be the v1 specific error-status and the value of the columner object can
indicate to the specific error condition .
But, the questions that come to my mind are:
1.If the index to the table entry is the error-index in the response PDU ,
some
other  response PDU may have the same error-index value for a different
varbind.So, there is a problem with unique indexing for the table entries.
The
solution to this could be to include the request ID also in the index
information as the request ID is unique to any request PDU.

The normal use of error-index is to indicate which varbind may have been the
source of the error.  I suspect many agents don't get this fancy though and
don't make use of the field.  I'm proposing to use this field instead as an
index to an error details table.  The table could be of a fixed size such as
50 entries that will wrap.  It is the agents responsbility to increment the
error-index for each new snmp error that occurs.  This way there is no
ambiguity issue.

2.Assuming that the above problem is solved how does the mgmt entity querry
this
table? The most obvious way seems to be a next operation as the stn doesn't
know
which particular object to query in that entry.What do you feel?

The error details table is just a regular snmp table, in your enterprise
branch.  Having the index from error-index, a simple get operation can be
performed.

3.Since every time the error-index is populated an entry is created the
number
of entries can swell up at times. So we have to devise a way of periodically
deleting entries from this table.How do you think we decide upon this?

Simply use a fixed size table that wraps, e.g. index = 1, then 2, then ..50,
then 1, etc.  There would never be more than 50 outstanding snmp errors, or
again whatever number you choose.

There could be a number of other questions that may come to one's mind but
right
now I'm not able to think beyond these. Your valuable opinions can surely
open
it up a lot more.

Thanks

---

From: Bob Natale <[email-masked]>
Date: Fri, 31 Mar 2000 12:15:02 -0500

At 3/31/2000:08:49 AM, Beecher Adams wrote:

Hi,

This thread belongs on [email-masked] and probably
not on [email-masked].  Moreover, I haven't been following
this thread real closely and I'm not sure who owns the
following quoted material but:

>don't make use of the field.

Very wrong.  Only a very broken agent would not use the
error-index field to point to the varbind for which an
error-status is being returned.

>I'm proposing to use this field instead as an index to an error details table.

This is a non-starter due to error in your
suspicion above.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------