Bookmark and Share
RSS

Recent Posts

SNMPv3 Auditing and Other Enhancements

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.

SNMPv3 Auditing

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 (CHGSNMPA) 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 and LOGSET parameters for the community with the Change Community for SNMP (CHGCOMSNMP) command. For SNMPv3, there is now a LOGGET and a LOGSET parameter on the Add User for SNMP (ADDUSRSNMP) and Change User for SNMP (CHGUSRSNMP) 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) and LOGSET(*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 the 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 parameter 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 Test 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.

The ADLINF parameter supports multiple values, so both of the values of *ASPNBR and *SYSD 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.

Required PTFs

The following PTFs provide the new function described by this article:
SI63661 for IBM i 7.1
SI63662 for IBM i 7.2
SI63664 for IBM i 7.3

Posted March 01, 2017 | Permalink

Post a Comment

Note: Comments are moderated and will not appear until approved

comments powered by Disqus