March 01, 2017
Clair Wood wrote this week’s article. Clair is an advisory software engineer with IBM in Rochester, Minnesota. His current responsibilities involve development for TCP/IP configuration and applications. He is the product owner of the IBM TCP/IP Connectivity Utilities for i.
This article describes the new support to audit SNMPv3 requests. Additional SNMP enhancements exist for the system description, storage pool descriptions, and storage pool block sizes. These enhancements are available via PTFs.
Auditing SNMPv3 messages is similar to the auditing that's done for SNMPv1. The same mechanism is used to control the auditing of all SNMP Get or Set requests. Audit messages by changing the system-wide SNMP attributes with the Change SNMP Attributes
) command. The Log Get requests (LOGGET
) parameter and the Log Set requests (LOGSET
) parameter control whether all Get (Get, GetNext, GetBulk) or Set requests and their associated responses are logged in the QUSRSYS/QSNMP journal. This now includes both SNMPv1 and SNMPv3 messages.
For SNMPv1, auditing requests for a specific community can be done by turning off the system-wide SNMP audit settings and then changing the LOGGET
parameters for the community with the Change Community for SNMP
) command. For SNMPv3, there is now a LOGGET and a LOGSET
parameter on the Add User for SNMP
) and Change User for SNMP
) commands which control the auditing of a specific SNMPv3 user.
SNMPv3 engine ID discovery takes place when an SNMP manager sends a Get request that specifies either a zero length user name or the user name initial and an authoritative engine ID consisting of all zeros. Auditing of engine ID discovery requests will always be done if LOGGET(*YES)
is specified in the system-wide SNMP attributes.
Note: When the PTFs are installed, any existing SNMP users will have their auditing attributes set to LOGGET(*SNMPATR)
which means that the system-wide SNMP attributes will initially control auditing for all the existing users.
The format and contents of an audit entry are described in the IBM i support document QSNMP audit journal layout changes after applying PTFs.
Appending Text to the System Description
It’s now possible to specify additional text to be appended to the standard text description ( sysDescr
) that's returned. The standard text identifies th
e system as an IBM i and also includes the version and release of the system. The System description (SYSD
) parameter of the CHGSNMPA
command had no effect on the standard text that was returned. A new parame
ter Additional information (ADLINF
) is now available on the CHGSNMPA
command. Specifying ADLINF(*SYSD)
will cause any user specified text entered for the SYSD
parameter to be appended to the standard text returned for sysDescr. For example, if the command CHGSNMPA SYSD('Application Te st System') ADLINF(*SYSD)
is run, the text returned by a GET request for sysDescr
will be "IBM OS/400 V7R3M0 Application Test System".
ASP Numbers for Storage Pool Descriptions
It’s also now possible to have the ASP number appended to the descriptive text (hrStorageDescr
) for all of the storage pools returned in the storage table (hrStorageTable
). The new ADLINF
parameter supports a value *ASPNBR
which will cause the ASP number to be appended to the standard descriptive text. For example, if the command CHGSNMPA ADLINF(*ASPNBR)
is run, the text returned by a Get request for hrStorageDescr
for an independent ASP will be "Independent ASP 33" if 33 is the ASP number for that specific auxiliary storage pool.
parameter supports multiple values, so both of the values of *ASPNBR
can be specified at the same time as follows: CHGSNMPA ADLINF(*SYSD *ASPNBR)
Note: The IBM i SNMP agent must be ended and restarted for changes to the ADLINF
parameter to take effect.
Larger Storage Pool Block Sizes
The largest possible configurable block size for storage pools supported by the Block size (BLKSIZE)
parameter of the CHGSNMPA
command was 32768 bytes. However, even larger block sizes are needed to accurately show storage sizes in the hrStorageTable
. Now it’s possible to use block sizes up to 1 MB (1048576 bytes). In addition, there are special parameter values, such as 512K and 1M, which can be used to make specifying block sizes easier. For example, specifying CHGSNMPA BLKSIZE(512K 4096)
sets the storage pool block size to 512K (524288) bytes. The block sizes allowed for disk units have not changed.
The following PTFs provide the new function described by this article:
for IBM i 7.1
for IBM i 7.2
for IBM i 7.3
Posted March 01, 2017 | Permalink