Bridging and IBM Networking Configuration Guide, Cisco IOS Release 15S

Configuring the TN3270 Server

The implementation of TN3270 Server on a channel-attached router using the CIP or CPA provides an effective method of removing the processing of TN3270 sessions from valuable mainframe cycles to a faster and more efficient router. This chapter provides information about configuring TN3270 Server support on the CIP and CPA types of CMCC adapters on a Cisco router.

This information is described in the following sections:

•Overview

•Benefits

•Preparing to Configure the TN3270 Server

•Configuring the TN3270 Server

•Configuring the TN3270 Server for Response-Time Monitoring

•Monitoring and Maintaining the TN3270 Server

•TN3270 Server Configuration Examples

For general information about configuring CMCC adapters, refer to the "Configuring Cisco Mainframe Channel Connection Adapters" chapter in this publication.

For a complete description of the TN3270 server commands in this chapter, refer to the "TN3270 Server Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 2 of 2). To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Platform Support for Cisco IOS Software Features" section on page li in the "Using Cisco IOS Software" chapter.

Overview

This section provides a brief introduction to the environments where the TN3270 server feature is used and describes some of the primary benefits and functions of the TN3270 server.

The following sections in this topic provide background information about the TN3270 Server:

•Benefits

•TN3270 Server Environments

•TN3270 Server Architecture

•Supported PU Types

•Supported LU Types

•LU Allocation

•Session Termination

•Response-Time Collection

•SSL Encryption Support

Additional details about the TN3270 Server implementation can be found in the TN3270 Design and Implementation Guide available on Cisco.com.

Benefits

The latest release of the TN3270 Server feature on the CMCC implements RFC 2355, TN3270 Enhancements and RFC 2562, Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB).

The TN3270 server provides the following benefits:

•Supports clients using the ASSOCIATE request.

•Maintains knowledge of printer and terminal relationships when an association is defined between LU resources.

•Enables clients to acquire a terminal LU and its associated printer without desktop configuration to specific LUs by grouping LUs in clusters.

•Enables you to capture response-time statistics for individual sessions and clients or for groups of sessions and clients.

•Supports specification of LU names for dynamic definition of dependent LUs (DDDLUs).

•Controls how keepalives are generated and keepalive responses are handled by the CMCC adapter.

•Prevents VTAM security problems when the UNBIND request is used with CICS.

•Supports deletion of LUs automatically on session termination.

•Supports Dynamic LU Naming.

•Supports Inverse DNS Nailing.

•Provides security through SSL Encryption.

TN3270 Server Environments

TN3270 communications in a TCP/IP network consist of the following basic elements:

•TN3270 client—Emulates a 3270 display device for communication with a mainframe application through a TN3270 server over an IP network. The client can support the standard TN3270 functions (as defined by RFC 1576) or the enhanced functionality provided by TN3270E (defined in RFC 2355). TN3270 clients are available on a variety of operating system platforms.

•TN3270 server—Converts the client TN3270 data stream to SNA 3270 and transfers the data to and from the mainframe.

•Mainframe—Provides the application for the TN3270 client and communicates with the TN3270 server using Virtual Telecommunications Access Method (VTAM).

The TN3270 server feature offers an attractive solution when the following conditions need to be supported in an SNA environment:

•Maintaining an IP backbone while providing support for SNA 3270-type clients.

•Offloading mainframe CPU cycles when using a TN3270 host TCP/IP stack with a TN3270 server.

•Providing support for high session density or high transactions per second.

The TN3270 server feature on a CMCC adapter card provides mapping between an SNA 3270 host and a TN3270 client connected to a TCP/IP network as shown in Figure 1. Functionally, it is useful to view the TN3270 server from two different perspectives:

•SNA Functions

•Telnet Server Functions

Figure 1 TN3270 Implementation

SNA Functions

From the perspective of an SNA 3270 host connected to the CMCC adapter, the TN3270 server is an SNA device that supports multiple PUs, with each PU supporting up to 255 logical units (LUs). The LU can be Type 1, 2, or 3. The SNA host is unaware of the existence of the TCP/IP extension on the implementation of these LUs.

The LUs implemented by the TN3270 server are dependent LUs. To route these dependent LU sessions to multiple VTAM hosts connected to the TN3270 server in the CMCC adapter card, rather than routing in the VTAM hosts, the TN3270 server implements a SNA session switch with end node (EN) dependent LU requester (DLUR) function. SNA session switching allows you to eliminate SNA subarea routing between hosts of TN3270 traffic by establishing Advanced Peer-to-Peer Networking (APPN) links with the primary LU hosts directly.

Using the DLUR function is optional so that the TN3270 server can be used with VTAM versions prior to version 4.2, which provide no APPN support. In these non-APPN environments, access to multiple hosts is accomplished using direct PU configuration in the TN3270 server.

Telnet Server Functions

From the perspective of a TN3270 client, the TN3270 server is a high-performance Telnet server that supports Telnet connections, negotiation and data format. The server on the CMCC adapter card supports Telnet connection negotiation and data format as specified in RFC 1576 (referred to as Traditional TN3270) and RFC 2355 (referred to as TN3270 Enhancements).

Unless the TN3270 server uses a Token Ring connection to a front-end processor (FEP), or other LLC connectivity to the mainframe host, it will require CSNA or CMPC support. For more information about configuring CSNA or CMPC support, see the "Configuring CSNA and CMPC" chapter in this publication.

TN3270 Server Architecture

The Cisco TN3270 server can be placed on a channel-attached router or a remote router. If the router is directly connected to the host, the TN3270 server resides on a CIP or CPA that is connected to the mainframe using Enterprise Systems Connection (ESCON) or bus-and-tag channel attachment.

Alternatively, you can use the TN3270 server on a remote router as an intermediate step toward using the CIP or CPA as a direct host connection. In this case, the TN3270 server resides on a router that is connected to the mainframe using a channel connection device, such as the FEP or a CIP or CPA.

The TN3270 server feature is implemented on the following CMCC adapters:

•CIP—Installed in a Cisco 7000 with RSP7000 or 7500 series router. Each CIP has up to two ESCON or two bus-and-tag (parallel) interfaces and a single virtual interface. The TN3270 server is installed on the virtual interface. Therefore, each CIP can have a single TN3270 server.

•CPA—ECPA or PCPA installed in a Cisco 7200 series router. Each CPA combines the function of an ESCON interface and a virtual interface on a single interface. As with the CIP, a single TN3270 server can be installed on each CPA.

Because a router can accommodate more than one CIP or CPA, each router can support multiple TN3270 servers.

Supported PU Types

The TN3270 server supports two types of PUs:

•Direct PUs—Used in subarea SNA

•DLUR PUs—Used with APPN

Direct PUs and DLUR PUs can coexist on the same CIP or CPA. Both types of PUs support either static or dynamic LUs. However, the LU type is defined only in VTAM and is not explicitly defined in the TN3270 server.

Direct PUs

The TN3270 server supports direct PUs when you want to configure a PU entity that has a direct link to a host. Direct PUs are used in non-APPN environments.

The definition of each direct PU within the router requires that you define a local service access point (SAP). Each PU on the TN3270 server must have a unique local/remote media access control (MAC)/SAP quadruple. If you want to connect PUs on the same adapter to the same remote MAC (RMAC) and remote SAP (RSAP), then you must configure each PU with a different link SAP (LSAP).

With direct PUs, the LU names in the TN3270 server do not necessarily match the LU names defined in VTAM. However, there are a couple of ways to accomplish matching LU names for direct PUs:

•LU seed configuration—To ensure that the LU seed configurations in the router and VTAM match for direct PUs, you need to define the value for the lu-seed parameter in the pu (TN3270) or pu (listen-point) command in the router, the same as the LUSEED value in the VTAM PU definition.

•INCLUD0E function available as of VTAM version 4.4—To allow the XCA to provide the LU name in the ACTLU message, use the INCLUD0E function. The TN3270 server then uses the LU name provided by the ACTLU.

DLUR PUs

When the SNA network uses APPN and the TN3270 server can reach multiple hosts, the DLUR function of the TN3270 server is recommended. Note that by using the DLUR function of the TN3270 server, all of the LUs in the server can be defined and owned by a controlling VTAM. When a client requests an application residing on a different VTAM host, the controlling VTAM will issue the request to the target host which will send a BIND directly to the client. All LU-LU data will then flow directly between the target host and the client without needing to go through the controlling VTAM.

DLUR allows the routing of TN3270 LUs to be performed in the CMCC adapter card using SNA session switching to multiple VTAM hosts rather than routing the sessions on the VTAM hosts. This feature is especially important with the multi-CPU CMOS mainframe, which comprises up to 16 CPUs that appear as separate VTAMs.

The implementation of TN3270 server LUs under DLUR also allows the server to learn about the LU names from VTAM in the ACTLU message, which greatly simplifies the configuration to support specifically requestable LUs such as printers.

Supported LU Types

The TN3270 server supports two types of LUs:

•Static LUs—Defined explicitly within VTAM. Allocation of static LUs requires a client to specify the PU and LU name. LU name requests are only supported by TN3270E clients.

•Dynamic LUs—Use the DDDLU feature of VTAM. Allocation of dynamic LUs requires a client to specify only a terminal type. LU name requests to be fulfilled by DDDLUs for PUs configured with the generic-pool deny command are supported.

The type of LU that is allocated is defined only in the VTAM switched major node. The TN3270 server does not specify the LU type.

LU Names in the TN3270 Server

Where SNA session switching is configured using DLUR PUs, the TN3270 server learns the LU names (static or dynamic) from VTAM in the ACTLU message. Direct PUs can also learn names from VTAM in the ACTLU message if the INCLUD0E parameter (available in VTAM version 4.4) is used in the switched major node definition.

However, for direct PUs, the TN3270 server can also specify a naming convention that it will use for any dynamic LUs that are allocated. For direct PUs a "seed" name can be configured on the PU in the TN3270 server configuration by using the lu-seed argument of the pu (TN3270) or pu (listen-point) command. The LU seed name defines a prefix for the LU name. The TN3270 server uses the LU seed name in conjunction with the LOCADDR to generate the name by which the TN3270 server recognizes that LU. It is important to note that VTAM also generates LU names using its own LUSEED parameter.

When using the lu-seed parameter in the TN3270 server configuration, it is best to use the same naming convention as the host to prevent situations where the LU name that the TN3270 server recognizes differs from the corresponding LU name assigned in VTAM.

Several factors determine how LUs are assigned and named. For more information about the different factors that influence LU naming, see the TN3270 Design and Implementation Guide available on Cisco.com.

LU Allocation

This section provides information about the following aspects of LU allocation:

•Formation of LU Model Type and Number

•Static LU Allocation

•Dynamic LU Allocation

•Dynamic LU Naming

•LU Nailing

•Inverse DNS Nailing

•LU Pooling and ASSOCIATE Requests

•Pooled LU Allocation

Formation of LU Model Type and Number

VTAM requires a model type and number in the Reply PSID NMVT from the TN3270 server to find an appropriate LU template in the LUGROUP major node. The model type is a four character string and the model number is a two or three character string.

The TN3270 server translates the following formats of terminal type string from a client:

•IBM-<XXXX>-<Y>[-E]: Specifies "XXXX0Y"or "XXXX0YE" in the model type and number field of the Reply PSID NMVT.

Note The "E" in the model string refers to 3270 Extended Datastream. It has no association with the "E" in "TN3270E."

•IBM-DYNAMIC: Specifies "DYNAMIC" in the model type and number field of the Reply PSID NMVT. The VTAM configuration also must have "DYNAMIC" defined as a template in the LUGROUP.

All other terminal strings that do not match the above syntax examples are forwarded as is to VTAM. For example, a string of "IBM-ZZ..Z," where "ZZ..Z" does not match the preceding syntax, is forwarded as "ZZ..Z."

In all cases, the string is translated from ASCII to EBCDIC and truncated at seven characters.

Clients that do not support TN3270E typically require a 3270 datastream on the System Services Control Point (SSCP)-LU flow. Clients that are TN3270E compliant typically use the SNA Character Set (SCS) on the SSCP-LU session. In order to accommodate these two classes of clients, the TN3270 server directs them to different LUGROUP entries at the host. To make this as easy as possible, the SCS requirement is also encoded into the model string sent to the host. Following the previously described terminal type string formats accepted by the server, this additional condition is applied:

If the client has negotiated TN3270E support, the character "S" is overlaid on the fifth character of the string, or appended if the string is less than five characters as shown in Table 1.

Static LU Allocation

A TN3270E client can request a specific LU name by using the TN3270E command CONNECT as documented in RFC 2355. The name requested must match the name by which the TN3270 server knows the LU and the host must have activated the LU with an ACTLU.

TN3270 clients can also use static LUs if client nailing is configured on the TN3270 server.

Dynamic LU Allocation

Dynamic LU allocation, using VTAM's DDDLU feature, is the most common form of request from TN3270 clients emulating a TN3270 terminal. The user typically requests connection as a particular terminal type and normally is not interested in what LOCADDR or LU name is allocated by the host, as long as a network solicitor logon menu is presented. In fact, only TN3270E clients can request specific LUs by name.

The TN3270 server performs the following functions with this type of session request:

•Forms an EBCDIC string based on the model type and number requested by the client (see the "Formation of LU Model Type and Number" section for information about the algorithm used). This string is used as a field in a Reply product set ID (PSID) network management vector transport (NMVT).

•Allocates a LOCADDR from the next available LU in the generic LU pool. This LOCADDR is used in the NMVT.

•Sends the formatted Reply PSID NMVT to VTAM.

To support DDDLU, the PUs used by the TN3270 server have to be defined in VTAM with LUSEED and LUGROUP parameters. When VTAM receives the NMVT it uses the EBCDIC model type and number string to look up an LU template under the LUGROUP. For example, the string "327802E" finds a match in the sample VTAM configuration shown in Figure 5 in the "VTAM Host Configuration Considerations" section. An ACTLU is sent and a terminal session with the model and type requested by the client is established.

LU name requests to be fulfilled by DDDLUs for PUs configured with the generic-pool deny command are supported.

For more information about defining the LUSEED and LUGROUP parameters in VTAM, see the "VTAM Host Configuration Considerations" section.

Dynamic LU Naming

The Dynamic LU Naming enhancement allows the user to configure named logical units (LUs) from the TN3270 server side. This enhancement allows the TN3270 server to pass an LU name to the Virtual Telecommunications Access Method (VTAM) software running on the mainframe and have VTAM dynamically create an LU with that name. The LU name is then sent to the mainframe as part of subvector 86 in the Reply PSID NMVT power-on frame. The TN3270 client can connect to any of the available TN3270 servers and the selected server can request a specific LU name for the client. In addition, the LU naming conventions have been modified to allow for more flexibility when specifying lu-seed names.

LU Nailing

The TN3270 server allows a client IP address to be mapped or "nailed" to one or more LU local addresses on one or more physical units (PUs) by means of router configuration commands. LU nailing allows you to control the relationship between the TN3270 client and the LU.

Using LU nailing, clients from traditional TN3270 (non-TN3270E) devices can connect to specific LUs, which overcomes a limitation of TN3270 devices that cannot specify a "CONNECT LU." LU nailing is useful for TN3270E clients because it provides central control of your configuration at the router rather than at the client.

The "model matching" feature of Cisco's TN3270 server is designed for efficient use of dynamic LUs. Each TN3270E client specifies a terminal model type at connection. When a non-nailed client connects and does not request a specific LU, the LU allocation algorithm attempts to allocate an LU that operated with that terminal model the last time it was used. If no such model is available, the next choice is an LU that has not been used since the PU was last activated. Failing that, any available LU is used; however, for dynamic LUs only, there is a short delay in connecting the session.

When a client or set of clients is nailed to a set of more than one LU, the same logic applies. If the configured LU nailing maps a screen client to a set of LUs, the LU nailing algorithm attempts to match the client to a previously used LU that was most recently used with the same terminal model type as requested by the client for this connection. If a match is found, then that LU is used. If a match is not found, any LU in the set that is not currently in use is chosen. If there is no available LU in the set, the connection is rejected.

For example, the following LUs are nailed to clients at address 192.195.80.40, and LUs BAGE1004 and BAGE1005, which were connected but are now disconnected.

lu    name   client-ip:tcp       nail state    model   frames in out    idle for

1   BAGE1001 192.195.80.40:3822   Y   P-BIND   327904E  4       4       0:22:35

2   BAGE1002 192.195.80.40:3867   Y   ACT/SESS 327904E  8       7       0:21:20

3   BAGE1003 192.195.80.40:3981   Y   ACT/SESS 327803E  13      14      0:10:13

4   BAGE1004 192.195.80.40:3991   Y   ACT/NA   327803E  8       9       0:0:7

5   BAGE1005 192.195.80.40:3997   Y   ACT/NA   327805   8       9       0:7:8

If a client at IP address 192.195.80.40 requests a terminal model of type IBM-3278-5, LU BAGE1005 will be selected over BAGE1004.

lu    name   client-ip:tcp       nail state    model   frames in out    idle for

1   BAGE1001 192.195.80.40:3822   Y   P-BIND   327904E  4       4       0:23:29

2   BAGE1002 192.195.80.40:3867   Y   ACT/SESS 327904E  8       7       0:22:14

3   BAGE1003 192.195.80.40:3981   Y   ACT/SESS 327803E  13      14      0:11:7

4   BAGE1004 192.195.80.40:3991   Y   ACT/NA   327803E  8       9       0:1:1

5   BAGE1005 192.195.80.40:4052   Y   ACT/SESS 327805   13      14      0:0:16

Inverse DNS Nailing

The Inverse DNS Nailing enhancement enables the TN3270 server to nail a pool of LUs to client machine names or to an entire domain. This enhancement allows dynamic IP addressing on the TN3270 client machines. This addressing is used in network design scenarios (for example, a Dynamic Host Configuration Protocol [DHCP] environment) and in individual network configuration scenarios (for example, a machine is moved and needs a new network address).

The Cisco IOS software inverse nailing support uses the DNS in routers to look up the symbolic name associated with a client IP address. The TN3270 server uses this symbolic name to assign a predefined LU pool for the user. This eliminates the need for nailed TN3270 clients to have statically defined IP addresses. If you configure inverse DNS nailing on the TN3270 server, you do not need to modify the DNS nailing statements in the router configuration.

LU Pooling and ASSOCIATE Requests

The TN3270 server enhancements introduced in Cisco IOS Release 12.0(5)T add support for the ASSOCIATE request through LU pooling. The LU pooling feature enables the TN3270 server to identify the relationships between screen and printer LUs.

The LU pool configuration is an option to the LU nailing feature that allows clients to be nailed to LUs. The LU pooling feature allows you to configure clients in the router and nail clients into groups of LUs. These groups of LUs are called clusters. Each cluster is given a unique pool name. An LU pool consists of one or more LU clusters that are related to each other. This allows logically related clients to connect to LUs that have the same logical relationship with the host. A cluster can contain screen LUs and their associated printer LUs. The pool name can be used instead of a device name on a CONNECT request. LU nailing is supported for LU pools.

The pool name can be used instead of a device name on a CONNECT request. The pool name must be eight characters or less in length and must comply with VTAM naming rules, which allow the following characters (alphabetic characters are not case sensitive):

•1st character—Alphabetic (A-Z) and national characters `@', `#', and `$'

•2nd-8th characters—Alphabetic (A-Z), numeric (0-9), and national characters `@', `#', and `$'

These naming rules are enforced by the TN3270 server when configuring a pool name and when processing the name received on a CONNECT request from the client. The TN3270 server rejects an invalid name and truncates the name received in the CONNECT request from the client to eight characters or at an invalid character (whichever comes first) when processing the CONNECT request.

Figure 2 provides an overview of clusters configured within PUs.

Figure 2 LU Pooling

Support for the ASSOCIATE request enables you to define a partner printer in the TN3270 server for a given terminal LU pool or single terminal. As a result, the TN3270 server maintains a knowledge of printer and terminal relationships. The client does not need to know the LU name of the partner printer in advance. Typically, a client can request a pool name, a specific LU, or a resource without citing a pool name or LU name.

If the client sends an ASSOCIATE request for a resource name to the TN3270 server, the server provides the client with a resource LU name.

In Figure 3, the client requests an LU from unixpool and is granted an LU from the specified pool. The client then initiates a new process by requesting the printer device associated with the given resource LU name.

The client requests a printer LU associated with termabc and the server grants the printer LU associated with termabc. Based on the configuration in the router that specifies the clusters of printer and screen LUs for pools, the TN3270 server assigns and allows the client to use the printer LU associated with its terminal LU.

Figure 3 Client Request for LU from a Specific Pool and Printer LU Association

Figure 4 shows the client request for a specific LU termxyz and then a request for a printer LU associated with the LU termxyz. The TN3270 server grants the screen LU and connects the printer associated with termxyz.

Figure 4 Client Request for a Specific LU and Printer LU Association

Pooled LU Allocation

When configured, the pool becomes one of several criteria used by the TN3270 server to assign an LU to a client. When a client requests a connection, the TN3270 server determines the authorized capabilities of the client. For example, the TN3270 server attempts to determine whether LU nailing definitions exist for the client.

When the client criteria is processed, the TN3270 server assigns the first available LU in the group to the client. If an appropriate LU is not found, the TN3270 connection is closed.

Screen and printer LUs for a cluster in a pool are allocated according to the following connection scenarios in the TN3270 server:

•The first client with an IP address that is nailed to a pool connects to the TN3270 server—A cluster is reserved for that client IP address. The first appropriate LU in the cluster that satisfies the client connection request is assigned.

•A client, with the same nailed IP address as a currently connected client, connects to the TN3270 server.

–Depending on the type of LU requested by the client (screen or printer LU), the first available screen or printer LU within a cluster that is reserved for that nailed IP address is allocated.

–If there is not an available screen or printer LU in an assigned cluster for the client connection, a new cluster is reserved for clients with that IP address. Then, the first appropriate LU in the cluster that satisfies the client connection request is assigned.

•A client, with a new IP address that is nailed to the same pool as other clients, connects to the TN3270 server—The next available cluster is reserved for that client IP address.

•A client requests a specific pool when connecting to the TN3270 server, but the client IP address is not nailed to the pool—The first available LU in the generic pool is allocated to the client.

For a detailed example of these LU allocation scenarios for a TN3270 server configuration using LU pooling, see the "LU Pooling Configuration Example" section.

Session Termination

The TN3270 server supports two configuration options that determine how the server responds when a client turns off the device or disconnects:

•LU Termination

•LU Deletion

LU Termination

In Cisco IOS Release 12.0(5)T and later, the TN3270 server supports LU termination options for sending either an UNBIND or a TERMSELF RU when a client turns off the device or disconnects from the server.

The termself keyword for the lu termination command orders termination of all sessions and session requests associated with an LU when a user turns off the device or disconnects from the server. This is an important feature for applications such as IBM's Customer Information Control System (CICS).

If you use an UNBIND request for session termination with CICS, Virtual Telecommunication Access Method (VTAM) security problems can arise. When CICS terminates a session from an UNBIND request, the application may reestablish a previous user's session with a new user, who is now assigned to the same freed LU.

LU Deletion

In Cisco IOS Release 12.0(5)T and later, the TN3270 server adds support for LU deletion options.

The lu deletion command specifies whether the TN3270 server sends a REPLY-PSID poweroff request to VTAM when a client disconnects. This command is recommended in host environments running VTAM version 4.4.1. Previous versions of VTAM are not compatible with Network Management Vector Transport (NMVT) REPLY-PSID.

Session Termination Scenarios

Sessions are terminated in the following conditions:

•The client logs off the LU-LU session and the LU is configured to disconnect on UNBIND.

•The client disconnects at the TCP layer.

•The client is idle too long or will not respond to a DO TIMING MARK message.

Any of the above conditions cause the server to do one of the following, depending upon how the lu termination command is configured:

•Unbind is configured—The TN3270 server sends an UNBIND followed by a NOTIFY (Secondary LU (SLU) DISABLED) message to the host. If the lu deletion command is configured to send a REPLY-PSID poweroff request, then the TN3270 server sends the request upon receipt of the NOTIFY response from the host.

•Termself is configured—The TN3270 server sends a NOTIFY (SLU DISABLED) to the host. Upon receipt of the NOTIFY response from the host, the TN3270 server sends a TERMSELF request to the host. If the lu deletion command is configured to send a REPLY-PSID poweroff request, then the TN3270 server sends the request upon receipt of the TERMSELF response.

Response-Time Collection

Response-time MIB support enables you to capture response-time statistics on the router for either individual sessions and clients or for groups of sessions and clients.

If SNMP is enabled on the router, a network management system (NMS) or users can use well-known and router-configured client group names to obtain response-time statistics. Response-time data collection is always enabled for all in-session clients, excluding printer clients. Table 2 shows the types of client groups that are monitored:

The names and IP subnets for the "client subnet" type of response-time group are user-defined. All other client groups are established dynamically by the TN3270 server as clients enter and exit applications. These client groups are named according to the format shown in the column labeled Client Group Name in Table 1.

In Cisco IOS Release 12.2, traps are not generated by the MIB.

Response-time data is collected using the following methods:

•Sliding-Window Average Response Times

•Response-Time Buckets

Sliding-Window Average Response Times

The sliding-window response-time method uses a moving average. It reflects the most recent response time and discounts the old response times. When there is no activity, this method preserves the old response times. The algorithm used for the sliding-window method is similar to the moving-average method. For detailed information about sliding-window average times, refer to the TN3270E-RT-MIB.

Response-Time Buckets

Response-time buckets contain counts of transactions with total response times that fall into a set of specified ranges. Response-time data gathered into a set of five buckets is suitable for verifying service-level agreements or for identifying performance problems through a network management application. The total response times collected in the buckets is governed by whether IP network transit times are included in the totals.

In Figure 5, four bucket boundaries are specified for a response-time collection, which results in five buckets.

Figure 5 Response-Time Boundaries

The first response-time bucket counts transactions with total response times that are less than or equal to boundary 1 (B-1), the second bucket counts transactions with response times greater than B-1 but less than or equal to B-2, and so on. The fifth bucket is unbounded, and it counts all transactions with response times greater than boundary 4.

The four bucket boundaries have default values of 1 second, 2 seconds, 5 seconds, and 10 seconds, respectively.

For a detailed explanation of response-time buckets, refer to the TN3270E-RT-MIB.

SSL Encryption Support

The SSL Encryption Support enhancement allows TN3270 clients and servers to negotiate authentication and encryption schemes using the Secure Socket Layer (SSL) technology. The TN3270 server uses SSL version 3.0 to establish secure sessions.

Preparing to Configure the TN3270 Server

Read the following sections to find important information that is useful to know before you configure the TN3270 server:

•Hardware and Software Requirements

•Design Considerations

•Configuring Host Connections

•VTAM Host Configuration Considerations

•TN3270 Server Configuration Modes

Hardware and Software Requirements

This section provides the following information about the hardware and software required to use the TN3270 server:

•Router Requirements

•Mainframe Requirements

•TN3270 Client Requirements

Router Requirements

The Cisco TN3270 server consists of a system image and a microcode image, which are virtually bundled as one combined image.

The following versions of hardware microcode are supported for the CIP and CPA in Cisco IOS Release 12.1:

•CIP hardware microcode—CIP27-2 and later

•CPA hardware microcode—XCPA27-2 and later

The following versions of hardware microcode are supported for the TN3270 Server Connectivity Enhancements feature on the CIP and CPA in Cisco IOS Release 12.1(5)T:

•CIP hardware microcode—CIP28-1 and later

•CPA hardware microcode—XCPA28-1 and later

To enable the TN3270 server feature, you must have a CMCC adapter installed in a Cisco 7000 with RSP7000, Cisco 7200 series router, or a Cisco 7500 series router.

For additional information about what is supported in the various releases of the Cisco IOS software and the CIP microcode, see the information on Cisco.com.

Inverse DNS Nailing

To use inverse DNS Nailing on the TN3270 server, you must specify which DNS servers are required to resolve the TN3270 server client IP addresses. To specify the DNS servers, use the following commands:

•ip domain-lookup

•ip domain-name

•ip name-server

SSL Encryption

To use TN3270 server SSL encryption, you must be running an IOS image with IPSec support. The strength of the SSL encryption support on the TN3270 server is determined by the strength of the IPSec image.

A server digital certificate loaded on the TN3270 router is also required.

Mainframe Requirements

Mainframe hosts using SNA with the TN3270 server must be running VTAM V4R2 or later.

Note You can use VTAM V3R4, but DLUR operation is not supported in V3R4 and proper DDDLU operation may require program temporary fixes (PTFs) to be applied to VTAM.

Dynamic LU Naming

The TN3270 server creates and deletes LUs dynamically on VTAM by sending Reply PSID poweron and Reply PSID poweroff messages when the named LU is connected and disconnected. To properly delete the dynamically created LUs, VTAM requires the following APARS:

•OW41274

•OW41686

•OW40315

You must replace the default exit ISTEXCSD with the VTAM User Exit for TN3270 Name Pushing, which you can download from the IBM website: http://www.ibm.com. This exit causes VTAM to ignore the LUSEED parameter on the PU statement, and instead use the SLU name sent by the router in the subvector 86 when a client connects in. If you do not configure this exit, VTAM ignores the subvector 86 and the specified LU name.

•If you specify the LUSEED operand for the PU definition in VTAM, and the subvector 86 specifies an LU name, the VTAM User Exit for TN3270 Name Pushing ignores the LUSEED operand.

•If you do not specify the LUSEED operand for the PU definition in VTAM, and the subvector 86 is not present, then the VTAM User Exit for TN3270 Name Pushing cannot generate an LU name. VTAM does not log this failure, and the TN3270 server does not receive the ACTLU request. The TN3270 server displays the following message:

*Apr 17 12:40:53:%CIP2-3-MSG:slot2 :

%TN3270S-3-NO_DYN_ACTLU_REQ_RCVD

  No ACTLU REQ received on LU JJDL1.6

Inverse DNS Nailing

If there are legacy and inverse DNS nailing statements, the inverse DNS nailing statements take precedence. The TN3270 server attempts an inverse DNS lookup before it checks for any legacy nailing configuration.

Cisco strongly recommends that you configure inverse DNS nailing on a PU that does not support generic LUs, or on a PU that has the generic-pool command configured but also has the deny keyword specified.

TN3270 Client Requirements

Based on the RFC standards, the Cisco TN3270 server supports any client that implements the TN3270 or TN3270E protocols.

Design Considerations

The number of sessions that a single TN3270 server can handle is directly related to the number of transactions per second and the amount of memory available to the CIP or CPA. There are other issues to be considered depending upon the environment that you want to support with the TN3270 server.

For comprehensive information about VTAM and router configuration issues and implementing specific TN3270 server scenarios, refer to the TN3270 Design and Implementation Guide.

Handling Large Configurations

The maximum size nonvolatile random-access memory (NVRAM) for the Cisco 7000, Cisco 7200, and Cisco 7500 series routers is 128 KB. The maximum number of nailing commands (commands that map IP addresses to LUs) that can be stored in a 128 KB NVRAM is approximately 4000. However, large configurations may contain as many as 10,000 nailing commands.

To maintain a configuration file that exceeds 128 KB there are two alternatives:

•Store the configuration file compressed in NVRAM.

•Store the configuration file in Flash memory (either internal Flash or on a PCMCIA card).

For more information about maintaining configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide. For information about router hardware and memory, refer to the hardware configuration guide for your Cisco router series.

Configuring Host Connections

Before configuring the TN3270 server, host connectivity must be configured using one of the following methods:

•Configuring CMPC support

•Configuring CSNA support

•Configuring Token Ring attachment to an FEP

For information about configuring CMPC or CSNA, see the "Configuring CSNA and CMPC" chapter in this publication.

VTAM Host Configuration Considerations

Other non-Cisco implementations of TN3270 support depend on predefined, static pools of LUs to support different terminal types requested by the TN3270 clients. The Cisco TN3270 server implementation on the CMCC adapter removes the static nature of these configurations by using a VTAM release 3.4 feature called DDDLU. DDDLU dynamically requests LUs using the terminal type provided by TN3270 clients. The dynamic request eliminates the need to define any LU configuration in the server to support TN3270 clients emulating a generic TN3270 terminal.

To support DDDLU, the PUs used by the TN3270 server have to be defined in VTAM with LUSEED and LUGROUP parameters, as shown in the following sample configuration:

Example VTAM host values defining LUSEED and LUGROUP name parameters:

TN3270PU

PU

.

IDBLK=05D,

IDNUM=30001,

Defines other PU parameters

LUSEED=TN3X1###,

*

Defines the seed component of 
the LU names created by DDDLU 
(e.g. LOCADDR 42 will have the 
name TN3X1042)

LUGROUP=AGROUP

*

Defines the LU group name

*

TN3X1100 

LU

LOCADDR=100,

MODETAB=AMODETAB

*

Defines a terminal which 
requires a specific LU name

*

TN3X1101

LU

LOCADDR=101,

DLOGMODE=M3287CS

*

Defines a printer which requires 
a specific LU name

Example VTAM host values defining LUGROUPname, AGROUP:

AGROUP

LUGROUP

*

Defines LU group to support 
various terminal types

327802E

LU

USSTAB=USSXXX,

LOGAPPL=TPXP001,

DLOGMOD=SNX32702,

SSCPFM=USS3270

*

Defines template to support IBM 
3278 terminal model 2 with 
Extended Data Stream. Note that 
the USS messages in USSXXX 
should be in 3270 datastream.

3278S2E

LU

USSTAB=USSYYY,

LOGAPPL=TPXP001,

DLOGMOD=SNX32702,

SSCPFM=USSSCS

*

Defines template to support IBM 
3278 terminal model 2 with 
Extended Data Stream, for 
TN3270E clients requesting 
BIND-IMAGE.

327805

LU

USSTAB=USSXXX,

LOGAPPL=TPXP001,

DLOGMOD=D4C32785,

SSCPFM=USS3270

*

Defines template to support IBM 
3279 terminal model 5

@

LU

USSTAB=USSXXX,

LOGAPPL=TPXP001,

DLOGMOD=D4A32772,

SSCPFM=USS3270

Defines the default template to 
match any other terminal types

With the configuration shown above defined in the host, the ACTPU sent by VTAM for the PU TN3270PU will have the "Unsolicited NMVT Support" set in the SSCP capabilities control vector. This allows the PU to dynamically allocate LUs by sending network management vector transport (NMVT) with a "Reply Product Set ID" control vector.

After the TN3270 server sends a positive response to the ACTPU, it will wait for VTAM to send ACTLUs for all specifically defined LUs. In the sample configuration shown in Figure 5, ACTLUs will be sent for TN3X1100 and TN3X1101. The server sends a positive response and sets SLU DISABLED. The LOCADDRs of the TN3X1100 and TN3X1101 LUs are put into the specific LU cache and reserved for specific LU name requests only.

To allow sufficient time for the VTAM host to send all the ACTLUs, a 30-second timer is started and restarted when an ACTLU is received. When the timer expires it is assumed that all ACTLUs defined in VTAM for the PU have been sent. All LUs that have not been activated are available in a generic LU pool to be used for DDDLU unless they have been reserved by the configuration using the generic-pool deny TN3270 configuration command.

After the VTAM activation, the server can support session requests from clients using dynamic or specific LU allocation.

For more information about DDDLU in VTAM, refer to the VTAM operating system manuals for your host system under the descriptions for LUGROUP.

Note If your host computer is customized for a character set other than U.S. English EBCDIC, you might need to code some VTAM configuration tables differently than indicated in the examples provided by Cisco.

Some VTAM configurations include the number sign (#) and at symbol (@). In the U.S. English EBCDIC character set, these characters are stored as the hexadecimal values 7B and 7C, respectively. VTAM will look for those hexadecimal values when processing the configuration file.

The characters used to enter these values are different in other EBCDIC National Language character sets. Table 3 lists the languages that have different characters for the 7B and 7C hexadecimal values and the corresponding symbols used to enter the characters.

For example, a parameter with a value of TN3X1### would have a value of TN3X1£££ for the French National Language character set.

TN3270 Server Configuration Modes

Figure 6 shows the TN3270 configuration modes that are supported in Cisco IOS Release 12.2 and which are described in the following sections of this topic:

•TN3270 Server Configuration Mode

•Listen-Point Configuration Mode

•Listen-Point PU Configuration Mode

•DLUR Configuration Mode

•DLUR PU Configuration Mode

•DLUR SAP Configuration Mode

•Response-Time Configuration Mode

•PU Configuration Mode

•Security Configuration Mode

•Profile Configuration Mode

The TN3270 server can be configured only on the virtual interface of a CMCC adapter. Some configuration commands create entities on the CMCC adapter. For most of these commands, the command changes to the mode associated with that entity (for example, a PU).

When preparing to configure the TN3270 server it is important to understand how to access and move between these different configuration modes. See the "Moving Between Configuration Modes" section for more information.

Figure 6 TN3270 Configuration Modes

Note The DLUR, DLUR SAP, DLUR PU and PU configuration modes existed in Cisco IOS Release 12.0(5)T and earlier. DLUR PU and PU configuration modes (shown in the shaded boxes) are legacy configuration modes, whose functions can be replaced by the listen-point configuration modes in Cisco IOS Release 12.0(5)T and later. For more information about the relationship of these legacy configuration modes to the new listen-point configuration modes, see the "Configuring the TN3270 Server with LU Pooling" section.

TN3270 Server Configuration Mode

From interface configuration mode, the following tn3270-server command puts you in TN3270 server configuration mode:

router(config-if)# tn3270-server

The following prompt appears:

(cfg-tn3270)#

Note For the CIP, enter interface configuration mode from the virtual channel interface using port 2; For the CPA, enter interface configuration mode from the physical channel interface using port 0.

Listen-Point Configuration Mode

From the TN3270 server configuration mode, the following listen-point command puts you in listen-point configuration mode:

router(cfg-tn3270)# listen-point ip-address [tcp-port [number]]

The following prompt appears:

(tn3270-lpoint)#

Listen-Point PU Configuration Mode

From listen-point configuration mode, you can create direct PUs and DLUR PUs:

•From the listen-point configuration mode, the following pu (listen-point) command creates a new direct PU:

router#(tn3270-lpoint)# pu pu-name idblk-idnum type adapno lsap [rmac rmac] [rsap 
rsap] [lu-seed lu-name-stem]

The pu (listen-point) command puts you in listen-point PU configuration mode and the following prompt appears:

(tn3270-lpoint-pu)#

•From listen-point configuration mode, the following pu dlur command creates a new PU for DLUR:

router#(tn3270-lpoint)# pu pu-name idblk-idnum dlur

The pu dlur command puts you in the listen-point PU configuration mode and the following prompt appears:

(tn3270-lpoint-pu)#

DLUR Configuration Mode

From TN3270 server configuration mode, the following dlur command puts you in DLUR configuration mode:

router(cfg-tn3270)# dlur fq-cpname fq-dlusname

The following prompt appears:

(tn3270-dlur)#

DLUR PU Configuration Mode

Note DLUR PU configuration mode is a legacy configuration mode whose function to define DLUR PUs can be replaced by using the listen-point configuration modes in Cisco IOS Release 12.0(5)T and later. When you define listen-point configurations, you can create DLUR PUs within listen-point PU configuration mode using the pu dlur command instead.

From DLUR configuration mode, the following pu (DLUR) command creates a new PU for DLUR:

router(tn3270-dlur)# pu pu-name idblk-idnum ip-address

The pu (DLUR) command puts you in the DLUR PU configuration mode and the following prompt appears:

(tn3270-dlur-pu)#

DLUR SAP Configuration Mode

From DLUR server configuration mode, the following lsap command puts you in DLUR SAP configuration mode:

router(tn3270-dlur)# lsap type adapno [lsap]

The following prompt appears:

(tn3270-dlur-lsap)#

Response-Time Configuration Mode

From TN3270 server configuration mode, the following response-time group command puts you in response-time configuration mode:

router(cfg-tn3270)# response-time group name [bucket boundaries t1 t2 t3 t4...][multiplier 
m]

The following prompt appears:

(tn3270-resp-time)#

PU Configuration Mode

Note PU configuration mode is a legacy configuration mode whose function to define direct PUs can be replaced by using the listen-point configuration modes in Cisco IOS Release 12.0(5)T and later. When you define listen-point configurations, you can create direct PUs within listen-point PU configuration mode using the pu (listen-point) command instead.

From TN3270 server configuration mode, the following pu (TN3270) command creates a new direct PU:

router(cfg-tn3270)# pu pu-name idblk-idnum ip-address type adapno lsap [rmac rmac] [rsap 
rsap] [lu-seed lu-name-stem]

The pu (TN3270) command puts you in PU configuration mode and the following prompt appears:

(tn3270-pu)#

Security Configuration Mode

From the TN3270 server configuration mode, the following security command puts you in security configuration mode:

router(cfg-tn3270)# security

The following prompt appears:

(tn3270-security)#

Profile Configuration Mode

From security configuration mode, the following profile command puts you in profile configuration mode:

router(cfg-tn3270)# profile profilename {ssl | none}

The following prompt appears:

(tn3270-sec-profile)#

Moving Between Configuration Modes

In general, the parameters within a configuration mode can be grouped into two categories:

•Parameters to identify the specific instance of the entity (for example, a PU name).

•Parameters to set operating options.

To return to a mode later in the configuration process, use the same configuration command but specify only the first set of identification parameters. The following examples show how to create, access, and remove different TN3270 entities in their associated configuration modes.

Working with a Listen-Point Direct PU

The following example shows how to create, access, and remove a listen-point PU entity:

1. To create a listen-point direct PU entity called PU1 and enter listen-point PU configuration mode from listen-point configuration mode, use the pu (listen-point) command as shown in the following example:

router(tn3270-lpoint)# pu PU1 94201231 tok 1 10

2. To return later to the listen-point PU configuration mode for the PU1 entity, use the same pu (listen-point) command without the "94201231 tok 1 10" parameters from listen-point configuration mode:

router(tn3270-lpoint)# pu PU1

3. To remove the listen-point PU entity called PU1, use the same command with the no keyword:

router(tn3270-lpoint)# no pu PU1

Working with a Listen-Point DLUR PU

The following example shows how to create, access, and remove a listen-point DLUR PU entity:

1. To create a listen-point DLUR PU entity called PU2 and enter listen-point PU configuration mode from listen-point configuration mode, use the pu dlur command as shown in the following example:

router(tn3270-lpoint)# pu PU2 017ABCDE dlur

2. To return later to the listen-point PU configuration mode for the PU2 entity, use the same pu dlur command without the "017ABCDE dlur" parameters from listen-point configuration mode:

router(tn3270-lpoint)# pu PU2

3. To remove the listen-point PU entity called PU2, use the same command with the no keyword:

router(tn3270-lpoint)# no pu PU2

Working with a DLUR Entity

The following example shows how to create, access, and remove a DLUR entity:

1. To create a DLUR entity with a control point name NETA.RTR1 and enter DLUR configuration mode from TN3270 server configuration mode, use the dlur command as shown in the following example:

router(cfg-tn3270)# dlur NETA.RTR1 NETA.HOST

2. To return later to the DLUR configuration mode for the NETA.RTR1 entity, use the same dlur command without the "NETA.RTR1 and NETA.HOST" parameters from TN3270 server configuration mode:

router(cfg-tn3270)# dlur

3. To remove the NETA.RTR1 DLUR entity, use the same dlur command with the no keyword:

router(cfg-tn3270)# no dlur

Working with a DLUR LSAP Entity

The following example shows how to create, access, and remove a DLUR LSAP entity:

1. To create a DLUR LSAP entity and enter DLUR SAP configuration mode from DLUR mode, type the following command:

router(tn3270-dlur)#lsap token-adapter 1 84

2. To return later to the DLUR SAP configuration mode on the same entity, use the same lsap command without the "84" parameter from TN3270 DLUR mode:

router(tn3270-dlur)#lsap token-adapter 1

3. To remove the DLUR LSAP entity, use the same identification parameters with the no keyword:

router(tn3270-dlur)#no lsap token-adapter 1 

Configuring the TN3270 Server

This section provides information about configuring and verifying the TN3270 server. It describes how to configure the commands that are applicable in multiple configuration modes, and how to configure the many options that are available in the TN3270 server.

This section also describes the tasks to configure the TN3270 server in certain environments, and references the configuration options that are available there. Older TN3270 server configurations that are still supported but are replaced by newer methods of configuration are discussed in the legacy configuration topic.

Finally, this section includes a basic procedure for verifying the TN3270 server configuration.

This section includes the following topics:

•Configuring TN3270 Siftdown Commands

•Configuring the TN3270 Server Options

•Configuring the TN3270 Server with LU Pooling

•Migrating from Legacy TN3270 Server Configuration Methods

•Verifying the TN3270 Server Configuration

See the "TN3270 Server Configuration Examples" section for examples.

Configuring TN3270 Siftdown Commands

There are many siftdown commands supported by the TN3270 server in multiple configuration modes. Values that you enter for a siftdown command in a subsequent configuration mode might override the values that you have entered for the same command (for the applicable PU only) in a previous configuration mode as shown in the hierarchy in Figure 6.

Consider the following example in which the keepalive (TN3270) command is configured in more than one command mode:

tn3270-server

keepalive 300

listen-point 10.10.10.1 tcp-port 40

  pu PU1 94223456 tok 1 08

    keepalive 10 send timing-mark 5

  pu PU2 94223457 tok 2 12

In this example the keepalive (TN3270) command is first configured in TN3270 server configuration mode, which applies to all PUs supported by the TN3270 server. The keepalive command is specified again under the listen-point PU configuration mode for PU1, which overrides the previously specified keepalive 300 value, for PU1 only. PU2 continues to use the value of the keepalive command in the TN3270 server configuration level.

Table 4 provides a list of the TN3270 siftdown commands and the associated configuration modes in which they are supported. An X in the column indicates that the command is supported. A "-" indicates that the command is not supported.

Note You cannot configure the siftdown commands shown in Table 4 while in DLUR, DLUR SAP, or response-time configuration modes for the TN3270 server.

The siftdown commands apply to the corresponding PUs, according to the configuration mode in which they are entered:

•TN3270 server configuration—The siftdown command at this level applies to all PUs supported by the TN3270 server.

•Listen-point configuration—The siftdown command at this level applies to all PUs defined at the listen point.

•Listen-point PU configuration—The siftdown command at this level applies to only the specified PU.

•PU configuration—The siftdown command at this level applies only to the specified PU.

The no form of a siftdown command typically inherits the value from the previously configured siftdown value from the entity above it according to the configuration mode hierarchy shown in Figure 6, or it returns to the default value.

Configuring the TN3270 Server Options

The TN3270 server supports many options, some of which are available in multiple configuration modes. The topics in this section explain background information about the TN3270 server options including why an option is useful and how you can configure it. The configuration procedures that are provided later in this chapter also indicate where the options are available in the configuration task list.

This section describes how to configure the following options for the TN3270 server:

•Configuring a Generic Pool of LUs

•Configuring Idle-Time

•Configuring IP Precedence

•Configuring IP ToS

•Configuring Keepalive

•Configuring LU Allocation and LU Nailing

•Configuring LU Deletion

•Configuring LU Termination

•Configuring the Maximum Number of Sessions Supported by the Server

•Configuring the Maximum Number of Sessions That Can be Obtained by a Single Client

•Configuring the TCP Port

•Configuring Timing Marks

•Configuring the Unbind Action

•Configuring SSL Encryption Support

Most of these options are available in multiple command modes and are called "siftdown" commands. For more information about how siftdown commands work, see the "Configuring TN3270 Siftdown Commands" section.

Refer to the "TN3270 Server Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 2 of 2) for additional information about the commands described in this section and chapter.

Configuring a Generic Pool of LUs

Configuring a generic pool of LUs in the TN3270 server specifies that "leftover" LUs from a pool of dynamic LUs are available to TN3270 sessions that do not request a specific LU or LU pool through TN3270E. All LUs in a generic pool are DDDLU capable.

A leftover LU is an inactive LU from a pool of dynamic LUs, which are defined in the switched major node in VTAM using the LU-SEED parameter and the LUGROUP parameter. A leftover LU is defined as an LU where all of the following conditions are true:

•The SSCP did not send an ACTLU during PU start-up.

•The PU controlling the LU is capable of carrying product set ID (PSID) vectors on NMVT messages, thus allowing DDDLU operation for that LU.

The default behavior is to permit a generic pool of LUs in the TN3270 server and allow leftover LUs to be used for dynamic connections. You might deny the use of the generic pool for security reasons.

To configure a generic pool of LUs for the TN3270 server, use the following command in TN3270 server, listen-point, listen-point PU, PU, or DLUR PU configuration modes:

The generic-pool command takes effect immediately for all upcoming connections, but existing sessions are unaffected. Once the existing sessions are terminated, then future connections will abide by the latest generic pool configuration for that PU. Use the no form of this command to selectively remove the permit or deny condition of generic pool use for the corresponding PU and return to the previously configured siftdown value applicable to the PU, or to the default value.

The generic-pool command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see "Configuring TN3270 Siftdown Commands" section.

Configuring Idle-Time

The idle time option in the TN3270 server specifies the allowable duration of inactivity in the client-server session before the TN3270 server disconnects an LU.

To prevent an LU session from being disconnected due to inactivity, specify an idle time value of 0 seconds. Note that TIMING-MARKS generated by the TN3270 server keepalive function are not considered "activity" on the client connection.

Note There are two TN3270 server options that can affect when a session is disconnected—idle time and keepalive. These two options operate independently of each other and both can be used to clean up partially disconnected sessions. Whichever option first detects that a session is eligible for disconnect immediately causes the TN3270 server to disconnect that session. If you are specifying both the idle time and keepalive options, then you might consider how the values for these options determine when client sessions are disconnected to achieve the response that you want.

To configure the allowable amount of idle time before the TN3270 server disconnects an LU, use the following command in TN3270 server, listen-point, listen-point PU, PU, or DLUR PU configuration modes:

The default behavior in TN3270 server configuration mode is that the session is never disconnected (or, a value of 0). The default value in other configuration modes is the value currently configured for that PU in a previously supported mode. Use the no form of this command to cancel the idle time period and return to the default for the corresponding PU.

The idle-time command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see "Configuring TN3270 Siftdown Commands" section.

Configuring IP Precedence

Configuring the IP precedence option in the TN3270 server allows you to assign different priority levels to IP traffic on a PU in the TN3270 server. IP precedence values are used with the weighted fair queueing (WFQ) or priority queueing features on a Cisco router to allow you to prioritize traffic. IP precedence and IP ToS values are used together to manage network traffic priorities.

The TN3270 server allows you to specify different IP precedence values for screen and printer clients because the communication requirements for each type of client is different. Screen clients are characterized by interactive communication which normally demands a higher priority of data transfer than printers. Printers are characterized by bulk data transfer where priority of sending the data is not as high.

To configure the traffic priority for screen and printer clients in the TN3270 server, use the following command in TN3270 server, listen-point, PU, or DLUR PU configuration modes:

Use the no form of this command to remove the screen or printer precedence value for the corresponding PU and return to the previously configured siftdown value applicable to the PU, or to the default value. However, you can enter new or different values for IP precedence without first using the no form of the command.

The ip precedence command in the TN3270 server is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see "Configuring TN3270 Siftdown Commands" section.

Configuring IP ToS

Configuring the IP ToS option in the TN3270 server allows you to assign different levels of service to traffic on a PU in the TN3270 server. IP ToS values are used with the WFQ and NetFlow switching features on a Cisco router. The Open Shortest Path First (OSPF) protocol can also discriminate between different routes based on IP ToS values. IP ToS and IP precedence values are used together to manage network traffic priorities.

The TN3270 server allows you to specify different IP ToS values for screen and printer clients because the communication requirements for each type of client is different. Screen clients are characterized by interactive communication which normally demands a higher priority of data transfer than printers. Printers are characterized by bulk data transfer where priority of sending the data is not as high.

To configure the level of service for screen and printer clients in the TN3270 server, use the following command in TN3270 server, listen-point, PU, or DLUR PU configuration modes:

Use the no form of this command to remove the screen or printer ToS value for the corresponding PU and return to the previously configured siftdown value applicable to the PU, or to the default value. However, you can enter new or different values for IP ToS without first using the no form of the command.

The ip tos command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

Configuring Keepalive

The keepalive options for the TN3270 server allow you to monitor the availability of a TN3270 client session by sending timing marks or Telnet no operation (nop) commands. You can configure the frequency and the type of keepalive that the TN3270 server sends to a client and when the TN3270 server determines that a client is inactive.

When you configure the keepalive command to send Telnet nop commands, no response is required by the client. If you specify only the keepalive interval, then the TN3270 server sends timing marks.

The default behavior of the TN3270 server is to send timing marks every 30 minutes if there is no other traffic flowing between the TN3270 client and server. The TN3270 server disconnects a session if the client does not respond within 30 seconds.

The keepalive command affects currently active and future TN3270 sessions. For example, reducing the keepalive interval for timing marks to a smaller nonzero value causes an immediate burst of DO TIMING-MARKS on those sessions that have been inactive for a period of time greater than the new, smaller value.

Note There are two TN3270 server options that can affect when a session is disconnected—idle time and keepalive. These two options operate independently of each other and both can be used to clean up partially disconnected sessions. Whichever option first detects that a session is eligible for disconnect immediately causes the TN3270 server to disconnect that session. If you are specifying both the idle time and keepalive options, then you might consider how the values for these options determine when client sessions are disconnected to achieve the response that you want.

To configure the keepalive options for the TN3270 server, use the following command in TN3270 server, listen-point, listen-point PU, PU, or DLUR PU configuration modes:

Use the no form of the command to cancel the current keepalive period and type and return to the previously configured siftdown value applicable to the PU, or to the default value.

The keepalive command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

Configuring LU Allocation and LU Nailing

With the addition of the LU pooling and listen-point configuration methods in Cisco IOS Release 12.0(5)T, the TN3270 server supports multiple methods of allocating LUs and assigning or "nailing" those LUs to a particular client or group of clients.

The TN3270 server supports nailing individual clients to a specific LU and nailing clients to pools. The individual nailing method is useful when a particular client must use a specific LU. Nailing clients to pools is useful when a client needs to have one of a group of LUs associated with a particular PU. For more information about these methods of LU nailing, see the "Methods of LU Nailing" section.

LU pooling configuration methods using listen points provides an efficient means of configuring clusters of screens and printer LUs into pools, and allocating LOCADDRs. Then, multiple clients can be assigned or "nailed" to those pools to be given access to those LUs.

Note You cannot specify the same LOCADDR in both an individual LU nailing statement and in a pool. The CMCC adapter does not allow a LOCADDR to be allocated multiple times, so the LU allocations in the TN3270 server must not overlap.

Nailing Clients to Specific LUs

To nail a client to a specific LU use the following command in PU configuration mode or listen-point PU configuration mode:

Nailing Clients to Pools

To nail a client to a pool of LUs use the following command in listen-point configuration mode:

Allocating LUs to Pools

To allocate LUs to a pool use the following command in listen-point PU configuration mode:

Configuring LU Deletion

The LU deletion options for the TN3270 server specify whether the TN3270 server sends a REPLY-PSID poweroff request to VTAM to delete the corresponding LU when a client disconnects. The LU deletion command is useful to prevent screen LUs from attaching to an LU that was used by a previous session that designates an incompatible screen size for the current LU.

The default behavior of the TN3270 server is to never delete LUs upon disconnect. This option is useful when you only have screen LUs and they all use the same screen size.

To configure the LU deletion options for the TN3270 server, use the following command in TN3270 server, listen-point, listen-point PU, PU, or DLUR PU configuration modes:

Use the no form of the command to remove LU deletion from the current configuration scope and return to the previously configured siftdown value applicable to the PU, or to the default value.

The lu deletion command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

For additional information about how sessions are terminated, see the "Session Termination" section.

Configuring LU Termination

The LU termination options for the TN3270 server specify the type of RU sent by the TN3270 server upon LU disconnect. The default behavior of the TN3270 server is to send an UNBIND request to the application to terminate the session.

With some applications (such as CICS), VTAM security problems can arise from an UNBIND request. In some cases the application might reestablish a previous user's session with a new user, who is now assigned to the same freed LU. To prevent this you can configure the TN3270 server to send a TERMSELF RU.

Use the termself keyword of the lu termination command when you want to be sure that the application terminates the session when the LU disconnects.

To configure the LU termination options for the TN3270 server, use the following command in TN3270 server, listen-point, listen-point PU, PU, or DLUR PU configuration modes:

Use the no form of the command to remove LU termination from the current configuration scope and return to the previously configured siftdown value applicable to the PU, or to the default value.

The lu termination command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

For additional information about how sessions are terminated, see the "Session Termination" section.

Configuring the Maximum Number of Sessions Supported by the Server

Configuring the maximum number of LU control blocks on the TN3270 server determines the limit on the number of sessions that the TN3270 server can support on the CMCC adapter. The practical limit (within the allowable range for the option) is determined in part by your licensing structure for the CMCC and on your hardware and usage characteristics.

Each control block uses about 1 KB of memory, with a possible 2 KB per LU additionally required for data during session activity. The TN3270 server attempts to allocate one LU control block for each LU activated by the host. For DDDLU, the control block is allocated when the client requests the LU, in anticipation of an ACTLU from the SSCP host.

By limiting the number of LU control blocks allocated, you can limit how much memory is used for the TN3270 server and be sure that memory is available to support other CMCC functions.

To configure the maximum number of LUs allowed for the TN3270 server, use the following command in TN3270 server configuration mode:

Use the no form of the command to restore the default value. Although you can change the value of the maximum-lus command at any time, you must deactivate the PU (DACTPU) or use the no pu command to free allocated control blocks if you reduce the maximum number below the current number of allowable LU control blocks.

Configuring the Maximum Number of Sessions That Can be Obtained by a Single Client

Configuring the maximum number of LU sessions for a TN3270 client limits the number of LU sessions that a client at a specified IP address or IP subnet can establish with the TN3270 server. Establishing this limit prevents a single workstation from using all of the available resources on the TN3270 server. If you configure LU pools and maximum LU sessions, the maximum LU session value limits the number of LOCADDRs that a client can connect to across all pools to which the client belongs.

If you do not configure the maximum number of LU sessions, the default configuration specifies no limit on the number of concurrent sessions from one client IP address.

To configure the maximum number of LU sessions allowed for a TN3270 client, use the following command in TN3270 server configuration mode:

Use the no form of the command to remove a single LU limit associated with a particular IP address, or to restore a default value of 65535.

Note There is no relationship between the allocate lu command and the client lu maximum command. The allocate lu command assigns named LOCADDRs to a pool. More than one TN3270 client can access pools and there is no relationship between the number of LUs assigned to a pool and the maximum number of LUs that one client can use.

Configuring the TCP Port

Configuring the TCP port option allows you to override the default TCP port setting of 23, which is the Internet Engineering Task Force (IETF) standard. The value of 65535 is reserved by the TN3270 server.

There are two ways that you can configure the TCP port:

•Using TN3270 server or PU configuration modes for the PU. This is the only method supported in legacy configurations, prior to Cisco IOS Release 12.0(5)T.

•In Cisco IOS Release 12.0(5)T and later, the TCP port can alternatively be configured in a listen point for the PU.

Legacy Configuration

To configure the TCP port in legacy configurations that do not implement a listen point, use the following command in TN3270 server, PU, or DLUR PU configuration modes:

Use the no form of the command to remove the TCP port from the current configuration scope and return to the previously configured siftdown value applicable to the PU, or to the default value.

The tcp-port command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

Listen-point Configuration

To configure the TCP port in listen-point configurations, use the following command in TN3270 server configuration mode:

Use the no form of the command to remove a listen point for the TN3270 server.

Configuring Timing Marks

Configuring the timing marks option for the TN3270 server specifies whether the TN3270 server sends a WILL TIMING-MARK in response to a definite or pacing request by a host application.

The default behavior of the TN3270 server is to send timing marks only for the keepalive function. If you configure the TN3270 server to send timing marks to achieve an end-to-end response protocol, then a WILL TIMING-MARK is sent by the TN3270 server when any of the following conditions are true:

•The host application requests a pacing response.

•The host application requests a definite response (DR), and either the client is not using TN3270E, or the request is not Begin Chain.

The use of timing marks can degrade performance. Some clients do not support timing marks used in this way. Therefore you should only configure timing marks when both of the following conditions are true:

•All clients support this timing mark usage.

•The application benefits from end-to-end acknowledgment.

To configure the timing marks option for the TN3270 server, use the following command in TN3270 server configuration mode:

Use the no form of the command to disable the sending of WILL TIMING-MARK except as used by the keepalive function.

Configuring the Unbind Action

Configuring the unbind action for the TN3270 server allows you to specify how the TN3270 server responds when it receives an UNBIND request. The TN3270 server can either keep the session or disconnect.

The default behavior in TN3270 server configuration mode is to disconnect the client session upon receipt of an UNBIND. In other configuration modes the default behavior is the currently configured value in the configuration mode applicable to the PU.

To configure the unbind action for the TN3270 server, use the following command in TN3270 server, listen-point, listen-point PU, PU, or DLUR PU configuration modes:

Use the no form of the command to remove the unbind action from the current configuration scope and return to the previously configured siftdown value applicable to the PU, or to the default value.

The unbind-action command is a siftdown command that is available in multiple command modes. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

Configuring SSL Encryption Support

Perform the tasks in the following sections to configure the SSL Encryption feature:

•Obtaining Server Digital Certificate from Certificate Authority (Required)

•Loading Server Digital Certificate onto the Flash of the TN3270 Router (Required)

•Configuring Security (Required)

•Configuring the Profile (Required)

•Configuring the Profile Options (Optional)

•Configuring the Default Profile (Optional)

•Configuring a Listen Point for Security (Optional)

Obtaining Server Digital Certificate from Certificate Authority

To obtain a server digital certificate, first create a certificate signing request pointer to the Readme.csr file. The certificate must be in PEM or Base 64 format.

After you obtain the server digital certificate, append the private key file to the digital certificate.

Loading Server Digital Certificate onto the Flash of the TN3270 Router

Copy the digital certificate to the Flash card on the TN3270 router.

Configuring Security

To configure security on the TN3270 server, use the following command beginning in TN3270 server configuration mode:

To enable and disable security on the TN3270 server, use the following commands beginning in security configuration mode:

Configuring the Profile

To configure a security profile on the TN3270 server, use the following command beginning in security configuration mode:

Configuring the Profile Options

To configure the security profile options, use the following commands beginning in profile configuration mode:

Configuring the Default Profile

To configure the default security profile name to be applied to the listen-points, use the following command beginning in security configuration mode:

Note The profile command must be specified before configuring a default-profile.

Configuring a Listen Point for Security

To configure a listen-point for security, use the following command beginning in TN3270 listen-point configuration mode:

Note The sec-profile command is optional if the default-profile command has been configured.

Configuring the TN3270 Server with LU Pooling

This section describes the required tasks to configure the TN3270 server with LU pooling in an APPN environment using DLUR PUs and in a non-APPN environment using direct PUs.

Step 1 Before configuring the TN3270 server, follow the "Guidelines for Configuring LU Pooling" section.

Step 2 Before you begin configuring the TN3270 server, be sure that you have configured host connectivity to the router. For more information about configuring host connectivity, see the "Configuring Host Connections" section.

Step 3 Complete the following tasks to configure the TN3270 server with LU pooling in an APPN environment using DLUR:

•Configuring the TN3270 Server and Defining a Pool

•Configuring DLUR

•Configuring SAPs Under DLUR

•Configuring a Listen Point and Nailing Clients to Pools

•Configuring Inverse DNS Nailing

•Configuring a Listen-Point PU to Define DLUR PUs and Allocate LUs

•Configuring a Listen-Point PU to Define DLUR PUs using Dynamic LU Naming

Note You can also use DLUR to reach a mix of APPN and non-APPN hosts. The host owning the PUs must be an APPN network node that also supports the subarea (that is, an interchange node). When an SLU starts a session with any of the APPN hosts, it can use session switching to reach that host directly. When it starts a session with a non-APPN host, the traffic will be routed through the owning host.

Step 4 Complete the following tasks to configure the TN3270 server with LU pooling in a non-APPN environment:

•Configuring the TN3270 Server and Defining a Pool

•Configuring a Listen Point and Nailing Clients to Pools

•Configuring a Listen-Point PU to Define Direct PUs and Allocate LUs

•Configuring a Listen-Point PU to Define Direct PUs using Dynamic LU Naming

Note The differences between the configuration tasks in a non-APPN environment and the APPN configuration tasks are that you do not configure DLUR or SAPs under DLUR, and you configure direct PUs at the listen point instead of DLUR PUs. All other options are the same.

Refer to the "Configuring the TN3270 Server Options" section of this publication and the "TN3270 Server Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 2 of 2) for additional information about the commands described in this section and chapter.

Guidelines for Configuring LU Pooling

To configure LU pools on the TN3270 server on a CMCC adapter, perform the following tasks:

1. Define a pool using the pool command.

2. Allocate specific LOCADDRs or LUs to the pool using the allocate lu command.

3. (Optional) Nail clients to the pool using the client ip pool command.

When configured, the pool becomes one of the several criteria used by the TN3270 server to assign an LU to a client. When a client requests a connection, the TN3270 server determines the authorized capabilities of the client. For example, the TN3270 server attempts to determine whether LU nailing definitions exist for the client.

Client preferences are taken into consideration. Examples of client preferences are:

•Device name on CONNECT request (TN3270E)

•LU name on TERMINAL-TYPE command (RFC 1576)

•Model type

When the client criteria is processed, the TN3270 server assigns the first available LU in the group to the client. If an appropriate LU is not found, the TN3270 connection is closed.

For more information about LU allocation in the TN3270 server, see the "LU Allocation" section. For an example of how LUs are allocated within LU pools, see the "LU Pooling Configuration Example" section.

Configuring the TN3270 Server and Defining a Pool

To establish a TN3270 server on the internal LAN interface on the CMCC adapter and configure LU pooling, use the following commands beginning in global configuration mode. When you use the tn3270-server command, you enter TN3270 server configuration mode and can use all other commands in the task list.

Configuring DLUR

This task is required when configuring DLUR connected hosts. To configure DLUR parameters for the TN3270 server, use the following commands beginning in TN3270 server configuration mode:

Configuring SAPs Under DLUR

To configure SAPs under the DLUR function, use the following commands beginning in DLUR configuration mode:

Configuring a Listen Point and Nailing Clients to Pools

To configure a listen point on the internal LAN interface on the CMCC adapter and nail clients to pools, use the following commands beginning in TN3270 server configuration mode.

When you use the listen-point command, you enter listen-point configuration mode and can use all other commands in this task list. Values that you enter for siftdown commands in listen-point configuration mode will override values that you previously entered in TN3270 server configuration mode.

Configuring Inverse DNS Nailing

Perform the tasks in the following section to configure the different methods of Inverse DNS Nailing feature:

•Nailing Clients to Pools by IP Address

•Nailing Clients to Pools by Device Name

•Nailing Clients to Pools by Device Name using a Domain ID

•Nailing Clients to Pools by Domain Name

•Nailing Clients to Pools by Domain Name Using a Domain ID

Note You can configure Inverse DNS Nailing five different ways by using the same commands. This task table section presents the five different configuration methods as separate task tables.

Use the domain-id command only when you are going to configure the client pool command with the name keyword and DNS-domain-identifier option specified or with the domain-id keyword specified.

Nailing Clients to Pools by IP Address

To nail a client to a pool of LUs by IP address, use the following commands beginning in TN3270 server configuration mode.

Nailing Clients to Pools by Device Name

To nail a client to a pool of LUs by device name, use the following commands beginning in TN3270 server configuration mode.

Nailing Clients to Pools by Device Name using a Domain ID

To nail a client to a pool of LUs by device name using a domain ID, use the following commands beginning in TN3270 server configuration mode.

Nailing Clients to Pools by Domain Name

To nail a client to a pool of LUs by domain name, use the following commands beginning in TN3270 server configuration mode.

Nailing Clients to Pools by Domain Name Using a Domain ID

To nail a client to a pool of LUs by domain name using a domain ID, use the following commands beginning in TN3270 server configuration mode.

Configuring a Listen-Point PU to Define DLUR PUs and Allocate LUs

To configure a listen-point PU on the internal LAN interface on the CMCC adapter and define DLUR PUs, use the following commands beginning in listen-point configuration mode.

When you use the pu command, you enter listen-point PU configuration mode and can use all other commands in this task list. Values that you enter for siftdown commands in listen-point PU configuration mode will override values that you previously entered in listen-point or TN3270 server configuration mode.

Configuring a Listen-Point PU to Define DLUR PUs using Dynamic LU Naming

To configure a listen-point PU on the internal LAN interface on the CMCC adapter, and to define DLUR PUs using dynamic LU naming, use the following commands beginning in TN3270 server configuration mode.

When you use the pu command, you enter listen-point PU configuration mode and can use all other commands in this task list. Values that you enter for siftdown commands (such as the lu deletion command) in listen-point PU configuration mode will override values that you previously entered in listen-point or TN3270 server configuration mode. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

Configuring the TN3270 Server and Defining a Pool

To establish a TN3270 server on the internal LAN interface on the CMCC adapter and configure LU pooling, use the following commands beginning in global configuration mode:

Configuring a Listen Point and Nailing Clients to Pools

To configure a listen point on the internal LAN interface on the CMCC adapter and nail clients to pools, use the following commands beginning in TN3270 server configuration mode.

When you use the listen-point command, you enter listen-point configuration mode and can use all other commands in this task list. Values that you enter for siftdown commands in listen-point configuration mode will override values that you previously entered in TN3270 server configuration mode.

Configuring a Listen-Point PU to Define Direct PUs and Allocate LUs

To configure a listen-point PU on the internal LAN interface on the CMCC adapter and configure direct PUs, use the following commands beginning in listen-point configuration mode.

When you use the pu command, you enter listen-point PU configuration mode and can use all other commands in this task list. Values that you enter for siftdown commands in listen-point PU configuration mode will override values that you previously entered in listen-point or TN3270 server configuration mode.

Configuring a Listen-Point PU to Define Direct PUs using Dynamic LU Naming

To configure a listen-point PU on the internal LAN interface on the CMCC adapter and configure direct PUs using dynamic LU naming, use the following commands beginning in listen-point configuration mode.

When you use the pu command, you enter listen-point PU configuration mode and can use all other commands in this task list. Values that you enter for siftdown commands (such as the lu deletion command) in listen-point PU configuration mode will override values that you previously entered in listen-point or TN3270 server configuration mode. For more information about configuring siftdown commands, see the "Configuring TN3270 Siftdown Commands" section.

Migrating from Legacy TN3270 Server Configuration Methods

Prior to Cisco IOS Release 12.0(5)T, TN3270 server configuration did not directly support listen points and LU pool configurations. These earlier methods for configuring PUs are referred to as "legacy" configuration methods. The TN3270 server commands to configure PUs vary slightly depending on whether or not you are using legacy configuration methods or listen points and LU pooling to configure PUs. While the legacy TN3270 server configuration commands are still supported, it is important to understand these variations in configuration so that you are not confused by the similar, but distinct command usages implemented for LU pooling.

Note Be sure that you use only a single configuration method for any particular IP address. Do not configure the same IP address using legacy methods and the newer listen-point configuration methods.

Methods of Configuring Direct PUs

For example, there are two ways in which you can configure direct PUs in the TN3270 server:

•TN3270 server configuration—In this legacy configuration mode you can use the pu (TN3270) command with the ip-address argument to create a PU entity that has its own direct link to a host at that IP address.

•Listen-point configuration—In this configuration mode you can use a different version of the pu command, but without an ip-address argument, to also create a PU entity that has its own direct link to a host defined at the listen point. In this configuration scenario, the IP address of the host is defined using the listen-point command and not in the pu (listen-point) command. This usage of direct PU configuration at a listen point allows you to eliminate repetitive configuration of the host IP address for each PU.

For examples of these methods of direct PU configuration see the "Basic Configuration Example" section and the "Listen-Point Direct PU Configuration Example" section.

Methods of Configuring DLUR PUs

Similarly, there are also two ways in which you can configure DLUR PUs in the TN3270 server:

•DLUR configuration—In this legacy configuration mode you can use a version of the pu command—pu (DLUR)—with pu-name, idblk-idnum, and ip-address arguments to create a PU entity that uses the SNA session switching facility to communicate with a host.

•Listen-point configuration—In this configuration mode you use a different command—the pu dlur command—with pu-name and idblk-idnum arguments to create a PU entity that uses the SNA session switching facility to communicate with a host addressed at the listen point.

For an example of these methods of DLUR PU configuration see the "Listen-Point DLUR PU Configuration Example" section.

Methods of LU Nailing

LU nailing is a method by which you can associate a client's connection request with a specific LU or pool of LUs. Use the following different methods to nail LUs in the TN3270 server:

•Nailing Clients to Specific LUs

•Nailing Clients to Pools

•Using a Combination of Nailing Methods

Nailing Clients to Specific LUs

Use the client ip lu legacy command when you want to assign a specific LOCADDR to a particular client at an IP address or subnet. This method of nailing is useful when a particular client must use a specific LU. You can use the client printer ip lu command to assign a particular LOCADDR to a client printer at an IP address or subnet.

Nailing Clients to Pools

Use the client ip pool command in listen-point configuration mode when you want to assign a group of LUs from a pool defined in the TN3270 server for a client at an IP address or subnet. This method of nailing is useful when a client needs to have one of a group LUs associated with a particular PU.

This configuration method uses the allocate lu listen-point PU configuration command to assign the range of LOCADDRS to the pool. The pool command defines the pool as a cluster of screen and printer LUs. In this method, clients can use the ASSOCIATE request to access printers defined to the pool.

Using a Combination of Nailing Methods

You can use both methods of LU nailing in a particular TN3270 server configuration, but there is no precedence in the configuration statements. Therefore when you nail a client to a specific LU or to a pool, you must be sure that the LOCADDR has not already been allocated. You cannot specify the same LOCADDR in both an individual LU nailing statement and in a pool. The CMCC adapter does not allow a LOCADDR to be allocated multiple times, so the LU allocations in the TN3270 server must not overlap.

For example, the following configuration statements are in error because LU 5 is allocated to both the pool and to an individual client at IP address 10.20.30.40:

tn3270-server

 pool MYPOOL cluster layout 4s1p

 pu PU1 12345678 tok 0 10

 allocate lu 5 pool MYPOOL clusters 2

 client ip 10.20.30.40 lu 5

The following example shows a valid configuration where a client at IP address 10.20.30.40 is nailed to the pool named EXAMPLE, which is allocated LOCADDRs 1 through 10, and an individual client at IP address 10.20.30.50 that is nailed only to LU 150:

tn3270-server

 pool EXAMPLE cluster layout 2s2p

 listen-point 80.80.80.81

  client ip 10.20.30.40 pool EXAMPLE

  pu PU1 12345678 tok 0 10

   allocate lu 1 pool EXAMPLE clusters 10

   client ip 10.20.30.50 lu 150

Verifying the TN3270 Server Configuration

This section provides basic steps that you can use to verify TN3270 server configurations. For detailed examples of configuration verification procedures for specific TN3270 server scenarios, see the Cisco TN3270 Design and Implementation Guide.

•Verify a Server Configuration that Uses LU Pooling

•Verify Dynamic LU Naming on the TN3270 Server

•Verifying Inverse DNS Nailing on the TN3270 Server

•Verifying SSL Encryption Support on the TN3270 Server

Verify a Server Configuration that Uses LU Pooling

Step 1 To display the current router configuration, enter the show run command:

router#show run

Building configuration...

interface Channel6/1

 no ip address

 no keepalive

 csna E160 40

!

interface Channel6/2

 ip address 172.18.4.17 255.255.255.248

 no keepalive

 lan TokenRing 15

  source-bridge 15 1 500

  adapter 15 4000.b0ca.0015

 lan TokenRing 16

  source-bridge 16 1 500

  adapter 16 4000.b0ca.0016

 tn3270-server

  pool PCPOOL   cluster layout 4s1p

  pool SIMPLE   cluster layout 1a

  pool UNIXPOOL cluster layout 49s1p

  dlur NETA.SHEK NETA.MVSD

   lsap token-adapter 15 04

    link SHE1     rmac 4000.b0ca.0016

  listen-point 172.18.4.18 tcp-port 23

   pu PU1      91903315 dlur

    allocate lu 1 pool PCPOOL   clusters 10

    allocate lu 51 pool UNIXPOOL clusters 2

    allocate lu 200 pool SIMPLE   clusters 50

  listen-point 172.18.4.19 tcp-port 2023

   pu PU2      91913315 token-adapter 16 08

    allocate lu 1 pool UNIXPOOL clusters 2

    allocate lu 101 pool SIMPLE   clusters 100

    allocate lu 201 pool PCPOOL   clusters 10

Step 2 To display information about the client LUs associated with a specific PU including the cluster layout and pool name, enter the show extended channel tn3270-server pu command:

Router#show extended channel 6/2 tn3270-server pu pu1 cluster

name(index)    ip:tcp               xid   state     link   destination  r-lsap

PU1(1)       172.18.4.18:23      91903315 ACTIVE    dlur   NETA.SHPU1

idle-time    0      keepalive 1800      unbind-act discon   generic-pool  perm

ip-preced-screen 0 ip-preced-printer 0 ip-tos-screen  0 ip-tos-printer 0

lu-termination unbind lu-deletion never

bytes 27489 in, 74761 out; frames 1164 in, 884 out; NegRsp 0 in, 0 out

actlus 5, dactlus 0, binds 5

Note: if state is ACT/NA then the client is disconnected

lu    name   client-ip:tcp       nail state    cluster   pool  count

1   SHED1001 161.44.100.162:1538   N   ACT/SESS 1/4s1p  PCPOOL   1/5

51  SHED1051 161.44.100.162:1539   N   ACT/SESS 1/49s1p UNIXPOOL 1/50

151 SHED1151 161.44.100.162:1536   N   ACT/SESS 1/1a    :GENERIC 1/1

152 SHED1152 161.44.100.162:1537   N   ACT/SESS 1/1a    :GENERIC 1/1

200 SHED1200 161.44.100.162:1557   N   ACT/SESS 1/1a    SIMPLE   1/1 

Verify Dynamic LU Naming on the TN3270 Server

Complete the following steps to verify the Dynamic LU Naming enhancement:

Step 1 Issue the show extended channel tn3270-server command. Confirm that lu-deletion is set to named.

Router# show extended channel 3/2 tn3270-server

<current stats> < connection stats >  <response time(ms)>

server-ip:tcp        lu in-use   connect disconn fail   host     tcp

172.28.1.106:23     510     1       12       11     0     54     40

172.28.1.107:23     511     0        0        0     0      0      0

172.28.1.108:23     255     0        0        0     0      0      0

total              1276     1

configured max_lu 20000

idle-time    0           keepalive 1800      unbind-action disconnect

tcp-port   23            generic-pool permit no timing-mark

lu-termination unbind lu-deletion named

Step 2 To verify that dynamic LU naming is configured on the PU named PU1, issue the show extended channel tn3270-server pu command. Confirm that lu-deletion is set to named.

Router# show extended channel 6/2 tn3270-server pu pu1

name(index)    ip:tcp               xid   state     link   destination r-lsap

PU1(1)       172.18.4.18:23      91903315 ACTIVE    dlur   NETA.SHPU1

idle-time    0      keepalive 1800      unbind-act discon   generic-poolperm

ip-preced-screen 0 ip-preced-printer 0 ip-tos-screen  0 ip-tos-printer 0

lu-termination unbind lu-deletion named

Troubleshooting Tips for Dynamic LU Naming

To troubleshoot dynamic LU naming, use the following tips:

•You must replace the default exit ISTEXCSD with the VTAM User Exit for TN3270 Name Pushing, which you can download from the IBM website: http://www.ibm.com. This exit causes VTAM to ignore the LUSEED parameter on the PU statement, and instead use the SLU name sent by the router in the subvector 86 when a client connects in. If you do not configure this exit, VTAM ignores the subvector 86 and the specified LU name.

•If the LUSEED operand is specified on the mainframe, but the subvector 86 requires an LU name, the VTAM User Exit for TN3270 Name Pushing ignores the LUSEED operand.

•If the LUSEED operand is not specified on the mainframe, and the subvector 86 is not present, then the VTAM User Exit for TN3270 Name Pushing cannot generate an LU name. VTAM does not log this failure, and the TN3270 server does not receive the ACTLU request. The TN3270 server displays the following message:

*Apr 17 12:40:53:%CIP2-3-MSG:slot2 :

%TN3270S-3-NO_DYN_ACTLU_REQ_RCVD

  No ACTLU REQ received on LU JJDL1.6

Specify the INCLUD0E=YES parameter on VTAM so that the TN3270 server will always receive the LU name generated by the VTAM User Exit for TN3270 Name Pushing.

Verifying Inverse DNS Nailing on the TN3270 Server

Complete the following steps to verify the Inverse DNS Nailing enhancement:

Step 1 To list all nailing statements with a specific nailed-domain name, enter the show extended channel tn3270-server nailed-domain command:

Router# show extended channel 1/2 tn3270-server nailed-domain .cisco.com

CISCO.COM listen-point 172.18.4.18  pool PCPOOL

Step 2 To list all nailing statements with a specific nailed machine name, enter the show extended channel tn3270-server nailed-name command:

Router# show extended channel 1/2 tn3270-server nailed-name myclient.cisco.com

MYCLIENT.CISCO.COM     listen-point 172.18.4.18  pool PCPOOL

HISCLIENT.CISCO.COM    listen-point 172.18.4.18  pool UNIXPOOL

HERCLIENT.CISCO.COM    listen-point 172.18.4.19  pool GENERALPOOL

Troubleshooting Tips for Inverse DNS Nailing

To troubleshoot inverse DNS nailing, use the following tips:

•If an inverse DNS lookup fails it could be because the DNS server is unavailable (either because it was not configured, or because it is down). In this case, you cannot tell if the client is nailed because it does not have a name. To complicate the scenario, assume there was not a legacy nailing match, but the PU supports LUs that have been assigned from a generic pool. In this situation, the client disconnects and the router displays the following console message:

A connection attempt from client <ip address> was refused because its DNS name could 
not be obtained.

This action removes any potential security risk but presents potential disadvantages—the client could be denied a valid LU, and the generic-pool permit and deny settings might be ignored. For these reasons, it is strongly recommended that users configure the Inverse DNS Nailing enhancement on a PU that does not support LUs that have been assigned from a generic pool or a PU that has the generic-pool command configured with the deny keyword specified.

•If an inverse DNS lookup succeeds, but the name is not nailed or the client has no machine name, then the client is not nailed and the TN3270 server reverts to the legacy LU nailing process.

Verifying SSL Encryption Support on the TN3270 Server

Complete the following steps to verify the SSL Encryption Support enhancement:

Step 1 To verify the security profile on the TN3270 server, enter the show extended channel tn3270-server security command using the sec-profile option. Confirm that the status is enabled (status: ENABLE), and that the security certificate is loaded (Certificate Loaded: YES).

Router# show extended channel 3/2 tn3270-server security sec-profile cert40

status:ENABLE Default Profile: (Not Configured)

Name               Active LUs  keylen encryptorder            Mechanism

CERT40                    0     40    RC4 RC2 RC5 DES 3DES    SSL

Servercert:slot0:coach188.pem

Certificate Loaded:YES				 Default-Profile:NO

Step 2 To verify the security profile on the TN3270 server listen-point, enter the show extended channel tn3270-server security command using the listen-point option. Confirm that the status is enabled (status: ENABLE) and that the state is active (State ACTIVE).

Router# show extended channel 3/2 tn3270-server security listen-point 172.18.5.188

status:ENABLE Default Profile: (Not Configured)

IPaddress      tcp-port   Security-Profile   active-sessions  Type    State

172.18.5.188    23        CERT40               0              Secure  ACTIVE

Active Sessions using Deleted Profile:0

Configuring the TN3270 Server for Response-Time Monitoring

To configure client subnet response-time groups, use the following commands in response-time configuration mode:

Verifying Response-Time Configuration

To verify the configuration of the client subnet response-time groups, use the show extended channel tn3270-server response-time subnet command.

To display a complete list of client subnet groups and their response-time collection control parameters, use the following form of the command:

Router# show extended channel 3/2 tn3270-server response-time subnet

group SUBNETGROUP1

  subnet 10.10.10.0 255.255.255.192

  aggregate NO excludeip NO dynamic definite response NO

  sample period multiplier 30

  bucket boundaries 10 20 50 100

group SUBNETGROUP2

  subnet 10.10.10.128 255.255.255.192

  subnet 10.10.10.192 255.255.255.192

  aggregate NO exclude ip NO dynamic definite response NO

  sample period multiplier 40

  bucket boundaries 20 30 60 120

group CLIENT SUBNET OTHER

  aggregate NO exclude ip NO dynamic definite response NO

  sample period multiplier 30

  bucket boundaries 10 20 50 100

To display the response-time collection parameters for a specific subnet, along with a list of the client members and their response-time statistics, use the following form of the command:

Router# show extended channel 3/2 tn3270-server response-time subnet

10.10.10.0 255.255.255.192 detail

group SUBNETGROUP1

  subnet 10.10.10.0 255.255.255.192

  aggregate NO excludeip NO dynamic definite response NO

  sample period multiplier 30

  bucket boundaries 10 20 50 100

  client 10.10.10.129:23

    buckets 5 8 11 9 4

    average total response time 33 average IP response time 24

    number of transactions 37

  client 10.10.10.130:23

    buckets 6 9 10 10 2

    average total response time 32 average IP response time 25

    number of transactions 37

  client 10.10.10.131:23

    buckets 11 14 10 8 7

    average total response time 27 average IP response time 19

    number of transactions 50

Monitoring and Maintaining the TN3270 Server

Use the following show commands in the privileged EXEC mode to monitor the TN3270 server. The port value differs by the type of CMCC adapter:

•CIP—port value corresponds to the virtual interface, which is port 2

•CPA—port value corresponds to port 0

Other maintenance and monitoring options for the TN3270 include:

•Managing DLUR Links

•Monitoring Dynamic LU Naming

•Monitoring Inverse DNS Nailing

•Shutting Down the TN3270 Server and Its Entities

Managing DLUR Links

The CMCC adapter allows you to convert a dynamic link to a static link while the DLUR subsystem is running. Dynamic links are those links that are established outside of the scope of the TN3270 DLUR configuration. These links are either configured by the host or are established dynamically using the VRN function and are activated by DLUR or activated remotely.

There are several advantages of converting a dynamic link to a static link:

•Supports removing a DLUR link without having to shut down the entire DLUR subsystem.

•In Network Node server configurations, having two or three static links defined allows you to provide adequate redundancy. You might want to convert a dynamic link to a static link to provide this benefit.

•Static links allow better control from the router end to show and control them. Dynamic links cannot be specifically shown or controlled by the router. The links appear in show command output, but with locally assigned names such as @DLURnn which make them difficult to identify.

Converting a Dynamic Link to a Static Link

To convert a dynamic link to a static link the CMCC adapter allows you to re-enter the local/remote MAC/SAP quadruple in the link (TN3270) command, which the CMCC accepts as a request to convert the link to a static link, and does not reject the command due to a duplicate local/remote MAC/SAP quadruple.

For example, use the following link (TN3270) command to convert the existing dynamic link named HOST at RMAC 4000.0000.0001 and RSAP 4 to a static link:

link HOST rmap 4000.0000.0001 rsap 4

Removing a Dynamic Link

To remove a dynamic link use the following commands in DLUR SAP configuration mode to convert the dynamic link to a static link and then to remove the link:

Monitoring Dynamic LU Naming

To monitor the status of the Dynamic LU Naming enhancement, use the following commands in EXEC mode:

Monitoring Inverse DNS Nailing

To monitor the status of the Inverse DNS Nailing enhancement, use the following commands in EXEC mode:

Shutting Down the TN3270 Server and Its Entities

To shut down the entire TN3270 server or to shut down individual TN3270 server entities, use the shutdown command in the appropriate configuration mode. The shutdown command is available in multiple configuration modes, including interface configuration mode for the CMCC adapter. This support allows you to have varying levels of control for different configurable entities.

For TN3270 server configurations, you can use the shutdown command in the following command modes:

•TN3270 server configuration mode—Shuts down the entire TN3270 server function.

•PU configuration mode—Shuts down an individual PU entity within the TN3270 server.

•DLUR configuration mode—Shuts down the whole DLUR subsystem within the TN3270 server.

•DLUR PU configuration mode—Shuts down an individual PU within the SNA session switch configuration in the TN3270 server.

•DLUR SAP configuration mode—Shuts down the local SAP and its associated links within the SNA session switch configuration.

•Listen-point configuration mode—Shuts down a listen point and all of its associated configuration entities.

•Listen-point PU configuration mode—Shuts down an individual PU within the listen point configuration.

To shut down the TN3270 server or a specific entity within the TN3270 server configuration, use the following command in the appropriate configuration mode:

TN3270 Server Configuration Examples

This section provides examples of router configurations for the TN3270 server. It provides LU pooling configuration examples with DLUR and with direct PU and legacy configuration examples without LU pooling:

•Basic Configuration Example

•Listen-Point Direct PU Configuration Example

•Listen-Point DLUR PU Configuration Example

•LU Pooling Configuration Example

•TN3270 Server Configuration Without LU Pooling Example

•TN3270 DLUR Configuration With CMPC Host Connection Example

•Removing LU Nailing Definitions Example

•TN3270 Server DLUR Using CMPC Example

•Dynamic LU Naming Example

•Inverse DNS Nailing Examples

•SSL Encryption Support Examples

Note The first three configuration examples in this section apply only to users who are already using TN3270.

Basic Configuration Example

The following example shows a router with a legacy TN3270 server configuration and PU specification prior to LU pooling and listen-point configuration support:

tn3270-server

 pu PU1 94223456 10.10.10.1 tok 1 08

  tcp-port 40

  keepalive 10

The following example shows the same router with a later TN3270 server configuration that replaces the existing configuration and uses the listen-point command to accomplish LU pooling. The listen-point command was first introduced in Cisco IOS Release 11.2(18)BC.

tn3270-server

 listen-point 10.10.10.1 tcp-port 40

   pu PU1 94223456 tok 1 08

    keepalive 10

Note In the new configuration, the IP address is not configured in the PU. Instead, the IP address is configured as a listen point and the PU is configured within the scope of the listen point. The tcp-port command is not configured within the scope of the PU, instead it is specified with the listen-point command.

Listen-Point Direct PU Configuration Example

The following example shows a router with a legacy TN3270 server configuration that contains different PUs configured with the same IP addresses:

tn3270-server

 pu PU1 94201231 10.10.10.2 tok 1 10

 pu PU2 94201232 10.10.10.3 tok 1 12

 pu PU3 94201234 10.10.10.3 tok 1 14

 pu PU4 94201235 10.10.10.4 tok 1 16

  tcp-port 40

 pu PU5 94201236 10.10.10.4 tok 2 08

The following example shows the same router replaced with a later TN3270 server configuration that uses the listen-point command introduced in Cisco IOS Release 11.2(18)BC:

tn3270-server 

 listen-point 10.10.10.2 

  pu PU1 94201231  tok 1 10

 listen-point 10.10.10.3

  pu PU2 94201232  tok 1 12

  pu PU3 94201234  tok 1 14

 listen-point 10.10.10.4

  pu PU5 94201236  tok 2 08

 listen-point 10.10.10.4 tcp-port 40

  pu PU4 94201235  tok 1 16

In this example, PU2 and PU3 are grouped into one listen point because they have the same IP address. Note that even though PU4's IP address is identical to PU5's IP address, they are not configured within the same listen point because the listen point indicates a unique IP address and TCP port pair. If you do not specify the TCP port, the default port value is 23.

Listen-Point DLUR PU Configuration Example

The following example shows a router with a legacy TN3270 server configuration for DLUR:

tn3270-server

 dlur NETA.RTR1 NETA.HOST

  dlus-backup NETA.HOST 

  lsap token-adapter 15 08

  link MVS2TN   rmac 4000.b0ca.0016

  pu PU1 017ABCDE 10.10.10.6

The following example shows the same router replaced with a later TN3270 server configuration that uses the new listen-point command introduced in Cisco IOS Release 11.2(18)BC:

tn3270-server

 dlur NETA.RTR1 NETA.HOST

  dlus-backup NETA.HOST 

  lsap token-adapter 15 08

  link MVS2TN   rmac 4000.b0ca.0016

 listen-point 10.10.10.6

  pu PU1 017ABCDE dlur

In this example, the PU is not configured within the scope of DLUR. Instead the PU is configured within the listen-point scope. The keyword dlur differentiates the listen-point direct PU from the listen-point DLUR PU. Note that the DLUR configuration must be completed before PU1 is configured.

Any siftdown commands configured within the scope of listen point are automatically inherited by the PUs that are configured within the scope of that listen point. To override the siftdown configurations, you can explicitly configure the siftdown configuration commands within the scope of the listen-point PU.

LU Pooling Configuration Example

Figure 7 shows a router running the TN3270 server (with DLUR PUs) and its LU pooling configuration.

Figure 7 TN3270 Server Using LU Pooling

To understand how LUs are allocated for clients that are nailed to pools in the TN3270 server, consider the router configuration for PU2 on the following pages, and assume that cluster 1 for PCPOOL has no LUs currently assigned to clients.

For a PC client with IP address 20.40.34.1, the TN3270 server reserves LUs 201-205 for cluster 1 of the PCPOOL. PCPOOL is defined with a cluster layout of "4s1p" for a total of 5 LUs (Figure 9). Because the cluster 1 LUs are reserved, a second PC client with IP address 20.40.34.7 (also nailed to the PCPOOL) is given LUs 206 to 210 for cluster 2 of the PCPOOL (provided that cluster 2 is the next available cluster without LUs currently allocated).

Next, consider that a total of 4 clients with IP address 20.40.34.1 have connected with a request for a screen LU. These clients are allocated LUs 201 to 204 (cluster 1) because according to the cluster definition "4s1p", the first 4 LUs are screen LUs. According to the cluster definition the last (5th) LU is a printer LU.

This means that cluster 1 is fully allocated for screen LUs. In this example, the next client with IP address 20.40.34.1 that connects with a request for a screen LU reserves the next available cluster, with LUs 211 to 215. This client is allocated LU 211, which is a screen LU.

The first client with IP address 20.40.34.1 to request a printer LU from the TN3270 server is allocated LU 205. LU 205 is the first available printer LU in the first cluster of reserved LUs for IP address 20.40.34.1.

Clients that connect with a request for a specific pool but that are not nailed to that pool are allocated an LU from the generic pool. In this example, an available LU in the range 251 to 255 is allocated.

The following router configuration shows an example of commands used to define the TN3270 server with LU pools.

Router Configuration

logging buffered

! logs Cisco IOS software messages to the internal buffer using the default

! buffer size for the router platform

interface Channel 6/1

 no ip address

 no keepalive

 csna E160 40

!

interface Channel 6/2

 ip address 172.18.4.17 255.255.255.248

 no keepalive

 lan TokenRing 15

  source-bridge 15 1 500

  adapter 15 4000.b0ca.0015

 lan TokenRing 16

  source-bridge 16 1 500

  adapter 16 4000.b0ca.0016

 tn3270-server

  pool NEREGION cluster layout 1a

  pool PCPOOL   cluster layout 4s1p

  pool UNIXPOOL cluster layout 49s1p

  dlur NETA.SHEK NETA.MVSD

   lsap token-adapter 15 04

    link SHE1     rmac 4000.b0ca.0016

  listen-point 172.18.4.18

   client ip 10.20.20.30 pool UNIXPOOL

   client ip 10.20.40.0 255.255.255.0 pool PCPOOL

   client ip 10.20.30.0 255.255.255.128 pool NEREGION

   pu PU1      91903315 dlur

    allocate lu 1 pool PCPOOL   clusters 10

    allocate lu 51 pool UNIXPOOL clusters 2

    allocate lu 200 pool NEREGION clusters 50

  listen-point 172.18.4.19

   client ip 20.30.40.40 pool UNIXPOOL

   client ip 20.40.34.0 255.255.255.0 pool PCPOOL

   client ip 20.40.50.0 255.255.255.128 pool NEREGION

   pu PU2      91913315 dlur

    allocate lu 1 pool UNIXPOOL clusters 2

    allocate lu 101 pool NEREGION clusters 100

    allocate lu 201 pool PCPOOL   clusters 10

Figure 8 shows cluster layouts for PU1 in the TN3270 server.

Figure 8 Cluster Layouts for PU1 in the TN3270 Server