Re: snmp questions

Dave,

Thanks for clarifying the doubts.
Two more , please don't mind

1) Whats the intention and concept behind "lexicographical" ordering in SNMP? Is 
this because we need a particular sequence to retrieve the data? so we choose 
increasing order of OID and hence lexicographical ordering?
2) This is regarding retrieving the next IOD in lexicograph order. Consider the 
following table:

Index           Column1   Rowstatus
-----------------------------------
ab                1            
ac                3
abghlkh        4
bc                5
be                6


If I am correct, by default the index is NON-IMPLIED and also its' single index, 
so NON-IMPLIED and the string length comes into picture.
Lets assume the OID for Column1 is 1.3.6.1.4.1.45

Now if I walk on the table, this is the sequence I get:

1.3.6.1.4.1.45.   2.a.b = 1
1.3.6.1.4.1.45.   2.a.c = 3
1.3.6.1.4.1.45.   2.b.c = 5
1.3.6.1.4.1.45.   2.b.e = 6
1.3.6.1.4.1.45.   7.a.b.g.h.l.k.h = 4

Included spaces in OID to distinguish the lengths. I assume I am correct till 
this point.

Now my question is, lets assume the user is running snmp walk on this table and 
initially we sent back the first OID 1.3.6.1.4.1.45.2.a.b as 1, the snmp walk 
comes back asking for the next OID, then how in the code we know this index is 
NON-IMPLIED and we need to send back 1.3.6.1.4.1.45.   2.a.c but not 
1.3.6.1.4.1.45.   7.a.b.g.h.l.k.h? I mean to say , do we need to implement the 
code based on the fact that the index is variable length string and the get next 
is to be written based on that? Because from the MIB I can make out that the 
index is variable length string and length needs to be prefixed to the OID,   
but how is this when it comes to writing code/implementing?

3) In the above example, when the first request comes from the user, we send the 
value as 1 for the OID 1.3.6.1.4.1.45.2.a.b. My question is, from the coding 
point of view, we send the value "1" back, how about adding the length "2" in 
OID before sending this back to user/snmp manager? who takes care of this. will 
the agent add 2 before "a.b" in the OID and sends out?

Thanks a lot for reading such a long mail.

Reagrds,
Pete



________________________________
From: Dave Shield <[email protected]>
To: Pete Snmp <[email protected]>
Cc: [email protected]
Sent: Tue, August 2, 2011 12:56:01 AM
Subject: Re: snmp questions

On 1 August 2011 19:15, Pete Snmp <[email protected]> wrote:
> 1) How come walk returns a valid entry without providing an OID to start with?

   $ man snmpwalk

       If no OID argument is present, snmpwalk will search the
       subtree rooted at SNMPv2-SMI::mib-2

> As walk uses get_next internally !

The command "snmpwalk" supplies a default starting point.
The GetMext request (and the snmpgetnext command) requires an OID.


> 2) I couldn't get what you mentioned about counters !
>      Could you please explain this with an example

   $ snmpget ... ifInOctets.1
   IF-MIB::ifInOctets.1 = Counter32: 109633764

What does that mean?  Absolutely nothing.

   $ snmpget ... ifInOctets.1 ; sleep 60 ; snmpget ... ifInOctets.1
   IF-MIB::ifInOctets.1 = Counter32: 109633764
   IF-MIB::ifInOctets.1 = Counter32: 109633824

What does that mean?
The system has received 60 octets in the last minute.

The individual value is irrelevant - what's important is the difference
between the two.


> 3) Regarding tables, ROW_STATUS is from SMI v2, so this is not there in
> SMIv1. In this case how are tables implemented in SMIv1?

First thing - don't get confused between SMI (the language used to
write MIB files, and hence to describe what management information
is potentially available), and SNMP (the protocol used to ask for this
information.
   They are two very different ideas, and it is perfectly possible
(and common) to use SNMPv1 to query for information defined
using SMIv2.  (or vice versa).

Secondly, SMI is purely concerned with *defining* MIB objects.
It has nothing to with how they are implemented in a given SNMP
agent (other than describing what the agent ought to be doing).
I tend to describe this in terms of a design document.

  Thirdly, the basic syntax and structure of tables is exactly the
same for both SMIv1 and SMIv2.

RowStatus is an (optional) convention, introduced to provide
a standard way for creating/deleting rows.  There's nothing in
the SNMP specs that says you *must* use this for managing
tables.  In many cases, this may not make sense.
   For example, the TCP connection table, or the table of running
processes will see rows appear and disappear automatically,
to reflect the status of the underlying system.   Neither of these
tables include a RowStatus column, because it doesn't make
sense in this context.


> How is the row creation/insertion/deletion handled in SNMPv1/SMI v1?

Implementation dependent.
It's up to the MIB designer to describe how (and whether) rows should/can
be created or destroyed.   Just as it is with SMIv2.

SMIv2 introduced the *option* of RowStatus - it didn't make it mandatory.


> 4) how come V1 traps has the agent address mentioned in the PDU, where as the
> address is not mentioned in the SNMPv2 NOTIFICATION? Any particular reason?

Two reasons:
   One was a desire to bring the structure of notification requests
into line with
the rest of the SNMP protocol requests.  So v2 notifications use a varbind
list to pass information (just as the GET*/SET requests do), rather than
having special header fields.
   So there are defined OIDs that can be used in the notification payload
varbind list, instead of the trap1 headers.   See the coexistence RFC for
details.

  The other was a growing recognition that not all networks are IP-based
(And in particular, IPv4-based).   If you want to send an SNMPv1 trap
using IPv6, then you're out of luck - the agent-addr header can't cope
with this.
   If you're using v2 traps, then the varbind list can cope with IPv4, IPv6,
IPX, etc, etc, etc


> 5) what is the use of conformance and compliance in SMI v2 MIB?

Good question.  If you ever find out, please let us know.

> how is this useful at the code level?

It's not.

> why is this introduced in SMI v2? Any specific reason? How is this useful.

The basic idea (as I understand it), was to have some way of determining
what MIBs were supported by a given SNMP agent.   I.e. some way of
saying  "can I ask you about X?"  (using the sysORTable)
   But it never really took off - it's basically an idea that failed.

Conformance/Compliance is really just one of the hoops you have
to jump through to keep the purists happy :-)
   But I didn't say that...

Dave

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users