i Can … Support SNMP V3 with 7.1

A stealth change in the 7.1 release is the support of V3 of the Simple Network Management Protocol (SNMP).  You won't find this secret documented clearly in the Information Center and it's not covered in the 7.1 overview information. It’s covered in the 7.1 Technical Overview Redbooks publication.

Simple Network Management Protocol (SNMP) version 3 is the current standard version of SNMP. SNMP has been available on i (and it's predecessors) for years, but hadn’t been updated since its original availability. The primary motivation for the update to SNMP in 7.1 was to support IPv6, but SNMPv3 also incorporates the use of user-based authentication and data privacy. 

You must enable the system to handle SNMPv3 requests. Do this by using the Change SNMP Attributes (CHGSNMPA) command, with the “Allow SNMPv3 support” (ALWSNMPV3) parameter set to *YES. The default is *NO, so until you specifically change the attributes, you won’t be using v3. The SNMP server must be ended and then started again for this change to take effect. If you change this attribute to allow SNMPv3, it won’t affect any existing SNMP applications that you may have, since older version packets will still be accepted and handled as they were before.

User-based authentication for SNMP requires that you use the Add User for SNMP (ADDUSRSNMP) command. This command is new in 7.1, and there are the corresponding change and remove commands. An SNMP user isn’t the same as an IBM i user profile. Rather, SNMP users are added and maintained separately. SNMP users allow for authentication and privacy for SNMP request/response flows, and you can restrict access to management information base (MIB) objects based upon the SNMP user names.

Finally, 7.1 also provides support for several new MIBs:
•    RFC 4293 - MIB for the Internet Protocol (IP)
•    RFC 4292 - IP Forwarding Table MIB
•    RFC 4022 - MIB for the Transmission Control Protocol (TCP)
•    RFC 4113 - MIB for the User Datagram Protocol (UDP)

 

i Can … be a DHCP Client

With IBM i 6.1 and the required PTFs (SI30956 and its requisite PTFs), the IBM i can participate in a network as a Dynamic Host Configuration Protocol (DHCP) client.In other words, a system administrator could configure an IBM i to get IP addresses from a DHCP server rather than manually assigning an IP address to each network interface (line) on the system. The system can also obtain other configuration information from the DHCP server, such as a default gateway or other routes and a list of DNS servers and domain names that can be used when resolving host names to IP addresses.

This is accomplished by specifying *IP4DHCP rather than an IP address when adding a TCP/IP interface (ADDTCPIFC command). Only one of these special interfaces can be added for any given line description. The following command is an example of adding a DHCP client interface for the ethernet line description ETHLINE:  ADDTCPIFC INTNETADR(*IP4DHCP) LIND(ETHLINE)

Once the interface has been added, use the start TCP/IP interface command to start the interface and to acquire an IP address: STRTCPIFC INTNETADR(*IP4DHCP) LIND(ETHLINE)

Since a system can have multiple DHCP-client interfaces, the line description must be specified in order to start or end the DHCP client interface.

The starting of the DHCP client interface will cause the client interface to go into an "acquiring" state until it has successfully been assigned an IP address by a DHCP server. Once the IP address has been assigned, the special *IP4DHCP interface will disappear from the list of interfaces shown by NETSTAT option 1.  The IP address that was acquired by DHCP will then show up in the list of interfaces. The lease expiration time for a DHCP-created interface can be seen by displaying the details of the interface from NETSTAT option 1.

When a DHCP client interface is ended, the IP address is released. In order to end a DHCP client interface, you must specify the *IP4DHCP special value rather than the acquired IP address. Depending on the DHCP-server configuration, it’s possible the next time the DHCP-client interface is started it could receive a different IP address, particularly if the interface is left in an inactive state for an extended period of time. 

When configuring a DHCP client interface an optional parameter DHCP dynamic DNS updates (keyword DHCPDYNDNS) can be specified.  A value of *YES will request the DHCP server to update the DNS records for the DHCP client. A value of *NO omits this request from the messages sent to the DHCP server.

I'd like to thank Clair Wood and Brian Jongekryg for writing this blog article.  Clair and Brian work on the TCP/IP Networking team in the development lab.

i Can … Identify Your Server Jobs

This week I’m going to review the support IBM i has for "server jobs." Most of this is not new, but I'm not sure this is widely known. There are three parts to this:

• How to identify a job as a server job
• How you can define a custom TCP application server
• IBM's documentation on server jobs

When you think of "server jobs" you may think of TCP application servers, such as Telnet or FTP. While these are certainly servers, "server jobs" as IBM has defined them have a broader definition - a server job is a job that provides any sort of service or background capability. They include the traditional TCP application servers, but also include jobs that provide general system services such as clustering or the job log server.

How to identify a job as a server job

It's quite easy to identify a job as a server job. The Change Job API has a parameter called "server type" - this parameter is simply a 30-character string that identifies the server. All IBM-supplied server jobs have this string starting with QIBM. During the server job initialization process, the Change Job API is called to appropriately identify the server job. Using either IBM i Navigator (aka iSeries Navigator) or IBM Systems Director Navigator, you can then use Work Management -> Server Jobs to display the server jobs. All jobs that have a server type specified are displayed. For IBM-supplied server jobs, the GUI knows how to map from the QIBM_xxx strings to a descriptive name that is displayed on the user interface. The networking tasks in the GUI also support managing server jobs.

If you write a server application, you can use the Change Job API to identify your job as a server job. However, the IBM-provided GUI will not know about your server type string, so whatever you put into the server type field will be displayed on the GUI - that is, unless you define your server as a custom application server, which allows you to specify the text that is displayed on the GUI.

How you can define a custom TCP application server

By defining your custom TCP application server to IBM i, you can allow your server application to be managed and controlled just like any IBM-supplied server application. That is, you can then start your server with STRTCPSVR and end it with ENDTCPSVR, and the GUI will display descriptive text for your server rather than the server type string.

Three commands, Add TCP Server (ADDTCPSVR), Remove TCP Server (RMVTCPSVR), and Change TCP Server (CHGTCPSVR) let you integrate your custom server application as if it were one of the IBM-supplied server applications. The command interface to add a TCP server is fairly simple and I won't go into the details of the parameters.

The GUI also has a Create User-Defined Server wizard that will lead you through the steps of creating your custom server, so you’re not required to use the command interface. In the Web console, this wizard is found through the “All Network Tasks” panel.

IBM's documentation on server jobs

There is a well-hidden table in the IBM i Information Center that summarizes the IBM-supplied server jobs. Unless you know about it, it's unlikely that you’d ever stumble upon this. It's hidden deep within the TCP/IP Troubleshooting section! It’s referenced from the Work Management section, but that too, is pretty well hidden.

So what is this Server Table? It’s a table that lists every server application that runs on IBM i, along with key characteristics - such as the job name, the subsystem in which it runs, how to start and end the server job, and so on.

For example, if you need to change the job description of a server job so you can change job-logging settings, you can go to this table and find the job description that the server job uses.

Miscellaneous stuff

I’d like to share a couple additional tidbits of information regarding server jobs.

First, the Change Job API has a parameter to specify the Client IP Address for IPv4. Don’t use this field as it is obsolete. The operating system stores the IP address implicitly for all server jobs. The Retrieve Thread Attributes API returns the IP address for the thread (if applicable).

Netstat 'connections' has support to show you the jobs associated with the remote port. Option 8, display jobs, allows you to see the jobs for that connection. From the job, you can then get to all the typical work management options for working with a job. This same support is also in the GUI.

 

 

 

i Can … Secure my Telnet Remote Terminal Session

This week's blog on secure Telnet was written by Kevin Hackney. Kevin is a member of the IBM i network applications and configuration team in the Rochester (Minn.) development lab.

IBM i has had the capability to utilize Secure Sockets Layer (SSL) and Transport Security Layer (TLS) to secure the Telnet server for several releases. This feature was only for the server, until last year. Now instead of needing third-party Telnet clients to connect to your IBM i over TLS/SSL, you can use the native Telnet client. This is a necessary enhancement for customers who need to completely disable unsecure Telnet terminal sessions on port 23 on their IBM i servers. Starting with IBM i 5.4, it’s possible to use SSL with the Telnet client (TELNET or STRTCPTELN CL command) from IBM i to any SSL Telnet server.

This feature was added via PTFs in IBM i 5.4 and 6.1, and in a future release, you can expect the TELNET and STRTCPTELN commands to be updated to include this function. When the PTF is installed, a new client application, QIBM_QTV_TELNET_CLIENT, will be registered with the Digital Certificate Manager (DCM). All desired servers need to either have their digital certificates imported and assigned to this application or a trust list must be setup including certificate authorities of the desired Telnet servers. For more information on digital certificates and trust lists, see the “Managing Applications in DCM” topic in the information center.

The destination server and the remote port need to support implicit mode SSL to work. Implicit-mode SSL means that the SSL handshake is done immediately after connection. The IBM i Telnet server does support this, you just need to have the “Allow SSL” (ALWSSL) parameter on the Change Telnet Attributes (CHGTELNA) CL command set to *YES or *ONLY.

The value *DFT for the PORT keyword on the Telnet command will use port 23 when the secure client is off, and port 992 when the environment variable is set for SSL. A value of 23 on the PORT keyword will be interpreted as 992 when the environment variable is set for SSL.

Enabling the secure Telnet client is done with an environment variable on 5.4 and 6.1. The current job needs to set the job-level environment variable QIBM_TELNET_CLIENT_SSL to ‘Y’.

ADDENVVAR ENVVAR(QIBM_TELNET_CLIENT_SSL) VALUE('Y') LEVEL(*JOB)

Deleting the environment variable or setting it to another value will disable the secure Telnet client.

To enable all Telnet client users on your system to use SSL, set the QIBM_TELNET_CLIENT_SSL as a system-level environment variable.

ADDENVVAR ENVVAR(QIBM_TELNET_CLIENT_SSL) VALUE('Y') LEVEL(*SYS)

System environment variables are inherited by all jobs and can be overridden by job-level environment variables. Note that jobs currently running wouldn’t inherit this system-level environment variable. You’d need to sign off and sign back on to inherit the system-level environment variable.

 

Requirements for Telnet client SSL/TLS:

• The partition must be at least IBM i 5.4 or greater.
• The DCM option 34 must be installed.
• PTF SI33240 is required for IBM i 5.4.
• PTF SI33100 is required for IBM i 6.1.
• DCM must have either a trust list or server certificates set up for the application QIBM_QTV_TELNET_CLIENT.
• All certificate authorities of desired servers must be in the trust list.
• Remote servers must be configured for implicit SSL on the requested port.

 

Documentation for this function is in the PTF cover letters for each release, which I’ll provide below. These PTFs are original and have been superseded; install the PTFs listed above.

    5.4 Release Notes 

    6.1 Release Notes  

 

 

Dump a Communications Trace

A recent enhancement to the 6.1 communications trace support allows the collected communications trace data to be dumped to a file in the packet capture (PCAP) format. The Dump Communications Trace (DMPCMNTRC) command was introduced in V5R3. This command lets you dump a communications trace to a stream file. Prior to the 6.1 enhancement, you could then print the dumped trace data with the Print Communications Trace command. Why would you want to dump a communications trace to a file rather than print it? There are a couple of reasons:

• If you're using IPv6 and want to format the trace for the IPv6 headers, you must first dump the trace to a file, then print the trace.
• By dumping the communications trace to a file, you can start another trace on the same communications line, yet keep the prior trace data; when it's been dumped, you can print it multiple times with different options if you want.

IBM recently added support to dump the communications trace data into a file in the PCAP format. Dumping the data in the PCAP format is pretty simple -- you need to create a data area named QCMNTRCPCP in QGPL; the existence of the data area controls whether the communications trace data is dumped in the IBM i internal format or the PCAP format. Dumping the communications trace data in PCAP format lets you use other tools, such as Wireshark or tcpdump, to analyze the trace data.  These tools offer formatting and analysis options that the IBM i Print Communications Trace (PRTCMNTRC) functionality doesn't support. 

You can expect in the next release after 6.1 the DMPCMNTRC command will be enhanced with new command parameters to specify the dump is to a file in the *PCAP format and you will no longer need to create a data area to enable the function.

This function is available with PTF SI33685. The PTF cover letter has the documentation for this enhancement.