sg245948-04 OSA Implem
sg245948-04 OSA Implem
OSA-Express
Implementation Guide
Product, planning, and quick
start information
Bill White
Hubert Kordmann
Joel Porterie
Rudi Van Niekerk
Thomas Wienert
ibm.com/redbooks
International Technical Support Organization
October 2005
SG24-5948-04
Note: Before using this information and the product it supports, read the information in “Notices” on
page ix.
This edition applies to the OSA-Express2 and OSA-Express features installed in the IBM System z9 109
(z9-109) and Eserver zSeries servers 990, 890, 900, and 800 (z990, z890, z900, and z800).
© Copyright International Business Machines Corporation 2000, 2001, 2003, 2005. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. iii
3.2.1 Channel path definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.2 Control unit definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.3 Device definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.4 Generating the input IOCDS from HCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Contents v
10.6 Defining Enterprise Extender to z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
10.6.1 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
10.6.2 VTAM definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
10.6.3 Activation and verification (NN-to-NN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
10.6.4 Defining Enterprise Extender to IBM Personal Communications . . . . . . . . . . . 177
10.6.5 Activation and verification (EN-to-NN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Contents vii
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions are
inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and
distribute these sample programs in any form without payment to IBM for the purposes of developing, using,
marketing, or distributing application programs conforming to IBM's application programming interfaces.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. ix
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Advanced Peer-to-Peer Networking® Parallel Sysplex® VSE/ESA™
AIX® Redbooks (logo) ™ VTAM®
ESCON® Redbooks™ z/Architecture™
Eserver® Resource Link™ z/OS®
Eserver® RACF® z/VM®
FICON® RMF™ z/VSE™
HiperSockets™ S/390® zSeries®
IBM® System z9™ z9™
MVS™ Tivoli®
OS/2® VM/ESA®
IPX, Java, JavaHelp, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows NT, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation
or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
This IBM® Redbook helps you to install, tailor, and configure the Open Systems
Adapter-Express (OSA-Express) features that are available on IBM System z9™ and IBM
Eserver zSeries® servers (System z9 109 and zSeries 990, 890, 900, and 800). It focuses
on the hardware installation and the software definitions that you need to provide connectivity
to various LAN environments. It provides information to help you with planning and system
setup. It also includes helpful utilities and commands for monitoring and managing the
OSA-Express features.
The target audience for this redbook is system engineers, network administrators, and system
programmers who will plan for and install OSA-Express. Prior to reading this redbook, you
must have a solid background in System z9 and zSeries hardware, HCD or IOCP, OSA/SF,
SNA/APPN, and TCP/IP.
Bill White is a Project Leader and Senior Networking Specialist at the ITSO in Poughkeepsie,
New York.
Hubert Kordmann is a Senior Consultant in the zSeries Support Center in Germany. He has
25 years of experience in supporting large zSeries and S/390® customers. His area of
expertise include zSeries servers and connectivity.
Joel Porterie is a Senior IT Specialist who has been with IBM France for 27 years. He works
for Network and Channel Connectivity Services in the EMEA Product Support Group. His
areas of expertise include z/OS®, TCP/IP, VTAM®, OSA-Express and Parallel Sysplex® for
zSeries. He has taught OSA-Express and FICON® problem determination classes and
provided onsite assistance in these areas in numerous countries. He also co-authored the
IBM Redbooks™ Using the IBM S/390 Application StarterPak, SG24-2095, and
OSA-Express Gigabit Ethernet Implementation Guide, SG24-5443.
Rudi Van Niekerk is a Consulting IT Specialist and IBM Certified Professional who works for
Network and Connectivity Services in South Africa. He has worked with IBM mainframes
since 1985. His areas of expertise include IBM Communications Server (VTAM/APPN,
TCP/IP), Parallel Sysplex, OSA-Express, and SNA-IP migration. He also co-authored the IBM
Redbook SNA in a Parallel Sysplex Environment, SG24-2113.
Thomas Wienert is a Senior IT Specialist working for IBM Systems Sales Technical Support
in Germany, where he supports clients in Germany, Switzerland, and Austria. He has worked
for IBM for 15 years as an S/390 Systems Engineer in technical support and marketing. His
areas of expertise include VTAM, TCP/IP, OSA-Express, z/OS, Parallel Sysplex, and
zSeries-related hardware.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. xi
Thanks to the following people for their contributions to this project:
Dave Bennin
Roy Costa
Robert Haimowitz
ITSO, Poughkeepsie Center
Connie Beuselinck
IBM Eserver zSeries Product Planning, Poughkeepsie Center
Alfred Christensen
Enterprise Networking Solutions Architecture, Strategy and Design, IBM Raleigh
Dennis Musselwhite
z/VM® CP Connectivity, IBM Endicott
Your efforts will help increase product acceptance and customer satisfaction. As a bonus,
you'll develop a network of contacts in IBM development labs, and increase your productivity
and marketability.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Send us your comments about this or
other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
[email protected]
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 1
1.1 Description
OSA-Express2 and OSA-Express comprise several integrated hardware features which can
be installed in a System z9 and zSeries input/output (I/O) cage, becoming integral
components of the server’s I/O subsystems. The OSA-Express Gigabit Ethernet (GbE),
1000BASE-T Ethernet, Fast Ethernet (FENET), Token Ring, and ATM features provide
significant enhancements over OSA-2 in function, connectivity, bandwidth, data throughput,
network availability, reliability, and recovery.
The OSA-Express2 Gigabit Ethernet short wavelength (GbE SX) and long wavelength
(GbE LX) features, the 10 Gigabit Ethernet Long Reach (10 GbE LR) feature, and now also
the 1000BASE-T Ethernet features are the newest members of the OSA-Express family. They
can provide increased bandwidth over the OSA-Express features.
All OSA-Express2 and OSA-Express features are “hot-pluggable”. Figure 1-1 shows the
features that are available on the System z9 and the zSeries servers.
z990
z890
4/16/100 Mbps 4/16/100 Mbps
Token Ring
100
0BA E-T
SE AS
FEN -T B
00
ET 10 T
NE
FE
10 Gb
E
bE
G
bE
LR
G
LR
bE
G
10
Ethernet Gb z9-109
E
FE
NE
10 T
E Gb
Gb 10
EL
R
00
BA
SE
T -T
NE
FE
FE
NE
T
4/16/100
Mb p s
G
bE
Token Ring
4/1
6/1 z800
00
z900 15 Mb
5 ps
AT
M
Terminology: If not specifically stated, the term OSA-Express applies to both the
OSA-Express and the OSA-Express2 features throughout this chapter.
The OSC channel type is used exclusively with the OSA-Express2 and OSA-Express
1000BASE-T Ethernets for the OSA-Express Integrated Console Controller (OSA-ICC). The
OSA-ICC function can eliminate the requirement for external console controllers. It is
supported by System z9 109 (z9-109) and zSeries 990 (z990) and 890 (z890) servers.
Note: For a detailed description about the OSA-ICC function, including configuration
information, refer to OSA-Express Integrated Console Controller Implementation Guide,
SG24-6364.
The OSA-Express2 Gigabit Ethernet and 1000BASE-T Ethernet features have the capability
to provide direct (logical partition (LPAR)-to-LPAR) connectivity to the Communication
Controller for Linux® (CCL) on z9-109 with the introduction of the OSN CHPID type. For more
information, see 1.2.15, “Communications controller migration support” on page 20.
Table 1-1 gives an overview of the type of traffic supported and whether Open Systems
Adapter Support Facility (OSA/SF) is required to configure the OSA-Express2 or
OSA-Express port, based on the supported modes of operation (CHPID types).
One OSA/SF application can communicate with all OSA features in a System z9 and zSeries
server. OSA/SF communicates with an OSA-2 or OSA-Express feature through a device
(type OSAD) defined via HCD/IOCP.
For more details, refer to 1.2.16, “OSA/SF support” on page 22, and Chapter 4, “Setting up
and using OSA/SF” on page 59.
Host
Memory
IOP Host
Memory
Channel OSA-Express
QDIO
Control
Unit
OSA-Express
non-QDIO
The components that make up QDIO are DMA, priority queuing (z/OS only), dynamic OSA
Address Table (OAT) building, LPAR-to-LPAR communication, and IP Assist (IPA) functions.
Priority queuing
Priority queuing is a capability supported by the QDIO architecture and introduced with the
Service Policy Server (for z/OS environments only). It sorts outgoing IP message traffic
according to the service policy you have set up for the specific priority assigned in the IP
header.
Priority queuing is an alternative to the best effort priority assigned to all traffic in most TCP/IP
networks. It allows the definition of four different priority levels for TCP/IP traffic through the
OSA-Express features defined for QDIO. For example, you can grant interactive
communications the highest priority while assigning batch traffic the lowest, with two
additional categories in between, perhaps based on particular user groups or projects.
QDIO uses four write (outbound) queues and one read (inbound) queue for each TCP/IP
stack sharing the OSA-Express feature. OSA-Express signals to Communications Server
when there is work to do. Communications Server puts outbound packets in one of the four
queues, based on priority settings. At a certain time, Communications Server signals the
OSA-Express feature that there is work to do. The OSA-Express feature searches the four
possible outbound queues by priority and sends the packets to the network, giving more
priority to queues 1 and 2, and less priority to queues 3 and 4.
For example, if there is data on every queue, queue 1 is served first, then portions of queue 2,
then fewer portions of queue 3, then even fewer portions of queue 4, and then back to
queue 1. This means that if there were four transactions running across the four queues, over
time, queue 1 would finish first, queue 2 would finish second, and so on.
Restriction: With OSA-Express2, priority queuing is by default enabled. This reduces the
total number of supported TCP/IP stacks and devices (see “Maximum TCP/IP stacks and
devices” on page 8).
The OAT entries are dynamically built when the corresponding IP device in the TCP/IP stack
is started. At device activation, all IP addresses contained in the TCP/IP stack’s IP HOME list
are downloaded to the OSA-Express port. Corresponding entries are built in the OAT.
Subsequent changes to these IP addresses cause a corresponding update of the OAT.
LPAR-to-LPAR communication
Access to an OSA-Express port can be shared among the system images that are running in
the LPARs to which the channel path is defined to be shared. Also access to a port can be
shared concurrently among TCP/IP stacks in the same LPAR or in different LPARs.
When port sharing, an OSA-Express port operating in QDIO mode has the ability to send and
receive IP traffic between LPARs without sending the IP packets to the LAN and then back to
the destination LPAR. For outbound IP packets, the OSA-Express port uses the next-hop IP
address within the packet to determine where it is sent. If the next-hop IP address had been
registered by another TCP/IP stack sharing the OSA-Express port, then the packet is sent
directly to that TCP/IP stack and not onto the LAN. This makes the forwarding of IP packets
possible within the same host system.
HiperSockets™ for System z9 and zSeries also provides a highly efficient way to
communicate between different LPARs with better throughput than LPAR-to-LPAR
communication.
The concurrent LIC update applies to the OSA-Express2 features 1000BASE-T Ethernet,
Gigabit Ethernet SX, Gigabit Ethernet LX, and 10 Gigabit Ethernet LR. It is offered for the
QDIO and OSA for Network Control Program (NCP) mode only (CHPID type OSD and OSN)
and is exclusive to z9-109, z990 and z890. (z990 and z890 require the January 2005 level of
LIC.)
For more information about QDIO, see Chapter 5, “QDIO mode” on page 79.
The OSA-Express 1000BASE-T, FENET, Token Ring, and 155 ATM MM and SM features
support non-QDIO mode. This mode supports SNA/APPN/HPR and TCP/IP traffic
simultaneously through the OSA-Express port. The following sections explain the non-QDIO
mode types.
TCP/IP Passthru
In TCP/IP Passthru mode, an OSA-Express feature transfers data between a TCP/IP stack, to
which it is defined, and clients on the following networks:
An Ethernet 10/100/1000 Mbps LAN that is attached to the port on an OSA-Express
1000BASE-T feature and supports one of the following frame protocols:
– Ethernet II using the DEC Ethernet V 2.0 envelope
– Ethernet 802.3 using the 802.2 envelope with SNAP
An Ethernet 10/100 Mbps LAN that is attached to the port on an OSA-Express FENET
feature and supports one of the following frame protocols:
– Ethernet II using the DEC Ethernet V 2.0 envelope
– Ethernet 802.3 using the 802.2 envelope with SNAP
A Token Ring 4/16/100 Mbps LAN that is attached to the port on an OSA-Express Token
Ring feature and supports one of the following frame protocols:
– IEEE 802.2 Logical Link Control (LLC)
– IEEE 802.5 MAC (802.5 using the 802.2 envelope)
– Token Ring 802.5 using the 802.2 envelope with SNAP
An ATM emulated 155 Mbps LAN on an ATM-based network that is attached to the port of
an OSA-Express ATM feature and supports one of the following frame protocols:
– Ethernet II using the DEC Ethernet V 2.0 envelope
– Ethernet 802.3 using the 802.2 envelope with SNAP
– Token Ring 802.5 using the 802.2 envelope with SNAP
For TCP/IP Passthru mode, the default OAT may be used. In that case, no configuration or
setup is required.
An ATM OSA-Express feature can run in the HPDT ATM Native mode to support high-speed
networking for classical IP networks (Request for Comments (RFC) 1577). OSA-Express
ATM features running in HPDT ATM Native mode cannot support any other mode at the same
time.
SNA/APPN/HPR support
In this mode, an OSA-Express feature acts as an SNA passthru agent to clients that:
Use the SNA protocol on the LAN that is directly attached to the OSA-Express
If an OSA-Express feature is running in the SNA mode, it is viewed by VTAM as an
external communications adapter (XCA) that can have either switched or non-switched
lines of communication.
Bridge from the ATM network in an ELAN configuration with OSA-Express ATM
An OSA-Express 155 ATM feature can support SNA traffic while operating in either ATM
Native mode or LAN Emulation (LANE).
Note: The restriction of 84 TCP/IP stacks was based on the support of only one control
unit per CHPID. With the October 2004 level of LIC, the OSA-Express and
OSA-Express2 features on the z990 and z890 servers support up to 16 control units
per CHPID.
Note: By default, OSA-Express2 has multiple priorities for outbound queues enabled
(four QDIO priorities). This means, the maximum number of supported devices is
reduced to 480 (1920 devices / 4 = 480 devices). This reduces the total number of
supported TCP/IP stacks to 160 (480 devices / 3 = 160 stacks).
Priority queues can be disabled via HCD/IOCP. For example, in IOCP use the
CHPARM value to disable priority queuing.
An IP address traditionally ties to a physical link at one end of a connection. If the associated
physical link goes down, it will be unreachable. The VIPA exists only in software and has no
association to any physical link. The TCP/IP stack is the destination IP address instead of the
network attachment.
For enhanced availability, the definition of one primary router and multiple secondary routers
for devices on an OSD-type CHPID is supported. However, only one secondary router is
supported for devices on an OSE-type CHPID.
For more details, refer to Chapter 13, “IPv6 support” on page 227.
Application
63 KB 63 KB 63 KB
send buffer
1.5 KB
9 KB
TCP Stack
..
1.5 KB 64 KB
.. 9 KB
..
.
1.5 KB 9 KB 1.5 KB
OSA-Express2
NIC ..
1.5 KB ..
1.5 KB
.. ..
. .. .
Figure 1-3 Large send versus standard Ethernet and Jumbo frame sizes
Large send supports outbound IPv4 traffic only and applies solely to unicasts. It reduces host
processor utilization, returning central processing unit (CPU) cycles for application use while
increasing network efficiencies. The large send is supported by z9-109, z990, and z890 and
applies only to OSA Express2 (10 Gigabit Ethernet LR, 1000 BASE-T Ethernet, and GbE SX
and LX). z990 and z890 servers require the January 2005 level of LIC.
Large send for Linux on System z9 and zSeries is available with Kernel 2.6 major update from
23 March 2005. For more information about Linux support, refer to the following Open source
projects Web site:
http://www-128.ibm.com/developerworks/views/opensource/projects.jsp
Large send support is available with z/OS 1.7 and z/OS 1.6 with program temporary fixes
(PTFs). Refer to the 2094, 2086, or 2084 PSP bucket for additional information.
The IEEE standard 802.1Q describes the operation of Virtual Bridged LANs. A VLAN is
defined to be a subset of the active topology of a LAN. The OSA-Express features provide for
the setting of multiple unique VLAN IDs per QDIO data device. They also provide for both
tagged and untagged frames to flow from an OSA-Express port. The number of VLANs
supported is specific to the operating system.
With System z9 and zSeries servers, where multiple TCP/IP stacks exist, potentially sharing
one or more OSA-Express features, VLAN support is designed to provide a greater degree of
isolation (see Figure 1-4).
LP 1 LP 2 LP 3 LP 4
z/OS TCP/IP z/OS TCP/IP Linux TCP/IP z/VM TCP/IP
IPv4 IPv4 IPv6 IPv6 IPv4 IPv4
VLAN 28 VLAN16 VLAN37 VLAN37 VLAN4 VLAN12
Ethernet Switch
z/OS V1.4 Communications Server only supports VLAN priority tagging. However, with APAR
PQ86508, both priority tagging and VLAN IDs are supported.
In z/VM V5.1, support was offered for one global VLAN ID for IPv6. The z/VM TCP/IP stack
supports one VLAN ID per OSA-Express port. Each port can be configured with a different
VLAN ID.
For Linux on zSeries support, refer to the following Web site for further information:
http://www.ibm.com/developerworks
For more information about VLAN, see Chapter 11, “VLAN support” on page 183.
With GVRP support, an OSA-Express2 port can register or deregister its VLAN IDs with a
GVRP-capable switch and dynamically update its table as the VLANs change (see
Figure 1-5).
OSA-Express2
VLAN22
VLAN33
VLAN44
GVRP support
dynamically registers
VLAN IDs to the
physical LAN
Physical LAN
Support of GVRP is exclusive to z9-109 and is applicable to all of the OSA-Express2 features
when in QDIO mode (CHPID type OSD). It is supported by z/OS 1.7 with PTFs, and z/VM
V5.1 with PTFs (planned availability in the second quarter of 2006).
SNMP support for LAN Channel Station (LCS) was introduced in May 2004. It applies to all of
the OSA-Express features supported on z9-109, z990, and z890 in conjunction with TCP/IP
applications only. It supports the same SNMP requests and alerts offered in QDIO mode
(Get, GetNext, Trap, and Set) and is exclusive to the z/OS V1.6 environment.
For more information on SNMP support, refer to the Direct SNMP Support for OSA-Express
Web site at:
http://www.ibm.com/servers/eserver/zseries/networking/dsnmp.html
Tip: If you subscribe to the document “OSA-Express Direct SNMP MIB module” through
Resource Link™, then you will receive e-mail notification of document changes.
OSA/SF is no longer required to manage SNMP data for the OSA-Express features. An
SNMP subagent exists on an OSA-Express feature, which is part of a direct path between the
z/OS or Linux master agent (TCP/IP stacks) and an OSA-Express MIB.
The OSA-Express features support an SNMP agent by providing data for use by an SNMP
management application, such as Tivoli® NetView. This data is organized into MIB tables
defined in the TCP/IP enterprise-specific MIB, as well as standard RFCs. The data is
supported by the SNMP TCP/IP subagent (see Figure 1-6).
z/OS z/OS
OSAD
UNIX Shell OSNMPD device
User's Address SNMP Agent's with
Space Address Space subagent
osnmp command
TCP/IP
Address Space
Tivoli NetView OSA proxy
Address Space TCP Subagent
Multicast support
Multicast support is for sending data to multiple recipients. OSA-Express features support IP
multicast destinations only in QDIO or IP Passthru mode.
A broadcast simultaneously transmits data to more than one destination. Messages are
transmitted to all stations in a network (for example, a warning message from a system
operator). The broadcast frames can be propagated through an OSA-Express feature to all
TCP/IP applications that require broadcast support, including applications using RIP V1.
ARP Takeover
ARP Takeover provides the capability of switching OSA-Express port operations from one
OSA-Express to another OSA-Express running in the same mode.
When TCP/IP is started in QDIO mode, it downloads all the home IP addresses in the stack
and stores them in each OSA-Express feature to which it has a connection. This is a service
of QDIO architecture and occurs only automatically for OSD channels. For OSA-Express
features set up as OSE channels (non-QDIO), you must define multiple IP addresses in the
OAT using OSA/SF. The OSA-Express then responds to ARP requests for its own IP address,
as well as for VIPAs.
If an OSA-Express feature fails while there is a backup OSA-Express available on the same
network or subnetwork, TCP/IP informs the backup OSA of which IP addresses (real and
VIPA) to take over, and the network connection is maintained. Note that for this to work,
multiple paths must be defined to the TCP/IP stack. For example, MULTIPATH must be
defined to the IPCONFIG statement of the TCP/IP profile in z/OS.
ARP statistics
QDIO includes an IPA function, which gathers ARP data during the mapping of IP addresses
to MAC addresses. CHPIDs defined as OSD maintain ARP cache information in the
OSA-Express feature (ARP offload). This is useful in problem determination for the
OSA-Express feature.
Note: Not all OSA-Express features provide ARP counter statistics and ARP cache
information to TCP/IP.
When TCP/IP is started in QDIO mode, it downloads all the home IP addresses in the stack
and stores them in the OSA-Express feature. This is a service of the QDIO architecture. The
OSA-Express feature port then responds to ARP requests for its own IP address and for
VIPAs. If an OSA-Express feature fails while a backup OSA-Express is available on the same
network or subnetwork, TCP/IP informs the backup OSA-Express feature port about which IP
addresses (real and VIPA) to take over. Then it sends a gratuitous ARP, which contains the
MAC address of the backup OSA-Express. The network connection is maintained.
Note: Linux on System z9 and zSeries supports only inbound checksum offload (inbound
packets).
When checksum is offloaded, the OSA-Express feature performs the checksum calculations.
Therefore, this function applies only to packets that actually go onto the LAN or come in from
the LAN. When multiple IP stacks share an OSA-Express feature port, and an IP stack sends
a packet to a next hop IP address owned by another IP stack sharing the same OSA-Express
port, OSA sends the IP packet directly to the other IP stack without placing it on the LAN.
Checksum offload does not apply to such IP packets.
Checksum offload does not apply to IPv6 packets. TCP/IP will continue to perform all
checksum processing for IPv6 packets. This function does not apply to ICMP checksum
processing. TCP/IP continues to perform processing for ICMP checksum.
For Linux on zSeries support, refer to the following Web site for further information:
http://www.ibm.com/developerworks
The Virtual Switch exploits the Layer 2 support within the z/VM Control Program. The z/VM
Control Program owns the connection to the OSA-Express feature and manages the MAC
addresses and VLAN connectivity of the attached guest systems. The Virtual Switch performs
automatic MAC address generation and assignment to allow uniqueness across the z/VM
guest systems. MAC addresses can also be locally administered.
The Virtual Switch uses each guest system’s unique MAC address to forward frames. Data is
transported and delivered within Ethernet frames. This provides the ability to transport both IP
and non-IP (for example, NetBIOS and SNA) frames through the fabric that the Virtual Switch
supports (see Figure 1-7). Through the address-resolution process, each guest system’s
MAC addresses become known to hosts residing on the physical side of the LAN segment. All
inbound or outbound frames passing through the OSA-Express port have the guest system’s
corresponding MAC address as the source or destination address.
z/VM
02-00-00-00-00-01 02-00-00-00-00-02 02-00-00-00-00-03
TCP/UDP
Linux Linux Linux
guest guest guest Appl.
SNA
Appl.
Virtual Switch (Layer 2)
Ethernet
NetBIOS
Switch
Appl.
02-00-00-00-00-01
02-00-00-00-00-02
02-00-00-00-00-03
OSA-Express
Figure 1-7 Layer 2 support via the virtual switch and OSA-Express
The OSA-Express2 or OSA-Express Ethernet features can filter inbound frames by VLAN ID
(IEEE 802.1q), the Ethernet destination MAC address, or both. Filtering can reduce the
amount of inbound traffic being processed by the operating system, helping to reduce CPU
utilization. Filtering by a VLAN ID can also allow you to isolate portions of your environment
that have sensitive data, providing a degree of low-level security.
Note: OSA-Express port sharing is supported only between Virtual Switches that use the
same transport mode (Layer 2 with Layer 2 and Layer 3 with Layer 3).
For more information about OSA-Express Layer 2 support and z/VM Virtual Switch, see
Chapter 12, “Layer 2 support” on page 201. For more information about the OSA-Express
VLAN support, see Chapter 11, “VLAN support” on page 183.
Load balancing
A single, locally administered MAC address can be defined to multiple physical OSA-Express
feature ports attached to different LAN segments. The number of sessions established is
monitored, and user session loads distributed. A session is established with the LAN segment
that responds the fastest.
Redundancy
A secondary path between a LAN workstation and the host server can be configured as “hot
standby”. If the primary path becomes unavailable, the secondary path receives the LAN
traffic.
Note: SNA enhanced availability is offered only for bridged source routing environments.
Ethernet does not support source routing. Therefore, only OSA-Express ATM LANE mode
(token ring) and OSA-Express Token Ring are supported.
The EE function is a TCP/IP encapsulation technology that carries SNA traffic from an
endpoint over an IP network (for example, via the OSA-Express port to Communications
Server) to another endpoint where it is de-encapsulated and presented to an SNA application.
For more information about Enterprise Extender, see Chapter 10, “Enterprise Extender” on
page 165.
In addition, IBM is working with our Linux distribution partners to enable them to provide the
changes required to run CCL in future distribution releases. Refer to the following Web site for
information regarding supported distributions and releases.
http://www-1.ibm.com/support/docview.wss?rs=2192&uid=swg27005768
In order to support CCL, VTAM must also support activation of CCL NCPs that are directly
attached to the activating VTAM through an XCA major node.
Figure 1-8 shows the traffic flow on a zSeries server between VTAM on a z/OS LPAR
communicating with the CCL running as a guest under z/VM in a separate LPAR. Note that
two Ethernet OSA-Express ports (CHPID type OSE) are used. On the z/OS side, one is
defined as LSA, while the other on the CCL side is defined as LCS. A third Ethernet
OSA-Express port (CHPID type OSE) is defined as LCS and is used to communicate with
SNA devices on the LAN.
z/VM z/OS
NCP VTAM
CCL
LCS LSA
OSE OSE
OSN can help to eliminate the requirement of having an external medium (and all related
hardware) for communications between an operating system and the CCL image in the same
System z9 server. Traffic between the LPARs (operating system and CCL) is no longer
required to flow on the LAN or ESCON® channel.
Using existing SNA support (multiple transmission groups), OSN support permits multiple
connections between the same CCL image and the same operating system (such as z/OS or
TPF), residing in the same System z9 server as the CCL image.
OSN provides an efficient method of communication and is designed to create a secure and
seamless integration of the operating system and CCL. For example, CHPID type OSN
supports the following functions:
Appears to the operating systems as an ESCON channel connected to a 374x device type
which exploits existing CDLC protocols
Allows system administrators of the various operating systems to configure, manage, and
operate their CCL NCPs as if they were running in an ESCON-attached 374x
Communications Controller
Enables NCP channel-related functions such as loading and dumping the NCP
Does not require external hardware (cables or switches)
Allows multiple CCL images to communicate with multiple operating system images,
supporting up to 180 connections (374x subchannels)
Can span Logical Channel Subsystems
OSN support is exclusive to the z9-109 and is supported by z/OS, z/VM, z/VSE™, TPF, and
Linux on System z9.
Figure 1-9 shows the traffic flow on a z9-109 between VTAM on a z/OS LPAR or TPF LPAR
communicating with the CCL running as a guest under z/VM in a separate LPAR. Note that
one Ethernet OSA-Express2 port (CHPID type OSN) is used. On the z/OS or TPF side, it is
defined as CDLC, while on the CCL side, it is defined as QDIO (QETH). A second Ethernet
OSA-Express port (CHPID type OSD) is defined as QETH and is used to communicate with
SNA devices on the LAN.
For more information about CCL, refer to IBM Communication Controller Migration Guide,
SG24-6298, and to the Linux on zSeries Web site:
http://www.ibm.com/software/network/ccl
OSD OSN
Interoperability testing has been performed for Windows® 2000, Windows XP, and Linux for
zSeries. In the past, workstation support was downloaded to a client supporting Windows
NT®, Windows 95, or OS/2®.
Use of the GUI is optional. A REXX command interface is also included with OSA/SF.
OSA/SF is not required to set up the OSA-Express features in QDIO mode (CHPID type
OSD), but it can be used for monitoring and controlling ports. OSA/SF has been, and
continues to be, integrated in z/OS, z/VM, and VSE/ESA™ and runs as a host application.
For OSA/SF, Java GUI communication is supported via TCP/IP only. In the past,
communication was supported via EHLLAPI (3270), APPC, and TCP/IP.
This integrated version of OSA/SF is a complete replacement for the currently integrated
versions in z/OS, z/VM, and VSE/ESA. This version of OSA/SF is not being offered as a
separately orderable program product.
In the z/OS environment, delivery is via the z/OS V1.4 z990 Compatibility Support feature (for
release z/OS V1.4) and z990 Compatibility for Selected Releases Web deliverable (for
releases z/OS V1.2 and z/OS V1.3).
This support is applicable to all OSA-Express2, OSA-Express, and OSA-2 features on all
supported servers.
Note: The OSA-2 features are not supported on the z9-109, z990, z890, or z800 servers.
With z/OS, you can use a second interface using a set of REXX EXECs through the Time
Sharing Options Extensions (TSO/E) to control the OSA-2 features, OSA-Express features,
or both that are defined to the System z9 and zSeries servers on which the TSO/E is running.
OSA/SF is not always required to customize an OSA-Express feature, but we highly
recommend that you use it to gather operational information and to assist in problem
determination. The OSA/SF Query function provides performance information about the
OSA-Express CHPIDs.
OSA/SF is required for the configuration of the OSA-Express 155 Mbps ATM features.
OSA/SF is not required to configure the OSA-Express features in operating modes OSD,
OSC and OSN.
Refer to Chapter 4, “Setting up and using OSA/SF” on page 59, for more information about
OSA/SF support and set up.
1.3 Connectivity
The OSA-Express features attach directly to the Self-Timed Interconnect (STI) buses via the
I/O cage of the System z9 and zSeries servers. This design eliminates ESCON bus
limitations.
An OSA-Express feature port is defined using the Hardware Configuration Definition (HCD)
and identified by its CHPID.
OSA-Express link
The transmission medium and cabling requirements for the OSA-Express ports depend on
the OSA-Express feature type, OSA-Express port, LAN, and network. Acquiring cables and
other connectivity items is the customer’s responsibility.
Note: DIX V2 and IEEE 802.3 frames can coexist on the same network. However, clients
or servers not using the same protocol are not able to communicate with each other.
OSA-Express devices
The different types of OSA channels (CHPID types) require the following device types:
OSA devices for QDIO (OSD) and non-QDIO (OSE) CHPID types
3270-X and 3287 devices for the OSA-ICC (OSC) CHPID type
3745 and OSN devices for the OSA for NCP (OSN) CHPID type
The OSA/SF program product requires one device (defined via HCD) to be associated with
the OSA-Express CHPID as device type OSAD (UNITADD=FE). OSA/SF uses this device to
communicate with the OSA-Express feature.
See Table 1-2 for details about the maximum number of OSA-Express2 or OSA-Express
ports supported by each System z9 and zSeries server, based on feature.
There is no maximum combined limit for the z9-109. All three I/O cages (84 slots) can be fully
populated with these features on the z9-109.
Spanned channels
Spanning is the ability to configure channels to multiple LCSs. When defined that way, the
channels can be shared transparently by any or all of the configured LPARs, regardless of the
LCS to which the LPAR is configured.
OSA-Express channels can be spanned across multiple LCSSs in z9-109, z990, and z890
servers.
MM 50 µm 550 m (500)
MM 50 µm 550 m (500)
MM 50 µm 550 m (500)
The OSA-Express2 10 GbE LR feature does not support autonegotiation to any other speed
and runs in full duplex mode only. The OSA-Express2 10 GbE LR feature must be defined as
CHPID type OSD. See 1.1.1, “Operating modes” on page 3, for details about modes of
operation and supported traffic types.
The OSA-Express2 GbE LX feature does not support autonegotiation to any other speed and
runs in full duplex mode only. The OSA-Express2 GbE LX feature must be defined as CHPID
type OSD or OSN. See 1.1.1, “Operating modes” on page 3, for details about modes of
operation and supported traffic types.
The OSA-Express2 GbE SX feature does not support autonegotiation to any other speed and
runs in full duplex mode only. The OSA-Express2 GbE SX feature must be defined as CHPID
type OSD or OSN. See 1.1.1, “Operating modes” on page 3, for details about modes of
operation and supported traffic types.
You can choose any one of the following settings for the OSA-Express 1000BASE-T Ethernet
feature port:
Auto-negotiate
10 Mbps half-duplex
10 Mbps full-duplex
100 Mbps half-duplex
100 Mbps full-duplex
1000 Mbps full-duplex
If you are not using autonegotiate, the OSA-Express port attempts to join the LAN at the
specified speed and duplex mode. If this does not match the speed and duplex mode of the
signal on the cable, the OSA-Express port does not connect.
LAN speed or duplex mode can be set explicitly, using OSA/SF or the OSA Advanced
Facilities function of the z9-109 server Hardware Management Console (HMC). The explicit
settings override the OSA-Express2 feature port’s ability to autonegotiate with its attached
Ethernet switch.
The OSA-Express2 1000BASE-T feature can be defined as CHPID type OSD, OSE, OSC, or
OSN. See 1.1.1, “Operating modes” on page 3, for details about modes of operation and
supported traffic types.
Feature codes 1364 and 2364: Feature code 1364 is supported on all System z9 and
zSeries servers. However it has been replaced by FC 3364 on the System z9, z990, and
z890 servers. Feature code 2364 is no longer orderable. You can only bring it forward on
an upgrade from z990, z890, z900 or z800.
The OSA-Express GbE LX features do not support autonegotiation to any other speed and
run in full duplex mode only. The OSA-Express GbE LX features must be defined as CHPID
type OSD. See 1.1.1, “Operating modes” on page 3, for details about modes of operation and
supported traffic types.
Feature codes 1365 and 2365: Feature code 1365 is supported on all zSystem9 and
zSeries servers. However it has been replaced by FC 3365 on the System z9, z890, and
z990 servers. Feature code 2365 is no longer orderable. You can only bring it forward on
an upgrade from z990, z890, z900 or z800.
The OSA-Express GbE SX features do not support autonegotiation to any other speed and
run in full duplex mode only. The OSA-Express GbE SX features must be defined as CHPID
Feature code 1366: You must carry forward FC 1366 on an upgrade from z990 to a
z9-109.
You can choose any one of the following settings for the OSA-Express 1000BASE-T Ethernet
feature port:
Autonegotiate
10 Mbps half-duplex
10 Mbps full-duplex
100 Mbps half-duplex
100 Mbps full-duplex
1000 Mbps full-duplex
If you are not using autonegotiate, the OSA-Express port attempts to join the LAN at the
specified speed and duplex mode. If this does not match the speed and duplex mode of the
signal on the cable, the OSA-Express port does not connect.
LAN speed or the duplex mode can be set explicitly, using OSA/SF or the OSA Advanced
Facilities function of the server HMC. The explicit settings override the OSA-Express feature
port’s ability to autonegotiate with its attached Ethernet switch.
The OSA-Express 1000BASE-T feature can be defined as CHPID type OSC, OSD, or OSE.
See 1.1.1, “Operating modes” on page 3, for details about modes of operation and supported
traffic types.
Feature code 2366: FC 2366 is replaced by FC 1366 on the z890 and z990 servers. You
must carry it forward on an upgrade from z990, z890, z900, or z800.
You can choose any one of the following settings for the OSA-Express FENET feature port:
Autonegotiate
10 Mbps half-duplex
10 Mbps full-duplex
100 Mbps half-duplex
100 Mbps full-duplex
If you are not using autonegotiate, the OSA-Express port attempts to join the LAN at the
specified speed and duplex mode. If this does not match the speed and duplex mode of the
signal on the cable, the OSA-Express port does not connect.
LAN speed or the duplex mode can be set explicitly, using OSA/SF or the OSA Advanced
Facilities function of the zSeries server HMC. The explicit settings override the OSA-Express
feature port’s ability to autonegotiate with its attached Ethernet switch.
The OSA-Express FENET feature can be defined as CHPID type OSD or OSE. See 1.1.1,
“Operating modes” on page 3, for details about modes of operation and supported traffic
types.
The RJ-45 receptacle is required to be attached using EIA/TIA category 5 UTP cable that
does not exceed 45 meters (147 feet), or a shielded twisted pair (STP) cable that does not
exceed 100 meters (328 feet) with a DB-9 D Shell connector.
The OSA-Express Token Ring feature supports auto-sensing as well as any of the following
settings: 4 Mbps half- or full-duplex, 16 Mbps half- or full-duplex, and 100 Mbps full-duplex.
Regardless of the choice made, the network switch settings must agree with those of the
OSA-Express Token Ring feature. If the LAN speed defaults to auto-sense, the OSA-Express
Token Ring feature senses the speed of the attached switch and inserts into the LAN at the
appropriate speed. If the Token Ring feature is the first station on the LAN and the user
specifies auto-sense, it defaults to a speed of 16 Mbps and attempts to open in full-duplex
mode. If unsuccessful, it defaults to half-duplex mode.
Note: The z890 and z990 are the last servers of the zSeries family that provide a Token
Ring feature. z9-109 does not support the Token Ring feature.
The OSA-Express Token Ring feature can be defined as CHPID type OSD or OSE. See
1.1.1, “Operating modes” on page 3, for details about modes of operation and supported
traffic types.
For TCP/IP Passthru mode (see 1.1.3, “Non-QDIO mode” on page 7), the default OAT may be
used. In that case, no configuration or setup is required.
Feature code 2363: With RPQ 8P2258, FC 2363 can be carried forward from a z900
when upgrading to a z990 in non-QDIO mode (OSE CHPID type) only.
The zSeries OSA-Express 155 ATM MM feature is not supported on z990 and z890 new
builds. If ATM connectivity is required, a multiprotocol switch or router with the appropriate
network interface (for example, Gigabit Ethernet, 1000BASE-T Ethernet, or 100BASE-TX
Ethernet) can be used to provide connectivity between the z890 or z990 server and an ATM
network.
The OSA-Express ATM features support TCP/IP Passthru and SNA/APPN/HPR traffic
concurrently in Ethernet or Token Ring LANE.
Note: Two instances of TCP/IP in one LPAR cannot share a single OSA-Express ATM
feature running in HPDT ATM Native mode. However, one instance each of TCP/IP and
VTAM in the same LPAR can do so.
QDIO support is available only when the OSA-Express ATM feature is running in the ATM
Ethernet LANE mode. QDIO cannot be used in any combination with any other modes of
operation. An OSA-Express ATM port can only be configured for one mode at a time, either
for ATM LANE (TR or Ethernet) or ATM Native.
With the ATM Native mode, each physical port on the OSA-Express ATM feature supports a
virtual connection between the server and an ATM Native network.
With the ATM LANE Mode, you can define two emulated ports for the OSA-Express ATM
feature port to connect to two separate ELANs, creating two LECs. An emulated port is a
virtual connection between the server and an existing Ethernet or token-ring network and
provides LEC services for SNA and IP clients. Because the OSA-Express ATM feature port
allows two emulated ports to be configured, the CHPID can handle two different kinds of
network traffic with no recabling at the physical port.
Tip: An option called partial activation enables you to add or change one emulated port
without interrupting traffic on the other emulated port. Partial activation applies only to
emulated ports.
The ATM LANE can support simultaneous IP and SNA/APPN/HPR traffic over Ethernet or
Token Ring LAN. This means the workstation interface and wiring can remain the same for
investment protection. Two ELANs or LECs can be defined per physical port, and each can be
connected to an ATM switch that is in turn connected to an Ethernet or Token Ring LAN. A
maximum of 4096 PUs for SNA per physical port is supported. Each ELAN will cache up to
2000 simultaneous MAC addresses.
The ATM Native mode can support Classical IP (RFC1577, RFC2225) and APPN
simultaneously.
Note: You must use OSA/SF to set up the 155 ATM features, regardless of the mode
being customized.
The two physical ports on the OSA-Express 155 ATM features have independent
subsystems; each port can be defined for either LAN emulation or native ATM.
Note: The z990 with RPQ 8P2258 is the model of the zSeries family of servers to provide
an ATM feature.
Feature code 2362: With RPQ 8P2258, FC 2362 can be carried forward from a z900
when upgrading to a z990 in non-QDIO mode (OSE CHPID type) only.
The zSeries OSA-Express 155 ATM SM feature is not supported on z990 for new build and
z890 servers. If ATM connectivity is required, use a multiprotocol switch or router with the
appropriate network interface (for example, Gigabit Ethernet, 1000BASE-T Ethernet,
100BASE-TX Ethernet) to provide connectivity between the z890 or z990 server and an ATM
network.
The OSA-Express ATM features support TCP/IP Passthru and SNA/APPN/HPR traffic
concurrently in Ethernet or Token Ring LAN emulation.
The OSA-Express ATM features support HPDT ATM Native mode in z/OS and z/VM
environments. This mode requires the exclusive use of the OSA-Express ATM feature. Data
transfer is supported via VTAM for both the SNA and TCP/IP functions of the
Communications Server.
Note: Two instances of TCP/IP in one LPAR cannot share a single OSA-Express ATM
feature running in HPDT ATM Native mode. However, one instance each of TCP/IP and
VTAM in the same LPAR can do so.
QDIO support is only available when the OSA-Express ATM feature is running in the ATM
Ethernet LANE mode. QDIO cannot be used in any combination with any other modes of
operation. An OSA-Express ATM port can only be configured for one mode at a time—either
for ATM LANE (TR or Ethernet) or ATM Native.
With the ATM Native Mode, each physical port on the OSA-Express ATM feature supports a
virtual connection between the server and an ATM Native network.
With the ATM LANE Mode, you can define two emulated ports for the OSA-Express ATM
feature port to connect to two separate ELANs, creating two LECs. An emulated port is a
virtual connection between the server and an existing Ethernet or token-ring network and
provides LEC services for SNA and IP clients. Because the OSA-Express ATM feature port
allows two emulated ports to be configured, the CHPID can handle two different kinds of
network traffic with no recabling at the physical port.
Tip: An option called partial activation enables you to add or change one emulated port
without interrupting traffic on the other emulated port. Partial activation applies only to
emulated ports.
The ATM Native mode can support Classical IP (RFC1577, RFC2225) and APPN
simultaneously.
Note: You must use OSA/SF to set up the 155 ATM features, regardless of the mode
being customized.
The two physical ports on the OSA-Express 155 ATM features have independent
subsystems; each port can be defined for either LAN emulation or native ATM.
Note: The z990 with RPQ 8P2258 is the last model of the zSeries family of servers to
provide the ATM features.
1000BASE-T
Token Ring
10 GbE LR
Functionality
155 ATM
FENET
GbE
GbE
SNMP support x x x x x x x x
1000BASE-T
1000BASE-T
Token Ring
10 GbE LR
Functionality
155 ATM
FENET
GbE
GbE
640 TCP/IP (with priority queues disabled) x x xa n/a n/a n/a n/a n/a
Jumbo frame support (8992 byte frame size) x x xe x xf n/a n/a n/a
a. Only in QDIO mode
b. Only for FC 1364 and FC 1365
c. Only for mode OSD and OSN
d. Exclusively on z9-109
e. Only when configured in 1 Gbps and in QDIO mode
Note: Certain functionality may require specific levels of an operating system or PTFs.
That information is provided when appropriate within this chapter.
For example, with this support, you can analyze possible bandwidth bottlenecks and perform
root cause analysis.
1.4 Summary
The OSA-Express features provide direct LAN and network connectivity as integrated
features of the System z9 and zSeries. This brings the strengths of System z9 and
z/Architecture™ to the client/server environment.
Table 1-4 summarizes the OSA-Express features as they relate to the different modes of
operation and maximum addressing range supported by all zSeries servers.
Table 1-4 Modes of operation and addressing support for OSA-Express and OSA-Express2
Maximum supported z900 + z800 z990 + z890 z990 + z890 z9-109
OSA-Express OSA-Express2
IP addresses
IP addresses per port (IPv4, IPv6, VIPA) 2048 2048 4096 4096
Non-QDIO (OSE)
QDIO (OSD)
Table 1-5 summarizes the supported OSA-Express2 and OSA-Express features based on the
System z9and zSeries server.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 41
2.1 OSA-Express definitions
Before you can exploit your OSA-Express feature, you must first properly define your
hardware and software for it. In doing so, you need to answer the following questions:
To which channel path identifier (CHPID) will the OSA-Express port be assigned?
Will the OSA-Express CHPID be shared or dedicated?
To which LCSS will it be defined (System z9 109 (z9-109), zSeries 990, and 890 (z990
and z890) only)?
Will the OSA-Express port (CHPID) be spanned across LCSSs (z9-109, z990, and z890
only)?
Will the OSA-Express CHPID be defined as OSN (OSA for NCP), OSD (QDIO) or
OSE (non-QDIO)?
Which protocol or protocols will be used with the OSA-Express port (TCP/IP, SNA, or
both)?
The first five items deal with defining the OSA-Express to hardware. For more information,
refer to Chapter 3, “Hardware configuration definitions” on page 47.
Refer to the z/OS quick start table (Table 2-2 on page 45), which provides a quick reference
for relating the CHPID type to operation mode.
For a quick check to determine if OSA/SF is required for your installation, refer to Table 2-1.
Yes Dynamic No
1000BASE-T
Yes Manual Yes
Yes Dynamic No
FENET
Yes Manual Yes
Yes Dynamic No
Token Ring
Yes Manual Yes
ATM
ENET LANE Yes Dynamic Yes
TR LANE Yes Manual Yes
ENET LANE Yes Manual Yes
For information about z/OS wizards and links to specific wizards, go to the following Web site:
http://www-1.ibm.com/servers/eserver/zseries/zos/wizards/
This easy-to-use configuration wizard assists the z/VM installer in providing desired IP
configuration information such as host and domain name, IP addresses, and subnet mask.
From that information, the wizard generates an initial z/VM TCP/IP configuration and verifies
that connectivity to the network has been established.
This utility is on the MAINT 193 minidisk. It can be run one time for the initial definition of a
single connection. The exec is named IPWIZARD. For more information about IPWIZARD,
refer to z/VM Guide for Automated Installation and Service, GC24-6064.
VSE/ESA
The TCP/IP for VSE/ESA Configuration Support is a PC-based front-end used to create a
TCP/IP for VSE/ESA configuration and startup-related files. The dialog is available in an OS/2
version and in a Windows version. Supported languages are English, German, Spanish, and
Japanese.
The dialog operates based on PC files that it reads and writes from and to a PC hard disk
(local or LAN). A batch file is created by the dialog to help upload output files to the host.
Linux
Linux also has a configuration tool that can be used to build your network configuration. The
distribution of Linux that you use determines the setup tool used (for example, SUSE LINUX
uses YAST).
For more information about the different types of OSA-Express features, refer to Chapter 1,
“Overview of Open Systems Adapter-Express” on page 1.
ATM Native Non-QDIO OSE ATM ATM TRLE Chapter 8, “ATM HPDT
IP traffic HPDT native (non-QDIO
mode)” on page 123
ATM Native Non-QDIO OSE TRLE,
SNA traffic HPDT XCA,
SWNET
Note: This IBM Redbook does not go into detail about how to define the OSA-Express
features to z/VM. However, you can update your z/VM TCP/IP profile with the correct
information based on the details in Table 2-3, the processes provided in this book, and the
example of a TCP/IP profile for z/VM included in “z/VM TCP/IP profile” on page 284.
Your IBM representative can supply a channel path identifier (CHPID) Report (z900 and
z800 only) or a physical channel identifier (PCHID) Report that specifies where the
OSA-Express feature is plugged into your server. The CHPID number and PCHID number
(except for z800 and z900) are required for all OSA-Express configuration and setup tasks.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 47
3.1 Configuration chart
The environment shown in Figure 3-1 uses one zSeries server (z990) configured with multiple
logical partitions (LPARs) and two LCSSs. Server SCZP901 has two OSA-Express
1000BASE-T attached to PCHID 110 and 310 (CHPID 0A and 0B, respectively). These
channels are spanned among the LCSSs.
SCZP901
SCZP901
LPAR
SC63
LCSS 1
LAN Infrastructure
Hardware Configuration
2. In the Define, modify, or view configuration data panel, select option 3 (Processors) and
press Enter.
3. In the next display (Figure 3-3), select the processor that you want to update by using
action code S. Then press Enter.
Note: We identify the panel selection options using the action code, rather than the item
number, to avoid confusion when a particular HCD menu changes.
4. In the next display (Figure 3-4), type an S next to the channel subsystem that you want to
work with. Then press Enter.
Processor ID . . . : SCZP901
Note: This example shows how to configure a 1000BASE-T OSA-Express feature. The
process is identical for the other OSA-Express features, including:
The Channel path type must be OSD for QDIO support, or OSE for non-QDIO
support. The OSA-Express 1000BASE-T feature also supports Integrated Console
Controller (OSC).
The Operation mode must be DED to dedicate the port to a single LPAR, SHR to
share among LPARs, or SPAN to share among LPARs in different LCSSs.
Processor ID . . . . : SCZP901
Configuration mode . : LPAR
Channel Subsystem ID : 0
8. Complete the access list for the partitions sharing the channel, as shown in Figure 3-7 and
Figure 3-8. In this example, 17 partitions share the OSA-Express channel in LCSS 0.
Select one or more partitions, then press Enter. To add, use F11.
Processor ID . . . . : SCZP901
Configuration mode . : LPAR
Channel Subsystem ID : 0
Select one or more partitions, then press Enter. To add, use F11.
Processor ID . . . . : SCZP901
Configuration mode . : LPAR
Channel Subsystem ID : 0
9. A panel is displayed for the candidate list. Select the partitions to include in the candidate
list and press Enter. If you do not want any partitions in the candidate list, press Enter.
The Channel Path List panel is displayed.
Connected to switches . . . __ __ __ __ __ __ __ __ +
Ports . . . . . . . . . . . __ __ __ __ __ __ __ __ +
If connected to a switch:
4. As shown in Figure 3-10, type an S next to the processor for the control unit. Then press
Enter.
Unit address . . . . . . 00 __ __ __ __ __ __ __ +
Number of units . . . . 255 ___ ___ ___ ___ ___ ___ ___
________________________________Add Device____________________________
Connected to CUs . . E200 ____ ____ ____ ____ ____ ____ ____ +
4. A panel is displayed on which you can edit information for the specific devices. Make any
changes that you need, and then press Enter.
5. Now the Device / Processor Definition panel (Figure 3-13) is displayed. Type a slash mark
(/) next to the processor that you want to select. Then press Enter.
6. In the panel shown in Figure 3-14, you have the option to change the starting unit address.
Verify the value (00 is only required with the default OAT(CHPID type OSE)), and then
press Enter.
Preferred CHPID . . . . . . . . __ +
Explicit device candidate list . No (Yes or No)
__________________________________Add Device_________________________
Connected to CUs . . E200 ____ ____ ____ ____ ____ ____ ____ +
13.Repeat the process as you did for the other devices, with the exception that you must
associate the unit address FE with the OSAD device (E20F) as shown in Figure 3-16.
Press Enter.
Preferred CHPID . . . . . . . . __ +
Explicit device candidate list . No (Yes or No)
15.Type a slash mark (/) next to the operating systems that you want to select, and then press
Enter.
16.In the Define Device Parameters / Features display (Figure 3-18), provide the values for
the features you want for this device. Then press Enter.
Parameter/
Feature Value + R Description
OFFLINE No Device considered online or offline at IPL
DYNAMIC Yes Device has been defined to be dynamic
LOCANY Yes UCB can reside in 31 bit storage
OSA/SF includes a graphical user interface (GUI) and a REXX interface. The OSA/SF GUI
runs on the Windows 2000, Windows XP, and Linux software platforms that have graphics
and Java 1.4 support. For more information about using the REXX interface, refer to
Appendix D, “Using the OSA/SF REXX interface” on page 267.
From a single OSA/SF GUI, you can establish connections to all server images (logical
partitions (LPARs)) that have OSA/SF running. And you do not need to have OSA/SF running
on each server image. This potentially allows you to have centralized control of OSA-Express
features that span server boundaries, as shown in Figure 4-1. You can have GUI instances
within each server image that has OSA/SF, so you can monitor your OSA-Express features
locally.
This chapter provides instructions to help you set up OSA/SF for z/OS and z/OS.e.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 59
4.1 Setup requirements and overview
OSA/SF is required when the OSA-Express feature is configured for shared non-QDIO mode
and SNA/APPN/HPR definitions, other than for Enterprise Extender (EE). OSA/SF is also
required for the OSA-Express 155 ATM features when being configured for Ethernet or
token-ring LAN emulations (LANE, non-QDIO, and QDIO).
OSA/SF is not required for OSA-Express features that are configured in QDIO mode or when
the default IP Passthru (non-QDIO mode) is used.
Figure 4-1 shows the communication path between the user interfaces and OSA-Express
features.
REXX
REXX
OSA/SF Command
Command
GUI Line
Line
(IOACMD)
(IOACMD)
LP A LP B LP 1 LP 2 LP 3
Channel
Subsystem
OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA
This integrated version of OSA/SF is applicable to the in-service releases of z/OS, z/VM, and
VSE/ESA. In the z/OS environment, delivery is via the z/OS 1.4 zSeries 990 (z990)
Compatibility Support feature (for release z/OS 1.4) and z990 Compatibility for Selected
Releases Web deliverable (for releases z/OS 1.3).
In the z/OS environment, the integrated version of OSA/SF can coexist with OSA/SF 2.1 and
does not overlay it. The integrated version of OSA/SF for z/VM 4.4 replaces OSA/SF 2.1. In
currently supported versions or releases of z/VM and VSE/ESA, this version is delivered as a
PTF and overlays OSA/SF 2.1. The OSA/SF GUI supports only TCP/IP connections.
For information about setting up access control to OSA/SF via RACF, refer to Open Systems
Adapter-Express Customer’s Guide and Reference, SA22-7403, or zSeries: Open Systems
Adapter-Express Customer’s Guide and Reference, SA22-7935.
Reminder: The OSAD device has to be defined in HCD or IOCP to the OSA-Express
CHPID for OSA/SF-to-OSA-Express communication to work. For an HCD setup example,
see step 11 on page 56, or for an IOCDS input example go to Example 3-1 on page 58.
Note: SYS1.APPCTP is a VSAM data set. It must be allocated using job ATBTPVSM,
included in SYS1.SAMPLIB.
4. For automatic startup of the APPC environment, add the following parameters to your
COMMNDxx member of SYS1.PARMLIB, as shown in Example 4-4.
3. Restart TCP/IP or use the OBEYFILE TCP/IP subcommand to make these modifications
active.
For more information about installing OSA/SF for z/OS or z/OS.e, see the program directory.
4.3.3 Downloading and installing the Java runtime and JavaHelp files
Follow the installation instructions for downloading the latest Java runtime files (Java 1.4 or
later) and JavaHelp files (JavaHelp 1.1.2 or later) from the Internet.
The Host - Open window (Figure 4-2) allows you to connect to the OSA/SF host. When you
start the OSA/SF GUI, enter the name of the OSA/SF host system. Although the window only
allows access to a single host system, you can open multiple windows on your workstation for
other host systems.
6. Back on the OSA/SF Commands panel (Figure 4-3 on page 66), select Install.
8. Back on the OSA/SF Commands display (Figure 4-3 on page 66), select Query.
9. The Query window (Figure 4-11) opens. You can use this window to display various
information. Type the CHPID number (in our case, 0A), and then select One OSA.
10.From the OSA/SF Commands panel (Figure 4-3 on page 66), select Set Parameters.
From the OSA/SF Commands panel (Figure 4-3 on page 66), you can also perform the
following tasks:
Start managing: This causes the copy of OSA/SF that runs in the image where the
command is issued to take over management of the specified CHPID (OSA). If the CHPID
is currently managed by a copy of OSA/SF running in another image, you must set the
Force indicator (z/OS, z/OS.e, and z/VM only).
When this command completes, another copy of OSA/SF running on another image is
limited to executing commands to this CHPID that do not change the CHPID’s
environment.
Synchronize (OSA2 only): Use this command to update OSA/SF when port parameters
are changed for the OSA-2 from a source other than OSA/SF.
3. From the CHPID View window (Figure 4-15), click Selected →Open OAT Information.
The OAT Information for CHPID 0A window (Figure 4-17) shows the LPAR number and the
devices associated with the IP address. Notice that devices E200 to E202 are up and
running on image A11, which is our test LPAR.
Also notice that only one device (E203) is needed for the second TCP/IP stack running on
the same LPAR, since the read/write devices (E200 and E201) are for this CHPID. E203 is
the second datapath device defined to the TRLE.
Although Open Systems Adapter Support Facility (OSA/SF) is not required because all
definitions are set dynamically, we recommend that you use OSA/SF for monitoring and
controlling the OSA-Express port.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 79
5.1 QDIO environment
Figure 5-1 shows a logical representation of the QDIO environment that discussed in the
remainder of this chapter.
SYSTEM 1 SYSTEM 2
TCP/IP TCP/IP
VTAM VTAM
OSA-Express OSA-Express
1000BASE-T 1000BASE-T
Port 0 Port 0
ETHERNET
Switch
To determine the current MIH value for the device (E201, in our example), enter the console
command:
D IOS,MIH,DEV=E201
To set these values at IPL time, update the IECIOSxx member in PARMLIB.
Note: The discussion here is based on the OSA-Express 1000BASE-T feature. However,
the information presented holds true for all OSA-Express2 and OSA-Express features.
Figure 5-2 shows the network configuration, which consists of two z/OS systems, with a
connection to an Ethernet switch through OSA-Express 1000BASE-T CHPIDs. The
workstation has an IP address of 192.16.1.101, and the Ethernet switch has an IP address of
192.16.1.15. In this environment, the IP address of the switch is necessary only for
configuration purposes.
SC63 SC64
TCP/IP TCP/IP
192.16.1.11 IP Address 192.16.1.21
OSAE200 Device OSA2D80
VTAM VTAM
TRLE
OSAE200 LCSS 0 OSAname OSA2D80
OSAE200 Portname OSA2D80
z/OS z/OS
CHPID 0A CHPID 0B
Ethernet
Switch
IP Address
192.16.1.15
IP Address
192.16.1.101
Multiple LPARs with only one TCP/IP stack per LPAR sharing only one
OSA-Express CHPID
Note the following requirements:
Only one TRLE is needed in each LPAR that contains only one datapath address. The port
name in the TRLE must be the same across the LPARs.
Each TCP/IP DEVICE name must match the port name in the TRLE.
Multiple LPARs with only one TCP/IP stack per LPAR sharing multiple
OSA-Express CHPIDs
Consider an example that has three OSA-Express CHPIDs. They must meet the following
requirements:
Three TRLEs are needed in each LPAR, and contain only one datapath address. For each
single OSA-Express CHPID, the port name in the TRLE must be the same across the
LPARs, but it must be unique across the OSA-Express ports.
Each TCP/IP stack has three DEVICE and LINK statements. Each DEVICE statement
must match the port name of the associated TRLE.
Multiple LPARs with multiple TCP/IP stacks per LPAR sharing multiple
OSA-Express CHPIDs
Consider an example with three OSA-Express CHPIDs and two TCP/IP stacks per LPAR.
They must meet the following requirements:
Three TRLEs are needed in each LPAR, containing two datapath addresses. For each
single OSA-Express CHPID, the port name must be the same across the LPARs, but must
be unique for each OSA-Express CHPID.
Each TCP/IP stack has three DEVICE and LINK statements. Each DEVICE statement
must match the port name of the associated TRLE.
VTAM in each LPAR assigns one datapath address to each TCP/IP stack in the same
LPAR.
Table 5-1 lists and describes the definitions used in the TRL major node for SC63 (these also
apply for SC64).
TYPE=TRL TRL major node MPC TRL major node known to VTAM.
OSAE200 TRLE minor node The name of the TRLE in VTAM for SC63. This name is downloaded to
OSA-Express and is used as OSANAME.
READ=E200 Read device The Read device number must be the even number of the device pair.
The Read Write pair of the OSA-Express port is used only to exchange
control information.
WRITE=E201 Write device The Write device number must be the odd number of the device pair.
The Read Write pair of the OSA-Express port is used only to exchange
control information.
DATAPATH=E202 Data device The device address of DATAPATH of each OSA-Express port. For QDIO,
this device is used for the data transfer in both directions. More than one
address can be defined, depending on throughput.
PORTNAME = PORTNAME associated PORTNAME must match the TCP/IP device name in the TCP/IP profile
OSAE200 with the devices for this connection. The association between TCP/IP and VTAM is done
through the PORTNAME.
MPCLEVEL= MPC compatibility level This indicates that the QDIO interface is used for the OSA-Express port.
QDIO
Note: In the TCP/IP profile, link type IPAQENET is used for all OSA-Express2 and
OSA-Express Ethernet features. For the OSA-Express Token Ring feature, the link type
must be defined as IPAQTR in the TCP/IP profile.
HOME
192.16.1.11 E200LNK
BEGINROUTES
ROUTE 192.16.1.0/24 = OSAE200LNK MTU 1492
ENDROUTES
START OSAE200
Example 5-4 shows the TCP/IP profile definitions for the OSA-Express port (OSA2D80) for
SC64.
HOME
192.16.1.21 2D80LNK
BEGINROUTES
ROUTE 192.16.1.0/24 = 2D80LNK MTU 1492
ENDROUTES
START OSA2D80
BEGINROUTES statement: If you are migrating your TCP/IP profile from an earlier
release, the profile may use the GATEWAY statement to define static routes instead of the
BEGINROUTES - ENDROUTES statements. GATEWAY is recognized and used, but
consider replacing it with BEGINROUTES.
We recommend that you use the BEGINROUTES method to define static routes for the
following reasons:
It is compatible with UNIX standards.
It is easier to code than GATEWAY.
It accepts both IPv4 and IPv6 addresses.
It has enhanced functionality.
Future static route enhancements will only be available with the BEGINROUTES
statement.
Normally the CHPID should be online. If the CHPID is offline, configure it online using the
following command:
CF CHP(0A),ONLINE
After all the definitions are added to OSA/SF, VTAM, and TCP/IP, you can activate the
configuration. Activation may require several tasks, such as:
Verifying that the devices are online
Activating an OSA/SF configuration
Activating the VTAM resources
Activating TCP/IP
If the devices are not online, use the z/OS console vary command:
V (E200-E202),ONLINE
After activating the TRL, the status of the TRLE is NEVAC or INACT until TCP/IP refers to it.
When the TCP/IP device is started, configuration information (for example, HOME IP
address) is downloaded to the OSA-Express.
Important: You cannot determine the devices used by TCP/IP from the field DevNum:
0000. You must display the VTAM TRLE to see the devices.
Notice the new addition to the NETSTAT output of ArpOffload in Example 5-6 and
Example 5-7. This indicates that the OSA-Express port supports Address Resolution Protocol
(ARP) offload (ARP caching on the feature) and that the ARP information can be retrieved via
NETSTAT ARP or through Simple Network Management Protocol (SNMP).
Example 5-9 shows the TRLE of the active OSA-Express 1000BASE-T on system SC64.
Note that message IST1717I shows the job name that uses this TRLE (in our case, TCPIPA).
Tip: If your static TRLE definition is incorrect, be aware that an active TRLE entry cannot
be deleted. Vary activate the TRL major node with a blank TRLE to cause the deletion of
previous entries. Then code the TRL major node with the correct TRLE entry and
definitions, and vary activate the TRL/TRLE node. Consider this blank entry example:
OSAE200 VBUILD TYPE=TRL
TRLE LNCTL=MPC,
READ=E200,
WRITE=E201,
DATAPATH=(E202),
PORTNAME=OSAE200,
MPCLEVEL=QDIO
OSA2: The procedures in this chapter deal with configuring an OSA-Express port.
However, you can use these same procedures to configure an OSA-2 port, with the
exception of the Hardware Configuration Definition (HCD), channel path identifier (CHPID)
type OSE.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 91
6.1 Default mode
Figure 6-1 shows a functional view of the connectivity as discussed in this chapter.
LPAR 1 LPAR 2
TCP/IP TCP/IP
Channel Subsystem
Port 0
Ethernet
Switch
For this example, we use the 1000BASE-T OSA-Express, CHPID type OSE, in default mode.
When an OSA-Express feature is manufactured, a basic configuration is installed that permits
some functionality without the need to build and load an OSA Address Table (OAT).
The default mode permits “passthru” functionality only. One use for this mode is in a new
installation, where you can establish that HCD and network connections are correct without
the added complication or concern of whether there is a configuration error in the OAT.
The System z9 or zSeries server sees the 1000BASE-T OSA-Express port as a LAN
Channel Station (LCS) device. An LCS device handles data traffic in either direction for any
TCP/IP partition that has an OSA-Express port defined.
The OSA/SF GUI must be connected to a z/OS host that has OSA/SF running. In addition,
the OSA CHPID must be defined by HCD, and the HCD must be activated. This step does not
require the CHPID to be installed or online. It only creates and saves an OSA-Express
configuration.
1. Start the OSA/SF GUI program:
a. Open a DOS window.
b. Enter the following command:
java IOAJAVA
c. At the prompt, type your password to obtain a connection.
2. In the Workstation Interface window, in the right panel under OSA/SF Commands, select
CHPID View.
a. On the Settings tab (Figure 6-3), you see that the CHPID is TCP/IP Passthru (OSE),
shared, and the processor code level is displayed (06.16).
4. Return to the CHPID View window, and click Selected →Open Device Information. Now
the unit addresses are displayed with their own status, as shown in Figure 6-5.
When the CHPID is dedicated to only one partition, LPAR 0 is unique in that this value is used
to identify that an OSE CHPID is dedicated. Regardless of the LPAR to which the OSE
CHPID may be dedicated, the LPAR number used is always 0.
Non-QDIO OSA-Express ports are defined to TCP/IP as LCS devices. You must assign an IP
address by coding an entry for the LINK name in the HOME statement. Depending on your
network design, you also need to code a route entry. OSA-Express can be activated via the
TCP/IP profile, using a START statement.
CHPID 0C
T HOME IP 00-01
L
C 192.16.1.24
P P 100 Mbps Ethernet
A / Switch
DEVICE
R I
2E40,2E41
P
OSAD, UA FE
S
C
6
4
Workstation
"FE" DEVICE 192.16.1.110
OSA/SF 2E4F
We defined:
One DEVICE statement per OSA-Express Port, with the even device number of the two
device addresses assigned to the hardware for the port
Note the following considerations:
– Even though you define only one port, you use two device numbers per OSA-Express
Port for TCP/IP Passthru mode. One device is used by TCP/IP for reading, and the
other device is used for writing.
– Using the DEVICE statement, you define the DEVICE name, the DEVICE type (LCS)
for the OSA-Express Port, and the DEVICE number (the read device number, which is
the even device number).
One LINK statement per OSA TCP/IP DEVICE statement
Using the LINK statement, you define the LINK name, the LINK type (in our example,
ETHERNET), the PORT number, and the DEVICE name.
Although the OSA Express Port is known by the device number, the port number in the
LINK statement must match the actual OSA Express Port number. With OSA-Express
1000BASE-T, the port is always zero.
Note: We defined the link type ETHERNET. If the OSA-Express card is token ring, you
must define the link type IBMTR. Although the OSA-Express Port is addressed by the
device number, the port number in the LINK statement must match the actual
OSA-Express Port number.
BEGINROUTES statement: If you are migrating your TCP/IP profile from an earlier
release, the profile may use the GATEWAY statement to define static routes instead of
the BEGINROUTES - ENDROUTES statements. GATEWAY is recognized and used,
but consider replacing it with BEGINROUTES.
We recommend that you use the BEGINROUTES method to define static routes for the
following reasons:
It is compatible with UNIX standards.
It is easier to code than GATEWAY.
It accepts both IPv4 and IPv6 addresses.
It has enhanced functionality.
Future static route enhancements will be available only with the BEGINROUTES
statement.
Figure 6-8 shows the TCP/IP profile definitions that we used to define OSA to TCP/IP for
LPAR SC64.
HOME
192.16.1.24 2E40LNK
BEGINROUTES
ROUTE 192.16.1.0/24 = 2E40LNK MTU 1492
ENDROUTES
START OSA2E40
6.5 Activation
Activation may require several tasks, such as:
Ensuring the devices are online
Activating an OSA/SF configuration
Activating VTAM resources
Activating TCP/IP
If the devices are not online, enter the z/OS console vary command:
V (2E40-2E41),ONLINE
We confirm the status of the TCP/IP devices using the NETSTAT DEV command as shown in
Figure 6-9. Note that both the device and the link are in READY status.
OSA-2: The procedures in this chapter deal with configuring an OSA-Express port.
However, you can use these same procedures to configure the OSA-2 port, with the
exception of the Hardware Configuration Definition (HCD), channel path identifier (CHPID)
type OSA.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 101
7.1 Configuration information
Figure 7-1 shows a functional view of the connectivity discussed in this chapter.
LPAR 1 LPAR 2
TCP/IP TCP/IP
VTAM VTAM
Channel Subsystem
OAT Table
OSA-Express
1000BASE-T Connectivity definitions:
Port 0
- TCP/IP Passthru
- SNA
Ethernet
Switch
The OSA-Express configuration file contains the OSA Address Table (OAT). The OAT maps
the LPAR, mode, unit address, and IP address to an OSA-Express port. The OSA-Express
port is defined as a local area network (LAN) Channel Station (LCS) device to TCP/IP. The
OAT configuration enables the OSA-Express to associate different IP addresses in separate
LPARs with the same OSA-Express port.
VTAM sees the OSA-Express port as an external communications adapter (XCA). One
OSA-Express port is linked to one device for SNA operation.
When the Activate command is issued from OSA/SF, the OSA configuration transfers the
SNA configuration and downloads the OAT to the OSA-Express by using the FE unit address
(OSAD device). After the SNA mode settings and OAT are downloaded, the OSA-Express
CHPID is automatically configured offline to all systems and then configured online. This
causes the OSA-Express hardware to be reset. It also activates the new OSA-Express
configuration or OAT.
Example 7-1 shows the IOCDS definitions used for CHPID 0C. In our configuration, we use
LPAR A11 (SC64), which is MIF ID 1 in CSS 1. The MIF ID and CSS values (1.1) are used in
the OSA/SF setup (Image number field in Figure 7-5 on page 107). For future considerations,
we also define 15 OSA devices, although only three are needed in our configuration.
T HOME IP DEVICE
L
C
P P 192.16.1.20 2E40,2E41 LPAR IODEVICE IP Address/SAP Port
C A XCAOSA63 2E4A
6 M CHPID 0C
3
"FE" DEVICE
OSA/SF UA Port
2E4F
00-01 Ethernet
0
0A 100 Mbps Switch
T HOME IP DEVICE
L
C
P P 192.16.1.24 2E40,2E41
OSAD, UA FE
A /
R I
P
4
"FE" DEVICE
OSA/SF 2E4F
The OSA/SF GUI must be connected to a z/OS host that has OSA/SF running. The
OSA-Express CHPID must also be defined by HCD and activated. This step does not require
the CHPID to be installed or online, but only creates and saves an OSA-Express port
configuration.
To create (add) and save the OSA-Express configuration using the OSA/SF GUI, follow these
steps.
1. Start the OSA/SF GUI program:
a. Open a DOS window.
b. Enter the following command:
java IOAJAVA
c. At the prompt, type your password to obtain a connection.
2. In the Workstation Interface window, in the right panel under OSA/SF Commands, select
CHPID View.
Note: If the OSA-Express CHPID is not defined to the server’s channel subsystem
(meaning that it is not in the list), or if the OSA-Express feature is not installed, select
the Planning configuration option instead of the Configuration option.
4. In the Configuration list for CHPID 0C panel (Figure 7-4), click Add to create a new
configuration. Then complete the following fields:
a. In the Configuration name entry field, enter a configuration name. This is the name that
is displayed in the configuration list panel.
b. Optionally, in the User data field, enter comments. This field has no effect on the
operation of the OSA-Express. However, a short description of what this configuration
is designated for can be useful later.
c. For Local MAC address, we select Use Universal. For Group MAC address, we use
the default of zeros. For your site, check the local networking standards for the correct
values.
d. A port name is required, and can be up to eight characters in length. Like the User data
field, this is not used by OSA-Express specifically. The value for Port name should not
duplicate other port names in your network.
e. For Port speed, we select Auto negotiate. This allows the OSA-Express to
automatically set its speed to the speed of the LAN to which it is connecting. If you set
port speed to a specific value, ensure that the LAN is also capable of this speed.
f. To configure the port for TCP/IP and SNA traffic, select the box for each protocol type.
Note: High Performance Data Transfer (HPDT) Multipath Channel (MPC) mode is
not a supported option for System z9 or zSeries servers.
Reminder: If you are using a CHPID dedicated to one LPAR, the LP number must
be 0.
b. For Even unit address, enter the address for this port. The unit address can be any
even address, but unit address 00,01 is associated with OSA-Express port 0 in the
default OAT. For this example, we type 00.
Note: The OSA-Express port unit address was used by HCD in Chapter 3,
“Hardware configuration definitions” on page 47, when defining the OSA devices.
c. For Default entry indicator, you can select Primary for one of the LPARs using this port.
The LPAR designated as the Primary receives any datagrams that are not specifically
addressed to any of the home IP addresses associated with this OSA-Express port.
See 1.2.2, “Primary/secondary router function” on page 10, for more information.
d. In the Home IP address box, enter the home IP address 192.16.1.24 for LPAR SC64.
e. Click Add to add this definition to the OSA/SF OAT.
2. The SNA OAT Entry Definition window (Figure 7-8) is used to assign a single unit address
to each OSA-Express port for every LPAR that accesses the port. In SNA mode, each
OSA-Express port that VTAM is sharing must have a unique SAP address.
Complete the following steps:
a. Enter the LP number of the LPAR, or for a z9-109, z990, or z890, enter the MIF ID and
CSS value that will use the port. In our example, LPAR A11 (SC64) on our z990 has an
Image number of x’1.1’ for CHPID 0C (see Example 7-1 on page 103). To determine
the LPAR number or MIF ID and CSS value, refer to your IOCDS.
Reminder: If you were using a CHPID dedicated to one logical partition, the LP
number must be 0.
Note: Defining multiple LPARs to use the same port is known as a shared port. In
SNA mode, no additional information is required in the OAT definition. This is unlike
TCP/IP Passthru mode, which requires the IP address to be added to the OAT.
Shared port is only possible when the VTAMs that are sharing the OSA port each
use a unique SAP address. Enter the unit address for this port.
3. In the OSA Configuration window, from the menu bar, select File →Save configuration
as shown in Figure 7-9.
The data set name on the host is hlq.P601.OSASF.CFGxxxx. Note that hlq is the data set
qualifier specified in the OSA/SF startup profile, and xxxx is a number from 1 to 9999.
Message IOAK000I is displayed when the configuration data is successfully saved on the
z/OS host.
The OAT information from the selected configuration is reformatted and saved in the OSA
configuration file. An OSA/SF installation action is done to download any required files
(specified in the OSA/SF config) and the OAT contained in the OATFILE data set.
Reminder: You may want to use an LAA in place of the universal address for SNA, as
discussed earlier.
Each workstation connecting to the OSA-Express port through SNA must have the
MAC address of the OSA-Express port defined. If the OSA-Express feature is replaced,
it is much easier to change the MAC address on the OSA-Express feature, rather than
to change all workstation profiles to point to the new universal MAC address of the new
feature. You can change the MAC address of the OSA-Express feature through
OSA/SF by using the configuration panels or OSA Advanced Facilities of the HMC.
***********************************************************************
* *
* XCA MAJNODE for 1000BASE-T OSA-Express *
* *
***********************************************************************
XCAOSA63 VBUILD TYPE=XCA
OSASNAM PORT MEDIUM=CSMACD, X
ADAPNO=0, X
CUADDR=2E4A, X
TIMER=60, X
SAPADDR=04
***********************************************************************
OSASNAG GROUP DIAL=YES, X
DYNPU=YES, X
ANSWER=ON, X
AUTOGEN=(3,L,P), X
CALL=INOUT, X
ISTATUS=ACTIVE
******************************** Bottom of Data************************
TYPE=XCA XCA major node The OSA functions such as an XCA to VTAM.
CUADDR= Channel unit address The code the device number defined for this port. In our
2E4A example, SC63 uses device number 2E4A for port 0.
MEDIUM= LAN type Use RING for token ring, or CSMACD for Ethernet.
CSMACD
SAPADDR=04 Service access point Code a value that is a multiple of 4. This address must
address be unique for each VTAM communicating with a port. Use
different SAP addresses if a port is shared by multiple
VTAMs. See the SAPADDR value of XCAOSA64.
Note: We defined the medium CSMACD. If the OSA card is token ring, you must define the
medium type RING.
DIAL=YES Switched peripheral You must code DIAL=YES to specify that the switched line
node control protocol is required.
Note: The current OSA-Express features support 4096 SNA PU Type 2 connections per
port on System z9 and zSeries servers.
***********************************************************************
* *
* XCA MAJNODE for 1000BASE-T OSA-Express *
* *
***********************************************************************
XCAOSA64 VBUILD TYPE=XCA
OSASNAM PORT MEDIUM=CSMACD, X
ADAPNO=0, X
CUADDR=2E4A, X
TIMER=60, X
SAPADDR=08
***********************************************************************
OSASNAG GROUP DIAL=YES, X
DYNPU=YES, X
ANSWER=ON, X
AUTOGEN=(3,L,P), X
CALL=INOUT, X
ISTATUS=ACTIVE
******************************** Bottom of Data************************
Figure 7-14 SNA mode XCA major node definition for XCAOSA64
Table 7-3 shows the only parameter that is different between XCAOSA63 and XCAOSA64.
SAPADDR=08 Service access point Since port 0 is shared with SC63, a different SAP
address address of 8 is used.
Table 7-4 lists the important parameters in the LU definition for SWOSA63.
MODETAB=MTAPPC Logon mode table Code a separate logon mode table for
APPC.
Figure 7-2 on page 104 shows the network and the connections for our configuration
example. Port 0 is connected to an Ethernet LAN, using IP address 192.16.1.20 for LPAR
SC63 and IP address 192.16.1.24 for LPAR SC64.
Note: We defined the link type ETHERNET. If the OSA-Express card is token ring, you
must define the link type IBMTR. Although the OSA-Express port is addressed by the
device number, the port number in the LINK statement must match the actual
OSA-Express port number.
BEGINROUTES statement: If you are migrating your TCP/IP profile from an earlier
release, the profile may use the GATEWAY statement to define static routes instead of
the BEGINROUTES - ENDROUTES statements. GATEWAY is recognized and used,
but consider replacing it with BEGINROUTES.
We recommend that you use the BEGINROUTES method to define static routes for the
following reasons:
It is compatible with UNIX standards.
It is easier to code than GATEWAY.
It accepts both IPv4 and IPv6 addresses.
It has enhanced functionality.
Future static route enhancements will be available only with the BEGINROUTES
statement.
HOME
192.16.1.20 2E40LNK
BEGINROUTES
ROUTE 192.16.1.0/24 = OSA2E40LNK MTU 1492
ENDROUTES
The configuration for LPAR SC64 is exactly the same with one exception, that the HOME
statement is coded to reflect the different IP address:
HOME
192.16.1.24 2E40LNK
7.5 Activation
After all the definitions are added to OSA/SF, VTAM, and TCP/IP, we can activate the
configuration. Activation may require several tasks, such as:
Verifying the devices are online
Activating VTAM resources
Activating TCP/IP
D U,,,2E40,2
IEE457I 21.29.17 UNIT STATUS 836
UNIT TYPE STATUS VOLSER VOLSTATE
2E40 OSA O
2E41 OSA O
D U,,,2E4A,1
IEE457I 21.32.17 UNIT STATUS 936
UNIT TYPE STATUS VOLSER VOLSTATE
2E4A OSA O
If they are not online, enter the z/OS console vary command:
V (2E40,2E41,2E4A),ONLINE
D NET,ID=XCAOSA64,E
IST097I DISPLAY ACCEPTED
IST075I NAME = XCAOSA64, TYPE = XCA MAJOR NODE 092
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1021I MEDIUM=CSMA/CD,ADAPNO= 0,CUA=2E4A,SNA SAP= 8
IST1885I SIO = N/A SLOWDOWN = N/A
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST170I LINES:
IST232I L2E4A000 NEVAC
IST232I L2E4A001 NEVAC
IST232I L2E4A002 NEVAC
Figure 7-18 shows the results from the switched major node.
D NET,ID=SWOSA64,E
IST097I DISPLAY ACCEPTED
IST075I NAME = SWOSA64, TYPE = SW SNA MAJ NODE 104
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I OSA64P TYPE = PU_T2 , CONCT
IST089I OSA64L1 TYPE = LOGICAL UNIT , CONCT
IST089I OSA64L2 TYPE = LOGICAL UNIT , CONCT
IST314I END
To verify that a connection exists, we performed a ping from one TCP/IP stack to the other.
Refer to Appendix A, “Commands” on page 237, for a list of other useful commands.
OSA-2: The procedures in this chapter deal with configuring an OSA-Express feature.
However, you can use these same procedures to configure the OSA-2 version of this
feature, with the exception of the Hardware Configuration Definition (HCD), channel path
identifier (CHPID) type OSA.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 123
8.1 Configuration information
In our environment, we created a configuration to run in native mode with two ATM features
on two different systems. Figure 8-1 shows the logical connectivity. We guide you through the
steps required to:
Create a new OSA Address Table (OAT) using the graphical user interface (GUI)
Create VTAM definitions to support this configuration
Create TCP/IP definitions to support this configuration
SYSTEM 1 SYSTEM 2
TCP/IP TCP/IP
XCA XCA
SWN SWN
VTAM VTAM
Port 0 Port 0
ATM Switch
T HOME IP DEVICE
L
C OSEF6
P P 10.11.41.220
PORTF6
A /
R I
P
ATM
V TRL NODE PORTNAME CHPID F6
S T PORTF6 OSEF6
3 A TRLE DEVICE nat.
UA
M OSEF6 OE90-OE91 Port
5
90
XCA NODE DEVICE 0
91
XCAATMF6 PORTF6
Creating (adding) and saving an OSA feature configuration is not disruptive. The OSA/SF
GUI code must be connected to a z/OS host which has OSA/SF running. This step does not
require the CHPID to be installed or online.
Create and save an OSA feature configuration using the following steps:
1. Start the OSA/SF GUI program.
a. Double-click the OSA/SF folder icon.
b. Double-click the OSA/SF program icon.
2. Start the OSA/SF host connection. Double-click the icon previously created to connect
your workstation to the host OSA/SF, and log on.
Note: If the OSA CHPID is not defined to the server’s channel subsystem (that is,
not in the list), or if the OSA feature is not installed, use the Planning configurations
option instead of the Configuration list option.
4. In the Configuration list that is displayed, click Add to create a new configuration.
5. In the Configuration window (Figure 8-4), follow these steps:
a. In the Configuration name entry field, type a configuration name. This is the name that
is displayed in the configuration list panel.
b. For Use this port in the configuration, click Yes to make sure that the physical port
changes are used. If you are configuring partial activation on an OSA-Express 155
ATM feature with ports previously configured, select No.
c. Optionally, in the Port description field, you can enter information. This field has no
effect on the operation of the OSA. However, providing a short description of what this
physical port is designed to achieve can be useful later.
d. The value in the Port name field must match the portname value of the TRLE
statement and the port name in the device statement of the TCP/IP profile. If SNA is
used, it must also match the portname value in the XCA. It can be up to eight
non-blank characters in length.
e. The Local end system ID (ESI) field is used to override the default of the universal
system ID that was IBM-supplied for this ATM port, with a locally administered
system ID.
f. For the other fields of the physical port configuration panel, check the documentation of
the ATM switch to which this ATM OSA-Express is attached, to ensure that the correct
settings are used.
6. Click the HPDT ATM native port 0 tab or click the right arrow in the upper right corner of
the notebook until HPDT MPC native port 0 - Page 1 of 2 entries is displayed.
a. For the Include in this configuration and Enable LAN traffic entries, select Yes. Then
click Add.
b. In the MPC OAT Entry Definition window (Figure 8-5), complete the following steps:
i. Specify an MPC OAT entry for this mode. The OSA name specified must match the
name of the TRLE in the TRL macro. It must also match the DEVICE and START
statements in the TCP/IP profile. The OSA name can be the same for different
partitions, but must be unique if you use more than one device pair address in the
same logical partition.
Reminder: If you are using a CHPID dedicated to one partition, the LP number
must be 0.
7. Click the right arrow in the upper right corner of the notebook until you see HPDT MPC
native port 0 - Page 2 of 2.
8. In the PVC Definition window, click Add to configure your permanent virtual circuits
(PVCs) for your environment.
We configured two PVCs, one for TCP/IP and one for SNA traffic. Note the following
points:
– PVCs are required only if you are establishing a PVC between the OSA port and the
ATM switch.
– Switched virtual circuits (SVCs) are not defined. These are built dynamically.
Figure 8-7 shows our settings for the PVC that is used for the TCP/IP traffic.
a. Fill in the PVC name. The PVC name must match the name of the ATMPVC statement
in the TCP/IP profile.
b. Identify each PVC with a unique virtual path indicator (VPI) and virtual channel
indicator (VCI) value. These values must agree with the VPI and VCI values assigned
in the ATM switch.
The VPI value can be 0 through 15. For each PVC, specify a VCI value from 32 through
8191.
3. From the Configuration window (Figure 8-8), select Configurations →Activate (no
install). Activate (no install) prevents disrupting an OSA that is already running with a
different configuration. You can defer the install to a more appropriate time.
TYPE=TRL TRL major node MPC TRL major node known to VTAM.
OSEF6 TRLE minor node This name must match the OSA name defined in the
OSA-Express ATM feature’s MPC OAT entry and the
DEVICE name in the TCP/IP profile.
READ=E90 Read device number Code the read device number defined for this port (port 0)
(even number of the and the related OSA name definition. In this example,
device pair) S35 uses device number 0E90 for port 0 and OSA name
OSEF6.
WRITE=E91 Write device number Code the write device number defined for this port (port
(odd number of the 0) and the related OSA name definition. In this example,
device pair) S35 uses device number 0E91 for port 0 and OSA name
OSEF6.
PORTNAME= PORTNAME coded The PORTNAME used in the TRLE must match the
PORTF6 in this TRLE PORTNAME definition used in the TCP/IP profile, the port
name in the ATM physical port panel of OSA/SF, as well
as the port name for the XCA major node if using SNA.
HOME
10.11.41.240 ATMPVCF6 ; FOR THE PVC.
10.11.41.241 ATMSVCF6 ; FOR THE SVC.
BEGINROUTES
10.0.0.0/8 = ATMPVCF6 MTU 4096 ; For the PVC
10.11.41.231 HOST = ATMSVCF6 MTU 9180 ; For the SVC
ENDROUTES
START OSEF6
Table 8-2 shows the interdependencies between the OSA-Express 155 ATM feature
configuration, the TCP/IP profile, and the TRLE statements in VTAM listed.
OSEF6 TCP/IP device name = This name must match the OSA name defined in
OSA name OSA-Express ATM feature’s MPC OAT entry and the TRLE
name.
PORTF6 Portname The PORTNAME in the TCP/IP profile must match the
PORTNAME value used in the TRLE and the port name in
the OSA configuration.
PVCF6IP PVC name The PVC name specified in the OSA native port
configuration for TCP/IP and the ATM switch.
We recommend that you use the BEGINROUTES method to define static routes for the
following reasons:
It is compatible with UNIX standards.
It is easier to code than GATEWAY.
It accepts both IPv4 and IPv6 addresses.
It has enhanced functionality.
Future static route enhancements will only be available with the BEGINROUTES
statement.
Table 8-3 describes the required statements for the TCP/IP profile used for ATM native mode
IP traffic.
ATMLIS ATM logical IP subnet This statement is needed to describe the characteristics
(LIS) of the LIS. The LIS is used with ATM Classic IP (CIP).
DEVICE TCP/IP device name The device name must match the TRLE name and the
OSA name in the OSA configuration.
LINK Link name Links must be specified for PVCs and SVCs separately.
The SVC Link requires an ATMLIS statement defining the
subnet and mask.
ATMARPSV ATMARP server for This defines the IP address and ATM address of the
CIP ATMARP server using information provided by the
ATMLIS statement.
HOME IP home address This specifies the home addresses for the defined SVC
and PVC links.
BEGINROUTES static route definition We defined the home IP address of the corresponding
SVC in the other system, because we are not using
dynamic routing.
Table 8-4 lists the relevant definitions used in the XCA major node.
PORTNAME= Name of the This is required for native ATM support. It has to match
PORTF6 port connecting PORTNAME in the TRLE definition and the port name in the
to OSA configuration.
PVCNAME= Name of PVC PVCNAME has to match the name defined in the OAT.
PVCF6SNA registered in the
ATM switch
HPR=YES Enable HPR for HPR is required for native ATM support.
this connection
TYPE=SWNET Switched Major Used to establish a switched connection with the PVC and SVC.
DLCADDR= ATM partner The last three groups of the numbers represent the ATM that
Interface you connect to. The last two digits represents the selector.
When you connect to a CMOS system, the first of these two
digits is the LPAR number minus 1. The 12 digits just prior to the
selector is the Local System Identifier (LSI) or MAC address.
8.5 Activation
After all the definitions are added to OSA/SF, VTAM and TCP/IP, you can activate the
configuration. Activation may require several tasks, such as:
Verifying the devices are online
Activating an OSA/SF configuration
Activating VTAM resources
Activating TCP/IP
If they are not online, enter the z/OS console vary command:
V (E90,E91),ONLINE
After activation of the TRL, the status of the TRLE is NEVAC or INACT until TCP/IP refers to it
or the XCA major node is activated.
Note that we split the PVC and SVC displays into two parts. TCP/IP displays it as one display.
Figure 8-10 shows the status of the PVC after activation. The PVC Status and LnkStatus
must be READY.
Figure 8-10 NETSTAT DEVLINKS for the native ATM PVC link
Figure 8-11 NETSTAT DEVLINKS for the native ATM SVC link
Note: If your static TRLE definition is incorrect, be aware that an active TRLE entry cannot
be deleted. You can vary activate the TRL node with a blank TRLE to cause the deletion of
previous entries. Then code the correct TRL with correct TRLE entries and definition and
vary activate this corrected TRL/TRLE node. See Table A-3 on page 239 for the vary
commands.
We activated the SNA resources for ATM with the following commands:
V NET,ACT,ID=XCAATMF6
V NET,ACT,ID=SWATMF6
We displayed the XCA major node to establish SNA connectivity, as shown in Figure 8-13, by
using the following command:
D NET,ID=XCAATMF6,E
Figure 8-13 Display of XCA major node for SNA on the ATM native mode
Figure 8-14 Display of active line for the native ATM connection
We displayed the status of PU, as shown in Figure 8-15, by using the following command:
D NET,ID=F6APU1
Then we established a dial connection, as displayed in Figure 8-16, by using the following
command:
V NET,DIAL,ID=SWF6PU1
Figure 8-17 Display of active switched PU for native the ATM connection
OSA-2: The procedures in this chapter deal with configuring an OSA-Express feature.
However, you can use these same procedures to configure the OSA-2 version of this
feature, with the exception of the Hardware Configuration Definition (HCD), channel path
identifier (CHPID) type OSA.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 141
9.1 Configuration Information
In our environment, we created a configuration to run in LANE mode with two partitions, both
using TCP/IP and SNA. Figure 9-1 shows the logical connectivity. We guide you through the
steps required to:
Create a new OSA Address Table (OAT) using the graphical user interface (GUI)
Create TCP/IP definitions to support this configuration
Create VTAM SNA definitions to support this configuration
LPAR 1 LPAR 2
TCP/IP TCP/IP
VTAM VTAM
Channel Subsystem
OAT Table
LAN
environment
TCP/IP Connections
C
L P
HOME IP DEVICE
P / 10.11.41.210 9E0,9E1
I
A P
10.11.42.210
9E2,9E3 Part IODEVICE IP Address Port
R
S30 09E0 10.11.41.210 0
V
T
XCA Node
A XCA309EA
DEVICE
9EA
OAT S30 09E2 10.11.42.210 1
S M
S35 09E0 10.11.41.220 0
3 XCA309EB 9EB ATM S35 09E2 10.11.42.220 1
0 CHPID F6
"FE" DEVICE
OSA/SF UA log.
9EF
Port
00-01
T 0A 0 155 Mbps ATM
C HOME IP DEVICE
L 02-03 SWITCH
P
0B
1
P / 10.11.41.220
9E0,9E1
I
A P
10.11.42.220
9E2,9E3 OSAD, UA FE
R
ATM LAN Bridge
V XCA Node DEVICE
T
A XCA359EA 9EA
S M Ethernet
3 XCA359EB 9EB
10.11.41..xxx
Token Ring
5
"FE" DEVICE 10.11.42.xxx
OSA/SF
9EF
Creating (adding) and saving an OSA-Express feature configuration is not disruptive. The
OSA/SF GUI code must be connected to an z/OS host which has OSA/SF running. This step
does not require the CHPID to be installed or online to create and save the OSA-Express
feature configuration.
1. Start the OSA/SF GUI program:
a. Double-click the OSA/SF folder icon.
b. Double-click the OSA/SF program icon.
2. Start the OSA/SF host connection. Double-click the icon previously created to connect
your workstation to the host OSA/SF and log on.
Note: If the OSA CHPID is not defined to the server’s channel subsystem (that is,
not in the list), or if the OSA feature is not installed, use the Planning option instead
of the Configurations option.
4. The Configuration list for CHPID F6 is displayed. Click Add to create a new configuration.
5. In the Configuration window (Figure 9-4) that opens, complete the following steps:
a. In the Configuration name entry field, enter a configuration name. This is the name that
is displayed in the configuration list panel.
b. For Use this port in the configuration, select Yes to make sure that the physical port
changes are used. If you configure for partial activation on an OSA-Express 155 ATM
feature with ports previously configured, choose No.
c. Optionally, in the Port description field, you can enter configuration information. This
field has no effect on the operation of the OSA, but a short description of what this
physical port is designed to achieve can be useful later.
d. A port name is required and can be up to eight characters in length. Like the User data
field, this is not used by OSA specifically. The value here should not duplicate other
port names in your network.
e. The Local end system ID (ESI) field is used to override the default of the universal
system ID, which was IBM-supplied for this ATM port, with a locally administered
system ID.
f. For the other fields of the physical port configuration panel, check the documentation of
the ATM switch to which this ATM OSA-Express is attached to ensure that the correct
settings are used.
6. Click the right double arrow in the upper right corner of the notebook until you see ATM
LEC port 0 at the top of the workbook. Then select the ATM LEC port 0 tab. We skip the
HPDT ATM native port 0 tab because it is not required for this configuration.
7. In the ATM LEC port 0 (Implementation values) - page 1 of 5 page (Figure 9-5), complete
the following steps:
a. For both the Include in this configuration and Enable LAN traffic fields, select Yes.
b. Optionally, in the User data field, you can enter information. This field has no effect on
the operation of the OSA, but a short description of what this logical port is designed to
achieve can be useful later.
c. The Local MAC address field is used to override the default of the universal MAC
address, which was IBM-supplied for this logical port, with a locally administered MAC
address.
d. For LAN type, select the type of LAN to which this port will connect.
e. For Maximum LAN frame size, specify one of the following values for any of the
emulated LAN types:
• 1516 bytes, which is the default for an Ethernet LAN
• 4544 bytes, which is the default for a 4 Mbps token-ring LAN
• 9234 bytes, which is a standard in LAN emulation Over ATM, which is published by
the ATM Forum
• 8190 bytes, which is the default for a 16 Mbps token-ring LAN
Note: We used the automatic configuration of the LEC port by the LAN emulation
configuration server (LECS).
If you do not have a LECS, you must provide the 20 byte ATM address of the LES.
Note: You can fill in multiple IP addresses and specify the entry used as a
primary or secondary. For further information about this IP availability function,
see 1.2.9, “Enhanced IP network availability” on page 16.
ii. After you finish the Home IP address list entries for the LP number and unit address
combination, click Add. This stores the record information in the OAT.
iii. After you store all your necessary IP addresses, click Cancel.
Figure 9-9 ATM LEC port 0 SNA values: Page 4 of 5 (set for token ring)
12.Click the right arrow again and you return to the starting panel for the definitions for logical
port 1. At this point, if you want to configure both logical ports, you must repeat all steps
starting from step 6 on page 145.
We do not repeat all the steps again. In Figure 9-11 and Figure 9-12, you can see the
differences between logical ports 0 and 1 that are in the OATs.
In this example, both VTAMs in S30 and S35 communicate over an Ethernet LAN via logical
port 0 (device number 9EA) and over a token-ring connection via logical port 1 (device
number 9EB). You need to define two types of major nodes in VTAM:
External Communication Adapter (XCA) major node
Switched major node
Note: The current OSA-Express features support 4096 SNA PU Type 2 connections per
port on System z9 and zSeries servers.
For the configuration example in Figure 9-2 on page 143, the XCA major node (XCAES30)
definition in the VTAM for system S30 is for an Ethernet connection via logical port 0 (device
number 9EA). XCATS30 represents the token-ring connection via logical port 1 of the
OSA-Express. Example 9-2 and Example 9-3 show the actual VTAM coding to implement
these connections.
TYPE=XCA XCA major node Each OSA port functions like an XCA to VTAM.
ADAPNO=0 PORT statement OSE9APE is the name of port 0 of the OSA feature. Code
ADAPNO=0 is for logical port 0 of OSA-Express 155 ATM.
CUADDR=E9A Channel unit Code the device number defined for this port (port 0). In this
address example, S30 uses device number E9A for port 0.
MEDIUM= LAN type Use RING for token ring, and use CSMACD for Ethernet.
CSMACD
SAPADDR=4 Service access Code a value that is a multiple of 4. This address must be
point address unique for each VTAM communicating with a port.
Use different SAP addresses if a port is shared by multiple
VTAMs. See the SAPADDR value of XCAES35 in Example 9-4.
DIAL=YES Switched OSE9EAGE is the minor node name of the line group. You must
peripheral node code DIAL=YES to specify that the switched line control protocol is
required.
AUTOGEN= Autogeneration This parameter enables VTAM to generate automatically three sets
(3,L,P) of LINE and PU of LINE and PU statements. The LINE names begin with L. The PU
statements names begin with P.
Example 9-4 and Example 9-5 present the definitions for XCA major nodes XCAES35 and
XCATS35 in VTAM for system S35 via both logical ports of the OSA-Express.
Table 9-3 shows the only parameter that is different between system S30 and S35.
SAPADDR=8 Service access A different SAP address of 8 is used because the two VTAMs
point address share the same port 0. See the SAPADDR value of XCAES30 in
Example 9-2 on page 153.
Example 9-6 shows how 3270 sessions can be set up with a switched major node
(SWNS301) for S30.
PUTYPE=2 PU type The PUTYPE must be 2 for a LAN switched station. Type 2
also denotes a type 2.1 PU.
CPNAME=OSANT1 Control point To dial in, a type 2.1 peripheral node on a switched line
(CP) name of a requires either CPNAME or both IDBLK and IDNUM.
type 2.1 node However, you can code all three operands.
Table 9-5 presents the important parameters in the LU definition for SWNS301.
MODETAB=MTAPPC Logon mode table Code a separate logon mode table for
APPC.
For connection from S35 to the OSANT1 workstation, the parameters for the switched major
node are exactly the same as the parameters in the switched major node SWNS301. You
should change the names for PUs and LUs to make them more meaningful. For connections
to other PUs, you must create additional entries that reflect their CPNAMEs or
IDBLOCK/IDNUM combinations.
Figure 9-2 on page 143 shows the network and the connections for our configuration
example. The following definitions are based on one OSA-Express 155 ATM feature, using
CHPID F6. It has logical port 0 connected to an Ethernet LAN and will be used by LPAR S30
as TCP/IP address 10.11.41.210, and by LPAR S35 as TCP/IP address 10.11.41.220. Logical
port 1 is connected to a token-ring LAN and will be used by LPAR S30 as TCP/IP address
10.11.42.210, and by LPAR S35 as TCP/IP address 10.11.42.220.
Note: Although the OSA port is mainly addressed by the device number, the port
number in the LINK statement must match the actual OSA port number.
BEGINROUTES statement: If you are migrating your TCP/IP profile from an earlier
release, the profile may use the GATEWAY statement to define static routes instead of
the BEGINROUTES - ENDROUTES statements. Gateway will be recognized and used,
but you should consider replacing it with BEGINROUTES.
Because it is compatible with UNIX standards, easier to code than GATEWAY, accepts
both IPv4 and IPv6 addresses, and has enhanced functionality, BEGINROUTES is the
recommended method for defining static routes. Future static route enhancements will
be available only with the BEGINROUTES statement.
Example 9-7 shows the TCP/IP PROFILE definitions needed to define OSA to TCP/IP for
LPAR S30.
HOME
10.11.41.210 OSAL9E0
10.11.42.210 OSAL9E2
BEGINROUTES
10.11.41.0/24 = OSAL9E0 MTU 1500
10.11.42.0/24 = OSAL9E2 MTU 1500
ENDROUTES
The configuration for LPAR S35 is exactly the same with one exception. That is, the TCP/IP
profile for LPAR S35 has the HOME statements coded to reflect the different IP address, as
shown in Example 9-8.
9.5 Activation
After we add all the definitions to OSA/SF, VTAM, and TCP/IP, we can activate the
configuration. Activation may require several tasks, such as:
Verifying the devices are online
Activating an OSA/SF configuration
Activating VTAM resources
Activating TCP/IP
D U,,,9E0,4
IEE457I 21.29.17 UNIT STATUS 836
UNIT TYPE STATUS VOLSER VOLSTATE
09E0 OSA O
09E1 OSA O
09E2 OSA O
09E3 OSA O
D U,,,9EA,2
IEE457I 21.32.17 UNIT STATUS 936
UNIT TYPE STATUS VOLSER VOLSTATE
09EA OSA O
09EB OSA O
2. From the list of configurations, highlight your saved configuration and click Change. This
retrieves the OSA configuration.
Note: The configuration defined the access from both LPARs. The effect of the activation
command is to make the OSA configuration active to all LPARs. You do not need to
activate OSA-Express from more than one LPAR.
D NET,ID=XCAES30,E
IST097I DISPLAY ACCEPTED
IST075I NAME = XCAES30, TYPE = XCA MAJOR NODE 715
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1021I MEDIUM=CSMA/CD, ADAPNO= 0,CUA=9EA, SNA SAP= 4
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST170I LINES:
IST232I L9EA000 ACTIV
IST232I L9EA001 ACTIV
IST232I L9EA002 ACTIV
IST314I END
D NET,ID=XCATS30,E
IST097I DISPLAY ACCEPTED
IST075I NAME = XCATS30, TYPE = XCA MAJOR NODE 715
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1021I MEDIUM=RING, ADAPNO= 1,CUA=9EB,SNA SAP= 4
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST170I LINES:
IST232I L9EB000 ACTIV
IST232I L9EB001 ACTIV
IST232I L9EB002 ACTIV
IST314I END
D NET,ID=SWNS301,E
IST097I DISPLAY ACCEPTED
IST075I NAME = SWNS301, TYPE = SW SNA MAJ NODE 718
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I OSAS301 TYPE = PU_T2 , CONCT
IST089I OSA30L1 TYPE = LOGICAL UNIT , CONCT
IST089I OSA30L2 TYPE = LOGICAL UNIT , CONCT
IST314I END
The displays of the major nodes on system S35 gave us equivalent results.
Enterprise Extender allows for the use of Systems Network Architecture (SNA) transport
protocols, namely Advanced Peer-to-Peer Networking (APPN) and Hardware Configuration
Definition (HCD), over an Internet Protocol (IP) network. It enables the leveraging of IP-based
infrastructure network components for use in delivering SNA traffic.
The EE function of IBM Communications Server for z/OS allows you to run SNA applications
and data on IP networks and IP-attached clients. You can use this feature with any
OSA-Express feature running IP traffic. EE is a simple set of extensions to the open High
Performance Routing (HPR) technology that integrates HPR frames into User Datagram
Protocol/Internet Protocol (UDP/IP) packets.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 165
10.1 The IP backbone as an APPN connection network
An important aspect of Enterprise Extender is the ability to view the IP network as an APPN
connection network. In this case, the benefit comes from the ability to dynamically establish a
single one-hop HPR link to any host to which IP connectivity is enabled, provided that the
host implements Enterprise Extender. In general, this allows the routing function to be
handled entirely within IP. IP routers serve as the only routing nodes (hosts) in the network.
Figure 10-1 illustrates the components of one APPN network with many host network nodes
(NNs) and end nodes (ENs) involved.
NN
EN
EN
IP Network
Intranet
EN
NN
Enterprise Extender has been designed to run over existing IP networks without requiring any
change to applications or to IP routers. SNA applications see the same SNA network
interfaces as before, where IP routers continue to see the same IP (UDP) packets.
Note: Only the nodes at the edges of the IP network (potentially, the host systems only)
need to be aware of Enterprise Extender.
Enterprise Extender supports the use of both precedence bits and port numbers to inform the
IP network of the transmission priority. We recommend that you use precedence bits because
they are in the IP header, where the UDP or TCP port numbers are carried inside the IP
datagram. Therefore, encrypted packets have unreadable port numbers, and fragmented
packets have no port numbers, after the first fragment. For such encrypted or fragmented
packets, intermediate routers cannot determine the appropriate priority.
SNA IP SNA
RTP
ANR
ANR ANR
EE (UDP/IP)
Therefore, an enhanced algorithm known as Responsive Mode ARB was introduced with
Enterprise Extender. It is now an option for RTP nodes regardless of whether their HPR
connection includes an Enterprise Extender link. Nodes that support Responsive Mode ARB
can negotiate their level of ARB support during route setup exchange, and fall back to the
original ARB if their partner does not support Responsive Mode.
IBM Communications Server allows multiple TCP/IP stacks to run concurrently with a single
VTAM, but the Enterprise Extender function can use only one of these at a time. VTAM can
change its allegiance from one TCP/IP stack to another, but only when all Enterprise
Extender connections have been terminated. A VTAM start option, TCPNAME, allows you to
specify which of several stacks VTAM is to use. If this option is not specified, VTAM chooses a
suitable stack that supports Enterprise Extender.
If VTAM is to act as an Enterprise Extender node, it must have an IP address associated with
it. This IP address is specified using the IPADDR start option, but the default IP address of the
chosen stack is used if the start option is not coded. The IP address needs to be predictable,
because partner Enterprise Extender nodes may need to connect to it. However it is not
desirable that a single IP port always be used for such connections. Therefore, this address
must be a virtual IP address (VIPA).
Enterprise Extender can be implemented under all modes of OSA-Express. A router that
supports EE can be implemented in a remote site as an endpoint, eliminating the need for EE
support at each workstation.
z/OS NN z/OS NN
SC64 SC65
VTAM VTAM
XCAEE64 XCAEE65
EE EE
TCPIPD TCPIPD
IUTSAMEH IUTSAMEH
VIPA1 VIPA1
192.16.1.20 192.16.1.30
E200-E202 2D80-2D82
OSA-Express OSA-Express
Personal
Ethernet Communications
Switch EN - EE
192.168.1.110
Note: The reserved TRLE named IUTSAMEH (same host) in VTAM provides the EE
connection between VTAM and TCP/IP. VTAM automatically activates the IUTSAMEH
when an MPCPTP device (in TCP/IP) is started.
In the profile for TCPIPD in the SC64 partition, we define one virtual IP address (VIPA1), one
OSA-Express port (OSAE200), and one IUTSAMEH. We define the same devices in SC65
(TCPIPE), using different IP addresses.
Example 10-1 shows the TCP/IP profile definitions used for our EE configuration in SC64.
;VIPA Definitions
DEVICE VIPA1 VIRTUAL 0
LINK VLINK1 VIRTUAL 0 VIPA1
HOME
192.16.1.21 E200LNK
192.16.1.20 VLINK1
BEGINROUTES
ROUTE 192.16.1.0/24 = E200LNK MTU 1492
ENDROUTES
START IUTSAMEH
START OSAE200
VIPA1
The VIPA address needs a virtual device and link defined. In our case, we name the device
VIPA1 and the link VLINK1. The VIPA address looks like an interface to a virtual network that
is concealed behind this TCP/IP stack.
Note: Define at least as many lines as the maximum concurrent connections expect.
Example 10-4 shows the switched major node that we use for SC65 (acting as an NN) that
was activated on SC64.
Example 10-5 shows the switched major node that we use for our EN workstation.
Note: In the definitions for SC65 (ATCSTR65), we alter IPADDR to 192.16.1.30 and
TCPNAME to TCPIPE. If TCPNAME is not defined, it can be dynamically updated with the
MODIFY console command. For example, F VTAM44,VTAMOPTS,TCPNAME=TCPIPE
VTAM44 is the job name of our started task (STC) for VTAM.
The parameters can be verified with the display of the VTAM options. To display the current
VTAM options, enter the following command:
D NET,VTAMOPTS
D NET,ID=XCAEE
D NET,ID=PUTO65,E
Example 10-7 shows the status of VIPA1 and IUTSAMEH DEVICEs used for Enterprise
Extender.
We look for IUTSAMEH and VIPA1. The link status must be READY.
Example 10-8 that shows a display of XCAEE (XCA majnode) used for Enterprise Extender.
Example 10-9 shows the results of D NET,ID=SWTO65 and PUTO65, to verify the NN-to-NN
connection between SC64 to SC65 via Enterprise Extender.
From the Windows Start menu, we select Start →Program →IBM Personal
Communications →Start or Configure Session (we select Configure Session). Then we
use these steps:
3. In the Configure DLUR window (Figure 10-6), we enter our values for PU name, Block ID,
Physical Unit ID, and the DLUS name (Net ID and CPNAME of VTAM), and click Next.
Important: The PU name, Block ID, and Physical Unit ID required in the Configure
DLUR panel must match the definitions defined to the associated switched major node
in VTAM.
5. In the Configure IBM-EEDLC Connection window (Figure 10-8), we enter the IP address
of SC64. For Local SAP and Remote SAP, we use the default SAP of 04, and click Next.
Important: The IP address in the Configure IBM-EEDLC Connection panel must be the
IP address of the VIPA (192.16.1.20).
192.16.1.20
Example 10-10 shows the VTAM display command that we use to verify that the defined LUs
are in session.
This chapter explains the concept of VLANs and provides some examples of access and
trunk mode usage. VLAN technology is supported by the OSA-Express2 and OSA-Express
Ethernet features running in QDIO mode and in the following operating system environments:
z/OS V1R4 with APAR PQ86508 or later
z/VM V4R4 or later
Linux kernel 2.4.19 or later
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 183
11.1 VLAN overview
A VLAN is a group of workstations with a common set of requirements, independent of
physical location. VLANs have the same attributes as a physical LAN, even though they may
not be located physically on the same LAN segment. VLANs can be used to increase
bandwidth and reduce overhead by allowing networks to be organized for optimum traffic flow.
Figure 11-1 shows an example of VLANs segmented into logically defined networks.
Floor 3
Router
Switch 2 Floor 2
Floor 3
Switch 1
Ports used to attach VLAN-unaware equipment are called access ports, while ports used to
connect to other switches or VLAN-aware servers are known as trunk ports. Network frames
generated by VLAN-aware equipment are marked with a tag, which identifies the frame to the
VLAN.
Trunk mode
Trunk mode indicates that the switch should allow all VLAN ID tagged packets to pass
through the switch port without altering the VLAN ID. This mode is intended for servers that
Access mode
Access mode indicates that the switch should filter on specific VLAN IDs and only allow
packets that match the configured VLAN IDs to pass through the switch port. The VLAN ID is
then removed from the packet before it is sent to the server. That is, VLAN ID filtering is
controlled by the switch. In access mode, the switch expects to see packets without VLAN ID
tags inbound to the switch port.
Hybrid mode
Hybrid mode is a combination of the previous two modes. This is a port where both
VLAN-aware and VLAN-unaware devices are attached. A hybrid port can have both tagged
and untagged frames.
Figure 11-2 shows a logical diagram of a VLAN environment with two switches and a number
of VLANs.
VLAN 101
Server
HUB 1
TRUNK PORT
Switch 1
Switch 2
Router Internet
In this example network, VLAN 100 only exists in Switch 1, because the trunk port to Switch 2
is not a member of VLAN 100. VLANs 101 and 102 span the two switches, because the trunk
ports in each switch are members of both VLANs.
This example illustrates two reasons why VLANs are generally used:
Staff in different physical locations retain common access to resources.
The server is used by staff in both buildings. By defining these workstations to the same
VLAN, no additional configuration or equipment is required for either location to access the
Linux server, while at the same time ensuring that other staff do not obtain access.
Consolidation of resource access.
The external network has to be accessed by different staff in both buildings. Extending
VLAN 102 across to the router port in Switch 1 (and configuring the router correctly) saves
having to provide an additional link to the external network or the router from the other
building.
Broadcast in VLANs
All ports that are members of the same VLAN, including trunk ports, operate as though they
are part of the same physical network. When a multicast or broadcast frame is received from
a device on a particular VLAN, the switch transmits the frame to all ports (both trunk and
access ports) belonging to the same VLAN.
The only difference between the trunk and access port in this case is that the frame
transmitted onto the trunk port will have the VLAN tag intact, so that the VLAN-aware
equipment at the other end of the link knows how to handle it.
VLAN isolation
An important point about VLANs in general is that they provide isolation. VLANs behave like
separate physical networks, even though they may be contained within the same switch.
In order for devices in different VLANs to communicate, IP routing must occur. In the network
shown in Figure 11-2, workstations in VLAN 100 and VLAN 101 cannot communicate,
because there is no routing path between the two VLANs. Workstations in VLANs 100 and
102 can communicate, as long as the IP router to which they are attached is configured
appropriately.
OSA-Express VLAN support allows a TCP/IP stack to register a specific VLAN ID for both
IPv4 and IPv6 for the same OSA-Express port. Note that the VLAN ID for IPv4 can be
different than the VLAN ID for IPv6.
Note: z/VM does not fully support IPv6. However, z/VM V5.1 enhances its IPv6 support by
allowing the z/VM TCP/IP stack to be configured for IPv6 networks connected through
OSA-Express operating in QDIO mode. The stack can be configured to provide static
routing of IPv6 packets and to send IPv6 Router Advertisements.
When a VLAN ID is configured to an OSA-Express port via the TCP/IP stack, the following
events occur:
The TCP/IP stack becomes VLAN-aware or enabled, and the OSA-Express port is
considered to be part of a VLAN.
During activation, the TCP/IP stack registers the VLAN ID value to the OSA-Express port.
A VLAN tag is added to all outbound packets.
The OSA-Express port filters all inbound packets based on the configured VLAN ID.
Tip: We recommend that you create and maintain diagrams of your physical and logical
LAN layout. Such diagrams can be helpful when configuring your VLANs and for problem
determination purposes.
If a VLAN ID is not configured to an OSA-Express port (VLAN tagging and VLAN ID filtering is
not performed), access mode must be configured at the Ethernet switch port with the
appropriate VLAN ID.
Figure 11-4 shows an example of trunk mode versus access mode, with four VLANs deployed
through two shared OSA-Express port. The TCP/IP stacks operate as though they have their
own unique and isolated networks, as follows:
VLAN 100 - IP-stack #1 and clients 1 and 2
VLAN 200 - IP-stack #2 and clients 3 and 4
VLAN 300 - IP-stack #3 and clients 5 and 6
VLAN 400 - IP-stack #4 and #5, and IP router (for access beyond that LAN segment)
OSA-Express #1 OSA-Express #2
VLAN aware Trunk connection for VLAN unaware Access connection for
(Tagged frames) VLAN 100, 200 and 300 (Untagged frames) VLAN 400
Router
Clients 1 and 2 Clients 3 and 4 Clients 5 and 6
IP-stacks #1, #2, and #3 are configured with a VLAN ID, which will be registered with
OSA-Express port #1. Note that the Ethernet switch port in this case is configured in trunk
mode. Also notice that VLAN-aware and VLAN-unaware IP-stacks are not defined to the
same OSA-Express port.
Note: This example is used solely to demonstrate the VLAN design rules. We do not
recommend implementing OSA-Express features with a single point-of-failure.
OSA-Express OSA-Express
Figure 11-5 OSA-Express port shared between two stacks in the same VLAN
Figure 11-6 shows a configuration where multiple TCP/IP stacks are sharing a single
OSA-Express port configured with multiple VLANs and as primary and secondary routers.
Restriction: When sharing an OSA-Express port, each VLAN can support multiple
secondary routers. However only one primary router is supported.
OSA-Express
Trunk Mode
Ethernet Switch
Figure 11-6 PRIRouter and SECRouter in a VLAN environment
In Figure 11-6, traffic isolation is still maintained even if multiple primary routers are
configured. This is because the OSA-Express filters traffic based on the VLAN ID and
forwards it to the appropriate TCP/IP stack. Untagged and null tagged frames are forwarded
by the OSA-Express to IP-stack #1 if the next-hop IP address matches. Otherwise those
frames are dropped.
Multiple VLAN IDs defined to a single OSA-Express port are not supported with z/OS or
z/VM.
Remember that if the OSA-Express port is connected to an Ethernet switch port that is
defined to run in access mode, then no VLAN definitions are required in the z/OS TCP/IP
profile.
TCPIPA.SC64.TCPPARMS(PROFILE)
SC64:
DEVICE OSAE200 MPCIPA SC64 z/OS 1.6 SC65 z/OS 1.6
LINK E200LNK IPAQENET OSAE200 VLANID 200
TCP/IP A TCP/IP A
...
HOME
192.16.1.21 E200LNK OSA-Express OSA-Express
...
IP Address 192.16.1.21 IP Address 192.16.1.31
BEGINROUTES
ROUTE 192.16.1.0/24 = E200LNK MTU 1492
ENDROUTES VLAN ID 200 VLAN ID 300
...
TCPIPA.SC65.TCPPARMS(PROFILE)
OSA-Express
SC65:
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 300 Trunk connection to support
... VLAN 200 and 300 traffic
HOME
192.16.1.31 E200LNK
...
Ethernet Switch Trunk Mode
BEGINROUTES
ROUTE 192.16.1.0/24 = E200LNK MTU 1492
ENDROUTES Access Access
... Mode Mode
VLAN 200 VLAN 300
To define an OSA-Express port in QDIO mode, refer to Chapter 5, “QDIO mode” on page 79
for details.
11.3.2 Verification
After activation, we verify that the VLAN IDs in our z/OS TCP/IP environment are defined
correctly, by issuing the netstat dev command via the TSO command interface - Option 6 (for
SC64, see Example 11-1). We issued the same command on SC65 to verify that it was
assigned to VLAN ID 300.
#spantree
#portfast
set spantree global-default bpdu-guard enable
!
#module 2 : 48-port 10/100BaseTX Ethernet
set vlan 200 2/5
set vlan 300 2/6
We successfully test the connections from Client 1 to SC64 and from Client 2 to SC65 using
ping commands. As expected, pinging from Client 1 to SC65 and from Client 2 to SC64 does
not work.
VLAN support is usually built as a module called 8021q.o. Use the insmod or modprobe
command to load the module before you attempt to use VLAN support.
When the module is loaded, you see the following messages in your system log or dmesg
output:
802.1Q VLAN Support v1.7 Ben Greear <[email protected]>
All bugs added by David S. Miller <[email protected]>
Remember that if the OSA-Express port is connected to an Ethernet switch port that is
defined to run in access mode, then no VLAN definitions are required for the Linux TCP/IP
stack.
z/VM
LINUX 2: LINUX2 LINUX3
LINUX3
LINUX 3:
Access Access
Mode Mode
VLAN 200 VLAN 210
We used SUSE LINUX Enterprise Server (SLES) 8 in our environment, which is one Linux
distribution that has VLAN support built into its kernel (version 2.4.19). A VLAN is defined to
an existing Ethernet interface. The vconfig command is used to add or remove a VLAN
configuration for a defined Ethernet interface.
LINUX commands
On LINUX2 and LINUX3, we define the VLAN configurations using the following commands:
LINUX2
vconfig add eth1 200
ifconfig eth1.200 200.1.1.1 netmask 255.255.255.0 up
LINUX3
vconfig add eth1 210
ifconfig eth1.210 210.1.1.1 netmask 255.255.255.0 up
Startup configuration
Configuring VLANs is a manual process that must be scripted to take place when the Linux
guests are booted. As VLAN usage grows, you can expect to see that Linux distributors will
include VLAN boot-time configuration in their network scripts.
11.4.2 Verification
We verify the VLAN definitions by entering the ifconfig command on LINUX2 and LINUX3.
Example 11-3 shows the results of LINUX3.
#spantree
#portfast
set spantree global-default bpdu-guard enable
!
#module 2 : 48-port 10/100BaseTX Ethernet
We successfully test the connections from Client 1 to LINUX2 and from Client 2 to LINUX3
using ping commands. As expected, pinging from Client 1 to LINUX3 and from Client 2 to
LINUX2 did not work.
To support VLANs, the OSA-Express2 features require the January 2005 level of LIC.
OSA-Express Ethernet features must be at DRV3G with MCL (J11204.022) or later, and
running in QDIO mode.
Remember that if the OSA-Express port is connected to an Ethernet switch port that is
defined to run in access mode, then no VLAN definitions are required in the z/VM TCP/IP
profile.
We configured the VLAN ID of 200 on VM5 using the parameter VLAN on the LINK statement
of the TCP/IP profile. The VLAN is an optional parameter followed by a decimal number
indicating the VLAN identifier to be assigned to this OSA-Express port. The valid range is 1 to
4094. The value used should be a VLAN identifier recognized by the Ethernet switch to which
the OSA-Express port is connected.
VM5
VM5:
DEVICE OSA2D48 OSD 2D48 PORTNAME OSACHP0D
z/VM 5.1
LINK OSA2D48L QDIOETHERNET OSA2D48 VLAN 200 TCP/IP
...
HOME
192.16.1.40 OSA2D48L OSA-Express
...
IP Address 192.16.1.40
GATEWAY
192.16.1 = OSA2D48L 1500 0
VLAN ID 200
OSA-Express
Port assigment for the Ethernet Switch
Port Type VLAN ID Connection Trunk connection to support
2/1 TRUNK n/a OSA-Express VLAN 200 traffic
2/5 ACCESS VLAN 200 Client 1
Ethernet Switch Trunk Mode
Access
Mode
VLAN 200
Client 1
11.5.2 Verification
After activation, we verify that the VLAN ID in our z/VM TCP/IP environment is defined
correctly, by issuing the netstat dev command (see Example 11-5).
#spantree
#portfast
set spantree global-default bpdu-guard enable
!
#module 2 : 48-port 10/100BaseTX Ethernet
set vlan 200 2/5
We successfully test the connection from Client 1 to VM5, using the ping command. And as
expected, pinging from VM5 to other clients and systems outside VLAN 200 does not work.
The virtual switch supports two VLAN modes (known as port types), that are based on
whether the attaching guest is VLAN-aware (the guest can send and receive tagged frames)
or VLAN-unaware (the guest is unable to handle tagged frames).
Port type access is for guests that are unaware of VLAN IDs, which send and receive only
untagged traffic. A guest that is connected to an access port must be configured as a member
of only one VLAN. The virtual switch associates the VLAN with each frame sent by that guest,
and only delivers frames to that guest if they are associated with the same VLAN. All frames
delivered to an access port are delivered untagged, regardless of the VLAN ID.
Port type trunk is designated for those guests that are VLAN-aware. VLAN membership is
determined for these connections based on the access list that was granted to each guest. A
trunk port that is not configured (granted) with any VLAN memberships is a member of the
virtual switch’s default VLAN ID (untagged set). Trunk ports with explicit VLAN membership
are not automatically members of the untagged set and must be explicitly authorized through
the GRANT operand of the SET VSWITCH command to add the default VLAN ID to the
guest’s access list. The OSA-Express connection to the virtual switch is a trunk port and is
automatically configured to be a member of the untagged set. This provides the virtual switch
with the ability to transmit and receive untagged frames.
When the virtual switch is configured to operate as VLAN-aware, the port on the Ethernet
switch for the OSA-Express port connection should be configured as a trunk port. Equally so,
Trunk Mode
Figure 11-10 VLAN configuration using OSA-Express and z/VM Virtual Switch (VLAN-aware)
In this example, one OSA-Express port is associated with a virtual switch. The OSA-Express
port functions like a trunk port with access to all of the VLAN IDs registered in the virtual
switch. The port on the Ethernet switch to which the OSA Express connects can belong to
any or all VLAN IDs configured in the virtual switch. This extends those VLANs out of the
virtual switch to the physical LAN segment.
The setup of the Ethernet switch port determines the VLAN membership.
Access Mode
Access VLAN 100 Access
Mode Mode
Router
VLAN 100 Ethernet Switch VLAN 200
Figure 11-11 VLAN configuration using OSA-Express and z/VM Virtual Switch (VLAN-unaware)
For more information and examples about how to set up the z/VM Virtual Switch, refer to
Chapter 12, “Layer 2 support” on page 201.
This chapter discusses OSA-Express Layer 2 support in conjunction with the z/VM Virtual
Switch, and the steps required for implementation. z/VM Virtual Switch introduced with z/VM
4.4 was built upon the Guest LAN technology delivered in earlier z/VM releases, which
supported Layer 3 (Network Layer) of the OSI model. In z/VM 5.1, the virtual switch
functionality is enhanced to include Layer 2 (Data Link Layer) support. This gives the virtual
switch the ability to operate in either Ethernet mode (Layer 2) or IP mode (Layer 3). Security
enhancements were also included with an External Security Manager (ESM).
For more details about z/VM communication services and concepts, refer to z/VM
Connectivity Version 5 Release 1, SC24-6080.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 201
12.1 Virtual switch
The virtual switch is a Guest LAN technology that bridges real hardware and virtual LANs,
offering external connectivity to the Guest LAN environment. The virtual switch operates with
virtual QDIO adapters. External LAN connectivity is available through the OSA-Express
Ethernet features configured in QDIO mode. Like the OSA-Express Ethernet features, the
virtual switch supports the transport of both IP packets and Ethernet frames.
By default, the virtual switch operates in IP mode (Layer 3). Each guest is identified by one or
more IP addresses for the delivery of IP packets. Data is transported within IP packets.
Therefore, the virtual switch in IP mode supports only TCP/IP-based application
communications. All IP traffic destined for the physical portion of the LAN segment is
encapsulated into an Ethernet frame with the OSA-Express port’s MAC address as the
source MAC address. Inbound, the OSA-Express port strips the Ethernet frame and forwards
the IP packet to the virtual switch for delivery to the guest based on the destination IP address
within the IP packet.
When operating in Ethernet mode (Layer 2), the virtual switch uses a unique MAC address for
forwarding frames for each guest system. Data is transported and delivered within Ethernet
frames. This provides the ability to transport both TCP/IP and non-TCP/IP based application
data through the virtual switch fabric. The address-resolution process allows each guest
system’s MAC address to become known to hosts residing on the physical side of the LAN
segment. All inbound or outbound frames passing through the OSA-Express port have the
guest system’s corresponding MAC address as the source or destination address.
A virtual switch can operate only in one of the two transport modes, exclusively. This means
that, if it is configured in IP mode, then all traffic passing through the virtual switch must be IP
based. The same is true when the switch is configured in Ethernet mode. However, Ethernet
mode allows any IEEE 802.2 based protocol to pass through.
We recommend that you use a virtual switch running in Ethernet mode if you have a
requirement to support multiple Linux systems in a z/VM environment. For the purpose of this
redbook, we concentrate primarily on the OSA-Express Layer 2 support, by highlighting the
Ethernet mode capabilities of a z/VM Virtual Switch and the set up required to implement
such an environment.
For more information about configuring the virtual switch for Layer 3 (IP mode), refer to Linux
on IBM Eserver zSeries and S/390: VSWITCH and VLAN Features of z/VM 4.4,
REDP-3719.
For more information about how to configure a virtual switch controller, refer to “Configuring a
virtual switch controller” on page 206.
A NIC is a set of virtual I/O devices that simulate one of the following network adapters:
OSA-Express
HiperSockets
For more information about how to configure the NIC, refer to “Linking the guest systems to
the virtual switch” on page 210.
The Control Program is the component of z/VM that manages the resources of a single
computer so that multiple computing systems (virtual machines) appear to exist. Think of CP
as a supervisor (or hypervisor) program running in a layer between the hardware and virtual
machines. When you are working in the CP environment, you are provided with central
processing unit (CPU) functions, input and output devices, and storage. Through CP, the
virtual machine can run its own operating system, such as Linux, z/OS, or z/VM itself.
Virtual machines created by CP have directory entries in the z/VM user directory (or user
registry) that describe the configuration and operating characteristics of each virtual machine.
Throughout this chapter, many of the virtual switch configuration definitions are defined as
directory entries in our examples.
Restriction: Traffic can be sent between logical partitions (LPARs) without going over the
physical network when the port sharing capability of the OSA-Express is used. However, a
restriction exists with port sharing now that Layer 2 support has been introduced.
Port sharing is supported only between virtual switches that are of the same transport
mode, for example Layer 2 with Layer 2 or Layer 3 with Layer 3. Attempted
communications between a Layer 2 virtual switch and a Layer 3 virtual switch sharing the
same OSA-Express port results in a network time-out condition. To resolve this, you must
have the Layer 2 and Layer 3 virtual switches using separate OSA-Express ports.
Communication between the Layer 2 and Layer 3 virtual switches can be established via
an IP router.
The VMLAN statement contains a MACPREFIX parameter, which allows the administrator to
specify a three byte ID prefix for all MAC addresses in this z/VM system. The VMLAN
parameter MACIDRANGE controls the range of identifiers that can be used by CP when
generating the unique identifier component of a virtual NIC’s MAC address.
In the user directory, a NICDEF statement is added for each guest who will connect to the
virtual switch. The MACID parameter of NICDEF allows the administrator to specify a unique
identifier that is appended to the MACPREFIX to form a unique MAC address for that guest. If
MACID is omitted, CP generates a unique identifier based on the range specified in the
MACIDRANGE parameter. If you specify your own MACID value in the NICDEF and the
MACID is already in use by another guest, the adapter is not created and you need to remove
the conflicting device or select a different MACID.
These locally generated MAC addresses are visible across the physical portion of the LAN
segment.
Tip: If you run multiple z/VM systems on your System z9 or zSeries server, change the
MACPREFIX of each system to avoid MAC address duplication.
Tip: To determine if you have the correct level of the Linux qeth device driver, check the
revision number. If the revision number is lower than 1.397, Layer 2 support will not work.
To check the revision number from Linux, enter:
strings /lib/modules/2.4.21-231-default/kernel/drivers/s390/net/qeth.o | grep driver
The objectives of the tests are two-fold. The first objective is to show Layer 2 functionality
within the z/VM Virtual Switch and Linux guests environment, and clients connected to the
Ethernet switch. The second objective is to show VLAN functionality across the Ethernet
switch between the z/VM and z/OS environment.
VSWTCH1
Virtual Switch
Ethernet Switch
User directory
Add the IUCV *VSWITCH statement to the z/VM user directory for the TCP/IP virtual machine
or machines. This is required for the virtual machine or machines to become virtual switch
controllers (see Example 12-1).
PROFILE EXEC
In order for the controller virtual machines to start automatically at z/VM IPL time, add the
entries to the PROFILE EXEC of AUTOLOG1, as shown in Example 12-2.
PROFILE TCPIP
Add the VSWITCH CONTROLLER ON statement to the TCP/IP configuration file. Copy an
existing z/VM TCP/IP stack’s PROFILE TCPIP file to the 191 disk of each controller virtual
machine (see Example 12-3). You can usually find a copy on the TCPMAINT 198 disk.
VSWITCH CONTROLLER ON
The ETHERNET parameter indicates that this virtual switch will operate in Ethernet mode.
The virtual switch will be connected to two OSA-Express ports, devices 2D40 to 2D42
(CHPID 0D), and 3D44to 3D46 (CHPID 0E).
Here, switchname is the name of the virtual switch, and operands defines the attributes of the
virtual switch.
Table 12-1 summarizes the common operands accepted by the DEFINE VSWITCH
command.
RDEV This operand is a real device address to be used to connect the virtual switch to a QDIO
OSA-Express device. You can specify a maximum of three real device numbers. Each real
device address represents a trio of devices. For example, specifying RDEV 111 222 333
means that the first devices, 111 to 113, are used to provide the connection to the real
hardware LAN segment. If there is a problem with the connection, devices 222-224 are used
next to provide the connection. If those devices fail to connect, devices 333 to 335 are used.
This feature provides dynamic recovery for OSA-Express device failures.
CONnect This operand indicates that the device identified by the RDEV keyword must be activated, and
traffic must flow through the device to the real LAN segment.
CONTRoller * | userid1 This operand identifies the z/VM user ID that controls the OSA-Express device connected at
the device address identified by rdev. CONTROLLER * means that CP selects from any of the
eligible z/VM TCP/IP stacks. If you specify multiple real devices on the RDEV keyword, specify
CONTROLLER *, or allow it to default. The controller functions are then spread across
multiple z/VM TCP/IP stacks, providing more flexibility in case of a failure.
IP | Ethernet This operand indicates whether the transport for the virtual switch is ETHERNET or IP. An
ETHERNET virtual switch operates at the Layer 2 level of the OSI model, while an IP virtual
switch operates at Layer 3.
PORTname portname This operand is a one- to eight-character name that identifies the OSA-Express port. You can
specify a maximum of three port names. Multiple port names are used when different port
names are needed for the multiple rdevs specified on the RDEV operand.
VMLAN
In addition, you can add a VMLAN statement to the CP SYSTEM CONFIG file, which
overrides the system-wide MAC address definitions used when generating local MAC
addresses for individual guests. We use the default system generated MAC address settings,
because we have only a single z/VM system in our environment.
The syntax of the VMLAN statement is shown as either of the following examples:
VMLAN LIMIT [ operands ]
VMLAN ACCOUNTing [ operands ]
In these statements, operands define the attributes to be set for all z/VM Guest LANs in the
system. Table 12-2 summarizes the operands of the VMLAN command.
MACPREFIX macprefix This operand specifies the three-byte prefix (manufacturer ID) used when generating locally
administered MAC addresses on the system. It must be six hexadecimal digits within the
range of 020000 through 02FFFF (inclusive). In combination with the MAC ID used on the
NICDEF directory statement, the MACPREFIX allows unique identification of virtual adapters
within a network. If MACPREFIX is not specified, the default is 020000 (02-00-00).
MACIDRange SYSTEM This operand is the range of identifiers (up to six hexadecimal digits each) to be used by CP
xxxxxx-xxxxxx USER when generating the unique identifier part (last six hexadecimal digits) of a virtual adapter
xxxxxx-xxxxxx MAC address. If a SYSTEM MACIDRANGE is not specified, CP creates unique identifiers in
any range (000001-FFFFFF).
USER xxxxxx-xxxxxx is the subset of the SYSTEM range of identifiers that are reserved for
user definition of MACIDs in the NICDEF directory statement. When specified, CP does not
assign MACIDs within this USER range during creation of virtual adapters defined
dynamically (DEFINE NIC) or with the NICDEF (or SPECIAL) directory statement without the
MACID operand. In these cases, CP generates a unique identifier for the adapter outside of
the USER range. Any MACID values specified on a NICDEF directory statement must be
within the USER range or the virtual adapter is not defined during LOGON processing. If a
USER MACIDRANGE is not specified, CP creates unique identifiers within the SYSTEM
MACIDRANGE.
The definitions in Example 12-5 are used to modify the default VMLAN values.
This function can also be performed by an ESM, such as RACF. For more information
regarding the use of an ESM, refer to 12.3, “z/VM Virtual Switch authorization” on page 223.
Alternative: To dynamically link your guest systems to the virtual switch, use the DEFINE
NIC and COUPLE commands. See “Defining and coupling a NIC using CP commands” on
page 241.
The NICDEF statement defines virtual devices, which are fully simulated by CP.
Example 12-7 shows an example user directory entry for our Linux guests that connect to the
QDIO Guest LAN (VSWTCH1).
Note: We could have added a MACID parameter to the NICDEF statement. Instead, we
chose to let the system generate one for us.
In this statement, vdev specifies the base virtual device address for the adapter, and
operands defines the characteristics of the virtual NIC.
HIPERs | QDIO HIPERs indicates that a simulated HiperSockets adapter should be created. QDIO indicates that
a simulated QDIO adapter should be created. If a LAN is identified in this statement or another
with the same vdev, the NIC is automatically coupled to the specified ownerid lanname.
devs The number (decimal) of virtual I/O devices to be created for a simulated NIC. If devs is omitted
the default number of devices is 3.
ownerid | * lanname This operand identifies a Guest LAN segment for an immediate connection to the NIC. If ownerid
and lanname are omitted, the simulated adapter is left in the uncoupled state. When ownerid and
lanname are specified, the adapter is automatically connected to the designated Guest LAN.
Note that ownerid can be specified as a name or using an asterisk (*) to represent the user ID of
the current virtual machine.
CHPID xx This operand is a two-digit hexadecimal number that represents the channel path identifier
(CHPID) number to be allocated in the virtual machine I/O configuration for this adapter. If CHPID
is omitted, an available CHPID is automatically assigned to this adapter. This option is required
when a HiperSockets adapter is created for a z/OS guest because z/OS configurations require
a predictable CHPID number. During LOGON, CP attempts to use the specified CHPID number.
If the specified CHPID number is already in use, this adapter is not defined. To correct this
situation, you must eliminate the conflicting device or select a different CHPID.
MACID xxxxxx This operand is a unique identifier (up to six hexadecimal digits) that is used as part of the
adapter MAC address. During LOGON, your MACID (three bytes) is appended to the system
MACPREFIX (three bytes) to form a unique MAC address for this adapter. If MACID is omitted
from this definition, CP generates a unique identifier for this adapter. If the specified MACID is
already in use, this adapter is not defined. To correct this situation, you must eliminate the
conflicting device or select a different MACID.
Note: We could have made all our changes dynamically by issuing the configuration
commands directly from MAINT or any other class B user ID. Consider making your
configuration changes dynamically if you cannot IPL your z/VM environment at will.
Controller
To check if the VM TCP/IP stacks are recognized as controller virtual machines, see
Example 12-8.
VMLAN
If you elect to change the default system-wide MAC addresses, use the command shown in
Example 12-10 to check if the VMLAN changes are applied. As mentioned earlier, we use the
system default MAC addresses.
Authorization
To check the access list of the authorized user IDs for the virtual switch, refer to
Example 12-11.
Q NIC DETAILS
Adapter C204 Type: QDIO Name: UNASSIGNED Devices: 3
Port 0 MAC: 02-00-00-00-00-04 LAN: * None MFS: 8992
RX Packets: 0 Discarded: 0 Errors: 0
TX Packets: 0 Discarded: 0 Errors: 0
RX Bytes: 0 TX Bytes: 0
Unassigned Devices:
Device: C204 Unit: 000 Role: Unassigned
Device: C205 Unit: 001 Role: Unassigned
Device: C206 Unit: 002 Role: Unassigned
Alternative: We could have defined the Linux guests as DHCP clients to request
IP addresses from a DHCP server running on the LAN. This works because the Linux
guests’ MAC addresses are visible to both the internal and external segments of the LAN.
For our Linux guests, we use a /etc/chandev.conf entry to ensure they connect to the virtual
switch at boot-time (see Example 12-13).
LNXSU2
noauto;qeth0,0xc204,0xc205,0xc206;add_parms,0x10,0xc204,0xc206,layer2
Note: When using the virtual switch in Ethernet mode, you must use the qeth parameter,
layer2. To disable Layer 2 functionality, you can use the no_layer2 parameter, which is the
default. The qeth driver then expects to connect to a virtual switch in IP mode.
We reboot the Linux guests after making the changes and ensure that the static IP address
and qeth device driver were loaded correctly for each guest. You can verify this by using the
ifconfig command as shown in Example 12-14.
On the z/VM side, we verify the connection by using the QUERY VSWITCH command as
shown in Example 12-15.
Notice that both LNXSU1 and LNXSU2 are connected to the virtual switch (VSWTCH1). Also,
the IP addresses are defined by us using the ifconfig command. Furthermore, you can see
that system generated MAC addresses are associated with the IP adrresses.
z/VM 5.1
LNXSU1 LNXSU2 LNXSU3 VSWCTL1 VSWCTL2 z/OS 1.6
MAC Addr. MAC Addr.
Primary Backup
02-00-00-00-00-01 02-00-00-00-00-02 Controller Controller
IP. 192.16.1.41 IP. 192.16.1.42 IP. 192.16.1.43
VSWTCH1
Virtual Switch
Ethernet Switch
192.16.1.15
Figure 12-2 Verifying virtual switch connectivity, using the PING command
When configuring a virtual switch with VLAN capabilities, you can select either access mode
or trunk mode. We configure our environment in trunk mode to show the Layer 2 and VLAN
capabilities of the virtual switch in conjunction with the OSA-Express Ethernet port, and
Ethernet switch. For more information about VLAN support and access mode and trunk
mode, refer to Chapter 11, “VLAN support” on page 183.
Define
Virtual Switch
Define
YES Porttype NO Virtual Switch
Authorize Guest
access to
Trunk (Access Mode default Porttype
? and default & VLAN ID
......
VLAN ID )
Define Done
Virtual Switch
(Trunk Mode) SET VSWITCH VSWTCH1 GRA LNXSU1
DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CONR * ETH VLAN 100 PORT
OSACHP0D OSACHP0E
Go to flowchart: trunk
mode configuration DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CONR * ETH VLAN 100 PORTT TRUNK
options PORT OSACHP0D OSACHP0E
YES NO
YES
Prepare
Authorize Guest LINUX
Authorize Guest
access with access with new Authorize Guest Setup
default Portype Porttype and access with new
& VLAN ID VLAN ID Porttype
...... ...... .....
Done
Refer to Example 12-18 on page 219 to see how to prepare the Linux setup.
Previously our tests traversed the virtual switch fabric without the use of VLANs. The
objectives of this section are to:
Add VLAN functionality to the environment (z/VM and z/OS)
Verify the VLAN environment
Show VLAN connectivity between the virtual switch, Linux Guests and the z/OS TCP/IP
stacks
To achieve these objectives, we use the following steps as explained in greater detail in the
following sections:
1. Define VLAN capabilities to the virtual switch.
2. Authorize the Linux guests access to the virtual switch with specific VLAN IDs.
3. Add VLAN functionality to the Linux guests.
4. Add VLAN support to the z/OS TCP/IP stacks.
5. Configure the Ethernet switch ports to trunk mode for the OSA-Express ports that
interconnect the z/VM, Linux, and z/OS environments.
Virtual Switch
Virtual Switch
manages and
OSA-Express 2D40 OSA-Express 3D44 OSA-Express
controls VLAN
membership
Authorizing Linux guests access to the virtual switch with VLAN IDs
You must alter the access for the Linux guests to include VLAN capabilities. You do this by
using the MODIFY command.
For our tests, we revoke all access and then authorize each guest to have access to the
virtual switch using the SET VSWITCH command (see Example 12-17). Notice the VLAN
parameters and lack of the PORTTYPE parameter. We adopt the settings from the virtual
switch (default mode from Example 12-16).
To enable VLAN support on the Linux guests, make changes to the interface that represents
the virtual switch. In our case, this is ETH0. First we apply an IP address of 0.0.0.0 to ETH0 to
eliminate any IP address conflicts. Then we add the VLAN IDs with corresponding the IP
address (see Example 12-18).
LNXSU2:
ifconfig eth0 down
ifconfig eth0 0.0.0.0 up
Important: To enable the virtual switch to identify the correct VLAN and IP address
allocated to the Linux guests, it is important to define ETH0 with an IP address of 0.0.0.0
as we did in Example 12-18 with ifconfig eth0 0.0.0 up. Failure to do so results in the
virtual switch incorrectly associating the VLAN ID with the ETH0 interface IP address. By
specifying an IP address of zero, the ETH0 interface presents the appropriate VLAN
interface IP address to the virtual switch.
SC64:
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 200
SC65:
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 300
First we display the virtual switch to verify that our new VLAN information is defined correctly
(see Example 12-21). Notice the VLAN and the Portype information. Toward the bottom of the
display under the Adapter owner sections, the Linux guests now reflect a Porttype of Trunk.
Next we check the virtual switch to see the list of authorized user IDs. In Example 12-22,
notice the VLAN-specific information that is displayed.
We then look at the interface configuration files for LNXSU1 and LNXSU2, respectively. The
changes to look for in these displays are the lack of IP addresses on the ETH0 interface. Only
the VLAN interfaces (subinterfaces) are associated with a valid IP address. The VLAN
interfaces (IDs) use the real interface (ETH0) to communicate with the LAN via the virtual
switch. During this process, the ETH0 interface adopts the IP address of the VLAN interface
to establish connectivity to the virtual switch and beyond.
We then issue PING commands from LNXSU1 and LNXSU2 to the IP addresses assigned to
the appropriate VLAN IDs for SC63, SC64 and SC65, respectively. On all occasions, we
receive a positive response indicating a functional infrastructure between the systems.
Lastly, we try to PING IP addresses that are not defined to the individual VLANs and vice
versa. As anticipated, they are not successful, verifying the intended isolation of the
environment.
Important: If an ESM is in place, the security definitions made by the SET VSWITCH
command are overridden by the ESM definitions.
COUPLE
SPECIAL
NICDEF
YES NO CP
ESM
ESM ACCESS
Installed
LIST
?
Protected NO
Resource
?
YES
YES Connection
YES
Permitted
To check who has access to a virtual switch, use the QUERY VSWITCH command with the
ACCESS option. In Example 12-25, you can see the authorized list of user IDs that can
connect to VSWTCH1.
To grant access to a virtual switch, use the SET VSWITCH GRANT command (see
Example 12-26).
Furthermore, you can grant or revoke access to VLANs identified by a VLAN ID. This means
that you can determine to which VLANs the user can be connected.
Attention: The RACF feature is pre-installed on z/VM version 5.1 and is disabled. Activate
RACF only if you have a valid license. Ensure that service level RSU1 or later is applied.
Otherwise RACF protection does not work properly.
Important: If you don’t have a profile for your virtual switch, the CP ACCESS LIST decides
about the access. See 12.3.1, “Running with CP authorization” on page 224, for more
information.
Furthermore, you can restrict access to a virtual switch especially for use VLANs. In
Example 12-28, we define a RACF profile for virtual switch VSWTCH1and VLAN ID 0001.
This means that only virtual guest machines can connect to VLANid 0001 that have at least a
permission UPDATE to the profile shown in Example 12-29.
If the RACF command is done, the virtual machine can use the CP COUPLE command to
connect to the virtual switch. Otherwise you see an error message as shown in
Example 12-31.
If you want to revoke the user from a virtual switch, use the command shown in
Example 12-32.
Attention: Before you activate the VMLAN class, you must define a profile for each virtual
switch. Otherwise the guests will be unable to contact the virtual switch.
With regard to IPv6 support, the requirements on the respective operating systems are:
z/OS V1R4 or later
z/VM V4R4 or later
Linux on System z9 and zSeries (kernel 2.4.19) or later
For details about IPv6 support for z/VM, refer to the z/VM library at:
http://www.vm.ibm.com/pubs/
For details about IPv6 support for Linux, visit the technical Linux library at:
http://www-128.ibm.com/developerworks/views/linux/library.jsp
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 227
13.1 IPv6
The current IP address space is unable to satisfy the huge increase in the number of users or
the geographical needs of the Internet expansion. In addition there are the requirements of
emerging applications to consider. Such applications include Internet-enabled personal digital
assistants (PDAs), home area networks (HANs), Internet-connected automobiles, integrated
telephony services, and distributed gaming.
IPv6 quadruples the number of network address bits from 32 bits (in IPv4) to 128 bits, which
provides more than enough globally unique IP addresses for every network device on the
planet. The use of globally unique IPv6 addresses simplifies the mechanisms used for
reachability and end-to-end security for network devices. This is functionality that is crucial to
the applications and services that are driving the demand for the IPv6 addresses.
Note: It is not necessary to write the leading zeros in an individual field, but there must
be at least one numeral in every field, except for the case described in item 2.
Due to some methods of allocating certain styles of IPv6 addresses, it is common for
addresses to contain long strings of zero bits. To simplify the writing of addresses that
contain zero bits, a special syntax is available to compress the zeros. The use of “::”
indicates multiple groups of 16 bits of zeros. The “::” can appear only once in an address.
The “::” can also be used to compress the leading or trailing zeros in an address.
Consider the following addresses:
1080:0:0:0:8:800:200C:417A (unicast address)
FF01:0:0:0:0:0:0:101 (multicast address)
0:0:0:0:0:0:0:1 (loopback address)
0:0:0:0:0:0:0:0 (unspecified addresses)
They can be represented as:
1080::8:800:200C:417A (unicast address)
FF01::101 (multicast address)
::1 (loopback address)
:: (unspecified addresses)
An alternative form that is sometimes more convenient when dealing with a mixed
environment of IPv4 and IPv6 nodes is to use x:x:x:x:x:x:d.d.d.d. Here, the x’s are the
hexadecimal values of the six high-order 16-bit pieces of the address. The d’s are the
decimal values of the four low-order 8-bit pieces of the address (standard IPv4
representation).
Consider this example:
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
In compressed form, it is written as:
::13.1.68.3
::FFFF:129.144.52.38
Example: An address of FE80 : : interface ID was added to the OSA Address Table
(OAT) of our OSA-Express feature at start of the device. The interface ID is derived
from the MAC address of the OSA-Express feature.
For more information about the related configuration statements for a particular function, refer
to z/OS V1R6.0 Communications Server: IP Configuration Reference, SC31-8776. For details
about how IPv4 and IPv6 can coexist in a z/OS environment, refer to z/OS V1R6.0 CS: IPv6
Network and Application Design Guide, SC31-8885.
To support IPv4 and IPv6, we added the NETWORK statement shown in Example 13-1 to our
BPXPRMxx.
The TYPE option in our case is CINET, because we are using multiple TCP/IP stacks.
Note: The BPXPRMxx member may be updated dynamically using the z/OS command
SETOMVS RESET=(xx). After this reset, you receive the message “BPXF203I DOMAIN
AF_INET6 WAS SUCCESSFULLY ACTIVATED.” You must recycle the TCP/IP stack to pick up the
change.
For more details about the definitions required in BPXPRMxx to provide a dual IPv4 and IPv6
stack, refer to “Defining TCP/IP as a UNIX System Services physical file system (PFS)” in
z/OS V1R6 CS: IP Configuration Guide, SC31-8775.
You can verify the OSA-Express code level using a VTAM command. See Figure 13-1.
VTAM definitions
Since our OSA-Express 1000BASE-T will operate in QDIO mode, a TRLE is required (see
Example 13-2).
TCP/IP definitions
We add one INTERFACE statement for the OSA-Express 1000BASE-T feature to support
IPv6. This statement merges the DEVICE, LINK, and HOME definitions into a single
statement. Several different parameters are associated with the INTERFACE statement. To
determine which of them best fits your requirements, refer to z/OS Communications Server IP
Configuration Reference Version 1 Release 6, SC31-8776.
Note: To configure a single physical device for both IPv4 and IPv6 traffic, you must use
DEVICE/LINK/HOME for the IPv4 definition and INTERFACE for the IPv6 definition, so that
the PORTNAME value on the INTERFACE statement matches the devicename on the
DEVICE statement.
In the TCP/IP profile for SC64 (see Example 13-3), we add the INTERFACE statement to
implement IPv6 on OSA2180 (portname).
BEGINROUTES
ROUTE FEC0::0/10 = L2180V6 MTU 1492
ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492
START OSA2180
START L2180V6
START OSA21A0
START OSA2360
13.5.1 Verification
We now verify our environment. Since the TRLE must be active before the interface is started,
we ensure that the TRLE is in an active state by using the following command:
D NET,ID,TRL,TRLE=osatrlename
The results are shown in Figure 13-1. You can also verify the OSA-Express code level with
this command.
D NET,TRL,TRLE=TRLE2180
DISPLAY ACCEPTED
NAME = TRLE2180, TYPE = TRLE 631
STATUS= ACTIV, DESIRED STATE= ACTIV
TYPE = LEASED , CONTROL = MPC , HPDT = YES
MPCLEVEL = QDIO MPCUSAGE = SHARE
PORTNAME = OSA2180 LINKNUM = 0 OSA CODE LEVEL = 0616
HEADER SIZE = 4096 DATA SIZE = 0 STORAGE = ***NA***
WRITE DEV = 2181 STATUS = ACTIVE STATE = ONLINE
SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA***
READ DEV = 2180 STATUS = ACTIVE STATE = ONLINE
DATA DEV = 2182 STATUS = ACTIVE STATE = N/A
The following message (for the IPv6 interface) was written to the z/OS console when the
TCP/IP stack was initializing:
EZZ4340I INITIALIZATION COMPLETE FOR INTERFACE L2180V6
If the device does not have a LnkStatus or IntfStatus of Ready, you must resolve this before
you continue. There are several factors that may cause the LnkStatus or IntfStatus to not be
ready. For example, the device may not be defined to z/OS correctly, or the device may not be
defined in the TCP/IP profile correctly, and so on.
Figure 13-3 shows the results of the OAT that was built after starting devices OSA2180 and
L2180V6.
LP 09 (A9)
00(2180) MPC n/a TRLE2180 (QDIO control) SIU ALL
01(2181) MPC n/a TRLE2180 (QDIO control) SIU ALL
02(2182) MPC 00 PRI4 No6 TRLE2180 (QDIO data) SIU ALL
9.12.2.36
192.168.1.164
FEC0::1:0:0:0:3302
FEC0::1001:0:0:0:3302
We use the ping command from various hosts within the network to verify connectivity for
IPv4 and IPv6
ping 192.168.1.164
CS V1R6: Pinging host 192.168.1.164
Ping #1 response took 0.048 seconds.
READY
ping FEC0:0:0:1::3302
CS V1R6: Pinging host FEC0:0:0:1::3302
Ping #1 response took 0.001 seconds
READY
Link-layer device support Y Y IPv4 devices are defined with the DEVICE and LINK configuration
statements. In IPv6, interfaces are defined with the INTERFACE
statement.
Ethernet LAN connectivity Y Y To define an MPCIPA device for IPv4, use the DEVICE statement
using OSA-Express in with the MPCIPA parameter and the LINK statement with the
QDIO mode IPAQENET parameter. For IPv6 traffic, you must configure
OSA-Express2 and OSA-Express features, running in QDIO
mode, by using an INTERFACE statement of type IPAQENET6.
Virtual device/interface Y Y With IPv4, a static virtual device is configured using DEVICE and
configuration LINK statements with the VIRTUAL parameter. An IPv6 virtual
interface is configured with an INTERFACE statement of type
VIRTUAL6.
IP routing functions
Transport-layer functions
Enterprise extender Y N
SMF SMFCONFIG Y Y New Type 119 records are used to collect IPv6-related
information. Related configuration statements:
SMFCONFIG
IP filtering Y N
Appendix A. Commands
This appendix lists the commands that we used to set up and verify the various local area
network (LAN) environments described in this redbook.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 237
z/OS commands
We used the following z/OS commands in this publication. For a complete list and description
of TCP/IP Console and TSO commands, refer to IP Systems Administration Commands,
SC31-8781.
Command Description
D TCPIP Lists TCP/IP stacks that have started since the last
initial program load (IPL) and stack status
Command Description
Command Description
Important: If your static TRLE definition is incorrect, remember that an active TRLE entry
cannot be deleted. In such cases, you can use these steps:
1. Vary activate the TRL node with a blank TRLE to cause the deletion of previous entries.
2. Code the correct TRL with correct TRLE entries and definition.
3. Vary activate this corrected TRL/TRLE node.
Command Description
Q OSA ACTIVE|ALL Displays the status of Open Systems Adapter (OSA) devices
Q PATHS rdev|rdev-rdev Displays the path status to real devices (PIM, PAM, LPM)
SET MITIME rdev|rdev-rdev mm:ss Sets the MIH time for device or devices
VARY OFF|ON CHPID cc Configures a CHPID off or on to both hardware and software
Command Description
NETSTAT OBEY START|STOP DEV Starts or stops the device name identified in NETSTAT DEV
output
IFCONFIG (z/VM4.3) Displays the TCP/IP devices and links (similar to the
NETSTAT DEV command, but has other uses; see note)
Note: IFCONFIG can help to temporarily modify network interfaces in the current TCP/IP stack. Refer
to z/VM TCP/IP Planning and Customization, SC24-6019, for detailed uses. For more information
about the other z/VM TCP/IP commands, refer to z/VM TCP/IP User’s Guide, SC24-6020.
Command Description
QUERY VSWITCH DETAILS Displays detail information about the virtual switch
Tip: You may choose to use the DEFINE NIC and COUPLE approach instead of the
NICDEF z/VM user directory statement. In this case, consider adding these two
commands into your guest’s PROFILE EXEC file so they are automatically executed at IPL
time or whenever the guest logs on.
In this syntax, vdev specifies the base virtual device address for the adapter, and operands
defines the characteristics of the virtual NIC. Operands accepted by the DEFINE NIC
command are listed in Table A-7.
HIPERsockets This operand defines this adapter as a simulated HiperSockets NIC. This adapter
functions similar to the HiperSockets internal adapter. A HiperSockets NIC can
function without a z/VM Guest LAN connection or can be coupled to a HiperSockets
Guest LAN.
QDIO This operand defines this adapter as a simulated QDIO NIC. This adapter functions
similar to the OSA-Express (QDIO) adapter. A QDIO NIC is only functional when it
is coupled to a QDIO Guest LAN.
DEVices devs Determines the number of virtual devices associated with this adapter. For a
simulated HiperSockets adapter, devs must be a decimal value between 3 and 3072
(inclusive). For a simulated QDIO adapter, devs must be a decimal value between
3 and 240 (inclusive). The DEFINE NIC command creates a range of virtual devices
from vdev to vdev + devs -1 to represent this adapter in your virtual machine. The
default value is 3.
CHPID nn A two-digit hexadecimal number that represents the CHPID number that the invoker
wants to allocate for this simulated adapter. If the requested CHPID number is
available, all of the virtual devices belonging to this adapter share the same CHPID
number. This option is useful only if you need to configure a virtual environment with
predictable CHPID numbers for your simulated devices.
Use the COUPLE CP command to attach the virtual NIC to a compatible Guest LAN. The
syntax of the COUPLE command for this scenario is:
COUPLE vdev TO [ operands ]
In this syntax, vdev specifies the base virtual device address for the adapter, and operands
defines where to connect the NIC. Table A-8 lists the operands that are accepted by the
COUPLE command for the purpose of connecting a virtual NIC to a Guest LAN.
ownerid lanname The ownerid is the name of the owner of the Guest LAN (such as SYSTEM).
The lanname is the name of the Guest LAN.
Remember that a virtual NIC can only be coupled to a compatible Guest LAN. For example, a
QDIO NIC cannot be coupled to a Guest LAN of type “HiperSockets”
Command Description
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 243
HMC advanced facilities for OSA-Express
The advanced facilities (Open Systems Adapter Support Facility (OSA/SF)) are available on
the HMC are as follows.
Note: These functions are used for troubleshooting under the guidance of IBM Product
Engineering.
Online help is available for each function on the HMC or the SE. You can activate the online
help in two ways:
By clicking Help on the active window
By pressing F1 on the keyboard
To gain access to the advanced facilities, log on at the HMC in system programmer mode
(Figure B-1).
3. In the Single Object Selection window (Figure B-3), you are prompted to select the
appropriate CPC. Then click OK.
Note: Enabling or disabling the port is also possible with an OSA/SF function.
Two tasks are related to the enable or disable port function. The first task enables or disables
the port. The second task sets the control of enabling and disabling the port either to its
Support Element, or to both the Support Element and Open Systems Adapter Support
Facility (OSA/SF).
Note: You can use port diagnostics only if the port is disabled.
Note: The settings made here override the capability of the OSA-Express FENET auto
negotiation facility.
The sequence to gain access to the CHPID functions is described in the following section.
The Advanced Facilities icon from the Support Element is placed under the CHPID Operation
in the Tasks Area. To start the advanced facilities, you drag the desired CHPID icon and drop
it over the Advanced Facilities icon.
This information can be useful in the diagnosis of an OSA-Express related problem. You may
be asked by the IBM Remote Technical Support Center, or your IBM Systems Services
Representative (IBM CE) for the OSA-Express code level as part of information gathering to
analyze a problem.
1. In the OSA Advanced Facilities, select View Code Level
2. Then click OK. The View Code Level panel is displayed (see Figure B-17).
The four digit code displayed will vary depending on the specific microcode EC and MCL
level active in the OSA-Express feature. The code will change as microcode maintenance
updates are applied to your System z9 or zSeries server by your IBM CE.
3. On the View Code Level panel, click OK. The Advanced Facilities panel is displayed.
You are unable to configure channels offline to the whole system with one command from an
operator console when you are running in logical partition (LPAR) mode. We explain the
procedure that is used from the HMC to configure a CHPID off or on for all LPARs.
3. In the CPC CHPIDs Work Area, drag the appropriate OSA-Express CHPID object and
drop it onto the Configure On/Off icon. An alternative is to highlight the CHPID and then
double-click the Configure On/Off icon.
4. The Configure On/Off window (Figure B-21) opens. The Current state column shows the
status of the channel for each logical partition.
Note: The state Standby is the indicator of an offline CHPID to the LPAR.
Attention: Before you click Apply in the next step, ensure that only the CHPID or
CHPIDs that you want toggled are highlighted.
b. In all cases, click Apply to immediately change the desired channel state.
5. The Configure On/Off Progress window briefly displays the message “In progress.” When
the message changes to “Complete”, click OK.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 263
RMF for OSA-Express
RMF reports that are associated with OSA-Express are:
Monitor II Channel Path Activity Report
Monitor I/Postprocessor Channel Path Activity Report
Postprocessor Overview Reporting/Recording
Measurements are contained in SMF Record Type 79(13) and are available through the
ERBSMFI interface. SMF has been implemented with the field R79CACR, which contains the
channel path acronym.
For OSA-Express CHPIDs (device types OSD and OSE), IBM has expanded the support for
performance information by supporting the Extended CPMF, which allows the user to better
understand what is occurring within the three main components of OSA-Express:
Processor utilization
Physical PCI bus utilization
The bandwidth per port (both read and write directions)
The Channel Path Measurement Facility (CPMF) provides information about CHPIDs on a
per-image basis. The Extended CPMF offers the enhancements that supply more data about
the new channel types.
For more information, refer to Resource Measurement Facility User’s Guide, SC28-1949.
For more information, see z/OS Resource Measurement Facility Report Analysis,
SC33-7991.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 267
Creating the OSA configuration
The Opens System Adapter (OSA) configuration in the TSO environment is built with two
z/OS sequential data sets. They contain statements that describe the Opens System
Adapter-Express (OSA-Express) configuration and the OSA Address Table (OAT).
2. Copy the required parts of the OAT entry obtained into a new data set.
Note: Only the even unit address entries are required for TCP/IP Passthru entries.
3. Update the OAT records for your logical partitions (LPARs) with the unit address, port
mode and port number, default entry indicator, and IP address for each required device.
– Partition: Enter the partition number that is used for that entry. If you are running in
basic mode or if the CHPID is dedicated, the partition number is 0.
– UA: The unit address can be any even address for TCP/IP Passthru, but unit address
00,01 is associated with OSA port 0 in the default OAT. Unit address 0A is usually
associated with OSA port 0 in SNA mode.
Note: Port 1 can be accessed and configured only for the OSA-Express 155 ATM
feature running in LAN Emulation mode. Even though ATM has only one physical
port, you can configure it as two logical ports.
The OSA port unit address was used by HCD when defining the OSA devices.
Note: Port 1 can be accessed and configured only for the OSA-Express 155 ATM
feature running in LAN Emulation mode. Even though this feature is just one
physical port, you can configure it as two logical ports.
– Default: Enter PRI or SEC to make this the primary or secondary entry for this port, or
enter no if it is neither the primary or secondary entry.
The entry designated as the primary receives any datagrams that are not specifically
addressed to any of the home IP addresses associated with this OSA port. The
secondary entry overtakes that function if the primary entry is not running.
– IP Address: Enter the home IP address for the port and unit address. Any time an
OSA port (in TCP/IP Passthru mode) is shared, each partition’s TCP/IP home IP
address must also be added to the OAT. This allows the OSA feature to forward the
received datagrams to the appropriate partition.
4. Update the OAT records for your other LPARs with the unit address, port mode, port
number, partition number, default entry indicator, and IP address for all devices in a similar
way as described for the first partition. However, this time, substitute the appropriate
addressing for your partitions.
Example D-3 shows an OAT file running in two partitions: 5 and 7. One TCP/IP stack is
running in each partition. UNITADD is defined in both partitions with a value of 00. Shared
SNA mode is defined for both partitions using UNITADD 02.
Note: The TSO user ID must be set up to use the OSA/SF TSO interface.
IOACMD: Enter
'quit' to end IOACMD
IOACMD: Enter
0 for help
IOACMD: Enter
1 to configure an OSA-2 ATM CHPID
IOACMD: Enter
2 to configure an OSA-2 FDDI, ENTR, fast Ethernet CHPID
IOACMD: Enter
3 to configure an OSA-Express gigabit Ethernet CHPID
IOACMD: Enter
4 to configure an OSA-Express ATM CHPID
IOACMD: Enter
5 to configure an OSA-Express fast Ethernet or
an OSA-Express 1000Base-T Ethernet CHPID
IOACMD: Enter 6 to configure an OSA-Express token ring CHPID
IOACMD: Enter a blank line to get a list of valid OSA CHPIDs
IOACMD: 0 - Quit
IOACMD: 1 - Activate
IOACMD: Sets up all the files and transfers the data to the CHPID
Refer to Open Systems Adapter-Express Customer’s Guide and Reference, SA22-7935, for
details about using OSA/SF.
As mentioned, Example D-4, Example D-5, and Example D-6 on page 274 show sample
configuration files.
/*======================================================================
sna.0.1 = Configuration name /* Configuration name (32-char max)
sna.0.2 = 90.00 /* Inactivity timer (ti)
/* .24-90 in increments of .12
/* 0 disables the inactivity timer
sna.0.3 = 10.00 /* Response timer (t1)
/* .20-51 in increments of .20
sna.0.4 = 1.04 /* Acknowledgement timer (t2)
/* .08-20.4 in increments of .08
sna.0.5 = 4 /* N3 (1-4)
sna.0.6 = 8 /* TW (1-16)
/*======================================================================
sna.0.7 = 6 /* Enhanced availability type
sna.0.8 = 0.00 /* Load balance factor (0-1)
sna.0.9 = 0.00 /* Session delay (0-15)
/*======================================================================
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 277
Sample environment
Figure E-1 is a logical representation of the environment used for the definition examples.
zSeries CEC
HiperSockets - EF
TCPIPD TCPIPE
2180-2182 (09) 2180-2182 (09)
192.168.1.64 192.168.1.65
7304-7306 7308-730A
(HS-EF)
2360-2362 (0B) 2360-2362 (0B)
(HS-EF) 192.168.1.5
10.10.1.60 10.10.1.61
192.168.1.4
21A0-21A1 (0E) 21A0-21A1 (0E)
2180-2182 2184-2186 2188-218A 9.12.2.37
9.12.2.36
192.168.1.60 192.168.1.61 192.168.1.62
TCP/IP profiles
The TCP/IP profile for SC64 (Example E-1) only shows the lines that we added or changed.
INTERFACE L2180V6 DEFINE IPAQENET6 PORTNAME OSA2180 ; IPv6 definition for CHPID09
IPADDR FEC0:0:0:1::3302
FEC0:0:0:1001::3302
HOME
192.168.1.64 SC642180LINK
192.168.1.4 SC642360LINK
192.168.1.164 VLINK1
10.10.1.64 HIPERLEF
9.12.2.36 SC6421A0LINK
BEGINROUTES
ROUTE FEC0::0/10 = L2180v6 MTU 1500
ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492
ROUTE 192.168.1.0/24 = SC642360LINK MTU 1492
ROUTE 9.12.2.0/24 = SC6421A0LINK MTU 2000
ROUTE 10.10.1.0/24 = HIPERLEF MTU 16384
ROUTE DEFAULT 192.168.1.64 SC642180LINK MTU 1492
ENDROUTES
START IUTIQDEF
START IUTSAMEH
START OSA2180
START L2180V6
START OSA21A0
START OSA2360
INTERFACE L2180V6 DEFINE IPAQENET6 PORTNAME OSA2180 ; IPv6 definition for CHPID 09
IPADDR FEC0:0:0:1::3365
HOME
192.168.1.5 SC652360LINK
192.168.1.65 SC652180LINK
192.168.1.165 VLINK1
10.10.1.65 HIPERLEF
9.12.2.37 SC6521A0LINK
BEGINROUTES
ROUTE FEC0::0/10 = L2180v6 MTU 1492
ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492
ROUTE 192.168.1.0/24 = SC642360LINK MTU 1492
ROUTE 9.12.2.0/24 = SC6521A0LINK MTU 2000
ROUTE 10.10.1.0/24 = HIPERLEF MTU 16384
ROUTE DEFAULT 192.168.1.5 SC652360LINK MTU 1492
ENDROUTES
START OSA2360
START OSA2180
START L2180V6
START OSA21A0
START IUTIQDEF
VTAM definitions
This section presents examples of VTAM definitions used for OSD and Enterprise Extender.
Example E-10 and Example E-11 contain only the lines that we changed or added to support
Enterprise Extender.
Linux definitions
This section includes examples of the definitions that we used in our Linux guests.
Example E-12 has changed or added lines in modules.conf (the same in both Linux guests).
Example E-13 and Example E-14 show only the lines that we added or changed in the
chandev.conf files.
The next two examples only show the lines that we added or changed in the rc.config file.
192.168.1.62 OSA2188L
10.10.1.62 HIPERLEF
;
GATEWAY
; (IP) Network First Link Max. Packet Subnet Subnet
; Address Hop Name Size (MTU) Mask Value
; ----------- ------------ ------- ----------- ----------- --------
;
; THESE ARE THE CURRENT GATEWAYS THAT ARE BEING USED TODAY IN PRODUCTION
192.168.1 = OSA2188L 1500 0
10 = HIPERLEF 8192 0.255.255.0 0.10.1.0
;
START HIPERDEF
START OSA2188
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 285
HiperSockets Accelerator description
HiperSockets Accelerator allows a z/OS TCP/IP router stack to efficiently route IP packets
from an OSA-Express (QDIO) interface to a HiperSockets (iQDIO) interface and vice versa.
The routing is done by the IBM Communications Server for z/OS device drivers at the lowest
possible software data link control level. IP packets do not have to be processed at the higher
level TCP/IP stack routing function, reducing the path-length and improving performance.
The TCP/IP routing stack creates IQDIORouting route entries for packets for which it is not
the destination stack. These entries are added to the IQDIORouting table. The destination
stack must be reachable through HiperSockets.
All subsequent packets for the same destination take the optimized device driver path, and do
not traverse the routing function of the TCP/IP routing stack. No change is required for target
stacks. A timer is built into the HiperSockets Accelerator function.
Note: If any IP packets need to be fragmented for routing between QDIO and iQDIO, then
they are not accelerated and the normal path through the TCP/IP stack routing function is
taken. IP fragmentation conflicts can be prevented, by using path MTU discovery, or by
coding the appropriate MTU size in the static route statement.
For details about defining MTU discovery and MTU sizes, refer to z/OS Communications
Server, IP Configuration Reference, SC31-8776.
Figure F-1 shows our network configuration and the HiperSockets Accelerator flow.
QDIO iQDIO
Device Driver VTAM Device Driver
CHPID EF
HiperSockets
iQDIO LAN
External LAN 10.10.1.64
192.168.1.64
OSA-Express
CHPID 09 Accelerated
QDIO - iQDIO routing
Linux 2
TCP/IP
10.10.1.60
192.168.1.10
HiperSockets definitions
Implementation of HiperSockets Accelerator is quite simple as indicated by our sample
TCP/IP profile in Example F-1.
HOME
192.168.1.64 SC642180LINK
10.10.1.64 HIPERLEF
BEGINROUTES
ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492
ROUTE 10.10.1.0/24 = HIPERLEF MTU 16384
ROUTE DEFAULT 192.168.1.64 SC642180LINK MTU 1492
ENDROUTES
START IUTIQDEF
START OSA2180
D TCPIP,TCPIPD,N,CONFIG
EZD0101I NETSTAT CS V1R4 TCPIPD 841
TCP CONFIGURATION TABLE:
DEFAULTRCVBUFSIZE: 00016384 DEFAULTSNDBUFSIZE: 00016384
.
.
.
IQDIOROUTE: YES QDIOPRIORITY: 1
D NET,TRL,TRLE=IUTIQDEF
IST097I DISPLAY ACCEPTED
IST075I NAME = IUTIQDEF, TYPE = TRLE 881
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES
IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE
IST1716I PORTNAME = LINKNUM = 0 OSA CODE LEVEL = D3GF
IST1577I HEADER SIZE = 4096 DATA SIZE = 65536 STORAGE = ***NA***
IST1221I WRITE DEV = 7301 STATUS = ACTIVE STATE = ONLINE
IST1577I HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA***
IST1221I READ DEV = 7300 STATUS = ACTIVE STATE = ONLINE
IST1221I DATA DEV = 7302 STATUS = ACTIVE STATE = N/A
IST1724I I/O TRACE = OFF TRACE LENGTH = *NA*
IST1717I ULPID = TCPIPD
IST1814I IQDIO ROUTING ENABLED
To verify that it works, we must communicate between the IP network on the OSA-Express
card and the IP network on the HiperSockets CHPID. Figure F-5 shows the HiperSockets
routing table before any communication has taken place.
D TCPIP,TCPIPD,N,ROUTE,IQDIO
EZD0101I NETSTAT CS V1R4 TCPIPD 874
IPV4 DESTINATIONS
DESTINATION GATEWAY INTERFACE
0 OF 0 RECORDS DISPLAYED
Since our workstation has multiple network adapters connected to different networks, we had
to build an indirect route from the 192.168.1 network to the 10 network. We accomplished this
using the command shown in Figure F-6.
From the workstation, we did a ping through the 192.168.1 network to our two Linux guests
on the HiperSockets 10 network to dynamically build the HiperSockets routing table.
Figure F-7 shows the results.
D TCPIP,TCPIPD,N,ROUTE,IQDIO
EZD0101I NETSTAT CS V1R4 TCPIPD 902
IPV4 DESTINATIONS
DESTINATION GATEWAY INTERFACE
10.10.1.60/0 10.10.1.60 HIPERLEF
10.10.1.61/0 10.10.1.61 HIPERLEF
2 OF 2 RECORDS DISPLAYED
The HiperSockets routing table is short lived. After about 90 seconds of no use, the display
once again looks like the example in Figure F-5.
For more implementation information about HiperSockets and HiperSockets Accelerator, refer
to zSeries HiperSockets, SG24-6816.
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 291
ARP Takeover description
ARP Takeover is a mechanism that allows traffic to be redirected from a failing Open Systems
Adapter-Express (OSA-Express) connection to another OSA-Express connection. When
TCP/IP is started, all of the IP addresses for devices defined as connecting to an
OSA-Express feature in QDIO mode (device type MPCIPA in the TCP/IP profile) are
dynamically downloaded to the OSA-Express card. If the OSA-Express card is running in
non-QDIO mode (device type LCS in the TCP/IP profile), then you must use OSA/SF to build
and activate a configuration that identifies the multiple IP addresses that are used with this
feature.
The OSA-Express card maintains the ARP table for all of the IP addresses to which it is
connected. Maintaining the ARP table within the OSA-Express card improves performance,
since fewer I/O operations are required to direct IP traffic to the desired destination.
Figure G-1 illustrates our test environment for ARP Takeover. We defined CHPID 09 and 0B
as OSD-type CHPIDs.
z/OS -SC64
TCPIPD
CHPID 09 CHPID 0B
OAT OAT
192.168.1.4 192.168.1..64
192.168.1.64 192.168.1.4
MAC ADDR
6296CA5BC MAC ADDR
6296C3690
SWITCH
C : \ ping 192.168.1.64
192.168.1.10
TCP/IP definitions
Example G-1 shows the items that we changed or added in our TCP/IP profile for ARP
Takeover support.
BEGINROUTES
ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492
ROUTE 192.168.1.0/24 = SC642360LINK MTU 1492
ROUTE DEFAULT 192.168.1.64 SC642180LINK MTU 1492
ROUTE DEFAULT 192.168.1.64 SC642360LINK MTU 1492
ENDROUTES
In the IPCONFIG statement, we added MULTIPATH to allow multiple path definitions to the
same network (or subnetwork). A DEVICE and LINK statement was needed for each of the
two OSA-Express features that we will switch between for the test. Notice the ROUTE
statements that define two paths to get to the same network.
Warning: Spantree port fast start should only be enabled on ports connected to
a single host. Connecting hubs, concentrators, switches, bridges, etc. to a
fast start port can cause temporary spanning tree loops. Use with caution.
Note: The results documented here are for our test with a specific switch. You should
consult the documentation provided by the manufacturer of your switch to determine the
requirements to support ARP Takeover.
zSeries CEC
z/OS -SC64
TCPIPD
CHPID 09 CHPID 0B
OAT OAT
192.168.1.4 192.168.1..64
192.168.1.64 192.168.1.4
MAC ADDR
6296CA5BC MAC ADDR
6296C3690
SWITCH
C : \ ping 192.168.1.64
192.168.1.10
Figure G-3 shows the contents of the ARP cache on a Windows workstation after pinging
each of IP address defined in TCPIPD before any error condition was introduced.
C:\>arp -a
Figure G-4 shows the contents of the ARP table from the OSA-Express cards before any
error condition was introduced.
We pulled the CAT5 cable that connects the Fast Ethernet port of CHPID 09 from the switch.
Figure G-5 shows the resulting messages from the z/OS console.
Figure G-5 z/OS console messages after pulling CHPID 09 CAT5 cable
Figure G-6 shows the contents of the ARP cache of the workstation after pulling the cable for
CHPID 09.
C:\>arp -a
Figure G-6 Workstation ARP cache after pulling CHPID 09 CAT5 cable
Notice that both IP addresses now point to the same MAC address, which is associated with
CHPID 0B. Nothing had to be done at the workstation to update ARP cache. The TCP/IP
running on z/OS initiated a gratuitous ARP to all hosts on the LAN when it was notified that
the connection on CHPID 09 was lost.
Figure G-7 z/OS TCP/IP ARP table after CAT5 cable for CHPID 09 pulled
Notice that there is no change yet in the MAC addresses in this ARP table. After a few
minutes, the ARP table contained entries associating the same IP address with both MAC
addresses, as shown in Figure G-8.
Figure G-8 z/OS TCP/IP ARP table minutes after CAT5 cable for CHPID 09 pulled
Then we cleaned up the ARP table by using the purgecache command available with z/OS
1.4. Figure G-9 shows an example of the command.
V TCPIP,TCPIPD,PURGECACHE,SC642180LINK
EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,PURGECACHE,SC642180LINK
EZZ9786I PURGECACHE PROCESSED FOR LINK SC642180LINK
EZZ0053I COMMAND PURGECACHE COMPLETED SUCCESSFULLY
When the CAT5 cable was plugged back into the switch, we received the messages shown in
Figure G-10 at the z/OS operator’s console.
Another gratuitous ARP was issued by TCPIPD to the hosts on the LAN that updated the
ARP cache with the correct MAC addresses. On our Windows workstation, the gratuitous
V TCPIP,TCPIPD,STOP,OSA2180
EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,STOP,OSA2180
EZZ0053I COMMAND VARY STOP COMPLETED SUCCESSFULLY
EZZ4315I DEACTIVATION COMPLETE FOR DEVICE OSA2180
EZZ4329I LINK SC642360LINK HAS TAKEN OVER ARP RESPONSIBILITY FOR
INACTIVE LINK SC642180LINK
A gratuitous ARP was sent, and the changes to the ARP tables were identical to those shown
in Figure G-6 and Figure G-7.
V TCPIP,TCPIPD,START,OSA2180
EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,START,OSA2180
EZZ0053I COMMAND VARY START COMPLETED SUCCESSFULLY
EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180
Once again, the gratuitous ARP was sent to update existing ARP cache entries to the correct
MAC addresses.
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this redbook.
IBM Redbooks
For information about ordering these publications, see “How to get IBM Redbooks” on
page 300. Note that some of the documents referenced here may be available in softcopy
only.
Network and e-business Products Reference booklet, GX28-8002
Using the IBM S/390 Application StarterPak, SG24-2095
SNA in a Parallel Sysplex Environment, SG24-2113
IBM System z9 and Eserver zSeries Connectivity Handbook, SG24-5444
Migrating Subarea Networks to an IP Infrastructure Using Enterprise Extender,
SG24-5957
IBM Communication Controller Migration Guide, SG24-6298
OSA-Express Integrated Console Controller Implementation Guide, SG24-6364
zSeries HiperSockets, SG24-6816
Linux on IBM Eserver zSeries and S/390: VSWITCH and VLAN Features of z/VM 4.4,
REDP-3719
Other publications
These publications are also relevant as further information sources:
z/OS MVS Initialization and Tuning Reference
Open Systems Adapter-Express Customer’s Guide and Reference, SA22-7403
zSeries: Open Systems Adapter-Express Customer’s Guide and Reference, SA22-7476
zSeries: Open Systems Adapter-Express Customer’s Guide and Reference, SA22-7935
z/OS Open Systems Adapter Support Facility User’s Guide, SC28-1855
Resource Measurement Facility Report Analysis, SC28-1950
VSE/ESA Open Systems Adapter Support Facility User’s Guide, SC28-1946
Resource Measurement Facility User’s Guide, SC28-1949
VM/ESA Open Systems Adapter Support Facility User’s Guide, SC28-1992
z/OS Resource Measurement Facility Report Analysis, SC33-7991
Communications Server: IP Configuration, SC31-8513
Communications Server: SNA Network Implementation Guide, SC31-8563
Communications Server: IP Systems Administration Commands, SC31-8781
Communications Server: IP Configuration Guide, SC31-8775
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 299
Communications Server: IP Configuration Reference, SC31-8776
Communications Server SNA Resource Definition Reference, SC31-8778
Communications Server: IPv6 Network and Application Design Guide, SC31-8885
z/VM Connectivity Version 5 Release 1, SC24-6080
z/VM CP Command and Utility Reference, SC24-6008
z/VM TCP/IP User’s Guide, SC24-6020
z/VM TCP/IP Planning and Customization, SC24-6019
Online resources
These Web sites and URLs are also relevant as further information sources:
System z9 and zSeries Networking
http://www.ibm.com/servers/eserver/zseries/networking/
System z9 and zSeries Networking white papers
http://www.ibm.com/servers/eserver/zseries/networking/wpapers.html
IBM Resource Link
http://www.ibm.com/servers/resourcelink/
© Copyright IBM Corp. 2000, 2001, 2003, 2005. All rights reserved. 301
CHPID F6 124, 142 Express Logon Facility (ELF) 20
Configuration list 144 external communications adapter (XCA) 8, 102, 173
IOCDS input 124 External Security Manager (ESM) 201, 223
CHPID number 72, 211, 238
class of service 167
CNTLUNIT CUNUMBR 58, 93, 103, 124, 142 F
command Fast Ethernet (FENET) 1–2, 44, 268
Linux for zSeries TCP/IP 242 FE,C UNUMBR 58, 93, 103, 124, 142
Linux z/VM Virtual Switch 241 FENET (Fast Ethernet) 1, 44, 268
TCP/IP for z/VM 240 flow and congestion control (enhanced) 169
TCP/IP operations for z/VM 240 FTP 64
TSO 239
z/OS 238 G
z/VM 240 GbE LR 42
z/VM Virtual Switch 241 Get and GetNext request 14
configuration name 105, 126, 144, 272 Gigabit Ethernet 2
configuration statement 204, 231 graphical user interface (GUI) 59
control point (CP) 157 gratuitous ARP 16, 295
Control Program (CP) 202–203 grep driver 205
control unit 47, 80, 92, 103, 124, 142 guest system 44, 80, 200, 202–203
definition 52 network connectivity 205
Q NIC DETAILS command 213
D virtual NIC 203
datapath 55
address 82 H
DED 50 Hardware Configuration Definition (HCD) 47–48, 58, 80,
Dependent LU Request (DLUR) 174 91–92, 101, 123, 141
Dependent LU Server (DLUS) 175 Hardware Management Console (HMC) 106, 243
device definition 54 HCD (Hardware Configuration Definition) 47–49, 58, 80,
device number 54, 84, 97, 115, 119, 131, 153 91–92, 101, 123, 141
last 2 digits 55 High Performance Data Transfer (HPDT) 8, 106, 123
DEVICE OSA2180 MPCIPA PRIRouter 233, 279, 287, high-performance routing (HPR) 168
293 HiperSockets Accelerator 285
DEVICE statement 82, 126, 157, 232 HMC (Hardware Management Console) 243
device type 23, 45, 54, 96, 119, 158 HPDT 123
device/processor definition 55 MPC 127
Direct Memory Access 5 HPDT (High Performance Data Transfer) 106, 123
DIX 26–29 HPDT ATM 8
DLUR (Dependent LU Request) 174 HPDT MPC 8
DLUS (Dependent LU Server) 175 HPR 19, 32, 34, 165
DMA 5 HPRIP 177
dot3StatsTable 14 hybrid mode 185
duplex mode 158
I
E I/O definition file (IODF) 49
EE (Enterprise Extender) 19 IEEE 802.1q
ELF (Express Logon Facility) 20 standard 183
End Node (EN) 171 VLANs 184
end system ID (ESI) 126, 144 inbound packet 16, 187
Enterprise Extender (EE) 19, 44, 89, 165, 236, 279 IP header checksums 16
important aspect 166 information provided (IP) 165
VTAM definitions 281 installer in providing (IP) 42
ESM (External Security Manager) 201, 223 installing OSA/SF 59
Ethernet frame 10, 202 Internet Protocol assist (IPA) 6
Ethernet mode 203 IOAENTR 268
Ethernet switch 81, 97, 115, 187, 205, 215 IOAOSHRA 268
access port 196 IOAOSHRS 268
VLAN functionality 205 IOAOSHRT 268
even device number 119 IOCDS 47, 58, 80, 92, 124, 142, 288
Index 303
networking, policy-based 43 channel on/off 256
NIC (network interface card) 210, 241 default mode 92
NICDEF statement 204 exception for token-ring feature 84
non-QDIO 3–4, 101 features 28
non-QDIO mode 42, 60, 91, 101, 123, 141, 267, 292 MAC address of defined port 106
default IP 60 Port 97
OSA-Express features 42 Token Ring 2
non-shared mode 91 OSA-Express 1000BASE-T settings 27, 29–30
OSA-Express Address Table (OAT) 189
OSA-Express ATM CHPID 271
O OSA-Express card 97, 119, 288, 292
OAT (OSA Address Table) 16, 255, 268 ARP table 292
dynamic 6 IP network 289
OAT default status display 99 OSA-Express CHPID 42, 82, 92, 103, 256
Open Systems Adapter Support Facility (OSA/SF) 4, 59, new support 264
101 One TRLE 82
OSA Address Table (OAT) 92, 102, 255, 268 OSA-Express connection 191, 220, 292
multiple IP addresses 16 Ethernet switch ports 220
OSA configuration 102, 111, 268 trunk port 191
file 113, 272 OSA-Express device 23, 176, 202
OSA name 133 OSA-Express Ethernet
port name 132 connection 206
OSA device 80, 92, 103, 124, 142, 158, 203, 235, 240, feature 183, 201
269 port 205
Display status 240 OSA-Express feature 42, 47, 59, 79, 84, 91, 101, 105,
START command 158 141, 153, 165, 189, 227, 230, 267
OSA feature 105, 125–126, 144, 270 ARP cache information 16
active sessions 271 CAT5 cable 294
OSA name 125 MAC address 106
OSEF6 131 network connectivity 79
OSA port 110, 126, 144, 269 TCP/IP profile definitions 85
DEVICE statement 158 OSA-Express link 23
Ethernet LAN 153 OSA-Express port 42, 92, 102, 171, 187, 206
HOME IP address 158 active session 111
MAC address 114 DEVICE statement 119
permanent virtual circuit 128 Ethernet frame 202
OSA/SF 4, 42, 244 Ethernet LAN 115
GUI setup 63 HOME IP address 119
profile 62 MAC address 114
REXX 59 SNA applications 171
set up 62 trunk mode 217
TCP/IP 62 OSA-Express2
OSA/SF GUI 59, 63, 93, 104, 125, 143 concurrent LIC update 7
and very useful function 76 feature 191
code 65, 125, 143 features 26
OSA configuration 125 OSC 3, 50
OSA feature configuration 104 OSD 3, 50
program 93, 104, 125, 143 OSE 3, 50, 101
TCP/IP connection 65 activation 98
window OSA CHPIDs 131, 152 SNA definition 109
OSA/SF host switched major node 117
connection 125, 143 TCP/IP definitions 107
system 65 TCP/IP profile 98
OSA-2 cabling requirements 23 VTAM setup 115
OSA-2 FENET OSN 3
maximum length 29–30
OSAD 23, 61
OSAD device 56, 86, 102, 152, 271 P
unit address FE 56 PAGENT 43
OSA-Express 2 partial activation 32–33, 126, 144
155 ATM feature in HPDT mode 123 permanent virtual circuit (PVC) 128
Index 305
configured VLAN IDs 189 VLAN 200 188
maximum 51 VLAN capability 215
untagged traffic 187 virtual switch 215
TN3270E Server 19, 89 VLAN ID 13, 18, 183, 187, 217
Token Ring, OSA Express feature 2 300 192
token ring, USE RING 116 OSA-Express registration process 183
token-ring configuration file 268 parameter 219
token-ring LAN 1 tag 185
token-ring LAN emulation (TR LANE) 143 value 187
TR LANE (token-ring LAN emulation) 143 VLAN ID 1 187
trace function 247 VLAN ID virtual switch 217
Transmission Control Protocol (TCP) 166 VLAN support 11, 187, 190, 205
Transport Resource List (TRL) 82, 127 Layer 2 support 205
Traps and Set 14 Layer 2 virtual switch configuration 215
TRLE 80, 84, 125, 232, 239 Linux 13
considerations 82 z/OS 12
trunk mode 184, 215, 293 z/VM 12
trunk port 184, 191 VLAN-aware 198
Type of Service (TOS) 236 VLAN-unaware 198
type of traffic 3 VPI (virtual path indicator) 128
VSWITCH VSWTCH1
GRA LNXSU1 VLAN 101 218
U GRA LNXSU2 VLAN 101 218
UDP packet 168 GRANT LNXSU1 210
UNI (User-to-Network Interface) 32, 34 GRANT LNXSU2 210
unit address 53, 95, 102, 269 GRANT LNXSU3 210
untagged frames 186 vswitch vswtch1 acc 221
USE RING for token ring 116 vswitch vswtch1 access 212
User-to-Network Interface (UNI) 32, 34 vswitch vswtch1 det 220
VTAM commands 239
V VTAM definition 45, 79, 102, 124, 173, 232, 277
V TCPIP,PURGECACHE command 236 VTAM resource 86, 98, 120, 135, 159, 176
VCI (virtual channel indicator) 128
view code level 256 W
VIPA wizard 43
Takeback 9
Takeover 9
virtual channel indicator (VCI) 128 X
virtual IP address (VIPA) 170 XCA 173
virtual machine 203, 241 XCA (external communications adapter) 8, 102, 173
user ID 211 XCA MAJNODE 115, 153, 176
virtual path indicator (VPI) 128 XCA major node 19, 115, 125, 153, 173
virtual switch 44
configuring a controller 206
controller 202 Z
detail information about 241 z/OS 59, 81, 93, 104, 125, 143, 227, 295
display information about 241 VLAN support 191
Layer 2 functionality 215 z/VM
Layer 2 support 202 TCP/IP command 240
MAC address 204 TCP/IP operations commands 240
OSA-Express devices 202 user directory 203
RACF profile 225 z/VM V5.1 44, 187
RACF security 225 z/VM Virtual Switch
VLAN capabilities 215 commands 241
VLAN connectivity 217 Layer 2 support 201
VLAN 183–184, 187, 193, 217 VLAN support 198
connectivity 17 zSeries server 48, 92, 106, 204, 243
design rules 187 not supported option 106
implementation 191, 194
isolation 186
OSA-Express
Implementation Guide
Product, planning, This IBM Redbook helps you to install, tailor, and configure the
Open Systems Adapter-Express (OSA-Express) features that are
INTERNATIONAL
and quick start
available on IBM System z9 and IBM Eserver zSeries servers TECHNICAL
information
(System z9 109 and zSeries 990, 890, 900, and 800). It focuses SUPPORT
on the hardware installation and the software definitions that you ORGANIZATION
Realistic examples
and considerations need to provide connectivity to various LAN environments. It
provides information to help you with planning and system setup.
It also includes helpful utilities and commands for monitoring and
Hardware and managing the OSA-Express features.
software setup BUILDING TECHNICAL
definitions INFORMATION BASED ON
The target audience for this redbook is system engineers, PRACTICAL EXPERIENCE
network administrators, and system programmers who will plan
for and install OSA-Express. Prior to reading this redbook, you IBM Redbooks are developed
must have a solid background in System z9 and zSeries by the IBM International
hardware, HCD or IOCP, OSA/SF, SNA/APPN, and TCP/IP. Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.