Rob,
First, you should have used the SNMP trace before the packet trace. You will
find the output very user-friendly but, according to what you report, it
looks as if your packet trace analysis "understands" SNMP very well - I
wonder if it might be "too well" (?)
Your guess is quite wrong. The MIB description is to translate the SNMP
numbers into names and, in the "official" format, to offer the possibility
to provide some human-readable explanation concerning any one MIB variable.
This is information for the SNMP manager and so is something your "non-IBM
NMSs" will need, assuming this is your shorthand for your SNMP managers (NMS
= "network management station"?)
The SNMP agent on the other hand needs no help "understanding" a MIB
variable for which it is responsible since it has to have embedded within
it - or a subagent which it accesses - the logic necessary to extract the
value of the MIB variable on request from a GetRequest and encapsulate it in
a GetResponse.
Thus "compiling" a MIB is something which is of interest only to the SNMP
manager. It is very likely that the documentation associated with your SNMP
manager will talk about this MIB description "compilation" process.
Note that there are three flavours of "SNMP manager" which run on z/OS. The
oldest ,of which I have some experience, encompasses the NetView SNMP
command which uses the SNMPQE procedure. The MIB description file for this
"SNMP manager" goes by the generic name of MIBDESC DATA (in recognition of
the TCP/IP for MVS product having a VM origin). The other two, the newer
NetView SNMP command and the OMVS OSNMP command, require other files. From
other threads and from a bit of reading - for those other threads - I
believe the newer NetView SNMP command performs some sort of "compiling" at
the time the command is issued.
At the end I've added the text from another post which - to some extent -
explains this further.
The consequence with all SNMP managers of not having a name to numbers MIB
description file which covers a particular MIB variable is that you cannot
use the name in the GET request and any GET response will not be able to
provide the name. That is all. Since you are able to use sysDescr (and
sysDescr appears in the response) you have managed to "install" the MIB
description file appropriate for your "SNMP manager", the OSNMP command.
Mr HTH or Capomaestro - however he might wish to be addressed - may - I'll
be generous and say "wittingly" - have hinted at a possible reason for your
problem. In the days when I played with CS IP SNMP, a value for sysDescr was
not available for specification, only for sysContact and sysLocation and
they were specified in TCPIP PROFILE (still using the original VM names).
With OSNMPD there is an alternative and that now allows the specification of
sysDescr. This is the OSNMP.DATA file which Mr HTH or Capomaestro wanted you
to know how to find. However, the evidence is now contradictory. If you did
not know that sysDescr was there, how is it you do not retrieve the default
value, "SNMPv3 agent version 1.0 with DPI version 2.0", from the sample in
the manual - and the first non-comment statement in the file? If you did
know that sysDescr was there - and deleted it, how is it you are puzzled
over it not being available? Perhaps you have a colleague who thought it
unnecessary and is him/herself not available right now :-) (I'm assuming, of
course, quite reasonably in my opinion, that a missing sysDescr will result
in a "noSuchName" response.
Perhaps you should try for sysUpTime as something entirely under control of
the OSNMPD SNMP agent. From my SNMP package - easier to find than googling
for the relevant RFC - I see there are 6 "sys" MIB variables and the other
5, including sysDescr, are available for "customization", which, except for
sysObjectID, includes deleting them altogether. (sysObjectID has a default
but that default is obtained from a subagent which offers another
opportunity to get in a mess. As Pat noted, the "sys" group, in general is
directly supported by the main SNMP agent. Having made that point, the other
MIB variables, in fact a MIB group, you can rely on always to be there from
a working OSNMPD SNMP agent is - probably a subset of - the - dare I say
"incestuous" - SNMP group: 1.3.6.1.2.1.11.1, .3, .4, .5, .6, .30, .31 and
.32.)
Regarding reading manuals, I hope you have found Appendix B. "Management
Information Base (MIB) objects" of the z/OS CS IP System Administrator's
Commands manual.
Quite a while ago now I consulted for a project getting OSA-Express features
running which also included getting the SNMP agent (OSNMPD) running. (I also
got the SNMP manager within NetView running at the same time which might be
handy for you as a way of taking small steps on the way to your "eventual
goal".) I noted in the sequence of tests I wrote down for use in the
Saturday evening/Sunday morning change slot that, to check out the SNMP
customization, I first tried using 127.0.0.1 on the same system before
trying from the system which would be used as a management LPAR.
Hm, I thought I'd finished but then I spotted the "community name" variable
in my test command. Perhaps you should be clear that this response doesn't
correspond to an invalid community name. I'm reminded of a VM trick where
entry of an unauthorised command resulted in a response claiming that the
entered command didn't exist - as some sort of security measure.
---
I have found 4 types of these MIB description files.
1. There is a formal means of describing MIBs, of which an example is
section 4 of RFC 2358. This I have seen used in the old NetView for AIX or
NetView/6000 product which now has a Tivoli label. Here you took one of
these formally constructed description files and "compiled" it into some
internal format suitable for the SNMP manager program component by
"importing" the MIB file, a MIB file which could simply have been copied
from the RFC text.
2. There is a way of describing the MIB using the MIBDESC DATA file (to give
it its original VM file name). This is a file which SNMPQE needs to be able
to find so that it could translate the dotted decimal OID into a MIB
variable name, for example, 1.3.6.1.2.1.10.7.2.1.2.n to
dot3StatsAlignmentErrors.n. Clearly it also permits the reverse mapping.
3. For the benefit of the relatively new CS IP SNMP manager, there is the
MIBS.DATA, or mibs.data, file. (From here I'm describing what I think rather
than what I know for certain just in case I'm leading anyone astray.) As far
as I can tell - using amazingly different names - the MIBDESC DATA line
format and the MIBS.DATA line format are the same, as long as you get rid of
the time_to_live number from the MIBDESC DATA line format.
4. For the relatively new NetView CNMESNMP command there is a process which
looks like it could be similar to 1, namely MIB description files are placed
in a directory, /etc/netview/mibs, quite a straightforward sort of a name if
you are "into" the UNIX way of doing things.
Again I'm having to advise based purely on what I find in a manual. In this
case the manual is "Installation: Configuring Additional Components". Here
job CNMSJ032 arranges to copy MIB description files from
/usr/lpp/tcpip/samples to /etc/netview/mibs. I believe this, rather than
"compiling", is simple copying - based on the absence of possible "compile"
error return codes as far as I can tell. I guess this so-called "job" is a
UNIX script so it should be very easy to see what it does.
The NetView SNMP command, which is an alias of CMNESNMP, enables
specification of the MIB description file or files to be used in conjunction
with the command. Checking NetView Command Reference Vol. 1, I see both -m,
the actual MIB description files to be used can be specified, default
assumed to be all MIB description files found in the specified
directory/directories, and -M, the directory or directories containing the
MIB description file, default assumed to be /etc/netview/mibs.
Thus it appears that, each time the SNMP command is used, these MIB
description files are "compiled". This contrasts with the NetView for AIX
approach which has a separate step, prior to use, of "importing" a MIB
description file and "compiling" it at that time - if my memory of all this
is sound after 10 years or so.
Digging deeper I notice an "output option" -OPw or -OPW (this is clever old
UNIX after all!) which, significantly, prints errors found while "parsing" a
MIB source file, "source" being this manual's word where I use the word
"description".
What I cannot check is whether these MIB description files are the "open",
expanded version (as used by 1 above) or line per OID versions (like 2 and 3
above). A simple browse of one of the files can sort that point out.
Eventually I found the description of the FKXECNVT utility (see later) which
strongly suggests the "open", expanded format.
If it turns out to be the "open", expanded version, this can be very
liberating when the problem of where to find an appropriate MIB description
file arises. Assuming the missing MIB description file corresponds to an
RFC-defined MIB module, just go to the latest RFC for the desired MIB on the
web and copy the section of the file which holds the fancy descriptions with
the curly brackets, double dashes and double colons, for example, section 4
in RFC 2358. Astute reading will indicate that, like anything a dumb
computer needs to understand, it starts with "BEGIN" and ends with "END".
Finally there are "revision bars" against all of this stuff so it looks like
we are out there with the pioneers - with the attendant threat of arrows
coming from behind - with this apparently new NetView facility.
<end of 4>
When I used to work with MIBDESC DATA files, or, since it was MVS,
tcpiphlq.MIBDESC.DATA files, I seem to remember having to merge any
additional lines into the file in OID order. This makes sense for a simple
lookup. I can only now imagine that you need to take the same approach if
you need to merge MIBS.DATA files.
I now quote the CS IP Configuration Reference manual: "The MIBS.DATA
statements can be used to specify character (usually called textual) names
for MIB objects not defined in any compiled MIB supplied with z/OS
Communications Server.". Thus, unlike MIBDESC DATA, you need only supply a
MIBS.DATA file containing descriptions corresponding to your one or more
additional SNMP subagents.
So, assuming IOBSNMP supports the only additional subagent and you he want
to use the CS IP SNMP command, you need only identify the OSA file as the
MIBS.DATA file, perhaps having checked it has the expected format.
Benefiting from scanning the NetView "Installation: Configuring Additional
Components" manual on page 124 I found the following:
Using FKXECNVT to Convert MIBs
------------------------------
To use the FKXECNVT utility, perform the following installation steps:
- The FKXECNVT module is shipped in the CNMSAMP sample. Copy the sample to a
data set in the SYSPROC concatenation for your TSO user ID.
- Sample file FKXMOBJ is required to convert MIB files to MIBS.DATA files.
Access this file directly from CNMSAMP or move it to a read/write data set
accessible from your TSO user ID.
For more information, refer to Tivoli NetView for z/OS Automated Operations
Network Customization Guide.
<end of quote>
One can get quite confused jumping between the CS IP and NetView platforms
for SNMP management but this is extreme! However it answers the need to
convert the presumably "open", expanded form of the MIB description files to
the one line per OID MIBS.DATA format.
The reason I make a fuss about theses MIB description file formats is that
it's expected of an SNMP subagent implementation that it provides the MIB
description in the "open", expanded format so that programs like NetView for
AIX can understand the data supplied by the supported MIB module, in other
words, it's the format general purpose SNMP managers on any platform expect
to use.
The way you know you are missing some MIB description data is to start an
SNMP "walk" from the very beginning to the very end of the MIB and then
check that every retrieved MIB variable is given a name. By preference this
should be done to an SNMP agent on a test system which is representative of
your production systems.
---
Chris Mason
----- Original Message -----
From: "Mergner, Robert A." <***@ibx.com>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMTCP-***@VM.MARIST.EDU>
Sent: Monday, 06 February, 2006 10:56 PM
Subject: [IBMTCP-L] Help with SNMP
My eventual goal is to set up SNMP agents on my zOS LPARs that can be
queried by non-IBM NMSs on other platforms (Windows, Unix, etc.).
My first step is to build an SNMP agent (OSNMPD) on a test LPAR and then
GET a standard MIB variable (such as sysDescr) using the OMVS command
OSNMP on another zOS LPAR. I did that and the response that I get back
is "sysDescr 1.3.6.1.2.1.1.1 noSuchName". A TCPIP packet trace shows
the GetRequest go out and the GetResponse comes back. The GetRequest
looks OK to me and the GetResponse certainly indicates "noSuchName".
I am guessing that the problem is that the agent cannot find any MIB
descriptions which causes the "noSuchName" although the command did
translate "sysDescr" into "1.3.6.1.2.1.1.1". I have read (and re-read
and re-read) the IBM materials (and some others) and I have not figured
out how the MIB thing works. The materials talk about "compiling" the
MIBs but don't say how. Are the standard and IBM-supplied MIBs already
compiled and available? Are the compiled MIBs in a table in load module
form in a load library or are they a text format in a USS file? Are
they already available or do I have to "load" them?
Thanks,
Rob Mergner
Independence Blue Cross
215-241-9090
***@ibx.com
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L