Analysis

Use the following checklist to check for unknown variables at the SNMP agent:
  1. Was the variable requested with the correct instance number?

    Variables that are not in a table have an instance number of 0. Variables that are part of a table might have more than one occurrence of the variable value. To get the value of the variable, you need to request a specific instance of the variable. To find the instance number, issue a GET NEXT request; the first occurrence of the variable should be returned.

  2. If the variable is not defined in any compiled MIB, is the variable name included in the MIBS.DATA file (for the snmp command) or the hlq.MIBDESC.DATA file (for the NetView® SNMP command)?
  3. Did the DPI connection come up successfully?
    1. Check the SNMP agent job output for messages indicating a problem in create_DPI_port.
    2. If the DPI port was not successful, no SNMP subagents are able to register MIB variables. The SNMP agent has no knowledge of these unregistered variables and reports them as noSuchName for SNMPv1 requests or noSuchObject for SNMPv2 and SNMPv3 requests.
  4. Has the subagent successfully connected to the SNMP agent?
    1. For subagents shipped as part of z/OS® Communications Server, check the MVS™ operator console for a message indicating that the subagent has completed its initialization.
    2. Issue an snmp walk command on the SNMP agent subagent status table. For example, either of the following commands display the subagents that are connected to the z/OS Communications Server SNMP agent and the status of their connections:
      • snmp -v walk saDescription
      • snmp -v walk saStatus
      A value of 1 for saStatus indicates that the subagent connection to the SNMP agent is valid. Following are other possible status values: 
      invalid                 (2)
connecting              (3)
disconnecting           (4)
closedByManager         (5)
closedByAgent           (6)
closedBySubagent        (7)
closedBySubAgentTimeout (8)
closedBySubAgentError   (9)
  5. If the SNMP agent was configured with SNMPv3 security, is the object within the MIB view of that allowed for that user or community?
    1. Look at the agent SNMPD.CONF file to determine to which VACM_GROUP the user or community name on the failing request belongs. Then examine the VACM_ACCESS statements for that group for the level of security requested on the failing request to determine which MIB views have been permitted to the user or community name.
    2. Alternatively, SNMP agent configuration can be determined from SNMP agent traces if they were set to level 255 at agent initialization.
    3. SNMP agent configuration can also be determined dynamically by issuing snmp walk requests against the agent configuration MIB objects, such as the vacmSecurityToGroupTable and the vacmAcessTable. Reading the values in these tables requires an understanding of how the tables are indexed. See Requests for Comments (RFCs) 2573, 2574, and 2575 for an explanation of the MIB objects containing the SNMP agent configuration.

If the problem still occurs after checking the preceding items and making any needed changes, obtain the following documentation:

For variable not recognized by manager messages:
  • If the manager is the z/OS UNIX snmp command, use the -d 4 option to obtain all manager traces.
  • If the manager is the NetView SNMP command, obtain the SNMP query stack level two output. The SNMP query stack level two trace shows the information flowing between the SNMP query stack and the SNMPIUCV subtask of NetView. Verify in the trace that the variable name being requested is being passed correctly to the SNMP query stack.
For agent unknown variable:
  • SNMP agent level 15 trace output
  • Traces from SNMP subagent programs (if the variable is supported by a z/OS Communications Server subagent)
The SNMP agent level 15 trace shows PDUs between the manager and agent, as well as between the agent and any existing subagents. Look for the following in the trace:
  • Is the ASN.1 number received from the manager in the SNMP GetRequest-PDU correct?
  • Has a DPI packet registering the requested variable been received?
    1. If not, if you know which subagent program owns the variable, check the subagent program for errors.
    2. If the DPI register has been received, make a note of the FD number for further trace information.
  • Were any errors reported for this FD number after the DPI register request was received?
  • Was there a DPI information exchange over this FD number as a result of the incoming SNMP GetRequest-PDU?
Another approach to this problem is to look at the agent saMIB variables. This information can be useful when traces are not available. The saMIB variables include the following information:
  • An entry for each subagent (including a field for subagent status)
  • A table of all trees registered, including:
    • Subagent to which the tree is registered
    • Status of the tree (valid, not valid, and so on)
A description of the saMIB objects can be found in the file samib.mib in the /usr/lpp/tcpip/samples directory.
The following documentation might also be needed in some cases, but it is suggested that the IBM® Software Support Center be contacted before this documentation is obtained:
  • Dump of SNMP agent address space
  • Dump of the subagent responsible for the MIB object whose value is being returned incorrectly.
    • Dump of TCP/IP address space (for TCP/IP and TN3270E Telnet subagent variables)
    • Dump of OMPROUTE address space (for OMPROUTE subagent problems)
    • Dump of Network SLAPM2 subagent address space (for Network SLAPM2 subagent problems)
    • Dump of user subagent address space

Information about obtaining a dump can be found in z/OS MVS Diagnosis: Tools and Service Aids. Obtaining SNMP traces is discussed later in SNMP traces.

Parent topic: Unknown variable