Subject: Re: [MIB-DOCTORS] [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. Please feed back your comments, thanks.

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Sep 2008 21:33:24 -0700

Hi -

> From: "Shimin Ban" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, September 24, 2008 7:43 PM
> Subject: [OPSAWG] REMINDER: A proposal about how to get the real cause of SNMP failed requests. ...
> If you have any suggestions or opinions please don't hesitate to e-mail me. Thank you in advance.
...

You could avoid modifying the protocol if you indexed your table
with the address to which the response was sent and the value of
request-id (flattened into unsigned32 in order to work as an index).
One nice benefit would be that the manager could look for the error
if the response was lost on the wire, something not practical with
randomly-assigned indexes.

In any case, you should think about providing some kind of age-out
mechanism for the error table entries, and might also consider whether it
would be worthwhile to support internationalization of the error
messages.

You should also think about what kind of access control policy
would be meaningful for this information.  One advantage of including
the address to which the response was sent in the indexing would be
that it would make sensible VACM configuration in multi-manager
situations possible.

Finally, you might give some consideration to how you would deliver
the error information from the instrumentation to the table in an
AgentX, SMUX, or proprietary subagent environment.

Randy

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Shimin Ban <[email-masked]>
Date: Thu, 25 Sep 2008 10:43:44 +0800

Hi,
I have a proposal about how to get the real cause of SNMP failed requests. I don't know if it is appropriate for an Internet-Draft. 
Any suggestion or opinion is appreciated.

o Background
You know, SNMP is a widely used protocol to manage devices in IP network. RFC3416 defindes 18 error status. But in many applications these error status can not feed back the real cause of the SNMP requests for the specifc services. For example, when creating VLAN fails what the user wants to know is not 'badValue', but 'why it failed'. The VLAN already exists? or VLAN ID exceeded the range? or some port cannot be added to VLAN etc. However, currently as far as know the application can't tell the user these information. So the user can't correct his operation in time. Maybe it takes him much time to find that: Oh! 2094 is a special VLAN used by the device and can't be created!! Then he is mad ...

The proposal provides a way to get the detailed error information from agent, through which the SNMP applications can feed back the real cause of SNMP requests to the user. So he can easily and timely identify and solve the problem. 

o How to work
In this approach a new MIB table is defined to store the detailed error information. For example, it's named snmpESTable. When the manager sends request to the agent, if there is an error occurred, the agent can deal with the error as below:
    1. The agent creates an entry with a random unique value except 0 as index in the snmpESTable and stores the detailed error information in it, saying '2094 is being used by me, you can't create it!'.
    2. The agent returns the response PDU with the index being filled in the error-status field. 
    3. The manager receives the response. It extracts the error status index from the response PDU.
    4. The manager finds the error status isn't 0 (noError) and sends a SNMP GetRequest to the agent with the error status as the index to query the detailed error information.
    5. The manager feeds back the information to the user. So the user knows what happened and has no necessary to be mad.

o Relationship to current SNMP
Because the error-status field is 32 bits, the approach can be backward-compatible with the former error status without changing the SNMP PDU format as long as we reserve 0(noerror)-18(inconsistentName).

o existing related standards or technique
RFC3877 and RFC3878 describe an alarm model. However I think they are different. I think, the failed SNMP requests described in the proposal can't cause the fault and triger the alarm system described in the 2 RFCs. Let me know if you know such a technique that could solve the issue easily.

The proposal is simple, but I believe it can solve the numerous and trivial and boring issues about SNMP error. 
If you have any suggestions or opinions please don't hesitate to e-mail me. Thank you in advance.

Cheers
Shimin