Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!netxcom!jpoller From: jpoller@netxcom.netx.com (Jack Poller) Newsgroups: comp.protocols.tcp-ip Subject: Re: What are the rules for Object Instances? Summary: access methods, naming Message-ID: <438@netxcom.netx.com> Date: 4 Jun 91 13:46:18 GMT References: <23109@shlump.lkg.dec.com> Organization: NetExpress Inc., Vienna, VA, USA Lines: 79 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!jpoller