Ahh, I hadn't thought of using the vmName as the index (I'm too used to thinking about indices as "integers"). That would work beautifully, because that name is guaranteed to be unique (in the scope of the table, at least), and is constant with respect to the object itself.
So in that case I would simple append the actual vmName string to the OID when throwing the trap. I haven't done anything with string indices yet, but it looks like I just have to convert each character in the string to its ASCII equivalent (for example, "vm1" would be .118.109.49, correct?). Easy peasy! Thanks Dave!! -----Original Message----- From: Dave Shield [mailto:d.t.shi...@liverpool.ac.uk] Sent: Wednesday, March 04, 2009 11:03 AM To: McGowen, Wendy Cc: net-snmp-users@lists.sourceforge.net Subject: Re: Trap question: OID for variable from a table 2009/3/4 McGowen, Wendy <wen...@pivot3.com>: > Do I have to include the index > value in the OID for the vmName object in the trap I believe so, yes. >From RFC 2578: 8.1. Mapping of the OBJECTS clause The OBJECTS clause, which need not be present, defines an ordered sequence of MIB object types. One and only one object ==>instance<== for each occurrence of each object type must be present... and 7. Mapping of the OBJECT-TYPE macro : For leaf objects which are not columnar objects.... .... instances of the object are identified by appending a sub-identifier of zero to the name of that object. Otherwise, the INDEX clause of the conceptual row object superior to a columnar object defines instance identification information. So yes, the OID of an _instance_ of vmName should include an index value. Although if this is a private implementation, solely used within your own organisation, then you can take whatever shortcuts you feel appropriate (as long as everyone knows what's expected). I would suggest that you stick as closely as possible to the spirit of the specs above. For example, you're probably better off using a dummy index value ('vmName.0', assuming simple integer indexes) in the trap varbind OID rather than omitting it altogether ('vmName'). Alternatively, if definition of the MIB table isn't fixed in stone as yet, then why not use vmName as the index? So the trap would then be sent containing a varbind such as: vmStatus."rowName" = onFire(5) and you're reported both the name and the status in one go! Dave ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
