jc@netrix.nac.dec.com (06/03/91)
Here's my dumb question of the week: We have a bunch of people working with SNMP, and one thing that has people confused is the "Object Instance", which apparently is the name for the funny zero that is appended to most (but not all) Object Identifiers. We have determined by experiment that with various agents lurking about on the network, this extra zero octet is sometimes required, sometimes optional, and sometimes forbidden. But we haven't yet intuited the pattern, and TFM (the RFCs, Marshall Rose's "Simple Book", etc.) seem to think that this is so obvious that it isn't worth explaining. It isn't obvious to us, and existing agents seem to follow a variety of rules. Does anyone know what the rules are for the use of this extra zero? When is it required? When is it forbidden? Or is it just an idiosyncracy of the various agents? Also, since it is (in our experience) always zero, is there an explanation (other than sheer perversity ;-) that it is there at all? Can it ever be nonzero? For instance, many agents require that the sysDescr be requested as 43.6.1.2.1.1.0 or they won't respond, while others don't need the zero. (Some will also accept 1.3.6.1.2.1.1, but that's a different problem. :-) There seems to be no obvious meaning to multiple (i.e., different) values for this variable, so why would an instance ever be needed? Is there some rule in the RFCs that covers this, so we can point at some of the agents and say "You're doing it wrong" and possibly get it changed so they're all the same? Or is it just a weirdness that we have to learn to live with? It ain't easy writing clients when the agents out there are inconsistent. But maybe if we understood the rules better...
rlstewart@eng.xyplex.com (Bob Stewart) (06/04/91)
I would have responded directly to the questioner, but the address full of !s and dec.coms scared me off. Besides, the answer may be of general interest. SNMP object instancing is designed to be simple and regular, so, in a sense, every object has an instance identifier, whether it can actually have multiple instances or not. To completely identify the object, that instance identifier goes on the end of the object identifier. For an object with only one possible instance, such as sysDescr, the instance ID is 0. For an object with multiple instances, such as ifSpeed, the instance identifier suits the object and is non-zero. The instance identifier for an interface is ifIndex, a small integer, which gets tacked onto the end of the ifSpeed object identifer to say which instance you want. A zero on the end of ifSpeed is not valid. A non-zero on the end of sysDescr is not valid. So why is the observed behavior confusing? It may be bugs or it may be agents that are trying to be extremely tolerant. It also may be the difference between get and get-next. Strictly speaking, for get and set you must supply the entire object identifier, including instance identifier. On the other hand, get-next is so powerful, you can leave off as much of the object identifier as you want to, and the agent will find what's lexically next. A handy result of this power is that you can get-next an object identifier with the instance completely missing, and get-next will return the first instance of that object. Using that full object identifier in your next get-next will get you the 2nd instance, and so on until there are no more instances and you'll get whatever lexically follows the last instance. You can thus discover all the instance identifiers. I hope that helps. Once you're immersed in this stuff it's easy to forget what it took to get that far under. Bob
jpoller@netxcom.netx.com (Jack Poller) (06/04/91)
In article <23109@shlump.lkg.dec.com> jc@netrix.nac.dec.com writes:
#Here's my dumb question of the week: We have a bunch of people working
#with SNMP, and one thing that has people confused is the "Object
#Instance", which apparently is the name for the funny zero that is
#appended to most (but not all) Object Identifiers. We have determined
#by experiment that with various agents lurking about on the network,
#this extra zero octet is sometimes required, sometimes optional, and
#sometimes forbidden. But we haven't yet intuited the pattern, and TFM
#(the RFCs, Marshall Rose's "Simple Book", etc.) seem to think that
#this is so obvious that it isn't worth explaining. It isn't obvious to
#us, and existing agents seem to follow a variety of rules.
#
#Does anyone know what the rules are for the use of this extra zero?
#When is it required? When is it forbidden? Or is it just an
#idiosyncracy of the various agents?
#
#Also, since it is (in our experience) always zero, is there an
#explanation (other than sheer perversity ;-) that it is there at all?
#Can it ever be nonzero?
#
#For instance, many agents require that the sysDescr be requested as
#43.6.1.2.1.1.0 or they won't respond, while others don't need the
^^^^^
Assuming typo - should be 1.3.6.1.2.1.1.0
#zero. (Some will also accept 1.3.6.1.2.1.1, but that's a different
#problem. :-) There seems to be no obvious meaning to multiple (i.e.,
#different) values for this variable, so why would an instance ever be
#needed?
#
#Is there some rule in the RFCs that covers this, so we can point at
#some of the agents and say "You're doing it wrong" and possibly get it
#changed so they're all the same? Or is it just a weirdness that we
#have to learn to live with? It ain't easy writing clients when the
#agents out there are inconsistent. But maybe if we understood the
#rules better...
A number of different problems appear to be occuring.
1. Two different access methods:
Remember that SNMP supports both GET and GET-NEXT. The get access
method will access ONLY the explicitly named object instance.
While the get-next access method will access the next object
instance in lexicographical order from the named object instance
get sysDescr returns ERROR
get sysDescr.0 returns sysDescr.0 = "SNMP Agent 1.1"
getnext sysDescr returns sysDescr.0 = "SNMP Agent 1.1"
getnext sysDescr.0 returns sysUpTime.0 = 14123
The confusion over the two access methods can lead to the
assumption that the instance name is sometimes optional, as there
are two methods to obtain the object instance for sysDescr.
2. Object Instance Naming Rules
The best bet is to read the RFC's quite carefully, as the rules are
well explained. Since I have not dealt with this aspect in 2
months, I won't try to confuse you.
3. Object Instance Names are often non-zero, especially when used in
Tables. Any easy table to study is the Address Translation Tables.
My suggestion to understanding this is to find or build a mib-tree
walker or browser. A mib-tree walker that can take its return value
as the next argument for get-next would be ideal. In this manner you
would be able to see the entire tree implemented by a given agent.
For instance:
getnext 192.1.1.1 public system sysDescr.0 = "SNMP Agent 1.1"
getnext 192.1.1.1 public sysDescr.0 sysUpTime.0 = 123456
.....
Jack L. Poller
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jack L. Poller (703) 749-2240 Telex 901976 G3 Fax (703) 749-2375
NetExpress, Inc., 1953 Gallows Road, Suite 300, Vienna, Virgina 22182
...!uunet!netxcom!jpollerkzm@hls.com (Keith McCloghrie) (06/05/91)
Bob, Your explanation was accurate, but you may have conveyed an impression you didn't intend: > For an object with > multiple instances, such as ifSpeed, the instance identifier suits the object > and is non-zero. This is indeed true for ifSpeed. However, there is nothing which prohibits the definition of an instance identifier (i.e. a MIB table's INDEX variable) which can take the value of zero. The closest to an example of this in the core MIB (i.e. MIB-II) is the IP Routing Table. Instances of objects in the IP Routing Table take the associated route's destination as their instance identifier. For a "default route", the instance of each object has the instance identifier of 0.0.0.0 (i.e. four OID sub-identifiers each of which has the value of zero). Keith.
rlstewart@eng.xyplex.com (Bob Stewart) (06/06/91)
>Bob, > >Your explanation was accurate, but you may have conveyed an impression >you didn't intend: {Good stuff deleted} >Keith Actually, I said what I meant but I was slightly wrong. Now I'll remember that an instance identification can be zero. It was a detail that never sunk in. Thanks for keeping it straight. Bob