0% found this document useful (0 votes)
140 views324 pages

sg245948-04 OSA Implem

Uploaded by

Antoni
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
140 views324 pages

sg245948-04 OSA Implem

Uploaded by

Antoni
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 324

Front cover

OSA-Express
Implementation Guide
Product, planning, and quick
start information

Realistic examples and


considerations

Hardware and software


setup definitions

Bill White
Hubert Kordmann
Joel Porterie
Rudi Van Niekerk
Thomas Wienert

ibm.com/redbooks
International Technical Support Organization

OSA-Express Implementation Guide

October 2005

SG24-5948-04
Note: Before using this information and the product it supports, read the information in “Notices” on
page ix.

Fifth Edition (October 2005)

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

Chapter 1. Overview of Open Systems Adapter-Express . . . . . . . . . . . . . . . . . . . . . . . . 1


1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Non-QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 OSA-Express elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Virtual IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Primary/secondary router function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.3 IPv6 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 Large send for TCP/IP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.5 VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.6 SNMP support for z/OS and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.7 TCP/IP multicast and broadcast support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.8 ARP cache management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.9 Enhanced IP network availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.10 Checksum offload support for z/OS and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.11 Layer 2 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.12 SNA enhanced availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.13 Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.14 TN3270E Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.15 Communications controller migration support. . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.16 OSA/SF support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.1 OSA-Express features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Software support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.3.3 Resource Measurement Facility enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 2. Quick start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41


2.1 OSA-Express definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2 OSA/SF requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3 Policy-based networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4 TCP/IP quick start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Quick start tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5.1 Notes regarding the quick start tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6 Linux definitions: Updating files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 3. Hardware configuration definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


3.1 Configuration chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

© 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

Chapter 4. Setting up and using OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59


4.1 Setup requirements and overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Setting up OSA/SF in z/OS or z/OS.e environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1 Setting up APPC and VTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.2 Setting up OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3 Communicating with OSA/SF using TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Installing OSA/SF GUI on a workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.1 Checking the hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2 Checking the software configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.3 Downloading and installing the Java runtime and JavaHelp files . . . . . . . . . . . . . 64
4.3.4 Downloading the code from z/OS using FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.5 Defining the CLASSPATH environment variable . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.6 Starting the OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 Using the OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Chapter 5. QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79


5.1 QDIO environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Missing Interrupt Handler for QDIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.4.1 TRLE considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.2 VTAM definitions (TRL major node ). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4.3 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5.2 OSA/SF activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5.3 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5.4 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.7 SNA support for QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 6. TCP/IP Passthru (non-QDIO mode). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91


6.1 Default mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2 HCD requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3 Displaying the default OAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.4 Customizing z/OS TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.1 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.5.2 Activating TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Chapter 7. Non-QDIO mode (TCP/IP and SNA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101


7.1 Configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.2 HCD requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.3 Creating and saving the configuration with the OSA/SF GUI . . . . . . . . . . . . . . . . . . . 104
7.3.1 TCP/IP definitions in OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.3.2 SNA definition in OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.3.3 Activating the OSA-Express configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.3.4 Displaying the MAC address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

iv OSA-Express Implementation Guide


7.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.4.1 VTAM definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.5.3 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 8. ATM HPDT native (non-QDIO mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123


8.1 Configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2 HCD requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.3 Creating and saving the configuration with the OSA/SF GUI . . . . . . . . . . . . . . . . . . . 125
8.3.1 Activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.4.1 VTAM TRL definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.4.3 VTAM XCA and switched major node definitions . . . . . . . . . . . . . . . . . . . . . . . . 134
8.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.5.2 OSA/SF activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.5.3 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.5.4 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Chapter 9. ATM LAN emulation (non-QDIO mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141


9.1 Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.2 HCD requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.3 Creating and saving the configuration with OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . 143
9.3.1 Activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
9.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9.4.1 Customizing VTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.5.1 Verifying that the devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.5.2 OSA/SF activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.5.3 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
9.5.4 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
9.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapter 10. Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165


10.1 The IP backbone as an APPN connection network . . . . . . . . . . . . . . . . . . . . . . . . . 166
10.2 What is Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
10.2.1 Why Enterprise Extender is strategic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
10.2.2 Cost effectiveness and resource convergence . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.2.3 Flow and congestion control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.2.4 Class of service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.2.5 Internet connectivity exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.2.6 Session availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
10.3 What you need to understand about Enterprise Extender . . . . . . . . . . . . . . . . . . . . 168
10.3.1 Transporting SNA over IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
10.3.2 Flow and congestion control (enhanced) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
10.4 Enterprise Extender implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
10.5 Configuration example for Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

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

Chapter 11. VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183


11.1 VLAN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
11.1.1 Types of connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
11.1.2 VLAN tagging basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
11.2 General VLAN design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
11.2.1 VLAN configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
11.2.2 Sharing an OSA-Express port with the same VLAN ID. . . . . . . . . . . . . . . . . . . 189
11.2.3 Primary and secondary router support with VLANs . . . . . . . . . . . . . . . . . . . . . 189
11.2.4 Operating system support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
11.3 VLAN support for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
11.3.1 VLAN implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
11.3.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
11.4 VLAN support for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
11.4.1 VLAN implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
11.4.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
11.5 VLAN support for z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
11.5.1 z/VM native VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
11.5.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
11.5.3 VLAN support for z/VM Virtual Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Chapter 12. Layer 2 support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201


12.1 Virtual switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
12.1.1 Virtual switch controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
12.1.2 Network interface card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
12.1.3 Guest systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
12.1.4 Ethernet mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
12.1.5 MAC addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
12.1.6 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
12.2 Description and objectives of our test environment . . . . . . . . . . . . . . . . . . . . . . . . . 205
12.2.1 Configuring Layer 2 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
12.2.2 Setting up and testing Layer 2 functionality for Linux guests . . . . . . . . . . . . . . 213
12.2.3 Configuring Layer 2 virtual switch with VLAN support . . . . . . . . . . . . . . . . . . . 215
12.3 z/VM Virtual Switch authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
12.3.1 Running with CP authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
12.3.2 Running with RACF authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapter 13. IPv6 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227


13.1 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
13.2 Advantages offered by IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
13.3 IPv6 addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
13.3.1 IPv6 TCP/IP Network part (prefix). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
13.4 Migrating to IPv6 on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
13.5 IPv6 implementation in z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
13.5.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
13.6 IPv6 function summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Appendix A. Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

vi OSA-Express Implementation Guide


z/OS commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
z/VM commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Defining and coupling a NIC using CP commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Linux on System z9 and zSeries TCP/IP commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Appendix B. HMC and SE tasks for OSA-Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243


HMC advanced facilities for OSA-Express. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Trace functions for OSA-Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Hardware functions for OSA-Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
View code level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Configuring OSA-Express channels on/off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Logging on to the Support Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
CHPID Configure on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Logging off from the Support Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Appendix C. RMF in an OSA-Express environment. . . . . . . . . . . . . . . . . . . . . . . . . . . 263


RMF for OSA-Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
RMF Monitor II output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
The Channel Activity Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Appendix D. Using the OSA/SF REXX interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267


Creating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Creating the OSA-Express configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Creating the OSA-Express OAT file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Appendix E. Sample definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277


Sample environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
z/OS definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
TCP/IP profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
VTAM definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Linux definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
z/VM TCP/IP profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Appendix F. HiperSockets Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285


HiperSockets Accelerator description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
HiperSockets definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Verifying HiperSockets Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Appendix G. ARP Takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291


ARP Takeover description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
ARP Takeover definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Cisco switch definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Verifying ARP Takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Pulling the CAT5 cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Stopping the device in the TCP/IP stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299


IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Contents vii
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

viii OSA-Express Implementation Guide


Notices

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®

The following terms are trademarks of other companies:

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.

x OSA-Express Implementation Guide


Preface

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.

The team that wrote this redbook


This IBM Redbook was produced by a team of specialists from around the world working at
the International Technical Support Organization (ITSO), Poughkeepsie Center.

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

Become a published author


Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with
specific products or solutions, while getting hands-on experience with leading-edge
technologies. You'll team with IBM technical professionals, Business Partners and/or
customers.

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

xii OSA-Express Implementation Guide


1

Chapter 1. Overview of Open Systems


Adapter-Express
This chapter describes the features of Open Systems Adapter-Express2 (OSA-Express2) and
the Open Systems Adapter-Express (OSA-Express). These features provide connectivity to
clients and servers on Ethernet, Fast Ethernet (FENET), 1000BASE-T Ethernet, Gigabit
Ethernet (GbE), 10 Gigabit Ethernet, and token ring local area networks (LANs), as well as
asynchronous transfer mode (ATM) networks.

© 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

ATM 155 ATM


Network

Figure 1-1 OSA-Express and OSA-Express2 connectivity

Terminology: If not specifically stated, the term OSA-Express applies to both the
OSA-Express and the OSA-Express2 features throughout this chapter.

2 OSA-Express Implementation Guide


1.1.1 Operating modes
The OSA-Express2 10 GbE LR has one port, while the other OSA-Express2 and
OSA-Express features have two independent ports that can be attached directly to a LAN or
ATM network. The integration of a channel path with network port makes the OSA-Express a
unique channel or channel path identifier (CHPID) type, recognized by the hardware I/O
configuration as one of the following types:
򐂰 Queued Direct I/O (OSD)
򐂰 Non Queued Direct I/O (OSE)
򐂰 OSA-Express Integrated Console Controller (OSC)
򐂰 Open System Adapter for Network Control Program (OSN)

Note that not all features support all CHPID types.

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).

Table 1-1 Supported CHPID types


CHPID Feature SNA/APPN/ TCP/IP 3270 OSA/SF
type HPR traffic traffic traffic required

OSD OSA-Express2 10GbE LR Noab Yes No No


OSA-Express2 GbE Noab Yes No No
OSA-Express2 1000BASE-T Noab Yes No No
OSA-Express 1000BASE-T Noab Yes No No
OSA-Express FENET Noa Yes No No
OSA-Express 155 ATM LANE Noa Yes No Yes
OSA-Express Token Ring Noa Yes No No

OSE OSA-Express2 1000BASE-T Yes Yes No Yes


OSA-Express 1000BASE-T Yes Yes No Yes
OSA-Express FENET Yes Yes No Yes
OSA-Express 155 ATM LANE Yes Yes No Yes
OSA-Express 155 ATM Native Yes Yes No Yes
OSA-Express Token Ring Yes Yes No Yes

OSC OSA-Express2 1000BASE-T No No Yes No


OSA-Express 1000BASE-T No No Yes No

OSN OSA-Express2 GbE Yesc No No No


OSA-Express2 1000BASE-T Yesc No No No

Chapter 1. Overview of Open Systems Adapter-Express 3


a. Systems Network Architecture (SNA) over Internet Protocol (IP) with the use of Enterprise
Extender or TN3270; see 1.2.13, “Enterprise Extender” on page 19, and 1.2.14, “TN3270E
Server” on page 19.
b. Layer 2 support allows for non-IPs, such as SNA. See 1.2.11, “Layer 2 support” on page 17.
c. Supports SNA PU Type 5 and PU Type2.1; see “OSA for NCP support” on page 21.

Open Systems Adapter Support Facility


OSA/SF is a host-based tool used to customize and manage the features of Open Systems
Adapter 2 (OSA-2) and OSA-Express.
򐂰 OSA/SF is not required for the OSA-Express feature that is configured for the Queued
Direct I/O (QDIO) mode, or the default IP Passthru non-QDIO mode. However, it can be
used for problem determination purposes.
򐂰 OSA/SF is not required for OSA-Express CHPID types OSC and OSN as well. Although
information on channel usage can by displayed through OSA/SF for OSN CHPIDs.
򐂰 OSA/SF is required for the configuration of the OSA-Express 155 ATM features.
򐂰 OSA/SF is a required facility when the OSA-Express feature is being configured for shared
non-QDIO mode and where SNA definitions are involved.

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.

QDIO versus non-QDIO


Figure 1-2 illustrates the much shorter I/O process when in QDIO mode compared with
non-QDIO mode (the same I/O path as the OSA-2 features). I/O interrupts and I/O
path-lengths are minimized. This results in improved performance versus non-QDIO mode,
reduction of System Assist Processor (SAP) utilization, improved response time, and server
cycle reduction.

Host
Memory

IOP Host
Memory

Channel OSA-Express
QDIO

Control
Unit

OSA-Express
non-QDIO

Figure 1-2 Non-QDIO versus QDIO data paths

4 OSA-Express Implementation Guide


Also in QDIO mode, the OSA-Express feature receives configuration information from the
host dynamically. This reduces configuration and setup time, eliminates duplicate data entry,
and reduces the possibility of data entry errors and incompatible definitions. We recommend
that you use QDIO mode in conjunction with the supported OSA-Express features wherever
possible.

1.1.2 QDIO mode


Queued Direct I/O is a highly efficient data transfer mechanism that satisfies the increasing
volume of TCP/IP applications and increasing bandwidth demands. It dramatically reduces
system overhead and improves throughput. It does so by using system memory queues and a
signaling protocol to directly exchange data between the OSA-Express microprocessor and
network software, using data queues in main memory and using Direct Memory Access
(DMA).

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.

Direct Memory Access


OSA-Express and Communications Server share a common storage area for
memory-to-memory communication, reducing system overhead and improving performance.
Data can move directly from the OSA-Express microprocessor to system memory. There are
no read or write channel programs for data exchange. For write processing, no I/O interrupts
have to be handled. For read processing, the number of I/O interrupts is minimized.

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).

Chapter 1. Overview of Open Systems Adapter-Express 5


Dynamic OSA Address Table update
With QDIO, this process simplifies installation and configuration setups. The definition of IP
addresses is done in one place, the TCP/IP profile, removing the requirement to enter the
information into the OAT using the OSA/SF.

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.

Note: For a detailed description about HiperSockets, refer to zSeries HiperSockets,


SG24-6816.

Internet Protocol Assist functions


The OSA-Express QDIO Licensed Internal Code (LIC) assists in IP processing and offloads
the TCP/IP stack functions for:
򐂰 Multicast support (see 1.2.7, “TCP/IP multicast and broadcast support” on page 15)
򐂰 Broadcast filtering (see 1.2.7, “TCP/IP multicast and broadcast support” on page 15)
򐂰 Building medium access control (MAC) and Logical Link Control (LLC) headers
򐂰 Address Resolution Protocol (ARP) processing (see 1.2.8, “ARP cache management” on
page 15)

QDIO functions exclusive to z9-109, z990, and z890 servers


The following QDIO enhancements are supported on z9-109, z990, and z890 servers.

TCP/IP enhanced functions


The enhanced functions include:
򐂰 Large Send for TCP/IP traffic for OSA-Express2 (see 1.2.4, “Large send for TCP/IP traffic”
on page 10)
򐂰 640 TCP/IP stacks (see “Maximum TCP/IP stacks and devices” on page 8)

Layer 2 transport mode


For IP and non-IP workloads, the OSA-Express2 features and the current OSA-Express
features on z9-109, z990, and z890 can support two transport modes: Layer 2 (Link Layer) as

6 OSA-Express Implementation Guide


well as the current Layer 3 (Network or IP Layer). For a more detailed description about the
Layer 2 support, see 1.2.11, “Layer 2 support” on page 17.

OSA-Express2 concurrent LIC update


The OSA-Express2 features have increased memory to facilitate concurrent application of
LIC updates. This allows the application of LIC updates without requiring a configuration
off/on, thereby minimizing the disruption of networking traffic during the update.

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.

1.1.3 Non-QDIO mode


Like any other channel-attached control unit and device, an OSA-Express feature can
execute channel programs (CCW chains) and present I/O interrupts to the issuing
applications. For non-QDIO mode, the OSA-Express features are defined as channel type
OSE. The non-QDIO mode requires the use of the OSA/SF for setup and customization of the
OSA-Express features.

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

Chapter 1. Overview of Open Systems Adapter-Express 7


The ATM OSA-Express feature port must be attached to a 155 Mbps ATM switch. On each
emulated LAN (ELAN), the ATM OSA-Express feature port provides ATM LAN Emulation
client (LEC) services by means of one of its two LEC ports.

For TCP/IP Passthru mode, the default OAT may be used. In that case, no configuration or
setup is required.

HPDT ATM Native


The High Performance Data Transfer (HPDT) ATM Native mode allows you to take full
advantage of the facilities of the ATM network to which the ATM OSA-Express feature port is
attached. You can specify that the port transfers data across both permanent virtual circuits
(PVCs) and switched virtual circuits (SVCs).

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).

1.2 OSA-Express elements


This section discusses the functionality that exploits the OSA-Express and OSA-Express2
features.

Maximum IP addresses per OAT


The OAT is a component of an OSA feature’s configuration. An OAT entry defines the data
path between an OSA feature port and an LPAR and device unit address. That is, it manages
traffic through the OSA CHPID.

OSA-Express features support a maximum of 2048 IP addresses (Internet Protocol Version 4


(IPv4), Internet Protocol Version 6 (IPv6), and virtual IP address (VIPA)) per port.
OSA-Express2 features support up to 4096 IP addresses per port. When the OSA-Express
port is defined in QDIO mode, the OAT table entries are built and updated dynamically.

Maximum TCP/IP stacks and devices


The maximum number of TCP/IP stacks and devices is based on the following mode types.
򐂰 OSA-Express in non-QDIO mode (CHPID type OSE)
An OSA-Express port in non-QDIO mode is capable of supporting up to 120 TCP/IP
stacks and 240 devices for all System z9 and zSeries servers.

8 OSA-Express Implementation Guide


򐂰 OSA-Express in QDIO mode (CHPID type OSD)
An OSA-Express port on the z900 and z800 servers is capable of supporting up to 80
TCP/IP stacks and 240 devices in QDIO mode.
An OSA-Express port on the z9-109, z990, and z890 servers in QDIO mode supports 160
TCP/IP stacks or connections and 480 devices per dedicated CHPID. Or it supports 160
total stacks across multiple LPARs using a shared or spanned CHPID.
The z990 and z890 need the October 2004 level of LIC. The z990 and z890 without the
October 2004 level of LIC support only a maximum of 84 TCP/IP stacks and 254 devices
are supported per dedicated CHPID.

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.

򐂰 OSA-Express2 in QDIO mode


The OSA-Express2 features support 640 TCP/IP stacks or connections per dedicated
CHPID, or 640 total stacks across multiple LPARs using a shared or spanned CHPID. The
maximum number of devices allowed is 1920 (1920 devices / 3 = 640 stacks). This
support is exclusive to z9-109, z990, and z890 in QDIO mode. The z990 and z890 require
the January 2005 level of LIC.

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.

1.2.1 Virtual IP address


In the TCP/IP environment, a VIPA frees TCP/IP hosts from dependence on a particular
network attachment. IT allows the establishment of primary and secondary paths through the
network. VIPA is supported by all of the OSA features.

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.

VIPA provides for multiple IP addresses to be defined to a TCP/IP stack, allowing


fault-tolerant, redundant, backup paths to be established. Applications become insensitive to
the condition of the network since the VIPA is always active, enabling users to route around
intermediate points of failure in the network.

VIPA Takeover and Takeback


Since a VIPA is associated with a TCP/IP stack and not a physical network attachment, it can
be moved to any TCP/IP stack within its network. If the TCP/IP stack that the VIPA is on fails
(due to an outage), the same VIPA can be brought up automatically on another TCP/IP stack
(VIPA Takeover) to allow end users to reach the backup server and applications. The original

Chapter 1. Overview of Open Systems Adapter-Express 9


session between the end user and original server is not disrupted. Once the failed TCP/IP
stack is restored, the same VIPA can be moved back automatically (VIPA Takeback).

1.2.2 Primary/secondary router function


The primary/secondary router function enables an OSA-Express2 or OSA-Express port to
forward packets with unknown IP addresses to a TCP/IP stack for routing through another IP
network interface, such as HiperSockets or another OSA-Express feature. For an
OSA-Express port to forward IP packets to a particular TCP/IP stack for routing to its
destination, the PRIRouter must be defined on the DEVICE statement in the TCP/IP profile. If
the TCP/IP stack that has an OSA-Express port defined as PRIRouter becomes unavailable,
then a second TCP/IP stack, defined as the secondary router (SECRouter on the DEVICE
statement in the TCP/IP profile), receives the packets for unknown IP addresses.

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.

1.2.3 IPv6 support


IPv6 is supported by the OSA-Express2 and OSA-Express features when configured in QDIO
mode. IPv6 is the protocol designed by the Internet Engineering Task Force (IETF) to replace
IPv4. IPv6 provides improved traffic management in the following areas:
򐂰 128-bit addressing
This eliminates all practical limitations on global address ability. Private address space,
and the network address translators (NATs) used between private intranet and public
internet, are no longer needed.
򐂰 Simplified header formats
These formats allow for more efficient packet handling and reduced bandwidth cost.
򐂰 Hierarchical addressing and routing
This keeps routing tables small and backbone routing efficient by using address prefixes
rather than address classes.
򐂰 Improved support for options
These options change the way IP header options are encoded, allowing more efficient
forwarding and greater flexibility.
򐂰 Address auto-configuration
This type of configuration allows stateless IP address configuration without a configuration
server. In addition, IPv6 brings greater authentication and privacy capabilities through the
definition of new extensions, and integrated Quality of Service (QoS) through a new traffic
class byte in the header.

For more details, refer to Chapter 13, “IPv6 support” on page 227.

1.2.4 Large send for TCP/IP traffic


Large send, also referred to as TCP segmentation offload, can improve performance by
offloading TCP packet processing from the host to the OSA-Express2 features running in
QDIO mode. Offload allows the host to send large blocks of data (64 KB) directly to the
OSA-Express2 feature. The OSA-Express2 feature then fragments the 64 KB blocks into
standard Ethernet frames (1500 bytes) to be sent on the LAN (see Figure 1-3).

10 OSA-Express Implementation Guide


Ethernet Jumbo TCP large
frame frame send

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.

1.2.5 VLAN support


Virtual LAN (VLAN) is supported by the OSA-Express2 and OSA-Express features when
configured in QDIO mode. This support is applicable to z/OS, z/VM, and Linux environments.

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.

Chapter 1. Overview of Open Systems Adapter-Express 11


VLANs facilitate easy administration of logical groups of stations that can communicate as
though they were on the same LAN. They also facilitate easier administration of moves, adds,
and changes in members of these groups. VLANs are also designed to provide a degree of
low-level security by restricting direct contact with a server to only the set of stations that
comprise the VLAN.

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

port 1 port 2 OSA-Express Ethernet


ports in QDIO mode

Ethernet Switch

VLAN28 VLAN16 VLAN4 VLAN12

Common physical network

Figure 1-4 VLAN support

VLAN support for z/OS


Full VLAN support is offered for all OSA-Express Ethernet features available on zSeries
servers. z/OS V1.5 Communications Server supports VLAN IDs. Support is offered for one
global VLAN (ID) per OSA-Express port, based on IP version.
򐂰 One Global VLAN (ID) for IPv4
򐂰 One Global VLAN (ID) for IPv6

z/OS V1.4 Communications Server only supports VLAN priority tagging. However, with APAR
PQ86508, both priority tagging and VLAN IDs are supported.

VLAN support for z/VM


z/VM V4.4 exploits the VLAN technology and conforms to the IEEE 802.1q standard. To
support VLAN, z/VM V4.4 provides:
򐂰 One global VLAN ID for IPv4
򐂰 Enhancements to TCP/IP for z/VM to enable membership in a VLAN for HiperSockets and
QDIO mode OSA-Express feature channels

12 OSA-Express Implementation Guide


򐂰 Enhancements to z/VM Guest - LAN simulation to allow virtual QDIO and HiperSockets to
participate in a VLAN
򐂰 Management and control of VLAN topology through the z/VM Virtual Switch

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.

VLAN support for Linux on System z9 and zSeries


VLAN support in a Linux on System z9 or zSeries environment is available for the
OSA-Express2 features and the OSA Express features (Fast Ethernet, 1000BASE-T
Ethernet, and Gigabit Ethernet features) operating in QDIO mode.

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.

VLAN support of GVRP


GVRP is defined in the IEEE 802.1P standard for the control of IEEE 802.1Q VLANs. It can
be used to help simplify networking administration and management of VLANs.

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

VLAN 22 VLAN33 VLAN44

Physical LAN

Figure 1-5 GVRP support

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).

Chapter 1. Overview of Open Systems Adapter-Express 13


1.2.6 SNMP support for z/OS and Linux
Simple Network Management Protocol (SNMP) is supported for all of the OSA-Express
features when configured in the QDIO mode (CHPID type OSD). The OSA-Express SNMP
subagent support offered via the OSA-Express features LIC are:
򐂰 Get and GetNext requests
This support was introduced in April 2002 and applies to all of the OSA-Express features
supported on z9-109, z990, z890, z900, and z800.
򐂰 dot3StatsTable
Ethernet data for dot3StatsTable was introduced in May 2003 and applies to all of the
Ethernet features supported on z9-109, z990, z890, z900, and z800. It implements the
SNMP EtherLike Management Information Base (MIB) module in RFC 2665, which
provides statistics for Ethernet interfaces. These statistics can assist in the analysis of
network traffic congestion.
򐂰 Performance data
This support was introduced in May 2003 and applies to all of the OSA-Express features
supported on z9-109, z990, z890, z900, and z800. The performance data reflects the
OSA-Express utilization.
򐂰 Traps and Set
This support was introduced in May 2004 and applies to all of the OSA-Express features
supported on z9-109, z990, and z890.

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).

14 OSA-Express Implementation Guide


Managers (clients) Agents (servers)

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

SNMP command SNMP Subagent


System z9
and zSeries
OSA-Express
Figure 1-6 SNMP support for z/OS example

1.2.7 TCP/IP multicast and broadcast support


Multicast and broadcast support are part of the IPA function of the OSA-Express feature.

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.

TCP/IP broadcast support for z/OS, z/VM, and Linux


Broadcast support is included for all of the OSA-Express2 and OSA-Express features when
configured in QDIO mode. It also supports the Routing Information Protocol (RIP) Version 1.
Broadcast support is also available for all of the OSA-Express features when carrying TCP/IP
traffic. It is configured in the non-QDIO mode (LCS 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.

1.2.8 ARP cache management


The query and purge ARP enhancements are supported for all OSA-Express2 and
OSA-Express features when configured in QDIO mode. The OSA-Express feature maintains
a cache of recently acquired IP-to-physical address mappings (or “bindings”). When the
binding is not found in the ARP cache, a broadcast (an ARP request “How can I reach you?”)
to find an address mapping is sent to all hosts on the same physical network. Because a
cache is maintained, it is not necessary for ARP to be used repeatedly, and the OSA-Express
feature does not have to keep a permanent record of bindings.

Query ARP table for IPv4 for Linux


A Query ARP table is supported using IPv4. The TCP/IP stack already has an awareness of
IPv6 addresses.

Chapter 1. Overview of Open Systems Adapter-Express 15


Purge ARP entries in cache for IPv4 for z/OS and Linux
Purging of entries in the ARP cache is supported using IPv4. The TCP/IP stack already has
an awareness of IPv6 addresses.

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.

1.2.9 Enhanced IP network availability


There are several ways to ensure network availability should failure occur at either the LPAR
or the CHPID or network connection level. Port sharing, redundant paths, and the use of
primary and secondary ports all provide some measure of recovery. A combination of these
can guarantee network availability regardless of the failing component.

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.

1.2.10 Checksum offload support for z/OS and Linux


The z/OS, Linux on System z9 and zSeries environments provide the capability of calculating
and validating the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) and IP
header checksums. Checksums are used to verify the contents of files when transmitted over
a network, for example:
򐂰 OSA-Express validates the TCP, UDP, and IP header checksums for inbound packets.
򐂰 OSA-Express calculates the TCP, UDP, and IP header checksums for outbound packets.

16 OSA-Express Implementation Guide


Checksum offload is supported on z9-109, z990, and z890 OSA-Express2 features and
OSA-Express Gigabit features when operating in QDIO mode.

By offloading checksum processing to the supporting OSA-Express features, host server


cycles are reduced, which can realize improved performance for most IPv4 packets.

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.

Checksum offload support is available with z/OS Version 1 Release 5 or later.

For Linux on zSeries support, refer to the following Web site for further information:
http://www.ibm.com/developerworks

1.2.11 Layer 2 support


The OSA-Express2 and OSA-Express Ethernet features on z9-109, z990 and z890 servers
can support two transport modes of the OSI model: Layer 2 (Link Layer or MAC Layer) and
Layer 3 (Network Layer). The Layer 2 transport mode allows for communication with IP and
non-IP protocols. OSA-Express works in conjunction with the Virtual Switch (a component of
z/VM V5.1) to enable Layer 2 functionality for guest systems, such as Linux on System z9 and
on zSeries.

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.

Chapter 1. Overview of Open Systems Adapter-Express 17


MAC address switching

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.

1.2.12 SNA enhanced availability


With the SNA enhanced availability, system availability is increased, network management is
simplified, the network is more scalable, and users can be added non-disruptively. The 4096
Physical Units (PUs) can be defined for each OSA-Express feature port.

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.

18 OSA-Express Implementation Guide


Overflow
User sessions flow through the primary path until the session limit is exceeded. When the
port no longer responds to requests, user sessions automatically flow to the next
OSA-Express port.

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.

1.2.13 Enterprise Extender


The Enterprise Extender (EE) function of 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 UDP/IP
packets. It provides:
򐂰 SNA application connectivity using an IP backbone support for:
– SNA-style priority
– SNA Parallel Sysplex exploitation
򐂰 Improved throughput and response times
򐂰 Compatible support for TCP and UDP traffic on the IP portion of the application traffic path
(SNA/HPR and UDP/IP traffic can coexist on an EE connection)

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.

EE requires Advanced Peer-to-Peer Networking® (APPN) and HPR at the endpoints. To


enable EE, you must configure the TCP/IP stack with a virtual IP address and define an XCA
major node. The XCA major node is used to define the PORT, GROUP, and LINE statements
for the EE connections.

For more information about Enterprise Extender, see Chapter 10, “Enterprise Extender” on
page 165.

1.2.14 TN3270E Server


The TN3270E Server is supported by z/OS. It allows desktop users to connect through an IP
network directly to SNA applications.

The following support is provided.


򐂰 Secure access using Secure Sockets Layer (SSL) and Client Authentication via Resource
Access Control Facility (RACF®)
򐂰 Over 64000 sessions per server when using multiple ports
򐂰 Over 2000 transactions/second with subsecond response time
򐂰 Reconnection of 16 K sessions in less than one minute using VIPA Takeover support
򐂰 IP QoS using Service Policy Server
򐂰 Host Print Support
򐂰 Tivoli support provides IP visibility to VTAM
򐂰 Manage with your Data Center resources
򐂰 More robust than external TN3270 servers

Chapter 1. Overview of Open Systems Adapter-Express 19


Communications Server also supports a secure, RACF-based single signon logic called
Express Logon Facility (ELF). ELF works with IBM TN3270 clients to securely authenticate
the client, acquire a passtoken, and then pass it on to the TN3270E server for replacement or
submission to the application.

1.2.15 Communications controller migration support


Communication Controller for Linux offers a migration path to move NCP-based SNA
workloads such as SNA Network Interconnect (SNI) from the IBM 3745 Communication
Controller to System z9 and zSeries servers. CCL provides an alternative platform for running
the NCP software product, in place of many configurations where a 37xx hardware
environment is used.

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

Traffic between the LPARs


Traffic between CCL and LAN environment

Figure 1-8 CCL traffic flow on a zSeries server

20 OSA-Express Implementation Guide


OSA for NCP support
With the introduction of OSN support on System z9, OSA-Express2 Gigabit Ethernet and
1000BASE-T Ethernet features have the capability to offer channel connectivity from
operating systems to the CCL (LPAR-to-LPAR communication). OSN support is provided with
a new CHPID type OSN. Each operating system that currently supports Channel Data Link
Control (CDLC) can use this connectivity option without changes to the operating system.
OSN supports both SNA PU Type 5 and PU Type 2.1 channel connectivity.

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

Chapter 1. Overview of Open Systems Adapter-Express 21


z/VM z/OS, TPF ...
NCP VTAM
CCL
QDIO CDLC

OSD OSN

Traffic between the LPARs


Traffic between CCL and LAN environment

Figure 1-9 CDLC traffic flow, using OSA for NCP

1.2.16 OSA/SF support


OSA/SF includes a Java™-based graphical user interface (GUI) in support of the client
application. The Java GUI is independent of any operating system or server (transparent to
the operating system), and is expected to operate wherever the Java 1.4 runtimes are
available.

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.

The OSA/SF) is used primarily to:


򐂰 Manage all OSA ports
򐂰 Configure all OSA non-QDIO ports
򐂰 Configure ATM LANE ports on z800 and z900 servers
򐂰 Configure local MAC

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).

22 OSA-Express Implementation Guide


The Java GUI version of OSA/SF is integrated in z/VM V4R4 and replaces V2R1. In currently
supported versions/releases of z/VM and VSE/ESA, this version is delivered as a PTF and
will overlay OSA/SF V2R1.

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.

Chapter 1. Overview of Open Systems Adapter-Express 23


Maximum OSA-Express features
All of the OSA-Express2 and OSA-Express features occupy one slot in an I/O cage.
򐂰 The z9-109 supports a maximum of 24 OSA-Express2 or OSA-Express features. The
features have two ports, except one port for the OSA-Express2 10 GbE LR feature. There
is no plugging limit of OSA Express2 and OSA-Express features per z9-109 I/O cage.
򐂰 Each z990 I/O cage supports 20 OSA-Express2 or OSA-Express features. The features
have two ports each, with the exception of one port for the OSA-Express2 10 GbE LR
feature. A maximum of 24 features can be installed in a z990 server.
򐂰 The z890 supports a maximum of 20 OSA-Express2 or OSA-Express features except the
smallest sub-uniprocessor (2086-110 allows 12). Each feature has two ports with the
exception of one port for the OSA-Express2 10 GbE LR feature.
򐂰 The z800 and z900 I/O cages support 12 OSA-Express features. The features have two
ports each. A maximum of 12 features (24 ports) can be installed in a z900 or z800 server.
In a z900, the total number of OSA-Express and OSA-2 features must not exceed 12.

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.

The maximum combined number of OSA-Express2, OSA-Express, FICON Express2, FICON


Express, FICON, Crypto Express2, PCIXCC, PCICC, and PCICA features supported by each
zSeries server family are:
򐂰 60 features for the z990 server, 48 for the model 2084-A08
򐂰 20 features for the z890 server, 12 for the model 2086-110
򐂰 48 features for the z900 server
򐂰 16 features for the z800 server

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.

Multiple Image Facility


Multiple Image Facility (MIF) enables OSA-Express channels installed on System z9 and
zSeries servers to be shared among LPARs.

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.

24 OSA-Express Implementation Guide


1.3.1 OSA-Express features
Table 1-2 lists the OSA-Express2 and OSA-Express feature support on all System z9 and
zSeries servers.

Table 1-2 System z9 and zSeries server support for OSA-Express


Feature name Feature Maximum portsa Connector Cable type Maximum
code type unrepeated
z800 z900 z890 z990 z9-109 distanceb

OSA-Express 2362 24 24 n/a 24c n/a SC Duplex SM 9 µm 20 km


155 ATM SM

OSA-Express 2363 24 24 n/a 24c n/a SC Duplex MM 50 µm 2 km


155 ATM MM
MM 62.5 µm 2 km

OSA-Express 1364 24 24 40 48 48i LC Duplex SM 9 µm 5 km


GbE LXd
MCPf 550 m (500)

OSA-Express 2364 24 24 24e 24e 24i SC Duplex SM 9 µm 5 km


GbE LX
MCPf 550 m (500)

OSA-Express 1365 24 24 40 48 48i LC Duplex MM 62.5 µm 220 m (166)


GbE SXg 275 m (200)

MM 50 µm 550 m (500)

OSA-Express 2365 24 24 24e 24e 24i SC Duplex MM 62.5 µm 220 m (166)


GbE SX 275 m (200)

MM 50 µm 550 m (500)

OSA-Express 1366 n/a n/a 40 48 48i RJ 45 UTP Cat5 100 m


1000BASE-T

OSA-Express 2366 24 24 24 24 24i RJ 45 UTP Cat5 100 m


Fast Etherneth

OSA-Express 2367 24 24 40 48 n/a RJ 45 STP 100 m


Token Ring
UTP 45 m

OSA-Express2 3364 n/a n/a 40 48 48 LC Duplex SM 9 µm 5 km


GbE LX
MCPf 550 m (500)

OSA Express2 3365 n/a n/a 40 48 48 LC Duplex MM 62.5 µm 220 m (166)


GbE SX 275 m (200)

MM 50 µm 550 m (500)

OSA-Express2 3366 n/a n/a n/a n/a 48 RJ 45 UTP Cat5 100m


1000BASE-T

OSA-Express2 3368 n/a n/a 20 24 24 SC Duplex SM 9 µm 10 km


10 GbE LR
a. Maximum number of ports is 24 for model 2086-110 and 48 for model 2084-A08.
b. Minimum fiber bandwidth in MHz/km for multimode fiber links are included in parentheses where applicable.
c. With RPQ 8P2258, this feature can be carried forward from a z900 when upgraded to a z990 in non-QDIO mode
(OSE CHPID type) only.
d. Feature 1364 is no longer orderable on z890 and z990. It has been replaced by feature 3364.
e. Can be brought forward on an upgrade from z900 or z800.

Chapter 1. Overview of Open Systems Adapter-Express 25


f. Mode conditioning patch (MCP) cables enable 1 Gbps single mode cards to connect to multimode fiber.
g. Feature 1365 is no longer orderable on z890 and z990. It has been replaced by feature 3365.
h. Feature 2366 is no longer orderable on z890 and z990. It has been replaced by feature 1366.
i. Can be brought forward from z990 or z900.

OSA-Express2 10 Gigabit Ethernet Long Reach (10 GbE LR) feature


Feature code 3368 occupies one slot in the z9-109, z990, or z890 I/O cage. It has one port
that connects to a 10 Gbps Ethernet LAN via a 9 micron single mode fiber optic cable
terminated with an SC Duplex connector. It supports an unrepeated maximum distance of 10
km (6.2 miles).

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 following 10GBASE-LR (standard transmission scheme) Ethernet standards are


applicable for this feature:
򐂰 IEEE 802.3ae
򐂰 IEEE 802.1q
򐂰 IEEE 802.3x - flow control
򐂰 DIX Version 2

OSA-Express2 Gigabit Ethernet long wavelength (GbE LX) feature


Feature code 3364 occupies one slot in the z9-109, z990, or z890 I/O cage. It has two
independent ports that connect to a 1 Gbps Ethernet LAN via a 9 micron single mode fiber
optic cable terminated with an LC Duplex connector. It supports an unrepeated maximum
distance of 5 km (3.1 miles). Multimode (62.5 or 50 micron) fiber optic cable may be used with
this feature. The use of these multimode cable types requires an MCP cable at each end of
the fiber link. Use of the single mode-to-multimode MCP cables reduces the supported
distance of the link to a maximum distance of 550 meters (1084 feet).

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 following 1000BASE-LX (standard transmission scheme) Ethernet standards are


applicable for this feature:
򐂰 IEEE 802.3ac
򐂰 IEEE 802.1q
򐂰 IEEE 802.3x
򐂰 IEEE 802.3z
򐂰 DIX Version 2

OSA-Express2 Gigabit Ethernet short wavelength (GbE SX) feature


Feature code 3365 occupies one slot in the z9-109, z990, or z890 I/O cage. It has two
independent ports that connect to a 1 Gbps Ethernet LAN via 50 or 62.5 micron multimode
fiber optic cable terminated with an LC Duplex connector over an unrepeated distance of 550
meters (for 50 µm fiber) or 220 meters (for 62.5 µm fiber).

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.

26 OSA-Express Implementation Guide


The following 1000BASE-SX (standard transmission scheme) Ethernet standards are
applicable for this feature:
򐂰 IEEE 802.3ac
򐂰 IEEE 802.1q
򐂰 IEEE 802.3x
򐂰 IEEE 802.3z
򐂰 DIX Version 2

OSA-Express2 1000BASE-T Ethernet feature


Feature code 3366 occupies one slot in the z9-109 I/O cage. It has two independent ports
that connect to a 1000 Mbps (1 Gbps), 100 Mbps, or 10 Mbps Ethernet LAN. Each port has
an RJ-45 receptacle for cabling to an Ethernet switch. The RJ-45 receptacle is required to be
attached using EIA/TIA category 5 unshielded twisted pair (UTP) cable with a maximum
length of 100 meters (328 feet).

The OSA-Express2 1000BASE-T Ethernet feature supports autonegotiation when attached


to an Ethernet hub, router, or switch. If you allow the LAN speed and duplex mode to default
to autonegotiation, the OSA-Express port and the attached hub, router, or switch
autonegotiate the LAN speed and duplex mode settings between them, and connect at the
highest common performance speed and duplex mode of interoperation. If the attached
Ethernet hub, router, or switch does not support autonegotiation, the OSA-Express port
examines the signal it is receiving and connects at the speed and duplex mode of the device
at the other end of the cable.

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.

The following Ethernet standards are applicable for this feature:


򐂰 10BASE-T (standard transmission scheme)
– IEEE 802.2
– IEEE 802.3
– ISO/IEC 8802-3
– DIX Version 2

Chapter 1. Overview of Open Systems Adapter-Express 27


򐂰 100BASE-TX (standard transmission scheme)
– IEEE 802.3u
򐂰 1000BASE-T (standard transmission scheme)
– IEEE 802.1p
– IEEE 802.1q
– IEEE 802.3ab
– IEEE 802.3ac
– IEEE 802.3u
– IEEE 802.3x
– PCI v2.2

OSA-Express Gigabit Ethernet long wavelength (GbE LX) feature


Feature codes (FC) 1364 and 2364 occupy one slot each in the System z9 and zSeries
server’s I/O cage. They both have two independent ports that connect to a 1 Gbps Ethernet
LAN via a 9 micron single mode fiber optic cable terminated with an LC Duplex connector (FC
1364) or an SC Duplex connector (FC 2364). Both support an unrepeated maximum distance
of 5 km (3.1 miles). Multimode (62.5 or 50 micron) fiber optic cable may be used with these
features. The use of these multimode cable types requires an MCP cable at each end of the
fiber link. Use of the single mode-to-multimode MCP cables reduces the supported distance
of the link to a maximum distance of 550 meters (1084 feet).

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.

The following 1000BASE-LX (standard transmission scheme) Ethernet standards are


applicable for these features:
򐂰 IEEE 802.3z
򐂰 DIX Version 2

OSA-Express Gigabit Ethernet short wavelength (GbE SX) feature


Feature codes 1365 and 2365 occupy one slot each in the System z9, zSeries server’s I/O
cage. They both have two independent ports that connect to a 1 Gbps Ethernet LAN via 50 or
62.5 micron multimode fiber optic cable terminated with an LC Duplex connector (FC 1365) or
an SC Duplex connector (FC 2365). Both support an unrepeated maximum distance of 550
meters (for 50 µm fiber) or 220 meters (for 62.5 µm fiber).

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

28 OSA-Express Implementation Guide


type OSD. See 1.1.1, “Operating modes” on page 3, for details about modes of operation and
supported traffic types.

The following 1000BASE-SX (standard transmission scheme) Ethernet standards are


applicable for these features:
򐂰 IEEE 802.3z
򐂰 DIX Version 2

OSA-Express 1000BASE-T Ethernet feature


Feature code 1366 occupies one slot in the z9-109, z990, or z890 I/O cage. It has two
independent ports that connect to a 1000 Mbps (1 Gbps), 100 Mbps, or 10 Mbps Ethernet
LAN. Each port has an RJ-45 receptacle for cabling to an Ethernet switch that is appropriate
for the LAN speed. The RJ-45 receptacle is required to be attached using EIA/TIA category 5
UTP cable with a maximum length of 100 meters (328 feet).

Feature code 1366: You must carry forward FC 1366 on an upgrade from z990 to a
z9-109.

The OSA-Express 1000BASE-T Ethernet feature supports autonegotiation when attached to


an Ethernet hub, router, or switch. If you allow the LAN speed and duplex mode to default to
autonegotiation, the OSA-Express port and the attached hub, router, or switch autonegotiate
the LAN speed and duplex mode settings between them, and connect at the highest common
performance speed and duplex mode of interoperation. If the attached Ethernet hub, router,
or switch does not support autonegotiation, the OSA-Express port examines the signal it is
receiving, and connects at the speed and duplex mode of the device at the other end of the
cable.

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.

The following Ethernet standards are applicable for this feature:


򐂰 10BASE-T (standard transmission scheme)
– IEEE 802.2
– IEEE 802.3
– DIX Version 2

Chapter 1. Overview of Open Systems Adapter-Express 29


򐂰 100BASE-TX (standard transmission scheme)
– IEEE 802.3u
򐂰 1000BASE-T (standard transmission scheme)
– IEEE 802.3ab

OSA-Express Fast Ethernet feature


Feature code 2366 occupies one slot in the z9-109, z990, z890, z900 or z800 I/O cage. It has
two independent ports that connect to a 100 Mbps or 10 Mbps Ethernet LAN. The port has an
RJ-45 receptacle for cabling to an Ethernet switch that is appropriate for the LAN speed. The
RJ-45 receptacle is required to be attached using EIA/TIA category 5 UTP cable with a
maximum length of 100 meters (328 feet).

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.

The OSA-Express FENET feature supports autonegotiation when attached to an Ethernet


hub, router, or switch. If you allow the LAN speed and duplex mode to default to
autonegotiation, the OSA-Express port and the attached hub, router, or switch autonegotiate
the LAN speed and duplex mode settings between them, and connect at the highest common
performance speed and duplex mode of interoperation. If the attached Ethernet hub, router,
or switch does not support autonegotiation, the OSA-Express port examines the signal it is
receiving and connects at the speed and duplex mode of the device at the other end of the
cable.

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 following Ethernet standards are applicable for this feature:


򐂰 10BASE-T (standard transmission scheme)
– IEEE 802.2
– IEEE 802.3
– DIX Version 2
򐂰 100BASE-TX (standard transmission scheme)
– IEEE 802.3u

30 OSA-Express Implementation Guide


OSA-Express Token Ring feature
Feature code 2367 occupies one slot in the zSeries server’s I/O cage. It has two independent
ports that connect to a 4 Mbps, 16 Mbps, or 100 Mbps Token Ring LAN. Each port has an
RJ-45 receptacle and a DB-9 D shell receptacle for cabling to a token-ring hub or token-ring
switch that is appropriate for the LAN speed. Only one of the port’s two receptacles can be
used at any time.

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.

The following token-ring standards are applicable for this feature:


򐂰 IEEE 802.2
򐂰 IEEE 802.5
򐂰 ISO/IEC 8802.5

OSA-Express 155 ATM MM feature


Feature code 2363 occupies one slot in the z800 or z900 I/O cage. It has two independent
ports that connection to a 155 Mbps ATM network via 62.5 micron or 50 micron multimode
fiber optic cable terminated with an SC Duplex connector; supporting an unrepeated
maximum distance of 2 km.

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.

Chapter 1. Overview of Open Systems Adapter-Express 31


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 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.

The following network protocols are applicable for this feature:


򐂰 ATM Forum User-to-Network Interface (UNI) Specifications Version 3.0 and 3.1 with
signaling protocol Q.2931 for Ethernet and Token-Ring ELANs
򐂰 LAN emulation
– Ethernet
• IEEE 802.2 LAN MAC protocols
• IEEE 802.3 CSMA/CD protocols
• Ethernet V.2 protocols (not supported by SNA/APPN)

32 OSA-Express Implementation Guide


– Token ring
• IEEE 802.2 LAN MAC protocols
• IEEE 802.5 MAC protocols

Note: The z990 with RPQ 8P2258 is the model of the zSeries family of servers to provide
an ATM feature.

OSA-Express 155 ATM SM feature


Feature code 2362 occupies one slot in the z800 or z900 I/O cage. It has two independent
ports that connection to a 155 Mbps ATM network via 9 micron single mode fiber optic cable
terminated with an SC Duplex connector, for a maximum unrepeated distance of 20 km.

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.

Chapter 1. Overview of Open Systems Adapter-Express 33


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.

The following network protocols are applicable for this feature:


򐂰 ATM Forum UNI Specifications Version 3.0 and 3.1 with signaling protocol Q.2931 for
Ethernet and Token-Ring ELANs
򐂰 LAN emulation
– Ethernet
• IEEE 802.2 LAN MAC protocols
• IEEE 802.3 CSMA/CD protocols
• Ethernet V.2 protocols (not supported by SNA/APPN)
– Token ring
• IEEE 802.2 LAN MAC protocols
• IEEE 802.5 MAC protocols

Note: The z990 with RPQ 8P2258 is the last model of the zSeries family of servers to
provide the ATM features.

Table 1-3 gives an overview of the OSA-Express supported functionality.

Table 1-3 OSA-Express functionality


OSA-Express2 OSA-Express
1000BASE-T

1000BASE-T

Token Ring
10 GbE LR

Functionality
155 ATM
FENET
GbE

GbE

ARP takeover x x xa x xa xa xa n/a

ARP cache management x x xa x xa xa xa xa

Checksum offload support (IPv4 only) x x xa xb xa n/a n/a n/a

SNMP support x x x x x x x x

Internet Protocol Version 6 (IPv6) support x x xa x xa xa n/a n/a

Large send support x x xa n/a n/a n/a n/a n/a

Layer 2 support x x xa x xa xa n/a n/a

34 OSA-Express Implementation Guide


OSA-Express2 OSA-Express

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

Concurrent LIC update xc xd xd n/a n/a n/a n/a n/a

Primary/secondary router function x x x x x x x x

Multicast and broadcast support x x x x x x x n/a

Virtual IP address (VIPA) support x x x x x x x x

VLAN (IEEE 802.1q)support x x xa x xa xa n/a n/a

VLAN support of GVRP xa d xa e xa e 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

1.3.2 Software support


Operating systems that support System z9 and zSeries servers in Basic mode and LPAR
mode also provide support for OSA-Express, including:
򐂰 z/OS
All still in-service releases of z/OS; for more information, go to:
http://www.ibm.com/servers/eserver/zseries/zos/support/zos_eos_dates.html
򐂰 z/VM
All still in-service releases of z/VM; for more information, go to:
http://www.vm.ibm.com/techinfo/lpmigr/vmleos.html
򐂰 VSE
All still in-service releases of VSE; for more information, go to:
http://www.ibm.com/servers/eserver/zseries/os/vse/support/support.htm
򐂰 Transaction Processing Facility (TPF):
All still in-service releases of TPF; for more information, go to:
http://www.ibm.com/software/htp/tpf/index.html
򐂰 Linux
For Linux on zSeries support and downloads, go to:
http://www.ibm.com/servers/eserver/zseries/os/linux/dist.html

Note: Certain functionality may require specific levels of an operating system or PTFs.
That information is provided when appropriate within this chapter.

Chapter 1. Overview of Open Systems Adapter-Express 35


1.3.3 Resource Measurement Facility enhancements
Resource Measurement Facility (RMF™, z/OS only) reporting supports the OSA-Express
features. This enables you to capture performance data for the OSA-Express features:
򐂰 Microprocessor utilization (per LPAR image if it applies)
򐂰 Physical Peripheral Component Interconnect (PCI) bus utilization
򐂰 Bandwidth per port (both read and write directions), per LPAR image

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

Multicast addresses (IPv4 + IPv6) 1024 1024 2048 2048

ARP table size 8192 8192 16384 16384

Non-QDIO (OSE)

Subchannels per TCP/IP link 2 2 n/a 2a

TCP/IP stacks per port 120 120 n/a 120a

SNA PUs per port 4096 4096 n/a 4096a

Devices per port 240 240 n/a 240a

CUs per port 1 1 n/a 1a

QDIO (OSD)

Subchannels per TCP/IP link 3 3 3 3

TCP/IP stacks per port 80 84 / 160b 640c 640c

Devices per port 240 254 / 480b 1920c 1920c

CUs per port 1 1 / 16b 16 16


a. OSA-Express2 1000BASE-T only
b. October 2004 LIC level required
c. If multiple priority for queues is enabled, the maximum is reduced to 160 TCP/IP stacks and
480 devices.

36 OSA-Express Implementation Guide


Further key characteristics of the OSA-Express features on System z9 and zSeries servers
include:
򐂰 Up to 24 ports on the z800 and z900, 40 ports on z890, and 48 ports on z9-109 and z990
servers help to reduce the need for external gateways. Each OSA-Express feature has two
ports on a zSeries server, with the exception of the OSA-Express2 10 GbE LR, which has
one port.
򐂰 OSA-Express features use full duplex, direct attachment to the zSeries STI infrastructure
to deliver high bandwidth paths to applications and line speed performance. The STI
attachment runs far faster than older ESCON devices or OSA-2 that connects to the
17 MB/s Channel Request Handler bus.
򐂰 OSA-Express features (10 GbE LR, GbE, 1000BASE-T, FENET, Token Ring, and 155
ATM (Ethernet or Token Ring LAN Emulation)) can use QDIO. QDIO is a highly efficient
data transfer architecture, which dramatically improves data transfer speed and efficiency
for TCP/IP traffic. QDIO can support SNA/APPN/HPR traffic through the use of Enterprise
Extender. QDIO incorporates a number of features.
– DMA allows data to move directly from the OSA-Express microprocessor to the host
memory. This bypasses three layers of processing that are required when using
ESCON and OSA-2 features, dramatically improving throughput.
– IP Assist allows compute-intensive functions that are usually handled by the host
system to be performed by the OSA-Express feature; for example, multicast support,
broadcast filtering, building MAC and LLC headers, and ARP processing and statistics
gathering. This reduces the load on the host system, freeing resources for increased
application workloads.
– LPAR-to-LPAR communication via the OSA-Express feature. This allows data being
sent from one LPAR to another within the same system to be routed directly through a
shared OSA-Express feature, completely bypassing the LAN.
– Priority queuing (for z/OS environments) sorts outgoing IP message traffic according to
the priority assigned in the IP header. This priority reflects the user’s business priorities
assigned to the application, user ID, time of day, and other characteristics.
– Dynamic building of the OAT reduces configuration and setup time, eliminates
duplicate data entry, and reduces the chance of data entry errors and incompatible
definitions. For example, TCP/IP profile definitions are entered once. Then they are
passed to the OSA-Express feature at device startup, and the OAT is then built and
maintained dynamically.
– Enhanced IP network availability is a service of the QDIO architecture. 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. The OSA-Express feature port 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-Express feature port
which IP addresses (real and VIPA) to take over, and sends a gratuitous ARP which
contains the MAC address of the backup OSA-Express. The network connection is
maintained.
򐂰 The OSA-Express features support VIPA in the TCP/IP environment. VIPA frees TCP/IP
hosts from dependence on a particular network attachment. VIPA provides for multiple IP
addresses to be defined to a TCP/IP stack, allowing fault-tolerant, redundant, backup
paths to be established. Applications become insensitive to the condition of the network
since the VIPA will always be active, enabling users to route around intermediate points of
failure in the network.

Chapter 1. Overview of Open Systems Adapter-Express 37


VIPA Takeover and Takeback allow for fast connection recovery in the event of a TCP/IP
stack services or application failure. Should a stack or configured application fail, the IP
addresses are transferred to backup copies and the OSA-Express features using QDIO
are updated dynamically. Network access services can continue uninterrupted.
This VIPA support also facilitates the movement of applications and workload within the
sysplex in a manner that is transparent to end-user connection requests.
򐂰 OSA-Express allows network traffic from multiple LPARs to travel through the same port.
TCP/IP and SNA/APPN/HPR traffic can be mixed on the same port simultaneously.
򐂰 Layer 2 support allows for communication with IP and non-IP protocols (NetBIOS, SNA,
and so on). OSA-Express works in conjunction with the z/VM Virtual Switch to enable
Layer 2 functionality for z/VM guest systems, such as Linux.
򐂰 Large send can improve performance by offloading TCP packet processing from the host
to the OSA-Express2 features. It allows the host to send large blocks of data (64 kilobytes)
directly to the OSA-Express2 feature.
򐂰 VLAN is supported by the OSA-Express features when configured in QDIO mode. This
support is applicable to z/OS, z/VM, and Linux environments. VLANs are also designed to
provide a degree of low-level security by restricting direct contact with a server to only the
set of clients/servers that comprise the VLAN.

Table 1-5 summarizes the supported OSA-Express2 and OSA-Express features based on the
System z9and zSeries server.

Table 1-5 Supported features for System z9 and zSeries servers


Feature name Feature code z9-109 z890 z990 z800 z900

1364 Yes Yes Yes Yes Yes


OSA-Express GbE LXa d
2364b Yes Yes Yes Yes Yes

OSA-Express2 GbE LX 3364 Yes Yes Yes No No

1365 Yes Yes Yes Yes Yes


OSA-Express GbE SXc d
2365b Yes Yes Yes Yes Yes

OSA-Express2 GbE SX 3365 Yes Yes Yes No No

OSA-Express2 10 GbE LR 3368 Yes Yes Yes No No

OSA-Express 1000BASE-Td 1366 Yes Yes Yes No No

OSA-Express2 1000BASE-T 3366 Yes No No No No

OSA-Express FENETd e 2366 Yes Yes Yes Yes Yes

OSA-Express Token Ring 2367 No Yes Yes Yes Yes

OSA-Express ATM SM 2362 No No Yesf Yes Yes

OSA-Express ATM MM 2363 No No Yesf Yes Yes


a. Superseded by FC 3364 for z990 and z890
b. No longer orderable
c. Superseded by FC 3365 for z990 and z890
d. Only carried forward on an upgrade to z9-109, z990 or z890
e. Superseded by FC 1366 for z990 and z890, and FC 3366 for z9-109
f. Only supported on z990 via RPQ 8P2258 when carried forward from z900

38 OSA-Express Implementation Guide


1.5 References
For further information on the OSA-Express features and configuration, see:
򐂰 Open Systems Adapter-Express Customer’s Guide and Reference for S/390, SA22-7403
򐂰 zSeries: Open Systems Adapter-Express Customer’s Guide and Reference, SA22-7476
򐂰 z/OS Open Systems Adapter Support Facility User’s Guide, SC28-1855
򐂰 Resource Measurement Facility Report Analysis, SC28-1950
򐂰 VM/ESA Open Systems Adapter Support Facility User’s Guide, SC28-1992
򐂰 VSE/ESA Open Systems Adapter Support Facility User’s Guide, SC28-1946
򐂰 Communications Server: IP Configuration, SC31-8513
򐂰 Communications Server: SNA Network Implementation Guide, SC31-8563
򐂰 Network and e-business Products Reference booklet, GX28-8002
򐂰 IBM Communication Controller Migration Guide, SG24-6298

Chapter 1. Overview of Open Systems Adapter-Express 39


40 OSA-Express Implementation Guide
2

Chapter 2. Quick start


This chapter provides information to help you achieve a quick start with your Open Systems
Adapter-Express (OSA-Express) installation. It assists you in determining which elements
you need based on your requirements. It also directs you to the appropriate sections in this
IBM Redbook for details.

© 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.

2.2 OSA/SF requirements


Open Systems Adapter Support Facility (OSA/SF) is used to configure the OSA-Express
features for non-QDIO mode, with one exception, the TCP/IP Passthru mode (non-shared).
You need OSA/SF for the 155 asynchronous transfer mode (ATM) feature even if it is being
configured for QDIO mode (ATM Ethernet LAN emulation (LANE)). This is because you must
configure the port definitions for the 155 ATM feature.

For a quick check to determine if OSA/SF is required for your installation, refer to Table 2-1.

Table 2-1 OSA/SF requirement


OSA-Express feature OSD (QDIO) OSE (non-QDIO) OAT built OSA/SF required

10 GbE LR Yes Dynamic No

GbE Yes Dynamic No

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

ATM Native Yes Manual Yes

42 OSA-Express Implementation Guide


For more information, see Chapter 4, “Setting up and using OSA/SF” on page 59.

2.3 Policy-based networking


UNIX® Policy Agent (PAGENT) is not required for OSA-Express. It is an option that you can
implement to manage and prioritize network traffic. For more information about PAGENT, see
“Priority queuing” on page 5.

2.4 TCP/IP quick start


If you have not yet configured your System z9 or zSeries TCP/IP environment, consider using
an IBM wizard or configuration tool.

z/OS TCP/IP Wizard


IBM provides a Web site that has access to several wizards that can assist you with
configuring your z/OS system. Included is a wizard for configuring TCP/IP. When you provide
your network definitions, the wizard gives you the configuration information required to set up
your z/OS TCP/IP environment.

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/

z/VM TCP/IP Wizard


A TCP/IP configuration wizard is packaged with z/VM. This new utility automates the
connection of a newly installed z/VM system to a TCP/IP-based network. The z/VM TCP/IP
configuration wizard requires no knowledge of TCP/IP for z/VM, and is similar to the network
configuration utilities used in Linux on System z9 and zSeries distributions during Linux
installation.

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).

Chapter 2. Quick start 43


2.5 Quick start tables
This section provides tables to help you to identify your OSA-Express feature and
implementation requirements. These tables direct you to installation information and setup
examples.

For more information about the different types of OSA-Express features, refer to Chapter 1,
“Overview of Open Systems Adapter-Express” on page 1.

2.5.1 Notes regarding the quick start tables


When reviewing Table 2-2 or Table 2-3, keep the following notes in mind for any additional
information related to your OSA-Express implementation:
򐂰 If you are using the default values for 1000BASE-T, Fast Ethernet, or Token Ring, OSA/SF
is not required. The default values are in regard to:
– Non-shared CHPID (port is not shared between logical partitions (LPAR))
– CHPID type OSE (non-QDIO)
– Port not shared between TCP/IP stacks
– TCP/IP and SNA cannot share the port concurrently
– Using the default unit addresses (starting with 00)
– Using TCP/IP Passthru only
򐂰 OSA/SF configuration is not required for OSA-Express features when defined as CHPID
types OSN and OSD.
򐂰 OSA/SF is required to complete the configuration of the ATM feature under all
circumstances.
򐂰 If SNA and APPN (LU6.2) are required for an OSA-Express feature that is defined as
CHPID type OSD, you must use Enterprise Extender. See Chapter 10, “Enterprise
Extender” on page 165.
򐂰 Layer 2 support for an OSA-Express feature that is defined as CHPID type OSD, allows for
communication with IP and non-IP protocols, such as NetBIOS and SNA. OSA-Express
works in conjunction with the virtual switch (a component of z/VM V5.1) to enable Layer 2
functionality for guest systems, such as Linux on System z9 and zSeries. See Chapter 12,
“Layer 2 support” on page 201.
򐂰 You can use TN3270 in conjunction with SNA (LU2) applications, when the OSA-Express
feature is defined as CHPID type OSD.

44 OSA-Express Implementation Guide


z/OS quick start table
Table 2-2 contains TCP/IP and VTAM definitions, as well as the CHPID types needed when
configuring the OSA-Express ports for use in a z/OS environment. It also provides references
to the appropriate sections in this IBM Redbook.

Table 2-2 z/OS quick start table


OSA-Express Operation CHPID TCP/IP TCP/IP link type VTAM Go to...
feature mode type device type definitions

10 GbE LR QDIO OSD MPCIPA IPAQENET TRLE Chapter 5, “QDIO


TCP/IP mode” on page 79

GbE QDIO OSD MPCIPA IPAQENET TRLE Chapter 5, “QDIO


TCP/IP mode” on page 79

QDIO OSD MPCIPA IPAQENET TRLE Chapter 5, “QDIO


TCP/IP mode” on page 79

1000BASE-T Non-QDIO OSE LCS ETHERNet, 802.3, Chapter 7, “Non-QDIO


TCP/IP or ETHEROR802.3 mode (TCP/IP and
SNA)” on page 101
Non-QDIO OSE XCA,
SNA SWNET

QDIO OSD MPCIPA IPAQENET TRLE Chapter 5, “QDIO


TCP/IP mode” on page 79

FENET Non-QDIO OSE LCS ETHERNet, 802.3, Chapter 7, “Non-QDIO


TCP/IP or ETHEROR802.3 mode (TCP/IP and
SNA)” on page 101
Non-QDIO OSE XCA,
SNA SWNET

QDIO OSD MPCIPA IPAQTR TRLE Chapter 5, “QDIO


TCP/IP mode” on page 79

Token Ring Non-QDIO OSE LCS IBMTR Chapter 7, “Non-QDIO


TCP/IP mode (TCP/IP and
SNA)” on page 101
Non-QDIO OSE XCA,
SNA SWNET

ATM LANE QDIO OSD MPCIPA IPAQENET TRLE Chapter 5, “QDIO


(ETH) TCP/IP mode” on page 79 and
9.3, “Creating and
saving the configuration
with OSA/SF GUI” on
page 143

Non-QDIO OSE LCS ETHERNet, 802.3, Chapter 9, “ATM LAN


TCP/IP ETHEROR802.3, emulation (non-QDIO
ATM LANE or IBMTR mode)” on page 141
(TR or ETH)
Non-QDIO OSE XCA,
SNA SWNET

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

Chapter 2. Quick start 45


z/VM quick start table
Table 2-3 contains CHPID and TCP/IP definitions to use when you configure the
OSA-Express ports for use in a z/VM environment.

Table 2-3 z/VM quick start table


OSA-Express Operation CHPID TCP/IP device TCP/IP link type VTAM
feature mode type type definitions

10 GbE LR QDIO OSD OSD QDIOETHERNET


TCP/IP

GbE QDIO OSD OSD QDIOETHERNET


TCP/IP

QDIO OSD OSD QDIOETHERNET


TCP/IP

1000BASE-T Non-QDIO OSE LCS ETHERNET, 802.3, or


TCP/IP ETHEROR802.3

Non-QDIO OSE XCA, SWNET


SNA

QDIO OSD OSD QDIOETHERNET


TCP/IP

FENET Non-QDIO OSE LCS ETHERNET, 802.3, or


TCP/IP ETHEROR802.3

Non-QDIO OSE XCA, SWNET


SNA

QDIO OSD OSD QDIOTR


TCP/IP

Token Ring Non-QDIO OSE LCS IBMTR


TCP/IP

Non-QDIO OSE XCA, SWNET


SNA

ATM LANE (ETH) QDIO OSD OSD QDIOATM


TCP/IP

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.

2.6 Linux definitions: Updating files


Several files require updating for OSA-Express implementation in a Linux environment. Refer
to “Linux definitions” on page 283 for examples of our implementation.

46 OSA-Express Implementation Guide


3

Chapter 3. Hardware configuration


definitions
As with all channel-attached devices, you must define an Open Systems Adapter-Express
(OSA-Express) feature by a channel path, a control unit, and input/output (I/O) devices in the
IOCDS. This chapter takes you through the steps to define the OSA-Express to the System
z9 or zSeries environment, using the z/OS Hardware Configuration Definition (HCD) tool. To
simplify the configuration process of the environment (Figure 3-1 on page 48), we have
extracted the portions of the setup that are common to all modes and types of the
OSA-Express.

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 0 LPAR LPAR


SC64 SC65

LCSS 1

PCHID 110 PCHID 310


CHPID OA CHPID OB
OSD OSD
Spanned Spanned

LAN Infrastructure

Figure 3-1 HCD definitions for OSA-Express CHPIDs

3.2 Hardware Configuration Definition


HCD is used to define the OSA-Express feature to the I/O hardware configuration. Examples
of the following definitions are included:
򐂰 Channel path
򐂰 Control unit
򐂰 Devices

48 OSA-Express Implementation Guide


3.2.1 Channel path definition
We created our definitions on a z/OS 1.6 system. Starting from the HCD main menu panel
(Figure 3-2), follow these steps:
1. Select option 1 and press Enter.

Hardware Configuration

Select one of the following.

1 1. Define, modify, or view configuration data


2. Activate or process configuration data
3. Print or compare configuration data
4. Create or view graphical configuration report
5. Migrate configuration data
6. Maintain I/O definition files
7. Query supported hardware and installed UIMs
8. Getting started with this dialog
9. What's new in this release

For options 1 to 5, specify the name of the IODF to be used.

I/O definition file . . . 'SYS6.IODFCC'

Figure 3-2 HCD main menu

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.

/ Proc. ID Type + Model + Mode+ Serial-# + Description


_ SCZP701 9672 XX7 LPAR 0508229672 ____________
_ SCZP702 9672 Z47 LPAR 0573329672 ____________
_ SCZP801 2064 1C7 LPAR 010ECB2064 ____________
S SCZP901 2084 A08 LPAR 026A3A2084 ____________

Figure 3-3 Processor list

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

CSS Max number


/ ID of devices + Description
S 0 64512 ________________________________
_ 1 64512 ________________________________

Figure 3-4 Channel subsystem list

Chapter 3. Hardware configuration definitions 49


5. In the Channel Path List display, press F11 to add a channel path.
6. In the Add Channel Path display, enter all the required information, as shown in Figure 3-5.
a. We defined 0A for the CHPID and 110 as the PCHID.
b. For Channel path type, we specify OSD, because we are defining 1000BASE-T, which
supports QDIO.
c. For Operation mode, we specify SPAN, because the feature will be shared among
LPARs and LCSSs.
d. For description, we recommend that you use a meaningful description to serve as a
reference point in HCD.
e. Press Enter.

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.

_________________________Add Channel Path___________________________

Specify or revise the following values.

Processor ID . . . . : SCZP901
Configuration mode . : LPAR
Channel Subsystem ID : 0

Channel path ID . . . . 0A + PCHID . . . 110


Number of CHPIDs . . . . 1
Channel path type . . . OSD +
Operation mode . . . . . SPAN +
Managed . . . . . . . . No (Yes or No) I/O Cluster ________ +
Description . . . . . . ________________________________

Specify the following values only if connected to a switch:


Dynamic entry switch ID __ + (00 - FF)
Entry switch ID . . . . __ +
Entry port . . . . . . . __ +

Figure 3-5 Add Channel Path display

50 OSA-Express Implementation Guide


7. In the next display (Figure 3-6), specify whether you want more than 160 TCP/IP stacks.
You can find details for this support in “Maximum TCP/IP stacks and devices” on page 8.

___________Allow for more than 160 TCP/IP stacks______

Specify Yes to allow more than 160 TCP/IP stacks,


otherwise specify No.

Will greater than 160 TCP/IP stacks


be required for this channel? . . . No

Figure 3-6 Allow TCP/IP stacks

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.

______________________________ Partition List_____________________________


Goto Backup Query Help
-----------------------------------------------------------------------
Row 1 of 15
Command ===> ________________________________________ Scroll ===> PAGE

Select one or more partitions, then press Enter. To add, use F11.

Processor ID . . . . : SCZP901
Configuration mode . : LPAR
Channel Subsystem ID : 0

/ Partition Name Number Usage + Description


/ A0A A OS Sysplex SC69
/ A0B B OS SC58
/ A0C C OS Sandbox Sysplex SC63
_ A0D D CF Sandbox Sysplex CF1
_ A0E E CF Trainer Sysplex FACIL03
_ A0F F CF Trainer Sysplex FACIL04
/ A01 1 OS Sysplex SC55
F1=Help F2=Split F3=Exit F4=Prompt F5=Reset
F7=Backward F8=Forward F9=Swap F10=Actions F11=Add

Figure 3-7 Access list definition panel (Part 1 of 2)

Chapter 3. Hardware configuration definitions 51


Press PF8 to view and select additional partitions (see Figure 3-8). Then press Enter.

______________________________ Partition List ____________________________


Goto Backup Query Help
-----------------------------------------------------------------------
Row 8 of 15
Command ===> _______________________________________ Scroll ===> PAGE

Select one or more partitions, then press Enter. To add, use F11.

Processor ID . . . . : SCZP901
Configuration mode . : LPAR
Channel Subsystem ID : 0

/ Partition Name Number Usage + Description


/ A02 2 OS Sysplex SC54
/ A03 3 OS Sysplex SC49
/ A04 4 OS Trainer #@$1
/ A05 5 OS Trainer #@$2
/ A06 6 OS Trainer #@$3
/ A07 7 OS Sysplex SC61
/ A08 8 OS Sysplex SC62
F1=Help F2=Split F3=Exit F4=Prompt F5=Reset
F7=Backward F8=Forward F9=Swap F10=Actions F11=Add

Figure 3-8 Access list definition panel (Part 2 of 2)

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.

3.2.2 Control unit definition


From the Channel Path List panel, follow these steps.
1. Type an S next to the CHPID that you just defined (0A, in our example), and press Enter.
2. Press F11 to add a control unit.
3. In the Add Control Unit display (Figure 3-9), enter the required information.
a. For Control unit number, we chose E200.
b. Control unit type must be OSA.
c. Press Enter.

52 OSA-Express Implementation Guide


_________________________ Add Control Unit _____________________

Specify or revise the following values.

Control unit number . . . . E200 +


Control unit type . . . . . OSA__________ +

Serial number . . . . . . . __________


Description . . . . . . . . 1000BASE-T______________________

Connected to switches . . . __ __ __ __ __ __ __ __ +
Ports . . . . . . . . . . . __ __ __ __ __ __ __ __ +

If connected to a switch:

Define more than eight ports . . 2 1. Yes


2. No
Propose CHPID/link addresses and
unit addresses . . . . . . . . . 2 1. Yes
2. No

Figure 3-9 Add Control Unit (Part 1 of 2)

4. As shown in Figure 3-10, type an S next to the processor for the control unit. Then press
Enter.

Select Processor / CU Row 1 of 5 More:


Command ===> _______________________________________________ Scroll ===>

Select processors to change CU/processor parameters, then press Enter.

Control unit number . . : E200 Control unit type . . . : OSA

---------------Channel Path ID . Link Address + -----------


/ Proc.CSSID 1------ 2------ 3------ 4------ 5------ 6------ 7------ 8--
_ SCZP701 _______ _______ _______ _______ _______ _______ _______ ___
_ SCZP702 _______ _______ _______ _______ _______ _______ _______ ___
_ SCZP801 _______ _______ _______ _______ _______ _______ _______ ___
S SCZP901.0 _______ _______ _______ _______ _______ _______ _______ ___
_ SCZP901.1 _______ _______ _______ _______ _______ _______ _______ ___

Figure 3-10 Processor selection

Chapter 3. Hardware configuration definitions 53


5. Figure 3-11 shows the OSA-Express control unit information. Note that the Unit address
must be set to 00 and the number of units must be 255. Press Enter.

______________________________ Add Control Unit ___________________________

Specify or revise the following values.

Control unit number . : E200 Type . . . . . . : OSA


Processor ID . . . . . : SCZP901
Channel Subsystem ID . : 0

Channel path IDs . . . . 0A __ __ __ __ __ __ __ +


Link address . . . . . . ____ ____ ____ ____ ____ ____ ____ ____ +

Unit address . . . . . . 00 __ __ __ __ __ __ __ +
Number of units . . . . 255 ___ ___ ___ ___ ___ ___ ___

Logical address . . . . __ + (same as CUADD)

Protocol . . . . . . . . __ + (D,S or S4)


I/O concurrency level . 2 + (1, 2 or 3)

Figure 3-11 Add Control Unit (Part 2 of 2)

6. Press Enter again to return to the Control Unit List panel.

3.2.3 Device definition


From the Control Unit List panel, follow these steps:
1. Type an S to select the control unit. Then press Enter.
2. Press F11 to add devices.
3. In the Add Device display, enter the required information as shown in Figure 3-12.
a. For Device number, we chose E200.
b. For Number of devices, we chose 15.
c. Device type must be OSA.
d. Press Enter.

________________________________Add Device____________________________

Specify or revise the following values.

Device number . . . . . . . . E200 (0000 - FFFF)


Number of devices . . . . . . 15__
Device type . . . . . . . . . OSA__________ +

Serial number . . . . . . . . __________


Description . . . . . . . . . 1000BASE-T______________________

Volume serial number . . . . . ______ (for DASD)

Connected to CUs . . E200 ____ ____ ____ ____ ____ ____ ____ +

Figure 3-12 Add Device display

54 OSA-Express Implementation Guide


Note: How many devices should you define? That depends on the CHPID type, number
of TCP/IP stacks, and SNA definitions required. For the number of devices, consider
the following points:
򐂰 Any OSD CHPID requires at least three devices (read, write, and datapath) for each
TCP/IP stack. For z/OS, only the first TCP/IP stack requires three devices, any
additional TCP/IP stack requires only one device (datapath).
򐂰 Any OSE CHPID requires two devices (read and write) for each TCP/IP. SNA use
requires one device, with the exception of ATM, which requires two devices for SNA.

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.

______________________ Device / Processor Definition ____________________


e Row 1 of 2
Command ===> _______________________________________ Scroll ===> PAGE

Select processors to change device/processor definitions, then press


Enter.

Device number . . : E200 Number of devices . : 15


Device type . . . : OSA

Preferred Device Candidate List


/ Proc.CSSID UA + Time-Out STADET CHPID + Explicit Null
/ SCZP901.0 __ No No __ No ___
_ SCZP901.1 __ No No __ No ___

Figure 3-13 Device / Processor Definition display

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.

___________________________Define Device / Processor_________________________

Specify or revise the following values.

Device number . : E200 Number of devices . . . . : 15


Device type . . : OSA
Processor ID . . . . : SCZP901
Channel Subsystem ID : 0

Unit address . . . . . . . . . . 00 + (Only necessary when different from


the last 2 digits of device number)
Time-Out . . . . . . . . . . . . No (Yes or No)
STADET . . . . . . . . . . . . . No (Yes or No)

Preferred CHPID . . . . . . . . __ +
Explicit device candidate list . No (Yes or No)

Figure 3-14 Define Device / Processor display

Chapter 3. Hardware configuration definitions 55


7. Press Enter again.
8. The Define Device to Operating System Configuration display is shown. Type an S next to
the operating system to which you want to connect the devices. Press Enter.
9. On the resulting displays, press Enter to accept the default values.
10.Repeat the process for each operating system as needed.
11.You should now see the Device List display. If you plan to use OSA/SF, define an OSAD
device. Press F11 to add a new device.
12.In the Add Device display, define the new device as shown in Figure 3-15.

__________________________________Add Device_________________________

Specify or revise the following values.

Device number . . . . . . . . E20F (0000 - FFFF)


Number of devices . . . . . . 1___
Device type . . . . . . . . . OSAD_________ +

Serial number . . . . . . . . __________


Description . . . . . . . . . 1000BASE-T______________________

Volume serial number . . . . . ______ (for DASD)

Connected to CUs . . E200 ____ ____ ____ ____ ____ ____ ____ +

Figure 3-15 OSAD definition (Part 1 of 2)

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.

___________________________Define Device / Processor______________________

Specify or revise the following values.

Device number . : E20F Number of devices . . . . : 1


Device type . . : OSAD
Processor ID . . . . : SCZP901
Channel Subsystem ID : 0

Unit address . . . . . . . . . . FE + (Only necessary when different from


the last 2 digits of device number)
Time-Out . . . . . . . . . . . . No (Yes or No)
STADET . . . . . . . . . . . . . No (Yes or No)

Preferred CHPID . . . . . . . . __ +
Explicit device candidate list . No (Yes or No)

Figure 3-16 OSAD definition (Part 2 of 2)

56 OSA-Express Implementation Guide


14.Define the device with these parameters to the operating system configuration, as shown
in Figure 3-17. Then press Enter.

_____________Define Device to Operating System Configuration____________


Row 1 of 4
Command ===> _____________________________________ Scroll ===> PAGE

Select OSs to connect or disconnect devices, then press Enter.

Device number . : E20F Number of devices : 1


Device type . . : OSAD

/ Config. ID Type Description Defined


/ L06RMVS1 MVS Sysplex systems
_ MVSW1 MVS Production systems
_ OPENMVS1 MVS OpenEdition MVS
_ TRAINER MVS Trainer/GDPS Systems

Figure 3-17 Device/Operating System Configuration display

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.

______________________Define Device Parameters / Features_____________________


Row 1 of 3
Command ===> ___________________________________________ Scroll ===> PAGE

Specify or revise the values below.

Configuration ID . : L06RMVS1 Sysplex systems


Device number . . : E20F Number of devices : 1
Device type . . . : OSAD

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

Figure 3-18 Defining Device Parameters / Features display

Chapter 3. Hardware configuration definitions 57


3.2.4 Generating the input IOCDS from HCD
You can generate input for IOCDS from HCD. It is then used to write the macro definitions to
the System z9 or zSeries server and can be used for quick debugging purposes. Example 3-1
depicts an IOCDS input that was generated by HCD for spanned OSA-Express ports running
in QDIO mode as shown in Figure 3-1 on page 48.

Example 3-1 IOCDS input


ID MSG2='SYS6.IODFCC - 2004-09-17 16:18',SYSTEM=(2084,1), *
TOK=('SCZP901',0080000A6A3A2084161833510104257F00000000,*
00000000,'04-09-17','16:18:33','SYS6','IODFCC')
RESOURCE PARTITION=((CSS(0),(A0A,A),(A0B,B),(A0C,C),(A0D,D),(A0E,E), *
(A0F,F),(A01,1),(A02,2),(A03,3),(A04,4),(A05,5),(A06,6),(A08,8), *
(A09,9)),(CSS(1),(A1A,A),(A1B,B),(A1C,C),(A1D,D),(A1E,E),(A1F,F),*
(A11,1),(A12,2),(A13,3),(A14,4),(A15,5),(A16,6),(A17,7),(A18,8), *
(A19,9))), *
MAXDEV=((CSS(0),64512),(CSS(1),64512))
CHPID PATH=(CSS(0,1),0A),SHARED, *
NOTPART=((CSS(0),(A0D,A0E,A0F),(=)),(CSS(1),(A1C,A1D,A1E,A1F), *
(=))),PCHID=110,TYPE=OSD
CHPID PATH=(CSS(0,1),0B),SHARED, *
NOTPART=((CSS(0),(A0D,A0E,A0F),(=)),(CSS(1),(A1C,A1D,A1E,A1F), *
(=))),PCHID=310,TYPE=OSD
CNTLUNIT CUNUMBR=E200,PATH=((CSS(0),0A),(CSS(1),0A)),UNIT=OSA
IODEVICE ADDRESS=(E200,015),CUNUMBR=(E200),UNIT=OSA
IODEVICE ADDRESS=E20F,UNITADD=FE,CUNUMBR=(E200),UNIT=OSAD
CNTLUNIT CUNUMBR=2D80,PATH=((CSS(0),0B),(CSS(1),0B)),UNIT=OSA
IODEVICE ADDRESS=(2D80,015),UNITADD=00,CUNUMBR=(2D80),UNIT=OSA
IODEVICE ADDRESS=2D8F,UNITADD=FE,CUNUMBR=(2D80),UNIT=OSAD

58 OSA-Express Implementation Guide


4

Chapter 4. Setting up and using OSA/SF


The Open Systems Adapter Support Facility (OSA/SF) is an application that helps you to
customize and manage your Open Systems Adapter-Express (OSA-Express) features. It also
allows you to obtain status and operational information about the Hardware Configuration
Definition (HCD)-defined OSA-Express features, to assist in problem determination.

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

Host Host Host Host Host


Programs Programs Programs Programs Programs

OSA/SF OSA/SF OSA/SF OSA/SF

Channel
Subsystem

OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA

Figure 4-1 OSA/SF communication path

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.

60 OSA-Express Implementation Guide


4.2 Setting up OSA/SF in z/OS or z/OS.e environment
This section explains how to set up OSA/SF on z/OS and z/OS.e. For information relating to
the z/VM or VSE operating systems, see 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.

4.2.1 Setting up APPC and VTAM


Before using OSA/SF to manage your OSA-Express features, you must configure APPC
communication regardless of the connection type used.

We used the following steps to set up the APPC environment:


1. Define the VTAM APPL statement for OSA/SF, edit VTAM Major Node member APPCOSA
in the VTAMLST, and add the statements shown in Example 4-1.

Example 4-1 APPCOSA from SYS1.VTAMLST


IOASERV APPL ACBNAME=IOASERV,
APPC=YES,AUTOSES=0,DDRAINL=NALLOW,
DMINWNL=5,DMINWNR=5, DRESPL=NALLOW,
DSESLIM=10,LMDENT=19,MODETAB=MTAPPC,
SECACPT=ALREADYV

2. Define an APPC local LU for OSA/SF by editing member APPCPMxx in the


SYS1.PARMLIB and adding the statements shown in Example 4-2.

Note: There is no dependency on the APPC scheduler for OSA/SF.

Example 4-2 APPCPM00 from SYS1.PARMLIB


LUADD
ACBNAME(IOASERV)
NOSCHED
TPDATA(SYS1.APPCTP)

Note: SYS1.APPCTP is a VSAM data set. It must be allocated using job ATBTPVSM,
included in SYS1.SAMPLIB.

3. Add the APPC procedure to the SYS1.PROCLIB, as shown in Example 4-3.

Example 4-3 APPC from SYS1.PROCLIB


//APPC PROC APPC=00
//APPC EXEC PGM=ATBINITM,PARM='APPC=&APPC',REGION=0K

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.

Example 4-4 COMMND00 from SYS1.PARMLIB


COM='S APPC,SUB=MSTR'

Chapter 4. Setting up and using OSA/SF 61


4.2.2 Setting up OSA/SF
To set up OSA/SF, use the following steps:
1. Create an STC (Started Task):
a. Copy the sample procedure from IOA.SIOASAMP(IOAOSASF) to SYS1.PROCLIB.
b. Edit the procedure and change the name to OSASF.
c. Verify that the data set names in the STEPLIB and IOALIB DDname statements match
your environment.
2. Create a startup profile for OSA/SF:
a. Allocate a sequential data set.
b. Copy into this data set the sample provided in IOA.SIOASAMP(IOASPROF).
c. Edit the profile and change SYSNAME and CECNAME to suit your installation (verify
UNIT and VOLSER).
3. Set up the OSA configuration and master profile:
a. Allocate data set IOA.&CECNAME.OSAS.CONFIG and copy it into the sample
provided in IOA.SIOASAMP(IOACFG).
b. Allocate data set IOA.&CECNAME.MASTER.INDEX and copy it into the sample
provided in IOA.SIOASAMP(IOAINX).
4. Set up REXX executable for use under TSO. Copy member IOACMD from
IOA.SIOASAMP to your local lists or executable data sets.
5. Issue the following commands from the SDSF log:
/s appc,sub=mstr
/s osasf

4.2.3 Communicating with OSA/SF using TCP/IP


As mentioned previously, we used TCP/IP as the connection type for communicating with
OSA/SF from a workstation. To set up TCP/IP, we used the following steps:
1. Update the TCPIP.TCPPARM(PROFILE) with the following data.
a. Add the server to the AUTOLOG statement, as shown in Example 4-5.

Example 4-5 IOASRV from TCP/IP profile


AUTOLOG
.
IOASRV
.

b. Add the port statement, as shown in Example 4-6.

Example 4-6 Port number from TCP/IP profile


PORT
.
2000 TCP IOASRV ; OSA/SF Server
.

62 OSA-Express Implementation Guide


2. Create a procedure in SYS1.PROCLIB(IOASRV), as shown in Example 4-7.

Example 4-7 IOASRV from SYS1.PROCLIB


//*
//* Sample TCP/IP Server Proc
//*
//SERVER PROC
//SERVER EXEC PGM=IOAXTSRV,PARM=2000,REGION=4M,TIME=1440
//IOALIB DD DSN=SYS1.SIOALMOD,DISP=SHR
//PROFILE DD DISP=SHR,DSN=TCPIPMVS.&SYSNAME..TCPPARMS(TCPPROF)

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 Installing OSA/SF GUI on a workstation


We used the following steps to install and set up the OSA/SF GUI on a Windows workstation
after we installed and set up OSA/SF on the host system.

4.3.1 Checking the hardware configuration


To use the OSA/SF GUI interface, a workstation with the following minimum hardware
features is required:
򐂰 A Pentium® 200 MHz (or equivalent), 32 MB of RAM
򐂰 An SVGA display with a resolution of 1024 by 768 with 16-bit colors
򐂰 A communications adapter that supports the TCP/IP communications protocol

In our configuration, we used:


򐂰 An IBM NetVista 1.8 GHz 1 GB RAM
򐂰 A display with a resolution of 1024 by 768 with 32 bit colors
򐂰 A 100BASE-T Ethernet adapter

4.3.2 Checking the software configuration


To use the GUI in conjunction with z/OS, z/OS.e, z/VM, or VSE/ESA, you must have a
workstation with either of the following versions:
򐂰 Microsoft® Windows 2000 or Windows XP with Service Pack 6a or later, as well as:
– A TCP/IP network connection
– Java 1.4 or later
– JavaHelp™ 1.1.2 or later
򐂰 Linux Kernel Version 2.4 or later with:
– A TCP/IP network connection
– Java 1.4 or later
– JavaHelp 1.1.2 or later

Chapter 4. Setting up and using OSA/SF 63


In our configuration, we used:
򐂰 Windows XP
򐂰 TCP/IP network connection
򐂰 Java 1.4
򐂰 JavaHelp 1.1.2

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.

For Java runtime, go to the following site:


http://java.sun.com/

For the JavaHelp files, go to the following site:


http://java.sun.com/products/javahelp/download_binary.html

4.3.4 Downloading the code from z/OS using FTP


Before you download the IOAJAVA GUI code, create a directory on your Windows workstation
where you can place the code for the GUI (ioajava.jar).

To download the OSA/SF GUI to the workstation, use these steps:


1. Open a DOS session on your workstation.
2. Change to the directory where you want the exec stored, by typing:
CD
3. Enter the File Transfer Protocol (FTP) command, using the IP address of your Host (for
example, FTP 192.168.14.32).
4. Enter your user ID and password.
5. Enter the following command to set the FTP transfer to binary:
bin
6. Enter the following command (the z/OS dataset name in single quotes):
cd ‘ioa.sioajava’
7. Enter the following command:
get ioajava ioajava.jar
8. When the download has completed successfully, enter the following command:
bye

4.3.5 Defining the CLASSPATH environment variable


After you download the GUI code, define the CLASSPATH environment variable for Windows.
1. In Windows, go to the Control Panel. Double-click System.
2. In the System Properties window, click the Advanced tab. On this page, click the
Environment Variables button.

64 OSA-Express Implementation Guide


3. In the Environment Variables window, define the CLASSPATH environment variable for
Windows. Select CLASSPATH and click the Edit button. If you do not find CLASSPATH
listed, click New to create it.
a. For CLASSPATH Variable Value, specify the directories where you have stored the
Java help files and the OSA/SF GUI code that you transferred. For example, you may
have the following CLASSPATH definitions for Variable Value:
C:\Program Files\Java\jh1.1.3\javahelp\lib\jh.jar;C:\osajavagui\ioajava.jar
b. Specify CLASSPATH for Variable Name in the window, if you are creating this variable.
c. Click OK.

4.3.6 Starting the OSA/SF GUI


Complete the following actions before you start the GUI:
1. Set up an OSA/SF GUI TCP/IP connection for your workstation.
2. Start an OSA/SF IOASRV task on the host system.

Starting the OSA/SF GUI on Windows


Follow these steps:
1. Open a new Command Prompt (DOS) window.
2. Change to the directory where the ioajava code resides.
3. Enter the following command from the C:\> command prompt:
java ioajava

4.4 Using the OSA/SF GUI


After you complete the steps for setting up the OSA/SF GUI, you can use the command
windows to configure an OSA-Express CHPID. The help panels that are part of the GUI
provide information for each window.

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.

Figure 4-2 OSA/SF Host - Open log on

Chapter 4. Setting up and using OSA/SF 65


The following sequence explains how to access the OSA/SF Commands window via the
Host - Open window. It also explains the functions that you can perform from the OSA/SF
Commands window.
1. In the Host - Open window (Figure 4-2), complete these tasks:
a. Enter the following information:
• Host name or IP address of the host system
• Port (specified in TCP/IP profile, see Example 4-6 on page 62)
• User ID and password for the system
b. Click Open.
2. The connection is established. Then you see the Workstation Interface window
(Figure 4-3). Two panels open when the interface is displayed:
– Command Output: This panel shows the result of any command that is run.
– OSA/SF Commands: This GUI allows you to enter most REXX commands.
Click the CHPID View button.

Figure 4-3 Workstation Interface

66 OSA-Express Implementation Guide


3. The CHPID View window (Figure 4-4) opens. It shows the CHPIDs managed by OSA/SF.
a. In our case, we double-clicked CHPID 0A (highlighted in the example).

Figure 4-4 CHPID view

Chapter 4. Setting up and using OSA/SF 67


b. Now you see the settings for that CHPID as shown in Figure 4-5. This window shows
the following information:
• The PCHID related to CHPID (in our case, 110)
• The type of OSA (in our case, 1000BASE-T Ethernet)
• The mode configured (in our case, QDIO)
• The OSA processor code level (in our case, 6.16)
Return to the CHPID View window.

Figure 4-5 CHPID settings

68 OSA-Express Implementation Guide


c. We double-click Port 0 for CHPID 0A as shown in Figure 4-6.

Figure 4-6 Port View

Chapter 4. Setting up and using OSA/SF 69


d. Now you see the settings as shown in Figure 4-7. This window shows the following
information:
• The LAN traffic state (enable)
• The MAC address
• The active speed mode (100 Mbps)
To view the packets transmitted and received and error counters, select the Statistics
tab.

Figure 4-7 Port settings

70 OSA-Express Implementation Guide


Figure 4-8 shows the details of the Statistics tab.

Note: The SNA tab is not applicable in QDIO mode.

Figure 4-8 Port Statistics tab

Chapter 4. Setting up and using OSA/SF 71


4. From the OSA/SF Commands panel shown in Figure 4-3 on page 66, select Configure
OSA CHPID.
5. In the Configure OSA CHPID window, complete these steps:
a. Type the CHPID number. In our case, we type 0A.
b. Select the proper CHPID. In our case, we choose OSD 1000Base-T Ethernet.
c. Change the configuration for CHPID 0A as in Figure 4-9. For example, you can:
• Select Specify local (address) instead of Use universal MAC.
• Change the LAN speed, for example, from 100 Mbps full duplex to 100 Mbps half
duplex.

Figure 4-9 1000Base-T Configuration settings

6. Back on the OSA/SF Commands panel (Figure 4-3 on page 66), select Install.

Note: The Install command is used to load an existing configuration onto an


OSA-Express only when you replace the OSA-Express feature. It is not for initial
installation.

72 OSA-Express Implementation Guide


7. To perform the initial configuration, select Activate. The Install window (Figure 4-10)
opens.

Figure 4-10 Install command

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.

Figure 4-11 Query window

Chapter 4. Setting up and using OSA/SF 73


The result appears in the Command Output window (Figure 4-12).

Figure 4-12 Output of query One OSA

10.From the OSA/SF Commands panel (Figure 4-3 on page 66), select Set Parameters.

74 OSA-Express Implementation Guide


11.In the OSA/SF Set Parameters window (Figure 4-13), depending on the type of feature,
you can now set some parameters. In our case, the only action to be done for 1000Base-T
is Enable or Disable LAN Traffic State.

Figure 4-13 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.

Chapter 4. Setting up and using OSA/SF 75


򐂰 Debug: This function of the OSA/SF GUI helps you to troubleshoot OSA problems. As
stated in the Debug OSA window (Figure 4-14), use these Debug OSA commands only
with assistance from IBM support.

Figure 4-14 Debug OSA

Follow these steps:


1. From the OSA/SF Commands panel (Figure 4-3 on page 66), select CHPID View.
2. From the CHPID View window, click Selected →Open Device Information to view device
information as shown in Figure 4-15.

Figure 4-15 CHPID View (Device Information)

76 OSA-Express Implementation Guide


Figure 4-16 shows the device information for CHPID 0A. You can see that unit addresses
E200 to E202 are online and allocated. This means that:
– VTAM TRL is active.
– TCP/IP is up and running.

Figure 4-16 Device Information

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.

Figure 4-17 OAT Information

Chapter 4. Setting up and using OSA/SF 77


78 OSA-Express Implementation Guide
5

Chapter 5. QDIO mode


This chapter covers the implementation steps that you need to establish network connectivity
with an Open Systems Adapter-Express (OSA-Express) port using QDIO mode. It guides you
through the steps to create:
򐂰 VTAM definitions to support this configuration
򐂰 TCP/IP definitions to support this configuration

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

Figure 5-1 QDIO mode example

5.2 Hardware Configuration Definition


The OSA channel path identifier (CHPID), the control unit, and the OSA devices must be
defined to Hardware Configuration Definition (HCD) and activated. Refer to Chapter 3,
“Hardware configuration definitions” on page 47, for the procedure to create the definitions.
The necessary definitions for CHPID 0A on partition SC64 (A11) in the IOCDS are shown in
3.2.4, “Generating the input IOCDS from HCD” on page 58.

5.3 Missing Interrupt Handler for QDIO


The WRITE devices (as defined in the TRLE) should have a Missing Interrupt Handler (MIH)
value of at least 15 seconds (or 30 seconds, if running as a guest system on VM).

To determine the current MIH value for the device (E201, in our example), enter the console
command:
D IOS,MIH,DEV=E201

To dynamically change the MIH value, enter the console command:


SETIOS MIH,DEV=E201,TIME=00:15.

To set these values at IPL time, update the IECIOSxx member in PARMLIB.

80 OSA-Express Implementation Guide


Important: On a multisubchannel device, the MIH is automatically configured OFF by
VTAM on the READ subchannel or subchannels. Setting an MIH value of ZERO for a
TCP/IP or VTAM WRITE device disable MIH on those devices.

5.4 Customizing the z/OS network environment

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

E200-E20F Device Number 2D80-2D8F

CHPID 0A CHPID 0B

OSAE200 OSAname OSA2D80


OSA-Express 1000BASE-T OSA-Express 1000BASE-T

Ethernet
Switch
IP Address
192.16.1.15
IP Address
192.16.1.101

Figure 5-2 Network configuration

Chapter 5. QDIO mode 81


5.4.1 TRLE considerations
TCP/IP uses a VTAM interface to run the OSA-Express in QDIO mode. You must define and
activate a Transport Resource List (TRL) major node before TCP/IP starts its QDIO device.
Table 2-2 on page 45 lists various uses of VTAM TRLE definitions. This section provides
implementation examples and the associated TRLE definition requirements.

No LPAR, only one TCP/IP stack, only one OSA-Express CHPID


For this definition, note the following requirements:
򐂰 Only one TRLE (osaname) is needed that contains only one datapath address.
򐂰 TCP/IP must refer to the port name in the TRLE.

No LPAR, multiple TCP/IP stacks, only one OSA-Express CHPID


An example of this definition is three TCP/IP stacks. They must meet the following
requirements:
򐂰 Only one TRLE (osaname) is needed that contains three datapath addresses.
򐂰 Each TCP/IP stack must refer to the port name in the TRLE.
򐂰 VTAM assigns one datapath address to each TCP/IP stack.

No LPAR, only one TCP/IP stack, multiple OSA-Express CHPIDs


Note the following requirements:
򐂰 One TRLE is needed for each OSA-Express CHPID and must contain only one datapath
address.
򐂰 The TCP/IP DEVICE name must match the port name in each of the TRLEs.

No LPAR, multiple TCP/IP stacks sharing multiple OSA-Express CHPIDs


An example of this definition is three TCP/IP stacks and two OSA-Express CHPIDs. They
must meet the following requirements:
򐂰 One TRLE is needed for each OSA-Express CHPID, with each containing three datapath
addresses.
򐂰 Each TCP/IP stack has two DEVICE and LINK statements. Each DEVICE statement must
match the port name in the TRLE.
򐂰 VTAM assigns, from both TRLEs, one datapath address to each TCP/IP stack.

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.

82 OSA-Express Implementation Guide


Multiple LPARs with multiple TCP/IP stacks per LPAR sharing only one
OSA-Express CHPID
For example, consider two TCP/IP stacks per LPAR, that must meet the following
requirements:
򐂰 Only one TRLE is needed in each LPAR, containing two datapath addresses. 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 associated TRLE.
򐂰 VTAM assigns one datapath address to each TCP/IP stack.

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.

5.4.2 VTAM definitions (TRL major node )


Example 5-1 shows the VTAM TRL major node definition for SC63.

Example 5-1 TRL major node for SC63


OSAE200 VBUILD TYPE=TRL
OSAE200P TRLE LNCTL=MPC,
READ=E200,
WRITE=E201,
DATAPATH=(E203),
PORTNAME=OSAE200,
MPCLEVEL=QDIO

Chapter 5. QDIO mode 83


Example 5-2 shows the VTAM TRL major node definition for SC64.

Example 5-2 TRL major node for SC64


OSA2D80 VBUILD TYPE=TRL
OSA2D80P TRLE LNCTL=MPC,
READ=2D80,
WRITE=2D81,
DATAPATH=(2D82),
PORTNAME=OSA2D80,
MPCLEVEL=QDIO

Table 5-1 lists and describes the definitions used in the TRL major node for SC63 (these also
apply for SC64).

Table 5-1 TRL major node definition for SC63


Required Explanation Remarks
parameters

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.

To add a second TCP/IP stack, an additional DATAPATH device must be


added to the TRLE statement and HCD. The DATAPATH address does
not need to be immediate after the write address. It can be any address
in the range of the defined devices of the OSA-Express in the HCD.

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

5.4.3 TCP/IP definitions


TCP/IP requires only the DEVICE and LINK definitions that correspond to the port name in a
VTAM TRLE. Example 5-3 shows the TCP/IP profile definitions of the OSA-Express
1000BASE-T port (OSAE200) for SC63.

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.

84 OSA-Express Implementation Guide


Example 5-3 TCP/IP profile for SC63
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 100

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.

Example 5-4 TCP/IP profile for SC64


DEVICE OSA2D80 MPCIPA
LINK 2D80LNK IPAQENET OSA2D80 VLANID 101

HOME
192.16.1.21 2D80LNK

BEGINROUTES
ROUTE 192.16.1.0/24 = 2D80LNK MTU 1492
ENDROUTES

START OSA2D80

The following definitions are used:


OSAE200 The device name; it must match the port name in the TRLE on SC63
OSA2D80 The device name; it must match the port name in the TRLE on SC64
E200LNK The link name in TCP/IP in system SC63
2D80LNK The link name in TCP/IP in system SC64
192.16.1.11 The IP address that is downloaded to the OSA-Express for SC63
192.16.1.21 The IP address that is downloaded to the OSA-Express for SC64

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.

Chapter 5. QDIO mode 85


5.5 Activation
Under the new QDIO architecture interface on OSA-Express, the CHPID is dynamically reset
as long as none of the devices are used in all of the shared LPARs. This rule does not apply
for the OSAD device.

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

5.5.1 Verifying that devices are online


The z/OS console display command can verify that the required devices are online. See
Example 5-5.

Example 5-5 The z/OS D U command


D U,,,E200,3
IEE457I 21.29.17 UNIT STATUS 836
UNIT TYPE STATUS VOLSER VOLSTATE
E200 OSA O
E201 OSA O
E202 OSA O

If the devices are not online, use the z/OS console vary command:
V (E200-E202),ONLINE

5.5.2 OSA/SF activation


Since QDIO does not require a configuration to be loaded onto the OSA-Express, this task is
not needed to manage configurations. However, it is still a useful diagnostic tool.

5.5.3 VTAM activation


Next, activate the TRL using the following VTAM command:
V NET,ACT,ID=OSAE200

TCP/IP requires an active TRL prior to starting its device.

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.

5.5.4 TCP/IP activation


There are two ways to activate the TCP/IP devices: either restart the TCP/IP stack or use the
TCP/IP Obeyfile command. We chose to restart the stack to implement the changes.

86 OSA-Express Implementation Guide


5.6 Relevant status displays
Example 5-6 and Example 5-7 show the status of the OSA-Express 1000BASE-T devices on
SC63 and SC64. To display the status, you use the TSO NETSTAT DEV command.

Example 5-6 NETSTAT DEVLINKS for SC63


DEVNAME: OSAE200 DEVTYPE: MPCIPA
DEVSTATUS: READY
LNKNAME: E200LNK LNKTYPE: IPAQENET LNKSTATUS: READY
NETNUM: N/A QUESIZE: N/A SPEED: 0000000100
IPBROADCASTCAPABILITY: NO
CFGROUTER: NON ACTROUTER: NON
ARPOFFLOAD: YES ARPOFFLOADINFO: YES
ACTMTU: 1492
VLANID: 200 VLANPRIORITY: DISABLED
READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED
CHECKSUMOFFLOAD: YES
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT
----- ------
224.0.0.1 0000000001

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.

Example 5-7 NETSTAT DEVLINKS for SC64


DEVNAME: OSA2D80 DEVTYPE: MPCIPA
DEVSTATUS: READY
LNKNAME: 2D80LNK LNKTYPE: IPAQENET LNKSTATUS: READY
NETNUM: N/A QUESIZE: N/A SPEED: 0000000100
IPBROADCASTCAPABILITY: NO
CFGROUTER: NON ACTROUTER: NON
ARPOFFLOAD: YES ARPOFFLOADINFO: YES
ACTMTU: 1492
VLANID: 101 VLANPRIORITY: DISABLED
READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED
CHECKSUMOFFLOAD: YES
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT
----- ------
224.0.0.1 0000000001

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).

Chapter 5. QDIO mode 87


Example 5-8 shows the TRLE of the active OSA-Express 1000BASE-T on system SC63.

Example 5-8 D NET,TRL,TRLE=OSAE200


D NET,TRL,TRLE=OSAE200P
IST097I DISPLAY ACCEPTED
IST075I NAME = OSAE200P, TYPE = TRLE 809
IST1954I TRL MAJOR NODE = OSAE200
IST486I STATUS= ACTIV----D, DESIRED STATE= ACTIV
IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES
IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE
IST1716I PORTNAME = OSAE200 LINKNUM = 0 OSA CODE LEVEL = 0616
IST1577I HEADER SIZE = 4096 DATA SIZE = 0 STORAGE = ***NA***
IST1221I WRITE DEV = E201 STATUS = ACTIVE STATE = ONLINE
IST1577I HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA***
IST1221I READ DEV = E200 STATUS = ACTIVE STATE = ONLINE
IST1221I DATA DEV = E202 STATUS = ACTIVE STATE = N/A
IST1724I I/O TRACE = OFF TRACE LENGTH = *NA*
IST1717I ULPID = TCPIPA
IST1815I IQDIO ROUTING DISABLED

Example 5-9 shows the TRLE of the active OSA-Express 1000BASE-T on system SC64.

Example 5-9 D NET,TRL,TRLE=OSA2D80


D NET,TRL,TRLE=OSA2D80P
IST097I DISPLAY ACCEPTED
IST075I NAME = OSA2D80P, TYPE = TRLE 812
IST1954I TRL MAJOR NODE = OSA2D80
IST486I STATUS= ACTIV----D, DESIRED STATE= ACTIV
IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES
IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE
IST1716I PORTNAME = OSA2D80 LINKNUM = 0 OSA CODE LEVEL = 0616
IST1577I HEADER SIZE = 4096 DATA SIZE = 0 STORAGE = ***NA***
IST1221I WRITE DEV = 2D81 STATUS = ACTIVE STATE = ONLINE
IST1577I HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA***
IST1221I READ DEV = 2D80 STATUS = ACTIVE STATE = ONLINE
IST1221I DATA DEV = 2D82 STATUS = ACTIVE STATE = N/A
IST1724I I/O TRACE = OFF TRACE LENGTH = *NA*
IST1717I ULPID = TCPIPA
IST1815I IQDIO ROUTING DISABLED

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

See “VTAM commands” on page 239 for the vary commands.

88 OSA-Express Implementation Guide


5.7 SNA support for QDIO mode
There may be cases where you need to transport Systems Network Architecture (SNA) traffic
over OSA-Express, and you prefer to leverage the benefits of QDIO. IBM provides three
technologies to integrate SNA-based traffic via TCP/IP:
򐂰 Use Enterprise Extender to connect SNA (LU6.2,0,1,2,3) endpoint traffic over TCP/IP
directly into the z/Series. See 1.2.13, “Enterprise Extender” on page 19, for more
information.
򐂰 The TN3270E Server supports TCP/IP host access to SNA applications. Refer to 1.2.14,
“TN3270E Server” on page 19, for details.
򐂰 Layer 2 support allows for non-IP protocols, such as SNA. See 1.2.11, “Layer 2 support”
on page 17, for details.

Chapter 5. QDIO mode 89


90 OSA-Express Implementation Guide
6

Chapter 6. TCP/IP Passthru (non-QDIO


mode)
This chapter describes the process required to configure an Open Systems Adapter-Express
(OSA-Express) port in TCP/IP Passthru non-QDIO mode with only one logical partition
(LPAR) (non-shared mode).

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

"default OAT" (TCP/IP Passthru)


OSA-Express 1000BASE-T

Port 0

Ethernet
Switch

Figure 6-1 TCP/IP in Passthru mode

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.

6.2 HCD requirements


The OSA-Express CHPID, the control unit, and the OSA devices must be defined to HCD and
activated. Refer to Chapter 3, “Hardware configuration definitions” on page 47, for the
procedure to create the definitions. Example 6-1 shows the necessary definitions for the
IOCDS used in this chapter. For future purposes, we use 15 OSA devices, although only two
are needed in our configuration.

92 OSA-Express Implementation Guide


The CHPID in our example is dedicated because it is needed only in partition SC69 (A11).
However, if you plan to use Open Systems Adapter Support Facility (OSA/SF), we
recommend that you share your OSA-Express port among all partitions where OSA/SF is
running. This is why we included the definition for the OSAD (FE) device.

Example 6-1 IOCDS input for CHPID 0C example


ID MSG2='SYS6.IODFCC - 2004-09-17 16:18',SYSTEM=(2084,1), *
TOK=('SCZP901',0080000A6A3A2084161833510104257F00000000,*
00000000,'04-09-17','16:18:33','SYS6','IODFCC')
RESOURCE PARTITION=((CSS(0),(A0A,A),(A0B,B),(A0C,C),(A0D,D),(A0E,E), *
(A0F,F),(A01,1),(A02,2),(A03,3),(A04,4),(A05,5),(A06,6),(A08,8), *
(A09,9)),(CSS(1),(A1A,A),(A1B,B),(A1C,C),(A1D,D),(A1E,E),(A1F,F),*
(A11,1),(A12,2),(A13,3),(A14,4),(A15,5),(A16,6),(A17,7),(A18,8), *
(A19,9))), *
MAXDEV=((CSS(0),64512),(CSS(1),64512))
CHPID PATH=(CSS(0,1),0C),SHARED, *
NOTPART=((CSS(0),(A0D,A0E,A0F),(=)),(CSS(1),(A1C,A1D,A1E,A1F), *
(=))),PCHID=311,TYPE=OSE
CNTLUNIT CUNUMBR=2E40,PATH=((CSS(0),0C),(CSS(1),0C)),UNIT=OSA
IODEVICE ADDRESS=(2E40,015),UNITADD=00,CUNUMBR=(2E40),UNIT=OSA
IODEVICE ADDRESS=2E4F,UNITADD=FE,CUNUMBR=(2E40),UNIT=OSAD

6.3 Displaying the default OAT


Although we do not need to use OSA/SF for the activities in this chapter, we thought it would
be instructive to view the default OAT.

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.

Chapter 6. TCP/IP Passthru (non-QDIO mode) 93


3. In the CHPID View window (Figure 6-2), click Selected →Object settings.

Figure 6-2 CHPID View Object

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).

Figure 6-3 Settings: CHPID 0C

94 OSA-Express Implementation Guide


b. Select the Performance tab. As shown in Figure 6-4, you see all partitions that share
the CHPID.

Figure 6-4 Performance data display

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.

Figure 6-5 Device information

Chapter 6. TCP/IP Passthru (non-QDIO mode) 95


5. Again return to the CHPID View window. This time click Selected →Open OAT
Information.
As shown in Figure 6-6, you see image A11 (SC64) with devices 2E40 and 2E41 online
and the status of SIU (started and in use). This display shows an example of an
OSA-Express CHPID shared with multiple partitions.

Figure 6-6 OAT Information

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.

6.4 Customizing z/OS TCP/IP


Definitions are required in TCP/IP for 1000BASE-T OSA-Express in TCP/IP Passthru mode.
When an external physical device is defined to the TCP/IP stack, it is defined via a set of
DEVICE and LINK statements. For Passthru mode, you can define only one LINK statement
for its related DEVICE statement. Other device types may require more than one LINK
statement to refer to the same DEVICE statement.

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.

96 OSA-Express Implementation Guide


Figure 6-7 shows the network and the connections of our configuration example.

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

Figure 6-7 TCP/IP Passthru mode with non-shared port

6.4.1 TCP/IP definitions


Our OSA-Express port is using CHPID 0C, with port 0 connected to a Ethernet switch. The
z/OS device addresses used for port 0 are 2E40 and 2E41.

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.

Chapter 6. TCP/IP Passthru (non-QDIO mode) 97


򐂰 A HOME IP address (in our example, we used IP address 192.16.1.24 for LPAR SC64)
The HOME statement relates an IP address to the OSA described in the DEVICE and
LINK statement pair.
򐂰 Routes using static routes through the BEGINROUTES statement

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.

Dynamic routing can be accomplished using the OMPROUTE daemon, or the


BSDROUTINGPARMS statement can be used in conjunction with the RouteD daemon.
We do not recommend the use of the BEGINROUTES statement (static routes) with the
OMPROUTE or OROUTED routing daemons.
򐂰 One START statement per OSA device
The START device statement entry uses the DEVICE statement name.

Figure 6-8 shows the TCP/IP profile definitions that we used to define OSA to TCP/IP for
LPAR SC64.

DEVICE OSA2E40 LCS 2E40


LINK 2E40LNK ETHERNET 0 OSA2E40

HOME
192.16.1.24 2E40LNK

BEGINROUTES
ROUTE 192.16.1.0/24 = 2E40LNK MTU 1492
ENDROUTES

START OSA2E40

Figure 6-8 TCP/IP profile definitions

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

98 OSA-Express Implementation Guide


Since the OSA-Express port is used in default mode, little needs to be done in our case. We
need to ensure only that the devices are online and then activate TCP/IP.

6.5.1 Verifying that devices are online


To verify that the required devices are online, enter the z/OS console display command:
D U,,,2E40,2
IEE457I 21.29.17 UNIT STATUS 836
UNIT TYPE STATUS VOLSER VOLSTATE
2E40 OSA O
2E41 OSA O

If the devices are not online, enter the z/OS console vary command:
V (2E40-2E41),ONLINE

6.5.2 Activating TCP/IP


There are three ways to make effective the added definitions to the TCP/IP profile.
򐂰 You can create an obeyfile using the definition statements listed in this chapter.
򐂰 You can restart the TCP/IP stack.
򐂰 You can issue the following z/OS command:
V TCPIP,TCPIP,START,OSAE200

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.

DEVNAME: OSA2E40 DEVTYPE: LCS DEVNUM: 2E40


DEVSTATUS: READY
LNKNAME: 2E40LNK LNKTYPE: ETH LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0
IPBROADCASTCAPABILITY: YES
MACADDRESS: 00096B1A1EF7
ACTMTU: 1500
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT
----- ------
224.0.0.1 0000000001

Figure 6-9 TCP/IP device and link status

For a summary of related commands, refer to Appendix A, “Commands” on page 237.

Chapter 6. TCP/IP Passthru (non-QDIO mode) 99


100 OSA-Express Implementation Guide
7

Chapter 7. Non-QDIO mode (TCP/IP and


SNA)
This chapter discusses customizing an Open Systems Adapter-Express (OSA-Express) port
for both TCP/IP and SNA non-QDIO mode, using Open Systems Adapter Support Facility
(OSA/SF). The OSA-Express port is shared between two logical partitions (LPARs), each
running a TCP/IP stack and a VTAM region.

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

Figure 7-1 TCP/IP non-QDIO mode shared port

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.

The following definitions are required to support this configuration:


򐂰 Hardware definitions
򐂰 OAT definitions
򐂰 TCP/IP definitions
򐂰 VTAM definitions

102 OSA-Express Implementation Guide


7.2 HCD requirements
The OSA-Express CHPID, control unit, and OSA devices must be defined to HCD, and must
be activated. Refer to Chapter 3, “Hardware configuration definitions” on page 47, for the
procedure to create the definitions.

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.

Example 7-1 IOCDS input for CHPID 0C example


ID MSG2='SYS6.IODFCC - 2004-09-17 16:18',SYSTEM=(2084,1), *
TOK=('SCZP901',0080000A6A3A2084161833510104257F00000000,*
00000000,'04-09-17','16:18:33','SYS6','IODFCC')
RESOURCE PARTITION=((CSS(0),(A0A,A),(A0B,B),(A0C,C),(A0D,D),(A0E,E), *
(A0F,F),(A01,1),(A02,2),(A03,3),(A04,4),(A05,5),(A06,6),(A08,8), *
(A09,9)),(CSS(1),(A1A,A),(A1B,B),(A1C,C),(A1D,D),(A1E,E),(A1F,F),*
(A11,1),(A12,2),(A13,3),(A14,4),(A15,5),(A16,6),(A17,7),(A18,8), *
(A19,9))), *
MAXDEV=((CSS(0),64512),(CSS(1),64512))
CHPID PATH=(CSS(0,1),0C),SHARED, *
NOTPART=((CSS(0),(A0D,A0E,A0F),(=)),(CSS(1),(A1C,A1D,A1E,A1F), *
(=))),PCHID=311,TYPE=OSE
CNTLUNIT CUNUMBR=2E40,PATH=((CSS(0),0C),(CSS(1),0C)),UNIT=OSA
IODEVICE ADDRESS=(2E40,015),UNITADD=00,CUNUMBR=(2E40),UNIT=OSA
IODEVICE ADDRESS=2E4F,UNITADD=FE,CUNUMBR=(2E40),UNIT=OSAD

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 103


7.3 Creating and saving the configuration with the OSA/SF GUI
Creating (adding) and saving an OSA-Express port configuration is not disruptive. The only
time a definition can have any effect on the OAT configuration is when the Activate
command is issued. In our case, we implemented the OAT definitions shown in Figure 7-2.

T HOME IP DEVICE
L
C
P P 192.16.1.20 2E40,2E41 LPAR IODEVICE IP Address/SAP Port

A SC63 2E40 192.16.1.20 0


/ OAT SC63 2E4A SAP=4 0
R I
P
SC64 2E40 192.16.1.24 0
V XCA Node DEVICE
S T SC64 2E4A SAP=8 0

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

V XCA Node DEVICE


S T Workstation
C A XCAOSA64 2E4A 192.16.1.110
6 M

4
"FE" DEVICE
OSA/SF 2E4F

Figure 7-2 Connectivity layout

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.

104 OSA-Express Implementation Guide


3. Figure 7-3 shows all the OSA-Express CHPID that were installed on the system used in
these examples. CHPID 0C is highlighted because we work with CHPID 0C throughout
this chapter.
a. Select the OSA-Express CHPID that represents the OSA-Express port that you are
going to place into a TCP/IP mode, SNA mode, or both.
b. From the OSA/SF menu bar, choose Selected →Configurations →Configuration.

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.

Figure 7-3 List of OSA-Express CHPIDs

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.

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 105


Note: You may want to use a locally administered address (LAA) in place of the
universal MAC address when using SNA. Each workstation connecting to the
OSA-Express port through SNA must have the MAC address of the defined
OSA-Express port. 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 also change the MAC address of the OSA-Express feature using OSA
Advanced Facilities in the Hardware Management Console (HMC).

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.

Figure 7-4 Adding a new configuration

106 OSA-Express Implementation Guide


7.3.1 TCP/IP definitions in OSA/SF
To set the TCP/IP definitions in OSA/SF, follow these steps:
1. To proceed to the TCP/IP setup, click Add... (see Figure 7-4), under the TCP/IP section.
2. The TCP/IP Passthru OAT Entry Definition window (Figure 7-5) opens. In Shared Port
mode, more than one LPAR can share an OSA-Express port. The OAT record definition is
used to assign a unit address and IP address to each LPAR/port combination. Fill in the
following fields:
a. For Image number, enter the LP number of the LPAR, or for a System z9 109 (z9-109),
or zSeries 990 or 890 (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 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.

Figure 7-5 TCP/IP configuration for OSE 0C

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 107


3. You see the TCP/IP OAT Settings panel once again as shown in Figure 7-6. Verify the
configuration information.

Figure 7-6 TCP/IP configuration

108 OSA-Express Implementation Guide


7.3.2 SNA definition in OSA/SF
Since our OSA-Express configuration will be defined to operate in both TCP/IP and SNA
modes, we must now define the SNA configuration mode.
1. Starting from the Configuration panel (see Figure 7-6), scroll down until you see the SNA
configuration section as shown in Figure 7-7. Next to the SNA OAT entries box, click the
Add... button to add the SNA address.

Figure 7-7 SNA configuration

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.

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 109


b. Enter the unit address for this port. We used unit address 0A.
The unit address can be any address, but unit addresses 00-03 are usually associated
with TCP/IP Passthru ports.
c. Click Add... to add this definition to the OSA/SF OAT.

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.

Figure 7-8 SNA OAT Entry Definition

3. In the OSA Configuration window, from the menu bar, select File →Save configuration
as shown in Figure 7-9.

Figure 7-9 Saving the configuration

110 OSA-Express Implementation Guide


The Save action takes the configuration information and saves it into a file on the z/OS host.

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.

7.3.3 Activating the OSA-Express configuration


All TCP/IP and SNA mode configuration changes are disruptive. Before you activate the
TCP/IP and SNA mode configurations, you must stop all devices having an active session
through the OSA-Express port. In contrast with previous versions of OSA/SF, the ports may
remain online. To activate the OSA configuration, follow these steps:
1. Cease all active sessions using the OSA-Express port.
2. 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.
3. In the Workstation Interface window, in the right panel under OSA/SF Commands, select
CHPID View.
4. In the CHPID View window, select CHPID 0C. Then, from the menu bar, choose
Selected →Configurations →Configuration.
5. In the window that opens, click File →Open saved configuration.

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 111


6. In the Host Configuration List window (Figure 7-10), select the configuration that you want
to activate. Then click Load to select the configuration action panel.

Figure 7-10 Configurations saved

112 OSA-Express Implementation Guide


7. To activate this configuration, select the Activate →Activate with install as shown in
Figure 7-11 or close the windows.

Figure 7-11 Activating the configuration

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.

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 113


7.3.4 Displaying the MAC address
In SNA mode, any downstream workstation doing a dial-in operation, such as PCOM as a
3270 terminal, needs to know the MAC address of the OSA port. To display this address, you
can use the OSA/SF GUI.
1. From the CHPID View window (Figure 7-3 on page 105), choose Selected →Object
settings.
2. In the Settings window (Figure 7-12), observe the MAC address value at the top of the
mode settings notebook to confirm that it matches the MAC address provided in the
planning section. In our example, we use the Universal Address 00096B1A1EF7, which
appears in the MAC address field.

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.

Figure 7-12 Reviewing the MAC address values

114 OSA-Express Implementation Guide


7.4 Customizing the z/OS network environment
In our environment, TCP/IP and VTAM coexist and share the same OSA-Express port without
affecting each other. This allows the definitions for TCP/IP and VTAM to be done
independently, as though the OSA-Express port was owned by VTAM or TCP/IP exclusively.

Reminder: Port sharing is set up in OSA/SF, not in TCP/IP or VTAM.

7.4.1 VTAM definitions


This section describes the definitions required in VTAM to allow SNA applications to access
the LAN via the OSA-Express port. To describe the VTAM setup, the network configuration
shown in Figure 7-2 on page 104 is used. In this example, both VTAMs in SC63 and SC64
communicate over a Ethernet switch via port 0 (device number 2E4A).

You need to define two types of major nodes in VTAM:


򐂰 XCA major node
򐂰 Switched major node (SWNET)

XCA major node


Define one XCA major node for each SNA OSA device with:
򐂰 The node type (VBUILD definition statement)
򐂰 The port used by the LAN (Port definition statement)
򐂰 The switched peripheral nodes (type 2) attached to an Ethernet LAN through an
OSA-Express port (Group, Line and PU definition statements)

Figure 7-13 shows the VTAM coding to implement this connection.

***********************************************************************
* *
* 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************************

Figure 7-13 XCA major node definition for SC63

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 115


Table 7-1 lists the Port parameters.

Table 7-1 XCA major node Port definition for XCAOSA63


Required Explanation Remarks
parameters

TYPE=XCA XCA major node The OSA functions such as an XCA to VTAM.

ADAPNO=0 PORT statement Code ADAPNO=0 for port 0 of OSA-Express FENET.

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.

Table 7-2 identifies the significant Group parameters.

Table 7-2 XCA major node Group definition for XCAOSA63


Required Explanation Remarks
parameters

DIAL=YES Switched peripheral You must code DIAL=YES to specify that the switched line
node control protocol is required.

AUTOGEN= Autogeneration of This parameter enables VTAM to automatically generate


(3,L,P) LINE and PU three sets of LINE and PU statements. The LINE names
statements begin with L. The PU names begin with P.

Note: The current OSA-Express features support 4096 SNA PU Type 2 connections per
port on System z9 and zSeries servers.

116 OSA-Express Implementation Guide


Figure 7-14 shows the XCA major node (XCAOSA64) definition in VTAM on LPAR SC64 for
the Ethernet connection via port 0 of the OSA-Express.

***********************************************************************
* *
* 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.

Table 7-3 XCA major node Port definition for XCAOSA69


Parameter Explanation Remarks

SAPADDR=08 Service access point Since port 0 is shared with SC63, a different SAP
address address of 8 is used.

Switched major node


Define one switched major node for each switched connection to the peripheral nodes
attached on the LAN. Code the following items:
򐂰 A remote physical unit (PU definition statement)
򐂰 The corresponding logical units (LU definition statements)

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 117


Figure 7-15 shows how 3270 sessions are set up with a switched major node (SWOSA63) for
SC63. It lists the important parameters in the PU definition for SWOSA63.

* THIS SWITCHED MAJNODE DEFINES THE OSA-Express SNA CONNECTION


* TO VTAM RUNNING IN LPAR SC63
*
VBUILD TYPE=SWNET
OSA63P PU ADDR=02, X
IDBLK=05D, X
IDNUM=12863, X
CPNAME=OSANT, X
IRETRY=YES, X
MAXOUT=7, X
MAXPATH=1, X
MAXDATA=1024, X
PACING=0, X
VPACING=0, X
PUTYPE=2, X
DISCNT=(NO), X
ISTATUS=ACTIVE, X
MODETAB=NEWMTAB, X
DLOGMOD=DYNTRN, X
USSTAB=USSLDYN, X
SSCPFM=USSSCS
OSA63L0 LU LOCADDR=0,MODETAB=MTAPPC,DLOGMOD=APPCMODE
OSA63L1 LU LOCADDR=1 3270 SESSIONS
OSA63L2 LU LOCADDR=2

Figure 7-15 Switched major node definition for SWOSA63

Table 7-4 lists the important parameters in the LU definition for SWOSA63.

Table 7-4 Switched major node LU definition for SWOSA63


Parameters Explanation Remarks

LOCADDR=0 LU’s local address at the PU LOCADDR=0 denotes an independent LU.

MODETAB=MTAPPC Logon mode table Code a separate logon mode table for
APPC.

LOCADDR=2 LOCADDR=2 denotes a dependent LU.

7.4.2 TCP/IP definitions


TCP/IP uses the OSA-Express port as an LCS device. Each port has its own unique DEVICE
and LINK statement defined in the TCP/IP profile.

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.

118 OSA-Express Implementation Guide


1. Define one DEVICE statement per OSA-Express port. Use the even device number of the
two device numbers assigned in the hardware to the port.
a. Define two device numbers per OSA-Express port for TCP/IP mode, in HCD, because
TCP/IP is running in full-duplex mode. One device is used by TCP/IP for reading, and
the other device is used for writing.
b. Using the DEVICE statement, define the DEVICE statement name, the DEVICE type
(LCS) for the OSA-Express port, and the DEVICE number (the read number, which is
the even number).
2. Define one LINK statement per OSA TCP/IP DEVICE statement.
Using the LINK statement, define the LINK name, the LINK type, the PORT number, and
the DEVICE statement name.

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.

3. Define the HOME IP address of the OSA-Express port.


4. Using the HOME statement, define an IP address referring to a LINK statement name.
5. Define static routes through the BEGINROUTES statement.

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.

Dynamic routing can be accomplished using the OMPROUTE daemon, or the


BSDROUTINGPARMS statement can be used in conjunction with the RouteD daemon.
We recommend that you do not use the BEGINROUTES statement (static routes) with the
OMPROUTE or OROUTED routing daemons.
6. Define one START command per DEVICE name.
After defining an OSA device in the TCP/IP profile, the device still has to be started
explicitly. The TCP/IP START device statement entry has one per TCP/IP Read device
that is required to be started. It uses the DEVICE statement name.

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 119


Example 7-2 shows the TCP/IP PROFILE definitions needed to define OSA-Express to
TCP/IP for LPAR SC63.

Example 7-2 z/OS TCP/IP PROFILE definitions for LPAR SC63


; TCP/IP SC63 PROFILE.TCPIP --- Hardware definitions
; OSA2E40 is an OSA-Express feature using logical port 0. Devices are
; 2E40-2E41.CHPID 0C.

DEVICE OSA2E40 LCS 2E40


LINK 2E40LNK ETHERNET 0 OSA2E40

HOME
192.16.1.20 2E40LNK

BEGINROUTES
ROUTE 192.16.1.0/24 = OSA2E40LNK MTU 1492
ENDROUTES

;Start the defined device


START OSA2E40

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

7.5.1 Verifying that devices are online


The z/OS console display command can verify that the required devices are online (see
Figure 7-16).

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

Figure 7-16 z/OS D U command

If they are not online, enter the z/OS console vary command:
V (2E40,2E41,2E4A),ONLINE

120 OSA-Express Implementation Guide


7.5.2 VTAM activation
VTAM activation is no different from any other VTAM resource. Use the VTAM VARY
command. On each LPAR, activate the XCA major node and the switched major node.
Typically, the commands are of the following format (for LPAR SC64):
V NET,ID=XCAOSA64,ACT
V NET,ID=SWOSA64,ACT

7.5.3 TCP/IP activation


There are three ways to activate TCP/IP devices:
򐂰 Restart the TCP/IP stack.
򐂰 Use the TCP/IP Obeyfile command.
򐂰 Issue the z/OS command:
/V TCPIP,TCPIP,START,OSA2E40

7.6 Relevant status displays


We monitored the status of the VTAM resources with the VTAM DISPLAY command.
Figure 7-17 displays the XCA major node for the 1000Base-T connection.

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-17 Display of XCA major node

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

Figure 7-18 Display of switched major node

Chapter 7. Non-QDIO mode (TCP/IP and SNA) 121


The NETSTAT DEV command displays the TCP/IP devices. Figure 7-19 shows both the
device and link in the READY state.

DEVNAME: OSA2E40 DEVTYPE: LCS DEVNUM: 2E40


DEVSTATUS: READY
LNKNAME: 2E40LNK LNKTYPE: ETH LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0
IPBROADCASTCAPABILITY: YES
MACADDRESS: 00096B1A1EF7
ACTMTU: 1500
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT
----- ------
224.0.0.1 0000000001

Figure 7-19 Display of TCP/IP device and link

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.

122 OSA-Express Implementation Guide


8

Chapter 8. ATM HPDT native (non-QDIO


mode)
This chapter covers the implementation steps to set up an Open Systems Adapter-Express
(OSA-Express) 155 asynchronous transfer mode (ATM) feature in High Performance Data
Transfer (HPDT) mode. An OSA-Express 155 ATM (native) can run only in HPDT mode
(QDIO is not supported). The ATM HPDT Native mode supports communication for both
TCP/IP and Systems Network Architecture (SNA).

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

OSA-Express ATM OSA-Express ATM

Port 0 Port 0

ATM Switch

Figure 8-1 HPDT MPC ATM native mode

8.2 HCD requirements


The OSA CHPID, the control unit, and the OSA devices must be defined to HCD, and
activated. Refer to Chapter 3, “Hardware configuration definitions” on page 47, for the
procedure to create the definitions. Example 8-1 shows the example definitions for the IOCDS
used in this chapter.

Example 8-1 Example of the IOCDS input for CHPID F6


.
CHPID PATH=(F6),SHARED,PARTITION=((A1,A2),(A1,A2)),TYPE=OSE
.
CNTLUNIT CUNUMBR=0E90,PATH=(F6),UNIT=OSA
.
IODEVICE ADDRESS=(0E90,15),CUNUMBR=(0E90),UNIT=OSA,UNITADD=90
IODEVICE ADDRESS=0E9F,UNITADD=FE,CUNUMBR=(0E90),UNIT=OSAD

124 OSA-Express Implementation Guide


8.3 Creating and saving the configuration with the OSA/SF GUI
Open Systems Adapter Support Facility (OSA/SF) is required to configure the OSA-Express
155 ATM feature. Figure 8-2 shows the configuration for the OSA-Express 155 ATM. It shows
interdependencies, such as the port name in the TRLE must match the device name in the
TCP/IP profile, as well as in the External Communication Adapter (XCA) major node (if SNA
is used). Furthermore, the TRLE name must be the same as the OSA name defined in the
OSA feature.

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

"FE" DEVICE OSAD, UA FE


OSA/SF OE9F

LPAR S30 OSE


TCPIP ATM
VTAM Native Mode

Figure 8-2 Devices in HPDT MPC ATM native mode

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.

Chapter 8. ATM HPDT native (non-QDIO mode) 125


3. In the OSA CHPIDs – Tree View window (Figure 8-3), complete these steps:
a. Select the OSA CHPID that represents an OSA port you are going to be configuring
(CHPID F6, in our case).
b. From the menu bar, choose Selected →Configurations →Configurations list.

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.

Figure 8-3 OSA CHPIDs – Tree View

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.

126 OSA-Express Implementation Guide


Figure 8-4 Configuration panel (physical port)

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.

Figure 8-5 MPC OAT entries

Reminder: If you are using a CHPID dedicated to one partition, the LP number
must be 0.

Chapter 8. ATM HPDT native (non-QDIO mode) 127


ii. Click Add to add the OAT port definition.
c. Now the configuration for MPC mode is complete. You can click Add to provide
additional entries. Figure 8-6 shows the completed OAT entries for MPC mode.

Figure 8-6 MPC ATM native port 0 - Page 1 of 2

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.

128 OSA-Express Implementation Guide


c. Check your ATM switch documentation for the settings of cell rates and protocol data
unit (PDU) sizes. Note the following hints:
• Specify the maximum PDU size for each direction in a PVC. The maximum PDU
size is equal to the size of one frame that can be processed in that direction for the
ATM AAL5 SDU layer.
• For a Best Effort virtual circuit, we recommend that you specify the highest peak cell
rate that is acceptable to both endpoints.
• For SNA data transfer, correlate the maximum PDU size with the maximum RU size
that you specify in the VTAM logmode table. For more information, see z/OS
V1R6.0 Communications Server SNA Resource Definition Reference, SC31-8778.
d. Because we are using Best Effort for bandwidth allocation, we do not need to specify
any of the sustained cell rates and cell burst size.
e. Click Add on the PVC Definition window.

Figure 8-7 PVC Definition window

Chapter 8. ATM HPDT native (non-QDIO mode) 129


Figure 8-8 shows the completed entries for the PVC records.

Figure 8-8 HPDT ATM native port: PVC records

8.3.1 Activating the OSA configuration


To activate the OSA configuration, follow these steps:
1. From the Configuration window (Figure 8-8), select Configuration →Save. This ensures
that the configuration is saved.
2. You see the OSA Support Facility Message (Figure 8-9) window. Click OK.

Figure 8-9 Message to indicate configuration saved successfully

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.

130 OSA-Express Implementation Guide


4. To complete the installation, use these tasks:
a. From the OSA/SF GUI window OSA CHPIDs - Tree View, select the OSA CHPID that
represents an OSA port you are going to install.
b. From the Configuration window (Figure 8-8), select Command →Install.
c. In the window that opens, select Force, and then click OK.

8.4 Customizing the z/OS network environment


This section describes the definitions needed in VTAM and TCP/IP, using Figure 8-2 on
page 125 as a reference. TCP/IP uses VTAM TRL interfaces to run in MPC mode. The TRL is
also shared for SNA traffic, which requires an XCA major node. You must define and activate
a TRL major node before TCP/IP starts its ATM native device, and the XCA major node can
be activated to allow SNA traffic.

8.4.1 VTAM TRL definitions


Example 8-2 shows the VTAM TRL major node definition for LPAR S35.

Example 8-2 TRL major node for S35


TRLATMF6 VBUILD TYPE=TRL
OSEF6 TRLE LNCTL=MPC,
READ=E90,
WRITE=E91,
PORTNAME=PORTF6,
STORAGE=ECSA,
MPCLEVEL=HPDT,
MAXREADS=8,
MAXBFRU=16

Table 8-1 lists and briefly describes the TRL parameters.

Table 8-1 TRL major node Port definition for OSEF6


Required Explanation Remarks
parameters

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.

Chapter 8. ATM HPDT native (non-QDIO mode) 131


8.4.2 TCP/IP definitions
TCP/IP requires device and link definitions that correspond to the TRLE name and the port
name in the VTAM TRLE. The PVC and SVC definitions for the ATM native mode IP traffic
must also correspond to the definition made in the native port configuration in the
OSA-Express ATM feature. Example 8-3 shows the TCP/IP profile definitions for S35.

Example 8-3 TCP/IP profile for S35


; TCPIP.PROFILE.TCPIP
; ===================

ATMLIS LIS2 10.11.0.0 255.255.0.0 ; describes CIP LIS


DEVICE OSEF6 ATM PORTNAME PORTF6 ENABLEIN
;
;for the SVC:
LINK ATMSVCF6 ATM OSEF6 LIS LIS2
ATMARPSV ARPVS1 LIS2 SVC 10.11.1.40
NSAP 39999999999999000099990C030004ACAD54C100
;
;for the PVC:
LINK ATMPVCF6 ATM OSEF6
ATMPVC PVCF6IP ATMPVCF6

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.

Table 8-2 TCP/IP statements in correlation to TRL and OAT


Required Explanation Remarks
parameters

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.

132 OSA-Express Implementation Guide


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.

Table 8-3 describes the required statements for the TCP/IP profile used for ATM native mode
IP traffic.

Table 8-3 TCP/IP statements description


Required Explanation Remarks
parameters

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.

START This starts the related TCP/IP devices.

Chapter 8. ATM HPDT native (non-QDIO mode) 133


8.4.3 VTAM XCA and switched major node definitions
This section discusses the XCA major node and switched major node definitions that we used
in our environment. Example 8-4 shows how we coded our XCA major node.

Example 8-4 VTAM XCA major node for native ATM


XCAATMF6 VBUILD TYPE=XCA
F6APORT PORT MEDIUM=ATM,
PORTNAME=PORTF6
F6AGRP1 GROUP DIAL=NO
F6ALIN1 LINE PVCNAME=PVCF6SNA
F6APU1 PU CPNAME=VTAM30,CPCP=YES,HPR=YES,CONNTYPE=APPN,
PUTYPE=2,TGP=ATMGBD,CAPACITY=49M,NETID=NETA
F6AGRP2 GROUP DIAL=YES,ANSWER=ON,ISTATUS=ACTIVE,CALL=INOUT,DYNPU=YES
F6ALIN2 LINE
F6APU2 PU

Table 8-4 lists the relevant definitions used in the XCA major node.

Table 8-4 XCA major node description


Required Explanation Remarks
parameters

TYPE=XCA XCA major node XCA major node is known to VTAM.

MEDIUM=ATM ATM Interface VTAM SNA interface is for ATM connection.

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

Next we defined the switched major node, as shown in Example 8-5.

Example 8-5 VTAM switched major node


SWATMF6 VBUILD TYPE=SWNET,MAXNO=256,MAXGRP=256
SWF6PU1 PU MAXPATH=5,MAXDATA=256,ADDR=03,MODETAB=WALKTAB,
CPNAME=VTAM30,CPCP=YES,HPR=YES,CONNTYPE=APPN,
PUTYPE=2,TGP=ATMGBA,CAPACITY=49M,NETID=NETA
SWF6PTH1 PATH DLCADDR=(1,C,ATMSVC,EXCLUSIVE),
DLCADDR=(7,BCD,00,01,00353207,00353207),
CALL=INOUT,
DLCADDR=(8,X,00,00,00),
DLCADDR=(21,X,0002,39999999999999000099990C01,
0204357A09B5,60),
GRPNM=F6AGRP2

134 OSA-Express Implementation Guide


Table 8-5 lists the relevant definitions used in switched major node.

Table 8-5 Description of switched major node


Required Explanation Remarks
parameters

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

8.5.1 Verifying that devices are online


The z/OS console display command can verify that the required devices are online:
D U,,,E90e,2
IEE457I 21.29.17 UNIT STATUS 836
UNIT TYPE STATUS VOLSER VOLSTATE
0E90 OSA O
0E91 OSA O

If they are not online, enter the z/OS console vary command:
V (E90,E91),ONLINE

8.5.2 OSA/SF activation


Activation of the configuration loaded on the OSA-Express feature was already accomplished
in 8.3.1, “Activating the OSA configuration” on page 130.

8.5.3 VTAM activation


Next, activate the TRL using the following VTAM command:
V NET,ACT,ID=TRLATMF6

TCP/IP requires an active TRL prior to starting its device.

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.

Chapter 8. ATM HPDT native (non-QDIO mode) 135


8.5.4 TCP/IP activation
There are two ways to activate the TCP/IP devices: either restart the TCP/IP stack or use the
TCP/IP VARY command. We chose to restart the stack to implement the changes. Refer to
Appendix A, “Commands” on page 237, for the command syntax.

8.6 Relevant status displays


The following displays were taken after we established a TCP/IP connection in OSA-Express
native ATM mode. We used the following command:
D TCPIP,TCPIP,NETSTAT,DEV

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.

LNKNAME: ATMPVCF6 LNKTYPE: ATM LNKSTATUS: READY


NETNUM: 0 QUESIZE: 0 BYTEIN: 0000000108 BYTEOUT: 0000000540
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.0.0.0
ATM SPECIFIC:
ATM PORTNAME: PORTF6
ATM PVC NAME: PVCF6IP PVC STATUS: READY

Figure 8-10 NETSTAT DEVLINKS for the native ATM PVC link

Figure 8-11 shows the status of the SVC.

DEVNAME: OSEF6 DEVTYPE: ATM DEVNUM: 0000


DEVSTATUS: READY
LNKNAME: ATMSVCF6 LNKTYPE: ATM LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0 BYTEIN: 0000000000 BYTEOUT: 0000000000
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.0.0.0
ATM SPECIFIC:
ATM PORTNAME: PORTF6
ATM LIS NAME: LIS2
SUBNETVALUE: 10.11.0.0 SUBNETMASK: 255.255.0.0
DEFAULTMTU: 0000009180 INACTVTIMEOUT: 0000000300
MINHOLDTIME: 0000000060 MAXCALLS: 0000001000
CACHENTRYAGE: 0000000900 ATMARPRETRY: 0000000002
ATMARPTIMEOUT: 0000000003 PEAKCELLRATE: 0000000000
NUMOFSVCS: 0000000000
ATMARPSV NAME: ARPVS1
VCTYPE: SVC ATMADDRTYPE: NSAP
ATMADDR: 39999999999999000099990C030004ACAD54C100
IPADDR: 10.11.1.40
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: NO

Figure 8-11 NETSTAT DEVLINKS for the native ATM SVC link

136 OSA-Express Implementation Guide


Next we displayed the status of VTAM TRLE node, as shown in Figure 8-12, by using the
following command:
D NET,TRL,TRLE=OSEF6

NAME = OSEF6, TYPE = TRLE 194


STATUS= ACTIV, DESIRED STATE= ACTIV
TYPE = LEASED , CONTROL = MPC , HPDT = YES
MPCLEVEL = HPDT MPCUSAGE = SHARE
PORTNAME = PORTF6 LINKNUM = N/A OSA CODE LEVEL =
HEADER SIZE = 4096 DATA SIZE = 56 STORAGE = ***NA***
WRITE DEV = 0E91 STATUS = ACTIVE STATE = ONLINE
HEADER SIZE = 4092 DATA SIZE = 60 STORAGE = ECSA
READ DEV = 0E90 STATUS = ACTIVE STATE = ONLINE
END

Figure 8-12 TRLE display of the native ATM connection

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

NAME = XCAATMF6, TYPE = XCA MAJOR NODE 742


STATUS= ACTIV, DESIRED STATE= ACTIV
MEDIUM = ATM, PORT NAME = PORTF6
ATM ADDRESS TYPE FORMAT
39999999999999000099990C010020357CD01930 LOCAL NSAP
I/O TRACE = OFF, BUFFER TRACE = OFF
VTAMTOPO = REPORT, NODE REPORTED - YES
LINES:
F6ALIN1 ACTIV
F6ALIN2 ACTIV
END

Figure 8-13 Display of XCA major node for SNA on the ATM native mode

Chapter 8. ATM HPDT native (non-QDIO mode) 137


We displayed the status of the line, as shown in Figure 8-14, by using the following command:
D NET,ID=F6ALIN1,E

NAME = F6ALIN1, TYPE = LINE 784


STATUS= ACTIV, DESIRED STATE= ACTIV
TYPE = LEASED , CONTROL = SDLC, HPDT = *NA*
PVCNAME = PVCF6SNA
GROUP = F6AGRP1, MAJOR NODE = XCAATMF6
TATE TRACE = OFF
VTAMTOPO = REPORT, NODE REPORTED - YES
F6APU1 TYPE = PU_T2.1 , ACTIV
END

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

NAME = F6APU1, TYPE = PU_T2.1 053


STATUS= ACTIV, DESIRED STATE= ACTIV
CP NAME = VTAM30, CP NETID = NETA, DYNAMIC LU = YES
XNETALS = YES
RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS
F6APU1 AC/R 21 YES 98910000000000000000017100238080
HPR = RTP - OVERRIDE = N/A - CONNECTION = YES
LLERP = NOTPREF - RECEIVED = NOTALLOW
VPCI/VCI = 000021
LINE NAME = F6ALIN1, LINE GROUP = F6AGRP1, MAJNOD = XCAATMF6
I/O TRACE = OFF, BUFFER TRACE = OFF
STATE TRACE = OFF
VTAMTOPO = REPORT, NODE REPORTED - YES
MAJOR NODE VTAMTOPO = REPORT
END

Figure 8-15 Display of active PU for native ATM connection

Then we established a dial connection, as displayed in Figure 8-16, by using the following
command:
V NET,DIAL,ID=SWF6PU1

CONNECTOUT ESTABLISHED FOR PU SWF6PU1 ON LINE F6ALIN2


APPN CONNECTION FOR NETA.VTAM30 IS ACTIVE - TGN = 22
VARY DIAL COMMAND COMPLETE FOR SWF6PU1

Figure 8-16 Display of messages issued during the dial connection

138 OSA-Express Implementation Guide


Finally, we displayed the status of the switched node that was just connected, as shown in
Figure 8-17, by using the following command:
D NET,ID=SWF6PU1,E

NAME = SWF6PU1, TYPE = PU_T2.1 230


STATUS= ACTIV, DESIRED STATE= ACTIV
CP NAME = VTAM30, CP NETID = NETA, DYNAMIC LU = YES
XNETALS = YES
RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS
SWF6PU1 AC/R 22 YES 98910000000000000000017100058080
HPR = RTP - OVERRIDE = N/A - CONNECTION = YES
LLERP = NOTPREF - RECEIVED = NOTALLOW
ATM ADDRESS TYPE FORMAT
39999999999999000099990C010020357CD01930 LOCAL NSAP
39999999999999000099990C010204357A09B560 REMOTE NSAP
VPCI/VCI = 000027
SWITCHED SNA MAJOR NODE = SWATMF6
LINE NAME = F6ALIN2, LINE GROUP = F6AGRP2, MAJNOD = XCAATMF6
TRACE = OFF, BUFFER TRACE = OFF
STATE TRACE = OFF
VTAMTOPO = REPORT, NODE REPORTED - YES
MAJOR NODE VTAMTOPO = REPORT
NO LOGICAL UNITS EXIST
END

Figure 8-17 Display of active switched PU for native the ATM connection

Chapter 8. ATM HPDT native (non-QDIO mode) 139


140 OSA-Express Implementation Guide
9

Chapter 9. ATM LAN emulation (non-QDIO


mode)
This chapter covers the implementation steps needed to set up an Open Systems
Adapter-Express (OSA-Express) 155 asynchronous transfer mode (ATM) feature in LAN
emulation (LANE) non-QDIO mode. An OSA-Express 155 ATM can run in TCP/IP Passthru
mode, Systems Network Architecture (SNA) mode, or in both modes simultaneously.

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

OSA-Express Connectivity definitions:


ATM - ATM
log.Port 0 log.Port 1 - TCP/IP Passthru
LAN
environment Port 0 - SNA

LAN
environment

Figure 9-1 ATM LANE mixed mode (shared port)

9.2 HCD requirements


The OSA CHPID, the control unit, and the OSA devices must be defined to HCD, and
activated. Refer to Chapter 3, “Hardware configuration definitions” on page 47, for the
procedure to create the definitions. Example 9-1 shows the definitions for the IOCDS used in
this chapter.

Example 9-1 IOCDS input for CHPID F6


.
CHPID PATH=(F6),SHARED,PARTITION=((A1,A2),(A1,A2)),TYPE=OSE
.
CNTLUNIT CUNUMBR=0E90,PATH=(F6),UNIT=OSA
.
IODEVICE ADDRESS=(09E0,15),CUNUMBR=(09E0),UNIT=OSA,UNITADD=00
IODEVICE ADDRESS=09EF,UNITADD=FE,CUNUMBR=(09E0),UNIT=OSAD

142 OSA-Express Implementation Guide


Note: If you are implementing Ethernet LANE (ENET LANE) only, the ATM CHPID can be
defined as OSD. If you want to use SNA, token-ring LAN emulation (TR LANE), or both,
define the ATM CHPID as OSE.

9.3 Creating and saving the configuration with OSA/SF GUI


Open Systems Adapter Support Facility (OSA/SF) is required to configure the OSA-Express
155 ATM feature for QDIO and non-QDIO modes. Figure 9-2 shows the configuration that we
used for our ATM LANE environment. We have two logical partitions (LPARs), S30 and S35,
each sharing the OSA-Express 155 ATM feature. The OSA is configured to allow each LPAR
to run in TCP/IP mode, SNA mode, or both.

TCP/IP and/or SNA Mode - shared Port


T

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

Figure 9-2 Devices in ATM LANE mixed mode

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.

Chapter 9. ATM LAN emulation (non-QDIO mode) 143


3. The OSA CHPIDs – Tree View window (Figure 9-3) opens. Complete these steps:
a. Select the OSA CHPID that represents an OSA port that you are going to configure,
which is CHPID F6 in our case.
b. Click Selected →Configurations →Configurations list.

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.

Figure 9-3 OSA CHPIDs Tree View

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.

144 OSA-Express Implementation Guide


Figure 9-4 Configuration panel (physical port)

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

Chapter 9. ATM LAN emulation (non-QDIO mode) 145


f. For Enhanced mode, select No if you want the LAN emulation client (LEC) port to drop
its data direct connections to other LECs if and when it loses its connection with its
LAN emulation server (LES). Otherwise, select Yes if you want this LEC port to keep its
data direct connections.
g. For Best effort peak rate (Mb/sec), check the documentation of the ATM switch to
which this ATM OSA-Express is attached, to ensure that the correct Best Effort peak
rate is used. The IBM-supplied default value is 155.0 Mb/sec, which is the maximum
speed supported by an ATM OSA-Express. Make sure that the peak cell rate is
acceptable to the ATM switch and to the clients on the LAN to which the ATM
OSA-Express is attached.
h. For Group MAC addresses, enter the MAC address of any destination group for which
you want this port to receive frames. If you don’t want to use group MAC addresses,
leave all values set to zeros.
i. For Configure this port for, select the emulation mode for this port as TCP/IP, SNA, or
both.

Figure 9-5 LEC port 0 (implementation values): Page 1 of 5

146 OSA-Express Implementation Guide


8. After you specify all desired entries, click the right arrow in the upper right corner of the
notebook to change to page 2, as shown in Figure 9-6. Check the documentation of the
ATM switch to which this ATM OSA-Express is attached, to ensure that the correct settings
are used.

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.

Figure 9-6 ATM LEC port 0 architected values: Page 2 of 5

Chapter 9. ATM LAN emulation (non-QDIO mode) 147


9. After you specify all desired entries, click the right arrow in the upper right corner of the
notebook to change to page 3. On this page, click the Add button to define TCP/IP
Passthru devices. If your ATM feature works only in SNA mode, you can skip this
configuration panel.
a. In the TCP/IP Passthru OAT Entry Definition window (Figure 9-7), follow these steps:
i. Add the IP addresses that are related to unit addresses, logical partitions, or both. If
you are using a CHPID dedicated to one partition, the LP number must be 0.

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-7 TCP/IP Passthru OAT Entry Definition window

148 OSA-Express Implementation Guide


b. You return to the TCP/IP OAT entries, page 3 of 5, where you can recheck all TCP/IP
OAT entries. For an example, refer to the TCP/IP OAT configuration for the logical port
0 in Figure 9-8.

Figure 9-8 ATM LEC port 0 (TCP/IP OAT entries): Page 3 of 5

Chapter 9. ATM LAN emulation (non-QDIO mode) 149


10.Click the right arrow in the upper right corner of the notebook to change to page 4 (SNA
values), which shows the SNA values for Ethernet or token ring set on page 2. Define the
SNA timer and counter setting as necessary.
Figure 9-9 shows the timer and counter slider and the additional enhanced SNA
availability feature. The enhanced SNA availability feature is available only for token-ring
networks. For more information about the SNA enhanced availability, refer to 1.2.12, “SNA
enhanced availability” on page 18.

Figure 9-9 ATM LEC port 0 SNA values: Page 4 of 5 (set for token ring)

150 OSA-Express Implementation Guide


11.Click the right arrow in the upper right corner of the notebook to go to page 5. Figure 9-10
shows an example of the filled-in SNA OAT for logical port 0.
a. Click Add.
b. In the SNA OAT Entry Definition panel, provide your LPAR and unit address
combination for that port.
After you add all your required entries for the SNA mode, you are now finished with all
required definitions for logical port 0.

Figure 9-10 ATM LEC port 0 SNA OAT entries: Page 5 of 5

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.

Figure 9-11 ATM LEC port 1 TCP/IP OAT entries: Page 3 of 5

Chapter 9. ATM LAN emulation (non-QDIO mode) 151


Keep in mind that the logical port 1 is now configured for token-ring connectivity.

Figure 9-12 ATM LEC port 1 SNA OAT entries: Page 5 of 5

9.3.1 Activating the OSA configuration


To activate the OSA configuration, follow these steps:
1. From the Configuration window (Figure 9-12), select Configuration →Save. This ensures
that the configuration is saved.
2. You see the OSA Support Facility Message (Figure 9-13) window. Click OK.

Figure 9-13 Message to indicate configuration saved successfully

3. Select Configurations →Activate or Activate (no install).


Activate downloads the configuration settings and makes the configuration usable
immediately. (Keep in mind that this is a disruptive function.) To be sure that the function is
successful, you must deallocate all devices at the CHPID level from applications in all
partitions (except the OSAD device).
Activate (no install) prevents disrupting an OSA that is already running with a different
configuration. You can defer the installation to a more appropriate time.
4. To complete the installation, complete these tasks:
a. From the OSA/SF GUI window OSA CHPIDs - Tree View, select the OSA CHPID that
represents an OSA port you are going to install.
b. Select Command →Install.
c. In the next window, select Force, and then click OK.

152 OSA-Express Implementation Guide


9.4 Customizing the z/OS network environment
In this mixed mode and shared port environment, TCP/IP and VTAM coexist and share the
same logical OSA ports without affecting each other. This allows the definitions for TCP/IP
and VTAM to be done independently, as though the OSA-Express 155 ATM logical ports were
owned by VTAM or TCP/IP exclusively. Port sharing is not set up in TCP/IP or VTAM, but
rather in OSA/SF.

9.4.1 Customizing VTAM


This section describes the definitions required in VTAM to allow SNA applications to access
the LAN connected to the host via an OSA-Express feature. To describe the VTAM setup, the
network configuration shown in Figure 9-2 on page 143 is used.

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

XCA major node


Define one XCA major node for each SNA OSA device for the following characteristics:
򐂰 The node type (VBUILD definition statement)
򐂰 The port used by the LAN (port definition statement)
򐂰 The switched peripheral nodes (type 2) attached to a token-ring or an Ethernet LAN
through an OSA port (GROUP, LINE, and PU definition statements)

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.

Example 9-2 XCA definition port 0 for system S30


**********************************************************************
* *
* XCA MAJNODE for ATM LANE OSA EXPRESS Log.PORT 0 on System S30 *
* *
**********************************************************************
XCAES30 VBUILD TYPE=XCA
OSE9EAPE PORT MEDIUM=CSMACD, X
ADAPNO=0, X
CUADDR=9EA, X
TIMER=60, X
SAPADDR=04
**********************************************************************
* *
**********************************************************************
OSE9EAGE GROUP DIAL=YES, X
DYNPU=YES, X
ANSWER=ON, X
AUTOGEN=(3,L,P), X

Chapter 9. ATM LAN emulation (non-QDIO mode) 153


CALL=INOUT, X
ISTATUS=ACTIVE
******************************** Bottom of Data ***********************

Example 9-3 XCA definition port 1 for system S30


**********************************************************************
* *
* XCA MAJNODE for ATM LANE OSA EXPRESS Log.PORT 1 on System S30 *
* *
**********************************************************************
XCAES30 VBUILD TYPE=XCA
OSE9EAPE PORT MEDIUM=RING, X
ADAPNO=1, X
CUADDR=9EB, X
TIMER=60, X
SAPADDR=04
**********************************************************************
* *
**********************************************************************
OSE9EAGE GROUP DIAL=YES, X
DYNPU=YES, X
ANSWER=ON, X
AUTOGEN=(3,L,P), X
CALL=INOUT, X
ISTATUS=ACTIVE
******************************** Bottom of Data ***********************

Table 9-1 provides a brief overview of the Port parameters.

Table 9-1 XCA major node Port definition for XCAES30


Required Explanation Remarks
parameters

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.

154 OSA-Express Implementation Guide


Table 9-2 provides a brief overview of the significant Group parameters.

Table 9-2 XCA major node Group definition for XCAES30


Required Explanation Remarks
parameters

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.

Example 9-4 XCA definition port 0 for system S35


**********************************************************************
* *
* XCA MAJNODE for ATM LANE OSA EXPRESS Log.PORT 0 on System S35 *
* *
**********************************************************************
XCAES35 VBUILD TYPE=XCA
OSE9EAPE PORT MEDIUM=CSMACD, X
ADAPNO=0, X
CUADDR=9EA, X
TIMER=60, X
SAPADDR=08
**********************************************************************
* *
**********************************************************************
OSE9EAGE GROUP DIAL=YES, X
DYNPU=YES, X
ANSWER=ON, X
AUTOGEN=(3,L,P), X
CALL=INOUT, X
ISTATUS=INACTIVE
******************************** Bottom of Data ***********************

Example 9-5 XCA definition port 1 for system S35


**********************************************************************
* *
* XCA MAJNODE for ATM LANE OSA EXPRESS Log.PORT 1 on System S35 *
* *
**********************************************************************
XCAES35 VBUILD TYPE=XCA
OSE9EAPE PORT MEDIUM=RING, X
ADAPNO=1, X
CUADDR=9EB, X
TIMER=60, X
SAPADDR=08
**********************************************************************
* *
**********************************************************************
OSE9EAGE GROUP DIAL=YES, X

Chapter 9. ATM LAN emulation (non-QDIO mode) 155


DYNPU=YES, X
ANSWER=ON, X
AUTOGEN=(3,L,P), X
CALL=INOUT, X
ISTATUS=INACTIVE
******************************** Bottom of Data ***********************

Table 9-3 shows the only parameter that is different between system S30 and S35.

Table 9-3 XCA major node Port definition for XCAES35


Parameters Explanation Remarks

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.

Switched major node


Define one switched major node for the switched connections to the peripheral nodes
attached to each LAN. You need to code the following:
򐂰 A remote physical unit (PU definition statement)
򐂰 The corresponding logical units (LU definition statement)

Example 9-6 shows how 3270 sessions can be set up with a switched major node
(SWNS301) for S30.

Example 9-6 Switched major node for S30


* THIS SWITCHED MAJNODE DEFINES THE OSA-EXPRESS SNA CONNECTION
* TO VTAM RUNNING IN LPAR S30
*
SWNS301 VBUILD TYPE=SWNET
OSAS301 PU ADDR=02, X
IDBLK=05D, X
IDNUM=12863, X
CPNAME=OSANT1 X
IRETRY=YES, X
MAXOUT=7, X
MAXPATH=1, X
MAXDATA=1024, X
PACING=0, X
VPACING=0, X
PUTYPE=2, X
DISCNT=(NO), X
ISTATUS=ACTIVE, X
MODETAB=NEWMTAB, X
DLOGMOD=DYNTRN, X
USSTAB=USSLDYN, X
SSCPFM=USSSCS
OSA30L0 LU LOCADDR=0,MODETAB=MTAPPC,DLOGMOD=APPCMODE
OSA30L1 LU LOCADDR=1 3270 SESSION
OSA30L2 LU LOCADDR=2 3270 SESSION

156 OSA-Express Implementation Guide


Table 9-4 presents the important parameters in the PU definition for SWNS301.

Table 9-4 Switched major node PU definition


Parameters Explanation Remarks

TYPE=SWNET Switched major


node

ADDR=02 PU’s SDLC OSAS301 is the PU name. ADDR is a required parameter.


station address

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.

Table 9-5 Switched major node LU definition


Parameters Explanation Remarks

LOCADDR=0 LU’s local address at the PU LOCADDR=0 denotes an independent LU.

MODETAB=MTAPPC Logon mode table Code a separate logon mode table for
APPC.

LOCADDR=2 LOCADDR=2 denotes a dependent LU.

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.

9.4.2 TCP/IP definitions


TCP/IP uses the OSA ports as LAN Channel Station (LCS) devices. For OSA, you define only
one LINK statement for the associated DEVICE statement. Other products may define and
associate more than one LINK statement to refer to the same device statement. For OSA,
each port has its own unique DEVICE and LINK statement defined in the TCP/IP profile.

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.

Chapter 9. ATM LAN emulation (non-QDIO mode) 157


In each partition, you must:
1. Define one DEVICE statement per OSA port. Use the even device number of the two
device numbers assigned in the hardware to the port.
a. Define two device numbers per OSA port for TCP/IP mode in HCD since TCP/IP runs
in full duplex mode. One device is used by TCP/IP for reading, and the other is used for
writing.
b. Using the DEVICE statement, define the DEVICE statement name, the DEVICE type
(LCS) for the OSA port, and the DEVICE number (the read device number, which is the
even device number).
2. Define one LINK statement per OSA TCP/IP DEVICE statement.
Using the LINK statement, you define the LINK name, the LINK type, the PORT number,
and the DEVICE statement name.

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.

3. Define the HOME IP address of the OSA port.


Using the HOME statement, define an IP address referring to a LINK statement name that
itself refers to a DEVICE statement name.
4. Define static routes through the BEGINROUTES statement.

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.

Dynamic routing can be accomplished using the OMPROUTE daemon or the


BSDROUTINGPARMS statement can be used in conjunction with RouteD daemon. We
recommend that you do not use the BEGINROUTES statement (static routes) with the
OMPROUTE or OROUTED routing daemons.
5. Define one START command per OSA DEVICE.
After you define an OSA device in the TCP/IP profile, the device must be started explicitly.
It uses the DEVICE statement name.

Example 9-7 shows the TCP/IP PROFILE definitions needed to define OSA to TCP/IP for
LPAR S30.

158 OSA-Express Implementation Guide


Example 9-7 TCP/IP profile definitions for LPAR S30
; TCP/IP S30 PROFILE.TCPIP --- Hardware definitions
; OSA9E0 is an OSA-Express feature using logical port 0. Devices are
; 9E0-9E1.
; OSA9E2 is an OSA-Express feature using logical port 1. Devices are
; 9E0-9E1.
DEVICE OSA9E0 LCS 9E0
DEVICE OSA9E2 LCS 9E2

LINK OSAL9E0 ETHEROR802.3 0 OSA9E0


LINK OSAL9E2 IBMTR 1 OSA9E2

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

;Start all the defined devices.


START OSA9E0
START OSA9E2

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.

Example 9-8 TCP/IP Profile HOME Statement for S35


HOME
10.11.41.220 OSAL9E0
10.11.42.220 OSAL9E0

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

Chapter 9. ATM LAN emulation (non-QDIO mode) 159


9.5.1 Verifying that the devices are online
The z/OS console display command can verify that the required devices are online as shown
in Figure 9-14. If they are not online, use the z/OS console vary command.
V (9E0-9E3,9EA,9EB),ONLINE

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

Figure 9-14 Results of the z/OS console display command

9.5.2 OSA/SF activation


If the configuration is not activated yet, follow the next procedure. Otherwise, skip the
OSA-Express activation.
1. As shown in Figure 9-15, choose Selected →Configuration →Configuration List.

Figure 9-15 Selecting a configuration

2. From the list of configurations, highlight your saved configuration and click Change. This
retrieves the OSA configuration.

160 OSA-Express Implementation Guide


3. Select Configurations and then choose either Activate or Activate (no install).
The difference between the two choices is the timing for the activation. If there are no
active sessions using this OSA-Express, the Activate command loads the new
configuration to the OSA-Express feature and recycle the hardware connections. This
process can take up to three minutes.
If you select Activate (no install), the new configuration is loaded to the OSA-Express
feature, but is not operational. When you use the no install option, you must return to the
tree view window and select Commands →Install.

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.

9.5.3 VTAM activation


The VTAM configuration is no different from any other VTAM device. Use the VTAM VARY
command. On each LPAR, activate the XCA major node and the switched major node.
Typically, the commands are of the following format (for LPAR S30):
V NET,ID=XCAES30,ACT
V NET,ID=XCATS30,ACT
V NET,ID=SWNS301,ACT

9.5.4 TCP/IP activation


There are two ways to activate the TCP/IP devices. Either restart the TCP/IP stack or use the
TCP/IP VARY command. We chose to restart the stack to implement the changes. Refer to
Appendix A, “Commands” on page 237, for the syntax of the command.

9.6 Relevant status displays


We monitored the status of the VTAM resources using the VTAM Display command.
Figure 9-16 displays the XCA major node for the Ethernet connection (port 0).

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

Figure 9-16 XCA major node logical port 0 display

Chapter 9. ATM LAN emulation (non-QDIO mode) 161


Figure 9-17 shows the results from the XCA major node for logical port 1 used for the
token-ring connection.

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

Figure 9-17 XCA major node logical port 1 display

Figure 9-18 shows the switched major node display.

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

Figure 9-18 Switched major node display

The displays of the major nodes on system S35 gave us equivalent results.

162 OSA-Express Implementation Guide


TCP/IP displays
The TSO NETSTAT DEV command displays the TCP/IP devices. Figure 9-19 shows both the
device and link in the READY state. To verify that a connection existed, we performed a ping
from both TCP/IP stacks to the workstation.

DEVNAME: OSA9E0 DEVTYPE: LCS DEVNUM: 9E0


DEVSTATUS: READY
LNKNAME: OSAL9E0 LNKTYPE: ETHOR LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0
BYTESIN: 0000206398 BYTESOUT: 0000001596
BROADCASTCAPABILITY: YES
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT
----- ------
224.0.0.1 0000000001
DEVNAME: OSA9E2 DEVTYPE: LCS DEVNUM: 9E2
DEVSTATUS: READY
LNKNAME: OSAL9E2 LNKTYPE: TR LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0
BYTESIN: 0789352831 BYTESOUT: 0324162550
ARPMACADDRESS: NON-CANONICAL SRBRIDGINGCAPABILITY: YES
BROADCASTCAPABILITY: YES BROADCASTTYPE: ALL RINGS
BSD ROUTING PARAMETERS:
MTU SIZE: 00000 METRIC: 00
DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES
GROUP REFCNT
----- ------
224.0.0.1 0000000001

Figure 9-19 Display of the TCP/IP device and link

For a summary of useful commands, refer to Appendix A, “Commands” on page 237.

Chapter 9. ATM LAN emulation (non-QDIO mode) 163


164 OSA-Express Implementation Guide
10

Chapter 10. Enterprise Extender


This chapter introduces and discusses Enterprise Extender (EE) technology. It explains the
concept and provides a sample implementation of the Open Systems Adapter-Express
(OSA-Express) in QDIO mode using EE.

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

Figure 10-1 Enterprise Extender example

10.2 What is Enterprise Extender


The Enterprise Extender architecture carries the SNA (HPR) traffic of any logical unit (LU)
type over an IP infrastructure, without requiring changes to that infrastructure. It treats the IP
network as a particular type of SNA logical connection, in much the same way as an
asynchronous transfer mode (ATM) or frame relay network is treated. In this manner, these
SNA protocols act as transport protocols on top of IP, as does any other transport protocol
such as Transmission Control Protocol (TCP).

10.2.1 Why Enterprise Extender is strategic


Enterprise Extender combines features of SNA and IP, to offer the best of both worlds when
running SNA traffic over an IP backbone. Because of its design, Enterprise Extender is
extremely flexible. It can be used in all networks, from the smallest to the largest. It also
provides you with a choice of where the SNA/IP boundary is placed.

166 OSA-Express Implementation Guide


10.2.2 Cost effectiveness and resource convergence
The use of Enterprise Extender allows you to avoid costly application rewrites by providing a
means of IP-enabling SNA applications that cannot be migrated to IP using technologies such
as TN3270. That is, EE allows the continued use of native SNA applications over a different
network, the IP network. This allows you to eliminate the SNA infrastructure altogether. The
ultimate result is the convergence to a single network infrastructure that carries both IP and
SNA application data.

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.

10.2.3 Flow and congestion control


TCP/IP and HPR both provide their own unique, network-specific mechanisms for flow and
congestion control. TCP uses a window technique, where HPR uses a technique based on
data rate. Enterprise Extender introduced a new variant of the HPR flow control method
known as Responsive Mode adaptive rate-based (ARB) flow control. Responsive mode ARB,
like basic mode ARB, is designed to prevent network congestion. However, unlike basic mode
ARB, it can also ensure a fair division of network capacity between the four SNA priorities and
native IP traffic.

10.2.4 Class of service


One of the biggest issues facing those who want to transport SNA over an IP network is the
question of maintaining SNA’s class of service. In SNA, the class of service specified for a
particular session is used to determine both the route taken by the session and the
transmission priority allotted to it.

With an IP backbone, the route is essentially unpredictable because of IP’s connectionless


property. However, IP provides for a transmission priority using the precedence bits in the IP
header. Many routers now support the use of these bits. However, in the past, they tended to
use the TCP or UDP port number as a means of assigning priorities to packets.

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.

10.2.5 Internet connectivity exploitation


Enterprise Extender enables remote branches or workstations to be connected to the SNA
backbone using the Internet, with no application changes required, while maintaining SNA
connectivity from end to end. Dependent LU sessions can be carried on an Enterprise
Extender connection as easily as any others, by using the dependent LU requester function.

Chapter 10. Enterprise Extender 167


10.2.6 Session availability
TCP/IP has always had the ability to reroute packets around failing components, without
disrupting the connection, by means of the connectionless property of IP. More recently SNA
has implemented the same function, although in a different fashion. The HPR extension to
SNA is connection-oriented, which has always been a characteristic of SNA. However, when
it detects a failure, it moves an existing connection around a failing component. The use of
HPR transport over an IP network provides nondisruptive rerouting around failed network
components using either IP or HPR methods, depending on the location of the failure.
HPR consists of the following layers:
򐂰 Automatic Network Routing (ANR): A connectionless layer that enables rerouting
around failures
򐂰 Rapid Transport Protocol (RTP): A reliable connection-oriented layer that provides the
end-to-end functionality

10.3 What you need to understand about Enterprise Extender


This section describes the mechanism used to carry SNA traffic over an IP network. It
includes a discussion about some of the interesting topics that arise when doing so, including
the maintenance of class of service, as well as TCP-friendly congestion and flow control.

10.3.1 Transporting SNA over IP


The designers of Enterprise Extender had the task of architecting the way in which SNA and
IP-based protocols would be layered to transport SNA data over the IP network. They
essentially had three choices of encapsulation of SNA data units: raw IP datagrams, UDP
packets, or a TCP connection. Let’s take a closer look at each choice in more detail:
򐂰 Raw IP datagrams
Datagrams are completely compatible with the HPR principles, because they flow through
the network with minimal overhead and provide no error recovery of any sort. However,
raw IP provides no means of multiplexing, particularly with no Internet Engineering Task
Force (IETF)-designated protocol value for HPR. Using a non-designated protocol value
can lead to inconsistencies with security measures that filter IP packets based on this
value. Additionally, although raw IP allows priority and type of service to be specified, in
practice not all networks or routers are, or can be, configured to support this.
򐂰 UDP packets
These packets provide the multiplexing required because they contain UDP port numbers.
This allows Enterprise Extender packets to be distinguished from other IP packets. It also
permits a priority scheme to be implemented independent of the type of service bits, since
many routers can prioritize traffic based on the received port number. In addition, UDP has
low overhead since it does not concern itself with error recovery or flow control.
򐂰 TCP connection
A TCP connection also provides multiplexing by means of port numbers, but it incurs a
significantly higher overhead than raw IP or UDP. A TCP connection handles error
recovery, retransmission, and flow control. None of these is required for an HPR
connection because the RTP endpoints are responsible for all of them.

168 OSA-Express Implementation Guide


Therefore UDP was the method chosen for Enterprise Extender, as illustrated in Figure 10-2.
It shows how SNA data is transported over the IP cloud in UDP frames.

SNA IP SNA

RTP

ANR
ANR ANR
EE (UDP/IP)

Figure 10-2 SNA transport over IP

10.3.2 Flow and congestion control (enhanced)


The original ARB algorithm introduced with HPR works well with SNA traffic alone, but is less
efficient in the Enterprise Extender environment when SNA and IP traffic must coexist. Upon
detection of a lost packet (a common occurrence in IP networks), the original ARB would
immediately reduce its sending rate by a significant amount, impacting performance.

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.

Responsive Mode ARB provides the following features:


򐂰 It competes fairly with TCP congestion control.
򐂰 It can tolerate a certain level of lost data without significant degradation.
򐂰 It gives priority to short transmissions.
򐂰 It allocates a fair bandwidth to sustained transmissions, independent of propagation
delays.
򐂰 It can ramp up its transmission rate faster at startup.

Chapter 10. Enterprise Extender 169


10.4 Enterprise Extender implementation
The following products implement Enterprise Extender:
򐂰 IBM Communications Server for z/OS
򐂰 IBM Communications Server for Windows
򐂰 IBM Communications Server for Linux
򐂰 IBM Communications Server for AIX®
򐂰 Cisco routers with SNA Switching Services (SNASw)
򐂰 IBM Personal Communications for Windows.

Restriction: VTAM for z/VM does not support Enterprise Extender.

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).

The Enterprise Extender connections themselves are defined to VTAM as switched


connections. The TCP/IP stack also needs a definition for the port represented by the VTAM
application, and this is done by using a same-host (IUTSAMEH) statement. This definition
must be active before VTAM can establish any Enterprise Extender connections.

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.

170 OSA-Express Implementation Guide


10.5 Configuration example for Enterprise Extender
Figure 10-3 shows the network configuration that we use to define EE via OSA-Express and
z/OS. We enable EE between two NNs SC64 and SC65 to allow LU6.2 sessions for
applications residing on the NNs. Using IBM Personal Communications for Windows, we also
define EE in an EN workstation for LU2 sessions with applications residing on SC64 and
SC65.

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

Figure 10-3 Network configuration

Using the OSA-Express for EE


We configure two OSA-Express ports operating in QDIO mode, to exploit the advantages
provided for EE. Chapter 5, “QDIO mode” on page 79, describes the configuration of
OSA-Express to support QDIO mode.

Note: Remember that an active TCP/IP connection, such as an OSA-Express port, is


required for EE implementation.

10.6 Defining Enterprise Extender to z/OS


This section describes the definitions required for TCP/IP and VTAM to allow access to SNA
applications through an OSA-Express port. For more information about these definitions and
other setup options, refer to SNA Network Implementation Guide, SC31-8777.

Chapter 10. Enterprise Extender 171


10.6.1 TCP/IP definitions
Three types of LINK/DEVICE statements are required in the TCP/IP profile:
򐂰 VIRTUAL for the VIPA
򐂰 MPCIPA/IPAQENET for the OSA-Express port operating in QDIO mode
򐂰 MPCPTP for IUTSAMEH

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.

Example 10-1 TCP/IP profile definitions for SC64


;TCP/IP SC64 PROFILE. TCPIP
IPCONFIG
DATAGRAMFWD

;OSA E200 1000BASE-T in QDIO to EE


DEVICE OSAE200 MPCIPA PRIRouter
LINK E200LNK IPAQENET OSAE200

;VIPA Definitions
DEVICE VIPA1 VIRTUAL 0
LINK VLINK1 VIRTUAL 0 VIPA1

;For Enterprise Extender


DEVICE IUTSAMEH MPCPTP
LINK EELINK MPCPTP IUTSAMEH

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.

172 OSA-Express Implementation Guide


10.6.2 VTAM definitions
In VTAM, two types of major nodes and modifications to the start options are required:
򐂰 External communication adapter (XCA) major node
򐂰 Switched major node
򐂰 ATCSRTxx member

External Communication Adapter


We define one XCA major node in each VTAM (SC64 and SC65) for the NN-to-NN and the
EN-to-NN connections. The XCA major node defines the IP port with these statements:
򐂰 PORT: This identifies the name of a port through which an HPR connection is made via
the IP network. The PORT statement must be set as MEDIUM=HPRIP for EE.
򐂰 GROUP: This must be set as DIAL=YES to define a TG. The group name (EEGROUP) is
defined in the PATH statement of the switched major node for the NN-to-NN EE
connection only.

Note: Define at least as many lines as the maximum concurrent connections expect.

Example 10-2 shows the XCA definitions for SC64.

Example 10-2 XCA definitions of XCAEE64


XCAEE64 VBUILD TYPE= XCA
EEPORT PORT MEDIUM=HPRIP,
LIVTIME=10,
IPTOS=(20,40,80,C0),
SAPADDR=4,
SRQRETRY=3,
SRQTIME=15
EEGROUP GROUP DIAL=YES,
DYNPUPFX=BR,
AUTOGEN=(10,L,P),
CALL=INOUT

We use the same definitions on SC65 (XCAEE65).

Switched major nodes for the NN-to-NN connection


A switched major node is used to define the PU and PATH statements to establish the EE
connection:
򐂰 PU: This defines the remote node (physical unit).
򐂰 PATH: This defines the remote IP address, or host name, and the group name specified in
the XCA major node.

Chapter 10. Enterprise Extender 173


Example 10-3 shows the switched major node that we use for SC64 (acting as an NN) that
was activated on SC65.

Example 10-3 Switched major node for SC64 (NN)


SWTO64 VBUILD TYPE=SWNET,
MAXGRP=4,
MAXNO=512
PUTO64 PU MAXDATA=256,ADDR=01,
CPNAME=SC64M,
CPCP=YES,HPR=YES,
DWACT=YES,PUTYPE=2
PATH64 PATH SAPADDR=08,IPADDR=192.16.1.20,
GRPNM=EEGROUP

Example 10-4 shows the switched major node that we use for SC65 (acting as an NN) that
was activated on SC64.

Example 10-4 Switched major node for SC65 (NN)


SWTO65 VBUILD TYPE=SWNET,
MAXGRP=4,
MAXNO=512
PUTO65 PU MAXDATA=256,ADDR=01,
CPNAME=SC65M,
CPCP=YES,HPR=YES,
DWACT=YES,PUTYPE=2
PATH65 PATH SAPADDR=8,IPADDR=192.16.1.30,
GRPNM=EEGROUP

Switched major node for the EN-to-NN connection


We also connect an EN workstation to SC64 (NN), using Dependent LU Request (DLUR),
through EE. In the EN, using IBM Personal Communications (PCOM), we define two LUs to
emulate 3270 sessions.

Example 10-5 shows the switched major node that we use for our EN workstation.

Example 10-5 Switched major node for PUDLUR1 (EN)


SWNDLUR VBUILD TYPE=SWNET,
MAXGRP=4,
MAXNO=512
PUDLUR1 PU ADDR=01,
IDBLK=05D,
IDNUM=11111,
ISTATUS=ACTIVE,
DISCNT=NO,
MAXDATA=265,
MAXOUT=7,
PACING=0,
PUTYPE=2,MODETAB=NEWMTAB,
VPACING=0
LUEE0001 LU LOCADDR=2,DLOGMOD=D4A32782,
LOGAPPL=SC64TS
LUEE0002 LU LOCADDR=3,DLOGMOD=D4A32782,
LOGAPPL=SC64TS

We specify the LOGAPPL=SC64TS to automatically connect the EN LUs to TSO on SC64.

174 OSA-Express Implementation Guide


Note: In Example 10-5, the parameters highlighted in bold must match with the
configuration in IBM Personal Communications. These parameters are not required to
establish connectivity. However, we choose to use them to control which PUs and LUs can
establish sessions through SC64. In a sense, this is a low-level security configuration.

VTAM start options


We alter the VTAM start options in the ATCSTRxx member to support EE and NN. We modify
the NODETYPE, TCPNAME, and IPADDR parameters. The VTAM options coded to
implement this connection are shown in Example 10-6.

Example 10-6 VTAM options for ATCSTR64


CONFIG=64,
SSCPID=64,
NOPROMPT,
SSCPNAME=SC64M,
NETID=USIBMSC,
XCFINIT=YES, XCF LINK
IQDCHPID=ED, XCF LINK CHPID FOR HIPERSOCKETS
HOSTSA=64, INTERCHANGE NODE
MAXSUBA=255,
NODETYPE=NN, NETWORK NODE NN FOR EE
SORDER=SUBAREA,
APPNCOS=#INTER, DEFAULT APPN COS
CONNTYPE=APPN,
CPCP=YES,
CDSERVR=YES, CENTRAL DIRECTORY SERVER
IPADDR=192.16.1.20, VIPA ADDRESS FOR EE ENTERPRISE EXT
IOPURGE=180,
TCPNAME=TCPIPD, TCPIP JOB NAME FOR EE ENT.EXT
SUPP=NOSUP,
HOSTPU=SC64MPU,
PPOLOG=YES,
DYNLU=YES,

The relevant definitions are:


򐂰 NODETYPE=NN: The NODETYPE option must be coded as NN if this VTAM is to act as a
Network Node Server (NNS) or a Dependent LU Server (DLUS) for other nodes. An
Enterprise Extender connection with dependent LU sessions works equally well to a
VTAM End Node that does not have to act as an NNS or DLUS.
򐂰 IPADDR: The IPADDR option is used to define the IP address of the local VIPA (in the
TCP/IP profile).
򐂰 TCPNAME: The TCPNAME option defines the job name of TCP/IP stack to be used.

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

Chapter 10. Enterprise Extender 175


10.6.3 Activation and verification (NN-to-NN)
After all the definitions are added to VTAM and TCPIP, we activate the configuration.
Activation requires several tasks, in this order:
1. Verifying that the OSA-Express devices are online
2. Activating the VTAM resources: TRLE (for OSA-Express), ATCSTR, XCA, and switched
major nodes
3. Starting the TCP/IP devices

Verify EE is running on z/OS


After activation, we verify that EE is running by entering the following commands:
D TCPIP,TCPIPx,NETSTAT,DEV

D NET,ID=XCAEE

D NET,ID=SWTO65 (to verify the NN-to-NN connection)

D NET,ID=PUTO65,E

Example 10-7 shows the status of VIPA1 and IUTSAMEH DEVICEs used for Enterprise
Extender.

Example 10-7 D TCPIP,TCPIPD,NETSAT,DEV


D TCPIP,TCPIPD,NETSTAT,DEV
DEVNAME: VIPA1 DEVTYPE: VIPA
DEVSTATUS: READY
LNKNAME: VLINK1 LNKTYPE: VIPA LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0

DEVNAME: IUTSAMEH DEVTYPE: MPC


DEVSTATUS: READY
LNKNAME: EELINK LNKTYPE: MPC LNKSTATUS: READY
NETNUM: 0 QUESIZE: 0

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-8 D NET,ID=XCAEE,E


D NET,ID=XCAEE64,E
IST097I DISPLAY ACCEPTED
IST075I NAME = XCAEE64, TYPE = XCA MAJOR NODE 222
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1679I MEDIUM = HPRIP
IST1685I TCP/IP JOB NAME = TCPIPD
IST1680I LOCAL IP ADDRESS 192.16.1.20 (VIPA1)
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST170I LINES:
IST232I L0000000 ACTIV
IST232I L0000001 ACTIV
IST232I L0000002 ACTIV
IST232I L0000003 ACTIV
IST314I END

176 OSA-Express Implementation Guide


We also look for an active state:
򐂰 HPRIP: Medium=HPRIP (as opposed to CSMACD, ATM, or RING)
򐂰 TCPIPD: The TCP/IP job name
򐂰 192.16.1.20: The local VIPA

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.

Example 10-9 D NET,ID=SWTO65 and PUTO65


D NET,ID=SWTO65,E
IST097I DISPLAY ACCEPTED
IST075I NAME = SWTO65, TYPE = SW SNA MAJ NODE 633
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST084I NETWORK RESOURCES:
IST089I PUTO65 TYPE = PU_T2.1,ACTIV
IST1500I STATE TRACE = OFF
IST314I END
*******************************************************************
D NET,ID=PUTO65,E
IST097I DISPLAY ACCEPTED
IST075I NAME = PUTO65, TYPE = PU_T2.1 643
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1043I CP NAME = SC65M, CP NETID = USIBMSC, DYNAMIC LU = YES
IST1589I XNETALS = YES
IST1105I RESOURCE STATUS TGN CP-CP TG CHARACTERISTICS
IST1106I PUTO65 AC/R 22 YES 98750000000000000000017100808080
IST1482I HPR = RTP - OVERRIDE = N/A - CONNECTION = YES
IST1510I LLERP = NOTPREF - RECEIVED = NOTALLOW
IST1680I LOCAL IP ADDRESS 192.16.1.20
IST1680I REMOTE IP ADDRESS 192.16.1.30
IST136I SWITCHED SNA MAJOR NODE = SWTO65
IST081I LINE NAME = L0000000, LINE GROUP = EEGROUP, MAJNOD = XCA

We looked for an active state, as well as:


򐂰 PU_T2.1: The link station is a PU type 2.1, APPN connection between the NNs.
򐂰 TGN CP-CP: The link station is in the APPN topology database CP-CP HPR=RTP. The
level of HPR supported is RTP and the status of the connection.
򐂰 LOCAL IP ADDRESS: The number 192.16.1.20 is the VIPA address of the TCP/IP stack
used by this VTAM.
򐂰 REMOTE IP ADDRESS: Number 192.16.1.30 is the VIPA address of the remote NN.

10.6.4 Defining Enterprise Extender to IBM Personal Communications


After we install and verify Enterprise Extender on z/OS (SC64), the VTAM switched major
node SWDLUR (Example 10-5 on page 174) is activated. Using IBM Personal
Communications V5.0 (with EE support) on the workstation, we configure one EE connection
to VTAM for LU2 sessions. In this example, the workstation is the EN and SC64 is the NN.

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:

Chapter 10. Enterprise Extender 177


1. In the Customize Communication window (Figure 10-4), we specify the following choices:
a. For Type of Host, select S/390.
b. For Interface, select IBM-EEDLC.
c. For Attachment, select LU(0,1,2,3) via DLUR (APPN can also be used).
d. Click the Link Parameter button.

Figure 10-4 Customize Communication window

178 OSA-Express Implementation Guide


2. In the Configure Local System window (Figure 10-5), we specify the appropriate values for
the Net ID, CP Name, Block ID, and Physical ID fields. Then we click Next.

Figure 10-5 Configure Local System window

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.

Figure 10-6 Configure DLUR window

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.

Chapter 10. Enterprise Extender 179


4. In the IBM EEDLC Device Connection window (Figure 10-7), under Device selection, we
choose Existing device. Under Connection selection, we choose Existing connection.
Then we click Next.

Figure 10-7 IBM EEDLC Device Connection window

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

Figure 10-8 IBM-EEDLC Connection window

180 OSA-Express Implementation Guide


6. In the window that opens, we click OK and save the new configuration for EE.

10.6.5 Activation and verification (EN-to-NN)


After all the definitions are added to IBM Personal Communications, we activate the
configuration. Activation requires these tasks:
򐂰 Verifying IP connectivity between the workstation and the VIPA
򐂰 Verifying that the PU DLUR and LUs were active by using the NN VTAM display command
on SC64:
D NET,ID=PUDLUR1,E
򐂰 Confirming that the correct DLOGMOD, USSTAB, and LOGAPPL were in accordance with
our environment

Verifying the EE connection for the workstation


Since we use LOGAPPL=SC64TS (TSO on SC64), we receive the TSO prompt (IKJ56700A
SC64 ENTER USERID =) after activation.

Example 10-10 shows the VTAM display command that we use to verify that the defined LUs
are in session.

Example 10-10 Display of LU sessions using EE


D NET,ID=PUDLUR1,E
IST097I DISPLAY ACCEPTED
IST075I NAME = PUDLUR1, TYPE = PU_T2 668
IST486I STATUS= ACTIV, DESIRED STATE= ACTIV
IST1043I CP NAME = ***NA***, CP NETID = USIBMSC, DYNAMIC LU = YES
IST1589I XNETALS = YES
IST1354I DLUR NAME = TEST1110 MAJNODE = SWDLUR
IST136I SWITCHED SNA MAJOR NODE = SWDLUR
IST654I I/O TRACE = OFF, BUFFER TRACE = OFF
IST1500I STATE TRACE = OFF
IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES
IST1657I MAJOR NODE VTAMTOPO = REPORT
IST355I LOGICAL UNITS:
IST080I LUEE0001 ACT/S LUEE0002 ACT/S
IST314I END

Chapter 10. Enterprise Extender 181


182 OSA-Express Implementation Guide
11

Chapter 11. VLAN support


This chapter discusses the IEEE 802.1q standard, which describes virtual local area network
(VLAN) identifier tagging. Deploying VLAN IDs allows a physical LAN to be subdivided or
segmented into separate VLANs. The Open Systems Adapter- Express (OSA-Express)
registration process of a VLAN ID supports a single VLAN ID per IPv4 or IPv6 connection.

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.

Engineering Marketing Accouting


VLAN VLAN VLAN
Switch 3

Floor 3

Router

Switch 2 Floor 2

Floor 3

Switch 1

Figure 11-1 Logically defined networks using VLANs

11.1.1 Types of connections


IEEE 802.1q VLANs operate by defining switch ports as members of virtual LANs. Devices on
a VLAN can be connected in three ways, based on whether the connected devices are
VLAN-aware or VLAN-unaware. VLAN-aware devices understand VLAN memberships (which
users belong to a particular VLAN) and VLAN formats.

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

184 OSA-Express Implementation Guide


are VLAN capable, and filters and processes all VLAN ID tagged packets. In trunk mode, the
switch expects to see VLAN ID tagged packets inbound to the switch port.

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

Access ports Access port

TRUNK PORT

Switch 1
Switch 2

VLAN 100 VLAN 102

Router Internet

Figure 11-2 VLAN logical diagram

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.

There is a single VLAN-aware router connected to Switch 1, which provides access to an


external network to users in VLANs 100 and 102. The trunk port to which the router is
attached is defined to VLANs 100 and 102, not to VLAN 101. Therefore, no workstations in

Chapter 11. VLAN support 185


VLAN 101 can reach the router. Hub 1 is a VLAN-unaware device, so the port in Switch 2 that
it connects to is an access port.

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.

11.1.2 VLAN tagging basics


In a VLAN environment, you find two types of frames:
򐂰 Untagged frames
There is no tag header following the source MAC address.
򐂰 Tagged frames
– Priority-tagged frame
The tag header includes only VLAN priority information, but no VLAN ID. (VLAN ID is
zero and is referred to as a null-tagged frame.)
– VLAN-tagged frame
The tag header includes both VLAN priority information and VLAN ID.

186 OSA-Express Implementation Guide


Figure 11-3 illustrates these descriptions.

Dest MAC address Source MAC address Type/Length

Ethernet header (untagged)

Tag Control Info


Dest MAC address Source MAC address Type/Length
(4 Bytes)

Ethernet header (tagged)

VLAN Tag x'8100' 3-bit Priority 1-bit Canonical 12-bit VLAN ID


(always zero)

Figure 11-3 VLAN tagging

11.2 General VLAN design considerations


Take the following points into consideration when designing VLANs using OSA-Express
Ethernet features:
򐂰 If a VLAN ID is defined to the TCP/IP stack for an OSA-Express port, the Ethernet switch
port to which the OSA-Express port is attached must be configured in trunk mode.
򐂰 If no VLAN ID is defined to the TCP/IP stack for an OSA-Express port, the Ethernet switch
port to which the OSA-Express port is attached must be configured in access mode.
򐂰 If an OSA-Express port is shared across multiple TCP/IP stacks and all are not defined
with a VLAN ID, then the Ethernet switch port must be defined in trunk mode. Untagged
traffic from the TCP/IP stacks that does not have a VLAN ID defined is tagged by the
switch with the default VLAN ID.
򐂰 Some Ethernet switch vendors use VLAN ID 1 for vendor-specific purposes or as the
default VLAN ID. Therefore, the use of VLAN ID 1 should be avoided.

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.

Chapter 11. VLAN support 187


If the TCP/IP stack is also configured with PRIRouter or SECRouter for an OSA-Express port
that has a VLAN ID defined, then the stack serves as an IP router for the configured VLAN ID.
See 11.2.3, “Primary and secondary router support with VLANs” on page 189, for details.

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.

11.2.1 VLAN configuration example


When designing VLANs in conjunction with an OSA-Express port, we recommend that
deployment is symmetrical with the configuration of the corresponding Ethernet switch. For
example, the Ethernet switch port associated with an OSA-Express port must be configured
in trunk mode when the OSA-Express port performs VLAN tagging and VLAN ID filtering.

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)

z/VM z/OS z/OS z/VM


LINUX1 LINUX2

IP-stack #1 IP-stack #2 IP-stack #3 IP-stack #4 IP-stack #5

VLAN ID 100 VLAN ID 200 VLAN ID 300 No VLAN ID No VLAN ID

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

Trunk Mode Ethernet Switch


Access Mode
VLAN 400
Access Mode Access Mode Access Mode
VLAN 100 VLAN 200 VLAN 300

Router
Clients 1 and 2 Clients 3 and 4 Clients 5 and 6

Figure 11-4 Trunk mode versus access mode

188 OSA-Express Implementation Guide


IP-stacks #4 and #5 do not have a VLAN ID defined, and therefore are unaware of the
existence of VLAN IDs and VLAN tagging. The Ethernet switch port to which OSA-Express
port #2 is connected, is configured in access mode.

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.

11.2.2 Sharing an OSA-Express port with the same VLAN ID


Figure 11-5 illustrates a single OSA-Express port shared between IP-stack #4 and #5, both
configured with the same VLAN ID. Since the configured VLAN IDs in both TCP/IP stacks are
identical and the next hop IP address is registered in the OSA-Express Address Table (OAT),
the OSA-Express logic bypasses the LAN and the packet is sent directly to the destination
TCP/IP stack.

z/VM z/OS z/OS


IP-stack #4 IP-stack #5
10.1.0.1/24 10.2.0.1/24
LINUX1 LINUX2 z/OS

IP-stack #1 IP-stack #2 IP-stack #4


VLAN ID 100 VLAN ID 100
OSA-Express

VLAN ID 2 VLAN ID 3 VLAN ID4

OSA-Express OSA-Express

ETHERNET Trunk Mode


Switch

Access Access Access


Mode Mode Mode Router
VLAN 2 VLAN 3 VLAN 4

Figure 11-5 OSA-Express port shared between two stacks in the same VLAN

11.2.3 Primary and secondary router support with VLANs


An OSA-Express port supports the primary and secondary router function on a registered
VLAN ID basis. This means that if an OSA-Express port is configured with a VLAN ID and
PRIRouter or SECRouter statement, that TCP/IP stack serves as an IP router for that specific
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.

Chapter 11. VLAN support 189


IP-stack #2 and IP-stack #4 serve as PRIRouters for their respective VLAN and subnetwork.
IP-stack #3 with SECRouter defined is the backup to IP-stack #2 for VLAN 200 traffic. And
IP-stack #1 serves as the default global primary router, since a VLANID is not configured. In
this case, the OSA-Express forwards all traffic to IP-stack #1 that does not have a VLAN ID of
200 or 300.

Restriction: When sharing an OSA-Express port, each VLAN can support multiple
secondary routers. However only one primary router is supported.

IP Subnet A IP Subnet B IP Subnet C

z/OS z/OS z/OS z/VM

IP-stack #1 IP-stack #2 IP-stack #3 IP-stack #4

No VLAN ID VLAN ID 200 VLAN ID 200 VLAN ID 300


Global Default PRIRouter SECRouter PRIRouter
PRIRouter

OSA-Express

Untagged and null tagged traffic


VLAN 200 and 300 traffic

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.

11.2.4 Operating system support


As mentioned earlier, z/OS, z/VM, and Linux provide full VLAN support using the
OSA-Express Ethernet features. It is possible to share an OSA-Express port between Linux
and other operating systems.

190 OSA-Express Implementation Guide


Note: A Linux on System z9 or zSeries TCP/IP stack supports multiple VLAN IDs on a
single interface. This means that frames going to a Linux on System z9 or zSeries TCP/IP
stack via a single OSA-Express port can come from multiple VLANs.

Multiple VLAN IDs defined to a single OSA-Express port are not supported with z/OS or
z/VM.

11.3 VLAN support for z/OS


z/OS V1R4 plus APAR PQ86508 or later releases provide full VLAN support for
OSA-Express2 and OSA-Express Ethernet features, running in QDIO mode. To support
VLANs, the new OSA-Express2 features require the January 2005 level of LIC. The
OSA-Express Ethernet features must be at DRV3G with MCL (J11204.022) or later, and
running in QDIO mode.

11.3.1 VLAN implementation


In our environment, we configure two VLANs (see Figure 11-7), one for each z/OS V1R6
system. We enable a connection between the two VLANs through an Ethernet switch and
defined a trunk port for the OSA-Express connection. We also install two workstations, one
connected to each VLAN.

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

Port assigment for the Ethernet Switch


Port Type VLAN ID Connection
2/1 TRUNK n/a OSA-Express
2/5 ACCESS VLAN 200 Client 1
2/6 ACCESS VLAN 300 Client 2
Client 1 Client 2
Figure 11-7 Our z/OS VLAN configuration at the ITSO

To define an OSA-Express port in QDIO mode, refer to Chapter 5, “QDIO mode” on page 79
for details.

Chapter 11. VLAN support 191


We configure the VLAN ID of 200 on SC64 and the VLAN ID of 300 on SC65 using the
parameter VLANID on the LINK statement of the TCP/IP profile. The VLANID is an optional
parameter followed by a decimal number indicating the Virtual LAN 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.

Ethernet switch configuration


We alter the configuration of the Ethernet switch to support the new VLANs and the trunk. We
add the VLAN 200 to port 2/5, the VLAN 300 to port 2/6, and defined the trunk to port 2/1.

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.

Example 11-1 Results of the netstat dev command on SC64


DevName: OSAE200 DevType: MPCIPA
DevStatus: Ready
LnkName: E200LNK LnkType: IPAQENET LnkStatus: Ready
NetNum: n/a QueSize: n/a Speed: 0000000100
IpBroadcastCapability: No
CfgRouter: Non ActRouter: Non
ArpOffload: Yes ArpOffloadInfo: Yes
ActMtu: 1492
VLANid: 200 VLANpriority: Disabled
ReadStorage: GLOBAL (4096K) InbPerf: Balanced
ChecksumOffload: Yes
BSD Routing Parameters:
MTU Size: 00000 Metric: 00
DestAddr: 0.0.0.0 SubnetMask: 255.255.255.0
Multicast Specific:
Multicast Capability: Yes
Group RefCnt
----- ------
224.0.0.1 0000000001
Link Statistics:
BytesIn = 23848
Inbound Packets = 182
Inbound Packets In Error = 0
Inbound Packets Discarded = 0
Inbound Packets With No Protocol = 0
BytesOut = 7736
Outbound Packets = 83
Outbound Packets In Error = 0
Outbound Packets Discarded = 0

192 OSA-Express Implementation Guide


We verify the configuration of the Ethernet switch by issuing the sh running-config
command to check the running configuration (see Example 11-2).

Example 11-2 Extract of the sh running-config command


pok6509t (enable) sh run
#vtp
set vtp domain itso_network
set vtp mode transparent
set vlan 1 name default type ethernet mtu 1500 said 100001 state active
set vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state active
set vlan 300 name VLAN0300 type ethernet mtu 1492 said 100201 state active

#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

set trunk 2/1 on dot1q 1-1005,1025-4094


set trunk 2/2 on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enable


set spantree guard none 2/1-48

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.

11.4 VLAN support for Linux


To support VLANs, the OSA-Express2 features require the January 2005 level of LIC. The
OSA-Express Ethernet features must be at DRV3G with MCL (J11204.022) or later, and
running in QDIO mode.

IEEE 802.1Q VLAN module


VLAN support was added to the Linux kernel at version 2.4.19. If your Linux system is not
running at this level or later, you must have an updated kernel or load the IEEE 802.1Q VLAN
module.

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.

To load the module using the modprobe command, you enter:


# modprobe 8021q

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]>

Chapter 11. VLAN support 193


11.4.1 VLAN implementation
In our environment (Figure 11-8), we configure two VLANs, one for each Linux system. We
enable a connection between the two VLANs through an Ethernet switch and define a trunk
port for the OSA-Express connection. We also install two workstations, one connected to
each VLAN.

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

vconfig add eth1 200


ifconfig eth1.200 200.1.1.1
netmask 255.255.255.0 up ETH1 ETH1
VLAN 200 VLAN 210
200.1.1.1 210.1.1.1

LINUX 3:

vconfig add eth1 210 OSA-Express


ifconfig eth1.210 210.1.1.1
netmask 255.255.255.0 up Trunk connection to support
VLAN 200 and 210 traffic

Ethernet Switch Trunk Mode

Access Access
Mode Mode
VLAN 200 VLAN 210

Port assigment for the Ethernet Switch


Port Type VLAN ID Connection
2/1 TRUNK n/a OSA-Express
2/5 ACCESS VLAN 200 Client 1
2/6 ACCESS VLAN 210 Client 2
Clients 1 Clients 2
Figure 11-8 LINUX VLAN configuration for the ITSO

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

194 OSA-Express Implementation Guide


After issuing the vconfig add commands on the respective systems, we receive the following
messages:
򐂰 LINUX2
Added VLAN with VID == 200 to IF -:eth1:-
򐂰 LINUX3
Added VLAN with VID == 210 to IF -:eth1:-

To remove a VLAN interface, you use the following command:


ifconfig eth1.200 down
vconfig rem eth1.200

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.

Ethernet switch configuration


We alter the configuration of the Ethernet switch to support the VLANs and the trunk. We add
the VLAN 200 to port 2/5 and the VLAN 210 to port 2/6, as well as define the trunk to port 2/1.

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.

Example 11-3 Results of the ifconfig command


ifconfig
eth1.210 Link encap:Ethernet HWaddr 00:06:29:6C:A5:BC
inet addr:210.1.1.1 Mask:255.255.255.0
inet6 addr: fe80::6:2900:56c:a5bc/10 Scope:Link
UP RUNNING MULTICAST MTU:1492 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:148 (148.0 b)

We verify the configuration of the Ethernet switch by entering the sh running-config


command to check the running configuration (see Example 11-2).

Example 11-4 Extract of the sh running-config command


pok6509t (enable) sh run
#vtp
set vtp domain itso_network
set vtp mode transparent
set vlan 1 name default type ethernet mtu 1500 said 100001 state active
set vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state active
set vlan 210 name VLAN0300 type ethernet mtu 1492 said 100201 state active

#spantree
#portfast
set spantree global-default bpdu-guard enable
!
#module 2 : 48-port 10/100BaseTX Ethernet

Chapter 11. VLAN support 195


set vlan 200 2/5
set vlan 210 2/6

set trunk 2/1 on dot1q 1-1005,1025-4094


set trunk 2/2 on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enable


set spantree guard none 2/1-48

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.

11.5 VLAN support for z/VM


To support VLAN, z/VM 4.4 and later releases provide:
򐂰 Enhancements to TCP/IP for z/VM to enable membership in a VLAN
򐂰 Enhancements to z/VM virtual QDIO and HiperSockets network interface to support VLAN
frame tagging as described in IEEE 802.1q
򐂰 Management and control of VLAN IDs that can be used by guest virtual machines

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.

11.5.1 z/VM native VLAN support


In our environment, we configure a VLAN (see Figure 11-9), with one z/VM V5R1 system. We
enable a connection for the VLAN through an Ethernet switch and define a trunk port for the
OSA-Express connection. We also installed a workstation, connected to the VLAN via an
access port on the Ethernet switch.

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.

196 OSA-Express Implementation Guide


PROFILE TCP/IP

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

Figure 11-9 z/VM VLAN configuration at the ITSO

Ethernet switch configuration


We alter the configuration of the Ethernet switch to support the VLAN and the trunk. We add
the VLAN 200 to port 2/5 and define the trunk to port 2/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).

Example 11-5 Results of the netstat dev command on VM5


VM TCP/IP Netstat Level 510

Device OSA2D48 Type: OSD Status: Ready


Queue size: 0 CPU: 0 Address: 2D48 Port name: OSACHP0D
IPv4 Router Type: NonRouter Arp Query Support: Yes
Link OSA2D48L Type: QDIOETHERNET Net number: 0
BytesIn: 4695 BytesOut: 984
Forwarding: Enabled MTU: 1492 IPv6: Disabled
VLAN ID: 200
Broadcast Capability: Yes
Multicast Capability: Yes
Group Members
----- -------
224.0.0.1 1

Chapter 11. VLAN support 197


We verify the configuration of the Ethernet switch by entering the sh running-config
command to check the running configuration (see Example 11-6).

Example 11-6 Extract of the sh running-config command


pok6509t (enable) sh run
#vtp
set vtp domain itso_network
set vtp mode transparent
set vlan 1 name default type ethernet mtu 1500 said 100001 state active
set vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state active

#spantree
#portfast
set spantree global-default bpdu-guard enable
!
#module 2 : 48-port 10/100BaseTX Ethernet
set vlan 200 2/5

set trunk 2/1 on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enable


set spantree guard none 2/1-48

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.

11.5.3 VLAN support for z/VM Virtual Switch


z/VM Virtual Switch supports IEEE 802.1Q VLANs. This means that guests attached to a
virtual switch can participate in VLAN networking. When an OSA-Express port is attached to
the virtual switch, VLAN operations are extended beyond the virtual switch to a physical LAN
segment.

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,

198 OSA-Express Implementation Guide


when the virtual switch is configured to operate as VLAN-unaware, the port on the Ethernet
switch for the OSA-Express port connection should be configured as an access port.

Figure 11-10 illustrates an example of a virtual switch configured as “VLAN-aware”.

The VLAN IDs are specified through


Guest1 Guest2 Guest3 z/VM 5.1 the SET VSWITCH command
This means that the guests must be
VLAN-aware in order to communicate
on a specific VLAN
"VLAN ID 100" "VLAN ID 100" "VLAN ID 200"

The Virtual Switch ensures


traffic flows correctly:
Guest3 belongs to VLAN 200 With a port type of trunk, the Virtual
Guest2 belongs to VLAN 100 Switch expects tags with VLAN IDs
Guest1 belongs to VLAN 100 from the attached guest systems
All data sent from the OSA-Express
port will be tagged, as it would be
VLAN ID 100 VLAN ID 200 when two real switches communicate

Virtual Switch "VLAN-aware"

The setup of the Ethernet switch port


OSA-Express determines the VLAN membership
The port must be defined in trunk
mode
Trunk connection for
VLAN 100 and 200

Trunk Mode

Access Mode Access Mode Router


VLAN 100 Ethernet Switch VLAN 200

Clients 1 and 2 Clients 3 and 4

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.

Chapter 11. VLAN support 199


If the virtual switch is set up as VLAN-unaware, any VLAN tagging that exists is ignored and
remains in the frame. The z/VM CP does not enforce VLAN membership restrictions in this
case. Tagged traffic flows unimpeded through the virtual switch to guest systems and the
OSA-Express port connection. Figure 11-11 illustrates an example of a virtual switch
configured as VLAN-unaware.

The setup of the Ethernet switch port determines the VLAN membership.

Guest1 Guest2 Guest3 z/VM 5.1


No VLAN IDs defined. Guests 1-3
are not aware of VLAN membership

With a port type of access, the Virtual


Switch ignores the presence of VLAN
tags
VLAN membership will not be enforced

Virtual Switch "VLAN-unaware"

The setup of the Ethernet switch port


OSA-Express determines the VLAN membership
The port must be defined in access
mode

Access Mode
Access VLAN 100 Access
Mode Mode
Router
VLAN 100 Ethernet Switch VLAN 200

Clients 1 and 2 Clients 3 and 4

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.

200 OSA-Express Implementation Guide


12

Chapter 12. Layer 2 support


Layer 2 support in the virtual switch and the Open Systems Adapter-Express (OSA-Express)
Ethernet features is a powerful solution that removes the requirement for an intermediate
router between an external local area network (LAN) and the internal Guest LAN. Running as
a Layer 2 switch means that Linux guests can exist and operate in the network the same way
hosts on a physical LAN environment do. Non-TCP/IP protocols are supported as are IPv4
and IPv6, which means there are more opportunities to consolidate machines to a z/VM
environment.

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.

12.1.1 Virtual switch controller


Virtual switch connectivity to an OSA-Express device is provided through a controller virtual
machine. The controller is responsible for the management of the OSA-Express devices for
the virtual switch. It handles the initialization of the device and communicates configuration
information to OSA-Express port. In OSA-Express or QDIO terms, you can think of the
controller managing the read and write devices and Control Program (CP) managing the
data device. To enable this functionality, at least one TCP/IP virtual machine must be
configured to act as a controller.

For more information about how to configure a virtual switch controller, refer to “Configuring a
virtual switch controller” on page 206.

202 OSA-Express Implementation Guide


Note: Unlike previous networking configurations that used the z/VM TCP/IP stack, there is
no requirement to manually configure any IP addresses or devices when using the virtual
switch. The only settings in the stack’s PROFILE TCPIP file are listed in Example 12-3 on
page 207.

12.1.2 Network interface card


You must create a virtual network interface card (NIC) for each guest system. When defined,
this NIC can be connected to the virtual switch. To the guest operating system, the NIC
devices look like a range of OSA devices. The NIC can be defined permanently via a z/VM
user directory statement or temporarily (for the life of the guest system’s session), using CP
commands.

A NIC is a set of virtual I/O devices that simulate one of the following network adapters:
򐂰 OSA-Express
򐂰 HiperSockets

A NIC can attach to multiple virtual switches of the same type.

For more information about how to configure the NIC, refer to “Linking the guest systems to
the virtual switch” on page 210.

12.1.3 Guest systems


Operating systems running in virtual machines are often called guest systems or simply
guests. A virtual machine is directly associated with a z/VM user ID or logon identifier. When
you log on to z/VM, you have a virtual machine at your disposal and can control the virtual
machine the way a system operator controls the real hardware.

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.

12.1.4 Ethernet mode


As mentioned earlier, the virtual switch has been enhanced to operate at the Layer 2 (Data
Link Layer) level of the OSI model, known as Ethernet mode. Since Ethernet mode uses MAC
addressing to forward data frames, it is protocol-independent, providing the ability to transport
both IP and non-IP application data, such as SNA, DECnet, IPX™ or NetBIOS. The virtual
switch works in conjunction with the Layer 2 support of the OSA-Express Ethernet features to
communicate with hosts residing on a physical LAN segment to which the OSA-Express port
is connected.

Chapter 12. Layer 2 support 203


The key attributes for this environment are:
򐂰 It supports all applications that deploy Ethernet (IEEE 802).
򐂰 Ethernet frames are transported on the LAN segment.
򐂰 All destinations are identified by MAC address.
򐂰 MAC addresses are locally administered by the LAN administrator through z/VM CP
commands or configuration statements.
򐂰 Each host connection is identified by a single MAC address.
򐂰 This is a Data Link Layer transport, in which all hosts maintain their respective ARP
caches.
򐂰 VLAN tagging resides within the Ethernet frame per IEEE 802.1Q specifications.

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.

12.1.5 MAC addresses


The LAN administrator can decide which MAC addresses are locally generated and
associated with each guest. This is done using a combination of the VMLAN statement (in
SYSTEM CONFIG) and the NICDEF statement (in the User Directory).

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.

204 OSA-Express Implementation Guide


12.1.6 Requirements
Layer 2 support is available only for the System z9, zSeries 990 and 890 (z990 and z890)
servers with the May 2004 Licensed Internal Code (LIC) level (Driver 55) or later. To use
Layer 2 support on your System z9 109 (z9-109), z990, or z890, you need the following
prerequisites:
򐂰 OSA-Express Ethernet port (with code level 6.14)
򐂰 z/VM 5.1
򐂰 Linux qeth device driver that supports Layer 2
In our testing, we used SUSE LINUX Enterprise Server (SLES) 8 running at Kernel
2.4.21-231 with qeth driver level 1.397.

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 response looks similar to this example:


qeth S/390 OSA-Express driver ($Re -L2- : 1.397 $/$Re -L2- : 1.131 $/$Re -L2- : 1.50
$:IPv6:VLAN)

12.2 Description and objectives of our test environment


Our test environment consists of a z/VM 5.1 and z/OS 1.6 systems, with network connectivity
via two OSA-Express 1000BASE-T ports (in separate features) and an Ethernet switch. On
the z/VM system, a virtual switch is configured with two virtual controllers (Primary and
Backup) to provide the OSA-Express connectivity. Three Linux guests systems are also
configured. On z/OS, we configure three TCP/IP stacks running on separate LPARs. The
OSA-Express 1000BASE-T ports are defined as channel type OSD (QDIO).

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.

12.2.1 Configuring Layer 2 support


For the first part of this exercise, we configure Layer 2 support without VLAN support. The
objectives are:
򐂰 Configure a Layer 2 virtual switch environment, using OSA-Express Ethernet ports
򐂰 Verify the Layer 2 virtual switch environment
򐂰 Verify connectivity between guests and clients connected through the virtual switch and
OSA-Express Ethernet port

To achieve these objectives, we use the following steps:


1. Configure a z/VM TCP/IP virtual machine to act as a controller for the virtual switch.
2. Define a virtual switch to provide network connectivity between guest systems and clients
via the OSA-Express Ethernet port.
3. Authorize access for each guest system to the virtual switch.

Chapter 12. Layer 2 support 205


4. Create a simulated NIC on each guest system to be connected to the virtual switch.
5. Verify the configuration.

Figure 12-1 shows a diagram of our Layer 2 virtual switch configuration.

LNXSU1 LNXSU2 LNXSU3 VSWCTL1 VSWCTL2


z/VM 5.1 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

OSA-Express 2D40 OSA-Express 3D44 OSA-Express

Ethernet Switch

Figure 12-1 Layer 2 virtual switch configuration

Configuring a virtual switch controller


The virtual switch uses a TCP/IP virtual machine to interface with the OSA-Express port or
ports. This TCP/IP virtual machine acts as a controller for the virtual switch and manages the
operation of the OSA-Express port or ports. In order for a virtual switch to provide connectivity
to a LAN, at least one TCP/IP virtual machine must be configured to be a controller. The
configuration allows the TCP/IP stack to connect to the system service that manages virtual
switch connections. The TCP/IP virtual machine can then control the OSA-Express Ethernet
connection. In our example, we define two virtual machines to act as virtual switch controllers.
This is done as explained in the following sections.

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).

206 OSA-Express Implementation Guide


Example 12-1 Virtual switch controller user definitions
USER VSWCTL1 VSWCTL1 32M 128M ABG
INCLUDE TCPCMSU
OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON
SHARE RELATIVE 3000
IUCV ALLOW
IUCV ANY PRIORITY
IUCV *CCS PRIORITY MSGLIMIT 255
IUCV *VSWITCH MSGLIMIT 65535
LINK 4TCPIP40 491 491 RR
LINK 4TCPIP40 492 492 RR
LINK TCPMAINT 591 591 RR
LINK TCPMAINT 592 592 RR
LINK TCPMAINT 198 198 RR
MDISK 191 3390 1706 005 440W02 MR RTCPIP WTCPIP MTCPIP

USER VSWCTL2 VSWCTL2 32M 128M ABG


INCLUDE TCPCMSU
OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON
SHARE RELATIVE 3000
IUCV ALLOW
IUCV ANY PRIORITY
IUCV *CCS PRIORITY MSGLIMIT 255
IUCV *VSWITCH MSGLIMIT 65535
LINK 4TCPIP40 491 491 RR
LINK 4TCPIP40 492 492 RR
LINK TCPMAINT 591 591 RR
LINK TCPMAINT 592 592 RR
LINK TCPMAINT 198 198 RR
MDISK 191 3390 1712 005 440W02 MR RTCPIP WTCPIP MTCPIP

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.

Example 12-2 PROFILE EXEC of AUTOLOG1


ADDRESS COMMAND CP AUTOLOG VSWCTL1 VSWCTL1
ADDRESS COMMAND CP AUTOLOG VSWCTL2 VSWCTL2

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.

Example 12-3 Virtual switch controller’s PROFILE TCPIP


ASSORTEDPARMS
PROXYARP VARSUBNETTING RESTRICTLOWPORTS
ENDASSORTEDPARMS

VSWITCH CONTROLLER ON

Chapter 12. Layer 2 support 207


SYSTEM DTCPARMS
Create a SYSTEM DTCPARMS file on each controller virtual machine’s 191 disk. You can
usually find a copy on the TCPMAINT 198 disk. However, you only need to include the lines
as shown in Example 12-4.

Example 12-4 SYSTEM DCTPARMS


:NICK.VSWCTL1 :TYPE.SERVER
:class.stack
:NICK.VSWCTL2 :TYPE.SERVER
:class.stack

Defining the virtual switch


A virtual switch is created using the CP DEFINE VSWITCH command from a z/VM Class B
user ID. Edit SYSTEM CONFIG and add the following definition to the file:
DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CON CONTR * ETHERNET PORTNAME OSACHP0D OSACHP0E

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).

The syntax of the DEFINE VSWITCH statement is:


DEFINE VSWITCH switchname [ operands ]

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.

Table 12-1 Common operands of the DEFINE VSWITCH statement


LIMIT parameter Description
operands

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.

208 OSA-Express Implementation Guide


LIMIT parameter Description
operands

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.

Table 12-2 Operands of the VMLAN statement


LIMIT parameter Description
operands

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.

Example 12-5 VMLAN definition


VMLAN MACPREFIX 02EEEE
VMLAN MACIDRANGE SYSTEM 100000-1FFFFF

Chapter 12. Layer 2 support 209


Authorizing the guest systems access to the virtual switch
Edit SYSTEM CONFIG and add the statements to control access to the virtual switch.
Although we add MODIFY VSWITCH statements (see Example 12-6) to grant access to the
virtual switch, you can use the SET VSWITCH command to achieve the same results.

Example 12-6 MODIFY VSWITCH statement

MODIFY VSWITCH VSWTCH1 GRANT LNXSU1


MODIFY VSWITCH VSWTCH1 GRANT LNXSU2
MODIFY VSWITCH VSWTCH1 GRANT LNXSU3

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.

Linking the guest systems to the virtual switch


To create a virtual NIC that will remain permanently defined to a guest system (after IPLs of
the guest system or the z/VM operating system), add the NICDEF statement to the z/VM user
directory.

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).

Example 12-7 NICDEF statements for Linux guests connecting to VSWTCH1


USER LNXSU1 LNXSU1 128M 1G G
NICDEF C204 TYPE QDIO LAN SYSTEM VSWTCH1

USER LNXSU2 LNXSU2 128M 1G G


NICDEF C204 TYPE QDIO LAN SYSTEM VSWTCH1

Note: We could have added a MACID parameter to the NICDEF statement. Instead, we
chose to let the system generate one for us.

The syntax of the NICDEF statement for NIC is:


NICDEF vdev [ operands ]

In this statement, vdev specifies the base virtual device address for the adapter, and
operands defines the characteristics of the virtual NIC.

210 OSA-Express Implementation Guide


Table 12-3 Operands for the SPECIAL User Directory statement
Operands Description

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.

Verifying the configuration


We perform an initial program load (IPL) to our test system and check to ensure that the
changes we made are correct.

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.

Example 12-8 QUERY CONTROLLER output


QUERY CONTROLLER
Controller VSWCTL1 Available: YES VDEV Range: * Level 510
Capability: IP ETHERNET VLAN_ARP
SYSTEM VSWTCH1 Primary Controller: * VDEV: 2D40
Controller VSWCTL2 Available: YES VDEV Range: * Level 510
Capability: IP ETHERNET VLAN_ARP
SYSTEM VSWTCH1 Backup Controller: * VDEV: 3D44
Ready; T=0.01/0.01 13:36:59

Chapter 12. Layer 2 support 211


Virtual switch
To check the state of the virtual switch, refer to Example 12-9.

Example 12-9 QUERY VSWITCH


QUERY VSWITCH
VSWITCH SYSTEM VSWTCH1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED ETHERNET Accounting: OFF
VLAN Unaware
State: Ready
QueueStorage: 8
Portname: OSACHP0D RDEV: 2D40 Controller: VSWCTL1 VDEV: 2D40
Portname: OSACHP0E RDEV: 3D44 Controller: VSWCTL2 VDEV: 3D44 BACKUP

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.

Example 12-10 QUERY VMLAN


Q VMLAN
VMLAN maintenance level:
Latest Service: VM63538
VMLAN MAC address assignment:
MACADDR Prefix: 020000
MACIDRANGE SYSTEM: 000001-FFFFFF (Will reflect your settings)
USER: 000000-000000 (Will reflect your settings)
VMLAN default accounting status:
SYSTEM Accounting: OFF USER Accounting: OFF
VMLAN general activity:
PERSISTENT Limit: INFINITE Current: 1
TRANSIENT Limit: INFINITE Current: 0

Authorization
To check the access list of the authorized user IDs for the virtual switch, refer to
Example 12-11.

Example 12-11 QUERY VSWITCH command

q vswitch vswtch1 access


vSWITCH SYSTEM VSWTCH1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED ETHERNET Accounting: OFF
VLAN Unaware
State: Ready
QueueStorage: 8
Portname: OSACHP0D RDEV: 2D40 Controller: VSWCTL1 VDEV: 2D40
Portname: OSACHP0D RDEV: 3D44 Controller: VSWCTL2 VDEV: 3D44 BACKUP
Authorized userids:
LNXSU1 LNXSU2 LNXSU3 SYSTEM

212 OSA-Express Implementation Guide


NICs
To check the NIC for each quest system, enter the Q NIC DETAILS command from the guest
system’s z/VM user ID (see Example 12-12).

Example 12-12 QUERY NIC

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

The default MAC address 02-00-00-00-00-04 was assigned by the system.

12.2.2 Setting up and testing Layer 2 functionality for Linux guests


To test our environment, we issue PING commands between LNXSU1 and LNXSU2, and the
clients connected through an OSA-Express 1000BASE-T port that was attached to an
external Ethernet switch. We choose to configure a static IP address for each Linux guest
LNXSU1 (192.16.1.41) and LNXSU2 (192.16.1.42), using the following command:
ifconfig eth0 192.16.1.41 netmask 255.255.255.0 up

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).

Example 12-13 LNXSU1 and LNXSU2 /etc/chandev.conf entries


LNXSU1
noauto;qeth0,0xc204,0xc205,0xc206;add_parms,0x10,0xc204,0xc206,layer2

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.

Chapter 12. Layer 2 support 213


Example 12-14 ifconfig command output from LNXSU1
ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:01
inet addr:192.16.1.41 Bcast:255.255.255.0 Mask:255.255.255.0
inet6 addr: fe80::200:0:0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:103 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1394 (1.3 Kb) TX bytes:11546 (11.2 Kb)
Interrupt:3

On the z/VM side, we verify the connection by using the QUERY VSWITCH command as
shown in Example 12-15.

Example 12-15 Query VSWITCH output


Q vswitch det
VSWITCH SYSTEM VSWTCH1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED ETHERNET Accounting: OFF
VLAN Unaware
State: Ready
QueueStorage: 8
Portname: OSACHP0D RDEV: 2D40 Controller: VSWCTL1 VDEV: 2D40
Portname: OSACHP0E RDEV: 3D44 Controller: VSWCTL2 VDEV: 3D44 BACKUP
VSWITCH Connection:
RX Packets: 38 Discarded: 0 Errors: 0
TX Packets: 98 Discarded: 0 Errors: 0
RX Bytes: 1922 TX Bytes: 216310
Device: 2D42 Unit: 002 Role: DATA
Unicast IP Addresses:
192.16.1.20 MAC: 00-09-6B-1A-1F-0F Remote
Adapter Owner: LNXSU1 NIC: C204 Name: UNASSIGNED
RX Packets: 78 Discarded: 0 Errors: 0
TX Packets: 151 Discarded: 0 Errors: 0
RX Bytes: 4778 TX Bytes: 11190
Device: C206 Unit: 002 Role: DATA
Options: Ethernet Broadcast
Unicast MAC Addresses:
02-00-00-00-00-01 IP: 192.16.1.41
Multicast MAC Addresses:
01-00-5E-00-00-01 IP: 224.0.0.1
33-33-00-00-00-01 IP: FF02::1
33-33-FF-00-00-01 IP: FF02::FF00:1
Adapter Owner: LNXSU2 NIC: C204 Name: UNASSIGNED
RX Packets: 81 Discarded: 0 Errors: 0
TX Packets: 51 Discarded: 0 Errors: 0
RX Bytes: 5078 TX Bytes: 3534
Device: C206 Unit: 002 Role: DATA
Options: Ethernet Broadcast
Unicast MAC Addresses:
02-00-00-00-00-02 IP: 192.16.1.42
Multicast MAC Addresses:
01-00-5E-00-00-01 IP: 224.0.0.1
33-33-00-00-00-01 IP: FF02::1

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.

214 OSA-Express Implementation Guide


Next we enter a PING command between LNXSU1 and LNXSU2 to confirm network
connectivity and reachabillity via the virtual switch. Then we successfully send PINGs from a
client connected to the Ethernet switch, to LNXSU1 and LNXSU2 (see Figure 12-2).

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

OSA-Express 2D40 OSA-Express 3D44 OSA-Express

Ethernet Switch

192.16.1.15

Figure 12-2 Verifying virtual switch connectivity, using the PING command

12.2.3 Configuring Layer 2 virtual switch with VLAN support


To demonstrate Layer 2 functionality across the virtual switch and OSA-Express ports, we
extend our Layer 2 configuration to include the z/OS TCP/IP stacks. Connectivity to the z/OS
systems is provided via an Ethernet Switch. The steps described previously to configure and
implement a virtual switch environment remain the same, except for the VLAN-specific
changes highlighted in the following text. As mentioned previously, the configuration changes
can be made dynamically depending on your circumstances, but to make them permanent,
you must add them to your system configuration files.

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.

Chapter 12. Layer 2 support 215


For assistance with the VLAN configuration process, refer to the flowcharts shown in
Figure 12-3 and Figure 12-4.

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

Figure 12-3 Virtual switch: VLAN configuration

216 OSA-Express Implementation Guide


The VLAN ID and port type values used in the DEFINE VSWITCH command become the
default values that are used by the guest system or systems, when attaching to the virtual
switch. With the SET VSWITCH command, you can authorize access for guests and change
the default values for a virtual switch defined as trunk port type (see Figure 12-4).

Virtual Switch Guest


defined in inherits NO NO Change
YES Authorize Guest
Change both access with new
TRUNK Mode Virtual
Switch defaults VLAN ID VLAN ID
with VLAN ID ? ?
defaults .....
?

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

Prepare Done Done


LINUX
Setup
SET VSWITCH VSWTCH1 GRA LNXSU1

SET VSWITCH VSWTCH1 GRA LNXSU1 PORTT ACCESS VLAN 200


Done SET VSWITCH VSWTCH1 GRA LNXSU1 PORTT ACCESS

SET VSWITCH VSWTCH1 GRA LNXSU1 VLAN 200

Figure 12-4 Virtual switch: Trunk mode configuration options

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.

Chapter 12. Layer 2 support 217


Figure 12-5 illustrates the VLAN test environment.

z/VM 5.1 z/OS 1.6


LNXSU1 LNXSU2 LNXSU3 SC63 SC64 SC65
VSWCTL1 VSWCTL2
MAC Addr. MAC Addr. VIPA 192.16.1.10 VIPA 192.16.1.20 VIPA 192.16.1.30
02-00-00-00-00-01 02-00-00-00-00-02 Primary Backup
IP. 193.16.1.41 IP: 192.16.1.42 IP. 192.16.1.43 Controller Controller IP 193.16.1.12 IP 192.16.1.21 IP 194.16.1.31
IP: 194.16.1.41 IP: 193.16.1.42 VLAN 101 VLAN 200 VLAN 300
VLAN 101,300 VLAN 101, 200

VLAN 101 VLAN 200 VLAN 300 VSWTCH1

Virtual Switch

Virtual Switch
manages and
OSA-Express 2D40 OSA-Express 3D44 OSA-Express
controls VLAN
membership

Ethernet Switch VLAN 200

Figure 12-5 Our VLAN configuration

Defining VLAN capabilities to the virtual switch


To add VLAN support to the virtual switch, include additional parameters to the DEFINE
VSWITCH command. You must configure the virtual switch as a port type of trunk and a
default VLAN ID of 100 as shown in Example 12-16. For more information about VLAN
standards and support, refer to Chapter 11, “VLAN support” on page 183.

Example 12-16 Defining the trunk port type


DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CON CONTR * ETH VLAN 100 PORTT TRUNK PORT OSACHP0D
OSACHP0E

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).

Example 12-17 Authorizing the guests


SET VSWITCH VSWTCH1 GRA LNXSU1 VLAN 101 300
SET VSWITCH VSWTCH1 GRA LNXSU2 VLAN 101 200

218 OSA-Express Implementation Guide


Adding VLAN functionality to the Linux guests
Ensure that your Linux system is at the appropriate kernel version. See “IEEE 802.1Q VLAN
module” on page 193, for details.

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).

Example 12-18 Linux guest configuration


LNXSU1:
ifconfig eth0 down
ifconfig eth0 0.0.0.0 up

vconfig add eth0 101


ifconfig eth0.101 193.16.1.41 netmask 255.255.255.0 up

vconfig add eth0 300


ifconfig eth0.300 194.16.1.41 netmask 255.255.255.0 up

LNXSU2:
ifconfig eth0 down
ifconfig eth0 0.0.0.0 up

vconfig add eth0 101


ifconfig eth0.101 193.16.1.42 netmask 255.255.255.0 up

vconfig add eth0 200


ifconfig eth0.200 192.16.1.42 netmask 255.255.255.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.

Adding VLAN support to the z/OS TCP/IP stacks


To enable VLAN support for the z/OS TCP/IP stacks, we add the VLAN ID parameter to the
OSA-Express LINK statements in the PROFILE member. Example 12-19 shows the
configuration that we use to define the VLANs.

Example 12-19 z/OS TCPI/IP VLAN configuration


SC63:
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 101

SC64:
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 200

SC65:
DEVICE OSAE200 MPCIPA
LINK E200LNK IPAQENET OSAE200 VLANID 300

Chapter 12. Layer 2 support 219


Configuring trunk mode to the Ethernet switch ports for the
OSA-Express connections
On the Ethernet switch, we define trunk mode to port 2/7, which is directly connected to the
OSA-Express port (CHPID 0D) on the z/VM machine (Example 12-20). Port 1/2 connected to
the z/OS OSA-Express port was already set to trunk mode for earlier tests.

Example 12-20 Ethernet switch configuration


SET TRUNK 2/7 ON DOT1Q 1-2005,1025-4094

Note: In a production environment, you normally configure another interface to connect to


the second OSA-Express port (0E) for redundancy purposes.

Verifying and testing the VLAN


After completing the configuration tasks, we verify the VLAN environment. Then we issue
PING commands between the Linux guests and the z/OS TCP/IP stacks to test the
configuration and Layer 2 functionality.

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.

Example 12-21 Virtual switch display with VLAN capability


q vswitch vswtch1 det
VSWITCH SYSTEM VSWTCH1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED ETHERNET Accounting: OFF
VLAN Aware Default VLAN: 0100 Default Porttype: Trunk
State: Ready
QueueStorage: 8
Portname: OSACHP0D RDEV: 2D40 Controller: VSWCTL1 VDEV: 2D40
Portname: OSACHP0E RDEV: 3D44 Controller: VSWCTL2 VDEV: 3D44 BACKUP
VSWITCH Connection:
RX Packets: 199 Discarded: 30 Errors: 0
TX Packets: 54 Discarded: 0 Errors: 0
RX Bytes: 14494 TX Bytes: 1365394
Device: 2D42 Unit: 002 Role: DATA
Unicast IP Addresses:
192.16.1.21 MAC: 00-09-6B-1A-1F-0F Remote
193.16.1.12 MAC: 00-09-6B-1A-1F-0E Remote
194.16.1.31 MAC: 00-09-6B-1A-1F-0F Remote
Adapter Owner: LNXSU1 NIC: C204 Name: UNASSIGNED
Porttype: Trunk
RX Packets: 172 Discarded: 0 Errors: 0
TX Packets: 18 Discarded: 0 Errors: 8
RX Bytes: 11286 TX Bytes: 1228
Device: C206 Unit: 002 Role: DATA
VLAN: 0101 0300
Options: Ethernet Broadcast
Unicast MAC Addresses:
02-00-00-00-00-01 IP: 194.16.1.41
Multicast MAC Addresses:
01-00-5E-00-00-01 IP: 224.0.0.1
33-33-00-00-00-01 IP: FF02::1
33-33-FF-00-00-01 IP: FF02::FF00:1
Adapter Owner: LNXSU2 NIC: C204 Name: UNASSIGNED
Porttype: Trunk
RX Packets: 10 Discarded: 0 Errors: 0

220 OSA-Express Implementation Guide


TX Packets: 13 Discarded: 0 Errors: 8
RX Bytes: 1160 TX Bytes: 1326
Device: C206 Unit: 002 Role: DATA
VLAN: 0101 0200
Options: Ethernet Broadcast
Unicast MAC Addresses:
02-00-00-00-00-02 IP: 192.16.1.42
Multicast MAC Addresses:
01-00-5E-00-00-01 IP: 224.0.0.1
33-33-00-00-00-01 IP: FF02::1
33-33-FF-00-00-02 IP: FF02::FF00:2
Ready; T=0.01/0.01 14:59:29

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.

Example 12-22 Authorized user IDs for virtual switch


q vswitch vswtch1 acc
VSWITCH SYSTEM VSWTCH1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED ETHERNET Accounting: OFF
VLAN Aware Default VLAN: 0100 Default Porttype: Trunk
State: Ready
QueueStorage: 8
Portname: OSACHP0D RDEV: 2D40 Controller: VSWCTL1 VDEV: 2D40
Portname: OSACHP0E RDEV: 3D44 Controller: VSWCTL2 VDEV: 3D44 BACKUP
Authorized userids:
LNXSU1 VLAN: 0101 0300 Porttype: Trunk
LNXSU2 VLAN: 0101 0200 Porttype: Trunk
SYSTEM VLAN: 0100 Porttype: Trunk
Ready; T=0.01/0.01 15:00:16

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.

Chapter 12. Layer 2 support 221


The configurations are displayed on the Linux guests with the ifconfig command. See
Example 12-23 for the results of LNXSU1.

Example 12-23 Interface display for LNXSU1


ifconfig
eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:01
inet6 addr: fe80::200:0:0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:172 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:8878 (8.6 Kb) TX bytes:2408 (2.3 Kb)
Interrupt:3

eth0.101 Link encap:Ethernet HWaddr 02:00:00:00:00:01


inet addr:193.16.1.41 Bcast:193.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::200:0:0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68 (68.0 b) TX bytes:78 (78.0 b)

eth0.300 Link encap:Ethernet HWaddr 02:00:00:00:00:01


inet addr:194.16.1.41 Bcast:194.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::200:0:0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:171 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8810 (8.6 Kb) TX bytes:922 (922.0 b)

lo Link encap:Local Loopback


inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

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.

222 OSA-Express Implementation Guide


12.3 z/VM Virtual Switch authorization
You can restrict the access to the virtual switch function of z/VM, using CP security or an
ESM.

Important: If an ESM is in place, the security definitions made by the SET VSWITCH
command are overridden by the ESM definitions.

Figure 12-6 shows the authorization flow of the COUPLE logic.

COUPLE
SPECIAL
NICDEF

YES NO CP
ESM
ESM ACCESS
Installed
LIST
?

Protected NO
Resource
?

YES

Authorize NO Connection NO Authorize


Connection Denied Connection
? ?

YES Connection
YES
Permitted

Figure 12-6 Authorization flow for COUPLE logic

Chapter 12. Layer 2 support 223


12.3.1 Running with CP authorization
If you do not have an ESM (such as RACF) in place, you can use the CP access authorization
function in z/VM. You can control the access to the virtual switch using the SET VSWITCH
command. Example 12-24 shows the valid syntax for this command.

Example 12-24 SET VSWITCH command syntax


--------------------------------------------!-PORTType-defporttype-! !-VLAN-defvid-!
>>--SET VSWITCH-switchname--.-GRAnt--userid-+----------------------+-+-------------+--><
! ! ! ! <------<!
! '-PORTType---ACCESS----' '-VLAN-vlanid-'
! '-TRUNK------'
!-REVoke--userid-----------------------!
! <-------------< !
! (1) !
!-PORTname----portname-----------------!
! <---------< !
! (2) !
!-RDEV--.---rdev------.----------------!
! '-NONE--------' !
!-CONnect------------------------------!
!-DISCONnect---------------------------!
!-QUEuestorage--numberM----------------!
!-CONTRoller--.-*-------.--------------!
! '-userid1-' !
!-IPTimeout--nnn-----------------------!
!-NONrouter----------------------------!
'-PRIrouter----------------------------'

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.

Example 12-25 Query of the authorization list for VSWTCH1


q vswitch vswtch1 access
vSWITCH SYSTEM VSWTCH1 Type: VSWITCH Connected: 2 Maxconn: INFINITE
PERSISTENT RESTRICTED ETHERNET Accounting: OFF
VLAN Unaware
State: Ready
QueueStorage: 8
Portname: OSACHP0D RDEV: 2D40 Controller: VSWCTL1 VDEV: 2D40
Portname: OSACHP0D RDEV: 3D44 Controller: VSWCTL2 VDEV: 3D44 BACKUP
Authorized userids:
LNXSU1 LNXSU2 LNXSU3 SYSTEM TCPIP

To grant access to a virtual switch, use the SET VSWITCH GRANT command (see
Example 12-26).

Example 12-26 Granting access to VSWTCH1


set vswitch VSWTCH1 grant lnxsu1
Command complete
Ready; T=0.01/0.01 11:32:59

224 OSA-Express Implementation Guide


If you want to prevent a user from connecting to a virtual switch, use the SET VSWITCH
REVOKE command (see Example 12-27).

Example 12-27 Revoking access to VSWTCH1


set vswitch VSWTCH1 revoke lnxsu1
Command complete
Ready; T=0.01/0.01 11:35:17

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.

12.3.2 Running with RACF authorization


In z/VM 5.1, an additional resource class, called VMLAN, is available. This class is used to
protect the COUPLE function to virtual switch and VLAN. To establish RACF security for
virtual switch, you must perform the following actions in your system:
1. Define profiles for each virtual switch.
2. Permit access to guest machines.
3. Activate the VMLAN class.

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.

Defining profiles for each virtual switch


To protect a virtual switch via RACF, it is important to define a RACF profile for each virtual
switch in your system. Example 12-28 shows our definition for the virtual switch called
VSWTCH1.

Example 12-28 Defining a RACF profile for a virtual switch


RAC RDEFINE VMLAN SYSTEM.SWTCH1 UACC(NONE)

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.

Example 12-29 Defining a RACF profile for VLAN restrictions


RAC RDEFINE VMLAN SYSTEM.VSWTCH1.0001 UACC(NONE)
Ready; T=0.01/0.01 15:18:43

Chapter 12. Layer 2 support 225


Permitting access to guest machines
To allow a virtual guest machine to establish the connection to a virtual switch, you must give
an RACF permit to the appropriate profile. In our system, the guest system wants to connect
to VSWICTH VSWTCH1. You can see the appropriate RACF command in Example 12-30.

Example 12-30 Permitting access to a virtual switch


RAC PERMIT SYSTEM.VSWTCH1 CLASS(VMLAN) ACCESS(UPDATE) ID(LNXSU1)
Ready; T=0.01/0.01 13:34:47

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.

Example 12-31 Failed access to a virtual switch


couple c204 system vswtch1
HCPNDF6011E You are not authorized to COUPLE to SYSTEM VSWTCH1
Ready(06011); T=0.01/0.01 08:25:51

If you want to revoke the user from a virtual switch, use the command shown in
Example 12-32.

Example 12-32 Revoking access to a virtual switch


RAC PERMIT SYSTEM.SW1 CLASS(VMLAN) ACCESS(UPDATE) ID(LNXSU1) DELETE
Ready; T=0.01/0.01 13:34:47

Activating the RACF VMLAN class


After you define the RACF profile for your virtual switch, you must activate the RACF class
(VMLAN). Example 12-33 shows the activation command.

Example 12-33 Activating the VMLAN class


RAC SETROPTS CLASSACT(VMLAN)

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.

226 OSA-Express Implementation Guide


13

Chapter 13. IPv6 support


Open Systems Adapter-Express2 (OSA-Express2) and Open Systems Adapter-Express
(OSA-Express) features, when running in QDIO mode, can be set up to use the IPv6 protocol.
This chapter discusses the implementation of IPv6 for z/OS V1R6, using the OSA-Express2
and OSA-Express features. It describes the basic functions of IPv6 and provides an example
configuration.

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.

13.2 Advantages offered by IPv6


IPv6 provides improved traffic management in the following areas:
򐂰 128-bit addressing
This eliminates all practical limitations on global address ability, which means that private
address space, and the network address translators (NATs) used between private intranet
and public Internet, are no longer needed.
򐂰 Simplified header formats
This allows for more efficient packet handling and reduced bandwidth cost.
򐂰 Hierarchical addressing and routing
This keeps routing tables small and backbone routing efficient by using address prefixes
rather than address classes.
򐂰 Improved support for options
This changes the way IP header options are encoded, allowing more efficient forwarding
and greater flexibility.
򐂰 Address autoconfiguration
This allows stateless IP address configuration without a configuration server. In addition,
IPv6 brings greater authentication and privacy capabilities through the definition of new
extensions. It also provides integrated Quality of Service (QoS) through a new traffic class
byte in the header.

13.3 IPv6 addressing


An IPv6 address is a 128-bit number written in colon hexadecimal notation. This scheme is
hexadecimal and consists of eight 16-bit pieces of the address. For example, xxxxxxxx
represents a single host on a single network.

Alternate notations described in RFC 2373 are acceptable, for example:


FEDC:BA98:7654:3210:FEDC:BA98:7654:321

228 OSA-Express Implementation Guide


There are three conventional forms for representing IPv6 addresses as text strings:
򐂰 The preferred form is xxxxxxxx, where the x’s indicate the hexadecimal value of the eight
16-bit pieces of the address, for example:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A

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

13.3.1 IPv6 TCP/IP Network part (prefix)


Designers have defined some address types and have left room for future definitions, since
unknown requirements may arise. RFC 2373: IP Version 6 Addressing Architecture (July
1998) defines the current addressing scheme. It defines different types of prefixes (and
therefore, address types) as follows:
򐂰 Link local address type
These are special addresses which are only valid on a link of an interface. Using this
address as destination, the packet never passes through a router. It is used for link
communications such as:
– Anyone else here on this link?
– Anyone here with a special address (for example, looking for a router)?

Chapter 13. IPv6 support 229


Consider this example:
fe80: (currently the only one in use)
fe90:
An address with this prefix is found on each IPv6-enabled interface after stateless
autoconfiguration, which is normally used.

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.

򐂰 Site local address type


These addresses are similar to the RFC 1918/Address Allocation for Private Internets in
IPv4 today. The added advantage is that everyone who uses this address type has the
ability to use the given 16 bits for a maximum number of 65536 subnetworks. This is
comparable to the 10.0.0.0/8 address in IPv4 today.
Another advantage is that, since it is possible to assign more than one address to an
interface with IPv6, you can also assign a site local address in addition to a global one.
It begins with the following prefixes:
fec0: (most commonly used)
fed0:
fee0:
򐂰 6bone test addresses
These addresses were the first global addresses defined and used for testing purposes.
They all begin with the following prefix:
3ffe:
򐂰 6to4 addresses
These addresses were designed for a special tunneling mechanism (RFC
3056/Connection of IPv6 Domains via IPv4 Clouds and RFC 2893/Transition Mechanisms
for IPv6 Hosts and Routers). They encode a given IPv4 address and a possible subnet.
They begin with the following prefix:
2002:
Consider this example, representing 192.168.1.1/5:
2002:c0a8:0101:5::1
򐂰 Assigned by a provider for hierarchical routing
These addresses are delegated to Internet service providers (ISP) and begin with the
following prefix:
2001:
򐂰 Multicast addresses
Multicast addresses are used for related services and always begin with the prefix: ffxx:.
Here, xx is the scope value.
򐂰 Anycast addresses
Anycast addresses are special addresses used to cover such items as the nearest
Domain Name System (DNS) server, nearest Dynamic Host Configuration Protocol
(DHCP) server, or similar dynamic groups. Addresses are taken out of the unicast address
space, and can be aggregated globally or site-local at the moment. The anycast
mechanism (client view) is handled by dynamic routing protocols.

230 OSA-Express Implementation Guide


Note: Anycast addresses cannot be used as source addresses. They are used only as
destination addresses.

A simple example of an anycast address is the subnet-router anycast address. Assuming


that a node has the following global assigned IPv6 address:
3ffe:ffff:100:f101:210:a4ff:fee3:9566/64
The subnet-router anycast address is created blanking the suffix (least significant 64 bits)
completely:
3ffe:ffff:100:f101::/64

13.4 Migrating to IPv6 on z/OS


For a summary of z/OS TCP/IP stack-related functions and the level of support provided in an
IPv6 network, refer to Table 13-1 on page 235. This table assists you in determining whether
a given function is applicable to IPv6.

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.

13.5 IPv6 implementation in z/OS


IPv6 support is built-in since z/OS 1.4, but is not enabled, by default. You must specify a
NETWORK statement with AF_INET6 in your BPXPRMxx member.

To support IPv4 and IPv6, we added the NETWORK statement shown in Example 13-1 to our
BPXPRMxx.

Example 13-1 BPXPRMxx NETWORK statement


NETWORK DOMAINNAME (AF_INET6)
DOMAINNUMBER(19)
MAXSOCKETS(2000)
TYPE(CINET)

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.

Chapter 13. IPv6 support 231


Note: IPv6 is supported by OSA-Express2 and OSA-Express features running in QDIO
mode, with the LIC level 3 or later (OSA-Express). For OSA-Express2, use the MCL
provided by IBM when OSA-Express2 becomes available in January 2005.

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).

Example 13-2 TRLE for OSA-Express 1000BASE-T


OSABT09 VBUILD TYPE=TRL
TRLE2180 TRLE LNCTL=MPC,
READ=2180,
WRITE=2181,
DATAPATH=2182,
PORTNAME=OSA2180,
MPCLEVEL=QDIO

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.

We used the following syntax:


INTERFace interfname DEFINE linktype PORTNAME portname IPADDR ipaddr
Note the following explanation:
򐂰 interfname: Specifies a name for the interface with no more than 16 characters in length
򐂰 linktype: Must be IPAQENET6; the only DLC that currently supports IPv6
򐂰 portname: Is specified in the VTAM TRLE definition for the QDIO interface
򐂰 ipaddr: Optional for link type IPAQENET6
If not specified, TCP/IP enables autoconfiguration for the interface. If used, one or more
prefixes or full IPv6 addresses can be specified.

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).

232 OSA-Express Implementation Guide


Example 13-3 TCP/IP profile for SC64 to support IPv4 and IPv6
DEVICE OSA2180 MPCIPA PRIRouter
LINK SC642180LINK IPAQENET OSA2180
INTERFACE L2180V6 DEFINE IPAQENET6 PORTNAME OSA2180
IPADDR FEC0:0:0:1::3302
FEC0:0:0:1001::3302

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

Figure 13-1 OSA-Express status and code level

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

Chapter 13. IPv6 support 233


Figure 13-2 shows the output of NETSTAT DEV, with the IPv6 interface shown as READY.

INTFNAME: L2180V6 INTFTYPE: IPAQENET6 INTFSTATUS: READY


NETNUM: 0 QUESIZE: 0 SPEED: 0000000100
BYTESIN: 0 BYTESOUT: 1304
MACADDRESS: 0006296CA5BC
DUPADDRDET: 1
CFGROUTER: NON ACTROUTER: NON
CFGMTU: NONE ACTMTU: 1492
MULTICAST SPECIFIC:
MULTICAST CAPABILITY: YES

Figure 13-2 NETSTAT DEV

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

Figure 13-3 Query CHPID via OSA/SF

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

13.6 IPv6 function summary


Table 13-1 summarizes the z/OS TCP/IP stack-related functions and the level of support,
based on the current release of Communications Server for z/OS V1R6, provided in an IPv6
network. You can use this table to determine whether a given function is applicable to IPv6.

234 OSA-Express Implementation Guide


Table 13-1 z/OS TCP/IP stack function support
z/OS TCP/IP stack IPv4 IPv6 Comments
function support support

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 IP addressing support

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.

Sysplex support Y Y IP Sysplex functions:


򐂰 Dynamic VIPA
򐂰 Sysplex Distributor
򐂰 SourceVIPA
򐂰 SNMP MIBs for dynamic VIPA
򐂰 SysplexPorts

IP routing functions

Dynamic routing - OSPF Y Y IPv6-related changes were made to OMPROUTE:


and RIP 򐂰 RIPng support with Communications Server for z/OS V1R5
򐂰 OSPFv3 support with Communications Server for z/OS
V1R6

Dynamic routing - Auto N Y


Configuration

Static route configuration Y Y Related configuration statements:


using BEGINROUTES BEGINROUTES
statement

Static route configuration Y N Related configuration statements:


using GATEWAY statement GATEWAY

Multipath routing groups Y Y Related configuration statements:


IPCONFIG
IPCONFIG6

Miscellaneous stack functions

Path MTU discovery Y Y Path MTU discovery is mandatory in IPv6.


Related configuration statements:
IPCONFIG
IPCONFIG6

Link-layer address Y Y In IPv4, this is performed using Address Resolution Protocol


resolution (ARP). In IPv6, this is performed using the neighbor discovery
protocol. Related configuration statements:
DEVICE and LINK (LAN Channel Station and OSA devices)
INTERFACE (IPAQENET6 interfaces)

Chapter 13. IPv6 support 235


z/OS TCP/IP stack IPv4 IPv6 Comments
function support support

ARP/Neighbor cache Y Y Use the V TCPIP,PURGECACHE command. For information, see


PURGE capability z/OS V1R6.0 Communications Server: IP Systems
Administration Commands, SC31-8781.

Datagram forwarding Y Y Related configuration statements:


enable/disable IPCONFIG
IPCONFIG6

Transport-layer functions

Fast response cache Y N


accelerator

Enterprise extender Y N

Server-BIND control Y Y Related configuration statement:


PORT

UDP Checksum Y N UDP checksum is required when operating over IPv6.


disablement option Related configuration statement:
UDPCONFIG

Network management and accounting functions

SNMP Y Y SNMP applications can, in z/OS V1R5, communicate over an


IPv6 connection. IPv6 management data includes added support
for the version-neutral (both IPv4 and IPv6) MIB data in the
following new, IETF Internet drafts:
򐂰 IP-MIB: draft-ietf-ipv6-rfc2011-update-01.txt
򐂰 IP-FORWARD-MIB: draft-ietf-ipv6-rfc2096-update-02.txt
򐂰 TCP-MIB: draft-ietf-ipv6-rfc2012-update-01.txt

Policy-based networking Y Y IPv6 support in Policy Agent in z/OS V1R5:


򐂰 IPv6 source and destination IP addresses are allowed to be
specified in policy rules (LDAP and configuration files).
򐂰 Interfaces in policy rules and subnet priority TOS masks are
allowed to be specified by name.
– Allowed for both IPv4 and IPv6 interfaces
– IPv6 interfaces must be specified by name
򐂰 “TOS” in policy definitions means IPv4 Type of Service or
IPv6 Traffic Class.

SMF SMFCONFIG Y Y New Type 119 records are used to collect IPv6-related
information. Related configuration statements:
SMFCONFIG

IPSec Y N Related configuration statement:


IPCONFIG

IP filtering Y N

Network access control Y N Related configuration statement:


NETACCESS

Stack and port access Y Y Related configuration statement:


control PORT
DELETE

Intrusion detection services Y N

236 OSA-Express Implementation Guide


A

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.

Table A-1 z/OS TCP/IP operator commands

Command Description

D U,,,dddda,nnn Gives the status of the device or devices

D U,,ALLOC,dddd,nnnb Shows to whom the device or devices are allocated

D M=DEV(dddd) Gives the status of the paths defined to a device

D M=CHP Gives the status and type of all CHPIDs defined to


the z/OS

D M=CHP(ccc) Gives the status of the path to the defined devices

D A,L List of the jobs running in the system

D IOS,MIH Displays MIH values for all devices

SETIOS MIH,DEV=dddd,TIME=mm:ss Sets the MIH time for a specified device

V dddd-dddd,ONLINE Varies a device online

V dddd-dddd,OFFLINE Varies a device offline

CF CHP(cc),ONLINE Configures a CHPID online

CF CHP(cc),OFFLINE Configures a CHPID offline

D TCPIP Lists TCP/IP stacks that have started since the last
initial program load (IPL) and stack status

D TCPIP,tcpipstack,NETSTAT,ARP Displays contents of Address Resolution Protocol


(ARP) cache for the TCP/IP stack

D TCPIP,tcpipstack,NETSTAT,DEV Status of a device or devices, or interface or


interfaces, defined in TCP/IP stack profile

D TCPIP,tcpipstack,NETSTAT,HOME Displays the home IP address or addresses defined


in the TCP/IP stack profile

D TCPIP,tcpipstack,NETSTAT,ND Displays the contents of the IPv6 neighbor cache

D TCPIP,tcpipstack,NETSTAT,ROUTE Displays the routing information for the TCP/IP stack

V TCPIP,tcpipstack,PURGECACHE,linkname Purges ARP cache for the specified adapter


(introduced with z/OS 1.4) (linkname or intfname (IPv6) from NETSTAT,DEV)

V TCPIP,tcpipstack,START,tcpipdev Starts a device or interface (IPv6) defined in a


TCP/IP stack

V TCPIP,tcpipstack,STOP,tcpipdev Stops a device or interface (IPv6) defined in a


TCP/IP stack
a. dddd indicates the device number.
b. nnn indicates the number of devices to be displayed.
c. cc indicates the CHPID number.

238 OSA-Express Implementation Guide


Table A-2 TCP/IP TSO commands

Command Description

NETSTAT ? Displays Netstat options

NETSTAT ARP ALL Displays ARP cache

NETSTAT DEV Displays the TCP/IP devices and links

NETSTAT HOME Displays the TCP/IP Home IP addresses

NETSTAT GATE Displays the TCP/IP Gateway addresses

PING ipaddress Performs one PING to specified address

TRACERTE ipaddress Traces router hops to a specified address

OBEYFILE Executes selected TCP/IP profile statements

Table A-3 VTAM commands

Command Description

D NET,VTAMOPTS Displays the current VTAM start options

F vtamname,VTAMOPTS, Modifies the current VTAM options (vtamname is the STC


optionname=value name; optionname is from VTAMOPTS.)

D NET,MAJNODES Displays the VTAM major nodes

D NET,id=xxxxxxx,E Displays information about a specified ID (for example, a


Line, PU, or LU)

D NET,TRL Displays the list of TRLEs

D NET,TRL,TRLE=trlename Displays the status of a TRLE

V NET,ID=ISTTRL,ACT,UPDATE=ALL Deletes inactive TRLEs from the TRL list

V NET,ID=mnodename,ACT Activates a major node

V NET,ID=mnodename,INACT Deactivates a major node

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.

Appendix A. Commands 239


z/VM commands
For information about z/VM commands, refer to z/VM CP Command and Utility Reference,
SC24-6008.

Table A-4 z/VM TCP/IP operations commands

Command Description

Q MITIME Displays MIH times for devices

Q OSA ACTIVE|ALL Displays the status of Open Systems Adapter (OSA) devices

Q rdev|rdev-rdev Displays the status of real devices

Q PATHS rdev|rdev-rdev Displays the path status to real devices (PIM, PAM, LPM)

Q CHPID cc Displays the real CHPID status

SET MITIME rdev|rdev-rdev mm:ss Sets the MIH time for device or devices

VARY OFF|ON rdev|rdev-rdev Varies devices off or online

VARY OFF|ON PATH cc FROM|TO Changes the status of a path to devices


rdev|rdev-rdev

VARY OFF|ON CHPID cc Configures a CHPID off or on to both hardware and software

Table A-5 z/VM TCP/IP commands

Command Description

NETSTAT ? Displays Netstat options

NETSTAT ARP Displays the ARP cache

NETSTAT DEV Displays the TCP/IP devices and links

NETSTAT HOME Displays the TCP/IP Home IP addresses

NETSTAT GATE Displays the TCP/IP Gateway addresses

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)

PING ipaddress Performs one PING to a specified address

TRACERTE ipaddress Traces router hops to a specified address

OBEYFILE Executes selected TCP/IP profile statements

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.

240 OSA-Express Implementation Guide


Table A-6 z/VM Virtual Switch commands

Command Description

DEFINE VSWITCH Defines the virtual switch and attributes

DEFINE NIC Defines the simulated network interface card (NIC)

COUPLE Helps to connect the NIC to the virtual switch

SET VSWITCH Controls the attributes of an existing virtual switch

QUERY CONTROLLER Displays the controller service machines

QUERY VSWITCH Displays information about the virtual switch

QUERY VSWITCH DETAILS Displays detail information about the virtual switch

QUERY VSWITCH name ACCESS Displays authorized user IDs

QUERY VMLAN Displays system-wide MAC addresses

Defining and coupling a NIC using CP commands

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.

To create a virtual NIC, use the following command syntax:


DEFINE NIC vdev [ operands ]

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.

Table A-7 Operands for the DEFINE NIC command


Operands Description

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.

Appendix A. Commands 241


Operands Description

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.

Table A-8 Operands for the Couple command


Operands Description

vdev This is the base address of the network adapter.

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”

Linux on System z9 and zSeries TCP/IP commands


When using the Linux commands listed in Table A-9, enter them in lowercase, as shown.

Table A-9 TCP/IP commands

Command Description

arp Displays ARP cache; use -? for options

dmesg imore Display device assignments (and more) at kernel initialization

netstat -i Displays an interface table

netstat -r Displays routes

ifconfig Displays network interfaces (LO, eth0, tr0, and so on)

ifconfig interface upidown Starts or stops a network interface

ping ipaddress Performs one PING to a specified address

route Displays routes

traceroute ipaddress Traces router hops to a specified address

242 OSA-Express Implementation Guide


B

Appendix B. HMC and SE tasks for


OSA-Express
This appendix discusses the tools that you can use from a Hardware Management Console
(HMC) or the Support Element (SE) of a System z9 or zSeries server. First it describes the
advanced facilities for the Open Systems Adapter-Express (OSA-Express) channels. The
advanced facilities are now available directly on the HMC as a task under CPC Operational
Customization. Then it offers guidance for CHPID Off/On.

© 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.

򐂰 Set Trace Buffer


򐂰 Read Trace Buffer
򐂰 Export Trace/Dump file to diskette
򐂰 Card-specific advanced facilities, with the following subdivision:
– Enable or disable ports
– Query port status
– Run port diagnostics
– View port parameter
– Display or alter MAC address
– Set Ethernet mode (only for FENET/1000BASE-T)

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).

Figure B-1 Console logon

Then follow these steps to start the individual functions:


1. Open the CPC group work area.

244 OSA-Express Implementation Guide


2. In the Hardware Management Console Workplace window (Figure B-2), switch to CPC
Operational Customization in the Task Area. Select the appropriate CPC and drag and
drop it to the OSA Advanced Facilities Task.

Figure B-2 HMC Workplace

3. In the Single Object Selection window (Figure B-3), you are prompted to select the
appropriate CPC. Then click OK.

Figure B-3 Single Object Selection

Appendix B. HMC and SE tasks for OSA-Express 245


4. The OSA Advanced Facilities window (Figure B-4) opens in the HMC console. Select the
OSA CHPID that you want to work with and click OK.

Figure B-4 HMC OSA Advanced Facilities window

The Standard Channel Advanced Facilities window (Figure B-5) opens.

Figure B-5 Standard Channel Advanced Facilities window

246 OSA-Express Implementation Guide


Trace functions for OSA-Express
These trace functions are used to troubleshoot under the guidance of IBM Product
Engineering.

Setting Trace Mask on the OSA-Express Card


Follow these steps:
1. In the Standard Channel Advanced Facilities window, select Card Trace/Log/Dump
facilities.
2. In the Card Trace/Log/Dump Facilities window (Figure B-6), select Display and or alter
trace mask and click OK.

Figure B-6 Card trace/Log/Dump Facilities

Appendix B. HMC and SE tasks for OSA-Express 247


With guidance from IBM, complete the fields shown in the Display and/or alter trace mask
window (Figure B-7).

Figure B-7 Display and/or alter trace mask window

Read Trace Buffer on the OSA-Express Card


Follow these steps:
1. In the Standard Channel Advanced Facilities window (Figure B-5), select Card
Trace/Log/Dump facilities.
2. In the Card Trace/Log/Dump Facilities window (Figure B-8), select Read Trace Buffer and
click OK.

Figure B-8 Read trace buffer confirmation window

248 OSA-Express Implementation Guide


The Read Trace Buffer function collects all data necessary for troubleshooting, and writes a
file on the HMC when the command is completed. Then you see the Read trace buffer
window as shown in Figure B-9.

Figure B-9 Read trace buffer completed

Hardware functions for OSA-Express


In the Standard Channel Advanced Facilities window, select Card specific advanced
facilities.... The Advanced facilities window opens as shown in Figure B-10. The following
sections explain the options on this window further.

Figure B-10 Card-specific advanced facilities

Appendix B. HMC and SE tasks for OSA-Express 249


Enable or disable ports on OSA-Express Cards
In the Advanced facilities window, select Enable or disable ports and click OK. The Enable
or disable ports window (Figure B-11) opens.

Note: Enabling or disabling the port is also possible with an OSA/SF function.

Figure B-11 Enable or disable ports window

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).

250 OSA-Express Implementation Guide


Query port status on an OSA-Express Card
In the Advanced facilities window, select Query port status and click OK. The Query port
status window (Figure B-12 on page 251) opens. To exit the window, simply click OK.

Figure B-12 Query port status window

Run diagnostics on an OSA-Express Card


In the Advanced facilities window (see Figure B-10 on page 249), select Run port
diagnostics and click OK.

Note: You can use port diagnostics only if the port is disabled.

Appendix B. HMC and SE tasks for OSA-Express 251


View port parameters on an OSA-Express Card
In the Advanced facilities window (see Figure B-10 on page 249), select View port
parameters and click OK. The View port parameters window (Figure B-13 on page 252)
opens. You can use the scroll buttons of the window to view all port parameters. Then to exit
the window, click OK.

Figure B-13 View port parameters window

252 OSA-Express Implementation Guide


Display or alter MAC address on an OSA-Express Card
Follow these steps:
1. In the Advanced facilities window, select Display or alter MAC address and click OK.
2. The Display or alter MAC address window (Figure B-14) opens. Change the MAC
address, and click Apply to activate it.
To exit the window without any changes, click Cancel.

Figure B-14 Display or alter MAC address window

Appendix B. HMC and SE tasks for OSA-Express 253


Settings for speed and mode on an OSA-Express 1000BASE-T card
Follow these steps:
1. In the Advanced facilities window, select Set card mode and click OK.
2. In the Set card mode window (Figure B-15), set or change the settings that are shown.
Then, click Apply to make the new settings active.
To exit the window without any changes, click Cancel.

Note: The settings made here override the capability of the OSA-Express FENET auto
negotiation facility.

Figure B-15 Ethernet Speed/Mode settings window

254 OSA-Express Implementation Guide


OSA reset to defaults
When you directly log on to the Support Element of an S/390 system, the OSA Reset to
defaults function is displayed, as shown in Figure B-16. This functions enables you to reset all
your customized entries in the OSA-Express adapter to the default settings, including the
OSA Address Table (OAT).

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.

Figure B-16 Advanced Facilities window at the Support Element

Appendix B. HMC and SE tasks for OSA-Express 255


View code level
The view code level task queries the OSA-ICC microcode level currently active in an
OSA-Express feature. The code level is a four digit number that relates to a specific
microcode engineering change (EC) and patch (MCL) level.

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).

Figure B-17 View code level

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.

Configuring OSA-Express channels on/off


With the new design of the OSA-Express adapters, there is no longer a need to configure the
OSA-Express CHPID offline and online to activate an OAT after changing it. However, for
recovery reasons, it still may be necessary. Normally, you use z/OS commands on the
operator console to configure a channel off or on.

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.

256 OSA-Express Implementation Guide


Logging on to the Support Element
To gain access to all channel functions, start a session from the HMC to the SE as follows:
1. From the Defined CPCs Work Area on the HMC, complete these steps:
a. Select the appropriate CPC Object and drag and drop it onto the Single Object
Operations icon in the CPC Recovery task list.
b. In the Single Object Selection window (Figure B-18), select the CPC involved, and then
click OK.

Figure B-18 Single Object Selection

c. When the confirmation window opens, click OK.

Appendix B. HMC and SE tasks for OSA-Express 257


2. After a short time, the HMC displays the Support Element Workplace, with the Group
Work Area, the Views Area, and the Daily Task Area. Figure B-19 shows an example of
that display. The S/390 visible in the background of the workplace is the indicator for
working on the SE.
In the Groups Work Area, double-click CPC, and the CPC Work Area is displayed, as
shown in the lower left side of Figure B-19.

Figure B-19 Support Element CPC Work Area

258 OSA-Express Implementation Guide


CHPID Configure on/off
The OSA-Express CHPID is configured on or off by doing the following:
1. In the CPC Work Area, right-click the CPC object and select CHPIDs.
2. The CPC CHPIDs Work Area is displayed (see Figure B-20 on page 259). Use the scroll
bar to display the required CHPID object.
Open the CHPID Operations Task Area in one of two ways:
– Use the rotate arrow push buttons under the task list to rotate through other task lists
until the CHPID Operations task list is displayed.
– Right-click anywhere in the workplace and select Task List →CHPID Operations.
These views are shown in Figure B-20, with the Channel Operations panel shown on
the right.

Figure B-20 Support Element CHPIDs Work Area

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.

Complete the following steps:


a. Read the warning information regarding configuring channels from the Support
Element function rather than from an available operating system.

Appendix B. HMC and SE tasks for OSA-Express 259


Toggle the CHPID if you cannot configure it offline and online from the operating
system in each of the LPARs to which the CHPID is assigned.
• If the channel should be set off to all partitions, use Toggle all off.
• If the channel should be set on to all partitions, use Toggle all on.
• If the channel should not be changed in all partitions, then select the affected
partitions. Clicking Toggle changes the desired state of the channel.

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.

Figure B-21 Configure On/Off window

5. The Configure On/Off Progress window briefly displays the message “In progress.” When
the message changes to “Complete”, click OK.

260 OSA-Express Implementation Guide


Logging off from the Support Element
When the work with the channels is finished, close the Support Element session as explained
here:
1. In the Views area (Figure B-20), double-click Console Actions.
2. The Console Action Work Area opens as shown in Figure B-22. Double-click Log off to
end the Support Element session.

Figure B-22 Logging off the Support Element

Appendix B. HMC and SE tasks for OSA-Express 261


262 OSA-Express Implementation Guide
C

Appendix C. RMF in an OSA-Express


environment
Resource Measurement Facility (RMF) measures and reports on the performance and
availability of such system resources as processors, channel paths, devices, and storage.
RMF has extended the supported channel types to include the Open Systems
Adapter-Express (OSA-Express). It also provides statistics about the bus utilization and the
transfer rate for both the read and write operations in the Channel Activity Report.

© 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.

RMF Monitor II output


The new support for OSA-Express CHPIDs (device types OSD and OSE) can be found in an
RMF Monitor report called the Channel Activity Report. Note that RMF must be defined with
the option DEVICE(COMM) in member ERBRMFxx from SYS1.PARMLIB.

For more information, refer to Resource Measurement Facility User’s Guide, SC28-1949.

The Channel Activity Report


To view the OSA-Express channel activity, complete these steps:
1. In the ISPF Primary Option Menu, enter 6 (Command).
2. In the ISPF Command Shell, enter RMFMON 2, and then press Enter.
3. In the RMF Display Menu, press F4.

264 OSA-Express Implementation Guide


Figure C-1 shows an example of the Channel Activity Report.

16:42:43 CHANNEL UTILIZATION(%) READ(B/S) WRITE(B/S) MSG MSG SEND RECV


ID NO G TYPE S PART TOT BUS PART TOT PART TOT RATE SIZE FAIL FAIL
08 OSD Y 0.0 12.1 16.0 0 21K 0 118K
09 OSD Y 6.8 11.9 15.6 0 0 0 0
0A OSD Y 0.0 3.6 15.8 0 3K 0 68K
0B OSD Y 7.9 11.9 13.0 0 0 0 0
0C OSD Y 0.0 0.0 8.6 0 0 0 0
0D OSD Y 0.0 0.0 8.6 0 0 0 0
0E OSE Y 0.0 1.4 12.4 0 0 0 0
10 OSD Y 0.8 3.5 15.6 0 717 0 0
11 OSD Y 0.0 12.4 16.3 0 127K 0 24K
12 OSD Y 0.0 3.5 15.6 0 0 0 0
13 OSE Y 0.0 0.4 10.8 0 0 0 0
14 OSD Y 0.0 0.0 8.6 0 0 0 0
15 OSD Y 0.0 0.0 8.6 0 0 0 0
16 OSD Y 0.0 3.5 15.6 0 0 0 0
17 OSE Y 0.0 0.4 10.8 0 0 0 0
18 OSE Y 0.0 0.4 10.8 0 0 0 0
19 OSD Y 0.0 3.1 15.6 0 0 0 0

Figure C-1 Channel Activity Report

4. To exit the report, enter QUIT.

For more information, see z/OS Resource Measurement Facility Report Analysis,
SC33-7991.

Appendix C. RMF in an OSA-Express environment 265


266 OSA-Express Implementation Guide
D

Appendix D. Using the OSA/SF REXX


interface
This appendix describes the steps required to configure an OSA-Express feature using the
TSO REXX interface for the non-QDIO modes.

© 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).

To build the OSA-Express feature configuration, use these steps:


1. Create two skeleton definitions:
– One skeleton definition for the configuration file
– One skeleton definition with the OAT entries
To ensure the correct format of the files, use the GET Configuration File and the GET OSA
Address Table commands to retrieve the current files into sequential data sets, or copy the
skeletons from IOA.SIOASAMP. Note the following points:
– The sample asynchronous transfer mode (ATM) configuration file is named IOAATME.
– The sample IOAFENET is used to configure Fast Ethernet and 1000BASE-T cards.
– The sample token-ring configuration file is named IOATR.
– The sample Gigabit configuration files is named IOAGIGA.
There are also two sample OAT data sets:
– IOAOSHRS (the OAT template for SNA sharing)
– IOAOSHRT (the OAT template for TCP/IP sharing)
2. Copy the skeleton definitions to work data sets.
3. Update, delete, or create the configuration and OAT entries as required.
4. Use the Configure OSA CHPID command to activate your changes.

Creating the OSA-Express configuration file


Follow these steps:
1. Create a skeleton configuration file:
– Example D-4 on page 272 shows a FENET/1000BASE-T configuration file.
– Example D-5 on page 273 shows a token-ring configuration file.
– Example D-6 on page 274 shows an ATM configuration.
A detailed description of all parameters is included in the example configuration files.
2. Update the skeleton with your configuration requirements.

Creating the OSA-Express OAT file


Complete the following steps:
1. Create a skeleton OAT by using the OSA/SF GET_OAT command or by using the sample
OAT file from the IOA.SIOASAMP data set.
The names of the sample OAT files are:
– IOAOSHRA: TCP/IP SNA MPC shared port
– IOAOSHRT: TCP/IP shared port (Example D-1)
– IOAOSHRS: SNA shared port (Example D-2)
– IOAENTR: Default OAT with two ports

268 OSA-Express Implementation Guide


Note: If you retrieve the OAT from the OSA card, the OAT obtained may contain several
unneeded entries, especially if it is the default OAT.

Example: D-1 Sample TCP/IP OAT file


This OAT template is a sample for setting up TCP/IP passthru mode
with port sharing between 2 Images running on a z990 which supports
logical channel subsytems.
Image 0.5 and Image 0.7 are sharing port 0.
Each OAT entry has more than one IP address associated with it.
************************************************************************
* UA(Dev) Mode Port Entry specific information Entry Valid
************************************************************************
Image 0.5
00(1800)* passthru 00 Pri 105.001.005.005 SIU ALL
105.001.005.015
************************************************************************
Image 0.7
00(1800)* passthru 00 Sec 107.001.007.007 SIU ALL
107.001.005.017

Example: D-2 Sample SNA OAT file


This OAT template is a sample for setting up SNA mode with port
with port sharing between 2 Images running on a z990 which supports
logical channel subsytems.
Image 0.5 and Image 0.7 are sharing port 0.
************************************************************************
* UA(Dev) Mode Port Entry specific information Entry Valid
************************************************************************
Image 0.5
0A(180A) SNA 00 SIU ALL
Image 0.7
0A(180A) SNA 00 SIU ALL

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.

Appendix D. Using the OSA/SF REXX interface 269


– Mode: For TCP/IP Passthru, the port mode is passthru. For SNA mode, the port mode
is sna.
– Port: Enter the port number you want associated with this unit address.

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.

Example: D-3 Sample OAT, shared port


This OAT template is a sample for setting up TCP/IP and SNA modes
with port sharing between 2 Images running on a z990 which supports
logical channel subsytems.
Image 0.5 and Image 0.7 are sharing port 0.
************************************************************************
* UA(Dev) Mode Port Entry specific information Entry Valid
************************************************************************
Image 0.5
00(1800)* passthru 00 Pri 105.001.005.005 SIU ALL
105.001.005.015
105.001.005.025
105.001.005.035
02(1802)* passthru 00 No 100.100.100.100 SIU ALL
0A(180A) SNA 00 SIU ALL
************************************************************************
Image 0.7
00(1900)* passthru 00 No 107.001.075.075 SIU ALL
107.100.075.085
02(1902)* passthru 00 Sec 107.005.035.035 SIU ALL
0A(180A) SNA 00 SIU ALL

270 OSA-Express Implementation Guide


Activating the OSA configuration
OSA configuration changes are disruptive, so all applications running via OSA devices must
not have active sessions. Also, the OSAD device must be online to the host on which OSA/SF
is running.
1. Vary all OSA devices offline (except the OSAD device), or at least those devices that have
active sessions for this OSA feature, to all partitions that are sharing this OSA feature.
2. Log on to TSO from the system on which OSA/SF is running.

Note: The TSO user ID must be set up to use the OSA/SF TSO interface.

3. Enter the IOACMD command.


4. You see the choices shown in Figure D-1. Select option 2 to load a configuration.

IOACMD: Enter the command to be issued

IOACMD: 0 - End IOACMD


IOACMD: 1 - Clear Debug
IOACMD: 2 - Configure OSA CHPID
IOACMD: 3 - Convert OAT
IOACMD: 4 - Get Configuration File
IOACMD: 5 - Get Debug
IOACMD: 6 - Get OSA Address Table
IOACMD: 7 - Install
IOACMD: 8 - Put OSA Address Table (OSA-2 only)
IOACMD: 9 - Query
IOACMD:10 - Set Parameter
IOACMD:11 - Shutdown (VM only)
IOACMD:12 - Start Managing
IOACMD:13 - Stop Managing
IOACMD:14 - Synchronize (OSA-2 only)

Figure D-1 IOACMD menu

5. You now see the list shown in Figure D-2.

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

Figure D-2 IOACMD configure list

6. You are prompted through the configuration steps.


a. Enter the OSA-Express feature type.
b. Enter the OSA CHPID number to which the CONFIG and OAT is to be downloaded.
c. Respond to the prompt: Is CHPID nn of type OSD (QDIO)? (Y./N).
d. Enter the fully qualified data set name containing the CONFIG definitions.

Appendix D. Using the OSA/SF REXX interface 271


e. Enter the fully qualified data set name containing the OAT definitions.
f. Enter the activation option, as shown in Figure D-3. Note the following points:
• Activate creates the OAT, updates the index data set, and downloads the OAT.
• Activate, no Install creates the OAT and updates the index data set, but does
not download the OAT. IOACMD INSTALL must be done at a later time.
g. Enter Y to confirm the download, because it is disruptive to the OSA-Express feature.

IOACMD: 0 - Quit

IOACMD: 1 - Activate
IOACMD: Sets up all the files and transfers the data to the CHPID

IOACMD: 2 - Activate, no Install


IOACMD: Only sets up the files, but does not transfer them to the CHPID
IOACMD: You must issue the Install command at a later time
IOACMD: to complete the activation

Figure D-3 IOACMD Activation options

7. IOACMD CONFIG_OSA performs the following functions:


– The OAT information from the specified data set is reformatted and saved on the z/OS
host, in the OSA configuration file. The OSA/SF configuration file (also defined in the
startup profile) is updated to point to any code files that are required to support this
configuration, and that are downloaded to the feature during any OSA/SF install action.
– An OSA/SF install action is done to download the OAT contained in the OATFILE data
set.

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.

Example: D-4 Sample Fast Ethernet configuration file


/***********************************************************************
/* Input for configuring an OSA-Express
/* Fast Ethernet or 1000Base-T Ethernet CHPID
/*======================================================================
/* Fast Ethernet parameters
/*======================================================================
fenet.0.1 = config file name /* Configuration name (32-char max)
fenet.0.2 = user data /* User data (32-char max)
fenet.0.3 = portname /* Port name (8-char max)
/* Data ignored for OSD CHPIDs
fenet.0.4 = 000000000000 /* Local MAC address (12 hex digits)
fenet.0.5 = auto /* Speed/mode
/* Auto - auto negotiate
/* 10H - 10 Mb, half duplex
/* 10F - 10 Mb, full duplex
/* 100H - 100 Mb, half duplex
/* 100F - 100 Mb, full duplex
/* 1000F - 1000 Mb, full duplex
/* (only valid for 1000Base-T)
/*======================================================================
fenet.0.6.1 = 000000000000 /* Group address 1 (12 hex digits)

272 OSA-Express Implementation Guide


fenet.0.6.5 = 000000000000 /* Group address 5
/*======================================================================
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)

Example: D-5 Sample token-ring configuration file


/***********************************************************************
/* Input file for configuring an OSA-Express Token Ring CHPID
/*======================================================================
/* Token ring parameters
/*======================================================================
tr.0.1 = config file name /* Configuration name (32-char max)
tr.0.2 = user data /* User data (32-char max)
tr.0.3 = portname /* Port name (8-char max)
/* Data ignored for OSD CHPIDs
tr.0.4 = 000000000000 /* Local MAC address (12 hex digits)
tr.0.5 = 00000000 /* Functional address (8 hex digits)
tr.0.6 = Auto /* Speed/mode
/* Auto - Auto sense from the ring
/* 4H - 4 Mbs Half duplex
/* 4F - 4 Mbs Full duplex
/* 16H - 16 Mbs Half duplex
/* 16F - 16 Mbs Full duplex
/* 100 - 100 Mbs Full duplex
/*======================================================================
tr.0.7.1 = 000000000000 /* Group address 1 (12 hex digits)
tr.0.7.5 = 000000000000 /* Group address 5
/*======================================================================
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)

Appendix D. Using the OSA/SF REXX interface 273


Example: D-6 Sample ATM configuration file
/***********************************************************************
/* Input file for configuring an OSA-Express ATM CHPID
/*======================================================================
/* Parameters for physical port 0
/*======================================================================
phy.0.1 = config file name /* Configuration name (32-char max)
phy.0.2 = port description /* Port description (16-char max)
phy.0.3 = Port name /* Port name (8-char max)
phy.0.4 = 000000000000 /* Local End System ID (12 hex digits)
phy.0.5 = auto /* Port UNI version (AUTO, 30 or 31)
phy.0.6 = 0 /* Control plane use
/* 0 - ILMI & SVC enabled
/* 3 - ILMI & SVC disabled
phy.0.7 = 0 /* Transmit clock source
/* 0 - OSA generated
/* 1 - Network generated
phy.0.8 = 0 /* Physical layer type
/* 0 - Sonet
/* 1 - SDH
phy.0.9 = 0.0.0.0 /* TCP/IP instance IP address
phy.0.10 = 1 /* Bandwidth allocation
/* 1 - Best effort only
/* 2 - Reserve bandwidth
/* & best effort
/* 3 - Reserved bandwidth
/*======================================================================
/* Parameters for Native port 0 - Valid only for OSE (non-QDIO) CHPIDs
/*======================================================================
nat.0.1 = configuration name /* Configuration name (32-char max)
nat.0.2 = Yes /* Enable LAN traffic (Yes, No)
/*======================================================================
/* PVC entry 1 for port 0 starts here
/*======================================================================
pvc.0.1.1 = PVC name /* PVC name (8-char max)
pvc.0.1.2 = 353207 /* Forward peak cell rate (0-353207)
pvc.0.1.3 = 353207 /* Backward peak cell rate(0-353207)
pvc.0.1.4 = 0 /* VPI for this PVC entry (0-255)
pvc.0.1.5 = 35 /* VCI for this PVC entry (32-65535)
/*======================================================================
pvc.0.1.6 = 8448 /* Forward Max PDU size (64-9188)
pvc.0.1.7 = 8448 /* Backward Max PDU size(64-9188)
/*======================================================================
pvc.0.1.8 = 0 /* Reserved bandwidth
/* 0 - Use defaults
/* 1 - Specify parameters 9-12
/*======================================================================
pvc.0.1.9 = 353207 /* Forward sustain cell rate (0-353207)
pvc.0.1.10= 353207 /* Backward sustain cell rate(0-353207)
pvc.0.1.11= 353207 /* Forward cell burst rate (0-353207)
pvc.0.1.12= 353207 /* Backward cell burst rate(0-353207)
/*======================================================================
emul.0.1 = configuration name /* Configuration name (32-char max)
emul.0.2 = Yes /* Enable LAN traffic (Yes, No)
emul.0.3 = 1 /* Emulated port type
/* 1 - Ethernet
/* 2 - Token ring
emul.0.4 = user data /* User data (32-char max)
emul.0.5 = ELAN name /* ELAN name (32-char max)
emul.0.6 = 000000000000 /* Local MAC address (12 hex digits)

274 OSA-Express Implementation Guide


emul.0.7 = 155.0 /* Best effort peak rate (1-155)
/* in 0.1 increments
emul.0.8 = 0 /* IBM Enhanced mode
/* 0 - drop direct connect
/* Not 0 - keep connections
/*======================================================================
emul.0.9 = 1516 /* Max LAN frame size
emul.0.10 = 1 /* LEC auto configure
/* 0 - disable auto config
/* parms 12-21 are required
/* 1 - enable auto config
/* parms 12-21 are ignored
emul.0.11 = 10 /* Control timeout (10-300)
/*======================================================================
emul.0.12 = 1200 /* VCC timeout
emul.0.13 = 300 /* Aging time (10-300)
/* LES ATM address (40 hex digits)
emul.0.14 = 1122334455667788990011223344556677889900
emul.0.15 = 10 /* Max unknown frame count (1-10)
emul.0.16 = 1 /* Max retry count (0-2)
emul.0.17 = 15 /* Forward time delay (4-30)
emul.0.18 = 1 /* LE ARP timeout (1-30)
emul.0.19 = 1 /* Flush timeout (1-4)
emul.0.20 = 6 /* Path switching delay (1-8)
emul.0.21 = 4 /* Connection complete timeout (1-10)
emul.0.22.1 = 000000000000 /* Group address 1 (12 hex digits)
emul.0.22.5 = 000000000000 /* Group address 5

/*======================================================================
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)
/*======================================================================

Appendix D. Using the OSA/SF REXX interface 275


276 OSA-Express Implementation Guide
E

Appendix E. Sample definitions


This appendix lists sample definitions for TCP/IP in various operating systems environments.
It also includes VTAM definitions used in z/OS.

© 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

LPAR-A4 z/VM WTSCVMT 7300-7302 (EF) 7300-7302 (EF)


7300-7302 (EF) 10.10.1.62 10.10.1.64 10.10.1.65
NetView
TCP/IP (SNMP) LPAR-A9 LPAR-A10
Linux 2 Linux 3 z/OS - SC64 z/OS - SC65

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

CHPID 09 CHPID 0B CHPID 0E


OSA-Express OSA-Express OSA-Express
Fast Ethernet Fast Ethernet Token Ring
6509 ITSO
192.168.1.9 VNC Network
192.168.1.10
OSPF EE
SNMP IP
VLAN
9.12.2

Figure E-1 ITSO test environment

278 OSA-Express Implementation Guide


z/OS definitions
This section includes examples of the definitions that we used in our z/OS logical partitions
(LPARs).

TCP/IP profiles
The TCP/IP profile for SC64 (Example E-1) only shows the lines that we added or changed.

Example: E-1 SC64 TCP/IP profile


IPCONFIG MULTIPATH IQDIOR DATAGRAMFWD

DEVICE OSA2180 MPCIPA PRIRouter ; OSD Fast Ethernet Devices on CHPID 09


LINK SC642180LINK IPAQENET OSA2180

INTERFACE L2180V6 DEFINE IPAQENET6 PORTNAME OSA2180 ; IPv6 definition for CHPID09
IPADDR FEC0:0:0:1::3302
FEC0:0:0:1001::3302

DEVICE VIPA1 VIRTUAL 0 ; VIPA for Enterprise Extender


LINK VLINK1 VIRTUAL 0 VIPA1

DEVICE IUTSAMEH MPCPTP ; For Enterprise Extender


LINK EELINK MPCPTP IUTSAMEH

DEVICE OSA2360 MPCIPA SECRouter ; OSD Fast Ethernet Devices on CHPID 0B


LINK SC642360LINK IPAQENET OSA2360

DEVICE IUTIQDEF MPCIPA ; HiperSockets CHPID EF


LINK HIPERLEF IPAQIDIO IUTIQDEF

DEVICE OSA21A0 LCS 21A0 ; OSE Token Ring Devices on CHPID 0E


LINK SC6421A0LINK IBMTR 0 OSA21A0

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

Appendix E. Sample definitions 279


The TCP/IP profile for SC65 (Example E-2) shows only the lines that we added or changed.

Example: E-2 SC65 TCP/IP profile


IPCONFIG MULTIPATH IQDIOR DATAGRAMFWD

DEVICE OSA2360 MPCIPA SECRouter ; OSD Fast Ethernet Devices on CHPID 0B


LINK SC652360LINK IPAQENET OSA2360

DEVICE OSA2180 MPCIPA ; OSD Fast Ethernet Devices on CHPID 09


LINK SC652180LINK IPAQENET OSA2180

DEVICE VIPA1 VIRTUAL 0 ; VIPA for Enterprise Extender


LINK VLINK1 VIRTUAL 0 VIPA1

DEVICE IUTSAMEH MPCPTP ; For Enterprise Extender


LINK EELINK MPCPTP IUTSAMEH

INTERFACE L2180V6 DEFINE IPAQENET6 PORTNAME OSA2180 ; IPv6 definition for CHPID 09
IPADDR FEC0:0:0:1::3365

DEVICE IUTIQDEF MPCIPA ; Hipersockets CHPID EF


LINK HIPERLEF IPAQIDIO IUTIQDEF

DEVICE OSA21A0 LCS 21A0 ; OSE Token Ring Devices on CHPID 0E


LINK SC6521A0LINK IBMTR 0 OSA21A0

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.

VTAM TRL definitions


We used the same TRLs in both SC64 and SC65.

Note: TRLs are built dynamically for Hipersockets.

280 OSA-Express Implementation Guide


Example: E-3 TRL for CHPID 09
OSAFE09 VBUILD TYPE=TRL
TRLE2180 TRLE LNCTL=MPC, X
READ=2180, X
WRITE=2181, X
DATAPATH=2182, X
PORTNAME=OSA2180, X
MPCLEVEL=QDIO

Example: E-4 TRL for CHPID 0B


OSAFE0B VBUILD TYPE=TRL
TRLE2360 TRLE LNCTL=MPC, X
READ=2360, X
WRITE=2361, x
DATAPATH=2362, X
PORTNAME=OSA2360, X
MPCLEVEL=QDIO

VTAM definitions for Enterprise Extender


Example E-5 through Example E-9 show the VTAM definitions for Enterprise Extender.

Example: E-5 SWNDLUR1


SWNDLUR1 VBUILD TYPE=SWNET, REQUIRED FOR TR X
MAXGRP=4, X
MAXNO=512
*
PUDLUR1 PU ADDR=01, ADDR NOT USED X
IDBLK=05D, X
IDNUM=11111, X
ISTATUS=ACTIVE, X
DISCNT=NO, X
MAXDATA=265, X
MAXOUT=7, X
PACING=0, X
PUTYPE=2,MODETAB=NEWMTAB, X
VPACING=0
LUEE0001 LU LOCADDR=1,DLOGMOD=D4A32782,LOGAPPL=SC64TS
LUEE0002 LU LOCADDR=2,DLOGMOD=D4A32782,LOGAPPL=SC64TS

Example: E-6 SWTO64


SWTO64 VBUILD TYPE=SWNET, X
MAXGRP=4, X
MAXNO=512
PUTO64 PU MAXDATA=256,ADDR=01, X
CPNAME=SC64M, X
CPCP=YES,HPR=YES, X
DWACT=YES,PUTYPE=2
PATH64 PATH SAPADDR=08,IPADDR=192.168.1.164, X
GRPNM=EEGROUP

Appendix E. Sample definitions 281


Example: E-7 SWTO65
SWTO65 VBUILD TYPE=SWNET, X
MAXGRP=4, X
MAXNO=512
PUTO65 PU MAXDATA=256,ADDR=01, X
CPNAME=SC65M, X
CPCP=YES,HPR=YES, X
DWACT=YES,PUTYPE=2
PATH65 PATH SAPADDR=8,IPADDR=192.168.1.165, X
GRPNM=EEGROUP

Example: E-8 XCAEE for SC64


XCAEE VBUILD TYPE=XCA
EEPORT PORT MEDIUM=HPRIP, X
LIVTIME=10, X
IPTOS=(20,40,80,C0), X
SAPADDR=4, X
SRQRETRY=3, X
SRQTIME=15
EEGROUP GROUP DIAL=YES,ANSWER=ON, X
DYNPU=YES, X
DYNPUPFX=BR, X
AUTOGEN=(10,L,P), X
CALL=INOUT

Example: E-9 XCAEE65 for SC65


XCAEE65 VBUILD TYPE=XCA
EEPORT PORT MEDIUM=HPRIP, X
LIVTIME=10, X
IPTOS=(20,40,80,C0), X
SAPADDR=4, X
SRQRETRY=3, X
SRQTIME=15
EEGROUP GROUP DIAL=YES,ANSWER=ON, X
DYNPU=YES, X
DYNPUPFX=BR, X
AUTOGEN=(10,L,P), X
CALL=INOUT

Example E-10 and Example E-11 contain only the lines that we changed or added to support
Enterprise Extender.

Example: E-10 ATCSTR64 for SC64


NODETYPE=NN, NETWORK NODE NN FOR EE X
IPADDR=192.168.1.164, VIPA ADDRESS FOR EE ENTERPRISE EXT X
TCPNAME=TCPIPD, TCPIP JOB NAME FOR EE ENT.EXT X

282 OSA-Express Implementation Guide


Example: E-11 ATCSTR65 for SC65
NODETYPE=NN, NETWORK NODE NN FOR EE X
IPADDR=192.168.1.165, VIPA ADDRESS FOR EE ENTERPRISE EXT X
TCPNAME=TCPIPE, TCPIP JOB NAME FOR EE ENT.EXT X

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-12 modules.conf


alias hsi0 qeth

Example E-13 and Example E-14 show only the lines that we added or changed in the
chandev.conf files.

Example: E-13 LINUX2 chandev.conf


noauto;qeth0,0x7106,0x7107,0x7108
qeth1,0x2180,0x2181,0x2182
add_parms,0x10,0x2180,0x2182,portname:OSA2180
qeth2,0x7304,0x7305,0x7306

Example: E-14 LINUX3 chandev.conf


noauto;qeth0,0x7109,0x710a,0x710b
qeth1,0x2184,0x2185,0x2186
add_parms,0x10,0x2184,0x2186,portname:OSA2180
qeth2,0x7308,0x7309,0x730a

The next two examples only show the lines that we added or changed in the rc.config file.

Example: E-15 LINUX2 rc.config


# Number of network cards: "_0" for one, "_0 _1 _2 _3" for four cards
#
NETCONFIG="_0 _1 _2"
# IP Adresses
#
IPADDR_0="9.12.9.3"
IPADDR_1="192.168.1.60"
IPADDR_2="10.10.1.60"
# Network device names (e.g. "eth0")
#
NETDEV_0="hsi0"
NETDEV_1="eth1"
NETDEV_2="hsi2"
#
IFCONFIG_0="9.12.9.3 broadcast 9.12.9.31 netmask 255.255.255.224 mtu 1492 up"
IFCONFIG_1="192.168.1.60 broadcast 192.168.1.255 netmask 255.255.255.0 mtu 1492 up"
IFCONFIG_2="10.10.1.60 broadcast 10.10.1.255 netmask 255.255.255.0 mtu 1492 up"

Appendix E. Sample definitions 283


Example: E-16 LINUX3 rc.config
# Number of network cards: "_0" for one, "_0 _1 _2 _3" for four cards
#
NETCONFIG="_0 _1 _2"
# IP Adresses
#
IPADDR_0="9.12.9.4"
IPADDR_1="192.168.1.61"
IPADDR_2="10.10.1.61"
# Network device names (e.g. "eth0")
#
NETDEV_0="hsi0"
NETDEV_1="eth1"
NETDEV_2="hsi2"
#
IFCONFIG_0="9.12.9.4 broadcast 9.12.9.31 netmask 255.255.255.224 mtu 1492 up"
IFCONFIG_1="192.168.1.61 broadcast 192.168.1.255 netmask 255.255.255.0 mtu 1492 up"
IFCONFIG_2="10.10.1.61 broadcast 10.10.1.255 netmask 255.255.255.0 mtu 1492 up"

Example E-17 - route.conf is the same in both Linux guests.

Example: E-17 route.conf


9.12.9.0 0.0.0.0 255.255.255.224 hsi0
192.168.1.0 0.0.0.0 255.255.255.0 eth0
default 9.12.9.1 0.0.0.0 hsi0

z/VM TCP/IP profile


The TCP/IP profile in Example E-18 shows only the statements that are related to Open
Systems Adapter-Express (OSA-Express) and HiperSockets.

Example: E-18 Sample z/VM TCP/IPprofile


DEVICE OSA2188 OSD 2188 PORTNAME OSA2180 ; OSD Fast Ethernet devices on CHPID 09
LINK OSA2188L QDIOETHERNET OSA2188
;
DEVICE HIPERDEF HIPERS 7300 PORTNAME HIPERPEF ; HiperSockets CHPID EF
LINK HIPERLEF QDIOIP HIPERDEF
;
HOME

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

284 OSA-Express Implementation Guide


F

Appendix F. HiperSockets Accelerator


This appendix provides a description of HiperSockets Accelerator, definition requirements,
and verification procedures.

© 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.

HiperSockets Accelerator is activated by configuring the IQDIORouting option in the TCP/IP


profile using the IPCONFIG statement.

The TCP/IP stack automatically detects IP packet prerouting across a HiperSockets


Accelerator-eligible route. Eligible routes are from OSA-Express (QDIO) to HiperSockets
(iQDIO), and from HiperSockets (iQDIO) to OSA-Express (QDIO).

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.

286 OSA-Express Implementation Guide


zSeries CEC
TCPIPD

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

C:\ ping 10.10.1.60

Figure F-1 HiperSockets Accelerator flow

HiperSockets definitions
Implementation of HiperSockets Accelerator is quite simple as indicated by our sample
TCP/IP profile in Example F-1.

Example: F-1 TCP/IP Profile for HiperSockets Accelerator


IPCONFIG IQDIOR DATAGRAMFWD

DEVICE OSA2180 MPCIPA PRIRouter ; OSD Fast Ethernet Devices on CHPID 09


LINK SC642180LINK IPAQENET OSA2180

DEVICE IUTIQDEF MPCIPA ; HiperSockets CHPID EF


LINK HIPERLEF IPAQIDIO IUTIQDEF

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

Appendix F. HiperSockets Accelerator 287


The profile in Example F-1 allows us to use the HiperSockets Accelerator to connect between
the OSA-Express card on CHPID 09 and HiperSockets on CHPID EF.

Note: HiperSockets must be defined in the IOCDS as CHPID type IQD.

Note the following points:


򐂰 IQDIOR activates HiperSockets Accelerator.
򐂰 DATAGRAMFWD is required to forward the datagrams between the two networks.
򐂰 PRIRouter is required to route IP addresses between the networks.

Verifying HiperSockets Accelerator


We verified that HiperSockets Accelerator was working by issuing z/OS console commands
and reviewing the resulting messages. When TCP/IP was started, we saw the message
shown in Figure F-2, which confirmed that HiperSockets Accelerator was enabled.

EZZ0688I IQDIO ROUTING IS ENABLED

Figure F-2 Message when starting TCP/IP

Next, we looked at the active TCP/IP configuration as shown in Figure F-3.

D TCPIP,TCPIPD,N,CONFIG
EZD0101I NETSTAT CS V1R4 TCPIPD 841
TCP CONFIGURATION TABLE:
DEFAULTRCVBUFSIZE: 00016384 DEFAULTSNDBUFSIZE: 00016384
.
.
.
IQDIOROUTE: YES QDIOPRIORITY: 1

Figure F-3 Results of D TCPIP,N,CONFIG command

Since IQDIOROUTE is YES, we know that HiperSockets Accelerator is enabled. We can


verify this in the dynamically built VTAM TRLE as well, as shown in Figure F-4.

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

Figure F-4 HiperSockets TRLE

288 OSA-Express Implementation Guide


You can see from message IST1814I that VTAM recognizes that HiperSockets Accelerator is
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

Figure F-5 HiperSockets route (before communication)

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.

ROUTE ADD 10.10.1.0 MASK 255.255.255.0 192.168.1.64 -p

Figure F-6 Adding an indirect route to the workstation

The -p in Figure F-6 makes this a persistent route across boots.

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

Figure F-7 HiperSockets route (after communication)

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.

Appendix F. HiperSockets Accelerator 289


290 OSA-Express Implementation Guide
G

Appendix G. ARP Takeover


This appendix describes Address Resolution Protocol (ARP) Takeover, the definition
requirements, and verification procedures.

© 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.

To take advantage of ARP Takeover, the following conditions must be met:


򐂰 If this is an OSD-type CHPID, IP addresses are dynamically downloaded to the feature.
Or, if this is an OSE-type CHPID, a configuration must be activated that includes all of the
IP addresses that are used by this feature.
򐂰 TCP/IP must have connections to at least two similar OSA-Express cards.
򐂰 The TCP/IP profile must be defined properly.

Figure G-1 illustrates our test environment for ARP Takeover. We defined CHPID 09 and 0B
as OSD-type CHPIDs.

Before 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-1 Test environment before ARP Takeover

292 OSA-Express Implementation Guide


ARP Takeover definitions
We updated the TCP/IP profile to support ARP Takeover. We also modified the Cisco switch
(6509) configuration to support ARP Takeover.

TCP/IP definitions
Example G-1 shows the items that we changed or added in our TCP/IP profile for ARP
Takeover support.

Example: G-1 SC64 TCP/IP profile


IPCONFIG MULTIPATH IQDIOR DATAGRAMFWD

DEVICE OSA2180 MPCIPA ; OSD Fast Ethernet Devices on CHPID 09


LINK SC642180LINK IPAQENET OSA2180

DEVICE OSA2360 MPCIPA ; OSD Fast Ethernet Devices on CHPID 0B


LINK SC642360LINK IPAQENET OSA2360
HOME
192.168.1.64 SC642180LINK
192.168.1.4 SC642360LINK

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.

Cisco switch definitions


We used the Cisco command set port host to do this, because it accomplishes all the tasks
required to define a port as an end-station port. This command sets:
򐂰 channel mode to off
򐂰 trunk mode to off
򐂰 port fast start to enabled

Example G-2 shows an example of executing the command.

Example: G-2 Set port host


6500-top> (enable) set port host 1/1
2000 Jan 15 04:01:32 %SYS-6-CFG_CHG:Module 1 block changed by Console//
Port(s) 1/1 channel mode set to off.

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.

Spantree port 1/1 fast start enabled.


Port(s) 1/1 trunk mode set to off.

Appendix G. ARP Takeover 293


Verifying ARP Takeover

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.

We verified that ARP Takeover worked by performing two different tasks:


1. Pulling the CAT5 cable from the OSA-Express feature
2. Stopping the device in the TCP/IP stack

Pulling the CAT5 cable


Figure G-2 shows our environment after pulling the CAT5 cable, and the route that the ping
takes as a result of this.

After 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-2 Test environment after pulling the CAT5 cable

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

Interface: 192.168.1.10 on Interface 0x3000004


Internet Address Physical Address Type
192.168.1.4 00-06-29-6c-36-90 dynamic
192.168.1.64 00-06-29-6c-a5-bc dynamic

Figure G-3 Windows workstation APR cache (normal)

294 OSA-Express Implementation Guide


Notice that 192.168.1.4 is currently assigned to the MAC address associated with CHPID 0B.
Also 192.168.1.64 is currently assigned to the MAC address associated with CHPID 09.

Figure G-4 shows the contents of the ARP table from the OSA-Express cards before any
error condition was introduced.

MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: TCPIPD 15:34:44


Querying ARP cache for address 192.168.1.4
Link: SC642360LINK ETHERNET: 0006296C3690

Querying ARP cache for address 192.168.1.64


Link: SC642180LINK ETHERNET: 0006296CA5BC

Querying ARP cache for address 192.168.1.10


Link: SC642180LINK ETHERNET: 0004AC1D18E9

Figure G-4 ARP table from SC64 TCPIPD (normal)

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.

EZZ4329I LINK SC642360LINK HAS TAKEN OVER ARP RESPONSIBILITY FOR


INACTIVE LINK SC642180LINK
EZZ4311I LINK SC642180LINK HAS FAILED ON DEVICE OSA2180

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

Interface: 192.168.1.10 on Interface 0x3000004


Internet Address Physical Address Type
192.168.1.4 00-06-29-6c-36-90 dynamic
192.168.1.64 00-06-29-6c-36-90 dynamic

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.

Appendix G. ARP Takeover 295


Figure G-7 shows the contents of the ARP table on z/OS immediately after pulling the CAT5
cable for CHPID 09.

MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: TCPIPD 15:37:16


Querying ARP cache for address 192.168.1.64
Link: SC642180LINK ETHERNET: 0006296CA5BC

Querying ARP cache for address 192.168.1.10


Link: SC642180LINK ETHERNET: 0004AC1D18E9

Querying ARP cache for address 192.168.1.4


Link: SC642360LINK ETHERNET: 0006296C3690

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.

MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: TCPIPD 15:39:23


Querying ARP cache for address 192.168.1.64
Link: SC642180LINK ETHERNET: 0006296CA5BC

Querying ARP cache for address 192.168.1.10


Link: SC642180LINK ETHERNET: 0004AC1D18E9

Querying ARP cache for address 192.168.1.4


Link: SC642360LINK ETHERNET: 0006296C3690

Querying ARP cache for address 192.168.1.64


Link: SC642180LINK ETHERNET: 0006296C3690

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

Figure G-9 z/OS PURGECACHE command

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.

EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180


EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180

Figure G-10 CAT5 cable for CHPID 09 plugged into switch

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

296 OSA-Express Implementation Guide


ARP updated only existing entries in ARP cache. It did not create entries for IP addresses
that were not currently in ARP cache.

Stopping the device in the TCP/IP stack


In this test, we created an error condition by stopping the device in the TCP/IP stack.
Figure G-11 shows the command that was issued and the resulting messages.

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

Figure G-11 Induced error by stopping the device in TCPIPD

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.

We started the device again, as shown in Figure G-12.

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

Figure G-12 Starting the device in TCPIPD

Once again, the gratuitous ARP was sent to update existing ARP cache entries to the correct
MAC addresses.

Appendix G. ARP Takeover 297


298 OSA-Express Implementation Guide
Related publications

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/

How to get IBM Redbooks


You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft
publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at
this Web site:
ibm.com/redbooks

Help from IBM


IBM Support and downloads
ibm.com/support

IBM Global Services


ibm.com/services

300 OSA-Express Implementation Guide


Index
emulated LAN types 145
Numerics OSA/SF definitions 143
1000BASE-T Ethernet 2 status displays 161
50.0 micron 26, 28 switched major node 156
62.5 micron 26, 28 TCP/IP definitions 157
6bone test address 230 TCP/IP PROFILE 158
6to4 address 230 VTAM definitions 153
802.1Q 184 ATM native
8021q.o module 193 HCD 124
OSA/SF definitions 125
A status displays 136
access list 51 switched definitions 135
Access mode 185 TCP/IP definitions 132
access port 184 TRL definitions 131
ACTIVE State 177, 233 XCA definitions 134
adaptive rate-based (ARB) 167 ATM Native Mode 33
Address Resolution Protocol (ARP) 235 ATM Native mode 32
advanced facilities 243 ATM switch 126, 144
ANR (Automatic Network Routing) 168 attached guest system 17
anycast address 230 Automatic Network Routing (ANR) 168
APPC 61 availability
APPCOSA 61 IP 16, 37
APPCPMxx 61 SNA 18
APPN connection network 166
ARP B
offload 16, 87 BEGINROUTES statement 85, 98, 119, 132–133, 158,
statistics 16 235
Takeover 291 static routes 98
ARP cache 15, 238, 294 broadcast
existing entries 297 in VLAN 186
ARP table 292 support for z/OS, z/VM, Linux 15
MAC addresses 296
ARP Takeover 16
asynchronous transfer mode (ATM) 1, 42, 141 C
ATM 123 candidate list 52
activation 135 CAT5 cable 294
configuration 125, 143 Channel Activity Report 264
description 31, 33 channel on/off 256
HPDT 123 Channel Path
LAN Emulation 32–33 List panel 50, 52
LANE 141 Measurement Facility 264
LEC 145 window 50
Native 32–33 channel path 50
Native mode 123 definition 49
port name 126 channel path identifier (CHPID) 47
SNA 151 checksum 16
switched major node 134 CHPID 80, 91, 211, 243, 268
TCP/IP OAT configuration 149 On/Off 256
TRLE 131 CHPID 09 279, 287, 292
XCA 134 Fast Ethernet port 295
ATM (asynchronous transfer mode) 42, 141 IPv6 definition 280
ATM HPDT Native mode 123 OSA-Express card 288
ATM LAN emulation 141 OSD Fast Ethernet devices 279
ATM LANE CHPID 0B 279, 293
activation 159 OSD Fast Ethernet Devices 279

© 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

302 OSA-Express Implementation Guide


definition 103 locally administered address (LAA) 106
IODEVICE Address 58, 93, 103, 124, 142 logical IP subnet (LIS) 132
IP address 43, 66, 81, 96, 102, 133, 148, 170, 203, 219, logical partition 44, 59, 102, 143, 204, 259, 269
269, 288, 292 LP number 107, 109
192.16.1.20 118 OSA-Express port 109
192.16.1.24 98, 107 LP number 107, 109, 127, 148
conflict 219 Home IP address list entries 148
space 228 LPAR 91, 107, 143, 256
IP network 19, 165–166 multiple TCP/IP stacks sharing multiple OSA-Express
HPR transport 168 CHPIDs 82
SNA data 168 multiple TCP/IP stacks, OSA-Express CHPID 82
SNA traffic 168 multiple with multiple TCP/IP stacks per, sharing mul-
IP router 166, 186, 204 tiple OSA-Express CHPIDs 83
IPA (Internet Protocol assist) 6 multiple with multiple TCP/IP stacks per, sharing
IPCONFIG IQDIOR 286 OSA-Express CHPID 83
IPv6 multiple with one TCP/IP stack per, sharing OSA-Ex-
address 228 pres CHPID 82
implementation 231 multiple with TCP/IP stack per, sharing multiple
migration 231 OSA-Express CHPIDs 83
support 187, 227 only one TCP/IP stack, multiple OSA-Express
IPv6 address 16, 85, 98, 119, 133, 158, 228, 232 CHPIDs 82
certain styles 229 only one TCP/IP stack, OSA Express CHPID 82
IPv6 support 10 LPAR S30 156
iQDIO 286 LPAR-to-LPAR communication 6
issued PING (IP) 201
IST075I Name 88, 121, 176, 288
IST097I Display 88, 121, 176, 288 M
IST486I Status 88, 121, 176, 288 MAC address 16, 70, 105–106, 114, 135, 145, 204, 230,
IUTSAMEH 172 244, 295
ARP cache 296
byte ID prefix 204
L of defined OSA-Express port 106
LAN Channel Station (LCS) 14, 92, 102, 157, 235 same IP address 296
LAN emulation 141, 165 major node 82, 115, 153, 173, 239
client 146 Management Information Base (MIB) 14
configuration 145 Maxconn 207, 212
configuration server 147 maximum IP addresses per OAT 8
server 146 maximum IP stacks and devices 8
LAN Emulation Client 32–33 maximum OSA-Express features 24
LANE 32–33, 165 maximum TCP/IP stacks and devices 8
large send 10 microcode 256
Layer 2 support 17, 44, 89, 201 Missing Interrupt Handler (MIH) 80
requirements 205 mode conditioner patch (MCP) 26, 28
LCS device 96, 102 modes of operation 3
LCS mode 15 MTU size 87, 99, 122, 192, 286
LEC 32–33 multicast address 230
LECS 147 multicast support 15
link local address type 229 Multipath Channel (MPC) 106
LINK statement 82, 96, 157, 192, 235, 293 Multiple Image Facility (MIF) 24
parameter VLAN 196 multiple IP addresses 16, 148, 292
parameter VLANID 192 multiple TCP/IP stack 82, 170, 187, 231
port number 97 multiple LPARs 83
Linux
commands for zSeries TCP/IP 242
definitions 46, 283 N
VLAN support 193 Native 32
Linux guest 195, 201, 283, 289 network interface card (NIC) 210, 241
testing Layer 2 functionality 213 NICDEF statement 210
VLAN support 219 NETWORK NODE (NN) 171, 282
local end system ID 126, 144 Network Node Server (NNS) 166
Local System Identifier (LSI) 135 Network Nodes (NN) 171

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

304 OSA-Express Implementation Guide


physical channel identifier (PCHID) 47 S
physical file system (PFS) 231 S/390 Open Systems Adapter-Express 2
physical port 126, 144, 269 SAP (service access point) 154
Physical Unit (PU) 18, 115, 153, 173 SE 243
policy-based networking 43 service access point (SAP) 154
port name 82, 125–126, 132 shared port 101, 110
port number 97, 119, 158, 167, 269 activation 120
port types 198 HCD 103
ports OSA/SF definitions 93, 104
disable 250 status displays 121
enable 250 TCP/IP definitions 118
status 251 VTAM definitions 115
primary/secondary router function 10 SHR 50
priority queuing 5 Simple Network Management Protocol (SNMP) 14
PROFILE TCPIP file 203 site local address type 230
protocol data unit (PDU) 129 SNA 101
pull-down menu 246 class of service 167
select CHPIDs 259 ELAN 32, 34
Task List 259 mode 8
purge ARP 16 QDIO 89
PVC (permanent virtual circuit) 128 SNA application 19, 89, 115, 153, 165
name 128, 274 SNA traffic 19, 89, 106, 128, 165
SNA transporting over IP 168
Q SNMP support 14
QDIO 3–4 SPAN 50
status displays 87 START L2180V6 233, 279
TCP/IP definitions 84 startup profile 272
TCP/IP profile 84 static route 85, 119, 133, 158
TRLE 82 subnet-router anycast address 231
versus non-QDIO 4 Support Element (SE) 243
VTAM definitions 82 Advanced Facilities icon 255
QDIO mode 60, 79, 101, 165, 183, 202, 227, 292 SVC 128, 132
OSA-Express 187 switched major node 117, 173
OSA-Express feature 292 PATH statement 173
OSA-Express port 191 System z9 2, 16, 42–43, 47, 92, 106, 153
Quality of Service (QOS) 228
query ARP 15 T
QUERY VSWITCH tagged frames 186
command 214 TCP connection 168
Detail 241 TCP segmentation offload 10
name Access 241 TCP/IP 42, 60, 91, 101, 123, 141, 167, 187, 201, 229,
238, 286, 292
R network interfaces 240
RACF TCP/IP definition 46, 79, 97, 102, 124, 142, 172, 232
authorization 225 TCP/IP device 82, 86, 97, 99, 121, 133, 161, 176, 239
profile 225 TCP/IP Passthru 7
security 225 TCP/IP profile 46, 84, 96, 118, 125, 157, 172, 192, 232,
Rapid Transport Protocol (RTP) 168 279, 286, 292
raw IP datagram 168 ATMPVC statement 128
Redbooks Web site 300 DEVICE name 125
Contact us xii device statement 126
Resource Measurement Facility (RMF) 263 device type LCS 292
Responsive Mode ARB 169 device type MPCIPA 292
flow control 167 IPCONFIG statement 16
REXX 267 IQDIORouting option 286
RMF (Resource Measurement Facility) 263 OSA device 119
RMF for OSA-Express 264 required statements 133
RMF Monitor II output 264 START statements 127
Routing Information Protocol (RIP) 15 TCP/IP stack 44, 163, 205

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

306 OSA-Express Implementation Guide


OSA-Express Implementation Guide
OSA-Express Implementation Guide
OSA-Express Implementation Guide
(0.5” spine)
0.475”<->0.873”
250 <-> 459 pages
OSA-Express Implementation Guide
OSA-Express Implementation Guide
OSA-Express Implementation Guide
Back cover ®

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.

For more information:


ibm.com/redbooks

SG24-5948-04 ISBN 0738492795

You might also like