IBM i > ADMINISTRATOR > NETWORKS

SNMP Enhancements for IBM i


The latest releases of the IBM i provided several enhancements for Simple Network Management Protocol (SNMP) support. They include IPv6 support, Internet address masking for communities and support for SNMP version 3 (SNMPv3). These enhancements provide both added function and improved security for network and system management applications.

IPv6 Support

In IBM i 7.1, IBM added full support for IPv6 for SNMP. This includes SNMP communications across an IPv6 network, the configuration of communities for SNMP managers and trap manager configuration. In addition, the IBM i SNMP manager APIs now support communications across an IPv6 network.

Internet Address Mask for Communities

Prior to 7.1, it was not possible to configure an Internet address mask for an SNMP community. Clients had to use static IP addresses for their SNMP managers if they didn’t want to allow any manager from any IP address to communicate with an IBM i agent. Now, the IP address and subnet mask is configurable, which allows for more IP address flexibility for SNMP managers that are assigned either a static IP address or a dynamic IP address within the subnet specified by the community configuration. For example, the command:

ADDCOMSNMP COM('ManagerNET') INTNETADR(('10.1.1.0' '255.255.255.0'))
              OBJACC(*READ)

will allow any manager within the 10.1.1.0 network to have SNMP read access when using the community name ManagerNET to communicate with the IBM i agent. In addition, if multiple manager applications are being used within the 10.1.1.0 network, you no longer need to configure an IP address for each individual manager.

SNMPv3 Enablement

In IBM i 7.1, IBM added support for SNMP version 3 (SNMPv3). This enables a higher level of security for SNMP communications than previous versions. The IBM i SNMPv3 support allows for authentication using the HMAC-SHA or HMAC-MD5 protocols. It also enables data privacy using the CBC-DES protocol.

Allowing SNMPv3

In order to begin using SNMPv3, you must perform several configuration-related tasks. First, SNMPv3 must be enabled in the SNMP attributes. To do this, run the command:

CHGSNMPA ALWSNMPV3(*YES)

The next time the SNMP server is started, it will begin accepting SNMPv3 requests from the network. This does not affect SNMPv1 communications. The server will still accept SNMPv1 requests and send SNMPv1 traps.

When SNMPv3 is enabled, the Configure TCP/IP SNMP (CFGTCPSNMP) command will show a new option (3) that can be used to work with SNMP users.

Configuring the SNMP Engine Identifier

The next step to configure your system for SNMPv3 is to set the SNMP engine identifier to an appropriate value. The easiest way to do this is to allow the system to automatically generate the SNMP engine ID for you. This can be done with the command:

CHGSNMPA SNMPENGID(*SYSGEN)

Specifying a value other than *SYSGEN is allowed but not recommended. The value generated by *SYSGEN is assigned based on the engine ID specification defined by RFC 3411 and the IP address specified in the host table for the system. In 7.2, stricter checking is done on the SNMP engine ID. If an SNMP engine ID does not meet the specification defined in RFC 3411 and the system is configured to enable SNMPv3, the SNMP server will fail to start.

Configuring SNMPv3 Users

The final step to start using SNMPv3 is to configure users. This is done via the Add User for SNMP (ADDUSRSNMP) command. The following is an example of adding an SNMP user:

ADDUSRSNMP USRNAME('TestUser') AUTPCL(*HMACSHA) AUTPWD('authpassword') 
                 PVYPCL(*CBCDES) PVYPWD('privpassword') KEYTYPE(*NONLOCALIZED)

The example creates a user named TestUser that uses the HMAC-SHA protocol for authentication and the CBC-DES encryption protocol for privacy. User names and the associated passwords are case sensitive. Also note that the user name does not correspond to an IBM i user profile and that the passwords do not follow the password rules for IBM i user profiles. However, the user name, authentication protocol, privacy protocol and passwords much match exactly with the user information configured within the SNMPv3 manager application.

Once the initial setup for SNMPv3 has been performed, the SNMP server must be ended and restarted for the SNMP agent to start receiving and handling SNMPv3 requests.

SNMPv3 Manager APIs

New APIs for native IBM i SNMP manager applications are available in IBM i 7.2. These new APIs provide the capability to send GET, GETNEXT and SET SNMP requests using SNMPv3 and to perform SNMPv3 agent engine ID discovery and time synchronization. The APIs are snmpDiscover_v3(), snmpGet_v3(), snmpGetnext_v3(), snmpSet_v3() and snmpFreeAuthCB_v3().

An SNMP manager application must first use the snmpDiscover_v3() API to perform agent SNMP engine ID discovery and time synchronization. The snmpDiscover_v3() API also creates an authentication control block for communication with the agent. Once this is complete, the snmpGet_v3(), snmpGetnext_v3() and snmpSet_v3() APIs may be used to send requests to the agent.

Once all communication with the agent is ended, the authentication control block used by the SNMPv3 APIs must be freed using snmpFreeAuthCB_v3(). It is important to note that a manager must have a separate authentication control block for each individual agent that the manager communicates with.

Other Considerations

When creating users for SNMPv3, it is recommended to avoid using common names or names that can be easily guessed such as 'initial', 'public' or 'test', especially if the users are not configured to use authentication or privacy.

Changing the SNMP engine ID after adding SNMPv3 users can cause authentication or privacy keys to no longer be valid if KEYTYPE(*LOCALIZED) was specified when the user was added. The Change User for SNMP (CHGUSRSNMP) command can be run to generate new authentication and privacy keys for a user.

It is not possible at this time to completely turn off SNMPv1 communications with the IBM i agent. However, it can essentially be turned off by changing the Object access (OBJACC) parameter for each configured community to *NONE. This will prevent IBM i from responding to any SNMPv1 requests. This will not, however, eliminate SNMPv1 traps from being sent if any trap managers have been configured.

Due to differences in SNMPv3 manager implementations, it may be necessary to add an environment variable to make a change in the way the IBM i agent performs validation checks during the initial communication with an SNMPv3 manager. If an SNMPv3 manager application is timing out attempting to establish SNMPv3 communications with the IBM i agent, add the environment variable with the following command:

ADDENVVAR ENVVAR(QIBM_SNMPV3_AUTH) VALUE('1') LEVEL(*SYS) 

After running this command, the SNMP server must be ended and restarted. You may also need to end and restart the SNMP manager application. Other issues preventing SNMPv3 communication can be caused by a mismatch with SNMP user names or passwords, or the authentication or privacy protocol being used.

One final note is that the SNMPv3 support on IBM i does not affect any subagent applications that use IBM i subagent APIs. Subagent applications will work with either SNMPv1 or SNMPv3 on IBM i without any changes being made to the subagent code itself.

Clair Wood is an Advisory Software Engineer with IBM in Rochester, Minnesota.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Simplification on the Line

IP telephony puts voice and data on one network

ADMINISTRATOR > NETWORKS

Using SSHs Port-Forwarding Capabilities

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters