Jeff,
When you write a MIB specification then you
are specifying the object classes. Thus,
the OID of an object in the specification
should not end with ".0".
The agent then defines what instances are
there for each object class. For scalars,
there is exactly one (or none if the object
is not supported) which is differentiated
from the object class with the .0 suffix.
For table cell instances, there is a index
instance (sub-)identifier, which can be
quite complex and long (<128 sub-IDs).
Best regards,
Frank
Jeff Ramin wrote:
I've done a little research, and I've answered my question below - the
.0 suffix for scalars is part of the SNMP spec.
So, this leads to my next question - when defining a MIB, do I specify
the trailing ".0" for scalars, or is the convention to omit it?
Thanks.
Jeff Ramin wrote:
Thanks for the reply Frank.
Is this a quirk of SNMP4J, or is this just the way SNMP is specified?
Would the request need to be for 1.2.3.4.5.1.0 in order for the
agent to return it, or would 1.2.3.4.5.1 be sufficient?
Frank Fock wrote:
Hello Jeff,
Scalars have to be registered with an .0 instance
identifier. Thus, try 1.2.3.4.5.1.0 and
1.2.3.4.5.2.0 and there will be no duplicate
registration error. The scope is a range
of OIDs with a lower and upper bound (exclusive
or inclusive).
Best regards,
Frank
Jeff Ramin wrote:
Hello again folks.
Could somebody please explain the concept of scope when it comes
to managed objects? I seem to be missing some vital information.
I'm using the DefaultMOServer to register MOScalars. I register one
object w/ an OID of 1.2.3.4.5.1 and then try to register another
object with 1.2.3.4.5.2, at which point I get a DuplicateRegistration
exception.
What am I missing? How to I specify that the scope of the first managed
object is its particular OID and not a range?
Thanks!
--
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com
_______________________________________________
SNMP4J mailing list
[email protected]
http://lists.agentpp.org/mailman/listinfo/snmp4j
