Re: snmp questions

On 2 August 2011 05:21, Pete Snmp <[email protected]> wrote:
> 1) Whats the intention and concept behind "lexicographical" ordering in SNMP?

I'm really not sure why you are asking me this.  I wasn't involved in the
original design of SNMP - I've only been involved with this project since
the mid-90s
   You'd probably have to go back to the mailing lists of the original
working group to discover the thinking.


> Is this because we need a particular sequence to retrieve the data? so
> we choose increasing order of OID and hence lexicographical ordering?

That seems plausible, yes.


> 2) This is regarding retrieving the next IOD in lexicograph order. Consider
> the following table:

It would be useful if you included the MIB definition of the table,
so it was clear exactly how it was being defined.



> 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.

I believe so, given the assumptions you are making - yes.
  [Except that this would imply a column object from a table rooted
   at 1.3.6.1.4 - which isn't possible.   So the OIDs that you are using
   are actually bogus.   But that doesn't affect the basic principles]



> 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

Remember that each table is implemented by a dedicated block of code
(the MIB implementation module).   This may use one of the handlers to
deal with some of the donkey work, or it may handle everything itself.
But in either case, there's table-specific code, which includes such detail
as where the table is rooted, how it is indexed, and what rows are valid.

This is used to determine which row should be returned for a given
GETNEXT request.


>                                            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?

Yes.
Either directly, or using one of the table helpers (which can handle this for
you automatically)

>                                                                  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?

It's difficult to answer this in the abstract.
It would be easier if you gave some indication of which table helper (if any)
you are using.

Have a look at some of the existing MIB tables, to get a feel for how this
has been handled elsewhere.


> 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?

The agent looks after this - yes.
Remember that a walk uses GETNEXT requests,  and the snmp manager
typically doesn't know what the first row actually is.
   So the first request will probably be

         GETNEXT  .1.3.6.1.4.1.45

and the agent will return the value for the first instance -
1.3.6.1.4.1.45.2.a.b
The next request will be

         GETNEXT  .1.3.6.1.4.1.45.2.a.b

and the agent will return   1.3.6.1.4.1.45.2.a.c
So this index processing needs to happen from the very first request,
not just starting with the second.


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