IBM Support

IBM i SNMP Overview



How do I use SNMP on an IBM i (iSeries, AS/400) system?
This document provides an overview of SNMP on the IBM i. It is divided into the following sections:

Resolving The Problem

Simple Network Management Protocol (SNMP)

1. Brief History of SNMP

In 1988, a working group was set up to define a set of technologies that would allow network administrators to remotely monitor and manage TCP/IP network devices. The result was SNMP (Simple Network Management Protocol), and it has two roles:
1. Universal method of defining management information.
2. Universal method of communicating that information between network devices and the network management device.

The following three major versions of SNMP are available:
  • SNMPv1
  • SNMPv2 (splintered into many variants of which the most common variant is SNMPv2c)
  • SNMPv3

2. Helpful Terminology
* SNMP Manager - Application that can query TCP/IP network devices by using SNMP.
* SNMP Agent - Listener code installed on managed network devices to accept and respond to requests from the SNMP Manager.
* SNMP SubAgent - Interfaces with the SNMP agent to expand the number of MIB objects that an SNMP manager can access.
* MIB - A Management Information Base (MIB) is a logical database residing in the managed system that defines a set of MIB objects. A MIB is considered a logical database because actual data is not stored in it, but rather provides a view of the data that can be accessed on a managed system. Standard MIBs have their structure defined by an RFC (Request For Comments). For example, MIB-II (or MIB-2) is defined by RFC 1213.
* OID - A MIB Object Identifier (OID) is a unit of managed information that specifically describes an aspect of a system, for example, CPU utilization, software name, hardware type, and more. A collection of related MIB objects is defined as a Management Information Base (MIB). A MIB object is sometimes also called a MIB variable. It can be referred to by using a short name (for example, sysContact), or by use of the canonical form (for example,
* SNMP Trap - An SNMP trap is a message that is originated by an agent application to alert a managing application of the occurrence of an extraordinary event.
Managing systems generate SNMP requests, and agent systems generate responses to these requests. After a request message is sent, SNMP does not need to wait for a response. SNMP can send other messages or realize other activities. These attributes make SNMP an asynchronous request and response protocol. An agent system can also generate SNMP messages called traps without a prior request from the managing system.

3. Support for SNMP on the IBM i

The IBM i operating system provides an SNMP Agent and APIs. These APIs can be used to build SNMP management and SNMP subagent applications.
It has support for the following versions:

  • Implemented on the AS/400 in OS/400 R320 and R360.
  • Based on Internet RFCs:

  • RFC 1157 Simple Network Management Protocol (SNMP)
    RFC 1155 Structure and Identification of Management Information for TCP/IP-based Internet.
    RFC 1212 Concise MIB Definition
    RFC 1213 Management Information Base for Network Management of TCP/IP-based Internet: MIB-II
    RFC 1215 Convention for Defining Traps for use with SNMP
    RFC 1280 IAB Official Protocol Standards
    RFC 1340 Assigned Numbers
  • Security based on Community Name
  • CFGTCPSNMP command to access configurable parameters
SNMPv2 (Note: No support for SNMPv2c)
Support for the original SNMPv2 build was implemented. However, work on SNMPv2 quickly splintered into a number of variants. The most commonly accepted of these became SNMPv2c, and the IBM i has no support for this variant. Most SNMP managers use SNMPv2c, and so in practical terms, unless the SNMP manager supports the base SNMPv2 version, SNMPv2 is not usable with the IBM i.

  • Support for SNMPv3 was added at R710, primarily to provide IPv6 functionality for SNMP
  • The IBM i supports a User-based Model for Security (USM). No support currently for View-based Security
  • Major driver for SNMPv3 was to improve the security of exchanges between Manager and Agent. This is achieved by introducing Encryption and Privacy protocols to secure exchange of UserID and data exchanges
  • SNMPv3 must be enabled on the system before it can be configured and used

The SNMP agent listens on port 161 and can be started by running STRTCPSVR *SNMP. It can be configured to autostart with TCP.

MIBs shipped with the IBM i
Standard MIBs
  • MIB-2 (RFC 1213)
    Describes those objects that are implemented by managed nodes running the Internet suite of protocols. IBM i implements 9 of the 10 MIB-2 groups.
    - System (mandatory, information such as system name, location, and contact information)
    - Interfaces (mandatory, information about the interfaces on the agent system)
    - Address Translation (deprecated, but mandatory for compatibility with MIB-1 nodes)
    - IP (mandatory, protocol information such as number of datagrams sent/received) - (updated by RFC 4293 and RFC 4292)
    - ICMP (mandatory, ICMP information such as the number of ICMP Echo (PING) messages received)
    - TCP (mandatory for all systems that implement TCP) - (updated by RFC 4022)
    - UDP (mandatory for all systems that implement UDP) - (updated by RFC 4113)
    - EGP (mandatory for all systems that implement EGP – IBM i doesn’t support EGP)
    - Transmission (mandatory, information about transmission protocols being used - broken down into Ethernet-like (RFC 1398), FDDI (RFC 1285), Frame Relay (RFC 1315), and Token Ring (RFC 1231)
    - SNMP (mandatory for all systems supporting SNMP protocol – information such as the number of SNMP requests received with an unknown community name)
Defines a uniform set of objects useful for the management of host computers and which are common across many computer system architectures. Broken down into:
- hrSystem (i.e. system UpTime, no. of users, contacts and system date)
- hrStorage (i.e. system memory size and DASD space available)
- hrDevice (i.e. information on system devices such as disk units, printers, processors, etc)
- hrSWRun (i.e. software running on the system including name and level)
- hrSWInstalled (i.e. software installed on the system - similar to output provided by DSPSFWRSC)
NOTE : hrSWRunPerf (information on system's CPU performance) is not supported on the IBM i. However, hrProcessorLoad does show the average load on the processor during the period since this OID was last queried.
  • SNMP SubAgent
Enterprise MIBs
  • Enterprise MIBs
    SNMP permits vendors to define MIB extensions or enterprise-specific MIBs, specifically for monitoring and controlling their products.
    Before an SNMP manager can access an enterprise MIB, the MIB description must be loaded into the manager.
    Each of the system shipped Enterprise MIB modules on the IBM i is contained in a member of physical file QSYS/QANMMIB
    FTP can be used to transfer the member over to an ASCII text file to load into the SNMP manager
    Most of the information in the Enterprise MIBs shipped with the IBM i can now be considered deprecated

    IBM Enterprise MIBs on IBM i
    • APPN MIB
    • Client Management MIB (deprecated)
    • NetView/6000 SubAgent MIB - Only one MIB object here is supported, nv6saComputerSystemLoad - it can provide the average percentage of load (processor usage) during the elapsed time
    • Remote Workstation MIB - information about 5494 remote workstation controllers attached to the AS/400 (deprecated)

APIs are provided to give SNMP Manager support and to create/add SNMP subagents. These APIs are documented on the IBM Knowledge Center at

The IBM i can send SNMP Trap messages to a defined SNMP Trap Manager (configured by using CHGSNMPA). IBM i Alert Support can be configured to send alerts by using SNMP traps. However, the SNMP Trap Manager must be able to interpret the alert data for this to be useful. (See technote N1019631 for further details.) SNMP Traps are sent by using SNMPv1, although support has now been added at IBM i V7R4M0 which allows SNMP traps to be sent by using SNMPv3.  The same release also introduced the ability for SNMP Informs to be sent.  (SNMP Informs are SNMPv3 only, and can best be considered as an acknowledged SNMP Trap, in that the SNMP Trap Manager needs to send an acknowledgment back to the SNMP agent when it receives an SNMP Inform)

The IBM i can be configured as an SNMP Trap Manager. The SNMP Trap Manager job needs to be started with the STRTRPMGR command. APIs are supplied to build an SNMP Trap Manager on the IBM i to do something with received SNMP Traps, or STRTRPMGR can specify to forward received SNMP Traps onto the configured SNMP Trap Manager in CHGSNMPA.
The SNMP Trap Manager listens on port 162.  Starting at IBM i R740, it is possible to have the SNMP Trap Manager autostarted with SNMP via settings in the SNMP Attributes (CHGSNMPA)

SNMP Traps are defined in RFC 1215. SNMP Traps that can be generated on the IBM i are as follows:
* coldStart - SNMP agent is reinitializing and configuration may have been altered
* warmStart - SNMP agent is reinitializing but configuration has not been altered
* linkDown - an interface has been deactivated
* linkUp - an interface has been activated
* authenticationFailure - an SNMP user has attempted to access the agent without the correct credentials (can be turned on/off by using CHGSNMPA)
* enterpriseSpecific - a placeholder that allows SNMP agent or subagent implementations to create enterprise-specific traps
  4. Configuring SNMP on the IBM i

Use command CFGTCPSNMP Option 1, or CHGSNMPA (and F4 to prompt) to configure the SNMP attributes

The parameters on this screen determine the facilities and behavior of the IBM i SNMP Agent.

System description: If the PTFs for APAR SE66509 are applied (from R710 and above; or R740 in base code) and if the Additional Information parameter is configured for *SYSD, any text added to this field will be appended to the value retrieved by a managing system viewing the SysDescr MIB Object of MIB-2.  (See APAR SE66509 or R740 Knowledge Center for additional detail.)

System contact: This field should contain the name and contact information of the person responsible for the operation of this AS/400. The data entered here can be retrieved by a managing system by viewing the sysContact MIB object of MIB-II. If you choose to enter *CNTINF in this field, the managing system will then retrieve the data entered in the service contact information. You can view this information by entering the following command: WRKCNTINF

System location: This field should contain the physical location of the AS/400. The data entered here can be retrieved by an SNMP manager by viewing the sysLocation MIB object of MIB-II.

Send authentication traps: This field enables the AS/400 to report, without any request from a manager, any authentication failures to the manager. That is any incoming request from a manager not belonging to a community that is recognized by the AS/400 SNMP agent is reported.

Automatic start: This field determines whether the SNMP agent is started when TCP/IP is started. If it is not, you must then run the following command: STRTCPSVR SERVER(*SNMP)

Object access: This field allows you to decide whether SNMP managers that are part of a recognized community have read only, read and write or no access rights (*READ, *WRITE or *NONE) to MIB objects on this system. The value entered here can be either used by, or overridden by, the same parameter in the community attributes. Note: The default value in the community attributes is *SNMPATR which picks up the value you specify here. For security reasons it may be advisable to specify *NONE in the SNMP attributes and use the community attributes to grant specific object access rights.

Log set requests: See Log trap requests.

Log get requests: See Log trap requests.

Log traps: The Log set requests, Log get requests and Log traps parameters specify whether these three activities are logged in a system journal, QUSRSYS/QSNMP. If this journal does not exist on the system, it will be necessary to manually create the journal and journal receiver.

Trap managers: The Trap managers parameter specifies which SNMP managers will receive the traps generated by this system. You may need to ask your network administrator for the internet address and community name of the system to which traps are to be sent. You can specify multiple managers in this field.

Translate community name: This field is set to *YES if the community name should be translated into ASCII characters before it is placed into the trap. Specify *YES if all the characters can be translated into ASCII. This would be appropriate if you were sending a trap to an ASCII-based system.
Local trap manager (V7R4M0 and above only): Ability to specify if the trap manager is started with the SNMP agent (instead of running the STRTRPMGR command), and if received traps are to be forwarded to another SNMP Trap Manager.  See the F1 Help text for further details of these parameters.

Allow SNMPv3 support: This field is set to *NO by default. If you want to enable SNMPv3 support, set this to *YES. See technote N1000041 for further details on configuring SNMPv3.
Note: From V7R4M0, it is also possible to specify *ONLY as a value here to only allow the SNMP agent to process SNMPv3 requests, and reject any SNMPv1 requests

SNMP engine identifier: This field relates to using SNMPv3. See technote N1000041. Recommended to use *SYSGEN when configuring it. Incorrectly setting the SNMPv3 Engine ID may prevent the SNMPv3 manager from communicating with the agent.

SNMP engine boots: This field relates to using SNMPv3. It should not be changed unless it becomes necessary to reset it to 0, and should not be done while SNMP is active, or it may cause authentication errors.

Block size: This field provides new function (requires latest PTFs applied) to allow you to change the block sizes used to report the sizes of storage pools (hrStorageTable) and disk units (hrDiskStorageTable) in the Host Resources MIB. Useful on systems with large amount of attached storage. Note that *DFT for storage pools means that the system determines the block size used. For disk units *DFT means that a block size of 1024 is used. If the block size is changed with CHGSNMPA, the SNMP server must be ended and restarted in order for the new block size to be used by the agent.
Additional Information: (Available with APAR SE66509) Specifying *ASPNBR for this parameter will add the ASP number to end of  predefined text returned for the hrStorageDesc field when retrieving the hrStorageTable.  Specifying *SYSD will append the text specified by the SYSD parameter of the CHGSNMPA command to the predefined text for the sysDescr value returned by the SNMP agent.  The ADLINF parameter allows multiple values to be specified, so both *ASPNBR and *SYSD can be specified at the same time.

To configure the IBM i as an SNMPv1 agent, a valid community must be defined by using either CFGTCPSNMP Option 2, or the ADDCOMSNMP or CHGCOMSNMP commands. The 'public' community is defined by default. Because this is a well-known community name across all SNMP platforms, it can sometimes be considered a security issue by audit or compliance programs. The community name is case-sensitive. You can configure which SNMP managers are allowed to access the system by using the community name, and override the CHGSNMPA settings for Object Access and SNMP journaling for each community defined. Both the SNMP manager and the SNMP agent need to be using the same community name.

To configure the IBM i as an SNMPv3 agent, you should refer to technote N1000041.
5. Securing SNMP on the IBM i

SNMPv1 is inherently insecure. Many compliance scanning tools will callout an issue if they detect SNMPv1 running on the system (see section above) with community name 'public'. SNMPv1 traffic is sent out over the network in plain text, so anyone with the ability to "sniff" the data on your network would be able to see which community was being used, and the IBM i responses to data requests.

You can make SNMPv1 less easy to gain access to by creating your own SNMPv1 communities and then using these on the IBM i agent and your SNMP manager; and then either removing the 'public' community, or changing it to have object access *NONE : i.e. running the CHGCOMSNMP COM('public') OBJACC(*NONE) command. You can further secure the community by specifying which SNMP managers are allowed to communicate with the agent using this community name.
If a system other than the ones defined attempted to get information via SNMP, it would not receive a response (and an authentication trap would be issued to any defined SNMP trap managers if enabled).

To make SNMP much more secure, you should consider configuring SNMPv3 (see reference to technote N1000041 above). SNMPv3 allows for the creation of SNMP users and the ability to encrypt both the user name and the data using authentication and privacy protocols. However, because of this additional security, SNMPv3 is more difficult to set up than SNMPv1. 
With IBM i V7R4M0 and upwards, it is now possible to configure the SNMP agent to ONLY access SNMPv3 requests, by running CHGSNMPA ALWSNMPV3(*ONLY).  All SNMPv1 requests received will be rejected with this setting.  It is recommended that SNMPv3 is configured and working correctly before this setting is taken.

It is also possible to setup SNMP journaling which can record SNMP requests received, responses sent and any SNMP traps sent or received. SNMPv1 has had journaling support for many years, but by applying the latest SNMP PTFs, journaling support has also been added for SNMPv3.
Technote N1020901 describes the journal entries and layout with the new function PTFs applied.

6. Hints and Tips / troubleshooting
Ensure you have the latest SNMP PTFs applied. Latest PTFs as of November 2019 are as follows:
R710 - SI66626
R720 - SI68842
R730 - SI69158
R740 - SI69366
* For SNMPv1, if having problems communicating, ensure that the community name being used on both SNMP manager and agent are identical (remembering the community name is case-sensitive)
* If the SNMP manager is configured to use SNMPv2c, the IBM i will not respond. There is no support for SNMPv2c. Configure the SNMP manager to use SNMPv1 and try again.
* Ensure that any firewall between the IBM i SNMP Agent, and the external SNMP Manager allows for UDP port 161 (Note: If you are sending or receiving SNMP traps, the firewall also requires UDP port 162 opened.)
* Make sure SNMP is started and listening. NETSTAT *CNN will show the listening connections.
Look for the following entry:

Remote           Remote     Local                        
Address          Port       Port       Idle Time  State  
*                *          snmp       016:36:35  *UDP  

Check that you have a QTMSNMP, QSNMPSA and QTMSNMPRCV job active on the system.
If not, try running ENDTCPSVR *SNMP, followed by STRTCPSVR *SNMP.
  7. Diagnostic Data
Refer to document,, for details of what information is needed by support in order to provide support for SNMP on IBM i.

[{"Product":{"code":"SWG60","label":"IBM i"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"Communications-TCP","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]

Historical Number


Document Information

Modified date:
10 September 2020