Table Of Contents
Hardware and Software Requirements
Where to Place the TN3270 Server and How Many Servers You Need
Implementing TN3270 Server on a CIP/CPA
Addressing LAN Printing Requirements
Addressing SNA Routing in Multi-Domain Environments
Addressing End User Service Level Requirements
Addressing Availability Requirements (Redundancy/Load Balancing)
Satisfying Expanding Network Address Requirements
TN3270 Server Configuration Modes
TN3270 Server Implementation
This chapter discusses the following aspects of TN3270 Server implementation:•
TN3270 Server on the CIP/CPA
•
TN3270 Server on the CIP/CPA
The TN3270 Server feature of the Cisco IOS software can be used in the following situations:
•
With the TN3270 Server in a channel-attached router, SNA can be terminated in the data center and still support the legacy TN3270 applications. The backbone network outside the data center can be pure IP. Similarly, if clients in branch offices need TN3270 connectivity, this can be provided without having to support SNA stacks at the branch office.
•
Enabling the TN3270 Server functions in the router enables you to offload TN3270 and TCP/IP processing from the host and saves host CPU cycles.
•
This support makes the TN3270 Server an enterprise-wide 3270 access solution.
Figure 2-1 TN3270 Session Overview
Hardware and Software Requirements
This section provides information about the hardware and software required to use the TN3270 Server. For additional information about what is supported in the various releases of the Cisco IOS software and the CIP microcode, see the information on CCO.Router Software Requirements
The TN3270 Server consists of a system image and a new microcode image. These are bundled as one combined image. The TN3270 Server feature was first included in the Cisco IOS Release 11.0BT special release. It is also included in release 11.2 and later. LU nailing, the process of mapping an IP address to an LU, was first included in the Cisco IOS Release 11.3.Router Hardware Requirements
The CIP hardware microcode must be CIP22-23 or later. The CPA hardware level must be CIP26-2 or later with Cisco IOS Release 11.3T or later.Mainframe Requirements
The hosts communicating via SNA with the TN3270 Server must be running VTAM V4R2. You can use VTAM V3R4, but DLUR operation is not supported in V3R4 and proper Dynamic Definition of Dependent LU (DDDLU) operation may require program temporary fixes (PTFs) to be applied to VTAM. We recommend using VTAM V4R2.TN3270 Client Requirements
Based on the RFC standards, the Cisco TN3270 Server will work with any client that implements the TN3270 or TN3270E protocols.Planning for Implementation
This section discusses the following considerations that must be addressed before implementing a TN3270 Server in your network:•
•
•
•
•
•
•
Where to Place the TN3270 Server and How Many Servers You Need
The TN3270 Server can be placed on a local router (one that is directly attached to the mainframe) or a remote router. If the router is local, the TN3270 Server resides on a CIP or CPA that is connected to the mainframe via ESCON or bus-and-tag. However, many organizations use the TN3270 Server on remote routers as an intermediate step in their migration to using the CIP or CPA as the host connection option. In this case, the TN3270 Server is placed on a router that is connected to the mainframe via any channel connection device, such as the FEP. Although placing the TN3270 Server on a remote router is not an optimal, long-term solution, it allows sites that are migrating from the FEP to the CIP or CPA to have TN2370 server functionality immediately.
The Cisco TN3270 Server provides up to 16,000 concurrently active LUs per channel-attached router at a rate of 850 transactions per second. The TN3270 server will support considerably more LUs at a lower throughput rate. While most organizations would never reach 16,000 concurrent sessions in a production environment, the TN3270 Server was designed to accommodate this number of sessions to account for day-to-day usage and to provide a buffer for failover LUs in the event of a failure of another TN3270 Server. Most large companies use their TN3270 servers at 12,000 to 14,000 users on a daily basis. On average, they install eight to ten CIPs or CPAs to provide TN3270 access for approximately 100,000 users.
The number of sessions 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. The 16,000 LU session capacity is based on 850 transactions per second and a session size of 200 bytes inbound (from the terminal) and 800 bytes outbound (to the terminal). Normally, a single terminal (or LU) is rated at one transaction per minute. Therefore, if a server can handle 1 transaction per second, then it can accommodate 60 terminals. At a rate of 850 transactions per second, it can accommodate 16,000 terminals. Printer LUs and file transfers reduce the number of available sessions.
Although the TN3270 Server can manage tens of thousands of sessions, you should consider the impact of gateway disruption when designing your network. How many users can you afford to disrupt if a gateway goes down? A typical number is 12,000 to 14,000 sessions, which allows them to benefit from the increased throughput rate.
The TN3270 Server has been tested with up to 30,000 concurrently active LUs.
Implementing TN3270 Server on a CIP/CPA
The TN3270 Server feature of Cisco IOS software can be implemented on either a CIP or a CPA.•
•
Note:
Defining PUs
SNA communication is based on the concept of PUs and LUs. When deciding how to configure a TN3270 Server, one of the first things you must consider is the type of PUs you will use and how you want to define them. The TN3270 Server supports two types of PUs:•
•
DLUR PUs and direct PUs can coexist on the same CIP/CPA.
The definition of each direct PU within the router requires a local service access point (SAP) to be defined. Traditionally, SNA uses SAP 04, 08, 0C, and so forth (multiples of four). But the source SAP used by the TN3270 adapter must be an even value. Each PU on a TN3270 adapter on the CIP must, however, have a unique local/remote media access control (MAC)/SAP quadruple. If the PUs are on the same adapter and are to connect to the same remote MAC (RMAC) and remote SAP (RSAP), then each must have a different link SAP (LSAP). Therefore, to create dozens of PUs tied to one TN3270 adapter, separate the SAPs by two or four. SAPs are in hexadecimal format and starting at AA are reserved for other uses (such as Subnetwork Access Protocol [SNAP] headers, IP, and address resolution protocol [ARP]). If you start with SAP 02 and increment each SAP by two, you can tie about 120 SAPs to an adapter. To define more SAPs, create another adapter and start over with SAP 4.
Each direct PU is defined on the CIP/CPA with a listening IP address and a target MAC address that goes to a particular logical partition (LPAR). The listening address is the IP address that the client addresses when requesting an LU from the associated PU. Multiple PUs can be defined with the same IP listening address and thereby create a pool of LUs. This pool of LUs is 255 LUs times the number of PUs with the same listening address. When a user requests an LU using the listening address that is associated with the group of PUs, the client will receive an LU from that pool. There is a predefined algorithm that is used to decide what LU the clients receives. (See the " Monitoring the TN3270 Server" section.) One TN3270 Server can simultaneously service multiple LPARs if you create a single PU or a pool of PUs per LPAR. To identify which PU or pool of PUs is associated with which LPAR, create a different listening port for each LPAR.
Figure 2-2 shows an example of three PUs within the same TN3270 Server. Two of the PUs are allocated to the same listening address. The third PU is assigned to a different listening address.
Figure 2-2 Allocation PUs
The TN3270 Server can support configurations where a group of PUs have the same IP listening address, each PU has its own separate listening address, or a combination of the two. Likewise, when defining a PU, you can define static LUs, dynamic LUs, or a combination of both.
Defining LUs
TN3270 clients need only an IP address and an optional LU name or type to connect to the TN3270 Server. The server then maps requested sessions with actual LUs available on the hosts.Each PU can have up to 255 LUs defined. With historical SNA networks, an LU was a physical device attached to a remote communications controller, such as an IBM 3274. Each port on these devices was a local address known as a LOCADDR. When a LOCADDR was defined, each LU within a PU was statically defined to match the static hardware. Today, with the virtual allocation of LOCADDRs, either static or dynamic LUs can be established.
The TN3270 Server supports static and dynamic LUs.
•
•
When a standard TN3270 client establishes a connection, there is no mechanism for requesting an LU by name. In this case, you must use dynamic LU pools or LU nailing. Because TN3270E supports requesting LUs by name, a TN3270E client can use either dynamic or static LUs.
In most environments, it is more advantageous for TN3270 clients to specify a dynamic LU rather than a static LU. For static LUs, the PU on the TN3270 Server allocates the required memory when the mainframe activates the LU. For dynamic LUs, the memory is not allocated until the LU is requested. Therefore, memory on the TN3270 Server is not allocated unnecessarily.
Activation of LUs
The LU activation process differs depending on whether the client is using a static or a dynamic LU.For static LUs, the first phase is LU activation. The LU requested must be defined at the host under the PU. The activation process is as follows:
1.
2.
3.
Network Management Vector Transports (NMVTs) are also sent to any running network management application, which allows the host to track the IP address of any device connecting to each LU.
For dynamic LUs, the first phase is session negotiation. This phase includes steps necessary to initiate the client-to-CIP/CPA connection and to select the LU:
1.
2.
3.
The second phase is session bind and data transfer. This phase includes the steps of the TN3270 host-to-client SNA session bind and data transfer:
1.
2.
3.
The third phase is session termination. Sessions are terminated in the following conditions:
•
•
•
•
•
Determining How LUs Will Be Named
There are several ways in which an LU can be named and assigned to a TN3270 client. It is important to understand how LU naming and allocation work before designing a TN3270 Server network. The same LU can be known to VTAM with one name and to the CIP/CPA with a different name. This can be by design, but also can be accidental, leading to client connection problems and network management problems.
The LU name assigned within the TN3270 Server is created using one of several methods. The method depends on the configuration of the TN3270 Server and the PU. PUs can be configured as either direct or DLUR-based.
•
•
In a multihost environment, hosts with DLUS/DLUR implemented require less configuration of the PUs and LUs on the TN3270 Server.
Other factors that impact the LU naming process are:
•
•
•
•
•
Dynamic Definition of Dependent LUs
Most of the current offerings of TN3270 server implementation use predefined pools of LUs to support different terminal types requested by the TN3270 clients. To simplify the management of such configurations, the Cisco IOS software TN3270 Server feature supports a VTAM V3R4 feature, called DDDLU, which allows you to dynamically request LUs using the terminal type provided by TN3270 clients. This feature eliminates the need to define any LU configuration in the server to support TN3270 clients emulating a generic 3270 terminal. Only the PUs need to be configured. Configuration for LUs in the server is necessary only for clients that require specific LU names to be secured (such as printers) or use IP addresses for authorization or application selection.
Dynamic LU allocation is the most common form of request from TN3270 clients emulating a TN3270 terminal. The client is typically concerned with emulating a particular terminal type, but is not normally interested in what LOCADDR or LU name is allocated by the host as long as a USS10 menu is presented or an LU-to-LU session is started (via the LOGAPPL facility).
The server performs the following tasks on such a session request:
•
•
•
When VTAM receives the NMVT, it uses the EBCDIC model type and number string to look up an LU template under the LUGROUP. An ACTLU is sent and a terminal session with the model and type requested by the client can be established.
Note:
D NET,EXITSThe output should say that ISTEXCSD is active and has exit ISTEXCSD in place.
LUGROUP Parameter
To use dynamic LUs, you must create and activate a VTAM LUGROUP major node, which contains the model types and definitions for the variety of terminal types used. Each model type provides different screen functions. The LUGROUP definition is used by the requesting LU to define terminal type settings, such as the default logmode, mode table, and USS table.
When defining an LUGROUP, it is best to define all combinations of model types that are typically found in your network as well as a default model statement. The default model statement acts as a catch-all definition for combinations not defined. You do not specify a model name in the default model statement. Instead, you begin the statement with the @ sign. The @ sign can also be used as a wildcard in other entries.
To cover all combinations of machine, model, and extension type, when creating the LUGROUP, you would include definitions to cover the following:
•
•
•
A 0 extension specifies a classic TN3270 connection. The client expects all data to be in a TN3270 data stream. An S extension indicates that the client expects the SSCP-to-LU data to be in SCS control code format. All entries with an S extension to the machine type should have SSCPFM=USSSCS coded. All others should have SSCPFM=USS3270 coded.
•
An E mode type indicates that the client supports the host sending a read-partition query to the client to determine the client's capabilities.
The combinations of the machine, model, and extension types result in 32 model entries plus the default entry.
However, you can specify an SSCPFM of USSSCS for all clients regardless of type. This reduces the entries to 16. Then if you use the wildcard to represent both the 3278 and 3279 machine types, the number of entries is reduced to eight (plus the default).
The switched major node definition must specify the LUGROUP name of the LUGROUP parameter defined in the major node. The LU names of these dynamic LUs are generated by the LUSEED parameter. Alternatively, you can code the VTAM-exit ISTEXCSD and use an in-house algorithm for assigning LU names.
For an example of an LUGROUP and a explanation of the contents, see the " PU and LU Definitions" section in the Migration Scenarios chapter.
LUSEED Parameter
LUSEED is a parameter used to reduce the configuration required for the definitions of LUs. The LUSEED parameter is required for dynamic LUs and can be used for static LUs.
The LUSEED parameter can be specified on both the channel-attached router and in VTAM. When configuring PUs in the channel-attached router, the parameter is LU-SEED. In VTAM, the parameter is LUSEED. The LU-SEED parameter is not valid on the channel-attached router if DLUR is used.
The LUSEED is a prefix that is used in the creation of LU names. The resulting LU name depends on the method used to specify the LU-SEED:
•
•
The TN3270 Server LU-SEED parameter defaults to the first six characters of the PU name concatenated with the two hexadecimal character LOCADDR number. For example, if the PU is named PUXCPA01 and no LU-SEED is coded on the CIP or CPA, then the LU with LOCADDR 10 decimal will be named PUXCPA0A.
Be sure to define each dynamic PU with a unique LU-SEED parameter in the VTAM switched definition. Otherwise, VTAM will attempt to define two LUs with the same name and the second request will fail. The TN3270 client will show connected, but the CIP/CPA will be waiting for the ACTLU to flow and the session will never flow.
We recommend that you make the LU-SEED on CIP/CPA and the LUSEED on VTAM identical for the same PU to ensure that dynamic LUs have the same name on both the channel-attached router and VTAM.
Note that even if the LU-SEED is coded the same on both VTAM and the CIP/CPA, static LU names may not match because they are hardcoded in VTAM. Unless VTAM passes the LU name to the CIP/CPA or the VTAM static LU names match the CIP LU-SEED naming convention the LU names in each will be different. The best solution to this problem is to use DLUR PUs or direct PUs with INCLUD0E so that VTAM passes all LU names (static and dynamic LUs) to the CIP/CPA. As an alternative, you can code LU-SEED in the CIP to match VTAM's static LU names, if possible.
INCLUD0E
INCLUD0E is a VTAM parameter that can be used with direct PUs to instruct the XCA to allow the LU name to be included in the ACTLU. If the TN3270 Server receives the LU name as part of the ACTLU, it uses this LU name and does not relearn the name from the Bind.The INCLUD0E is available and supported in VTAM Version 4.4. If you use INCLUD0E, you must also apply the PTFs for the following authorized program analysis reports (APARs):
•
•
•
LU Nailing
DDDLU and LU pooling are increasing in popularity and can be used for most LU needs. The exception, however, is if a client must use a specific LU name because of application requirements. For example, Information Management System (IMS) applications use a security mechanism to control access that is based on the LU name. These clients are often groups such as personnel departments or office branches. For these clients the requirement is to lock their LU to an IP address. There are two methods of locking an LU to an IP address. The first method is for the client to use the TN3270E function, which allows the client to specify the LU name. The second method is to use the client LU nailing feature of the Cisco IOS software TN3270 Server feature.LU address mapping allows a client IP address to be mapped, or "nailed," to one or more LU local addresses on one or more PUs. You can then control the relationship between the TN3270 client and the LU. 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 also useful for TN3270E clients because it allows you to perform the configuration of the client at the router, providing central control, rather than at the client.
The "model matching" feature of the TN3270 Server is designed for efficient use of dynamic LUs. Each 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. For dynamic LUs, however, there is a short delay in connecting the session.
Where a client or set of clients is nailed to 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, 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.
The client LU nailing feature associates particular LU names to particular client IP addresses or IP subnets. The LU nailing is used to:
•
•
•
•
•
The CLIENT command nails client IP addresses to specific LUs. The parameter is configured using the "client ip" or "client printer" statement under a TN3270 Server PU. Each client statement is configured on a per PU basic. A client statement can specify one IP address or a group of IP addresses within a subnet. A specific IP address can be included in more than one client statement.
DHCP with Client Nailing
Some clients may require the use of client LU nailing but belong to a Dynamic Host Configuration Protocol (DHCP) group. Therefore, their specific IP address is not going to vary. The client LU nailing feature works with DHCP by using the subnet parameter. This means that a DHCP group that is part of a particular subnet can be specified to access a single LU or a group of LUs based upon the subnet address.
TN3270E and Statically Defined LUs with Client Nailing
Consider the situation where a TN3270E client requests an LU that is statically defined in the PU. If neither the LU nor the client are subjects of nailing statements, the client will get the LU that it requested. If the client is nailed and the requested LU is available and in the set to which the client is nailed, the client will get the LU that is requested. Otherwise the request is refused.
LU Assignment and Naming Summary
Table 2-1 discusses the factors that impact how an LU name is assigned and explains the result.Table 2-1 LU Naming Summary
Note:
LU Selection Algorithm
When a user requests an LU from the LU pool, an allocation algorithm that reuses resources is used. The algorithm gives preference to LUs that are already active, provided the last use was with the same model as the new client. In the following two situations the algorithm will choose an LU that has not been used before:•
•
Figure 2-3 illustrates the decision process used by the LU selection algorithm.
Figure 2-3 LU Selection Algorithm
Preference order:1) Active, correct model, 2) Inactive, no model, 3) Active, wrong model, 4) Active, correct model, but had a prior problem?Addressing LAN Printing Requirements
In the past, large amounts of mainframe print output would be printed in the data center and the distributed to the various branch offices overnight. Today, users expect the ability to print the host output on a LAN printer and also to specify which LAN printer is used. For various groups, such as a sales group, this may mean that the same type of output will be printed to different offices, depending on where they are traveling that week. This situation raises two immediate concerns, first is security of document and second is control of printing.
Printing security of document printing can be resolved by specifying the client LU nailing parameter. This restricts access to an LU to only a particular IP address or group of IP addresses. This control is important for groups such as a personnel department.
Printing control is more difficult to address.
Figure 2-4 illustrates the control of a printing environment. The printing output is the starting point and the control of this output can be controlled with one or many of the three choices.
Figure 2-4 Control of a Printing Environment
Central control indicates that the print definition setup and print allocation is controlled from the mainframe. This choice is the least flexible of all the options and requires the most maintenance to control. Central control printer administration means that the printer LU and printer output definitions are statically defined in the mainframe printer application.
Workgroup-based printing is the recommended option for departments that share a common printer. The workgroup option works with the central control option. A group of printers is defined for a particular output group or groups and all printer output is sent there. Workgroup-based printing does not require central control. This option requires less control at the mainframe application and makes host modifications easier. This option works well when old PCs (386/486 PCs) are decommissioned and are reused as a permanent print servers.
Decentralized mainframe printing is ideal for the traveling client. This option allows clients to specify the LU name (using the TN3270E function) for their output and to receive their print output regardless of where they are logged in. This provides greater flexibility, but it comes with a price. For every client that uses this option, there must be a separate printer LU.
Which method you choose to manage your LAN printing depends upon your client requirements. The most commonly implemented solution is to use workgroup-based printing for permanently located groups and decentralized mainframe printing for the roaming client.
The client nailing feature of Cisco's TN3270 Server simplifies mainframe printing. If you have statically defined printer sessions, it is necessary to have printer LUs predefined in the switched major node. The client must request the name of one of these printer LUs. If the client requests the name of a printer that is already in use, then the session request is rejected. With LU nailing, you can use the client printer ip command to define printers for a client. LU nailing provides a better method of defining printers for a client because the assignment is centrally managed and the client cannot request an incorrect LU.
Addressing SNA Routing in Multi-Domain Environments
Another requirement is the ability to route traffic through the TN3270 server to data application without routing the traffic through the VTAM, which could be on a different host. To allow this, APPN is installed on the hosts and on the TN3270 Server router.
Note:
To enable the TN3270 session to pass between the router and VTAM an LU 6.2 session pipe is established between the DLUR, which is the Cisco router, and the DLUS, which is VTAM. Once a pair of LU 6.2 sessions has been brought up between the DLUR and DLUS, dependent PU/LU flows (SSCP-to-PU and SSCP-to-LU sessions) are encapsulated over the LU 6.2 sessions between the DLUR and DLUS SSCP. These LU 6.2 sessions are known as the control point (CP)-to-server pipe. In this way, SSCP services are provided from VTAM without requiring the distribution of SSCP code or definition.
When the SNA network uses APPN and the TN3270 Server can reach multiple hosts, we recommend that you use DLUR and configure your PUs under DLUR. You can also use DLUR to reach a mix of APPN and non-APPN hosts. The host that owns the PUs must be an APPN network node. When a secondary LU 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 is routed through the owning host.
The implementation of DLUR/DLUS requires no changes to existing applications or dependent terminals. DLUR requires VTAM Version 4.2 or later with APPN activated and VTAM configured as a network node(NN). VTAM can be configured either a pure NN or an interchange node (ICN). To implement session switching requires additional knowledge of the VTAM configuration and the implementation of the APPN network.
How DLUR and DLUS Works
All dependent LUs, and the PUs that support them, require sessions to their owning SSCP. These sessions carry various control messages and management requests. These messages always take the form of SSCP-to-PU and SSCP-to-LU sessions that cannot cross domain boundaries or network boundaries. A PU serving dependent LUs must be connected directly to its owning VTAM or to a CIP or CPA connected to that VTAM.
In addition, routing in a subarea network is always done at the subarea level. In other words, any session involving a dependent LU must pass through the same adjacent subarea node as the SSCP-to-LU session, even if the dependent LU happens to reside in an APPN node.
To address these restrictions, the DLUS and DLUR were created.
The DLUS is a product feature (APPN option set 1066) of a T5 (VTAM) network node supporting session services extensions. The DLUS function enables VTAM to provide SSCP services for dependent LUs in remote APPN ENs or NNs. The DLUS provides SSCP services through standard SSCP-to-PU and SSCP-to-LU session flows that are encapsulated and sent over LU 6.2 sessions.
The DLUR is a function (APPN option set 1067) of an APPN EN or NN that owns dependent LUs but obtains services from a DLUS. The DLUR function is configured on the CIP or CPA under the TN3270 Server. The PUs are defined under the DLUR statement. The hierarchical structure is: TN3270 Server, DLUR, and PU. The DLUR function provides a remote boundary function for dependent LUs; that is, it removes the requirement that a node supporting dependent LUs must be adjacent to a subarea boundary node.
DLUR/DLUS removes these restrictions by providing the following functions:
•
This CP-to-server pipe consists of a pair of sessions between the CPs in the DLUR and DLUS nodes. These sessions are called CPSVRMGR sessions. The pipe can carry a number of SSCP-to-PU and SSCP-to-LU sessions and does not need to be between adjacent CPs. The pipe can cross network boundaries.
•
When a primary LU requests a search for a dependent LU, it normally receives a positive response from the DLUS, not the DLUR. The response identifies the DLUS as the server for the dependent LU and includes the correct CP name (the DLUR). The route can then be calculated directly to the DLUR, typically by the NN server of the primary LU (which is never the dependent LU). In cases where the DLUR supports cross-network CPSVRMGR sessions, the DLUR may respond to a search, but it still indicates that it is the owning CP.
Because the DLUS presents itself as the NN server for the dependent LUs, it must always be an NN.
Using the DLUR/DLUS, or CP-to-server pipe, SSCP-to-PU and SSCP-to-LU control messages can be exchanged between VTAM, the PU, and the local dependent LUs. SSCP-to-PU and SSCP-to-LU control messages are required for PU and LU activation and to initiate LU-to-LU session establishment. LU-LU sessions can, for example, be initiated by a LOGON request from a terminal operator. The LOGON request is forwarded to VTAM, which locates the destination LU using existing subarea (SSCP-to-SSCP) or APPN (CP-to-CP) data flows. Following the activation flows, the primary LU sends a BIND to establish the session. The BIND, and successive LU-to-LU session data, will be using the best route between the two session partners for the desired Class of Service (COS).
When you plan to use DLUR/DLUS, remember the following guidelines:
•
•
•
How Session Switching Works
The LUs implemented by the TN3270 Server are dependent LUs. To route these dependent LU sessions to multiple VTAM hosts connected to the server in the channel-attached router (rather than routing in the VTAM hosts), the TN3270 Server implements an SNA session switch with the EN DLUR function.
Figure 2-5 illustrates how session switching works.
Figure 2-5 How Session Switching Works
To illustrate how session switching works, consider the situation in which a client's owning VTAM is on Host A and the client wants to reach an application on Host B:
•
•
To implement session switching, a CP-to-CP session between the two VTAMs is required. This can be achieved three ways:
•
•
•
Addressing End User Service Level Requirements
As traffic on the Internet increases, there is increased congestion. One way to address this problem is to discriminate between different types of traffic and provide the appropriate quality of service (QoS). For example, interactive traffic should have a higher priority than bulk data transfer. IP precedence and type of service (ToS) is part of the IP specification that provides this prioritization.
The TN3270 Server allows you to specify IP precedence and ToS. At the protocol level, IP precedence allows a router network to discriminate between different types of traffic by assigning different priorities to them. IP ToS allows router networks to discriminate between different types of traffic by assigning different routing characteristics to them. Precedence and ToS values complement one another and provide flexibility in managing your network traffic.
In TN3270 Server, two types of TN3270 clients can be connected: screens or printers. Screens are interactive and printers need bulk data transfer. IP ToS and IP precedence allow you to discriminate between these types of sessions and assign different precedence values to the interactive connection and the bulk data connection.
IP ToS and IP precedence values can be specified for either the TN3270 Server as a whole or individual PUs. Values can be specified on both levels, in which case siftdown determines the value on an individual PU. Siftdown allows you to configure values that apply to all entities of the server in TN3270 Server configuration and to configure values for individual PUs at the PU configuration mode.
The Cisco implementation of IP precedence allows values of 0 to 7. The Cisco implementation of ToS allows values from 0 to 15. It is up to the administrator to choose values consistent with organizational policies when configuring IP precedence and ToS. Also, whether these values work depends on what the organization or Internet Service Provider's (ISP's) router does with packets with different IP ToS/precedence values. If you are using a Cisco router network, configuring weighted fair queuing (WFQ) or priority queuing allow you to prioritize traffic using IP precedence. The Open Shortest Path First (OSPF) protocol can discriminate between different routes based on IP ToS value; functions such as WFQ and NetFlow switching are also affected by ToS values.
Addressing Availability Requirements (Redundancy/Load Balancing)
Moving the 3270 access from the host to an outboard server provides many benefits, but also raises the issues of server redundancy. Having a "single point of failure" is an issue for sites that cannot allow for disruptive session failure. With legacy SNA, when a path is broken, the session is lost and the user must reconnect. With the outboard gateways, the data travels from the client to the server via TCP and then from the server to VTAM via SNA. As a result, any loss between the server and VTAM will result in a disrupted session.
Cisco offers several options for providing redundancy, including LocalDirector, DistributedDirector, and Hot Standby Router Protocol (HSRP).
Note:
LocalDirector
LocalDirector dynamically load-balances traffic between multiple servers to ensure timely access and response to requests. It is independent of domain name servers and applications; rather, it functions as a front end to a group of servers by load balancing traffic demands between servers and speeding user access to server-based applications. Servers can be added and removed transparently, but to end users LocalDirector provides the appearance of a single, virtual server.
LocalDirector is a high-performance networking device with over 45 Mbps throughput. It supports up to 8,000 virtual IP addresses and domain names. It can also direct traffic to 8,000 servers that can be a collection of heterogeneous hardware platforms and operating systems, and it efficiently handles over 700,000 simultaneous TCP connections.
In addition to its directing capabilities, LocalDirector also serves as a simple bridge to forward data packets between its interfaces. This bridging ensures that LocalDirector does not interfere with network operation while it is in service and it can be brought online immediately after powering up without affecting network connectivity.
The LocalDirector does not use Domain Name System (DNS) for domain name lookup. Networks without a DNS or that do not require their TN3270 sessions to reference the DNS for mainframe connectivity are suited to use the LocalDirector.
Most data centers implement a redundant CIP or CPA and TN3270 Server solution to create multiple IP addresses for the end user to reference for host connectivity. LocalDirector is installed with the TN3270 Server to provide consolidation of the IP addresses and load balancing.
The IP addressing consolidation is achieved by creating a virtual IP address on the LocalDirector. The real IP addresses, as defined in the TN3270 Server, are included in the LocalDirector. The real IP addresses are bound to the virtual address creating a pool of host connection addresses. A typical configuration binds all the real IP addresses to a single virtual IP address, which creates a simple environment to administer. There is a range of configuration possibilities available, such as creating multiple virtual addresses and allocating a particular address to a particular group or region. The best type of virtual address allocation will depend on the needs of the company.
DistributedDirector
DistributedDirector can be run on either a Cisco 2500 or 4700-M router. With DistributedDirector, users need only a single DNS host name or URL-embedded host name for accessing a globally distributed set of servers, thus providing the appearance of a single virtual server. This eliminates the need for users to choose a server from a list of possible sites.
DistributedDirector enables transparent distribution of all common TCP/IP network services, such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Telnet, TN3270, and gopher.
Using the Director Response Protocol (DRP), a simple User Datagram Protocol (UDP)-based application developed by Cisco, the Director can query properly configured Cisco routers in the field for Exterior Gateway Protocol (EGP) and Internal Gateway Protocol (IGP) topological "distance" metrics. With this information and other configuration metrics, the Director can assign an optimal distributed server to each client. As a result, users can be transparently and automatically assigned a distributed server anywhere on the Internet.
DistributedDirector monitors the status of the TN3270 Server by opening a Telnet port. If DistributedDirector cannot open the port it marks the server as unavailable.
DistributedDirector works in conjunction with a DNS server. More than one DistributedDirector can exist in the network. For redundancy, we suggest that you install one DistributedDirector or every major DNS server.
DNS
The use of either LocalDirector or DistributedDirector is not the only option to provide redundancy. DNS is also a valid option. To provide redundancy using DNS, you must install more than one TN3270 Server. For each TN3270 Server, assign all the PUs to the same IP listening address. Configure the DNS server to include a DNS entry for all the defined IP listening addresses. The result is that the client requests a server and the request is processed using a round-robin method. The disadvantage of this method is that a client still may be sent to an inactive TN3270 Server because the DNS server does not have the capability to monitor the status of the TN3270 Servers. Also, because some clients ignore IP addresses returned by a DNS server after the initial response, this solution may not work for all clients.
Satisfying Expanding Network Address Requirements
For VTAM to control routing in a network, it must know the location of its resources (LUs, PUs, and other SSCPs). VTAM uses element addresses in conjunction with the subarea address to identify the location of resources (also known as network addressable units[NAUs]). The subarea address indicates where the resource is located; the element address indicates the unique address within the subarea.
Minor nodes, such as an application program or LU, require a single element address. Some minor nodes, such as local non-SNA devices and application programs that use parallel sessions, require more than one element address. This requirement increases the number of element addresses that are used in a subarea.
These element addresses are available up to various ranges dependent on the level of VTAM. The TN3270 Server supports the following methods of addressing:
•
•
•
Use the MAXSUBA start option or the MAXSUBA operand in NCP to enable communication between subareas with different addressing structures. The MAXSUBA start option specifies the highest subarea value used in the network. A MAXSUBA of 63, for example, defines a network with up to 63 subareas and 1024 elements in each subarea. You must code the MAXSUBA start option in VTAM's start option list if you want VTAM to communicate with nonextended addressing nodes or if the MAXSUBA operand is coded in an NCP with which VTAM communicates.
Note:
TN3270 Configuration
For TN3270 configuration, the mainframe remains the same as with a PU 2.1 definition. A switched major node member in SYS1.VTAMLST is defined and, within that member, the PU is defined. The LU definitions within each PU can be defined statically or dynamically. A static LU definition means that each LU with a LOCADDR parameter is hard-coded within the switched major node member. A dynamic LU is defined using DDDLUs.
TN3270 Server Configuration Modes
There are several TN3270 configuration modes and router command prompts that you use when configuring the TN3270 Server. These configuration modes and command prompts are described in this section. The TN3270 Server can be configured only on port 2, the internal LAN port, of a CIP card or port 0 of the CPA.TN3270 configuration modes described in this section include the following:
•
The following sections describe how to move within configuration modes and identify the configuration commands:
•
•
TN3270 Server Configuration Mode
From interface configuration mode, the tn3270-server command puts you in TN3270 Server configuration mode.The following prompt appears:
tn3270-server>DLUR Configuration Mode
From TN3270 Server configuration mode, the dlur command puts you in DLUR configuration mode.The following prompt appears:
tn3270-dlur>DLUR SAP Configuration Mode
From DLUR server configuration mode, the lsap command puts you in DLUR SAP configuration mode.The following prompt appears:
tn3270-dlur-lsap>PU Configuration Mode
You access the PU configuration mode from the TN3270 Server configuration mode or from the DLUR configuration mode. In either mode, the pu command puts you in PU configuration mode.For direct PUs, from TN3270 configuration mode issue the pu command to create a new PU:
pu pu-name idblk-idnum ip-address type adapno lsap [rmac rmac] [rsap rsap] [lu-seed lu-name-stem]
The following prompt appears:
tn3270-pu>For DLUR PUs, from DLUR configuration mode issue the pu command to create a new PU:
pu pu-name idblk-idnum ip-address
The following prompt appears:
tn3270-dlur-pu>From either mode, to return to PU configuration mode on PU pu-name the command is:
pu pu-name
Moving Between Configuration Modes
Some configuration commands create entities on the CIP or CPA. For most of these, the command changes to the mode associated with that entity (for example, a PU). In general, the parameters provided to create the entity come in two sets: those that identify the specific instance of the entity (for example, a PU name) and those that merely set operating parameters. To return to the mode, the same command is used but with only the first set of parameters. Tables 2-2, 2-3, and 2-4 show example tasks to return to a command mode without creating a new entity.
To create a DLUR LSAP and enter DLUR LSAP configuration mode, perform the following task beginning in TN3270 DLUR configuration mode:
Table 2-2 DLUR LSAP Configuration Mode
Create a DLUR LSAP and enter DLUR LSAP configuration mode.
lsap token-adapter 1 84
To return later to the DLUR LSAP configuration mode on the same entity, perform the following task beginning in TN3270 DLUR configuration mode:
Table 2-3 Returning to DLUR LSAP Configuration Mode
Enter DLUR LSAP configuration mode on the same LSAP.
lsap token-adapter 1
To remove an entity, the same identification parameters are needed. Perform the following task beginning in TN3270 DLUR configuration mode:
Table 2-4 Removing a DLUR LSAP Entity
Remove a previously defined DLUR LSAP entity.
no lsap token-adapter 1
Commands Allowed in Multiple Modes
The following commands are valid in TN3270 configuration mode or in either variation of PU configuration mode:•
•
•
•
•
•
•
•
Values entered in PU configuration mode override settings made in TN3270 configuration mode. In addition, the no form of these commands entered in PU configuration mode will restore the command value entered in TN3270 command mode.
Configuring the TN3270 Server
This section describes how to configure TN3270 Server support on the CIP and CPA for the following:•
Not all tasks are required.
Note:
Configuring Multiple APPN Hosts
When the host site uses APPN and the TN3270 Server can reach multiple mainframe hosts, we recommend that you use DLUR and configure your PUs under DLUR by performing the following tasks:•
•
•
Note:
Configuring Non-APPN Hosts
When the host site does not use APPN, you configure your PU parameters for a directly connected mainframe host by performing the following tasks:•
•
•
•
Configuring SNA Support
CSNA must be configured prior to configuring TN3270 support. Refer to the "Configure IBM Channel Attach for CSNA Support" section of the "Configuring IBM Channel Attach" chapter of the IOS Bridging and IBM Networking Configuration Guide.Initiating the TN3270 Server
To establish a TN3270 Server on the internal LAN interface on the CIP, perform the following tasks (Table 2-5) beginning in global configuration mode:
When you use the tn3270-server command, you enter TN3270 configuration mode and are able to use all other commands in the task list. You can override many configuration values you enter in TN3270 configuration mode from PU configuration mode. On IBM host systems, these types of commands are often referred to as "siftdown" commands because their values sift down through several levels of configuration and can be optionally altered at each configuration level.
Maximum-LUs Command
The maximum-lus command sets a limit on the number of LU control blocks that are allocated for the TN3270 Server. It can be used to prevent the TN3270 Server from inhibiting other applications on the CIP or CPA.The TN3270 Server attempts to allocate one LU control block for each LU activated by the hosts. For DDDLU, the control block is allocated when the client requests the LU (in anticipation of an ACTLU from the mainframe host).
Valid values are from 0 to 32000. The default is 2100. However, memory and other limitations may prevent the maximum value from being achieved. Although this value may be changed at any time, reducing it below the number currently allocated will not force control blocks to be released. In fact, no LU control blocks will be released to the system until the PU is inactivated.
Idle Time Disconnect Command
The idle time disconnect command specifies the number of seconds of LU inactivity, from both host and client, before the TN3270 session is disconnected. Specifying zero seconds means that LU sessions are not disconnected when inactive.
Keepalive Command
Use the keepalive command (when issued under the TN3270 command context) to monitor active LUs. For example, keepalive 600 sends a Telnet TIMING-MARK every 10 minutes if there is no other traffic flowing between the server and the client. If, after a timeout period of between one and three minutes, the end client does not respond, then the CIP or CPA disconnects the session. This action is useful for cleaning up partially disconnected TCP sessions.
If you are using static LUs, then use one of the following code releases: CIP22-27, CIP24-5 or CIP25-6 and higher. These releases handle partially disconnected sessions without use of the keepalive command.
UNBIND-Action Command
A session unbind (specified using the unbind-action command) indicates whether or not a TN3270 session is disconnected upon UNBIND. A value of disconnect indicates that the TN3270 Server disconnects the TN3270 client upon receipt of an UNBIND. A value of keep indicates that no automatic disconnect is made by the TN3270 Server upon receipt of an UNBIND.
Generic-pool Command
Use the generic-pool TN3270 configuration command to specify whether or not leftover LUs are made available to TN3270 sessions that do not request a specific LU or LU pool through TN3270E. A leftover LU is an LU from the pool of dynamic LUs that you have specify in the switched major node using the LU-SEED parameter and the LUGROUP parameter.
The generic-pool command can be used as a global TN3270-server command, but is also used in PU-configuration mode to change the value (permit or deny) for specific PUs:
•
•
Older TN3270 clients cannot request an LU session using a specific LU name. In earlier versions of the Cisco IOS software, the generic-pool deny command prevented non-TN3270E clients from obtaining a session. But with the current release of the Cisco IOS software you can nail LUs to IP addresses in the router configuration. This feature allows non-TN3270E clients to establish a session even if the generic-pool deny command has been specified.
Configuring IP Precedence and ToS Support (Optional)
There are two commands that support IP precedence and IP ToS.
To configure IP precedence, perform the following task (Table 2-6) in TN3270 Server or TN3270 PU configuration mode:
Table 2-6 IP Precedence Configuration Tasks
Configure the IP level.
ip precedence {screen | printer} value
Use the no ip precedence screen or the no ip precedence printer command to return the precedence value to a default of 0.
To configure IP ToS, perform the following task (Table 2-7) in TN3270 Server or TN3270 PU configuration mode:
Table 2-7 IP ToS Configuration Tasks
Configure the IP ToS delay level.
ip tos {screen | printer} value
Use the no ip tos screen or the no ip tos printer command to return the precedence value to a default of 0.
These commands can be specified in the TN3270 Server configuration mode the DLUR/Direct PU configuration mode. The commands affect all the LUs under the PU based on the siftdown value.
The default value for the IP precedence screen and printer parameters is 0. If IP precedence is not configured, the IP precedence field is set to 0 for both screen and printer. The default value for the IP ToS screen is 0.
When Telnet negotiation is taking place, IP precedence and IP ToS values of 0 are used. These values are used until the Bind takes place. If it is a type 2 Bind, the TN3270 client is assumed to be screen. Otherwise, it is assumed to be printer. These definitions of screen and printer might not be consistent with implementations in other configurations or products. The IP precedence and IP ToS values are used until the TN3270 session is terminated.
The show command displays four distinct values for IP precedence and the IP ToS. The values correspond to the screen and printer. The following example shows the IP precedence and IP ToS as displayed in the show extended command.
redback#show extended channel 3/2 tn3270-server<current stats> <connection stats> <response time(ms)>server-ip:tcp lu in-use connect disconn fail host tcp172.28.1.99:23 0 0 1 1 0 0 20total 0 0configured max_lu 2100idle-time 3600 keepalive 1800 unbind-action disconnectip-preced-screen 0 ip-preced-printer 0 ip-tos-screen 0 ip-tos-printer 0tcp-port 23 generic-pool permit no timing-markdlur MPX.REDBCP status RESETdlus MPX.NGMVMPCname(index) ip:tcp xid state link destination r-lsapPUS1(1) 172.28.1.99:23 05D19001 XID tok 0 4000.7470.00e7 08 A8Configuring PU Parameters on the TN3270 Server
Configuring PU parameters is required when you configure PUs that do not use DLUR. To configure PU parameters for the TN3270 Server, perform the following tasks (Table 2-8) beginning in TN3270 configuration mode:
When you use the pu command, you enter PU configuration mode and can use all other commands in this task list. Configuration values you enter in PU configuration mode override other values entered while in TN3270 configuration mode. In addition, you can enter PU configuration mode from the DLUR configuration mode when configuring PUs that are connected by means of DLUR.
If you are configuring PUs for directly connected hosts, you need not perform any additional configuration tasks.
Configuring DLUR Parameters
Configuring DLUR parameters is required when if you configure DLUR connected hosts. To configure DLUR parameters for the TN3270 Server, perform the following tasks (Table 2-9) beginning in TN3270 configuration mode:
Configuring SAPs under DLUR
To configure SAPs under the DLUR function, perform the following tasks (Table 2-10) beginning in DLUR configuration mode:
Configuring PUs under DLUR
This task is required when configuring DLUR connected hosts. To configure PUs under the DLUR function, perform the following tasks (Table 2-11) beginning in DLUR configuration mode:
Note:
Configuring LU Nailing (Optional)
To configure LU nailing, perform the following task (Task 2-12) in TN3270 PU configuration mode:
Table 2-12 LU Nailing Configuration Tasks
Configure the IP address and nail type and specify the LOCADDR range.
client [printer] ip ip-address [mask] lu first-locaddr [last-locaddr]
The client command allows a client with multiple TN3270 connections from the same IP address to nail their screen connections to LUs that are configured as screen LUs at the host and to nail printer connections to LUs that are configured as printers at the host. When the connection is made, a device type of "328*" is matched to a printer definition, and any other device type is matched to a screen definition.
Creating a Pool of Static LUs Using LU Nailing
Unlike dynamic pools, the definition of static LUs does not allow LU pooling. Static LUs require the client to address the LU by name. To work around this problem, static LUs can be defined with a client IP statement that allows any user to access any LU. This parameter turns the static LUs into a pool of LUs.In the following example, all clients in subnet 10.1.1.0 are assigned an LU in the range between LOCADDR 1 and 255:
PU PU1 0CB00001 10.8.8.8 token-adapter 0 48CLIENT IP 10.1.1.0 255.255.255.0 LU 1 255LU nailing also limits access to the TN3270 Server to a specific network. For example, if all the PUs specified use the "CLIENT IP 148.149.0.0 255.255.0.0 LU 1 255" command, then only clients on this specific network (148.149.0.0) have access to those PUs defined on the TN3270 Server.
Monitoring the TN3270 Server
Table 2-13 lists some of the monitoring tasks specific to the TN3270 Server. To display the full list of show commands, enter show ? at the EXEC prompt.Use the following show command in privileged EXEC mode:
Other methods of monitoring the TN3270 Server are discussed in Chapter Chapter 5, Network Management.
