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