Cisco 11.0 BT How to use

1
Doc. No.
Cisco Systems, Inc.
All rights reserved.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Cisco Systems, Inc.
Corporate Headquarters
Copyright © 1998
Cisco IOS Release 11.0 BT Release Note and
Update to Configuration Guides and Command
References
January 15, 1999
This document supplements the Cisco IOS Release 11.0 documentation set with new and changed
commands that support Cisco IOS Release 11.0(10)BT and later. Note that Cisco IOS Release
11.0(10)BT is the initial release of Cisco IOS Release 11.0 BT. No prior versions of Cisco IOS
Release 11.0 BT exist. The TN3270 server function is supported on a Channel Interface Processor
card in a Cisco 7000 series or Cisco 7500 series router. The following Cisco IOS releases are
covered by this release note publication:
•Cisco IOS 11.0(10)BT
•Cisco IOS 11.0(11)BT
•Cisco IOS 11.0(12)BT
•Cisco IOS 11.0(13a)BT
Note Cisco IOS Release 11.0(13)BT was renumbered and released as 11.0(13a)BT.)
•Cisco IOS 11.0(14)BT, Cisco IOS 11.0(14a)BT1
Note Shipment of Cisco IOS Release 11.0(14)BT was halted due to CSCdj05366. A fix was
implemented and the release was renumbered and released as 11.0(14a)BT1.
78-3610-09

2Cisco IOS Release 11.0 BT Release Note and Update to Configuration Guides and Command References
Introduction
•Cisco IOS 11.0(15)BT
•Cisco IOS 11.0(16)BT
•Cisco IOS 11.0(17)BT
•Cisco IOS 11.0(18)BT
•Cisco IOS 11.0(19)BT
•Cisco IOS 11.0(20)BT
•Cisco IOS 11.0(21)BT
•Cisco IOS 11.0(22)BT
Cisco IOS Release 11.0 BT is based on Cisco IOS Release 11.0.
Introduction This Release Note and Update is divided into the following sections:
•Release Note, page 2
—Platform Support, page 3
—Cisco IOS Packaging, page 3
—Boot ROM Requirements, page 3
—CIP Boot Image Requirements, page 3
—Memory Requirements, page 3
—Microcode Software, page 4
—New Software Features in 11.0(10)BT, page 4
•Update to Configuration Guide, page 4
•Update to Command Reference, page 19
•Cisco Connection Online, page 57
•Cisco Connection Documentation, page 57
Use this document in conjunction with the Router Products Release Notes for Cisco IOS
Release 11.0 and the Cisco IOS Release 11.0 configuration guide and command reference
publications,specificallytheRouterProducts ConfigurationGuideChapters1to6,RouterProducts
Configuration Guide Chapters 22 to 33,Router Products Command Reference Chapters 1 to 6,
Router Products Command Reference Chapters 22 to 33.
Release Note Cisco IOSRelease 11.0BTintroducesTN3270serversupportonChannelInterfaceProcessor(CIP)
cards.
Note To enable the TN3270 server feature, you must have a CIP card installed in a Cisco 7000
series router or Cisco 7500 series router. The TN3270 server is different from the TN3270 terminal
emulation access feature described in the “Configuring TN3270” chapter of the Access and
Communication Servers Configuration Guide.

Cisco IOS Release 11.0 BT Release Note and Update to Configuration Guides and Command References 3
Release Note
Platform SupportCisco IOS Release 11.0 BT supports the following router platforms:
•Cisco 7500 series
•Cisco 7000 series and Cisco 7000 series with RSP7000
Cisco IOS Packaging
The following feature sets are available in Release 11.0 BT. Refer to the Router Products Release
Notesfor Cisco IOS Release 11.0 for a list ofthefeatures provided intheCisco 7000 and Cisco 7500
series feature sets.
•Enterprise (this feature set includes CIP)
•Enterprise/CIP2
Boot ROM Requirements
Boot ROMs that support Cisco IOS Release 11.0 are required. No special requirements exist for
Cisco IOS Release 11.0 BT.
CIP Boot Image Requirements
The CIP boot image is bundled in the Cisco IOS Release 11.0 BT image. You must have the image
that supports your CIP or your CIP2 hardware. You cannot run a CIP and a CIP2 card in the same
router. See Table 1 for a list of image names and supported CIP or CIP2 cards.
Table 1 11.0 BT Image Names for CIP and CIP2 Hardware
Memory Requirements
The memory requirements for Cisco IOS 11.0 BT are shown in Table 2. The CIP supports up to
128 Mb of memory.
Table 2 11.0 BT Memory Requirements
Image Names Supported CIP Hardware
rsp-k-mz CIP
rsp-k2-mz CIP2
gs7-k-mz CIP
gs7-k2-mz CIP2
Cisco 7500 Series
and Cisco 7000
with RSP7000 MinimumRequired Code Memory Required Main Memory Required CIP Memory Release11.0 Runs From
Enterprise Set
(rsp-k-mz) 8 MB Flash memory card 24 Mb 32 Mb RAM
Enterprise/CIP2 Set
(rsp-k2-mz) 8 MB Flash memory card 24 Mb 32 Mb RAM

4Cisco IOS Release 11.0 BT Release Note and Update to Configuration Guides and Command References
Update to Configuration Guide
Microcode Software
Note that microcode software images are bundled with the system software image. Bundling
eliminates the need to store separate microcode images. When the router starts up, the system
software unpacks the microcode software bundle and loads the proper software on all the interface
processor boards.
New Software Features in 11.0(10)BT
The TN3270 server is a new feature on the CIP of the Cisco 7000 family of routers. The TN3270
server allows TN3270 clients access to IBM and IBM-compatible mainframes. It can reduce the
cycles spent by the mainframe on TCP/IP and TN3270 processing by a factor of ten or more and
off-load the TCP/IP and TN3270 cycles from the mainframe.
The TN3270 server supports up to 8000 (CIP1) or up to 16000 (CIP2) concurrent sessions, while
most external gateway solutions can support only 1000 to 2000 sessions. The TN3270 server offers
the following capabilities:
•Load Balancing and Redundancy—Provides effective CIP resource utilization and more
consistent response times. (This feature is initially provided by means of an external, prototype
implementation.)
•End-to-End Session Visibility—Provides enhanced resource management.
•Systems Network Architecture (SNA) Session Switching—Off-loads VTAM by providing
session routing.
•TN3270E Support—In combination with a TN3270E client, provides advanced SNA
management and SNA functionality, including printer support.
•Dynamic Definition of Dependent Logical Units (LU)—Provides simplified configuration and
network definition at the router and in VTAM.
•Dynamic Allocation of LUs—Makes efficient use of LU pool resources while supporting
multiple SNA model types.
TN3270 server requires 32 MB of CIP dynamic RAM to support up to 4000 sessions, 64 MB to
support 8000 sessions, and 128 MB to support 16000 sessions (CIP2 only). TN3270 server can run
concurrently with any of the other CIP applications (IP Datagram, TCP/IP Offload, or CIP SNA
(CSNA)), but operation of any of these features will affect the total number of sessions supported
because of contention for CIP processor cycles.
Update to Configuration Guide
The information that follows is an update to the Router Products Configuration Guide, Chapters 23
to 33. Add the TN3270 information as a standalone chapter following page 33-22.
Cisco 7000 Series Required Code Memory Required CIP Memory Release11.0 Runs From
Enterprise Set
(gs7-k-mz) 8 MB Flash memory card 16 Mb 32 Mb RAM
Enterprise/CIP2 Set
(gs7-k2-mz) 8 MB Flash memory card 16 Mb 32 Mb RAM
Cisco 7500 Series
and Cisco 7000
with RSP7000 MinimumRequired Code Memory Required Main Memory Required CIP Memory Release11.0 Runs From

Configuring TN3270 Server on the Channel Interface Processor 5
Cisco’s Implementation of TN3270 on a Channel Interface Processor
Configuring TN3270 Server on the Channel
Interface Processor
This chapter describes TN3270 server support provided by the Channel Interface Processor (CIP)
card for Systems Network Architecture (SNA) devices. For a complete description of the commands
mentioned in this chapter, refer to the “TN3270 Server Commands” update chapter.
Cisco’s Implementation of TN3270 on a Channel Interface Processor
The TN3270 server feature on a CIP card provides mapping between an SNA 3270 host and a
TN3270clientconnectedto a TCP/IP network as shownin Figure 1. Functionally, it is usefultoview
the TN3270 server from two different perspectives: SNA functions and Telnet Server functions.
•SNA Functions
From the perspective of an SNA 3270 host connected to the CIP, the TN3270 server is an SNA
device that supports multiple physical units (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 TN3270 server are dependent LUs. To route these dependent LU
sessions to multiple virtual telecommunications access method (VTAM) hosts connected to the
server in the CIP card, rather than routing in the VTAM hosts, the TN3270 server implements a
SNA session switch with end node dependent LU requester (DLUR) function. Using the DLUR
isoptional so that the TN3270 servercan be used with VTAM versions priortoversion 4.2, which
provide no APPN support.
SNA session switch allows you to eliminate SNA subarea routing between hosts of TN3270
traffic by establishing APPN links with the primary LU hosts directly.
•Telnet Server Functions
From the perspective of a TN3270 client, the TN3270 server is a Telnet server that can support
approximately 8000 (CIP1) or 16000 (CIP2) concurrent Telnet sessions. The server on the CIP
card supports Telnet connection negotiation and data format as specified in RFC 1576 (referred
to as “traditional TN3270”) and RFC 1647 (referred to as “TN3270E”).
Figure 1 TN3270 Implementation
Because the TN3270 server configuration is performed after an interface is configured for CIP SNA
(CSNA) support, TN3270 configuration issues and tasks are addressed separately from the interface
configuration tasks. The description of TN3270 configuration issues and tasks begins in the section
“Configuring TN3270 on a Channel Interface Processor,” later in this chapter.
Router Router Token
Ring
SNA TCP/IP
TN3270
client
S4735

6Configuring TN3270 Server on the Channel Interface Processor
Configuring TN3270 on a Channel Interface Processor
Note To enable the TN3270 server feature, you must have a CIP installed in a Cisco 7000 family
router. The TN3270 server is different from the TN3270 terminal emulation access feature described
in the “Configuring TN3270” chapter of the Access Services Configuration Guide.
Configuring TN3270 on a Channel Interface Processor
The following sections describe additional features of TN3270 server support on the CIP. The
features discussed include the following:
•Dynamic LU Allocation
•Formation of LU Model Type and Number
•Specific LU Allocation
•SNA Session Switch—End Node DLUR
•Multiple Hosts Support
You will also need to understand the following information before proceeding with TN3270
configuration tasks:
•VTAM Host Configuration Considerations for Dynamic LU Allocation
•TN3270 Configuration Modes
Dynamic LU Allocation
This will be the most common form of request from TN3270 clients emulating a TN3270 terminal.
The user typically wants to specify emulating 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. The server will perform the following on such a session request:
•Form an EBCDIC string based on the model type and number requested by the client (see
“Formation of LU Model Type and Number” for the algorithm used). This string is used as a field
in a Reply product set ID (PSID) network management vector transport (NMVT).
•Allocate a LOCADDR from the next available LU in the generic LU pool. This LOCADDR is
used in the NMVT.
•Send the formatted Reply PSID NMVT to VTAM.
When VTAM receives the NMVT, it will use the EBCDIC model type and number string to look up
an LU template under the LUGROUP. For example, the string “327802E” will find a match in the
sample configuration shown in Figure 2. An ACTLU will be sent and a terminal session with the
model and type requested by the client is established.
Formation of LU Model Type and Number
VTAM requires a model type and number from the Reply PSID NMVT to use as a key to look up in
the LU group to find an LU template. The model type is a four character string; the model number
is a two or three character string. The server will accept the following formats of terminal type string
from the client:
•IBM-<XXXX>-<Y>[-E]: This will be formatted as “XXXX0Y”or “XXXX0YE” in the model
type and number field in the Reply PSID NMVT.

Configuring TN3270 Server on the Channel Interface Processor 7
Configuring TN3270 on a Channel Interface Processor
•IBM-DYNAMIC: This will result in “DYNAMIC” being put in the model type and number field.
The VTAM configuration will need to have “DYNAMIC” defined as a template in the LU group.
In fact “IBM-ZZ..Z,” where “ZZ..Z” does not match the preceding syntax, will be forwarded as
“ZZ..Z.”
Note The “E” in the model string refers to 3270 extended datastream. It has no connection with
the “E” in “TN3270E”.
•Any other string is forwarded as is.
•In all cases, the string forwarded is translated from ASCII to EBCDIC and truncated at seven
characters.
A complication arises with TN3270E clients that request a copy of the BIND-IMAGE. Such clients
require system control services (SCS) datastream on the system services control point (SSCP)-LU
flow. All other clients require 3270 datastream on that flow. Therefore, these two kinds of client
must be directed 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 to receive BIND-IMAGE, the character “S” is overlaid on the fifth
character of the string, or appended if the string is less than five characters. (See Table 3.)
Specific LU Allocation
A TN3270E client can request a specific LU name by using the TN3270E command CONNECT as
documented in RFC 1647. The name requested must match the name by which the TN3270 server
knows the LU (see the section “LU Names in the TN3270 Server”), and the host must have activated
the LU (with ACTLU).
LU Names in the TN3270 Server
Where SNA session switching is configured (that is, on DLUR PUs) the TN3270 server learns the
LU names from the ACTLUs.
For direct PUs, a “seed” name can be configured on the PU. The TN3270 server uses this name in
conjunction with the LOCADDRS to generate names for the LUs. It is best to use the same naming
convention as the host, if possible.
Table 3 Examples of Model String Mapping
String from client (ASCII) BIND-IMAGE requested? String to Host (EBCDIC)
IBM-3278-4 No 327804
IBM-3279-5E No 327905E
IBM-3279-3-E Yes 3279S5E
IBM-DYNAMIC Yes DYNASIC
ABC Yes ABCS
ABCDEFGH Yes ABCDSFG

8Configuring TN3270 Server on the Channel Interface Processor
VTAM Host Configuration Considerations for Dynamic LU Allocation
SNA Session Switch—End Node DLUR
An end node DLUR function is implemented as part of the TN3270 server. The purpose of the
DLUR is to allow the routing of TN3270 LUs to multiple VTAM hosts to be performed in the CIP
card rather than on the VTAM hosts. The need for this feature will increase with the introduction of
the new 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 on the ACTLU, which greatly simplifies the configuration to support specifically
requested LUs such as printers.
Multiple Hosts Support
The TN3270 server supports access to multiple hosts via the configuration on a PU basis (Table 4).
PUs connected to different hosts or applications can be configured with different IP address.
From the pu (direct) TN3270 configuration command values shown in Table 4, PU X2 establishes
a link to a host at SAP 8 on MAC address 4100.cafe.0002. A client connecting to IP address
171.69.176.43 is allocated an LU from that PU and is routed to that host.
Note that by using the DLUR function, all 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.
VTAM Host Configuration Considerations for Dynamic LU Allocation
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 CIP TN3270 server
implementation removes the static nature of these configurations by using a VTAM release 3.4
feature, dynamic definition of dependent LU (DDDLU). (Refer to the VTAM operating system
manuals for your host system, under the descriptions for LUGROUP for additional information.)
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 Figure 2.
Table 4 Direct PU Configuration in Router
Comman
dPU Name IDBLK IP-address Type
Adapte
r
number LSAP RMAC RMAC LU-seed LU-name
pu X1 05D30001 192.195.80.40 tok 1 4 rmac 4100.cafe.0001 lu-seed TN3X1###
pu X2 05D30002 171.69.176.43 tok 1 8 rmac 4100.cafe.0002 lu-seed TN3X2###

Configuring TN3270 Server on the Channel Interface Processor 9
VTAM Host Configuration Considerations for Dynamic LU Allocation
Figure 2 VTAM Host Values Defining LUSEED and LUGROUP
With the configuration shown in Figure 2 defined in the host, the ACTPU sent by VTAM for the PU
TN3270PU will have the “Unsolicited NMVT Support” set in the system services control point
(SSCP) capabilities control vector. This allows the PU to dynamically allocate LUs by sending
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 2, ACTLUs
will be sent for TN3X1100 and TN3X1101. The server sends a positive response and sets SLU
DISABLED. The LOCADDR of these 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 time expires, it is assumed 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.
Example VTAM host values defining LUSEED and LUGROUP name parameters:
TN3270PU PU .
IDBLK=05D,
IDNUM=30001,
* define other PU parameters
LUSEED=TN3X1###, * define the seed component of the LU names
created by DDDLU (e.g. LOCADDR 42 will have
the name TN3X1042)
LUGROUP=AGROUP * define the LU group name
*
TN3X1100 LU LOCADDR=100,
MODETAB=AMODETAB * define a terminal which requires a specific LU name
*
TN3X1101 LU LOCADDR=101,
DLOGMODE=M3287CS * define a printer which requires a specific LU name
Example VTAM host values defining LUGROUPname, AGROUP:
AGROUP LUGROUP * define LU group to support various
terminal types
327802E LU USSTAB=USSXXX,
LOGAPPL=TPXP001,
DLOGMOD=SNX32702,
SSCPFM=USS3270
* define 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
* define 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
* define template to support IBM 3279
terminal model 5
@ LU USSTAB=USSXXX,
LOGAPPL=TPXP001,
DLOGMOD=D4A32772,
SSCPFM=USS3270
this is the default template to match any
other terminal types

10 Configuring TN3270 Server on the Channel Interface Processor
TN3270 Configuration Modes
After the VTAM activation, the server can support session requests from clients using dynamic or
specific LU allocation.
TN3270 Configuration Modes
The TN3270 configuration modes and router command prompts are described in the following
sections and displayed in Figure 3. The TN3270 server can be configured only on Port 2, the internal
LAN port, of a CIP card.
Some configuration commands create entities on the CIP. 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 which identify the specific instance of the entity (for
example, a PU name) and those that merely set operating parameters. To return to the mode later, the
same command is used but with only the first set of parameters. The following example tasks clarify
how to return to a command mode without necessarily 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:
To return later to the DLUR LSAP configuration mode on the same entity, perform the following
task beginning in TN3270 DLUR configuration mode:
To remove an entity, the same identification parameters are needed. Perform the following task
beginning in TN3270 DLUR configuration mode:
TN3270 configuration modes described in this section include the following:
•TN3270 Server Configuration Mode
•DLUR Configuration Mode
•DLUR SAP Configuration Mode
•PU Configuration Mode
•Commands Allowed in Multiple Modes
Task Command
Create a DLUR LSAP and enter DLUR LSAP
configuration mode. lsap token-adapter 1 84
Task Command
Enter DLUR LSAP configuration mode on the
same LSAP. lsap token-adapter 1
Task Command
Remove a previously defined DLUR LSAP entity. no lsap token-adapter 1