osa express - implemantation guide - redbook ibm

ibm.com/redbooks

Front cover

OSA-Express Implementation Guide

Bill WhiteJoerg Haertel

Thomas Wienert

Product, planning, and quick start information

Realistic examples and considerations

Hardware and software setup definitions

http://www.redbooks.ibm.com/


International Technical Support Organization


April 2009

SG24-5948-05

© Copyright International Business Machines Corporation 1999, 2001, 2002, 2003, 2005, 2006, 2007, 2008, 2009.All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP ScheduleContract with IBM Corp.

Sixth Edition (April 2009)

This edition applies to the OSA-Express3, OSA-Express2, and OSA-Express features installed in the IBM System z10 and System z9 severs.

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

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiThe team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Chapter 1. OSA overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 QDIO mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.3 Non-QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.4 OSA addressing support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.5 OSA/SF support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 OSA capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.1 Virtual IP address (VIPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 Primary/secondary router function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.3 IPv6 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.4 Large send for TCP/IP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.5 VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.6 SNMP support for z/OS and Linux on System z . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.7 TCP/IP multicast and broadcast support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.8 ARP cache management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.9 IP network availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.10 Checksum offload support for z/OS and Linux on System z. . . . . . . . . . . . . . . . 171.2.11 Layer 2 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.12 QDIO data connection isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2.13 Layer 3 VMAC for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.14 Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2.15 TN3270E Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2.16 OSA for NCP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 2. Quick start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1 Software support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2 OSA definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.1 Modes of operation and addressing support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3 OSA/SF requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4 Quick start tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.1 OSA function support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.2 Quick start tables for z/OS and z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5 Policy-based networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 3. Hardware configuration definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1 Configuration chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Channel path definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.2 Control unit definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.3 Device definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

© Copyright IBM Corp. 1999, 2001, 2002, 2003, 2005, 2006, 2007, 2008, 2009. All rights reserved. iii

3.2.4 Generating the input IOCDS from HCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 4. Setting up and using OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1 Setup requirements and overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2 Setting up OSA/SF in the z/OS environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Setting up APPC and VTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.2 Setting up OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.3 Communicating with OSA/SF using TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Installing OSA/SF GUI on a workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.1 Checking the hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.2 Checking the software configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.3 Downloading and installing the Java runtime and JavaHelp files . . . . . . . . . . . . . 524.3.4 Downloading the code from z/OS using FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.5 Defining the CLASSPATH environment variable . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.6 Starting the OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Using the OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Chapter 5. QDIO mode for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1 QDIO environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3 Missing Interrupt Handler for QDIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4.1 Defining OSA devices to z/OS Communications Server for QDIO . . . . . . . . . . . . 705.4.2 VTAM definitions (TRL major node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.3 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.5.3 TCP/IP devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.7 SNA support for QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 6. QDIO mode for z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.1 QDIO environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.3 Missing Interrupt Handler for QDIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4 Customizing the z/VM network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.4.1 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.5.2 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapter 7. Non-QDIO mode for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.1 Configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.2 Hardware definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.3 Creating and activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.1 TCP/IP definitions in OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.3.2 SNA definition in OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.3.3 Activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.3.4 Displaying the MAC address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.4.1 VTAM definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

iv OSA-Express Implementation Guide

7.5 Activating the connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.5.3 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Chapter 8. Non-QDIO mode for z/VM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.1 Configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088.2 Hardware definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088.3 OSA configuration and OAT definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.3.1 Creating and activating our OSA configuration and OAT . . . . . . . . . . . . . . . . . . 1098.4 Network definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.4.1 VTAM definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.5 Activating the connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.5.3 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 9. z/OS VMAC support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239.1 Virtual MAC overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

9.1.1 Virtual MAC concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1249.1.2 Virtual MAC address assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.2 Virtual MAC implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259.2.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapter 10. VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13110.1 VLAN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

10.1.1 Types of connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13210.1.2 VLAN tagging basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

10.2 General VLAN design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13510.2.1 VLAN configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13610.2.2 Sharing an OSA port with the same VLAN ID. . . . . . . . . . . . . . . . . . . . . . . . . . 13710.2.3 Primary and secondary router support with VLANs . . . . . . . . . . . . . . . . . . . . . 13710.2.4 Operating system support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

10.3 VLAN support for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.3.1 VLAN implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.3.2 Configuring OSA with VLAN ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13910.3.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

10.4 VLAN support for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14510.4.1 VLAN implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14510.4.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

10.5 VLAN support in z/VM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14810.5.1 z/VM native VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14810.5.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 11. z/VM virtual switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15111.1 Virtual switch description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

11.1.1 VSWITCH controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15311.1.2 Network interface card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15311.1.3 VSWITCH capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

11.2 Our VSWITCH environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15611.3 Configuring a Layer 2 VSWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Contents v

11.3.1 Defining the virtual switch environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15811.3.2 Authorizing the guest system access to the virtual switch . . . . . . . . . . . . 15911.3.3 Connecting the guest systems to the VSWITCH . . . . . . . . . . . . . . . . . . . . . 16011.3.4 Verifying the virtual switch configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16111.3.5 Setting up Layer 2 for the guest systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16311.3.6 Creating definitions for Layer 2 support - SUSE and Red Hat . . . . . . . . . . . . . 16311.3.7 Making permanent device and network definitions . . . . . . . . . . . . . . . . . . . . . . 165

11.4 Configuring VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16711.4.1 Defining VLAN capabilities to the virtual switch . . . . . . . . . . . . . . . . . . . . . . . . 16811.4.2 Authorizing Linux guests access to the virtual switch with VLAN IDs . . . . . . . . 16911.4.3 Adding VLANs to the guest systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17011.4.4 Adding VLAN support to the z/OS TCP/IP stacks. . . . . . . . . . . . . . . . . . . . . . . 17311.4.5 Configuring trunk mode in the Ethernet switch for the OSA connections . . . . . 17311.4.6 Verifying the VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

11.5 Enabling port isolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17611.5.1 Port isolation off - systems sharing the same VSWITCH and OSA . . . . . . . . . 17811.5.2 Port isolation on - systems sharing the same VSWITCH and OSA . . . . . . . . . 179

11.6 Configuring link aggregation support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18111.6.1 Defining link aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18111.6.2 Setting up the external Ethernet switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18311.6.3 Verifying the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Appendix A. OSA features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187OSA feature descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Appendix B. OSA-Express Network Traffic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . 197OSA-Express Network Traffic Analyzer (OSAENTA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Determining the microcode level for OSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Defining TRLE definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Checking TCPIP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Customizing OSA-Express Network Traffic Analyzer (NTA). . . . . . . . . . . . . . . . . . . . . 201Defining a resource profile in RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Allocating a VSAM linear data set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Starting the OSAENTA trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Additional tools for diagnosing CS for z/OS IP problems. . . . . . . . . . . . . . . . . . . . . . . . . . 216Network Management Interface API (NMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Appendix C. HMC and SE tasks for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219HMC advanced facilities for OSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Trace functions for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Hardware functions for OSA-Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

View code level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Configuring OSA channels on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Logging on to the Support Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229CHPID Configure on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Logging off from the Support Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Appendix D. Useful commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235z/OS commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236z/VM commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Defining and coupling a NIC using CP commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Linux on System z TCP/IP commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

vi OSA-Express Implementation Guide

Appendix E. Using the OSA/SF REXX interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Creating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Creating the OSA configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Creating the OAT file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Appendix F. TCP/IP Passthru mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Default mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252HCD requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Displaying the default OAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Customizing z/OS TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Activating TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Appendix G. Sample definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Sample environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262z/OS definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

TCP/IP profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263VTAM definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

z/VM TCP/IP profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Appendix H. ARP takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269ARP takeover description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270ARP takeover definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Ethernet switch definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Verifying ARP takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Pulling the CAT5 cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Stopping the device in the TCP/IP stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Appendix I. HiperSockets Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277HiperSockets Accelerator description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278HiperSockets definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Verifying HiperSockets Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Appendix J. RMF in an OSA environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283RMF for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284RMF Monitor II output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

The Channel Activity Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Appendix K. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287z/VM virtual switch authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Running with CP authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Running with RACF authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Contents vii

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

© Copyright IBM Corp. 1999, 2001, 2002, 2003, 2005, 2006, 2007, 2008, 2009. All rights reserved. ix

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

CICS®DB2®ESCON®HiperSockets™IBM®MQSeries®NetView®OMEGAMON®

Parallel Sysplex®RACF®Redbooks®Redbooks (logo) ®Resource Link™System z10™System z9®System z®

Tivoli®VTAM®WebSphere®z/Architecture®z/OS®z/VM®z/VSE™z9®

Novell, SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other countries.

Red Hat, and the Shadowman logo are trademarks or registered trademarks of Red Hat, Inc. in the U.S. and other countries.

SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries.

Other company, product, or service names may be trademarks or service marks of others.

x OSA-Express Implementation Guide

http://www.ibm.com/legal/copytrade.shtml

Preface

This IBM® Redbooks® publication will help you to install, tailor, and configure the Open Systems Adapter (OSA) features that are available on IBM System z10™ and IBM System z9® servers. It focuses on the hardware installation and the software definitions that are needed to provide connectivity to 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 features.

The target audience for this document is system engineers, network administrators, and system programmers who will plan for and install OSA features. The reader is expected to have a good understanding of System z® hardware, HCD or IOCP, OSA/SF, SNA/APPN, and TCP/IP.

The team that wrote this bookThis book 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 and Connectivity Specialist at the ITSO in Poughkeepsie, New York.

Joerg Haertel is a Senior IT Specialist working for System z Sales Technical Support in Germany. He holds a diploma in communications engineering. He has 20 years of technical experience in the z/VM® and z/VSE™ environment. Joerg has worked at IBM for 22 years. His areas of expertise include Linux® for System z, TCP/IP, DB2®, and System z-related hardware. He has written extensively on CICS®, CTG, and MQSeries®, setup for Linux on System z, as well as on z/VSE.

Thomas Wienert is a Senior IT Specialist working for IBM STG in Germany, supporting clients in Germany, Austria, Sweden and Switzerland. He has over 24 years of experience with IBM networking. Thomas has been with IBM for 19 years working as a Systems Engineer in technical sales, product support and implementation services. His areas of expertise include Communications Server for z/OS®, OSA-Express, z/OS, Parallel Sysplex®, and System z-related hardware. He co-authored a number of IBM Redbooks publications.

Thanks to the following people for their contributions to this project:

Dave Bennin, Roy Costa, and Robert Haimowitz ITSO, Poughkeepsie Center

Connie Beuselinck System z Product Planning, IBM Poughkeepsie

Joel GoldmanSystem z (OSA firmware) Development, IBM Poughkeepsie

Susan Farrell and Angelo Macchianoz/VM Networking Development, IBM Endicott

Cliff LakingTechnical Support - z/VM and Linux on System z, IBM UK

© Copyright IBM Corp. 1999, 2001, 2002, 2003, 2005, 2006, 2007, 2008, 2009. All rights reserved. xi

Become a published authorJoin us for a two- to six-week residency program! Help write an IBM Redbooks publication 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 welcomeYour comments are important to us!

We want our books to be as helpful as possible. Send us your comments about this or other IBM Redbooks in one of the following ways:

� Use the online Contact us review Redbooks 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 OrganizationDept. HYJ Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

xii OSA-Express Implementation Guide

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html



http://www.redbooks.ibm.com/contacts.html

Chapter 1. OSA overview

This chapter describes the Open Systems Adapter-Express3 (OSA-Express3) and Open Systems Adapter-Express2 (OSA-Express2) features. These features provide connectivity to other servers and clients on 1000BASE-T Ethernet (10, 100, and 1000 Mbps), Gigabit Ethernet (GbE), and 10 Gigabit Ethernet environments.

The following topics are covered:

� Functional description

� Operating modes

� OSA capabilities

1

Terminology: If not specifically stated otherwise, the term OSA applies to the OSA-Express3 and OSA-Express2 features throughout this book.

© Copyright IBM Corp. 1999, 2001, 2002, 2003, 2005, 2006, 2007, 2008, 2009. All rights reserved. 1

1.1 Functional descriptionThe Open Systems Adapter-Express3 (OSA-Express3), and OSA-Express2 features comprise a number of integrated hardware features that can be installed in a System z I/O cage, becoming integral components of the server’s I/O subsystems. They provide high function, connectivity, bandwidth, data throughput, network availability, reliability, and recovery.

All OSA-Express3 and OSA-Express2 features are “hot-pluggable.”

Figure 1-1 shows the OSA-Express3 and OSA-Express2 Ethernet features available on the System z10 and System z9 servers.

Figure 1-1 OSA-Express3 and OSA-Express2 Ethernet connectivity

For a complete list and description of all the OSA-Express3 and OSA-Express2 features offered on the System z10 and System z9 servers, go to Appendix A, “OSA features” on page 187.

1.1.1 Operating modesThe integration of a channel path with network ports makes the OSA a unique channel or CHPID type, recognized by the hardware I/O configuration as one of the following:

� OSD (Queued Direct Input/Output)� OSE (non Queued Direct Input/Output)� OSC (OSA Integrated Console Controller)� OSN (Open System Adapter for NCP)

Note that not all features support all CHPID types.

Ethernet

GbE

z10 BC

1000BASE-T

10 GbE

z9 EC

GbE

10 GbE

1000BASE-T

z9 BC

10 GbE

GbE

1000BASE-T

z10 EC

GbE

1000BASE-T

10 GbE

2 OSA-Express Implementation Guide

Table 1-1 gives an overview of the type of traffic supported and whether OSA/SF is required to configure the OSA-Express3 or OSA-Express2 CHPID, based on the supported modes of operation.

Table 1-1 Supported CHPID types

Open Systems Adapter Support Facility (OSA/SF)OSA/SF is a host-based tool used to customize and manage all OSA features.

� OSA/SF is not required for the OSA feature that is configured for the 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 CHPID types OSC and OSN, although information about channel usage can by displayed through OSA/SF for OSN CHPIDs.

� OSA/SF is a required facility when the OSA 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 z server. OSA/SF communicates with an OSA feature through a device (type OSAD) defined via HCD/IOCP.

For more details, refer to 1.1.5, “OSA/SF support” on page 9.

QDIO versus non-QDIOFigure 1-2 on page 4 illustrates the much shorter I/O process when in QDIO mode compared with non-QDIO mode. I/O interrupts and I/O path-lengths are minimized, resulting in improved performance versus non-QDIO mode, reduction of System Assist Processor (SAP®) utilization, improved response time, and server cycle reduction.

CHPIDtype

Feature SNA/APPN/HPR traffic

TCP/IP traffic

3270 traffic

OSA/SF

OSD OSA-Express3 10GbE LROSA-Express3 10GbE SROSA-Express2 10GbE LROSA-Express3 GbEOSA-Express2 GbEOSA-Express3 1000BASE-TOSA-Express2 1000BASE-T

Noa,b

Noa,b

Noa,b

Noa,b

Noa,b

Noa,b

Noa,b

a. SNA over IP with the use of Enterprise Extender or TN3270 (see “Enterprise Extender” onpage 21 and “TN3270E Server” on page 21).

b. Layer 2 support allows for non-IP protocols, such as SNA (see “Layer 2 support” on page 18).

YesYesYesYesYesYesYes

NoNoNoNoNoNoNo

OptionalOptionalOptionalOptionalOptionalOptionalOptional

OSE OSA-Express3 1000BASE-TOSA-Express2 1000BASE-T

YesYes

YesYes

NoNo

RequiredRequired

OSC OSA-Express3 1000BASE-TOSA-Express2 1000BASE-T

NoNo

NoNo

YesYes

n/an/a

OSN OSA-Express3 GbEOSA-Express2 GbEOSA-Express3 1000BASE-TOSA-Express2 1000BASE-T

Yesc

Yesc

Yesc

Yesc

c. Supports SNA PU Type 5 and PU Type2.1 (see “OSA for NCP support” on page 22).

NoNoNoNo

NoNoNoNo

OptionalOptionalOptionalOptional

Chapter 1. OSA overview 3

Figure 1-2 Non-QDIO data path versus QDIO data paths

Note that OSA-Express3 features use Direct Memory Access (DMA) and a data router model to eliminate store and forward delays that could occur with the OSA-Express2 features when in QDIO mode.

Also in QDIO mode, all OSA features receive 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 the use of QDIO mode wherever possible.

1.1.2 QDIO modeQDIO is a highly efficient data transfer mechanism that is designed to dramatically reduce system overhead and improve throughput by using system memory queues and a signaling protocol to directly exchange data between the OSA microprocessor and network software. QDIO is the interface between the operating system and the OSA hardware.

The components that make up QDIO are DMA, data router (OSA-Express3 only), Priority Queuing (z/OS only), dynamic OSA Address Table building, LPAR-to-LPAR communication, and Internet Protocol (IP) Assist functions.

QDIO supports IP and non-IP traffic with the OSA-Express3 and OSA-Express2 features. These features support two transport modes: Layer 2 (Link Layer) for IP and non-IP traffic, and Layer 3 (Network Layer) for IP traffic only. A more detailed discussion about the Layer 2 support is provided in 1.2.11, “Layer 2 support” on page 18.

Direct Memory Access (DMA) OSA and the operating system share a common storage area for memory-to-memory communication, reducing system overhead and improving performance. Data can move directly from the OSA microprocessor to system memory and vice versa, utilizing a “store and forward” technique in DMA. 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.

Host Memory

LAN

NIC

ControlUnit

Channel

Non-QDIO (LCS)

QDIO

Host Memory

OSA-Express2

LAN

Store and forward

LAN

OSA-Express3

Host Memory

Data router

QDIO

OSA-Express

Host Memory

Host Memory

LAN

NIC

ControlUnit

Channel

Non-QDIO (LCS)

QDIO

Host Memory

OSA-Express2

LAN

Store and forward

LAN

OSA-Express3

Host Memory

Data router

QDIOQDIO

Host Memory

Host Memory

OSA-Express2

LAN

Store and forward

LAN

OSA-Express3

Host Memory

Host Memory

Data router

QDIO

OSA-Express


Data routerWith OSA-Express3, what was previously done in firmware is now performed in hardware. There is additional logic in the IBM ASIC to handle packet construction, inspection, and routing, thereby allowing packets to flow between host memory and the LAN at line speed without firmware intervention. With the data router, the “store and forward” technique in DMA is no longer used, which enables a direct host memory-to-LAN flow. This avoids a “hop” and is designed to reduce latency and to increase throughput for standard frames (1492 bytes) and jumbo frames (8992 bytes).

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

This is an alternative to the best effort priority assigned to all traffic in most TCP/IP networks. Priority queuing allows the definition of four different priority levels for TCP/IP traffic through the OSA 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 feature.

OSA signals to z/OS Communications Server when there is work to do. z/OS Communications Server puts outbound packets in one of the four queues, based on priority settings.

At a certain time, z/OS Communications Server signals the OSA feature that there is work to do. The OSA 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.

Dynamic OSA Address Table (OAT) updateWith QDIO, this process simplifies installation and configuration tasks. The definition of IP addresses is done in one place, the TCP/IP profile, thus removing the requirement to enter the information into the OAT using the OSA Support Facility (OSA/SF).

The OAT entries will be 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, and corresponding entries are built in the OAT. Subsequent changes to these IP addresses will cause a corresponding update of the OAT.

Note: With OSA-Express3 and 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 subchannels” on page 8).


LPAR-to-LPAR communicationAccess to an OSA port can be shared among the system images that are running in the logical partitions 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 logical partition or in different logical partitions.

When port sharing, an OSA port operating in QDIO mode has the ability to send and receive IP traffic between logical partitions without sending the IP packets out to the LAN and then back to the destination logical partition.

For outbound IP packets, the OSA 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 port, then the packet will be 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.

Internet Protocol Assist (IPA) functionsOSA QDIO assists in IP processing and offloads the TCP/IP stack functions for the following:

� Multicast support (see “TCP/IP multicast and broadcast support” on page 15)� Broadcast filtering (see “TCP/IP multicast and broadcast support” on page 15)� Building MAC and LLC headers� Address Resolution Protocol (ARP) processing (see “ARP cache management” on

page 16)� Checksum offload (see “Checksum offload support for z/OS and Linux on System z” on

page 17)

QDIO functionsThe following QDIO functions are supported on z10 an z9 servers:

TCP/IP functions� Large Send for TCP/IP traffic for OSA-Express3 and OSA-Express2 (see “Large send for

TCP/IP traffic” on page 11)� 640 TCP/IP stacks (see “Maximum TCP/IP stacks and subchannels” on page 8)

Concurrent LIC updateThe OSA features have increased memory to facilitate concurrent application of LIC updates, allowing the application of LIC updates without requiring a configuration off/on, thereby minimizing the disruption of networking traffic during the update.

Concurrent LIC update applies to the OSA-Express3 and OSA-Express2 features (1000BASE-T Ethernet, Gigabit Ethernet SX, Gigabit Ethernet LX, 10 Gigabit Ethernet SR, and 10 Gigabit Ethernet LR). It is offered for the QDIO and OSA for NCP mode only (CHPID type OSD and OSN).

Hardware assistsComplementary virtualization technology is available, which includes:

� QDIO Buffer-State Management (QEBSM) - Two hardware instructions help to eliminate the overhead of hypervisor interception.

� Host Page-Management Assist (HPMA) - An interface to the z/VM central storage management function designed to allow the hardware to assign, lock, and unlock page frames without z/VM hypervisor assistance.

These hardware assists allow a cooperating guest operating system to initiate QDIO operations directly to the applicable channel, without interception by z/VM, thereby helping to


provide additional performance improvements. Support is integrated in System z Licensed Internal Code.

QDIO Diagnostic Synchronization for z/OS QDIO Diagnostic Synchronization is exclusive to System z, and the OSA-Express3 and OSA-Express2 features when configured as CHPID type OSD (QDIO). It is designed to provide the system programmer and network administrator with the ability to coordinate and simultaneously capture both operating system (software) and OSA (hardware) traces at the same instance of a system event. This allows the host operating system to signal the OSA-Express3 and OSA-Express2 feature to stop traces and capture the current trace records. Using existing tools (traps) and commands, the operator can capture both hardware and software traces at the same time, and then correlate the records during post processing.

OSA-Express Network Traffic Analyzer for z/OSOSA-Express Network Traffic Analyzer is exclusive to System z and the OSA-Express3 and OSA-Express2 features when configured as CHPID type OSD (QDIO). It allows trace records to be sent to the host operating system to improve the capability to capture data for both the system programmer and the network administrator. This function allows the operating system to control the sniffer trace for the LAN and capture the records into host memory and storage, using existing host operating system tools to format, edit, and process the sniffer records.

For more information, refer to Appendix B, “OSA-Express Network Traffic Analyzer” on page 197.

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

The 1000BASE-T features support non-QDIO mode. This mode supports SNA/APPN/HPR and TCP/IP traffic simultaneously through the OSA CHPID. The non-QDIO mode types are as follows:

TCP/IP PassthruIn TCP/IP Passthru mode, an OSA feature transfers data between a TCP/IP stack to which it is defined and clients on an Ethernet 10/100/1000 Mbps LAN that is attached to the port on a 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

For TCP/IP Passthru mode, the default OAT may be used. In that case, no configuration or setup is required. See Appendix F, “TCP/IP Passthru mode” on page 251 details.

SNA/APPN/HPR supportIn this mode, an OSA 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 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.


1.1.4 OSA addressing supportThis section describes the maximum number IP addresses, MAC addresses, and subchannels supported by the OSA features.

Maximum IP addresses per OATThe OSA Address Table (OAT) is a component of an OSA feature’s configuration. An OAT entry defines the data path between an OSA feature port and a logical partition (LP) and device unit address. That is, it manages traffic through the OSA CHPID.

OSA-Express features support a maximum of 2048 IP addresses (IPv4, IPv6, and VIPA) per CHPID, while OSA-Express3 and OSA-Express2 features support up to 4096 IP addresses per CHPID.

When the OSA CHPID is defined in QDIO mode, the OAT table entries are built and updated dynamically.

Maximum number of media access control (MAC) addressesWhen configured as OSD, up to 2048 MAC or virtual (VMAC) addresses are supported per CHPID with OSA features. Included in the maximum number of MAC addresses is the “burnt-in” MAC address of the OSA port.

The MAC or VMAC addresses are added to the Layer 2 table of the OAT when the TCP/IP stacks (in which the addresses are defined) are started.

Also see “Layer 2 support” on page 18 and “Layer 3 VMAC for z/OS” on page 20.

Maximum TCP/IP stacks and subchannelsA subchannel is a logical representation of a device. One subchannel is assigned to each device defined to the logical partition. Therefore, if you are sharing an OSA CHPID across 15 LPs and define one device, that device uses 15 subchannels.

The maximum number of supported TCP/IP stacks and subchannels on System z10 and System z9 servers are as follows:

� OSA CHPID in non-QDIO mode (type OSE)

An OSA CHPID in non-QDIO mode is capable of supporting up to 120 TCP/IP stacks and 240 subchannels for all System z servers.

� OSA CHPID in QDIO mode (type OSD)

The OSA features support 640 TCP/IP stack connections per dedicated CHPID, or 640 total stacks across multiple logical partitions using a shared or spanned CHPID. The maximum number of subchannels allowed is 1920 (1920 subchannels / 3 = 640 stacks).

Note: By default, OSA-Express3 and OSA-Express2 have multiple priorities for outbound queues enabled (four QDIO priorities). This means the maximum number of supported subchannels is reduced to 480 (1920 subchannels / 4 = 480 subchannels), thus reducing the total number of supported TCP/IP stacks to 160 (480 subchannels / 3 = 160 stacks).

Priority queues can be disabled via HCD/IOCP. For example, in IOCP use the CHPARM=02 value to disable priority queuing.


1.1.5 OSA/SF supportOSA/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 current Java runtimes are available.

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 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 z/VSE, 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 z/VSE. This version of OSA/SF is not being offered as a separately orderable program product.

The Open Systems Adapter Support Facility (OSA/SF) is used primarily to:

� Manage all OSA ports.� Configure all OSA non-QDIO ports.� Configure local MAC.� Display registered IPv4 addresses (in use and not in use). It is supported on System z

servers for QDIO ports.� Display registered IPv4 or IPv6 Virtual MAC and VLAN ID associated with all OSA

Ethernet features configured as QDIO Layer 2.� Provide status information about an OSA port - its “shared” or “exclusive use” state.

OSA/SF is an integrated component of z/VM.

This support is applicable to all OSA features on System z servers.

With z/OS, a second interface using a set of REXX EXECs through the Time Sharing Option Extensions (TSO/E) can be used to control the OSA features defined to System z servers on which the TSO/E is running.

OSA/SF is not always required to customize an OSA feature, but is highly recommended to gather operational information and to assist in problem determination. The OSA/SF Query function provides performance information about the OSA CHPIDs.

OSA/SF is not required to configure the OSA features in operating modes OSD, OSC, and OSN.

For details regarding OSA/SF, the GUI, and REXX EXECs, refer to Chapter 4, “Setting up and using OSA/SF” on page 47 and Appendix E, “Using the OSA/SF REXX interface” on page 241.

1.2 OSA capabilitiesThis section discusses the capabilities that exploit the OSA-Express3 and OSA-Express2 features.


1.2.1 Virtual IP address (VIPA)In the TCP/IP environment, VIPA frees TCP/IP hosts from dependence on a particular network attachment, allowing 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 Virtual IP Address, on the other hand, 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 will always be active, enabling users to route around intermediate points of failure in the network.

VIPA Takeover and TakebackSince 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 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 functionThe primary/secondary router function enables an OSA 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 feature.

In order for an OSA 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 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), will receive 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 Internet Protocol Version 6 (IPv6) is supported by the OSA features when configured in QDIO mode. IPv6 is the protocol designed by the Internet Engineering Task Force (IETF) to replace Internet Protocol Version 4 (IPv4). IPv6 provides improved traffic management in the following areas:

Important: Sharing a single OSA port can fail in Load Balancing solutions. A circumvention is to use GRE or NAT, which can have a negative effect on performance. Layer 3 virtual MAC is a function available on System z servers with OSA-Express. For more detailed information about Layer 3 VMAC for z/OS refer to “Layer 3 VMAC for z/OS” on page 20


� 128–bit addressing

Eliminates all practical limitations on global address ability. This 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

Allow for more efficient packet handling and reduced bandwidth cost.

� Hierarchical addressing and routing

Keep routing tables small and backbone routing efficient by using address prefixes rather than address classes.

� Improved support for options

Changes the way IP header options are encoded, allowing more efficient forwarding and greater flexibility.

� Address auto-configuration

Allows stateless IP address configuration without a configuration server. In addition, IPv6 brings greater authentication and privacy capabilities through the definition of extensions, and integrated Quality of Service (QoS) through a traffic class byte in the header.

1.2.4 Large send for TCP/IP trafficLarge send can improve performance by offloading TCP packet processing from the host to the OSA-Express3 or OSA-Express2 features running in QDIO mode. Offload allows the host to send large blocks of data (up to 64 kilobytes) directly to the OSA-Express3 or OSA-Express2 feature. The OSA-Express3 or OSA-Express2 feature then fragments those large blocks into standard Ethernet frames (1500 bytes) to be sent out on the LAN (see Figure 1-3).

Figure 1-3 Large send versus standard Ethernet and Jumbo frame sizes

Large send supports outbound IPv4 traffic only, and applies solely to unicasts. Large send support reduces host processor utilization, returning CPU cycles for application use while

.....

.....

.....

Ethernetframe

Jumboframe

TCP largesend

..

..

Applicationsend buffer

TCP Stack

OSA-Express2or

OSA-Express3

63 KB 63 KB 63 KB

1.5 KB

1.5 KB

1.5 KB

1.5 KB

1.5 KB

1.5 KB

9 KB

9 KB

9 KB9 KB

63 KB


increasing network efficiencies. Large send applies only to the OSA-Express3 and OSA-Express2 features.

Large send can be enabled by specifying the SEGMENTATIONOFFLOAD parameter within the GLOBALCONFIG block in your TCPIP profile member. The default is NOSEGMENTATIONOFFLOAD.

For more information about large send for Linux on System z, refer to:

http://www.software.ibm.com/developerworks/opensource/linux390

Large send support is also available with z/OS.

1.2.5 VLAN supportVirtual Local Area Network (VLAN) is supported by the OSA-Express3 and OSA-Express2 features when configured in QDIO mode. This support is applicable to z/OS, z/VM, and Linux on System z environments.

The IEEE standard 802.1q describes the operation of Virtual Bridged Local Area Networks. A VLAN is defined to be a subset of the active topology of a Local Area Network. The OSA 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 port. The number of VLANs supported is specific to the operating system.

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 z servers, where multiple TCP/IP stacks exist, potentially sharing one or more OSA features, VLAN support is designed to provide a greater degree of isolation (see Figure 1-4 on page 13).

Tip: Applications that use large TCP send buffers will obtain the most benefit from large send.




Figure 1-4 VLAN support

VLAN support for z/OSFull Virtual Local Area Network (VLAN) support is offered for all OSA Ethernet features available on System z servers. z/OS Communications Server supports Virtual Local Area Network Identifications (VLAN IDs). Support is offered for up to eight global VLAN IDs per OSA port, based on the IP version:

� Eight Global VLAN (IDs) for IPv4� Eight Global VLAN (IDs) for IPv6

VLAN support for z/VMz/VM exploits the VLAN technology and conforms to the IEEE 802.1q standard. Support is offered for one global VLAN ID per OSA port, based on the IP version:

� One Global VLAN (ID) for IPv4� One Global VLAN (ID) for IPv6

The z/VM TCP/IP stack supports one VLAN ID per OSA port. Each port can be configured with a different VLAN ID.

VLAN support for Linux on System zVLAN support in a Linux on System z environment is available for the OSA Ethernet features operating in QDIO mode.

For Linux on System z support, refer to the following Web site for further information:

http://www.ibm.com/developerworks

VLAN support of GVRPGVRP 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.

Common physical network

LP 1z/OS TCP/IP

IPv4VLAN 28

OSA-Express Ethernet ports in QDIO mode

port 1

LP 2z/OS TCP/IPIPv4 IPv6

VLAN16 VLAN37

LP 3Linux TCP/IPIPv6 IPv4

VLAN37 VLAN4

LP 4z/VM TCP/IP

IPv4VLAN12

VLAN28 VLAN16 VLAN4 VLAN12

port 2

Ethernet Switch



With GVRP support, an OSA-Express3 or OSA-Express2 port can register or de-register its VLAN IDs with a GVRP-capable switch and dynamically update its table as the VLANs change (Figure 1-5).

Figure 1-5 GVRP support

Support of GVRP is exclusive to System z. It is applicable to all of the OSA-Express3 and OSA-Express2 features when in QDIO mode (CHPID type OSD), and is supported by z/OS and z/VM.

More information on VLAN support can be found in Chapter 10, “VLAN support” on page 131.

1.2.6 SNMP support for z/OS and Linux on System zSNMP is supported for all of the OSA features when configured in the QDIO mode (CHPID type OSD). The OSA SNMP subagent support offered via the OSA features LIC includes:

� Get and GetNext requests

This support applies to all OSA features supported on System z servers.

� dot3StatsTable

Ethernet data for dot3StatsTable applies to all of the Ethernet features supported on System z servers. 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 applies to all of the OSA features supported on System z servers. The performance data reflects the OSA utilization.

� Traps and Set

This support applies to all of the OSA features supported on System z.

SNMP support for LAN Channel Station (LCS) applies to all of the OSA features supported on System z, 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 environment.

Physical LAN

OSA-Express2

VLAN22VLAN33VLAN44

GVRP support dynamically registers VLAN IDs to the physical LAN

VLAN44

Physical LAN

OSA-Express3

VLAN22VLAN33VLAN44

GVRP support dynamically registers VLAN IDs to the physical LAN

VLAN 22 VLAN33


For more information about SNMP support, refer to:

http://www.ibm.com/servers/eserver/zseries/networking/dsnmp.html

Open Systems Adapter Support Facility is not required to manage SNMP data for the OSA features. An SNMP subagent exists on an OSA feature, which is part of a direct path between the z/OS or Linux on System z master agent (TCP/IP stacks) and an OSA-Express Management Information Base (MIB).

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

Figure 1-6 SNMP support - z/OS example

1.2.7 TCP/IP multicast and broadcast supportMulticast and broadcast support is part of the Internet Protocol assist (IPA) function of the OSA feature.

Multicast supportFor sending data to multiple recipients, OSA features support IP multicast destinations only in QDIO or IP Passthru mode.

TCP/IP broadcast support for z/OS, z/VM, and Linux on System zBroadcast support is included for all of the OSA features when configured in QDIO mode and supporting the Routing Information Protocol (RIP) Version 1. Broadcast is also supported for all of the OSA features when carrying TCP/IP traffic and configured in the non-QDIO mode (LAN Channel Station - LCS mode).

Tip: If you subscribe to the document “OSA-Express Direct SNMP MIB module” through Resource Link™, you will receive e-mail notification of document changes.

OSNMPDSNMP Agent's Address Space

z/OS

System zOSA-Express

UNIX ShellUser's AddressSpaceosnmp command

Managers (clients)

z/OS

Agents (servers)

OSADdevicewithsubagent

OSA proxy Subagent

Tivoli NetViewAddress Space

SNMP command

TCP/IPAddress Space

TCP

SNMP Subagent


http://www.ibm.com/servers/eserver/zseries/networking/dsnmp.html

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 feature to all TCP/IP applications that require broadcast support, including applications using RIP V1.

1.2.8 ARP cache managementThe query and purge ARP enhancements are supported for all OSA features when configured in QDIO mode. The OSA 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, ARP does not have to be used repeatedly, and the OSA feature does not have to keep a permanent record of bindings.

Query ARP table for IPv4 for Linux on System zThe Query ARP table is supported using Internet Protocol Version 4 (IPv4). The TCP/IP stack already has an awareness of Internet Protocol Version 6 (IPv6) addresses.

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

ARP takeoverARP takeover provides the capability of switching OSA port operations from one OSA to another OSA running in the same mode in z/OS environments.

When z/OS TCP/IP is started in QDIO mode, it downloads all the home IP addresses in the stack and stores them in each OSA feature to which it has a connection. This is a service of QDIO architecture and only occurs automatically for OSD channels. For OSA ports set up as OSE channels (non-QDIO), you must define multiple IP addresses in the OSA Address Table using OSA/SF. The OSA then responds to ARP requests for its own IP address, as well as for virtual IP addresses (VIPAs). If an OSA feature fails while there is a backup OSA available on the same network or subnetwork, TCP/IP informs the backup OSA 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. See Appendix H, “ARP takeover” on page 269 for more information.

ARP statisticsQDIO includes an IP assist (IPA) function, which gathers Address Resolution Protocol (ARP) data during the mapping of IP addresses to media access control (MAC) addresses. CHPIDs defined as OSD maintain ARP cache information in the OSA feature (ARP offload). This is useful in problem determination for the OSA feature.

Note that not all OSA features provide ARP counter statistics and ARP cache information to TCP/IP.

1.2.9 IP network availabilityThere are several ways to ensure network availability, should failure occur at either the logical partition or the CHPID/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 feature. This is a service of QDIO architecture. The OSA port then responds to ARP requests for its own IP address, as well as for virtual IP addresses (VIPAs). If an OSA feature fails while there is a backup OSA available on the same network or subnetwork, TCP/IP informs the backup OSA port which IP addresses (real and VIPA) to take over, and sends a gratuitous ARP that 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 on System zz/OS and Linux on System z environments provide the capability of calculating and validating the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) and Internet Protocol (IP) header checksums. Checksums are used to verify the contents of files when transmitted over a network. For example:

� OSA will validate the TCP, UDP, and IP header checksums for inbound packets.� OSA will calculate the TCP, UDP, and IP header checksums for outbound packets.

Checksum offload is supported by all OSA Ethernet features when operating in QDIO mode.

By offloading checksum processing to the supporting OSA features, host server cycles are reduced, which can result in improved performance for most IPv4 packets.

When checksum is offloaded, the OSA feature performs the checksum calculations. Therefore, this function only applies to packets which actually go onto the LAN or come in from the LAN. When multiple IP stacks share an OSA port, and an IP stack sends a packet to a next hop IP address owned by another IP stack sharing the same OSA port, OSA sends the IP packet directly to the other IP stack without placing it out 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 will continue to perform processing for ICMP checksum.

Checksum offload support is available with z/OS.

For Linux on System z support, refer to the following Web site for further information:


Dynamic LAN idle for z/OS Dynamic LAN idle is exclusive to System z servers and applies to the OSA-Express3 and OSA-Express2 features (CHPID type OSD), and is supported by z/OS.

Dynamic LAN idle is designed to reduce latency and improve networking performance by dynamically adjusting the inbound blocking algorithm. When enabled, the z/OS TCP/IP Stack will adjust the inbound blocking algorithm to best match the application requirements.

For latency sensitive applications, the blocking algorithm is modified to be “latency sensitive.” For streaming (throughput sensitive) applications, the blocking algorithm is adjusted to maximize throughput. In all cases, the z/OS TCP/IP stack dynamically detects the application requirements, making the necessary adjustments to the blocking algorithm. The monitoring of the application and the blocking algorithm adjustments are made in real-time, dynamically adjusting the application’s LAN performance.

Note: Linux on System z only supports inbound checksum offload (inbound packets).



System administrators can authorize the z/OS TCP/IP stack to enable a dynamic setting, which was previously a static setting. The z/OS TCP/IP stack dynamically determines the best setting for the current running application, based on system configuration, system, inbound workload volume, CPU utilization, traffic patterns, and other related items.

1.2.11 Layer 2 support The OSA Ethernet features on System z 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 works in conjunction with either z/VM TCP/IP or Linux on System z Layer 2 support running in a Logical Partition or as a z/VM guest.

The z/VM virtual switch can also be used to enable Layer 2 functionality for guest systems; this is illustrated in Figure 1-7.

Figure 1-7 Layer 2 support for OSA-Express

The virtual switch exploits both Layer 2 and Layer 3 support in the z/VM Control Program. For Layer 2 support, the z/VM Control Program owns the connection to the OSA 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, providing the ability to transport both IP and non-IP (for example, NetBIOS and SNA) frames through the fabric that the virtual switch supports. Through the address-resolution process each guest system’s MAC address becomes known to hosts residing on the physical side of the LAN segment. All inbound or outbound frames passing through the OSA port have the guest system’s corresponding MAC address as the source or destination address.

The OSA Ethernet features can filter inbound frames by Virtual Local Area Network identification (VLAN ID, IEEE 802.1q), the Ethernet destination MAC address, or both.

02-00-00-00-00-01

z/VMguest

Virtual Switch (Layer 2)

Linuxguest

Linux

OSA-Express

02-00-00-00-00-02

02-00-00-00-00-03

z/VM

02-00-00-00-00-0102-00-00-00-00-0202-00-00-00-00-03

NetBIOSAppl.

SNAAppl.

TCP/UDPAppl.

Ethernet Switch


Filtering can reduce the amount of inbound traffic being processed by the operating system, helping to reduce CPU utilization. Filtering by VLAN ID or MAC address can also allow you to isolate portions of your environment that have sensitive data, thereby providing a degree of low-level security.

Link aggregation for z/VM in Layer 2 modeLink aggregation is exclusive to System z and is applicable to the OSA-Express2 and OSA-Express3 features in Layer 2 mode when configured as CHPID type OSD (QDIO), and is supported by z/VM.

z/VM virtual switch-controlled (VSWITCH-controlled) link aggregation (IEEE3 802.3ad) allows you to dedicate an OSA-Express3 or OSA-Express2 port to the z/VM operating system when the port is participating in an aggregated group when configured in Layer 2 mode. Link aggregation (trunking) is designed to allow you to combine multiple physical OSA-Express3 or OSA-Express2 ports into a single logical link for increased throughput and for nondisruptive failover in the event that a port becomes unavailable.

Link aggregation for z/VM in Layer 2 mode functions as follows:

� Aggregated links are viewed as one logical trunk and contain all of the Virtual LANs (VLANs) required by the LAN segment.

� Link aggregation is between a VSWITCH and the physical network switch.� Load balance communications is across multiple links in a trunk to prevent a single link

from being overrun.� Up to eight OSA-Express3 or OSA-Express2 ports are supported in one aggregated link.� Ability to dynamically add/remove OSA ports for “on demand” bandwidth.� Full-duplex mode (send and receive).

1.2.12 QDIO data connection isolationThe QDIO data connection isolation function provides a higher level of security on System z10 and System z9 servers when sharing the same OSA port in z/VM environments that use the virtual switch (VSWITCH). The VSWITCH is a virtual network device that provides switching between OSA ports and the connected guest systems.

QDIO data connection isolation (also known as VSWITCH port isolation), allows you to disable the internal routing on a per QDIO connection basis, providing a means for creating security zones and preventing network traffic between the zones. For example, this function will ensure that traffic to an external network is forced to flow only between a guest operating system and the external network (see Figure 1-8 on page 20).

Note: Target links for aggregation must be of the same type (for example, Gigabit Ethernet to Gigabit Ethernet).


Figure 1-8 VSWITCH port isolation

As shown in Figure 1-8, when in isolation mode, data traffic destined for a guest system port in the VSWITCH will be blocked, while traffic going to an external host will be sent to the OSA port for delivery. The isolation options (ON or OFF) can be set via the SET VSWITCH ISOLATION command.

QDIO data connection isolation is supported by all OSA-Express3 and OSA-Express2 features on System z10, and by all OSA-Express2 features on System z9, with an MCL update. Refer to the appropriate Preventive Service Planning bucket for details regarding your System z server.

For more detailed information about the VSWITCH, refer to Chapter 11, “z/VM virtual switch” on page 151.

1.2.13 Layer 3 VMAC for z/OSTo help simplify the infrastructure and provide load balancing when a logical partition is sharing the same OSA MAC address with another logical partition, each operating system instance can now have its own unique virtual MAC (VMAC) address. All IP addresses associated with a TCP/IP stack are accessible using their own VMAC address, instead of sharing the MAC address of an OSA port. This applies to Layer 3 mode and to an OSA port shared among logical partitions.

This support is designed to:

� Improve IP workload balancing� Dedicate a Layer 3 VMAC to a single TCP/IP stack� Remove the dependency on Generic Routing Encapsulation (GRE) tunnels� Improve outbound routing� Simplify configuration setup� Allow z/OS to use a standard interface ID for IPv6 addresses� Allow WebSphere® Application Server content-based routing to support an IPv6 network

Ethernet Switch

z/OSGuest

Virtual Switch port isolation

LinuxGuest

OSA-Express3

z/VM LPAR

z/OSGuest

LinuxGuest


� Eliminate the need for PRIROUTER/SECROUTER function in z/OS

OSA Layer 3 VMAC for z/OS is applicable to OSA Ethernet features when configured as CHPID type OSD (QDIO).

1.2.14 Enterprise ExtenderThe Enterprise Extender (EE) function of z/OS Communications Server allows you to run SNA applications and data on IP networks and IP-attached clients. It can be used with any OSA feature running IP traffic. EE is a simple set of extensions to the open High Performance Routing technology that integrate HPR frames into User Datagram Protocol/Internet Protocol (UDP/IP) packets, providing:

� 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 port to Communications Server) to another endpoint where it is de-encapsulated and presented to an SNA application.

EE requires APPN/HPR at the endpoints. In order 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.

Refer to the Enterprise Extender Implementation Guide, SG24-7359 for more information.

1.2.15 TN3270E ServerThe 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 SSL and Client Authentication via RACF®� Over 64,000 sessions per server when using multiple ports� Over 2,000 transactions/second with sub-second response time� Reconnect 16 K sessions in less than a 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

z/OS Communications Server also supports a secure, RACF-based single sign-on 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/submission to the application.


For more information about the TN3270E server, based on your release, refer to Communications Server for z/OS TCP/IP Implementation Volume 2: Standard Applications:

� SG24-7533 for z/OS V1R9� SG24-7340 for z/OS V1R8 � SG24-7170 for z/OS V1R7

1.2.16 OSA for NCP supportOpen Systems Adapter for NCP (OSA for NCP) support is available on System z10 and System z9 servers. It provides channel connectivity from the operating systems to the Communication Controller for Linux on System z (CCL) image, using OSA-Express3 and OSA-Express2 Ethernet features with CHPID type OSN. Each operating system that currently supports Channel Data Link Control (CDLC) can utilize this connectivity option without changes to the operating system. OSN supports both SNA PU Type 5 and PU Type 2.1 channel connectivity.

OSA for NCP can help eliminate the requirement for having an external medium (and all related hardware) for communications between an operating system and the CCL image in the same System z server. Traffic between the logical partitions (operating system and CCL) is no longer required to flow on the Local Area Network (LAN) or ESCON® channel.

Utilizing 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 z/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:

� 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 though they were running in an ESCON-attached 374x Communications Controller.

� Enables NCP channel-related functions such as loading and dumping of 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 devices).

� Can span channel subsystems.

OSN support is exclusive to System z servers, and is supported by z/OS, z/VM, z/VSE, z/TPF, and Linux on System z.

Figure 1-9 on page 23 shows the traffic flow on a System z server between VTAM on a z/OS logical partition or z/TPF logical partition communicating with the CCL running as a guest under z/VM in a separate logical partition. Note that one OSA CHPID type OSN is used. On the z/OS or z/TPF side, it is defined as CDLC, while on the CCL side it is defined as QDIO (QETH). A second OSA CHPID type OSD is defined as QETH and is used to communicate with SNA devices on the LAN.


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

For more information about CCL, refer to IBM Communication Controller for Linux on System z V1.2.1 Implementation Guide, SG24-7223, and the following URL:

http://www.ibm.com/software/network/ccl

z/OS, z/TPFLinux on System z

OSD or OSE

OSN

NCPCCL

VTAM

CDLC

Traffic between CCL and LAN environmentTraffic between the LPs


http://www.ibm.com/software/network/ccl

Chapter 2. Quick start

This chapter provides information to help you achieve a quick start with your OSA installation. It assists you in determining which elements you need based on your requirements. It also directs you to the appropriate sections in this book for details.

The topics covered in this chapter include:

� Software support

� OSA definitions

� OSA/SF requirements

� Quick start tables

� Policy-based networking

2


2.1 Software supportTable 2-1 summarizes the OSA functions and feature with their minimum required operating system support levels for z/OS and z/VM. For the most current information, refer to the appropriate Preventive Service Planning (PSP) bucket for your server.

The following conventions are used:

Y The function is supported.N The function is not supported.- The function is not applicable to that specific operating system.x The function is supported on this System z server.

Table 2-1 OSA functions minimum support requirements summary - z/OS and z/VM

Functionz1

0

z9

z/OS V1R10

z/OS V1R9

z/OS V1R8

z/OS V1R7

z/VM V5R4

z/VM V5R3

z/VM V5R2

ARP takeover x x Y Y Y Y Y Y Y

ARP cache management x x Y Y Y Y - - -

Checksum offload support (IPv4 only) x x Y Y Y Y N N N

SNMP support x x Y Y Y Y - - -

Internet Protocol Version 6 (IPv6) support x x Y Y Y Y Y Y Y

Large send support x x Y Y Y Y - - -

Layer 2 support x x - - - - Y Y Y

Layer 3 VMAC for z/OS x x Y Y Y N Ya Yab Yab

640 TCP/IP stacks (with priority queues disabled)

x x Y Y Y Y Y Y Y

Concurrent LIC update x x Y Y Y Y Y Y Y

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

Multicast and broadcast support x x Y Y Y Y Y Y Y

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

VLAN (IEEE 802.1q) support x x Y Y Y Y Y Y Y

VLAN support of GVRP x x Y Y Y Y Y Y Y

Jumbo frame support (8992 byte frame size)

x x Y Y Y Y Y Y Y

QDIO Diagnostic Synchronization for z/OS x x Y Y Y N Yb Yb Yb

Network Traffic Analyzer for z/OS x x Y Y Y N Yb Yb Yb

Dynamic LAN Idle for z/OS x x Y Y Y N Yb Yb Yb

Link aggregation for VSWITCH (Layer 2) x x - - - - Y Y N

QDIO data connection (port) isolation x x - - - - Yb Yb Yb

OSA-Express3 10 Gigabit Ethernet LR CHPID type OSD

x Y Y N N Y Y Y


OSA-Express3 10 Gigabit Ethernet SR CHPID type OSD

x Y Y Y Y Y Y Y

OSA-Express3 Gigabit Ethernet LXusing two ports per CHPID types OSD

x Y Ya Ya N Y Ya Ya

OSA-Express3 Gigabit Ethernet LXusing one port per CHPID type OSD

x Y Y Y Y Y Y Y

OSA-Express3 Gigabit Ethernet SXusing two ports per CHPID type OSDOSA-Express3-2P Gigabit Ethernet SX(using two ports per CHPID type OSD)

x Y Ya Ya N Y Ya Ya

OSA-Express3 Gigabit Ethernet SXusing one ports per CHPID type OSDOSA-Express3-2P Gigabit Ethernet SXusing one ports per CHPID type OSD

x Y Y Y Y Y Y Y

OSA-Express3 1000BASE-T Ethernetusing two ports per CHPID type OSDOSA-Express3-2P 1000BASE-T Ethernetusing two ports per CHPID type OSD

x Y Ya Ya N Y Ya Ya

OSA-Express3 1000BASE-T Ethernetusing one ports per CHPID type OSDOSA-Express3-2P 1000BASE-T Ethernetusing one ports per CHPID type OSD

x Y Y Y Y Y Y Y

OSA-Express3 1000BASE-T Ethernetusing two ports per CHPID type OSEOSA-Express3-2P 1000BASE-T Ethernetusing two ports per CHPID type OSE

x Y Y Y Y Y Y Y

OSA-Express3 1000BASE-T Ethernetusing one port per CHPID type OSE OSA-Express3-2P 1000BASE-T Ethernetusing one port per CHPID type OSE

x Y Y Y Y Y Y Y

OSA-Express2 10 Gigabit Ethernet LRCHPID type OSD

x x Y Y Y Y Y Y Y

OSA-Express2 Gigabit Ethernet LX CHPID type OSD

x x Y Y Y Y Y Y Y

OSA-Express2 Gigabit Ethernet SXCHPID type OSD

x x Y Y Y Y Y Y Y

OSA-Express2 1000BASE-T EthernetCHPID type OSD

x x Y Y Y Y Y Y Y

OSA-Express2 1000BASE-T Ethernet CHPID type OSE

x x Y Y Y Y Y Y Y

a. Support for guest use onlyb. PTFs required

Function

z10

z9

z/OS V1R10

z/OS V1R9

z/OS V1R8

z/OS V1R7

z/VM V5R4

z/VM V5R3

z/VM V5R2

Chapter 2. Quick start 27

Linux on System z For information about software support for Linux on System z distributions, go to:

� Novell® SUSE®:

http://www.novell.com/linux/mainframe/

� Red Hat®:

http://www.redhat.com/

2.2 OSA definitionsBefore you can exploit your OSA feature, you must first properly define your hardware and software for it. In doing so, you need to answer the following questions:

� What is the physical channel identifier (PCHID) assigned to the OSA ports?� To which channel path identifier (CHPID) will the OSA ports be assigned?� Will the OSA CHPID be shared or dedicated?� To which channel subsystem (CSS) will OSA CHPID be defined?� Will the OSA CHPID be spanned across CSSs?� Which OSA CHPID type will be required?� Which network protocol or protocols will be used with the OSA CHPID?

OSA device typesThe 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 devices, for the OSA for NCP (OSN) CHPID type

Refer to the z/OS quick start table (Table 2-5 on page 32), which provides a quick reference for relating the CHPID type to an operation mode.

The OSA/SF program product requires one device (defined via HCD) to be associated with the OSA CHPID as device type OSAD (UNITADD=FE). OSA/SF uses this device to communicate with the OSA feature.

The OSA-Express Network Traffic Analyzer for z/OS requires one or more data path devices for the OSAENTA trace interface, depending on the configuration.

Multiple Image Facility (MIF)Multiple Image Facility enables OSA CHPIDs installed on System z servers to be shared among logical partitions.

Spanned channelsOSA CHPIDs can be spanned across multiple channel subsystems (CSSs) on System z servers. Spanning is the ability to configure channels to multiple CSSs. When defined that way, the channels can be transparently shared by any or all of the configured logical partitions, regardless of the CSS to which the logical partition is configured.

For more information about defining the OSA to hardware, refer to Chapter 3, “Hardware configuration definitions” on page 35.


http://www.novell.com/linux/mainframe/



2.2.1 Modes of operation and addressing support The OSA features provide direct LAN connectivity as integrated features of System z. This brings the strengths of System z and z/Architecture® to the client/server environment.

Table 2-2 summarizes the OSA features as they relate to the different modes of operation and maximum addressing ranges supported by System z servers.

Table 2-2 OSA modes of operation and addressing support

2.3 OSA/SF requirementsOpen Systems Adapter Support Facility (OSA/SF) is used to configure OSA features for non-QDIO mode, with one exception, the TCP/IP Passthru mode (non-shared).

OSA-Express OSA-Express2 OSA-Express3a

a. Applies to System z10 only

Addresses

IP addresses per CHPID 2048 4096 4096

Multicast addresses 1024 2048 2048

ARP table size 8192 16384 16384

MAC addresses 2048b

b. Supported by Ethernet features only (excluding FC 2366)

2048 2048

non-QDIO (OSE)

Subchannels per TCP/IP link 2 2c 2c

c. 1000BASE-T feature only

TCP/IP stacks per CHPID 120 120c 120c

SNA PUs per CHPID 4096 4096c 4096c

Subchannels per CHPID 240 240c 240c

CUs per CHPID 1 1c 1c

QDIO (OSD)

Subchannels per TCP/IP link 3 3 3

TCP/IP stacks per CHPID 84 / 160 640d

d. If multiple priority queues are enabled, the maximum is reduced to 160 TCP/IP stacks and480 subchannels per CHPID.

640d

Subchannels per CHPID 254 / 480 1920d 1920d

CUs per CHPID 1 / 16 16 16

Note: The ARP table and multicast addresses are obtained from the same storage pool. The overall capacity limit for both tables is the sum of the IPv4 addresses, plus the IPv6 addresses, plus the IPv4 multicast addresses, plus the IPv6 multicast addresses, and the IPv4 remote addresses. While the maximum number of multicast addresses is 2048, if there are a large number of other addresses that make up the same storage pool, the amount of multicast addresses might be less than 2048. Keep in mind that some operating systems generate a multicast address for each IPv6 address specified.


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

Table 2-3 OSA/SF requirement for configuring OSA features

In addition, OSA/SF can be very useful for problem determination purposes for OSA ports in either QDIO or non-QDIO mode.

2.4 Quick start tablesThis section provides tables to help you identify your OSA feature and implementation requirements. These tables direct you to installation information and setup examples.

For more information about the different types of OSA features, refer to Appendix A, “OSA features” on page 187.

2.4.1 OSA function supportTable 2-4 lists the functions that are supported based on an OSA feature.

Table 2-4 OSA function support

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

10 GbE LR10 GbE SR

Yes Dynamic No

GbEGbE 2P

Yes Dynamic No

1000BASE-T Ethernet1000BASE-T 2P Ethernet

Yes Dynamic No

Yes Manual Yes

OSA-Express2 and OSA-Express3

OSA-Express

Function

10 G

bE

Gb

E

1000

BA

SE

-T

Gb

E

1000

BA

SE

-T

ARP takeover x x xa x xa

ARP cache management x x xa x xa

Checksum offload support (IPv4 only) x x xa x xa

SNMP support x x x x x

Internet Protocol Version 6 (IPv6) support x x xa x xa

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

Layer 2 support x x xa x xa

Layer 3 VMAC for z/OS x x x x x

Concurrent LIC update x x x n/a n/a

Primary/secondary router function x x x x x


2.4.2 Quick start tables for z/OS and z/VMWhen reviewing Table 2-5 or Table 2-6 on page 32, keep the following considerations in mind for your OSA implementation:

� If you are using the default OAT for the OSA 1000BASE-T features, OSA/SF is not required. The default OAT values only allow the following:

– Non-shared CHPID (port is not shared between logical partitions (LPAR)).– CHPID type OSE (non-QDIO).– Ports not shared between TCP/IP stacks.– TCP/IP and SNA do not share a port concurrently.– The default unit addresses (starting with 00).– TCP/IP Passthru only.

� The OSA/SF configuration is not required for OSA features when defined as CHPID types OSC, OSN, and OSD.

� If SNA and APPN (LU6.2) are required for an OSA feature that is defined as CHPID type OSD, you must use Enterprise Extender.

� Layer 2 support for an OSA feature that is defined as CHPID type OSD allows for communication with IP and non-IP protocols, such as NetBIOS, SNA, and others.

� OSA features can also work in conjunction with the virtual switch (a component of z/VM) to enable Layer 2 functionality for guest systems, such as Linux on System z. See Chapter 11, “z/VM virtual switch” on page 151.

� You can use TN3270 in conjunction with SNA (LU2) applications, when the OSA feature is defined as CHPID type OSD.

Multicast and broadcast support x x x x x

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

VLAN (IEEE 802.1q) support x x xa x xa

VLAN support of GVRP x x xa n/a n/a

Jumbo frame support (8992 byte frame size) x x x x x

QDIO Diagnostic Synchronization for z/OS x x xa n/a n/a

Network Traffic Analyzer for z/OS x x xa n/a n/a

Dynamic LAN Idle for z/OS x x xa n/a n/a

Link Aggregation for z/VM Layer 2 mode x x xa n/a n/a

QDIO data connection isolation x x xa n/a n/a

a. Only in QDIO mode

OSA-Express2 and OSA-Express3

OSA-Express

Function

10 G

bE

Gb

E

1000

BA

SE

-T

Gb

E

1000

BA

SE

-T


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

Table 2-5 z/OS quick start table

z/VM quick start tableTable 2-6 contains CHPID and TCP/IP definitions to use when you configure the OSA ports for use in a z/VM environment. It also provides references to the appropriate sections in this publication.

Table 2-6 z/VM quick start table

For your z/VM and guest system environment consider using the virtual switch in conjunction with your OSA and LAN environment. The virtual switch provides IEEE802.3 capabilities such as VLAN and link aggregation support, as well as port isolation. See Chapter 11, “z/VM virtual switch” on page 151 for details.

2.5 Policy-based networkingThe z/OS Policy Agent (PAGENT) is not required for OSA. The PAGENT is a component in z/OS that is responsible for implementing policy decisions. Policy Agent enforces a set of rules and policies that dictate how users, applications, and organizations can access and use

OSA feature Operation mode

CHPID type

TCP/IP device type

TCP/IP link type VTAM definitions

Go to...

10 GbE LR10 GbE SR

QDIOTCP/IP

OSD MPCIPA IPAQENET TRLEChapter 5, “QDIO mode for z/OS” on page 67GbE

GbE 2PQDIOTCP/IP

OSD MPCIPA IPAQENET TRLE

1000BASE-T1000BASE-T 2P

QDIOTCP/IP

OSD MPCIPA IPAQENET TRLE

Non-QDIOTCP/IP

OSE LCS ETHERNet, 802.3, or ETHEROR802.3

Chapter 7, “Non-QDIO mode for z/OS” on page 85

Non-QDIOSNA

OSE XCA, SWNET

OSA feature Operation mode

CHPID type

TCP/IP device type

TCP/IP link type VTAM definitions

Go to...

10 GbE LR10 GbE SR

QDIOTCP/IP

OSD OSD QDIOETHERNETChapter 6, “QDIO mode for z/VM” on page 77GbE

GbE 2PQDIOTCP/IP

OSD OSD QDIOETHERNET

1000BASE-T1000BASE-T 2P

QDIOTCP/IP

OSD OSD QDIOETHERNET

Non-QDIOTCP/IP

OSE LCS ETHERNET, 802.3 or ETHEROR802.3

Chapter 8, “Non-QDIO mode for z/VM” on page 107Non-QDIO

SNAOSE XCA and

SWNET


IT resources. From an OSA perspective you can set up policies to manage and prioritize network traffic. For information about PAGENT from the OSA perspective, see “Priority queuing” on page 5. For more detailed information about the PAGENT, refer to Communications Server for z/OS V1R9 TCP/IP Implementation Volume 4: Security and Policy-Based Networking, SG24-7536.


Chapter 3. Hardware configuration definitions

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

Your IBM representative can supply a physical channel identifier (PCHID) Report that specifies where the OSA feature is plugged into your server. The CHPID number and PCHID number are required for all OSA configuration and setup tasks.

3


3.1 Configuration chartThe environment shown in Figure 3-1 uses one System z10 server configured with two logical partitions (LPARs) and two CSSs. Server SCZP202 has two OSA-Express3 1000BASE-T features. We defined one CHPID to PCHID 1C1 and one CHPID to PCHID 231 (CHPID 0A and 0B, respectively). The CHPIDs were spanned across two CSSs.

Figure 3-1 HCD definitions for OSA CHPIDs

3.2 Hardware Configuration DefinitionHCD is used to define OSAs to the I/O hardware configuration. Examples of the following definitions are included:

� Channel path� Control unit� Devices

LPARSC81

SCZP202

CSS 0

LPARVMLINUX3

PCHID 1C1CHPID 0A

OSDE200 - E20F

Port 1 Port 0

PCHID 231CHPID 0B

OSD2D80 - 2D8F

Port 1 Port 0

z/VM V5R4z/OS V1R10

Ethernet

CSS 1


3.2.1 Channel path definitionWe created our definitions on a z/OS V1R10 system. Starting from the HCD main menu panel (Figure 3-2), follow these steps:

1. Select option 1 and press Enter.

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.

z/OS V1.10 HCD Command ===> ________________________________________________________________ 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 . . . 'OSARES1.IODF16.WORK' +

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.

Chapter 3. Hardware configuration definitions 37

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.

Figure 3-4 Channel subsystem list

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 on page 39.

a. We defined 0A for the CHPID and 1C1 as the PCHID.

b. For Channel path type, we specify OSD, because we are defining an OSA-Express3 1000BASE-T, which supports QDIO.

c. For Operation mode, we specify SPAN, because the feature will be shared among LPARs and CSSs.

d. For description, we recommend that you use a meaningful description to serve as a reference point in HCD.

e. Press Enter.

Goto Filter Backup Query Help ------------------------------------------------------------------------------ Processor List Row 1 of 9 More: > Command ===> _______________________________________________ Scroll ===> PAGE Select one or more processors, then press Enter. To add, use F11. / Proc. ID Type + Model + Mode+ Serial-# + Description _ B706STP1 2097 E26 LPAR __________ ________________________________ _ B706STP2 2097 E26 LPAR __________ ________________________________ _ ISGSYN 2064 1C7 LPAR __________ ________________________________ _ ISGS11 2064 1C7 LPAR __________ ________________________________ _ SCZP101 2094 S18 LPAR 02991E2094 ________________________________ _ SCZP201 2097 E26 LPAR 01DE502097 ________________________________ s SCZP202 2098 E10 LPAR 052B622098 ________________________________ _ SCZP801 2064 1C7 LPAR 010ECB2064 ________________________________ _ SCZP901 2084 C24 LPAR 026A3A2084 ________________________________

Goto Backup Query Help ------------------------------------------------------------------------------ Channel Subsystem List Row 1 of 2 Command ===> _______________________________________________ Scroll ===> PAGE Select one or more channel subsystems, then press Enter. To add, use F11. Processor ID . . . : SCZP202 CSS Devices in SS0 Devices in SS1 / ID Maximum + Actual Maximum + Actual Description s 0 65280 6774 65535 0 ________________________________ _ 1 65280 5736 65535 0 ________________________________


Figure 3-5 Add Channel Path display

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 subchannels” on page 8.

Figure 3-6 Allow TCP/IP stacks

Note: This example shows how to configure an OSA-Express3 1000BASE-T feature. The process is identical for the other OSA-Express3 or OSA-Express2 features, including:

� The Channel path type must be OSD for QDIO support, or OSE for non-QDIO support. The OSA-Express3 and OSA-Express2 1000BASE-T features also support the Integrated Console Controller (OSC).

� The Operation mode must be DED to dedicate the OSA CHPID to a single LPAR, SHR to share among LPARs, or SPAN to share among LPARs in different CSSs

_________________________Add Channel Path___________________________

Specify or revise the following values. Processor ID . . . . : SCZP202 Configuration mode . : LPAR Channel Subsystem ID : 0 Channel path ID . . . . 0A + PCHID . . . 1C1 Number of CHPIDs . . . . 1 Channel path type . . . OSD + Operation mode . . . . . SPAN + Managed . . . . . . . . No (Yes or No) I/O Cluster ________ + Description . . . . . . OSA-Express3 1000BASE-T_________ Specify the following values only if connected to a switch: Dynamic entry switch ID __ + (00 - FF) Entry switch ID . . . . __ + Entry port . . . . . . . __ +

___________Allow for more than 160 TCP/IP stacks______

Specify Yes to allow more than 160 TCP/IP stacks, otherwise specify No. Specifying Yes will cause priority queuing to be disabled. Will greater than 160 TCP/IP stacks be required for this channel? . . . No


8. Complete the access list for the partitions sharing the channel, as shown in Figure 3-7. In this example, two partitions share the OSA CHPID in CSS 0.

Figure 3-7 Access list definition panel

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 definitionFrom 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-8), enter the required information.

a. For Control unit number, we chose E200.b. Control unit type must be OSA.c. Press Enter.

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

______________________________ Define Access List ________________________

Select one or more partitions for inclusion in the access list. Channel subsystem ID : 0 Channel path ID . . : 0A Channel path type . : OSD Operation mode . . . : SPAN Number of CHPIDs . . : 1 / CSS ID Partition Name Number Usage Description / 0 A01 1 OS SC81 alternate _ 1 A11 1 CF CF8C / 1 A12 2 OS VMLINUX3 alternate

_________________________ Add Control Unit _____________________

Specify or revise the following values. Control unit number . . . . E200 + Control unit type . . . . . OSA__________ + Serial number . . . . . . . __________ Description . . . . . . . . ________________________________ 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


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

Figure 3-9 Processor selection

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

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

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

3.2.3 Device definitionFrom 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.

Select Processor / CU Row 14 of 22 More: > Command ===> _______________________________________________ Scroll ===> PAGE 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------ _ SCZP201.0 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP201.1 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP201.2 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP201.3 _______ _______ _______ _______ _______ _______ _______ _______ S SCZP202.0 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP202.1 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP801 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP901.0 _______ _______ _______ _______ _______ _______ _______ _______ _ SCZP901.1 _______ _______ _______ _______ _______ _______ _______ _______

______________________________ Add Control Unit ___________________________

Specify or revise the following values. Control unit number . : E200 Type . . . . . . : OSA Processor ID . . . . . : SCZP202 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 . _ + (1, 2 or 3)


3. In the Add Device display, enter the required information as shown in Figure 3-11.

a. For Device number, we choose E200.b. For Number of devices, we choose 15.c. Device type must be OSA.d. Press Enter.

Figure 3-11 Add Device display

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.

________________________________Add Device____________________________

Specify or revise the following values. Device number . . . . . . . . E200 + (0000 - FFFF) Number of devices . . . . . . 15__ Device type . . . . . . . . . OSA__________ + Serial number . . . . . . . . __________ Description . . . . . . . . . OSA-Express3 1000BASE-T_________ Volume serial number . . . . . ______ (for DASD) Connected to CUs . . E200 ____ ____ ____ ____ ____ ____ ____ +

Question: How many devices should you define?

The answer depends on the CHPID type, the number of TCP/IP stacks, the usage of the OSA-Express Network Traffic Analyzer and SNA definitions required. For the number of devices, consider the following:

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

� If you plan to use the OSA-Express Network Traffic Analyzer (OSAENTA) function, you will need one additional data device. This data device is used to transmit the captured trace data to TCP/IP over a QDIO data device.

� Any OSE CHPID requires two devices (read and write) for each TCP/IP. SNA requires one device.


5. Now the Device / Processor Definition panel (Figure 3-12) is displayed. Type a slash mark (/) next to the processor that you want to select. Then press Enter.

Figure 3-12 Device / Processor Definition display

6. In the panel shown in Figure 3-13, 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.

Figure 3-13 Define Device / Processor display

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.

______________________ Device / Processor Definition ____________________

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 SS+ UA+ Time-Out STADET CHPID + Explicit Null / SCZP202.0 _ __ No No __ No ___

___________________________Define Device / Processor_________________________

Specify or revise the following values. Device number . . . : E200 Number of devices . . . . : 15 Device type . . . . : OSA Processor ID . . . . : SCZP202 Channel Subsystem ID : 0 Subchannel set 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)


12.In the Add Device display, define the new device as shown in Figure 3-14.

Figure 3-14 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-15. Press Enter.

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

__________________________________Add Device_________________________

Specify or revise the following values. Device number . . . . . . . . E20F + (0000 - FFFF) Number of devices . . . . . . 1___ Device type . . . . . . . . . OSAD_________ + Serial number . . . . . . . . __________ Description . . . . . . . . . OSA/SF device______________ Volume serial number . . . . . ______ (for DASD) Connected to CUs . . E200 ____ ____ ____ ____ ____ ____ ____ +

___________________________Define Device / Processor______________________

Specify or revise the following values. Device number . . . : E20F Number of devices . . . . : 1 Device type . . . . : OSAD Processor ID . . . . : SCZP202 Channel Subsystem ID : 0 Subchannel set 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)


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

Figure 3-16 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-17), provide the values for the features you want for this device. Then press Enter.

Figure 3-17 Defining Device Parameters / Features display

_____________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 SS Description Defined_ ALLDEV MVS All devices / L06RMVS1 MVS Sysplex systems _ MVSW1 MVS Production systems _ OPENMVS1 MVS OpenEdition MVS _ TEST2094 MVS Sysplex systems

______________________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 IPLDYNAMIC Yes Device has been defined to be dynamic LOCANY No UCB can reside in 31 bit storage


3.2.4 Generating the input IOCDS from HCDYou can generate input for IOCDS from HCD. It is then used to write the macro definitions to the System z10 or System z9 server and can be used for quick debugging purposes. Example 3-1 depicts an IOCDS input that was generated by HCD for spanned OSA CHPIDs running in QDIO mode.

Example 3-1 IOCDS input

ID MSG1='IODF16', * MSG2='OSARES1.IODF16.WORK - 2008-09-26 03:17', * SYSTEM=(2098,1),LSYSTEM=SCZP202, * TOK=('SCZP202',00800006991E2094090130760108270F00000000,* 00000000,'08-09-26','03:17:37',' ',' ') RESOURCE PARTITION=((CSS(0),(A01,1),(*,2),(*,3),(*,4),(*,5),(** ,6),(*,7),(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F* )),(CSS(1),(A11,1),(A12,2),(*,3),(*,4),(*,5),(*,6),(*,7)* ,(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F))) CHPID PATH=(CSS(0,1),0A),SHARED, * PARTITION=((CSS(1),(A12),(=))),PCHID=1C1,TYPE=OSD CHPID PATH=(CSS(0,1),0B),SHARED, * PARTITION=((CSS(1),(A12),(=))),PCHID=231,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),CUNUMBR=(2D80),UNIT=OSA IODEVICE ADDRESS=2D8F,UNITADD=FE,CUNUMBR=(2D80),UNIT=OSAD


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 OSA features. It also allows you to obtain status and operational information about the HCD-defined OSA ports, 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 E, “Using the OSA/SF REXX interface” on page 241.

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 features that span server boundaries, as shown in Figure 4-1. You can have GUI instances in each server image that has OSA/SF, so you can monitor your OSA features locally.

This chapter provides instructions to help you set up and use OSA/SF.

4


4.1 Setup requirements and overviewOSA/SF is required when the OSA feature is configured for shared non-QDIO mode and SNA/APPN/HPR definitions, other than for Enterprise Extender (EE).

OSA/SF is not required for OSA features that are configured in QDIO mode or when the default IP Passthru (non-QDIO mode) is used. However, it has been proven very useful for monitoring, problem determination and simple performance analysis. Therefore, we recommend to install and use OSA/SF, even if you are only using OSA features running in QDIO mode.

Figure 4-1 shows the communication path between the user interfaces and OSA features.

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 z/VSE.

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 5.4 replaces OSA/SF 2.1. In currently supported versions or releases of z/VM and z/VSE, this version is delivered as a PTF and overlays OSA/SF 2.1. The OSA/SF GUI supports only TCP/IP connections.

The OSA/SF GUI is common across z/OS, z/VM, and z/VSE. Examples of how the GUI is used can be found in 4.4, “Using the OSA/SF GUI” on page 53.

4.2 Setting up OSA/SF in the z/OS environmentThis section explains how to set up OSA/SF on z/OS. For information about setting up OSA/SF in z/VM or z/VSE, and for access control to OSA/SF via RACF, refer to Open Systems Adapter-Express Customer’s Guide and Reference, SA22-7935.

HostPrograms

LP A LP 1 LP 2LP B LP 3

ChannelSubsystem

OSA/SF OSA/SFOSA/SF

OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA

OSA/SF

REXXREXXCommandCommand

LineLine(IOACMD)(IOACMD)

OSA/SFOSA/SFGUIGUI

HostPrograms

HostPrograms

HostPrograms

HostPrograms


4.2.1 Setting up APPC and VTAMBefore using OSA/SF to manage your OSA 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, X APPC=YES,AUTOSES=0,DDRAINL=NALLOW, X DMINWNL=5,DMINMNR=5,DRESPL=NALLOW, X DSESLIM=10,LMDENT=19,MODETAB=MTAPPC

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.

Example 4-2 APPCPM00 from SYS1.PARMLIB

LUADD ACBNAME(IOASERV) /* Specify the name of the LU to be */ /* added */ NOSCHED /* Specify that the APPC/MVS */ /* transaction scheduler is associated */ /* with this LU name */ TPDATA(SYS1.APPCTP) /* Specify that VSAM data set */ /* SYS1.APPCTP is the permanent */ /* repository for the TP profiles */ /* for this LU */

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 parameters shown in Example 4-4 to your COMMNDxx member of SYS1.PARMLIB.

Example 4-4 COMMND00 from SYS1.PARMLIB

COM='S APPC,SUB=MSTR'

Reminder: The OSAD device has to be defined in HCD or IOCP to the OSA CHPID for OSA/SF-to-OSA communication to work. For an HCD setup example, see step 11 on page 43, or for an IOCDS input example go to Example 3-1 on page 46.

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

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

Chapter 4. Setting up and using OSA/SF 49

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


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

Example 4-7 IOASRV from SYS1.PROCLIB

//IOASRV PROC //IOASRV EXEC PGM=IOAXTSRV,PARM='2000',REGION=0M,TIME=NOLIMIT //STEPLIB DD DISP=SHR,DSN=SYS1.SIOALMOD //IOALIB DD DISP=SHR,DSN=SYS1.SIOALMOD //SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(PROF&SYSCLONE.) //SYSPRINT DD SYSOUT=*,DCB=(RECFM=FBA,LRECL=121,BLKSIZE=121) //*SYSUDUMP DD SYSOUT=*

3. Restart TCP/IP or use the OBEYFILE TCP/IP subcommand to make these modifications active.

4.3 Installing OSA/SF GUI on a workstationWe 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 configurationTo 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:

� A Pentium 1.70 GHz with 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 configurationTo use the GUI in conjunction with z/OS, z/VM, or z/VSE, you must have a workstation with either of the following versions:

� Microsoft® Windows 2000 or Windows XP, 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

In our configuration, we used:

� Windows XP SP2� TCP/IP network connection� Java 1.6� JavaHelp 2.0


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/javase/technologies/desktop/javahelp/index.jsp

4.3.4 Downloading the code from z/OS using FTPBefore 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) or the Hostname, if a Hostname resolution technique has been set up in your environment.

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 data set 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 bye command.

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

3. In the Environment Variables window, define the CLASSPATH environment variable for Windows. Select CLASSPATH and click Edit. 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, separated by a semicolon. For example, you may have the following CLASSPATH definitions for Variable Value:

C:\Program Files\Java\jh2.0\javahelp\lib\jh.jar;C:\Documents and Settings\Administrator\osasf\ioajava.jar

b. Specify CLASSPATH for Variable Name in the window, if you are creating this variable.


http://java.sun.com/

http://java.sun.com/javase/technologies/desktop/javahelp/index.jsp

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 WindowsFollow 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 completed the steps for setting up the OSA/SF GUI, you can use the command windows to configure an OSA 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

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 50) • 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 you entered.– OSA/SF Commands - This GUI allows you to enter most REXX commands.

Click CHPID View.

Figure 4-3 Workstation Interface

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


b. Now you see the settings for that CHPID, shown in Figure 4-5. This window shows, among others things, the following information:

• The PCHID related to CHPID (in our case, 1C1)• The Hardware model of OSA (in our case an OSA-Express3)• 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, 07.05)• The Channel Path status (in our case the OSA CHPID is online)

Return to the CHPID View window.

Figure 4-5 CHPID settings

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


Figure 4-6 CHPID View

d. Now you see the settings shown in Figure 4-7 on page 57. This window shows the following information:

• The LAN traffic state (enable)• The MAC address• The active speed mode (100 Mbps)• The TCP port name (OSAE200)

To view the packets transmitted and received, and error counters, select the Statistics tab.

Note: As shown in Figure 4-6, CHPID 0A has two OSA ports, Port 0 and Port 1. In our z10 server we have OSA-Express3 1000BASE-T cards (Feature code #3367) installed. Those features are 4 port dual-density cards and allow the configuration and operating of two ports per CHPID.

Note: The reason we see a speed of 100 Mbs here is that this is the maximum speed our switch supports. Both the OSA port and the switch negotiate the speed according to their attributes.


Figure 4-7 Port settings


Figure 4-8 on page 58 shows the details of the Statistics tab. Use the scroll bar to see more statistics.

Figure 4-8 Port Statistics tab

4. From the OSA/SF Commands panel shown in Figure 4-3 on page 54, select Configure OSA CHPID.

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


5. In the Configure OSA CHPID window, shown in Figure 4-9, complete the following steps:

a. Type the CHPID number. In our case, we type 0A.b. Select the proper CHPID type. In our case, we choose OSD3 1000Base-T Ethernet

because we use an OSA-Express3 1000BASE-T card, configured in QDIO mode.c. Press ENTER.

Figure 4-9 Configure OSA CHPID

d. Here you can apply changes for the configuration of CHPID 0A, as shown in Figure 4-10 on page 60.

For example, you could:

• Select Specify local (address) instead of the universal MAC. • Change the LAN speed from 100 Mbps full duplex to 100 Mbps half duplex.

Note: When configuring or changing OSA-Express3 features with 4-ports, make sure you select the correct port in the CHPID (such as Port 0 or Port 1).


Figure 4-10 1000Base-T Ethernet Configuration settings

6. Save your changes now by selecting File and then Save Configuration.

7. To perform the initial configuration, select Activate with install as shown in Figure 4-11.

Figure 4-11 Activate 1000BASE-T Ethernet configuration

Note: The Install command, from the OSA/SF Commands panel (Figure 4-3 on page 54), can be used to load an existing configuration onto an OSA when you replace the OSA feature. It is not for the initial installation of an OSA feature.


8. Back on the OSA/SF Commands display (Figure 4-3 on page 54), select Query.

9. The Query window (Figure 4-12) 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-12 Query window

The result of your Query command appears in the Command Output window (Figure 4-13).

Figure 4-13 Command output of query One OSA

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

11.In the OSA/SF Set Parameters window (Figure 4-14 on page 62), depending on the type of feature, you can now set some parameters. You enter the CHPID number, in our case


0A, and select OSA-Express3 - All Types, because we are working with an OSA-Express3 1000BASE-T feature. The only valid action for our 1000BASE-T feature running in QDIO mode here is to check for the LAN traffic state and do an Enable/Disable. Complete the field Port number by typing a 0 or 1 and press LAN traffic state.

Figure 4-14 Set Parameters

From the OSA/SF Commands panel (Figure 4-3 on page 54), 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 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.

� Debug

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


Figure 4-15 Debug OSA

Follow these steps:

1. From the OSA/SF Commands panel (Figure 4-3 on page 54), select CHPID View.

2. From the CHPID View window, click Selected Open Device Information to view device information, as shown in Figure 4-16.

Figure 4-16 CHPID View (Device Information)


Figure 4-17 shows the device information for CHPID 0A. You can see that unit addresses for Port 0, E200 to E202, are online and allocated. The same is true for Port 1 (E204 to E206). This means that:

– VTAM TRL is active.– TCP/IP is up and our OSA port has been started.

Figure 4-17 Device Information

3. From the CHPID View window (Figure 4-16 on page 63), click Selected Open OAT Information.

The OAT Information for CHPID 0A window (Figure 4-18 on page 65) shows:

– The LPAR number

– The OSA port

– The devices associated with the IP address, in our case 192.168.1.64 of our OSA Port 0 and 192.168.1.164 as the associated source VIPA address

Furthermore, you see the MAC address of this OSA port used by the Layer 3 VMAC function, discussed in Chapter 9, “z/OS VMAC support” on page 123. Use the scroll bar to see the remaining OAT information regarding OSA Port 1 of CHPID 0A.

Note: Remember, to be able to use the OSA-Express Network Analyzer function, we defined an additional unit address during the HCD process, and in the VTAM TRLE an additional data path—for CHPID 0A, Port 0 the device E203, and Port 1 the device E207. Both devices are online.


Figure 4-18 OAT Information


Chapter 5. QDIO mode for z/OS

This chapter covers the implementation steps needed to establish z/OS network connectivity with an OSA CHPID using QDIO mode.

Although OSA/SF is not required because all definitions are set dynamically, we do recommend that you use OSA/SF for monitoring and controlling the OSA port.

For more information about installing and using OSA/SF, refer to Chapter 4, “Setting up and using OSA/SF” on page 47.

5


5.1 QDIO environmentFigure 5-1 shows a logical representation of the z/OS environment that will be discussed in the remainder of this chapter.

Figure 5-1 QDIO mode example for z/OS

5.2 Hardware Configuration DefinitionThe OSA channel path identifier (CHPID), the control unit, and the OSA devices must be defined to the System z hardware either by coding suitable IOCP statements or through Hardware Configuration Definition (HCD). Refer to Chapter 3, “Hardware configuration definitions” on page 35, for the procedure to create the definitions.

The necessary definitions for CHPID 0A and CHPID 0B are also shown in the IOCDS format, in 3.2.4, “Generating the input IOCDS from HCD” on page 46.

5.3 Missing Interrupt Handler for QDIOThe 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 z/VM).

To determine the current MIH value for the device (E201, in our example), enter the command:

D IOS,MIH,DEV=E201

To dynamically change the MIH value, enter the command:

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

TCP/IP A TCP/IP B

Port 0 Port 1 Port 0 Port 1

OSA-Express31000BASE-T


Port 0 Port 1

Ethernet

VTAM VTAM


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

5.4 Customizing the z/OS network environmentFigure 5-2 shows the network configuration, which consists of two z/OS LPARs, each with two connections to an Ethernet switch through OSA ports.

Figure 5-2 Network configuration

In our environment we are using the first CHPID of each feature with the associated ports (0 and 1) on each OSA-Express3 1000BASE-T feature for demonstration purposes only. In a production environment, both CHPIDs should be used and connected to at least two different Ethernet switches to avoid a single point of failure.

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 disables MIH on those devices.

Note: The discussion in this chapter is based on the OSA-Express3 1000BASE-T feature (FC 3367), which has four ports. Although we show additional definitions in our examples for a second OSA port for each CHPID, the same definitions (minus the second OSA port) can be used for all OSA-Express2 and OSA-Express3 features that have only one port per CHPID.

OSA-Express3 1000BASE-T

IP Address192.168.3.2


z/OS z/OS

VTAM VTAM

TCP/IP A TCP/IP B

192.168.3.64

OSAE200 OSA2D84

E200-E20F 2D80-2D8F

OSAE204 OSA2D84

OSAE200 OSAE204

Device Number

IP Address

Device

TRLE

Portname

OSAnameOSA2D80 OSA2D84

CHPID 0A CHPID 0B

Ethernet

192.168.1.65

OSAE204


192.168.3.4 192.168.1.5

OSA2D80

OSAE200 OSA2D80

Chapter 5. QDIO mode for z/OS 69

5.4.1 Defining OSA devices to z/OS Communications Server for QDIOTo define an OSA device to z/OS Communications Server using QDIO, you need to define a QDIO TRLE. The following example shows the TRLE definition needed for our OSA-Express3 1000BASE-T feature related to CHPID 0A (port 0 and 1).

5.4.2 VTAM definitions (TRL major node)Example 5-1 shows the VTAM TRL major node definition required for TCP/IP A.

Example 5-1 VTAM TRL major node related to TCP/IP A

OSAE200 VBUILD TYPE=TRL * * QDIO TRLE FOR OSA-EXPRESS3 CHPID 0A PORT 0 * OSAE200P TRLE LNCTL=MPC, * READ=E200, * WRITE=E201, * DATAPATH=(E202,E203), * PORTNAME=OSAE200, * PORTNUM=0, * MPCLEVEL=QDIO * * QDIO TRLE FOR OSA-EXPRESS3 CHPID 0A PORT 1 * OSAE204P TRLE LNCTL=MPC, * READ=E204, * WRITE=E205, * DATAPATH=(E206,E207), * PORTNAME=OSAE204, * PORTNUM=1, * MPCLEVEL=QDIO

TCP/IP uses a VTAM interface to run the OSA in QDIO mode. You must define and activate a Transport Resource List (TRL) major node before TCP/IP starts its QDIO device.

Table 2-5 on page 32 lists the various uses of VTAM TRLE definitions, while this chapter provides implementation examples and the associated TRLE definition requirements.


Table 5-1 lists and describes the definitions used in the TRL major node for our OSA-Express3 1000BASE-T feature for CHPID 0A, port 0.

Table 5-1 VTAM TRL major node definition for port 0, related to TCP/IP A

TRLE considerationsFor OSA, there are two types of subchannels:

1. Subchannels dedicated to control flows. The control subchannels are defined on the READ and WRITE operands.

2. Subchannels dedicated to data. The data subchannels are specified on the DATAPATH operand.

Data subchannels are used for sending and receiving data through the OSA device, or for receiving trace data from the OSA device (OSAENTA).

It is important to note that a sufficient number of DATAPATH subchannel addresses be defined to accommodate the number of concurrent instances or exploiters that will be using an OSA port. Consider the following:

� Each TCP/IP in the same logical partition instance that starts an OSA port in QDIO mode is assigned one of the DATAPATH channels by VTAM. That means that you must code at least one DATAPATH subchannel.

� To add a second TCP/IP stack in the same LPAR, an additional DATAPATH device must be added to the TRLE statement and HCD.

� Each TCP/IP in the same logical partition instance that starts an OSA-Express Network Traffic Analyzer (OSAENTA) trace is also assigned one of the DATAPATH channels by VTAM.

Required parameters

Explanation Remarks

TYPE=TRL TRL major node MPC TRL major node known to VTAM.

OSAE200P TRLE minor node The name of the TRLE in VTAM. This name is downloaded to OSA 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 port is used only to exchange control data.

WRITE=E201 Write device The Write device number must be the odd number of the device pair. The Read Write pair of the OSA port is used only to exchange control data.

DATAPATH=(E202,E203)

Data devices The device address of the DATAPATH of each OSA port. For QDIO, the device E202 is used for the data transfer in both directions. The additional device E203 will be needed by the OSA Network Traffic Analyzer trace function, which will be covered in Appendix B, “OSA-Express Network Traffic Analyzer” on page 197.

PORTNAME=OSAE200

PORTNAME associated with the devices

PORTNAME must match the TCP/IP device name in the TCP/IP profile for this connection. The association between TCP/IP and VTAM is done through the PORTNAME.

PORTNUM=0 Physical Port number associated with this CHPID

PORTNUM specifies which physical port on an OSA is to be used for this QDIO device. For OSA-Express and OSA-Express2, only one port, port 0, is supported. For OSA-Express3, multiple ports (0 and 1) are supported.The default is port number 0.

MPCLEVEL=QDIO MPC compatibility level This indicates that the QDIO interface is used for the OSA port.


� With z/OS V1R10 and later, you can set up multiple VLANIDs per OSA port per stack per IP protocol version. You need to configure a separate interface to the OSA port for each VLAN. Each of these interfaces requires a separate DATAPATH device in the TRLE definition as well.

The DATAPATH addresses do not need to be immediate after the write address. It can be any address in the range of the defined devices of the OSA in the HCD.

5.4.3 TCP/IP definitionsTCP/IP requires DEVICE, LINK, and HOME or INTERFACE statements that correspond to the port name in a VTAM TRLE. Example 5-2 shows the TCP/IP profile definitions of both OSA-Express3 1000BASE-T ports defined to CHPID 0A for TCP/IP A.

In our environment, OSA port 1 (OSAE200) uses the INTERFACE statement and OSA port 0 uses the DEVICE, LINK, and HOME statements.

Example 5-2 TCP/IP profile for TCP/IP A

DEVICE VIPAA VIRTUAL 0 LINK VLINK1 VIRTUAL 0 VIPAA ; DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VLANID 980 ; INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.65/24 MTU 1492 VLANID 981 VMAC ROUTEALL HOME 192.168.1.164 VLINK1 192.168.3.64 OSAE200LNK BEGINROUTES ROUTE 192.168.3.0/24 = OSAE200LNK MTU 1492 ROUTE 192.168.1.0/24 = OSAE204I MTU 1492 ENDROUTES START OSAE200 START OSAE204I

Note: We discuss the setup of z/OS V1R10 multiple VLAN support in more detail in Chapter 10, “VLAN support” on page 131.

Important: z/OS V1R10 introduced the INTERFACE statement, which provides the equivalent of DEVICE, LINK, and HOME definitions in one statement. You can still use the DEVICE, LINK, and HOME statements for IPv4 traffic, as we did for port 0 in Example 5-2. However, there are configurations that require you to migrate to the INTERFACE statement, for example when using multiple VLANs.


The following definitions are used when defining OSA port 0:

OSAE200 Device name; must match port name (port 0 of CHPID 0A) in TRLE on TCP/IP A

OSAE200LNK The link name of port 0 of CHPID 0A in TCP/IP A192.168.1.64 The IP address of port 0 of CHPID 0A for TCP/IP A

For the setup of OSA port 1, using the INTERFACE statement, we defined:

OSAE204I Interface nameOSAE204 The OSA portnameSOURCEVIPAINT Specifies the link name of an IPv4 static VIPA for source VIPA processingIPADDR Specifies the home IP address and the number of bits in the subnet mask

5.5 ActivationNormally 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 VTAM and TCP/IP, you can activate the configuration. Activation may require several tasks, such as:

� Verifying that the devices are online� Activating the VTAM resources� Activating TCP/IP

5.5.1 Verifying that devices are onlineThe display command can verify that the required devices for our OSA-Express3 1000BASE-T feature are online (see Example 5-3).

Example 5-3 The z/OS D U,,,E200,8 command to check OSA port devices related to CHPID 0A

IEE457I 15.30.54 UNIT STATUS 421 UNIT TYPE STATUS VOLSER VOLSTATE E200 OSA A-BSY E201 OSA A E202 OSA A-BSY E203 OSA O E204 OSA A-BSY E205 OSA A E206 OSA A-BSY E207 OSA O

All devices (read, write, data, and OSAENTA) are either active or online for each OSA port.

If the devices are not online, use the vary command:

V (E200-E207),ONLINE

5.5.2 VTAM activationNext, activate the corresponding TRL using the following VTAM command:

V NET,ACT,ID=OSAE200P and V NET,ACT,ID=OSAE204P


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 starts it. When the TCP/IP device is started, configuration information (for example, HOME IP address) is loaded into the OSA feature.

5.5.3 TCP/IP devicesThere are two ways to activate the TCP/IP devices: either restart the TCP/IP stack or use the V TCPIP,,START command, for example:

V TCPIP,TCPIPA,START,OSAE200

The V TCPIP,,STOP command can be used to stop the device, for example:

V TCPIP,TCPIPA,STOP,OSAE200

5.6 Relevant status displaysExample 5-4 shows the status of port 0 of the OSA-Express3 1000BASE-T devices for TCP/IP A. To display the status, you can use the D TCPIP,, NETSTAT DEV command.

Example 5-4 D TCPIP,,NETSTAT,DEV for TCP/IP A

DEVNAME: OSAE200 DEVTYPE: MPCIPA DEVSTATUS: READY CFGROUTER: NON ACTROUTER: NON LNKNAME: OSAE200LNK LNKTYPE: IPAQENET LNKSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO ARPOFFLOAD: YES ARPOFFLOADINFO: YES ACTMTU: 1492 VLANID: 980 VLANPRIORITY: DISABLED DYNVLANREGCFG: NO DYNVLANREGCAP: YES READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED CHECKSUMOFFLOAD: YES SECCLASS: 255 MONSYSPLEX: NO BSD ROUTING PARAMETERS: MTU SIZE: N/A METRIC: 00 DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0 MULTICAST SPECIFIC: MULTICAST CAPABILITY: YES ...

Example 5-5 on page 74 shows the status of port 1 of the OSA-Express3 1000BASE-T devices, which we defined with the INTERFACE statement. Again, to display the status, use the D TCPIP,, NETSTAT DEV command.

Example 5-5 D TCPIP,,NETSTAT,DEV for TCP/IP A

INTFNAME: OSAE204I INTFTYPE: IPAQENET INTFSTATUS: READY PORTNAME: OSAE204 DATAPATH: E206 DATAPATHSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 02000274AA6D VMACORIGIN: OSA VMACROUTER: ALL SRCVIPAINTF: VLINK1 CFGROUTER: NON ACTROUTER: NON


ARPOFFLOAD: YES ARPOFFLOADINFO: YES CFGMTU: 1492 ACTMTU: 1492 IPADDR: 192.168.1.65/24 VLANID: 981 VLANPRIORITY: DISABLED DYNVLANREGCFG: NO DYNVLANREGCAP: YES READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED CHECKSUMOFFLOAD: YES SECCLASS: 255 MONSYSPLEX: NO MULTICAST SPECIFIC:

As you can see, the output differs slightly, for example showing the VMAC address of this OSA-Expresss3 port.

The D TCIP,,NETSTAT,HOME command can be used to display IPv4 home addresses and determine whether each address is associated with a LINK definition or an INTERFACE definition (see Example 5-6).

Example 5-6 D TCPIP,,NETSTAT,HOME command

EZZ2500I NETSTAT CS V1R10 TCPIPA 178 HOME ADDRESS LIST: ADDRESS LINK FLG 192.168.1.164 VLINK1 P 192.168.3.64 OSAE200LNK 127.0.0.1 LOOPBACK ADDRESS INTERFACE FLG 192.168.1.65 OSAE204I 4 OF 4 RECORDS DISPLAYED

To determine the devices used and allocated by TCP/IP, you have to display the VTAM TRLE. Example 5-7 shows the TRLE of port 0 (CHPID 0A) of the active OSA-Express3 1000BASE-T belonging to TCPIPA. Message IST1221I tells you which devices TCPIPA uses for READ, WRITE, and DATA, as well as for OSAENTA.

Example 5-7 D NET,TRL,TRLE=OSAE200P

D NET,TRL,TRLE=OSAE200P IST097I DISPLAY ACCEPTED IST075I NAME = OSAE200P, TYPE = TRLE 750 IST1954I TRL MAJOR NODE = TRLSC81 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE IST2263I PORTNAME = OSAE200 PORTNUM = 0 OSA CODE LEVEL = 0707IST1577I 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 IST1918I READ STORAGE = 4.0M(64 SBALS) IST1757I PRIORITY1: UNCONGESTED PRIORITY2: UNCONGESTED IST1757I PRIORITY3: UNCONGESTED PRIORITY4: UNCONGESTED IST2190I DEVICEID PARAMETER FOR OSAENTA TRACE COMMAND = 00-01-00-02


IST1801I UNITS OF WORK FOR NCB AT ADDRESS X'11137010' IST1802I P1 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 IST1802I P2 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 IST1802I P3 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 IST1802I P4 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 IST1221I DATA DEV = E203 STATUS = RESET STATE = N/A IST1724I I/O TRACE = OFF TRACE LENGTH = *NA* IST314I END

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 System z server. See 1.2.14, “Enterprise Extender” on page 21 for an overview and refer to Enterprise Extender Implementation Guide, SG24-7359 for more details.

� The TN3270E Server supports TCP/IP host access to SNA applications (refer to 1.2.15, “TN3270E Server” on page 21). For more information, refer to Communications Server for z/OS V1R9 TCP/IP Implementation Volume 2: Standard Applications, SG24-7533.

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 for both OSA-Express3 1000BASE-T ports (0 and 1) belonging to CHPID 0B:

OSA2D80 VBUILD TYPE=TRL TRLE LNCTL=MPC, * READ=2D80, * WRITE=2D81, * DATAPATH=(2D82,2D83), * PORTNAME=OSA2D80, * PORTNUM=0, * MPCLEVEL=QDIO TRLE LNCTL=MPC, * READ=2D84, * WRITE=2D85, * DATAPATH=(2D86,2D87), * PORTNAME=OSA2D84, * PORTNUM=1, * MPCLEVEL=QDIO

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


Chapter 6. QDIO mode for z/VM

This chapter covers the implementation steps that are needed to establish network connectivity with an OSA CHPID in QDIO mode.

Although Open Systems Adapter Support Facility (OSA/SF) is not required because all definitions are set dynamically, we do recommend that you use OSA/SF for monitoring and controlling the OSA port.

For more information about installing and using OSA/SF, refer to Chapter 4, “Setting up and using OSA/SF” on page 47.

6


6.1 QDIO environmentFigure 6-1 shows a logical representation of the z/VM environment that is discussed in the remainder of this chapter.

Figure 6-1 QDIO mode example for z/VM

6.2 Hardware Configuration DefinitionThe OSA channel path identifier (CHPID), the control unit, and the OSA devices must be defined to the System z hardware either by coding suitable IOCP statements or through Hardware Configuration Definition (HCD). Refer to Chapter 3, “Hardware configuration definitions” on page 35, for the procedure to create the definitions.

The necessary definitions for CHPID 0A and CHPID 0B are also shown in the IOCP/IOCDS format, in 3.2.4, “Generating the input IOCDS from HCD” on page 46.

6.3 Missing Interrupt Handler for QDIOThe WRITE devices should have a Missing Interrupt Handler (MIH) value of at least 15 seconds. To determine the current MIH value for the device (E201, in our example), use the following command:

Q MITIME E201

To dynamically change the MIH value, use either of the following commands:

SET MITIME E201 00:15 (for a single device)SET MITIME E200-E20F 00:15 (for a range of devices)

To set these values at IPL time, update the PROFILE EXEC of user ID AUTOLOG1.

TCPIP TCPIP01




Ethernet

Port 0 Port 1


6.4 Customizing the z/VM network environmentFigure 6-2 shows our z/VM network configuration, which consists of a z/VM LPAR with two TCP/IP stacks and three OSA ports connected to an Ethernet switch.

Figure 6-2 Network configuration

To demonstrate the setup for OSA connectivity, we are only using the first CHPID of each OSA-Express3 1000BASE-T feature with the associated port or ports. In a production environment, both CHPIDs should be used and the ports should be connected to at least two different Ethernet switches to avoid single points of failure.

The TCP/IP stack for z/VM user ID TCPIP01 has one port defined to it to show how all OSA-Express2 and OSA-Express3 features that support only one port per CHPID are configured.

Note: The discussion in this chapter is based on the OSA-Express3 1000BASE-T feature (FC 3367), which has four ports. We show definitions in our examples for two ports per CHPID and one port per CHPID. One port per CHPID applies to all OSA-Express2 and some OSA-Express3 features.

TCPIP01TCPIP

z/VM V5R4 (LPAR)

Ethernet Switch

CHPID 0B2D80-2D82 2D84-2D86

Port 0 Port 1

E200-E202 E204-E206

Port 0 Port 1

CHPID 0A

192.168.3.2

192.168.3.10DEVICE E200 00

192.168.1.11DEVICE E204 01

192.168.3.6DEVICE 2D80 00

192.168.1.7DEVICE 2D84 00

TCPIP01TCPIP

z/VM V5R4 (LPAR)

Ethernet Switch

CHPID 0B2D80-2D82 2D84-2D86

Port 0 Port 1

E200-E202 E204-E206

Port 0 Port 1

CHPID 0A

192.168.3.2

192.168.3.10DEVICE E200 00

192.168.1.11DEVICE E204 01

192.168.3.6DEVICE 2D80 00

192.168.1.7DEVICE 2D84 00

Chapter 6. QDIO mode for z/VM 79

6.4.1 TCP/IP definitionsTCP/IP requires DEVICE, LINK, and HOME definitions that correspond to the hardware device addresses and port numbers.

Example 6-1 shows the TCP/IP profile definitions of the stack for z/VM user ID TCPIP for both OSA-Express3 1000BASE-T ports from CHPID 0A. The device addresses are E200 (port 0) and E204 (port 1).

Example 6-1 Profile for TCP/IP stack for user ID TCPIP

DEVICE DEV_E200 OSD E200 PORTNUMBER 00 LINK DEV_E200 QDIOETHERNET DEV_E200 MTU 1500 ETHERNET ;DEVICE DEV_E204 OSD E204 PORTNUMBER 01 LINK DEV_E204 QDIOETHERNET DEV_E204 MTU 1500 ETHERNET ;HOME 192.168.1.11 255.255.255.0 DEV_E204 192.168.3.10 255.255.255.0 DEV_E200 ; START DEV_E200START DEV_E204

Example 6-2 shows the TCP/IP profile definitions of the stack for z/VM user ID TCPIP01 for one OSA-Express3 1000BASE-T port from CHPID 0B. The device addresses are 2D80 and 2D84.

Example 6-2 Profile for TCP/IP stack for user ID TCPIP01

DEVICE DEV_2D80 OSD 2D80 LINK DEV_2D80 QDIOETHERNET DEV_2D80 MTU 1500 ETHERNET ; DEVICE DEV_2D84 OSD 2D84 LINK DEV_2D84 QDIOETHERNET DEV_2D84 MTU 1500 ETHERNET ; HOME 192.168.1.7 255.255.255.0 DEV_2D84 192.168.3.6 255.255.255.0 DEV_2D80 ; START DEV_2D80 START DEV_2D84

Note that PORTNUMBER 00 is the default value. Therefore, it does not need to be defined in the DEVICE statement.

6.5 ActivationNormally the CHPID should be online. If the CHPID is offline, configure it online using the following command:

VARY ON CHPID 0A


After all the definitions are added to TCP/IP, you can activate the configuration. Activation may require several tasks, such as:

� Verifying that the devices are online� Activating TCP/IP

6.5.1 Verifying that devices are onlineWith the QUERY CHPID command, you can verify that the OSA devices are online (see Example 6-3).

Example 6-3 CP command - QUERY CHPID 0A and 0B

QUERY CHPID 0A Path 0A online to devices E200 E201 E202 E203 E204 E205 E206 E207 Path 0A online to devices E208 E209 E20A E20B E20C E20D E20E E20F

QUERY CHPID 0B Path 0B online to devices 2D80 2D81 2D82 2D83 2D84 2D85 2D86 2D87 Path 0B online to devices 2D88 2D89 2D8A 2D8B 2D8C 2D8D 2D8E 2D8F Ready; T=0.01/0.01 10:10:29

All devices needed for our environment are online. If the devices are not online, the VARY ON command can be used as follows:

VARY ON E200-E20F

The QUERY OSA ALL command also shows the OSAD device (2D8F and E20F) for each adapter (see Example 6-4).

Example 6-4 CP command - QUERY OSA ALL

QUERY OSA ALL OSA 2980 ATTACHED TO TCPIP 2980 DEVTYPE OSA CHPID 02 OSD OSA 2981 ATTACHED TO TCPIP 2981 DEVTYPE OSA CHPID 02 OSD OSA 2982 ATTACHED TO TCPIP 2982 DEVTYPE OSA CHPID 02 OSD OSA 2984 ATTACHED TO DTCVSW1 2984 DEVTYPE OSA CHPID 02 OSD OSA 2985 ATTACHED TO DTCVSW1 2985 DEVTYPE OSA CHPID 02 OSD OSA 2986 ATTACHED TO DTCVSW1 2986 DEVTYPE OSA CHPID 02 OSD OSA 2988 ATTACHED TO TCPIP01 2988 DEVTYPE OSA CHPID 02 OSD OSA 2989 ATTACHED TO TCPIP01 2989 DEVTYPE OSA CHPID 02 OSD OSA 298A ATTACHED TO TCPIP01 298A DEVTYPE OSA CHPID 02 OSD OSA 2D80 ATTACHED TO TCPIP01 2D80 DEVTYPE OSA CHPID 0B OSD OSA 2D81 ATTACHED TO TCPIP01 2D81 DEVTYPE OSA CHPID 0B OSD OSA 2D82 ATTACHED TO TCPIP01 2D82 DEVTYPE OSA CHPID 0B OSD OSA 2D84 ATTACHED TO TCPIP01 2D84 DEVTYPE OSA CHPID 0B OSD OSA 2D85 ATTACHED TO TCPIP01 2D85 DEVTYPE OSA CHPID 0B OSD OSA 2D86 ATTACHED TO TCPIP01 2D86 DEVTYPE OSA CHPID 0B OSD OSA E200 ATTACHED TO TCPIP E200 DEVTYPE OSA CHPID 0A OSD OSA E201 ATTACHED TO TCPIP E201 DEVTYPE OSA CHPID 0A OSD OSA E202 ATTACHED TO TCPIP E202 DEVTYPE OSA CHPID 0A OSD OSA E204 ATTACHED TO TCPIP E204 DEVTYPE OSA CHPID 0A OSD OSA E205 ATTACHED TO TCPIP E205 DEVTYPE OSA CHPID 0A OSD OSA E206 ATTACHED TO TCPIP E206 DEVTYPE OSA CHPID 0A OSD OSA 2983 FREE , OSA 2987 FREE , OSA 298B FREE , OSA 298C FREE OSA 298D FREE , OSA 298E FREE , OSA 2D83 FREE , OSA 2D87 FREE OSA 2D88 FREE , OSA 2D89 FREE , OSA 2D8A FREE , OSA 2D8B FREE


OSA 2D8C FREE , OSA 2D8D FREE , OSA 2D8E FREE , OSA 2D8F FREE OSA E203 FREE , OSA E207 FREE , OSA E208 FREE , OSA E209 FREE OSA E20A FREE , OSA E20B FREE , OSA E20C FREE , OSA E20D FREE OSA E20E FREE , OSA E20F FREE An offline OSA was not found. OSA 2D8F is an OSA Agent OSA E20F is an OSA Agent Ready; T=0.01/0.01 08:30:48

6.5.2 TCP/IP activationThere 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.

6.6 Relevant status displaysTo display the status of the OSA connections and to verify the configuration, you can use the TCPIP command NETSTAT DEV.

Example 6-5 shows the status of the OSA-Express3 1000BASE-T devices for z/VM user ID TCPIP. OSA devices E200 and E204 are in a ready state and E200 is using port 0, while E204 is using port 1.

Example 6-5 NETSTAT DEV for TCPIP

netstat tcp tcpip dev VM TCP/IP Netstat Level 540 TCP/IP Server Name: TCPIP DTCNET400W A denial-of-service attack has been detected; issue NETSTAT DOS for more information

Device DEV_E200 Type: OSD Status: Ready Queue size: 0 CPU: 0 Address: E200 Port name: UNASSIGNED Link DEV_E200 Type: QDIOETHERNET Port number: 0 Transport Type: Ethernet Speed: 100000000 BytesIn: 43804 BytesOut: 3636 Forwarding: Enabled MTU: 1500 IPv6: Disabled IPv4 Path MTU Discovery: Disabled

IPv4 VIPA ARP Multicast Group Members --------------- ------- 224.0.0.1 1 Device DEV_E204 Type: OSD Status: Ready Queue size: 0 CPU: 0 Address: E204 Port name: UNASSIGNED Link DEV_E204 Type: QDIOETHERNET Port number: 1 Transport Type: Ethernet Speed: 100000000 BytesIn: 752 BytesOut: 1216 Forwarding: Enabled MTU: 1500 IPv6: Disabled IPv4 Path MTU Discovery: Disabled

IPv4 VIPA ARP Multicast Group Members


--------------- ------- 224.0.0.1 1 Ready; T=0.01/0.01 16:51:56

Example 6-6 shows the status of the OSA-Express3 1000BASE-T devices for z/VM user ID TCPIP01. OSA devices 2D80 and 2D84 are in a ready state and both devices are using port 0.

Example 6-6 NETSTAT DEV for TCPIP01

netstat tcp tcpip01 dev VM TCP/IP Netstat Level 540 TCP/IP Server Name: TCPIP01 Device DEV_2D80 Type: OSD Status: Ready Queue size: 0 CPU: 0 Address: 2D80 Port name: UNASSIGNED Link DEV_2D80 Type: QDIOETHERNET Port number: 0 Transport Type: Ethernet Speed: 1000000000 BytesIn: 43840 BytesOut: 810 Forwarding: Enabled MTU: 1500 IPv6: Disabled IPv4 Path MTU Discovery: Disabled

IPv4 VIPA ARP Multicast Group Members --------------- ------- 224.0.0.1 1 Device DEV_2D84 Type: OSD Status: Ready Queue size: 0 CPU: 0 Address: 2D84 Port name: UNASSIGNED Link DEV_2D84 Type: QDIOETHERNET Port number: 0 Transport Type: Ethernet Speed: 1000000000 BytesIn: 404 BytesOut: 810 Forwarding: Enabled MTU: 1500 IPv6: Disabled IPv4 Path MTU Discovery: Disabled

IPv4 VIPA ARP Multicast Group Members --------------- ------- 224.0.0.1 1 Ready; T=0.01/0.01 08:02:07

The NETSTAT HOME command can be used to display IPv4 and IPv6 home addresses (see Example 6-7 for z/VM user ID TCPIP).

Example 6-7 NETSTAT HOME for TCPIP

netstat home VM TCP/IP Netstat Level 540 TCP/IP Server Name: TCPIP IPv4 Home address entries: Address Subnet Mask Link VSWITCH ------- ----------- ------ ------- 192.168.1.11 255.255.255.0 DEV_E200 <none> 192.168.3.10 255.255.255.0 DEV_E204 <none>


IPv6 Home address entries: None


Chapter 7. Non-QDIO mode for z/OS

This chapter discusses customizing OSA CHPIDs in non-QDIO mode for TCP/IP and SNA for a z/OS environment. To configure an OSA CHPID in non-QDIO mode, OSA/SF is required.

This chapter does not cover the setup process for an OSA CHPID running in default mode, using the default OSA Address Table (OAT). That information can be found in Appendix F, “TCP/IP Passthru mode” on page 251.

7


7.1 Configuration informationFigure 7-1 shows a functional view of the connectivity discussed in this chapter for a non-QDIO OSA CHPID in a z/OS environment.

The following must be configured and activated to use any type of OSA port in non-QDIO mode:

� Hardware definitions� OSA configuration and OAT definitions� Network definitions

Figure 7-1 Non-QDIO mode shared port

To set up the data paths between the OSA port and the z/VM network protocols, two files are required:

� The OSA configuration file, which contains information pertaining to the hardware characteristics of the OSA port, such as MAC address, line speed, and timer values.

� The OSA Address Table (OAT), which consists of parameters that map the LPAR, mode, unit address, and network protocol (TCP/IP and SNA) specifics to the OSA port.

When the Activate command is issued from OSA/SF, the OSA configuration file and OAT are downloaded to the OSA, using the FE unit address (OSAD device). After they are downloaded, the OSA CHPID is automatically configured offline to all systems and then configured online. This causes the OSA hardware to be reset. It also activates the new OSA configuration.

z/OS LPAR

TCP/IP

VTAM

Channel Subsystem


Port 0 Port 1

OAT Table

Connectivity definitions:- TCP/IP Passthru - SNA

Ethernet


7.2 Hardware definitionsThe OSA CHPID, control unit, and OSA devices must be defined to HCD/IOCP, and must be activated. Refer to Chapter 3, “Hardware configuration definitions” on page 35, for the procedure to create the definitions.

Example 7-1 shows the IOCP definitions used for CHPID 0C. For future considerations, we defined 15 OSA devices, although only three are needed in our configuration.

Example 7-1 IOCP input for CHPID 0C example

ID MSG1='IODF29',MSG2='SYS6.IODF29 - 2008-10-08 12:04', * SYSTEM=(2098,1),LSYSTEM=SCZP202, * TOK=('SCZP202',00800006991E2094120450420108282F00000000,* 00000000,'08-10-08','12:04:50','SYS6','IODF29') RESOURCE PARTITION=((CSS(0),(A01,1),(*,2),(*,3),(*,4),(*,5),(** ,6),(*,7),(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F* )),(CSS(1),(A11,1),(A12,2),(*,3),(*,4),(*,5),(*,6),(*,7)* ,(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F))) CHPID PATH=(CSS(0),0C),SHARED,PARTITION=((A01),(=)),PCHID=230,* TYPE=OSE CNTLUNIT CUNUMBR=2E40,PATH=((CSS(0),0C)),UNIT=OSA IODEVICE ADDRESS=(2E40,015),UNITADD=00,CUNUMBR=(2E40),UNIT=OSA IODEVICE ADDRESS=2E5F,UNITADD=FE,CUNUMBR=(2E40),UNIT=OSAD

7.3 Creating and activating the OSA configurationIn this section we show how we created and activated our OSA configuration for z/OS, using the OSA/SF GUI. If you prefer to use the OSA/SF REXX command interface, then the steps in Appendix E, “Using the OSA/SF REXX interface” on page 241 can be used instead.

Creating (adding) and saving an OSA 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 on page 88.

Chapter 7. Non-QDIO mode for z/OS 87

Figure 7-2 Connectivity layout

The OSA/SF GUI must be connected to a host that has OSA/SF running. The OSA 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 port configuration.

To create (add) and save the OSA 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.

Figure 7-3 on page 89 shows all the OSA CHPIDs that were installed on the system used in these examples. CHPID 0C (port 0) is highlighted because we work with CHPID 0C throughout this chapter.

3. Select the OSA CHPID and select the OSA port that you are going to place in TCP/IP mode, SNA mode, or both. We are using a OSA-Express3 1000BASE-T Ethernet feature with four ports. We start with the definitions of port 0.

VTAM

TCP/IP A

192.168.4.3

OSA2E40

Devices Port + Port 1

IP Address

Device

CHPID 0C

Ethernet

XCA Node

2E40, 2E41, 2E4A

Switch Maj.

XCAOSAX3

SWOSAX3 START OF OSA ADDRESS TABLE-------------------------- UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01)00(2E40)* P-T 00 NO 192.168.4.3 SIU ALL 02(2E42)* P-T 01 NO 192.168.4.4 SIU ALL 04(2E44) N/A N/A CSS 05(2E45) N/A N/A CSS 06(2E46) N/A N/A CSS 07(2E47) N/A N/A CSS 08(2E48) N/A N/A CSS 09(2E49) N/A N/A CSS 0A(2E4A) SNA 00 S ALL 0B(2E4B) SNA 01 S ALL

OAT

192.168.4.4

OSA2E42


OSA2E40 OSA2E42Port 0 Port 1

Unit Address used by TCP/IP: 00-01

Unit Address used by VTAM: 0B

Unit Address used by VTAM: 0A

Unit Address used by TCP/IP: 02-03

2E42, 2E43, 2E4B


4. From the OSA/SF menu bar, choose Selected Configurations Configuration.

Figure 7-3 List of OSA CHPIDs

5. In the Configuration list for the CHPID 0C panel (Figure 7-4 on page 90), 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.

Tip: We recommend that you follow our steps for the entire setup process for port 0. Once familiar with this process you can easily adapt it to setting up port 1, if required in your environment.

Note: If the OSA CHPID is not defined to the server’s channel subsystem (meaning that it is not in the list), or if the OSA feature is not installed, select the Planning configuration option instead of the Configuration option.


d. A port name is required; it can be up to eight characters in length. Like the User data field, this is not used by OSA 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 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 Add for each protocol type.

Figure 7-4 Adding a new configuration

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 port through SNA must have the MAC address of the defined OSA port. If the OSA feature is replaced, it is much easier to change the MAC address on the OSA 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 feature using OSA Advanced Facilities in the Hardware Management Console (HMC).


7.3.1 TCP/IP definitions in OSA/SFTo 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 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 z10 or z9 enter the MIF ID and CSS value that will use the port. In our example, LPAR A01 on our z10 server has an Image number of x’0.1’ for CHPID 0C (see Example 7-1 on page 87). To determine the LPAR number or MIF ID and CSS values, refer to your IOCDS.

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 port 0 in the default OAT. For this example, we type 00.

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 port. See 1.2.2, “Primary/secondary router function” on page 10, for more information.

d. In the Home IP address box, we enter the home IP address 192.168.4.3.

e. Click Add to add this definition to the OSA/SF OAT.

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

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

Note: The OSA port unit address was used by HCD in Chapter 3, “Hardware configuration definitions” on page 35, when defining the OSA devices.


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


7.3.2 SNA definition in OSA/SFSince our OSA 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 shown in Figure 7-7. Next to the SNA OAT entries box, click Add... 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 port for every LPAR that accesses the port. In SNA mode, each OSA port that VTAM is sharing must have a unique SAP address.

Complete the following steps:

a. Enter the combination of CSS value and MIF ID of the Logical Partition (LPAR) that will use the OSA port. In our example, the OSA port will be used by LPAR A01 in our System z10 server. A01 has a CSS value of 0 and a MIF ID of 1. Therefore, our Image number is’0.1’ for CHPID 0C (see Example 7-1 on page 87). To determine the CSS value and MIF ID, refer to your IOCDS.

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.

Figure 7-8 SNA OAT Entry Definition

3. Now we have done the necessary setup for our port 0. If you need to define port 1 for non-QDIO as well, you can do it now by repeating the procedure “Creating and activating the OSA configuration” on page 87. Otherwise, continue with the next step.

4. In the OSA Configuration window, from the menu bar, select File Save configuration as shown in Figure 7-9 on page 95.

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-9 Saving the configuration

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.SCZP202.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 configurationAll 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 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 port.




java IOAJAVA


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.

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


7. To activate this configuration, select 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.


7.3.4 Displaying the MAC addressIn 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 89), 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 Universal Address 00145E74A950, which appears in the MAC address field.

Figure 7-12 Reviewing the MAC address values

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 port through SNA must have the MAC address of the OSA port defined. If the OSA feature is replaced, it is much easier to change the MAC address on the OSA 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 feature through OSA/SF by using the configuration panels or OSA Advanced Facilities of the HMC.


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

The OSA port is defined as a local area network (LAN) Channel Station (LCS) to TCP/IP. An LCS uses two devices for TCP/IP operation.

VTAM sees the OSA port as an external communications adapter (XCA). One OSA port is linked to one device for SNA operation.

7.4.1 VTAM definitionsThis section describes the definitions required in VTAM to allow SNA applications to access the LAN via the OSA port. To describe the VTAM setup, the network configuration shown in Figure 7-2 on page 88 is used. In this example VTAM communicates over an 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 nodeDefine 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 port

(Group, Line and PU definition statements)

Example 7-2 shows the XCA major node definitions used for this connection.

Example 7-2 XCA major node definition

XCAOSA VBUILD TYPE=XCA OSAX3 PORT MEDIUM=CSMACD, X ADAPNO=0, X CUADDR=2E4A, X TIMER=60, X SAPADDR=04 *********************************************************************** OSAX3G GROUP DIAL=YES, X DYNPU=YES, X ANSWER=ON, X AUTOGEN=(3,L,P), X CALL=INOUT, X ISTATUS=ACTIVE

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


Table 7-1 lists the Port parameters.

Table 7-1 XCA major node Port definition for XCAOSAX3

Table 7-2 identifies the significant Group parameters.

Table 7-2 XCA major node Group definition for XCAOSAX3

Switched major nodeDefine 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)

Example 7-3 shows how 3270 sessions are set up with a switched major node. It lists the important parameters in the PU definition.

Example 7-3 Switched major node definition

VBUILD TYPE=SWNET OSASW 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

Requiredparameters

Explanation Remarks

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

ADAPNO=0 PORT statement Code ADAPNO=0 for port 0 of OSA-Express3 1000BASE-T

CUADDR=2E4A

Channel unit address Code the device number defined for this port. In our example, VTAM uses device number 2E4A for port 0.

MEDIUM=CSMACD

LAN type Use CSMACD for Ethernet.

SAPADDR=04 Service access point address

Code a value that is a multiple of 4. This address must 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 XCAOSAX3.

Required parameters

Explanation Remarks

DIAL=YES Switched peripheral node

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

AUTOGEN=(3,L,P)

Autogeneration of LINE and PU statements

This parameter enables VTAM to automatically generate three sets of LINE and PU statements. The LINE names begin with L. The PU names begin with P.

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


VPACING=0, X PUTYPE=2, X DISCNT=(NO), X ISTATUS=ACTIVE, X MODETAB=NEWMTAB, X DLOGMOD=DYNTRN, X USSTAB=USSLDYN, X SSCPFM=USSSCS OSASWL0 LU LOCADDR=0,MODETAB=MTAPPC,DLOGMOD=APPCMODE OSASWL1 LU LOCADDR=1 3270 SESSIONS OSASWL2 LU LOCADDR=2

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

Table 7-3 Switched major node LU definition for SWOSA63

7.4.2 TCP/IP definitionsTCP/IP uses the OSA 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 88 shows the network and the connections for our configuration example. Port 0 is connected to an Ethernet LAN, using IP address 192.168.4.3.

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, 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 port, and the DEVICE number (the read device 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.

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

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.

Tip: We tested our non-QDIO environment with both OSA-Express3 1000BASE-T ports defined to CHPID 0C. For your reference you will find the required TCP/IP definitions for port 1 in Example 7-4 on page 102 as well.

Note: Although the OSA port is addressed by the device number, the port number in the LINK statement must match the actual OSA port number.


4. Using the HOME statement, define an IP address referring to a LINK statement name.

5. Define static routes through 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.

Example 7-4 shows the TCP/IP PROFILE definitions needed to define OSA to TCP/IP A.

Example 7-4 z/OS TCP/IP PROFILE definitions

; OSA DEFINITIONS FOR LCS TCPIP PATHTHRU PORT 0DEVICE OSA2E40 LCS 2E40 LINK OSA2E40LNK ETHERNET 0 OSA2E40 ; ; OSA DEFINITIONS FOR LCS TCPIP PATHTHRU PORT 1DEVICE OSA2E42 LCS 2E42 LINK OSA2E42LNK ETHERNET 1 OSA2E42 ;HOME 192.168.4.3 OSA2E40LNK

192.168.4.4 OSA2E42LNK ;BEGINROUTES ROUTE 192.168.4.0/24 = OSA2E40LNK MTU 1492 ROUTE 192.168.4.0/24 = OSA2E42LNK MTU 1492 ENDROUTES ; START OSA2E40 START OSA2E42

7.5 Activating the connectionsAfter 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 that the devices are online� Activating VTAM resources� Activating TCP/IP


7.5.1 Verifying that devices are onlineThe z/OS console display command can verify that the required devices are online (see Figure 7-13).

Figure 7-13 z/OS D U command

If they are not online, enter the z/OS console VARY command:

V (2E40,2E41,2E4A),ONLINE

7.5.2 VTAM activationVTAM activation is no different from any other VTAM resource. Use the VTAM VARY NET command. Activate the XCA major node and the switched major node. Typically, the commands are of the following format:

V NET,ID=XCAOSAX3,ACTV NET,ID=SWOSAX3,ACT

7.5.3 TCP/IP activationThere 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,,START,OSA2E40

7.6 Relevant status displaysWe monitored the status of the VTAM resources with the VTAM DISPLAY NET command. Figure 7-14 displays the XCA major node for the OSA-Express3 1000Base-T connection.

D U,,,2E40,2IEE457I 17.33.33 UNIT STATUS 699 UNIT TYPE STATUS VOLSER VOLSTATE 2E40 OSA A-BSY 2E41 OSA A

D U,,,2E4A,1IEE457I 17.34.12 UNIT STATUS 701 UNIT TYPE STATUS VOLSER VOLSTATE 2E4A OSA A


Figure 7-14 Display of XCA major node

Figure 7-15 shows the results from the switched major node.

Figure 7-15 Display of switched major node

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

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

D NET,E,ID=XCAOSAX3 IST097I DISPLAY ACCEPTED IST075I NAME = XCAOSAX3, TYPE = XCA MAJOR NODE 704 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1021I MEDIUM=CSMA/CD,ADAPNO= 0,CUA=2E4A,SNA SAP= 4 IST1885I SIO = 54 SLOWDOWN = NO IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST170I LINES: IST232I L2E4A000 ACTIV IST232I L2E4A001 ACTIV IST232I L2E4A002 ACTIV IST314I END

D NET,E,ID=SWOSAX3 IST097I DISPLAY ACCEPTED IST075I NAME = SWOSAX3, TYPE = SW SNA MAJ NODE 707 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST084I NETWORK RESOURCES: IST089I OSASW TYPE = PU_T2 , CONCT IST089I OSASWL1 TYPE = LOGICAL UNIT , CONCT IST089I OSASWL2 TYPE = LOGICAL UNIT , CONCT IST314I END

DEVNAME: OSA2E40 DEVTYPE: LCS DEVNUM: 2E40 DEVSTATUS: READY LNKNAME: OSA2E40LNK LNKTYPE: ETH LNKSTATUS: READY NETNUM: 0 QUESIZE: 0 IPBROADCASTCAPABILITY: YES MACADDRESS: 00145E74A950 ACTMTU: 1500 SECCLASS: 255 MONSYSPLEX: NO BSD ROUTING PARAMETERS: MTU SIZE: N/A METRIC: 00 DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0 MULTICAST SPECIFIC: MULTICAST CAPABILITY: YES GROUP REFCNT SRCFLTMD ----- ------ -------- 224.0.0.1 0000000001 EXCLUDE SRCADDR: NONE


OSA/SF is a very useful tool when verifying your setup. We used the OSA/SF Java GUI and did a Query CHPID for OSA port 0C.

Example 7-5 shows the TCP/IP passthru and the SNA devices for CHPID 0C.

Example 7-5 Excerpt of the OAT showing the TCP/IP passthru and SNA devices

START OF OSA ADDRESS TABLE-------------------------- UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01)00(2E40)* P-T 00 NO 192.168.4.3 SIU ALL 02(2E42) N/A N/A CSS 03(2E43) N/A N/A CSS 04(2E44) N/A N/A CSS 05(2E45) N/A N/A CSS 06(2E46) N/A N/A CSS 07(2E47) N/A N/A CSS 08(2E48) N/A N/A CSS 09(2E49) N/A N/A CSS 0A(2E4A) SNA 00 SIU ALL

Example 7-6 shows another excerpt of the Query CHPID 0C command. We verified that our configuration was active, and the mode that was configured.

Example 7-6 Excerpt of the OSA/SF Query CHPID 0C command output

INFORMATION FOR PORT 0---------------------- Port type 1000Base-T Ethernet Configuration name non qdio chpid 0C (ip+sna) LAN traffic state Enabled Port disabled state N/A Service mode No Modes configured SNA, TCP/IP Passthru Local MAC address 00145E74A950 Universal MAC address 00145E74A950 Configured speed/mode Auto negotiate Active speed/mode 1000 Mbps full duplex TCP port name 1GIGPCIe

Refer to Appendix D, “Useful commands” on page 235, for a list of other useful commands.


Chapter 8. Non-QDIO mode for z/VM

This chapter discusses customizing OSA CHPIDs in non-QDIO mode for TCP/IP and SNA for a z/VM environment. To configure an OSA CHPID in non-QDIO mode, OSA/SF is required.

This chapter does not cover the setup process for an OSA CHPID running in default mode, using the default OSA Address Table (OAT). That information can be found in Appendix F, “TCP/IP Passthru mode” on page 251.

8


8.1 Configuration informationFigure 8-1 shows a functional view of the connectivity definitions discussed in this chapter for a non-QDIO OSA CHPID in a z/VM environment.

The following must be configured and activated to use any type of OSA port in non-QDIO mode:

� Hardware definitions� OSA configuration and OAT definitions� Network definitions

Figure 8-1 Non-QDIO mode shared port

8.2 Hardware definitionsThe OSA CHPID, control unit, and OSA devices must be defined to HCD/IOCP, and must be activated. Refer to Chapter 3, “Hardware configuration definitions” on page 35, for the procedure to create the definitions.

Example 8-1 shows the IOCP definitions used for CHPID 0C. For future considerations, we defined 15 OSA devices, although only three are needed in our configuration.

Example 8-1 IOCP input for CHPID 0C example

ID MSG1='IODF29',MSG2='SYS6.IODF29 - 2008-10-08 12:04', * SYSTEM=(2098,1),LSYSTEM=SCZP202, * TOK=('SCZP202',00800006991E2094120450420108282F00000000,* 00000000,'08-10-08','12:04:50','SYS6','IODF29') RESOURCE PARTITION=((CSS(0),(A01,1),(*,2),(*,3),(*,4),(*,5),(** ,6),(*,7),(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F* )),(CSS(1),(A11,1),(A12,2),(*,3),(*,4),(*,5),(*,6),(*,7)*

z/VM LPAR

TCP/IP

VTAM

Channel Subsystem


Port 0 Port 1

OAT Table

Connectivity definitions:- TCP/IP Passthru - SNA

Ethernet


,(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F))) CHPID PATH=(CSS(1),0C),SHARED,PARTITION=((A12),(=)),PCHID=230,* TYPE=OSE CNTLUNIT CUNUMBR=2E40,PATH=((CSS(1),0C)),UNIT=OSA IODEVICE ADDRESS=(2E40,015),UNITADD=00,CUNUMBR=(2E40),UNIT=OSA IODEVICE ADDRESS=2E5F,UNITADD=FE,CUNUMBR=(2E40),UNIT=OSAD

8.3 OSA configuration and OAT definitionsTo set up the data paths for the OSA port, two files are required:

1. The OSA configuration file, which contains information pertaining to the hardware characteristics of the OSA port, such as MAC address, line speed, and timer values.

2. The OSA Address Table (OAT), which consists of parameters that map the LPAR, mode, unit address, and network protocol (TCP/IP and SNA) specifics to the OSA port.

When the Activate option is selected from OSA/SF, the OSA configuration file and OAT are downloaded to the OSA, using the FE unit address (OSAD device). After they are downloaded, the OSA CHPID is automatically configured offline to all systems and then configured online. This causes the OSA hardware to be reset. It also activates the new OSA configuration.

For information on installing and customizing OSA/SF for z/VM, as well as the user interface (OSA/SF REXX command interface or OSA/SF GUI), refer to OSA-Express Customer’s Guide and Reference, SA22-7935.

8.3.1 Creating and activating our OSA configuration and OATIn this section we show how we created and activated our OSA configuration for z/VM, using the OSA/SF REXX command interface. If you prefer to use the OSA/SF GUI, the steps in 7.3, “Creating and activating the OSA configuration” on page 87 can be used instead.

We implemented the configuration file and OAT for the z/VM configuration shown in Figure 8-2 on page 110.

Chapter 8. Non-QDIO mode for z/VM 109

Figure 8-2 Connectivity layout

There are two methods to prepare the configuration file and OAT for an OSA CHPID. You can either use the sample files and templates for z/VM, or you can use the IOACMD command menu to get the configuration file and OAT that are loaded in the OSA feature for a particular CHPID.

z/VM comes with three administration user IDs (OSADMIN1, OSADMIN2, and OSADMIN3) for using and managing OSA/SF. Those users also allow you to communicate with OSA/SF via REXX commands.

The sample files and templates can be found on the E disk (200) of user OSADMIN1, OSADMIN2, or OSADMIN3 (see Example 8-2). The sample files and templates also provide instructions for their use.

Example 8-2 Sample files and templates on E disk (200) of user OSADMIN1

FILEL * * E....IOAFENET SAMPPROF E2 F (Configuration file for OSA Fast Ethernet and 1000BASE-T features)IOAOSHRT SAMPPROF E2 F (OAT template for TCP/IP only for shared ports across LPARs)IOAOSHRS SAMPPROF E2 F (OAT template for SNA only for shared ports across LPARs)

Note: Before starting with your OSA configuration task, make sure OSA/SF is running and the OSA CHPID and OSAD devices for the OSA port that will be configured are online.

z/VMV5R4

Ethernet Switch

192.168.3.2

2E44-2E45 2E46-2E47

Port 0 Port 1

OSAD2E5F

TCPIP01OSA/SFOSADMIN1

IUCV

IOACMDQueryGetPut

IOACMAINOAT

192.168.3.20

192.168.3.30

SNA terminal

VTAM

XCAP0E

XCAP1E

CHPID 0C

2E4A 2E4B

z/VMV5R4

Ethernet Switch

192.168.3.2

2E44-2E45 2E46-2E47

Port 0 Port 1

OSAD2E5F

TCPIP01OSA/SFOSADMIN1

IUCV

IOACMDQueryGetPut

IOACMAINOAT

192.168.3.20

192.168.3.30

SNA terminal

VTAM

XCAP0E

XCAP1E

CHPID 0C

2E4A 2E4B


IOAOSHRA SAMPPROF E2 F (OAT template for TCP/IP and SNA for shared ports across LPARs)....

For our environment, we chose to use the IOACMD command menu to get the configuration file and OAT that were loaded in the OSA. We followed these steps:

1. First we have to get the OSA configuration file, then the OAT table that is currently loaded in the OSA feature. Both files are required and stored on your A-disk.

To do so, we logged on to our z/VM LPAR with user ID OSADMIN1 and entered the IOACMD command. The menu shown in Example 8-3 appeared. First we used option 4 to get the OSA configuration file for CHPID 0C, next option 6 to get the OAT.

Example 8-3 IOACMD menu

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

2. We provided answers to the questions that followed. After the dialog was completed the OAT and configuration file were saved to the A-disk where we then modified the content.

Example 8-4 shows the modified OSA configuration file (0C CNFG A). This file contains the required input parameters to customize a Fast Ethernet or 1000Base-T Ethernet (non-QDIO) CHPID. We only added the Configuration name and the Port name to the file; all other parameters are the default values.

Example 8-4 Excerpt from our OSA configuration file for CHPID 0C

/*======================================================================/* Ethernet parameters for port 0/*======================================================================fenet.0.1 = non qdio 0C ip+sna /* Configuration name (32-char max)fenet.0.2 = /* User data (32-char max)fenet.0.3 = OSA2E40 /* Port name (8-char max) /* Data ignored for OSD CHPIDsfenet.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)/*======================================================================/* SNA parameters for port 0 - Valid only for OSE (non-QDIO) CHPIDs/*======================================================================sna.0.1 = non qdio 0C ip+sna /* Configuration name (32-char max)sna.0.2 = 90.00 /* Inactivity timer (ti) /* .24-90 in increments of .12 /* 0 disables the inactivity timersna.0.3 = 10.00 /* Response timer (t1) /* .20-51 in increments of .20sna.0.4 = 1.04 /* Acknowledgement timer (t2) /* .08-20.4 in increments of .08sna.0.5 = 1 /* N3 (1-4)sna.0.6 = 8 /* TW (1-16)/*======================================================================/* Ethernet parameters for port 1/*======================================================================fenet.1.1 = non qdio 0C ip+sna /* Configuration name (32-char max)fenet.1.2 = /* User data (32-char max)fenet.1.3 = OSA2E42 /* Port name (8-char max) /* Data ignored for OSD CHPIDsfenet.1.4 = 000000000000 /* Local MAC address (12 hex digits)fenet.1.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)/*======================================================================/* SNA parameters for port 1 - Valid only for OSE (non-QDIO) CHPIDs/*======================================================================sna.1.1 = non qdio 0C ip+sna /* Configuration name (32-char max)sna.1.2 = 90.00 /* Inactivity timer (ti) /* .24-90 in increments of .12 /* 0 disables the inactivity timersna.1.3 = 10.00 /* Response timer (t1) /* .20-51 in increments of .20sna.1.4 = 1.04 /* Acknowledgement timer (t2) /* .08-20.4 in increments of .08sna.1.5 = 1 /* N3 (1-4)sna.1.6 = 8 /* TW (1-16)

Example 8-5 shows an excerpt of our OAT definitions file (0C OAT A). In the OAT, we defined two TCP/IP links using device addresses 2E44-2E45 and 2E46-2E47. For SNA we used address 2E4A for port 0 and 2E4B for port 1.

Note: For TCP/IP, you define only the odd-numbered device address with the passthru option, the port number, and the IP address. For SNA, you specify only the SNA option and the port number.


Example 8-5 Excerpt of our OAT for the z/VM LPAR

************************************************************************** UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************00(2E40) N/A N/A CSS01(2E41) N/A N/A CSS02(2E42) N/A N/A CSS03(2E43) N/A N/A CSS04(2E44)* passthru 00 no 192.168.003.020 SIU ALL06(2E46)* passthru 01 no 192.168.003.030 S ALL08(2E48) N/A N/A CSS09(2E49) N/A N/A CSS0A(2E4A) SNA 00 S ALL0B(2E4B) SNA 01 S ALL0C(2E4C) N/A N/A CSS0D(2E4D) N/A N/A CSS0E(2E4E) N/A N/A CSS

3. The next step was to configure the OSA CHPID (load the modified configuration file and OAT). We issued the IOACMD CONFIG_OSA command and the menu shown in Example 8-6 appeared. We then provided answers to the questions that followed.

Example 8-6 Configuring non-QDIO mode for an OSA-Express3 Ethernet CHPID

ioacmd config_osa 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 7 to configure a non QDIO (OSE) OSA-Express3 Ethernet CHPID IOACMD: Enter a blank line to get a list of valid OSA CHPIDs 7 IOACMD: Enter CHPID -OR- 'quit' to end IOACMD 0c IOACMD: Is CHPID C of type OSD (QDIO)? (y/N) n <---- The OSA port is non-QDIO (CHPID type OSE)IOACMD: Enter the name of the configuration file containing IOACMD: the OSA-Express fast Ethernet/1000Base-T parameters. IOACMD: -OR- IOACMD: 'quit' to end IOACMD 0c cnfg <---- Modified configuration file (from IOAFENET sample) IOACMD: Enter the name of the dataset containing the OAT you IOACMD: want to put on the OSA IOACMD: (This should be in the same format returned by Get OAT) IOACMD: -OR- IOACMD: Enter 0 to exit this EXEC

Important: The OSA feature only accepts the ACTIVATE request if no resources (such as XCA major nodes or TCP/IP devices) are associated with devices on the CHPID to be activated. See Example 8-7 on page 114 for OSA/SF error messages.


0c oat <---- Modified OAT (from IOAOSHRA template) IOACMD: What action should be taken for this configuration? IOACMD: 0 - Quit IOACMD: 1 - Activate IOACMD: Sets up all the files and transfers the data to the CHPID IOACMD: If there are any 'in use' OAT entries, 'activate' will fail 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 1 <---- Activate the OSA configuration

In our environment an active XCA major node caused OSA/SF to interrupt the activation process (see Example 8-7). After inactivating the XCA major node, the ACTIVATE process completed with no errors.

Example 8-7 OSA/SF error messages - when a device is in use

IOACMD: ****************************************************************** IOACMD: Install completed with the following result IOAI696E Install for CHPID 0C not complete. See command output for details IOACMD: ****************************************************************** IOACMD: OSA mode file IOAFENET.CFG0C00 for port 00 IOACMD: had the following result IOAK889E Physical port 0 is in use by image 1.2 UA 0A IOACMD: OSA mode file IOAFENET.OAT0C for port 00 IOACMD: had the following result IOAK889E Physical port 0 is in use by image 1.2 UA 0A IOACMD: OSA mode file IOAFENET.CFG0C01 for port 01 IOACMD: had the following result IOAK889E Physical port 0 is in use by image 1.2 UA 0A IOACMD: OSA mode file IOAFENET.SNA0C00 for port 00 IOACMD: had the following result IOAK889E Physical port 0 is in use by image 1.2 UA 0A IOACMD: OSA mode file IOAFENET.SNA0C01 for port 01 IOACMD: had the following result IOAK889E Physical port 0 is in use by image 1.2 UA 0A IOACMD: IOACMD: Output complete for install IOACMD: The Configure OSA command has completed

Tip: All options can be issued in one IOACMD command, for example:

ioacmd config_osa#7#0c#n#0c cnfg#0c oat#1#


8.4 Network definitionsIn this section we discuss the VTAM and TCP/IP definitions we used in our environment.

TCP/IP and VTAM coexist and share the same OSA port. The definitions can be done independently, as though the OSA port were owned by VTAM or TCP/IP exclusively.

The OSA port is defined as a local area network (LAN) Channel Station (LCS) to TCP/IP. An LCS uses two devices for TCP/IP operation.

VTAM sees the OSA port as an external communications adapter (XCA). One OSA port is linked to one device for SNA operation.

8.4.1 VTAM definitionsThis section describes the definitions required in VTAM to allow SNA applications to access the LAN via the OSA port. To describe the VTAM setup, the network configuration shown in Figure 8-2 on page 110 is used. In this example, VTAM communicates over a Ethernet switch via ports 0 and 1of OSA CHPID 0C, using device numbers 2E4A and 2E4B.

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

� XCA major node� Switched major node (SWNET)

XCA major nodeDefine 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 port

(Group, Line and PU definition statements)

Example 8-8 shows the VTAM coding to implement the connections. The PORT parameters map to the OAT entries defined in Example 8-5 on page 113.

Example 8-8 XCA major node definitions for 2E4A and 2E4B

XCAP0E VBUILD TYPE=XCA OSAX3P0E PORT MEDIUM=CSMACD, X ADAPNO=0, X CUADDR=2E4A, X TIMER=60, X SAPADDR=8 **************************************** OSAX3GP0 GROUP DIAL=YES, X DYNPU=YES, X ANSWER=ON, X AUTOGEN=(3,L,P), X CALL=INOUT, X ISTATUS=ACTIVE

XCAP1E VBUILD TYPE=XCA OSAX3P1E PORT MEDIUM=CSMACD, X

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


ADAPNO=1, X CUADDR=2E4B, X TIMER=60, X SAPADDR=8 **************************************** OSAX3GP1 GROUP DIAL=YES, X DYNPU=YES, X ANSWER=ON, X AUTOGEN=(3,L,P), X CALL=INOUT, X ISTATUS=ACTIVE

Table 8-1 on page 117 lists the PORT parameters.


Table 8-1 XCA major node Port definition for XCAOSAX3

Table 8-2 identifies the significant GROUP parameters.

Table 8-2 XCA major node Group definition for XCAOSAX3

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

Figure 8-2 on page 110 shows the network and the connections for our configuration example. Port 0 is connected to an Ethernet switch, using IP address 192.168.3.20, while port 1 is using IP address 192.168.3.30. These parameters map to the OAT entries defined in Example 8-5 on page 113.

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.

Using the DEVICE statement, define the DEVICE statement name, the DEVICE type (LCS) for the OSA 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.

Requiredparameters

Explanation Remarks

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

ADAPNO=0 PORT statement Code ADAPNO=0 for port 0 of OSA-Express3 1000BASE-T

CUADDR=2E4A (or 2E4B)

Channel unit address Code the device number defined for this port. In our example, VTAM uses device number 2E4A for port 0.

MEDIUM=CSMACD

LAN type Use CSMACD for Ethernet.

SAPADDR=08 Service access point address

Code a value that is a multiple of 4. This address must 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 XCAOSAX3.

Required parameters

Explanation Remarks

DIAL=YES Switched peripheral node

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

AUTOGEN=(3,L,P)

Autogeneration of LINE and PU statements

This parameter enables VTAM to automatically generate three sets of LINE and PU statements. The LINE names begin with L. The PU names begin with P.

Note: The current OSA features in System z10 and z9 servers support 4096 SNA PU Type 2 connections per port.


3. Define the HOME IP address of the OSA port (the IP address refers to the LINK statement name).

4. Define static routes through the GATEWAY statement.

5. 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. There is one TCP/IP START statement entry per TCP/IP device. It uses the DEVICE statement name.

Example 8-9 shows the TCP/IP PROFILE definitions for an OSA port.

Example 8-9 z/VM TCP/IP PROFILE definitions

; OSA DEFINITIONS FOR LCS TCPIP PATHTHRU ; -------------------------------------------DEVICE DEV_2E44 LCS 2E44 LINK DEV_2E44 ETHERNET 00 DEV_2E44 DEVICE DEV_2E46 LCS 2E46 LINK DEV_2E46 ETHERNET 01 DEV_2E46 ; -------------------------------------------HOME 192.168.3.20 255.255.255.0 DEV_2E44 192.168.3.30 255.255.255.0 DEV_2E46 START DEV_2E44 ; START DEV_2E46 OSA2E40

8.5 Activating the connectionsAfter all the definitions were added to OSA/SF, VTAM, and TCP/IP, we activated the configuration. Activation may require several tasks, such as:

� Verifying the devices are online� Activating VTAM resources� Activating TCP/IP

8.5.1 Verifying that devices are onlineThe z/VM console display command (CP Q OSA) can verify that the required devices are online (see Figure 8-3).

Figure 8-3 z/VM Q OSA command

Note: Although the OSA port is addressed by the device number, the port number in the LINK statement must match the actual OSA port number.

CP Q OSAOSA 2E44 ATTACHED TO TCPIP01 2E44 DEVTYPE OSA CHPID 0C OSE OSA 2E45 ATTACHED TO TCPIP01 2E45 DEVTYPE OSA CHPID 0C OSE OSA 2E46 ATTACHED TO TCPIP01 2E46 DEVTYPE OSA CHPID 0C OSE OSA 2E47 ATTACHED TO TCPIP01 2E47 DEVTYPE OSA CHPID 0C OSE OSA 2E4A ATTACHED TO VTAM 2E4A DEVTYPE OSA CHPID 0C OSE OSA 2E4B ATTACHED TO VTAM 2E4B DEVTYPE OSA CHPID 0C OSE


If they are not online, enter the z/VM console VARY ON on command:

VARY ONLINE 2E4A 2E4B

8.5.2 VTAM activationVTAM activation is no different from any other VTAM resource. Use the VTAM VARY NET command. Activate the XCA major node and the switched major node. The commands have the following syntax:

V NET,ID=XCAPOE,ACTV NET,ID=XCAP1E,ACT

8.5.3 TCP/IP activationThere are two ways to activate TCP/IP devices:

� Restart the TCP/IP stack.� Use the TCP/IP obeyfile command.

8.6 Relevant status displaysWe queried the status of the VTAM resources with the VTAM DISPLAY NET command. Figure 8-10 displays the XCA major node for the OSA connection.

Example 8-10 Results of the XCA majnode display command

vtam d net,id=xcap0e,scope=all Ready; IST097I DISPLAY ACCEPTED IST075I NAME = XCAP0E, TYPE = XCA MAJOR NODE IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1021I MEDIUM=CSMA/CD,ADAPNO= 0,CUA=2E4A,SNA SAP= 8 IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST170I LINES: IST232I L2E4A000, ACTIV IST232I L2E4A001, ACTIV IST232I L2E4A002, ACTIV IST314I END vtam d net,id=xcap1e,scope=all Ready; IST097I DISPLAY ACCEPTED IST075I NAME = XCAP1E, TYPE = XCA MAJOR NODE IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST1021I MEDIUM=CSMA/CD,ADAPNO= 1,CUA=2E4B,SNA SAP= 8 IST654I I/O TRACE = OFF, BUFFER TRACE = OFF IST170I LINES: IST232I L2E4B000, ACTIV IST232I L2E4B001, ACTIV IST232I L2E4B002, ACTIV IST314I END


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

Figure 8-4 Display of TCP/IP device and link

OSA/SF is also useful for the verification of your setup. We used the OSA/SF administration user OSADMIN2 and ioacmd command to do a Query CHPID for OSA port 0C.

Example 8-11 shows both the TCP/IP passthru and the SNA devices for our OSA CHPID 0C.

Example 8-11 Extract of the OAT showing TCP/IP passthru and SNA devices

************************************************************************ *** OSA/SF Get OAT output created 17:40:16 on 10/29/2008 *** *** IOACMD APAR level - OA26286 *** *** Host APAR level - OA23824 *** ************************************************************************ *** Start of OSA address table for CHPID 0C *** ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************ Image 0.1 (A01 ) 00(2E40)* passthru 00 no 192.168.004.003 S ALL 02(2E42)* passthru 01 no 192.168.004.004 S ALL 04(2E44) N/A N/A CSS 05(2E45) N/A N/A CSS 06(2E46) N/A N/A CSS 07(2E47) N/A N/A CSS 08(2E48) N/A N/A CSS

netstat dev VM TCP/IP Netstat Level 540 TCP/IP Server Name: TCPIP01 Device DEV_2E44 Type: LCS Status: Ready Queue size: 0 CPU: 0 Address: 2E44 Link DEV_2E44 Type: ETHERNET Net number: 0 Speed: 10000000 BytesIn: 62 BytesOut: 0 Forwarding: Enabled MTU: 1500 IPv4 Path MTU Discovery: Disabled Broadcast Capability: Yes Multicast Capability: Yes IPv4 VIPA ARP Multicast Group Members --------------- ------- 224.0.0.1 1 Device DEV_2E46 Type: LCS Status: Inactive Queue size: 0 CPU: 0 Address: 2E46 Link DEV_2E46 Type: ETHERNET Net number: 1 Speed: 10000000 BytesIn: 0 BytesOut: 0 Forwarding: Enabled MTU: 1500 IPv4 Path MTU Discovery: Disabled Broadcast Capability: Yes Multicast Capability: Unknown


09(2E49) N/A N/A CSS 0A(2E4A) SNA 00 SIU ALL 0B(2E4B) SNA 01 S ALL 0C(2E4C) N/A N/A CSS ************************************************************************ Image 1.2 (A12 ) 00(2E40) N/A N/A CSS 01(2E41) N/A N/A CSS 02(2E42) N/A N/A CSS 03(2E43) N/A N/A CSS 04(2E44)* passthru 00 no 192.168.003.020 SIU ALL 06(2E46)* passthru 01 no 192.168.003.030 S ALL 08(2E48) N/A N/A CSS 09(2E49) N/A N/A CSS 0A(2E4A) SNA 00 S ALL 0B(2E4B) SNA 01 S ALL 0C(2E4C) N/A N/A CSS 0D(2E4D) N/A N/A CSS 0E(2E4E) N/A N/A CSS 0F(2E4F) N/A N/A CSS

Example 8-12 shows another extract of the OSA/SF query for CHPID 0C. We verified that our configuration was active and the mode configured was correct.

Example 8-12 Extract of the OSA/SF query CHPID 0C command output

INFORMATION FOR PORT 0---------------------- Port type 1000Base-T Ethernet Configuration name non qdio chpid 0C (ip+sna) LAN traffic state Enabled Port disabled state N/A Service mode No Modes configured SNA, TCP/IP Passthru Local MAC address 00145E74A950 Universal MAC address 00145E74A950 Configured speed/mode Auto negotiate Active speed/mode 1000 Mbps full duplex TCP port name 1GIGPCIe

Refer to Appendix D, “Useful commands” on page 235, for a list of other helpful commands.


Chapter 9. z/OS VMAC support

Virtual Medium Access Control (VMAC) support for z/OS Communications Server is a function that affects the operation of an OSA interface at the OSI layer 2 level—the Data Link Control (DLC) layer with its sublayer Medium Access Control (MAC).

VMAC support enables an OSA interface to have not only a physical MAC address, but also distinct virtual MAC addresses for each device or interface in a stack. That is, each stack may define one VMAC per protocol (IPv4 or IPv6) for each OSA interface.

With the use of VMACs, decisions at the layer 3 level, that is, the network layer (or IP layer) can be made for forwarding and routing of IP packets entering the System z environment via the OSA.

From a LAN perspective, the OSA interface with a VMAC appears as a dedicated device or interface to a z/OS TCP/IP stack.

9


9.1 Virtual MAC overviewPrior to the introduction of the virtual MAC function, an OSA interface only had one MAC address. This restriction caused problems when using load balancing technologies in conjunction with z/OS TCP/IP stacks that share OSA interfaces.

The single MAC address of the OSA also causes a problem when using z/OS TCP/IP stacks as a forwarding router for packets destined to unregistered IP addresses.

With the use of the VMAC function, packets destined for a z/OS TCP/IP stack are identified by an assigned VMAC address and packets sent to the LAN from the stack use the VMAC address as the source MAC address. This means that all IP addresses associated with a z/OS TCP/IP stack are accessible via their own VMAC address, instead of sharing a single physical MAC address of an OSA interface.

9.1.1 Virtual MAC conceptFigure 9-1 depicts how the definition of VMACs in the z/OS TCP/IP stacks gives the appearance of having a dedicated OSA interface on each stack. When packets arrive at the shared OSA interface, the individual VMAC assignments allow the packets to be forwarded directly to the correct stack. In the example shown, no individual stack needs to be defined as a primary or secondary router, thus offloading this function from a z/OS TCP/IP stack.

Figure 9-1 Forwarding packets to LPARs using VMACs

This simplifies a shared OSA configuration significantly. Defining VMACs has very little administrative overhead. It is also an alternative to GRE or NAT when load balancing technologies are used.

Connect to 10.1.2.31

OSA 10.1.2.11 OSA 10.1.2.21 OSA 10.1.2.31 OSA 10.1.2.41

Connect to 10.1.2.41

VMAC [ <mac1> ] VMAC [ <mac2> ] VMAC [ <mac3> ] VMAC [ <mac4> ]

10.1.2.11 vmac1

10.1.2.21 vmac2

10.1.2.31 vmac3

10.1.2.41 vmac4

10.1.2.0/24

LPAR A LPAR B

Device OSAVMAC [ <mac1> ]

OSA 10.1.2.11 OSA 10.1.2.21 OSA 10.1.2.31 OSA 10.1.2.41




LPAR C LPAR D

Switch

ARPCache


For IPV6, TCP/IP uses the VMAC address for all neighbor discovery address resolution flows for that stack’s IP addresses, and likewise uses the VMAC as the source MAC address for all IPv6 packets sent from that stack. Again, from a LAN perspective, the OSA interface with a VMAC appears as a dedicated device to that stack.

9.1.2 Virtual MAC address assignment The VMAC address can be defined in the stack, or generated by the OSA. If generated by the OSA, it is guaranteed to be unique among all other physical MAC addresses and all other VMAC addresses generated by any OSA feature.

The same VMAC can be defined for both IPv4 and IPv6 usage, or a stack can use one VMAC for IPv4 and one for IPv6. Also, a VLAN ID can be associated with an OSA device or interface defined with a VMAC.

9.2 Virtual MAC implementationIn this section, we show a scenario in which we share two OSA ports between TCPIPA and TCPIPB. We define VMACs for those two z/OS TCP/IP stacks. From a LAN perspective, the OSA ports of both stacks will then appear as a dedicated device or interface. See Figure 9-2 on page 126.

When implementing VMAC support, keep the following points in mind:

� The VMAC function is only available for OSA interfaces configured in QDIO mode.

� Each stack may define one VMAC per protocol (IPv4 or IPv6) for each OSA interface.

� If a VMAC is defined, the stack will not receive any packets destined to the physical MAC.

� VLAN IDs also apply to VMACs like physical MACs.

� If OSAs are not shared, VMACs are not necessary.

� Allow the OSA to generate VMAC addresses.

� When configuring VMACs to solve load balancing issues, remember to:

– Remove GRE tunnels as appropriate.– Change external load balancer configurations (such as directed mode to dispatch

mode).

Note: VMAC definitions on a device in a z/OS TCP/IP stack override any NONRouter, PRIRouter, or SECRouter parameters. If necessary, selected stacks on a shared OSA may define the device with VMAC and others may define the device with PRIRouter and SECRouter capability.

Note: We recommend letting the OSA generate the VMACs instead of assigning an address in the TCP/IP profile. If VMACs are defined in the LINK statement, they must be defined as locally administered MAC addresses, and should be unique to the LAN on which they reside.

Note: VMAC support is only available with the IBM System z10 and z9 servers. For more information, see the 2098DEVICE, 2097DEVICE, 2094DEVICE, and 2096DEVICE Preventive Service Planning (PSP) buckets.

Chapter 9. z/OS VMAC support 125

Figure 9-2 Our configuration for the implementation of VMAC

We shared an OSA-Express3 1000BASE-T feature (CHPID 0A) between stacks TCPIPA and TCPIPB.

We configured port 0 of the OSA-Express3 1000BASE-T within TCPIPA and TCPIPB using the DEVICE, LINK, and HOME statements. Environments running a version of z/OS V1R9 or older have to define their VMAC environment with those statements.

We used the INTERFACE statement in TCPIPA and TCPIPB to configure VMACs for OSA-Express3 1000BASE-T (port 1). Starting with z/OS V1R10 Communications Server, you can use the INTERFACE statement to configure IPv4 definitions for OSA ports in QDIO mode.

Note that Figure 9-2 is used only for demonstration purposes. We do not recommend implementing any configuration with a single point of failure.

Configuring the VMAC The VMAC can either be defined on the LINK statement or the INTERFACE statement in the TCP/IP profile. Example 9-1 and Example 9-2 show the VMAC definitions for TCPIPA and TCPIPC.


OSAE200

CHPID 0A shared between TCPIPA and TCPIPB

Ethernet Switch

Port 0

z/OS 1.10

VTAM

TCP/IP A192.168.3.64

OSAE200

E204-E207

OSAE204

DeviceNumber

IP Address

Device/INTERFACE

Portname

192.168.1.65

OSAE204I

OSAE200

VMAC

E200-E203z/OS 1.10

VTAM

TCP/IP B192.168.3.4

OSAE200

E204-E207

OSAE204

DeviceNumber

IP Address

Device/INTERFACE

Portname

192.168.1.5

OSAE204I

OSAE200

VMAC

E200-E203

OSAE204

Port 1

020012345678 02000B74AA6D 020087654321 02000D74AA6D


Example 9-1 DEVICE/LINK (OSA port 0) and INTERFACE (OSA port1) VMAC definition for TCPIPA

DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VMAC 020012345678 1; INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.65/24 MTU 1492 VMAC ROUTEALL 2HOME 192.168.3.164 VLINK1 192.168.3.64 OSAE200LNK

If VMAC is defined without a MAC address 2, then OSA generates a VMAC using a part of the “burned-in” MAC address of the OSA (we intentionally specified ROUTEALL here, which is the default, for demonstration purposes only).

You may also specify the MAC address for VMAC 1. as we did when defining port 0 of the OSA-Express3 1000BASE-T feature. If you decide to specify a MAC address, it must be a locally administered address, which means bit 6 of the first byte is 1 and bit 7 of the first byte is 0.

Example 9-2 DEVICE/LINK (OSA port 0) and INTERFACE (OSA port1) VMAC definition for TCPIPB

DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VMAC 020087654321 1; INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.5/24 MTU 1492 VMAC ROUTEALL ;HOME 192.168.3.165 VLINK1 192.168.3.4 OSAE200LNK

9.2.1 VerificationWe verified that our VMACs were correctly defined in TCPIPA (see Example 9-3 on page 128) and TCPIPB (see Example 9-4 on page 128).

Note: There is no need to define PRIRouter or SECRouter on the DEVICE statement. When VMAC is specified on the LINK statement, PRIRouter or SECRouter is ignored.


Example 9-3 Display VMACs of both OSA-Express3 ports on TCPIPA

D TCPIP,,N,DEVDEVNAME: OSAE200 DEVTYPE: MPCIPA DEVSTATUS: READY LNKNAME: OSAE200LNK LNKTYPE: IPAQENET LNKSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 020012345678 1 VMACORIGIN: CFG 2 VMACROUTER: ALL ARPOFFLOAD: YES ARPOFFLOADINFO: YES ACTMTU: 1492 VLANID: NONE VLANPRIORITY: DISABLED ...INTFNAME: OSAE204I INTFTYPE: IPAQENET INTFSTATUS: READY PORTNAME: OSAE204 DATAPATH: E206 DATAPATHSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 02000D74AA6D 3 VMACORIGIN: OSA 4 VMACROUTER: ALL SRCVIPAINTF: VLINK1 CFGROUTER: NON ACTROUTER: NON ARPOFFLOAD: YES ARPOFFLOADINFO: YES CFGMTU: 1492 ACTMTU: 1492 IPADDR: 192.168.1.65/24 VLANID: NONE VLANPRIORITY: DISABLED

We specified a MAC address 1 for the OSA-Express3 1000BASE-T port 0 in TCPIPA and TCPIPB, so VMACORIGIN is CFG 2. Because we did not specify a MAC address for the OSA-Express3 1000BASE-T port 1 in TCPIPA and TCPIPB, the OSA generated the MAC address 3. Because this is an OSA-generated MAC address, VMACORIGIN is OSA 4.

Example 9-4 Display VMACs of both OSA-Express3 ports on TCPIPB

D TCPIP,,N,DEVDEVNAME: OSAE200 DEVTYPE: MPCIPA DEVSTATUS: READY LNKNAME: OSAE200LNK LNKTYPE: IPAQENET LNKSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 020087654321 1 VMACORIGIN: CFG 2 VMACROUTER: ALL ARPOFFLOAD: YES ARPOFFLOADINFO: YES ACTMTU: 1492 VLANID: NONE VLANPRIORITY: DISABLED ...INTFNAME: OSAE204I INTFTYPE: IPAQENET INTFSTATUS: READY PORTNAME: OSAE204 DATAPATH: E208 DATAPATHSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 02000B74AA6D 3 VMACORIGIN: OSA 4 VMACROUTER: ALL SRCVIPAINTF: VLINK1 CFGROUTER: NON ACTROUTER: NON ARPOFFLOAD: YES ARPOFFLOADINFO: YES CFGMTU: 1492 ACTMTU: 1492 IPADDR: 192.168.1.5/24 VLANID: NONE VLANPRIORITY: DISABLED

We can also see the VMAC in the OSA Address Table (OAT) queried by OSA/SF (see Example 9-5). OSA registers all IP addresses (including VIPA) in the z/OS TCP/IP stack, and maps them to the VMAC address.


Note that the last three bytes of the OSA-generated VMAC 7 are identical to that of the universal MAC address (“burned-in” address) of the OSA 5. The first byte of the OSA-generated VMAC is always 02, in order to make the VMAC a locally administered address. To make the VMAC unique among all z/OS TCP/IP stacks, the second and third bytes are used as a counter that is incremented each time OSA generates a MAC address.

Example 9-5 Query of CHPID 0A with OSA/SF

INFORMATION FOR PORT 0---------------------- Port type 1000Base-T Ethernet Local MAC address 00145E74AA6C Universal MAC address 00145E74AA6C

INFORMATION FOR PORT 1---------------------- Port type 1000Base-T Ethernet Local MAC address 00145E74AA6D Universal MAC address 00145E74AA6D 5

START OF OSA ADDRESS TABLE-------------------------- UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01) CULA 0000(E200)* MPC n/a OSAE200 (QDIO control) SIU ALL 02(E202) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL VMAC IP Address HOME 020012345678 192.168.3.64 HOME 020012345678 192.168.3.164 Group Address Multicast Address 01005E000001 224.0.0.1 03(E203) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL VMAC IP Address HOME 020087654321 192.168.3.4 HOME 020087654321 192.168.3.165 Group Address Multicast Address 01005E000001 224.0.0.1

04(E204)* MPC n/a OSAE204 (QDIO control) SIU ALL 06(E206) MPC 1 No4 No6 OSAE204 (QDIO data) SIU ALL VMAC IP Address HOME 02000D74AA6D 7 192.168.1.65 HOME 02000D74AA6D 192.168.1.164 Group Address Multicast Address 01005E000001 224.0.0.1 07(E207) N/A N/A CSS 08(E208) MPC 1 No4 No6 OSAE204 (QDIO data) SIU ALL VMAC IP Address HOME 02000B74AA6D 7 192.168.1.5 HOME 02000B74AA6D 192.168.1.165


Chapter 10. VLAN support

Virtual Local Area Network (VLAN) technology is becoming more important in network planning. A VLAN is a configured logical grouping of nodes using switches. A VLAN configuration provides many benefits, such as improved network performance by reducing traffic on a physical LAN, enhanced security by isolating traffic, and providing more flexibility in configuring networks.

The VLAND IEEE standard 802.1p/q is supported by the OSA-Express3, OSA-Express2, and OSA Ethernet features running in QDIO mode.

This chapter briefly explains the concepts of VLANs followed by examples on how to set up VLAN support in the TCP/IP stacks of z/OS, z/VM, and Linux on System z.

10


10.1 VLAN overviewA 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 10-1 shows an example of VLANs segmented into logically defined networks.

Figure 10-1 Logically defined networks using VLANs

10.1.1 Types of connectionsIEEE 802.1p/q 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

EngineeringVLAN

MarketingVLAN

AccoutingVLAN

Switch 3

Switch 2

Switch 1


generated by VLAN-aware equipment are marked with a tag, which identifies the frame to the VLAN.

Trunk modeTrunk 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 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 modeHybrid 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 10-2 shows a logical diagram of a VLAN environment with two switches and a number of VLANs.

Figure 10-2 VLAN logical diagram

In this sample 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.

VLAN 102VLAN 100

Switch 2Switch 1

VLAN 101

Server

Access ports Access port

HUB 1

Trunk port

TRUNK PORT

Chapter 10. VLAN support 133

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 Switch 1 saves having to provide an additional link from the other building.

Broadcast in VLANsAll 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 isolationAn 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 10-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.

10.1.2 VLAN tagging basicsIn 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.


Figure 10-3 illustrates these descriptions.

Figure 10-3 VLAN tagging

10.2 General VLAN design considerationsWe recommend to consider the following items when designing VLANs that include OSA Ethernet features:

� If a VLAN ID is defined to the TCP/IP stack for an OSA port, the Ethernet switch port to which the OSA port is attached must be configured in trunk mode.

� If no VLAN ID is defined to the TCP/IP stack for an OSA port, the Ethernet switch port to which the OSA port is attached must be configured in access mode.

� If an OSA 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 .

z/OS VLAN support allows a TCP/IP stack to register up to eight VLAN IDs for both IPv4 and IPv6 for the same OSA port. Note that the VLAN IDs for IPv4 can be different than the VLAN ID for IPv6.

When a VLAN ID is configured to an OSA port via the TCP/IP stack, the following occurs:

� The TCP/IP stack becomes VLAN-aware or enabled, and the OSA port is considered to be part of a VLAN.

� During activation, the TCP/IP stack registers the VLAN ID value to the OSA port.

� A VLAN tag is added to all outbound packets.

� The OSA port filters all inbound packets based on the configured VLAN ID.

Dest MAC address Source MAC address Type/Length

Tag Control Info(4 Bytes)

Dest MAC address Source MAC address Type/Length

VLAN Tag x'8100' 3-bit Priority 1-bit Canonical(always zero)

12-bit VLAN ID

Ethernet header (untagged)

Ethernet header (tagged)

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

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.


10.2.1 VLAN configuration exampleWhen designing VLANs in conjunction with an OSA 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 port must be configured in trunk mode when the OSA port performs VLAN tagging and VLAN ID filtering.

If a VLAN ID is not configured to an OSA 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 10-4 shows an example of trunk mode versus access mode, with four VLANs deployed through two shared OSA ports. 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)

Figure 10-4 Trunk mode versus access mode

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

Note: This example is used solely to demonstrate the VLAN design rules. We do not recommend implementing OSA features with a single point of failure.

OSA #1

Trunk Mode

Trunk connection forVLAN 100, 200 and 300

Ethernet Switch

No VLAN ID

z/VM

IP-stack #5

LINUX1

VLAN ID 100

z/VM

LINUX2

VLAN ID 200

IP-stack #2IP-stack #1

No VLAN ID

z/OS

IP-stack #4

Router

Access ModeVLAN 400

Access connection forVLAN 400

Access ModeVLAN 100

Clients 1 and 2

Access ModeVLAN 200

Clients 3 and 4

Access ModeVLAN 300

Clients 5 and 6

VLAN ID 300

z/OS

IP-stack #3

VLAN unaware(Untagged frames)

VLAN aware(Tagged frames)

OSA #2


10.2.2 Sharing an OSA port with the same VLAN IDFigure 10-5 illustrates a single OSA 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 Address Table (OAT), the OSA logic bypasses the LAN environment and the packets are sent directly to the destination TCP/IP stack.

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

10.2.3 Primary and secondary router support with VLANsOSA provides primary (PRIRouter) and secondary (SECRouter) router support. This function allows a single TCP/IP stack, on a per-protocol (IPv4 and IPv6) basis, to register and act as a router stack based on a given OSA port. Secondary routers can also be configured to provide for conditions in which the primary router becomes unavailable and the secondary router takes over for the primary router. An OSA port supports the primary and secondary router function on a registered VLAN ID basis. This means that if an OSA 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.

z/OS V1R9 and later introduced the TCP/IP OSA virtual MAC (VMAC) function. VMAC support enables an OSA interface to have not only a physical MAC address, but also distinct virtual MAC addresses for each device or interface in a stack.

OSA

VLAN ID 100 VLAN ID 100

z/OS IP-stack #4

10.1.0.1/24 10.2.0.1/24

z/OS IP-stack #5

Trunk Mode

Access Mode

VLAN 2

Access Mode

VLAN 4

Access Mode

VLAN 3

ETHERNET Switch

z/VM

OSA

Router

LINUX1

IP-stack #1

VLAN ID 2

LINUX2

IP-stack #2

VLAN ID 3

z/OS

IP-stack #4

VLAN ID4

Tip: If your OSA ports are shared across multiple TCP/IP routing stacks, we highly recommend using virtual VMAC in your environment. It can simplify your network infrastructure and avoid PRIROUTER or SECROUTER setup issues when sharing a port between multiple LPARs. Refer to Chapter 9, “z/OS VMAC support” on page 123 for more details about VMAC.


10.2.4 Operating system supportAs mentioned earlier, z/OS, z/VM, and Linux on System z provide full VLAN support using the OSA features. It is possible to share an OSA port between Linux on System z and other operating systems.

10.3 VLAN support for z/OS z/OS provides full VLAN support for OSA-Express3, OSA-Express2, and OSA Ethernet features, running in QDIO mode. Up to z/OS V1R9, the existing VLAN support in the z/OS stack was limited to one VLAN per OSA per IP version (IPv4 and IPv6). This could inhibit your installation from consolidating OSA ports across different VLANs into a single port. With z/OS V1R10 Communications Server, you can configure multiple VLANs from the same TCP/IP stack for a single OSA feature. The multiple VLAN function allows you to consolidate multiple application servers across multiple stacks into a single z/OS image where the traffic related to these servers is on unique VLANs.

10.3.1 VLAN implementation In our VLAN environment the System z10 server consisted of one z/OS V1R10 LPAR and one z/VM V5.4 LPAR with LINUX guests. We shared the OSA-Express3 1000BASE-T feature (CHPID 0A) between the z/OS and z/VM LPARs.

We configured z/OS TCP/IP so that port 0 of the OSA-Express3 1000BASE-T feature would belong to VLAN 980 using the DEVICE, LINK, and HOME statements. Environments running z/OS V1R9 or older have to define their TCPIP VLAN environment with these statements. Only one VLAN ID per OSA port per stack per IP version is supported.

Starting with z/OS V1R10 Communications Server, you can use the INTERFACE statement in the TCP/IP profile to configure IPv4 definitions for OSA ports in QDIO mode rather than using the DEVICE, LINK, and HOME statements. The stack supports a maximum of eight VLAN IDs per interface to the same OSA port. We strongly recommend that you migrate and use the INTERFACE with z/OS V1R10 or later.

We will use the INTERFACE statement to configure our OSA-Express3 port 1 to belong to VLANs 981 and 982.

Figure 10-6 on page 139 provides an overview of our configuration. We enabled a connection between the VLANs through an Ethernet switch and defined two trunk ports for the OSA-Express3 connection. We also installed one workstation connected to the Ethernet switch.

Remember that if the OSA 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.

Note: On System z10 and System z9 servers multiple VLAN IDs on a single OSA port are supported by z/OS V1R10 TCP/IP (and later), and Linux on System z TCP/IP stacks.

Multiple VLAN IDs defined to a single OSA port are not supported with z/VM native; however, guest systems running under z/VM are supported.

Note: With z/OS V1R10, the stack supports a maximum of eight VLANs for each OSA port and each IP version (IPv4 and IPv6). This function is limited to OSA features in QDIO mode (CHPID type OSD) that support the Layer 3 Virtual MAC address (VMAC) function.


Figure 10-6 Our z/OS VLAN configuration

To define an OSA port in QDIO mode, refer to Chapter 5, “QDIO mode for z/OS” on page 67 for details.

10.3.2 Configuring OSA with VLAN IDThe first step is to plan the configuration of the switch that the OSA ports will be connected to.

Planning, configuration, and verification of the switch portsIt is important to be aware of the switch configuration and definitions to which the OSA ports will be connected. You will need to confirm the following information.

Table 10-1 shows the Ethernet switch port assignment with VLAN IDs and mode type in our configuration.

Table 10-1 Switch port assignment with VLAN IDs

We altered the configuration of the Ethernet switch to support VLANs and reserve a VLAN range of 980-999. Then we altered the two trunk ports. We added the VLANs 980-999 to both trunk ports 1/14 and 1/16. Finally we added VLAN 980 to port 1/10, where our workstation was connected.



z/OS V1R10

VTAM

TCP/IP A

192.168.3.64

OSAE200

E204-E207

OSAE204

OSAE200 OSAE204

DeviceNumber

IP Address

DEVICEINTERFACE

Portname

CHPID 0A

Ethernet Switch

192.168.1.65

OSAE204I

Port 0 Port 1

OSA2D80

OSAE200

z/VM

TCP/IP

VLAN IDs 980 981

Shared OSA ports in QDIO mode

VSWITCH (Layer 2)

LNXSU10 LNXRH5 TCPIP01

NIC

Linux Linux z/VM V5.4

NIC NIC

VLAN 981192.168.1.60

192.168.2.65

OSAE205I

982

E200-E203

VLAN982192.168.2.60

VLAN 982192.168.3.60

VLAN984192.168.5.60

VLAN 981192.168.1.10

Ethernet switch port VLAN ID (mode) Connection

Interface GIGA 1/10 980 (Access mode) Workstation

Interface GIGA 1/14 980-999 (Trunk mode) OSA (CHPID 0A) port 0 (E200)

interface GIGA 1/16 980-999 (Trunk mode) OSA (CHPID 0A) port 1 (E204)


We verified the configuration of the Ethernet switch by issuing the sh running-config command to check the running configuration (see Example 10-1).

Example 10-1 Extract of the sh run command

(enable) sh run !interface GigabitEthernet1/10 switchport switchport access vlan 980 switchport mode access no ip address!interface GigabitEthernet1/14 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 980-999 switchport mode trunk no ip address!interface GigabitEthernet1/16 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 980-999 switchport mode trunk no ip addressspeed 1000

Define a TRLE in VTAM to represent each OSA portTCP/IP uses a VTAM interface to run the OSA in QDIO mode. You must define and activate a Transport Resource List (TRL) major node before TCP/IP starts the QDIO device. Example 10-2 shows the TRLE definition used for our OSA-Express3 1000BASE-T (port 0).

Example 10-2 VTAM TRL major node for port 0

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

Example 10-3 shows the TRLE definition needed for our second OSA-Express3 1000BASE-T (port 1).

Example 10-3 VTAM TRL major node for port 1

OSAE204 VBUILD TYPE=TRL OSAE204P TRLE LNCTL=MPC, READ=E204, WRITE=E205, DATAPATH=(E206,E207,E208), PORTNAME=OSAE204, PORTNUM=1,


MPCLEVEL=QDIO

In order to use multiple VLANs for our OSA, we needed to configure a separate INTERFACE to the OSA for each VLAN. Each of these interfaces requires a separate DATAPATH device in the TRLE definition. Notice the higher number of defined datapath devices. We defined VLAN 981 and 982 with one INTERFACE statement for each VLAN, which will allocate E206 and E207. We reserved a datapath device for the OSA network traffic analyzer as well (E208).

We activated our Transport Resource List (TRL) major node before TCP/IP starts its QDIO device.

Activate the corresponding TRL minor node using the following VTAM command:

V NET,ACT,ID=OSAE200P and V NET,ACT,ID=OSAE204P

TCP/IP Profile definitions for OSA-Express3 port 0 (using DEVICE/LINK/HOME)Now we show you how to define OSA port 0 to TCP/IP. We create the DEVICE, LINK, and HOME statements required to define and assign this port to VLAN 981.

Example 10-4 shows the TCPIP profile definition for OSA-Express3 port 0. Notice that the VLANID parameter is part of the LINK statement.

Example 10-4 Extract of the TCPIP profile showing the definitions for OSA (port 0)

DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VLANID 980 ; HOME 192.168.1.164 VLINK1 192.168.3.64 OSAE200LNK ;BEGINROUTES ROUTE 192.168.3.0/24 = OSAE200LNK MTU 1492ENDROUTES ; START OSAE200

TCP/IP Profile definitions for OSA-Express3 port 1 (using INTERFACE) Next we show you how to define OSA port 1 to TCP/IP. We create the INTERFACE statement required to define and assign VLAN 981 and 982 to OSA port 1.

Using the INTERFACE statement

When defining multiple VLANs to an OSA port, use the following configuration rules:

� Define a unique VLAN ID in the stack profile for each IP version (IPv4 and IPv6).

� Configure the VMAC parameter on each INTERFACE statement with the default ROUTEALL attribute. The VMAC address can either be specified or OSA-generated. If you specify a VMAC address, it must be unique for each INTERFACE statement.

� Configure a unique subnet for each IPv4 interface for this OSA feature using the subnet mask specification on the IPADDR parameter on the INTERFACE statement.

Note: Remember that z/OS V1R10 TCPIP introduces the INTERFACE statement. If your installation runs an older z/OS release, you must use the DEVICE, LINK, and HOME statements when defining your OSA port.


Example 10-5 shows the TCPIP profile definition for OSA-Express3 (port 1).

Example 10-5 Extract of our TCPIP profile showing the definitions for port 1

INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.65/24 MTU 1492 VLANID 981 VMAC ROUTEALL ; INTERFACE OSAE205I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK2 IPADDR 192.168.2.65/24 MTU 1492 VLANID 982 VMAC ROUTEALL HOME 192.168.1.164 VLINK1 192.168.2.164 VLINK2 ; BEGINROUTES ROUTE 192.168.1.0/24 = OSAE204I MTU 1492 ROUTE 192.168.2.0/24 = OSAE205I MTU 1492 ENDROUTES ; START OSAE204I START OSAE205I

SOURCEVIPAINT

The SOURCEVIPAINTERFACE parameter must point to the link name of a static VIPA. For interfaces defined using DEVICE/LINK/HOME, source VIPA selection continues to work based on the ordering of the home list.

IPADDR with subnet mask

With the INTERFACE statement you can control VIPA ARP processing by configuring a subnet mask for the OSA. If you specify a non-0 num_mask_bits value on the IPADDR parameter of the INTERFACE statement, then the stack will inform OSA to only perform ARP processing for a VIPA if the VIPA is configured in the same subnet as the OSA.

INTERFACE statement - resource considerations:� Each VLAN requires a separate interface definition.

� Each interface requires a separate DATAPATH device in the TRLE definition.

� Each DATAPATH device consumes fixed storage.

� You can control the amount of storage, by using:

– QDIOSTG in the VTAM start option– READSTORAGE parameter on the INTERFACE statement


10.3.3 VerificationAfter activation, we verify that the VLAN IDs in our z/OS TCP/IP environment are defined correctly, by issuing the z/OS d tcpip,,netstat,dev command. See Example 10-6 for the output regarding OSA-Express3 1000BASE-T port 0.

Example 10-6 Results of the netstat dev command for OSA port 0

DEVNAME: OSAE200 DEVTYPE: MPCIPA DEVSTATUS: READY LNKNAME: OSAE200LNK LNKTYPE: IPAQENET LNKSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 020012345678 VMACORIGIN: CFG VMACROUTER: ALL ARPOFFLOAD: YES ARPOFFLOADINFO: YES ACTMTU: 1492 VLANID: 980 VLANPRIORITY: DISABLED DYNVLANREGCFG: NO DYNVLANREGCAP: YES READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED CHECKSUMOFFLOAD: YES SECCLASS: 255 MONSYSPLEX: NO BSD ROUTING PARAMETERS: MTU SIZE: N/A METRIC: 00 DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0 MULTICAST SPECIFIC:

The OSA device OSAE200 (port 0) shows the status ready and the VLANID 980 is assigned.

Now we verify that OSA device OSAE204 is working properly as well. Again, we issue the z/OS d tcpip,,netstat,dev command. See Example 10-7 for the output regarding OSA-Express3 1000BASE-T (port 1).

Example 10-7 Results of the netstat dev command for OSA port 1

INTFNAME: OSAE204I INTFTYPE: IPAQENET INTFSTATUS: READY PORTNAME: OSAE204 DATAPATH: E206 DATAPATHSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 02000974AA6D VMACORIGIN: OSA VMACROUTER: ALL SRCVIPAINTF: VLINK1 CFGROUTER: NON ACTROUTER: NON ARPOFFLOAD: YES ARPOFFLOADINFO: YES CFGMTU: 1492 ACTMTU: 1492 IPADDR: 192.168.1.65/24 VLANID: 981 VLANPRIORITY: DISABLED DYNVLANREGCFG: NO DYNVLANREGCAP: YES READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED CHECKSUMOFFLOAD: YES SECCLASS: 255 MONSYSPLEX: NO MULTICAST SPECIFIC: ...INTFNAME: OSAE205I INTFTYPE: IPAQENET INTFSTATUS: READY PORTNAME: OSAE204 DATAPATH: E207 DATAPATHSTATUS: READY SPEED: 0000000100 IPBROADCASTCAPABILITY: NO VMACADDR: 02000A74AA6D VMACORIGIN: OSA VMACROUTER: ALL SRCVIPAINTF: VLINK2


CFGROUTER: NON ACTROUTER: NON ARPOFFLOAD: YES ARPOFFLOADINFO: YES CFGMTU: 1492 ACTMTU: 1492 IPADDR: 192.168.2.65/24 VLANID: 982 VLANPRIORITY: DISABLED DYNVLANREGCFG: NO DYNVLANREGCAP: YES READSTORAGE: GLOBAL (4096K) INBPERF: BALANCED CHECKSUMOFFLOAD: YES SECCLASS: 255 MONSYSPLEX: NO MULTICAST SPECIFIC: MULTICAST CAPABILITY: YES

The output proves that both OSA interfaces OSAE204I and OSAE205I are up and ready. Each interface has its VLANID assigned and we can discover the two datapath devices that TCP/IP has allocated: E206 for OSAE204 and E205 for OSAE205. The VMAC addresses are shown as well.

Occasionally we have pointed out that the use of OSA/SF may help you in your installation, even if you are running OSA in QDIO mode only. Here comes some evidence.

In Example 10-8 we used OSA/SF to show the content of the OAT.

Example 10-8 Extract of the OAT for CHPID 0A using OSA/SF

START OF OSA ADDRESS TABLE--------------------------UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01) CULA 0000(E200)* MPC n/a OSAE200 (QDIO control) SIU ALL 02(E202) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL IPv4 VLAN 980 VMAC IP Address HOME 020012345678 192.168.1.164 HOME 020012345678 192.168.2.164 HOME 020012345678 192.168.3.64 Group Address Multicast Address 01005E000001 224.0.0.1 03(E203) MPC n/a No4 No6 OSAE200 (QDIO data) S ALL 04(E204)* MPC n/a OSAE204 (QDIO control) SIU ALL 06(E206) MPC 1 No4 No6 OSAE204 (QDIO data) SIU ALL IPv4 VLAN 981 VMAC IP Address HOME 02001B74AA6D 192.168.1.65 HOME 02001B74AA6D 192.168.1.164 Group Address Multicast Address 01005E000001 224.0.0.1 07(E207) MPC 1 No4 No6 OSAE204 (QDIO data) SIU ALL IPv4 VLAN 982 VMAC IP Address HOME 02001C74AA6D 192.168.2.65


HOME 02001C74AA6D 192.168.2.164

A closer look at the OAT helps us to easily verify our VLAN configuration.

Finally, we successfully tested the connections from our workstation to OSA device OSAE200, both belonging to VLAN 980, using ping commands. As expected, pinging from the workstation to OSA interfaces OSAE204I and OSA205I does not work. Additionally, the Linux guest LNXSU10 could successfully ping our OSA interface OSAE204I, both belonging to VLAN 981.

10.4 VLAN support for LinuxVLAN support was added to the Linux kernel in Version 2.4.19. If your Linux system is not running at this level or a later one, you need an updated kernel to 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]>

10.4.1 VLAN implementation In our environment (see Figure 10-7) we configured two VLANs, one for each Linux system. We enabled a connection between the two VLANs through an Ethernet switch, and defined the OSA connection in trunk mode. We also installed two workstations, one defined to each VLAN.

Note: Remember that if the OSA 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.


Figure 10-7 VLAN configuration - Linux on System z

A VLAN is defined for an existing Ethernet interface. The vconfig command is used to add or remove a VLAN configuration for a defined Ethernet interface.

LINUX commandsOn LINUX2 and LINUX3, we defined the VLAN configurations and brought up the interfaces, using the following commands:

� LINUX2

vconfig add eth1 200ifconfig eth1.200 200.1.1.1 netmask 255.255.255.0 up

� LINUX3

vconfig add eth1 210ifconfig eth1.210 210.1.1.1 netmask 255.255.255.0 up

After issuing the vconfig add commands on the respective systems, we received 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 downvconfig rem eth1.200

Trunk Mode

Access Mode

VLAN 200

Access Mode

VLAN 210

Client 1 Client 2

Trunk connection to support VLAN 200 and 210 traffic

LINUX 2:

vconfig add eth1 200ifconfig eth1.200 200.1.1.1netmask 255.255.255.0 up

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

Port assigment for the Ethernet Switch

Ethernet Switch

LINUX2 LINUX3z/VM

LINUX3

LINUX 3:

vconfig add eth1 210ifconfig eth1.210 210.1.1.1netmask 255.255.255.0 up

ETH1VLAN 200200.1.1.1

ETH1 VLAN 210210.1.1.1

OSA


Startup configurationConfiguring 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 automatically include VLAN boot-time configuration in their network scripts.

Ethernet switch configurationWe altered the configuration of the Ethernet switch to support the VLANs and the trunk port. We added VLAN ID 200 to port 2/5 and VLAN ID 210 to port 2/6, as well as defined port 2/1 as a trunk port.

10.4.2 VerificationWe verified the VLAN definitions with the ifconfig command on LINUX2 and LINUX3. Example 10-9 shows the results from LINUX3.

Example 10-9 Results of the ifconfig command

ifconfigeth1.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 verified the configuration of the Ethernet switch with the sh running-config command to check the running configuration (see Example 10-10).

Example 10-10 Extract of the sh running-config command

pok6509t (enable) sh run #vtpset vtp domain itso_networkset vtp mode transparentset vlan 1 name default type ethernet mtu 1500 said 100001 state activeset vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state activeset vlan 210 name VLAN0300 type ethernet mtu 1492 said 100201 state active

#spantree#portfastset spantree global-default bpdu-guard enable!#module 2 : 48-port 10/100BaseTX Ethernetset vlan 200 2/5set vlan 210 2/6

set trunk 2/1 on dot1q 1-1005,1025-4094set trunk 2/2 on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enableset spantree guard none 2/1-48


We successfully tested 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 failed.

10.5 VLAN support in z/VM z/VM provides the following support:

� Enhancements to TCP/IP for z/VM to enable membership in a VLAN

� Enhancements to z/VM virtual QDIO and HiperSockets networking interfaces 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

10.5.1 z/VM native VLAN supportIn our environment (see Figure 10-8), we had a z/VM V5R4 LPAR and an OSA port. The OSA port was connected to a trunk port on an Ethernet switch. We also had a workstation, which was connected to an access port on the same Ethernet switch.

We configured a VLAN 200 in the z/VM TCP/IP stack for the OSA port, using the parameter VLAN on the LINK statement in the TCP/IP profile. VLAN is an optional parameter followed by a number indicating the VLAN identifier to be assigned to the OSA port. The valid range is 1 - 4094. The value used should be a VLAN identifier recognized by the Ethernet switch to which the OSA port is connected.

Figure 10-8 z/VM VLAN configuration

Ethernet switch configurationWe altered the configuration in the Ethernet switch to support the VLAN and the trunk port. We added the VLAN 200 to port 2/5 and defined port 2/1 as a trunk port.

Trunk Mode

Access Mode

VLAN 200

Client 1

Trunk connection to supportVLAN 200 traffic

Port Type VLAN ID Connection 2/1 TRUNK n/a OSA-Express 2/5 ACCESS VLAN 200 Client 1

Port assigment for the Ethernet Switch

DEVICE OSA2D48 OSD 2D48 PORTNAME OSACHP0D LINK OSA2D48L QDIOETHERNET OSA2D48 VLAN 200 ... HOME 192.16.1.40 OSA2D48L ... GATEWAY 192.16.1 = OSA2D48L 1500 0

PROFILE TCP/IP

VLAN ID 200

z/VM V5R4TCP/IP

IP Address 192.16.1.40

Ethernet Switch

OSA


10.5.2 VerificationAfter activation, we verified that the VLAN ID in our z/VM TCP/IP environment was defined correctly with the netstat dev command (see Example 10-11).

Example 10-11 Results of the netstat dev command on VM5

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

We verified the configuration of the Ethernet switch with the sh running-config command to check the running configuration (see Example 10-12).

Example 10-12 Extract of the sh running-config command

sh run #vtpset vtp domain itso_networkset vtp mode transparentset vlan 1 name default type ethernet mtu 1500 said 100001 state activeset vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state active

#spantree#portfastset spantree global-default bpdu-guard enable!#module 2 : 48-port 10/100BaseTX Ethernetset vlan 200 2/5

set trunk 2/1 on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enableset spantree guard none 2/1-48

We successfully tested the connection from Client 1 to z/VM, using the ping command. As expected, pinging from z/VM to other clients and systems outside VLAN 200 failed.


Chapter 11. z/VM virtual switch

The z/VM virtual switch is built on guest LAN technology and consists of a network of virtual adapters that can be used to interconnect guest systems. The virtual switch can also be associated with one or more OSA ports. This capability allows access to external LAN segments without requiring an intermediate router between the external LAN and the internal z/VM guest LAN.

The virtual switch can operate at Layer 2 (data link layer) or Layer 3 (network layer) of the OSI model.

In this chapter we describe the elements and capabilities of the virtual switch in conjunction with OSA Ethernet features, and explain how to implement Layer 2 support, VLAN support, port isolation, and link aggregation in such an environment.

11


11.1 Virtual switch descriptionThe virtual switch bridges real hardware and virtualized LANs, using virtual QDIO adapters. External LAN connectivity is achieved through OSA Ethernet features configured in QDIO mode. Like the OSA Ethernet features, the virtual switch supports the transport of Layer 2 (Ethernet frames) and Layer 3 (IP packets) traffic.

By default, the virtual switch operates in IP mode (Layer 3) and data is transported within IP packets. Each guest system is identified by one or more IP addresses for the delivery of IP packets. All outbound traffic destined for the physical portion of the LAN segment is encapsulated in Ethernet frames with the MAC address of the OSA port, as the source MAC address. With inbound traffic, the OSA port strips the Ethernet frame and forwards the IP packets to the virtual switch for delivery to the guest system based on the destination IP address within each IP packet.

When operating in Ethernet mode (Layer 2), the virtual switch uses a unique MAC address for forwarding frames to each connecting 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. 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 through an attached OSA port. All inbound or outbound frames passing through the OSA port have the guest system’s corresponding MAC address as the destination or source address.

The switching logic resides in the z/VM Control Program (CP) which owns the OSA port connection and performs all data transfers between guest systems connected to the virtual switch and the OSA port (see Figure 11-1).

Figure 11-1 Virtual switching logic

In this chapter we concentrate primarily on the OSA Layer 2 support. We highlight the Ethernet mode (Layer 2) capabilities of a z/VM virtual switch (VSWITCH) and the definitions required to implement such an environment.

In the remainder of this section we discuss the elements that make up the virtual switch and its capabilities.

Virtual Switch

Guest 1

OSA Port

z/VM Control Program

Ethernet Switch

Guest 2 Guest 3

NIC NIC NIC

Port 3Port 2Port 1

Real Device


11.1.1 VSWITCH controllerVSWITCH connectivity to an OSA device is managed through a controller virtual machine. The controller is responsible for the management of the OSA devices that are attached to the virtual switch. It handles the initialization of the device and communicates configuration information to the OSA port. In QDIO or OSA device terms, you can think of the controller as the manager of the control read and write devices and the Control Program (CP) as the manager of the data device. To enable this functionality, at least one TCP/IP virtual machine must be configured to act as a controller.

Two VSWITCH controllers (DTCVSW1 and DTCVSW2) come predefined with the base installation of z/VM V5R3 and later releases. They are started during the IPL of the z/VM system through user AUTOLOG1. Both controllers are monitored by TCP/IP and get restarted should they become unresponsive.

11.1.2 Network interface card A network interface card (NIC) is a set of virtual I/O devices that simulate one of the following network adapters:

� OSA (in QDIO mode)� HiperSockets

Each guest system that is going to connect to a virtual switch needs to have at least one virtual NIC defined. Once 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), using CP commands. These CP commands are typically put into the guest system’s PROFILE EXEC together with the required COUPLE of the QDIO NIC to an existing VSWITCH, virtual HiperSockets LAN or real HiperSockets LAN.

MAC addressesA MAC address provides the identification for Ethernet frames that are transported across a LAN segment. A virtual NIC is assigned a locally defined MAC address by z/VM when it is created. These locally generated MAC addresses are visible across the physical portion of the LAN segment via an OSA port when the VSWITCH is running in Layer 2 mode.

You can specify which MAC addresses are locally generated and assigned to each guest. system. 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 you to specify a three byte ID prefix for all MAC addresses in the 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 that will connect to the virtual switch. The MACID parameter of NICDEF allows you to specify a unique identifier that is appended to the MACPREFIX to form a unique MAC address for that guest system. If MACID is omitted, CP generates a unique identifier based on the range specified in the MACIDRANGE parameter. If you specify a MACID value in the NICDEF that is already in use by another guest system, the virtual network adapter is not created. Therefore, it is

Note: Unlike previous networking configurations that deployed a Guest LAN with a router virtual machine TCP/IP stack, there is no requirement to define any IP addresses or devices in the TCP/IP stack for the VSWITCH controller virtual machines.

Chapter 11. z/VM virtual switch 153

recommended that a MACID value be used to ensure that the guest systems maintain a consistent, predictable MAC address.

11.1.3 VSWITCH capabilitiesIn this section we describe the key VSWITCH capabilities used in conjunction with the OSA Ethernet features:

� Layer 2 and Layer 3 support� VLAN support� Port isolation support� Link aggregation support

Layer 2 and Layer 3 supportLayer 2 and Layer 3 support relate to transport modes. A transport mode is a method used to identify, manage, and transport data through the virtual switch. The virtual switch supports two transport modes: IP mode and Ethernet mode. A virtual switch can operate in only one of the two transport modes, exclusively.

IP modeIn this mode, the virtual switch operates at Layer 3 (Network Layer) of the OSI model. IP addressing is used in IP mode to transport TCP/IP application data. The virtual switch works in conjunction with the Layer 3 support of the OSA Ethernet features to communicate with hosts residing in an IP network. By default, the virtual switch operates in IP mode.

The key attributes for IP mode are:

� Supports IP for TCP/IP applications only. � IP packets are transported on the LAN segment.� All destinations are identified by IP addresses.� IP address assignments are set by the TCP/IP stack in the guest virtual machine.� Each TCP/IP stack can have more than one IP address.� ARP processing is offloaded to the OSA adapter. � VLAN tagging resides in internal QDIO headers. � All TCP/IP stacks share the OSA “burnt-in” MAC address. � IPv4 networks only.

Ethernet modeIn this mode, the virtual switch operates at Layer 2 (Data Link Layer) of the OSI model. Since Ethernet mode uses MAC addressing to forward frames, it is protocol-independent, providing the ability to transport both TCP/IP and non-TCP/IP application data (such as SNA, DECnet, IPX™, or NetBIOS). The virtual switch works in conjunction with the Layer 2 support of the OSA Ethernet features to communicate with hosts residing on a physical LAN segment to which the OSA port is connected.

The key attributes for Ethernet mode are:

� Supports all applications that deploy Ethernet (IEEE 802.2).

� Ethernet frames are transported on the LAN segment.

� All destinations are identified by MAC address.

� MAC addresses can be locally administered through z/VM CP commands or configuration statements.

� Each connection is identified by a single MAC address.

� TCP/IP stack maintains its own ARP cache.


� VLAN tagging resides within the Ethernet frames per IEEE 802.1Q specifications.

� IPv4 and IPv6 networks are supported.

� Required for deployment of link aggregation.

With Ethernet mode the path length for transporting data is reduced because there is no need to traverse an extra layer up the protocol stack. For this reason, and the functional benefits, we recommend using the VSWITCH in Ethernet mode.

VLAN supportVLAN capability in the VSWITCH is based on IEEE standards 802.1p/q and is supported by OSA Ethernet features running in QDIO mode. VLAN support works with both Layer 2 and Layer 3 transport modes in the VSWITCH.

The purpose of VLANs is to provide logical isolation. Therefore, VLANs behave like separate physical networks, even though they may be contained within the same switch or VSWITCH. In order for devices in different VLANs to communicate, IP routing must occur.

The VLAN protocol uses additional information in the Ethernet header stored after the destination and source MAC address. The information marks the frame as one that contains a VLAN ID. This technique is known as tagging.

Delivery of frames tagged with a VLAN ID is controlled by the physical switch or VSWITCH, not by the devices connecting to the same infrastructure.

How the VSWITCH is defined (with or without the VLAN option) determines whether it is VLAN aware or VLAN unaware.

The VSWITCH supports two VLAN mode types: access mode and trunk mode. These modes specify whether the VSWITCH will apply a VLAN tag (access mode) or expects the VLAN tag (trunk mode) to be applied by the connected guest system.

Ports in access modeAn access port is a type of connection in a VSWITCH that is used to transport data from a guest system which is VLAN unaware. This port provides the guest system with connectivity through a VSWITCH that is VLAN aware, without requiring the guest system to support VLAN tagging.

Access port definitions work with a Layer 2 or a Layer 3 VSWITCH. Only one VLAN ID can be used for each access port.

Ports in trunk mode A trunk port is a type of connection in a VSWITCH that is used to transport data from a guest system that is VLAN aware. Generally, all frames that flow through this port are VLAN tagged. The exception to this is when a trunk port is granted access to the untagged VLAN set.

Trunk port definitions work with a Layer 2 and a Layer 3 VSWITCH. Multiple VLAN IDs can be assigned to each trunk port.

Port isolation supportThrough the port sharing capabilities of the OSA feature and VSWITCH, systems operating in separate z/VM images or LPARs can communicate directly through the same OSA feature or VSWITCH without sending data out to the physical network. In some cases, this can pose a security threat, which can be eliminated with the use of VLANs. However, VLANs may not satisfy all requirements for complete isolation.


Port isolation does this by separating and isolating frames within the VSWITCH, and preventing guest systems that share the same VSWITCH from communicating with each other.

When port isolation is turned on, traffic will also be blocked between those guest systems sharing the VSWITCH and OSA port. All network traffic is forced to pass through the physical OSA port. Only routing outside the System z server will allow connectivity back into the VSWITCH. This is also true for multiple VSWITCHs sharing the same OSA port and for connections to other logical partitions sharing the same OSA port.

Link aggregation supportLink aggregation support allows up to eight dedicated OSA ports to appear as a single logical link for data transmissions with a physical LAN. This capability provides load balancing and failover for a VSWITCH.

In z/VM these links are OSA ports that are grouped on a VSWITCH operating in Ethernet mode (Layer 2), and given a groupname. From the VSWITCH perspective the group is treated as a single link for external connectivity. A port group on the VSWITCH conforms to the Link Aggregation Group (LAG) defined by IEEE 802.3ad.

When OSA ports are grouped into a LAG, they are no longer sharable with other operating systems or LPARs. Once an OSA port is removed from the group, it is sharable once again.

For more details about these topics and z/VM communication services and concepts, refer to z/VM Connectivity Version 5, SC24-6080.

11.2 Our VSWITCH environmentFigure 11-2 on page 157 shows our VSWITCH environment, which consisted of a z/VM V5R4 LPAR and a z/OS V1R10 LPAR sharing four OSA-Express3 1000BASE-T ports in two separate features. The four OSA ports were connected to ports on an Ethernet switch that were defined as trunk ports. The OSA ports were defined to our System z10 server as channel type OSD (QDIO), which is a requirement for Layer 2 support.

Two virtual switches were configured in the z/VM LPAR with two virtual controllers (primary and backup). The OSA ports were attached to the virtual switches to provide connectivity from the guest systems to the external LAN.

Under z/VM, two Linux guest systems were configured:

� LNXSU10 (SUSE Linux Enterprise Server (SLES) 10 at level 2.6.16.600.3)

� LNXRH5 (Red Hat 5 at level 2.6.18-92.e15)

Note: VSWITCH administration is a dynamic process, it allows you to change access authorizations on the fly. However, for changes to the attributes of the VSWITCH (such as transport mode or VLAN aware/unaware), the VSWITCH must be redefined.


Figure 11-2 The VSWITCH environment

Figure 11-2 is a multipurpose diagram used throughout the remainder of this chapter.

The purpose of our VSWITCH environment was to show the following functionality:

1. Layer 2 within the VSWITCH, Linux guest systems, and OSA ports

2. VLAN support across the VSWITCH, Linux guest systems, z/OS environment, and the clients connected to the Ethernet switch

3. Port isolation across the Ethernet switch between the VSWITCH, Linux guest systems, and z/OS environment

4. Link aggregation across the VSWITCH, the OSA ports, and Ethernet switch

We provide setup and verification examples in the following sections:

� Configuring a Layer 2 VSWITCH� Configuring VLAN support� Enabling port isolation� Configuring link aggregation support

To validate our VSWITCH environment we used OSA/SF and various system commands. You will find examples of their usage in the subsequent sections of this chapter.

Tip: We recommend checking the appropriate Preventive Service Planning buckets for required APARs and PTFs before implementing the VSWITCH in your environment.

eth1eth1 eth0eth0

LNXRH5LNXSU10z/VMV5R4

L2SW1L2SW2

Ethernet Switch

T = Trunk ModeA = Access Mode

CHPID 0B2D80-2D82 2D84-2D86

Port 0 Port 1CHPID 0A

E200-E202 E204-E206

Port 0 Port 1

VTAM / TRL

z/OSV1R10

eth1eth1 eth0eth0


L2SW1L2SW2

Ethernet Switch


CHPID 0B2D80-2D82 2D84-2D86


E200-E202 E204-E206

Port 0 Port 1CHPID 0B

2D80-2D82 2D84-2D86


2D80-2D82 2D84-2D86


2D80-2D82 2D84-2D86


E200-E202 E204-E206


E200-E202 E204-E206


E200-E202 E204-E206

Port 0 Port 1

VTAM / TRL

z/OSV1R10


11.3 Configuring a Layer 2 VSWITCHIn this section, we discuss how our VSWITCH was configured in Ethernet mode to support Layer 2 traffic and how this environment was verified.

Figure 11-3 shows our Layer 2 virtual switch configuration.

Figure 11-3 Layer 2 virtual switch configuration

In this section, we show how to do the following:

� Configure a Layer 2 virtual switch environment, using OSA ports� Verify the Layer 2 virtual switch environment� Verify connectivity between guests and clients connected through the virtual switch and

OSA port

11.3.1 Defining the virtual switch environmentThese are the steps we took to implement our Layer 2 VSWITCH environment:

1. Defined a virtual switch to provide network connectivity between guest systems and clients via the OSA port.

2. Authorized access for each guest system to the virtual switch.

3. Created a simulated NIC on each guest system to be connected to the virtual switch.

4. Verified the configuration.

eth1

192.168.1.61

192.168.2.61

192.168.3.61

eth1

192.168.1.60

192.168.2.60

192.168.3.60

eth0eth0


L2SW1L2SW2

Ethernet Switch


192.168.3.2

CHPID 0B2D80-2D82 2D84-2D86


E200-E202 E204-E206

Port 0 Port 1

VTAM / TRL2E200-E202 E204-E206

z/OSV1R10

TCP/IPOSAE200I

192.168.3.65/24OSAE204I

192.168.1.65/24OSAE205I

192.168.2.65/24eth1

192.168.1.61

192.168.2.61

192.168.3.61

eth1

192.168.1.60

192.168.2.60

192.168.3.60

eth0eth0


L2SW1L2SW2

Ethernet Switch


192.168.3.2

CHPID 0B2D80-2D82 2D84-2D86


E200-E202 E204-E206


E200-E202 E204-E206

Port 0 Port 1

VTAM / TRL2E200-E202 E204-E206

z/OSV1R10

TCP/IPOSAE200I

192.168.3.65/24OSAE204I

192.168.1.65/24OSAE205I

192.168.2.65/24


A virtual switch is created using the CP DEFINE VSWITCH command from any z/VM Class B user (such as MAINT, TCPMAINT or AUTOLOG1), or by adding the following definition to SYSTEM CONFIG:

DEFINE VSWITCH L2SW1 RDEV E200 2D80 ETHERNET

The ETHERNET parameter indicates that the virtual switch will operate in Ethernet mode providing Layer 2 functionality. The virtual switch is connected to two OSA ports, CHPID 0A (devices E200- E202), and CHPID 0B (devices 2D80 - 2D82).

Devices 2D80 - 2D82 are for a secondary interface that will be used in the event of a problem with the primary interface (devices E200-E202).

The syntax of the DEFINE VSWITCH statement is as follows:

DEFINE VSWITCH switchname [ operands ]

The switchname is the name of the virtual switch, and the operands define the attributes of the virtual switch.

Adding VMLANIn 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 the individual NIC devices the guest systems use. We used the default system generated MAC address settings, because we only had a single z/VM system in our environment.

The syntax of the VMLAN statement is as follows:

VMLAN [ operands ]

In this statement, operands defines the attributes to be set for all z/VM Guest LANs in the system. The definitions in Example 11-1 can be used to modify the default VMLAN values.

Example 11-1 VMLAN definition

VMLAN MACPREFIX 02EEEE VMLAN MACIDRANGE SYSTEM 100000-1FFFFF

Refer to CP Commands and Utilities Reference, SC24-6081 for all operands accepted by the commands used in the chapter.

11.3.2 Authorizing the guest system access to the virtual switchTo authorize guest system access to a VSWITCH, statements need to be added to the SYSTEM CONFIG on MAINT parm disk CF1. We added MODIFY VSWITCH statements (see

Note: Definitions made in the z/VM SYSTEM CONFIG file can be added to the PROFILE EXEC of the user AUTOLOG1. The AUTOLOG virtual machine is automatically logged on as part of the z/VM IPL sequence and is a very convenient way to make definitions permanent.

Tip: If you run multiple z/VM systems on a System z server, change the MACPREFIX of each system to avoid MAC address duplication.


Example 11-2) to grant access to the virtual switch. You can also use SET VSWITCH commands to achieve the same results.

Example 11-2 MODIFY VSWITCH statement in SYSTEM CONFIG file

MODIFY VSWITCH L2SW1 GRANT LNXSU10MODIFY VSWITCH L2SW2 GRANT LNXSU10MODIFY VSWITCH L2SW1 GRANT LNXRH5MODIFY VSWITCH L2SW2 GRANT LNXRH5

To add, change, or remove authorizations of guest systems, the z/VM CP provides the Class B command SET VSWITCH switchname.

Example 11-3 Add user authorization, using CP commands

SET VSWITCH L2SW1 GRANT LNXSU10SET VSWITCH L2SW2 GRANT LNXSU10SET VSWITCH L2SW1 GRANT LNXRH5SET VSWITCH L2SW1 GRANT LNXRH5

Example 11-4 Revoke a user authorization, using CP commands

SET VSWITCH L2SW1 REVOKE LNXSU10

This function can also be performed by an ESM, such as RACF. For more information regarding the use of an ESM, refer to “z/VM virtual switch authorization” on page 288.

11.3.3 Connecting the guest systems to the VSWITCHTo connect guest systems to the VSWITCH, virtual NICs are needed. 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), a NICDEF statement needs to be added to the z/VM user directory.

The NICDEF statement defines virtual OSA devices, which are fully simulated by CP. Example 11-5 shows a sample user directory entry for our Linux guests that connect to the VSWITCH (L2SW1).

Example 11-5 NICDEF statements for Linux guests connecting to L2SW1

USER LNXSU1 LNXSU10 128M 1G G NICDEF 8000 TYPE QDIO LAN SYSTEM L2SW1 USER LNXSU2 LNXRH5 128M 1G G NICDEF 8000 TYPE QDIO LAN SYSTEM L2SW1

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

Note: We could have added a MACID parameter to the NICDEF statement. Instead, we chose to let the system generate the MAC address for us.


The syntax of the NICDEF statement for a virtual NIC is:

NICDEF vdev TYPE QDIO [ operands ]

In this statement, vdev specifies the base virtual device address for the adapter, and operands defines the characteristics of the virtual NIC.

11.3.4 Verifying the virtual switch configurationWe performed an initial program load (IPL) of our z/VM LPAR and checked to ensure that the changes we made were correct by querying the controller, VSWITCH, NIC, VMLAN, and access authorizations.

Checking the controllerTo check whether the VM TCP/IP stacks are recognized as controller virtual machines the QUERY CONTROLLER command can be used (see Example 11-6).

Example 11-6 QUERY CONTROLLER output

QUERY CONTROLLER Controller DTCVSW1 Available: YES VDEV Range: * Level 540 Capability: IP ETHERNET VLAN_ARP GVRP LINKAGG ISOLATION SYSTEM L2SW1 Backup Controller: * VDEV: 2D80 Controller DTCVSW2 Available: YES VDEV Range: * Level 540 Capability: IP ETHERNET VLAN_ARP GVRP LINKAGG ISOLATION SYSTEM L2SW1 Primary Controller: * VDEV: E200

Checking the VSWITCHTo check the state of the virtual switch the QUERY VSWITCH command can be used (see Example 11-7).

Example 11-7 QUERY VSWITCH

QUERY VSWITCH L2SW1 VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 1 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Unaware MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP

Checking the VMLANIf you elect to change the default system-wide MAC addresses instead of the system default MAC addresses, use the QUERY VMLAN command to check whether the VMLAN changes are applied (see Example 11-8 on page 162).

Note: We could have made all our changes dynamically by issuing the configuration commands directly from MAINT or any other Class B user ID. Dynamic changes are useful when you are unable to IPL z/VM, or if the changes are only intended to be temporary.


Example 11-8 QUERY VMLAN

QUERY VMLAN VMLAN maintenance level: Latest Service: VM64471 VMLAN MAC address assignment: MACADDR Prefix: 020000 MACIDRANGE SYSTEM: 000001-FFFFFF USER: 000000-000000 VMLAN default accounting status: SYSTEM Accounting: OFF USER Accounting: OFF VMLAN general activity: PERSISTENT Limit: INFINITE Current: 3 TRANSIENT Limit: INFINITE Current: 0

Checking authorizationTo check the access list of the authorized user IDs for the virtual switch, use the QUERY VSWITCH switchname ACC command (see Example 11-9).

Example 11-9 QUERY VSWITCH command

QUERY VSWITCH L2SW1 ACC VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 1 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Unaware MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Authorized userids: LNXRH5 LNXSU10 SYSTEM RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP

Checking the NICsTo check the NIC for each guest system, enter the QUERY NIC DETAILS command from the guest system’s z/VM user ID (see Example 11-10).

Example 11-10 QUERY NIC details

QUERY NIC DETAILS Adapter 8000.P00 Type: QDIO Name: UNASSIGNED Devices: 3 MAC: 02-00-00-00-00-08 VSWITCH: SYSTEM L2SW1 RX Packets: 28 Discarded: 0 Errors: 0 TX Packets: 57 Discarded: 149 Errors: 0 RX Bytes: 2157 TX Bytes: 3918 Connection Name: HALLOLE State: Session Established Device: 8000 Unit: 000 Role: CTL-READ Device: 8001 Unit: 001 Role: CTL-WRITE Device: 8002 Unit: 002 Role: DATA vPort: 0065 Index: 0065 VLAN: 0980 0981 0982 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-08 Multicast MAC Addresses:


01-00-5E-00-00-01 33-33-00-00-00-01 33-33-FF-00-00-08

Note that the default MAC address 02-00-00-00-00-08 was assigned by the system.

11.3.5 Setting up Layer 2 for the guest systemsWe chose to configure a static IP address for each Linux guest LNXSU10 (192.168.1.60) and LNXRH5 (192.168.1.61), using the following commands:

ifconfig eth0 192.168.1.60 netmask 255.255.255.0 upifconfig eth0 192.168.1.61 netmask 255.255.255.0 up

To test our environment, we issued PING commands between LNXSU10, LNXRH5, and the workstations connected through an OSA port that were attached to an Ethernet switch.

Configuring a Linux device has changed from using /etc/chandev.conf to the use of the sysfs structure. Scripts located in /etc/sysconfig/hardware and /etc/sysconfig/network/ for SUSE, and /etc/sysconfig/network-scripts/ for Red Hat configure the qeth devices and network definitions.

Besides making permanent definitions using the appropriate scripts, those definitions can also be made dynamically. See Device Drivers, Features and Commands, SC33-8289 for details.

11.3.6 Creating definitions for Layer 2 support - SUSE and Red HatFor Layer 2 support, an OSA QDIO device must be attached and defined to the Linux running on a System z. We used a virtual NIC with addresses 8000, 8001, and 8002 that were coupled or attached to the VSWITCH.

To activate the interface you echo the addresses of the OSA devices (real or virtual) to the sysfs structure (see Example 10-11).

Example 11-11 Echo command

echo 0.0.8000,0.0.8001,0.0.8002 > /sys/bus/ccwgroup/drivers/qeth/group

The Linux 3270 console will display the status of the OSA devices (see Example 11-12).

Example 11-12 3270 console message

LNXSU10 : qeth: Device 0.0.8000/0.0.8001/0.0.8002 is a Guest LAN QDIO card (level: V542)with link type GuestLAN QDIO (portname: ) qeth: MAC address 02:00:00:00:00:04 successfully registered on device eth1

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.


The /var/log/messages file contains entries that show the status of the OSA devices (see Example 11-13).

Example 11-13 Contents of /var/log/messages file

Oct 20 15:48:54 linux-su10 kernel: qeth: Device 0.0.8000/0.0.8001/0.0.8002 is a Guest LAN QDIO card (level: V542)Oct 20 15:48:54 linux-su10 kernel: with link type GuestLAN QDIO (portname: )Oct 20 15:48:54 linux-su10 kernel: qeth: MAC address 02:00:00:00:00:04 successfully registered on device eth1Oct 20 15:48:55 linux-su10 ifup: eth1Oct 20 15:48:55 linux-su10 ifup: eth1 configuration: qeth-bus-ccw-0.0.8000Oct 20 15:49:05 linux-su10 kernel: eth1: no IPv6 routers present

The results of the echo command for the OSA devices can also be viewed by displaying the contents of /proc/qeth (see Example 11-14).

Example 11-14 cat /proc/qeth command

devices CHPID interface cardtype port chksum prio-q'ing rtr4 rtr6 -------------------------- ----- ---------- -------------- ---- ------ ---------- ---- ---- 0.0.7000/0.0.7001/0.0.7002 x03 eth0 GuestLAN QDIO 0 sw always_q_2 no no 0.0.8000/0.0.8001/0.0.8002 x04 eth1 GuestLAN QDIO 0 sw always_q_2 no no

The interface name is eth1 and should be online. To check this, do the following:

cat /sys/bus/ccwgroup/drivers/qeth/0.0.8000/online

The output should be 1 if the device is online.

Once the interface is registered successfully, the network definitions can be created (see Example 11-15).

Example 11-15 Defining the eth1 interface for LNXSU10

ifconfig eth3 192.168.1.60 netmask 255.255.255.0

On the z/VM side, we verified the connection by using the QUERY VSWITCH command as shown in Example 11-16.

Example 11-16 Query VSWITCH detail - output

QUERY VSWITCH L2SW1 DET VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Unaware MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 VSWITCH Connection: RX Packets: 0 Discarded: 0 Errors: 0


TX Packets: 34 Discarded: 0 Errors: 0 RX Bytes: 0 TX Bytes: 8028 Device: E200 Unit: 000 Role: DATA vPort: 0001 Index: 0001 RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP Adapter Connections: Adapter Owner: LNXRH5 NIC: 8000.P00 Name: UNASSIGNED RX Packets: 6 Discarded: 0 Errors: 0 TX Packets: 33 Discarded: 79 Errors: 0 RX Bytes: 476 TX Bytes: 7994 Device: 8002 Unit: 002 Role: DATA vPort: 0067 Index: 0067 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-06 IP: 192.168.1.61 Multicast MAC Addresses: 01-00-5E-00-00-01 01-00-5E-00-00-FB 33-33-00-00-00-01 33-33-00-00-00-FB 33-33-FF-00-00-06 Adapter Owner: LNXSU10 NIC: 8000.P00 Name: UNASSIGNED RX Packets: 6 Discarded: 76 Errors: 0 TX Packets: 12 Discarded: 199 Errors: 0 RX Bytes: 476 TX Bytes: 944 Device: 8002 Unit: 002 Role: DATA vPort: 0066 Index: 0066 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-04 IP: 192.168.1.60 Multicast MAC Addresses: 01-00-5E-00-00-01 33-33-00-00-00-01

Notice that both LNXSU10 and LNXRH5 are connected to the virtual switch (L2SW1). Also, the IP addresses shown are those defined using the ifconfig command. Furthermore, you can see that system-generated MAC addresses are associated with the IP addresses.

We used the PING command to verify connectivity between LNXSU10 and LNXRH5 via the virtual switch.

11.3.7 Making permanent device and network definitionsSUSE and Red Hat provide a set of GUI tools and shell scripts to configure network devices and network settings. However, depending on the distribution, different members are created.

Creating permanent Layer 2 definitions for SUSE In order to make all the definitions from the previous section permanent, we coded the required information into the distribution-specific configuration member.

SUSE SLES 10 has two locations where the final hardware- and network-related configuration files are stored. These locations will not change.

� Hardware-related definitions are stored at:

/etc/sysconfig/hardware

� Network interface definitions are stored at:

/etc/sysconfig/network


You will have to decide whether you will use one of the existing interfaces or create a new interface.

In our environment we created a new member for device address 8000. SUSE uses file names created from the type of hardware combined with the hardware address; see Example 11-17. OSA QDIO devices are named as follows:

� hwcfg-qeth-bus-ccw-0.0.7000� hwcfg-qeth-bus-ccw-0.0.8000

Example 11-17 /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.7000

STARTMODE='auto'MODULE='qeth'MODULE_OPTIONS=''MODULE_UNLOAD='yes'SCRIPTUP='hwup-ccw'SCRIPTUP_ccw='hwup-ccw'SCRIPTUP_ccwgroup='hwup-qeth'SCRIPTDOWN='hwdown-ccw'CCW_CHAN_IDS='0.0.7000 0.0.7001 0.0.7002'CCW_CHAN_NUM='3'QETH_LAYER2_SUPPORT='0'

To create a new QDIO device definition simply copy one of the existing definition files into a new file making the address portion of the filename fit the address of the new QDIO device you have chosen. After this is completed, open the new file and change the device addresses in the CCW_CHAN_IDS statement to match the new interface. If you plan to implement Layer 2 support, then insert a QETH_LAYER2=’1’ statement.

On our SUSE system we created the hardware configuration member in Example 11-18 for the NIC 8000 device.

Example 11-18 /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.8000

CCW_CHAN_IDS='0.0.8000 0.0.8001 0.0.8002'CCW_CHAN_MODE=''CCW_CHAN_NUM='3'LCS_LANCMD_TIMEOUT=''MODULE='qeth'MODULE_OPTIONS=''QETH_IPA_TAKEOVER='0'QETH_LAYER2_SUPPORT='1'QETH_OPTIONS=''SCRIPTDOWN='hwdown-ccw'SCRIPTUP='hwup-ccw'SCRIPTUP_ccw='hwup-ccw'SCRIPTUP_ccwgroup='hwup-qeth'STARTMODE='auto'

The network definition file for NIC device 8000 is shown in Example 11-19. Again that file is a copy of an existing ifcfg-qeth-bus-ccw-0.0.xxxx file, similar to the one that was created during system installation using a QDIO OSA device.

Example 11-19 /etc/sysconfig/network/ifcfg-qeth-bus-ccw-0.0.8000

BOOTPROTO='static'


BROADCAST=''ETHTOOL_OPTIONS=''IPADDR='192.168.1.60'LLADDR=''MTU=''NETMASK='255.255.255.0'NETWORK=''REMOTE_IPADDR=''STARTMODE='auto'USERCONTROL='no'PREFIXLEN=''

Creating permanent Layer 2 definitions for Red Hat Red Hat 5 has one location where both network- and hardware-related interface information is stored. This locations is fixed and will not change:

/etc/sysconfig/network-scripts

We created a configuration file for the new device with address x’8000’. Red Hat uses file names starting with ifcfg- concatenated with the Linux interface name. For example, OSA QDIO devices are called:

ifcfg-eth1

Red Hat puts hardware-related and network definitions in one configuration file.

On our Red Hat system we created the configuration file for the NIC 8000 device as shown in Example 11-20.

Example 11-20 /etc/sysconfig/network-scripts/ifcfg-eth1

# IBM QETHDEVICE=eth1VSWITCH=1OPTIONS="layer2=1"BOOTPROTO=noneIPADDR=192.168.1.61NETMASK=255.255.255.0NETTYPE=qethONBOOT=yesSUBCHANNELS=0.0.8000,0.0.8001,0.0.8002TYPE=EthernetUSERCTL=noIPV6INIT=noPEERDNS=yes

11.4 Configuring VLAN supportTo demonstrate Layer 2 functionality across the virtual switch and OSA ports, we extended 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.


Previously our configuration traversed the virtual switch fabric without the use of VLAN IDs. 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 guest systems and the z/OS

TCP/IP stacks

Figure 11-4 on page 168 illustrates our VSWITCH environment with VLANs.

Figure 11-4 Our VSWITCH environment with VLANs

To add VLAN capability to our VSWITCH environment, we took the following steps:

1. Defined VLAN capabilities for the virtual switch.

2. Granted the Linux guests access to the virtual switch with specific VLAN IDs.

3. Added VLAN functionality to the Linux guests.

4. Added VLAN support to the z/OS TCP/IP stacks

5. Configured the Ethernet switch ports to trunk mode for the OSA ports that interconnect the z/VM, Linux, z/OS environments, and the external Workstation at IP 192.168.3.2.

11.4.1 Defining VLAN capabilities to the virtual switchWhen configuring a virtual switch with VLAN capabilities, you can select whether the VSWITCH will provide either access mode or trunk mode. We configured our environment in

eth1

VLAN 981192.168.1.61

VLAN 982192.168.2.61

VLAN 980192.168.3.61

eth1

VLAN 981192.168.1.60

VLAN 982192.168.2.60

VLAN 980192.168.3.60

eth0eth0


L2SW1L2SW2

Ethernet Switch


VLAN 980 - 999

VLAN 980

192.168.3.2

CHPID 0B2D80-2D82 2D84-2D86

Port 0 Port 1

E200-E202 E204-E206

Port 0 Port 1

VTAM / TRL2E200-E202 E204-E206

z/OSV1R10

TCP/IPVLAN 980 / OSAE200I

192.168.3.65/24VLAN 981 / OSAE204I

192.168.1.65/24VLAN 982 / OSAE205I

192.168.2.65/24

E200-E202 E204-E206

CHPID 0A

eth1

VLAN 981192.168.1.61

VLAN 982192.168.2.61

VLAN 980192.168.3.61

VLAN 981192.168.1.61

VLAN 982192.168.2.61

VLAN 980192.168.3.61

eth1

VLAN 981192.168.1.60

VLAN 982192.168.2.60

VLAN 980192.168.3.60

VLAN 981192.168.1.60

VLAN 982192.168.2.60

VLAN 980192.168.3.60

eth0eth0


L2SW1L2SW2

Ethernet Switch


VLAN 980 - 999

VLAN 980

VLAN 980 - 999

VLAN 980

192.168.3.2

CHPID 0B2D80-2D82 2D84-2D86

Port 0 Port 1

E200-E202 E204-E206

Port 0 Port 1

VTAM / TRL2E200-E202 E204-E206

z/OSV1R10


192.168.3.65/24VLAN 981 / OSAE204I

192.168.1.65/24VLAN 982 / OSAE205I

192.168.2.65/24

E200-E202 E204-E206

CHPID 0A


trunk mode to show the Layer 2 and VLAN capabilities of the virtual switch in conjunction with the OSA port and Ethernet switch. For more information about VLAN support and access or trunk mode, refer to Chapter 10, “VLAN support” on page 131.

For assistance with the VLAN configuration process, refer to the flowchart shown in Figure 11-5.

Figure 11-5 Virtual switch: VLAN configuration

The VLAN ID and port type values used in the DEFINE VSWITCH command are inherited by the guest systems, when attaching to the virtual switch.

To add VLAN support to the virtual switch, include additional parameters on the DEFINE VSWITCH command. We configured our virtual switch as a trunk port with a default VLAN ID of 10 as shown in Example 11-21. For more information about VLAN standards and support, refer to Chapter 10, “VLAN support” on page 131.

Example 11-21 Defining the trunk port type

DEFINE VSWITCH L2SW1 RDEV E200 2D80 ETH VLAN 10 PORTT TRUNK

Another operand that can be specified when defining a VLAN-aware virtual switch is NATive. This keyword and value specifies the native VLAN ID to be associated with untagged frames received and transmitted by the virtual switch. If this option is omitted the default VLAN is used as the native VLAN ID. Usually, the same native VLAN ID as your real switch should be used. The default for most Ethernet switches is 1.

11.4.2 Authorizing Linux guests access to the virtual switch with VLAN IDsYou must update the access authorization for the Linux guests to include VLAN capabilities. With the SET VSWITCH command, you can authorize access for guests and change the

PorttypeTrunk

?

Define Virtual Switch

YES NO

Define Virtual Switch(Trunk Mode)

Define Virtual Switch

(Access Mode and default VLAN ID )

DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CONR * ETH VLAN 100 PORTT TRUNK PORT OSACHP0D OSACHP0E

DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CONR * ETH VLAN 100 PORT OSACHP0D OSACHP0E

Go to flowchart in:

Done

Authorize Guest access to

default Porttype & VLAN ID

......

SET VSWITCH VSWTCH1 GRA LNXSU1

Figure 11-6 on page 170


default values for a virtual switch defined as a trunk port. For assistance with the VLAN port type configuration options and granting access, refer to the flowchart shown in Figure 11-6.

Figure 11-6 Virtual switch - VLAN port type configuration options

For our environment, we revoked all access and then authorized each guest to have access to the virtual switch using the SET VSWITCH command (see Example 11-22). Notice the VLAN parameters and absence of the PORTTYPE parameter. The port type was determined in the VSWITCH definition (from Example 11-21).

Example 11-22 Authorizing the guests

SET VSWITCH L2SW1 GRA LNXSU10 VLAN 980-982SET VSWITCH L2SW1 GRA LNXRH5 VLAN 980-982

11.4.3 Adding VLANs to the guest systemsTo enable VLAN support on the Linux guests, changes must be made to the interface that represents the virtual switch. In our case, this is eth1. We applied an IP address of 0.0.0.0 to eth1 to eliminate any IP address conflicts, then we added the VLAN IDs with the corresponding IP address.

Virtual Switchdefined in

TRUNK Mode with VLAN ID

YES

Done

Authorize Guest access with

default Portype & VLAN ID

......

Prepare LINUXSetup

NOChange both

defaults?

NO

YES

Authorize Guest access with new

Porttype and VLAN ID

......

Done

Change VLAN ID

?

YES Authorize Guest access with new

VLAN ID.....

NO

Authorize Guest access with new

Porttype.....

Done

Prepare LINUXSetup

Done

SET VSWITCH VSWTCH1 GRA LNXSU1

SET VSWITCH VSWTCH1 GRA LNXSU1 PORTT ACCESS VLAN 200

SET VSWITCH VSWTCH1 GRA LNXSU1 PORTT ACCESS

SET VSWITCH VSWTCH1 GRA LNXSU1 VLAN 200

Guest inherits Virtual Switch

defaults?

Important: For the virtual switch to identify the correct VLAN and IP address allocated to the Linux guest, it is important to define eth’x’ with an IP address of 0.0.0.0 using the ifconfig eth’x’ 0.0.0.0 up command. Failure to do so results in the virtual switch incorrectly associating the VLAN ID with the eth’x’ interface IP address. By specifying an IP address of zero, the eth’x’ interface presents the appropriate VLAN interface IP address to the virtual switch.


Defining VLAN support for SUSE and Red HatPrevious steps describing how to configure and implement a virtual switch environment remain the same, except for the VLAN-specific values.

The VLAN configuration changes can be made dynamically depending on your circumstances. However, 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 configured our environment in trunk mode to show the Layer 2 and VLAN capabilities of the virtual switch in conjunction with the OSA ports and Ethernet switch. For more information about VLAN support and access mode and trunk mode, refer to Chapter 10, “VLAN support” on page 131.

For the shell scripts to define a VLAN interface, refer to Device Drivers, Features and Commands, SC33-8289. You can download it from:

http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26cdd03.pdf

The scripts work the same way in SUSE and Red Hat. The only exception is the interface name that is created. See Example 11-23 for the SUSE results and Example 11-24 for the Red Hat results.

Example 11-23 SUSE defining VLAN ID 980 on Interface eth1

linux-su10:/ # vconfig add eth1 980Added VLAN with VID == 990 to IF -:eth1:-linux-su10:/ # ifconfig vlan980 192.168.3.60 netmask 255.255.255.0

linux-su10:/ # ifconfig vlan980vlan980 Link encap:Ethernet HWaddr 02:00:00:00:00:04 inet addr:192.168.3.60 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::ff:fe00:4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:468 (468.0 b)

Example 11-24 Red Hat defining VLAN ID 980 on Interface eth1

[root@linrh5 ~]# vconfig add eth1 980Added VLAN with VID == 990 to IF -:eth1:-[root@linrh5 ~]# ifconfig eth1.980 192.168.3.61 netmask 255.255.255.0

[root@linrh5 ~]# ifconfig eth1.980eth1.980 Link encap:Ethernet HWaddr 02:00:00:00:00:06 inet addr:192.168.3.61 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::ff:fe00:6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:33 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0

Important: Ensure that your Linux guest system is at the appropriate kernel version. See 10.4, “VLAN support for Linux” on page 145, for details.




RX bytes:0 (0.0 b) TX bytes:8122 (7.9 KiB)

After defining a VLAN interface, for example VLAN 980, the name of the interface depends on the distribution. SUSE names the interface vlan980, while Red Hat names the interface eth1.980.

Permanent definitions for VLAN support - SUSE In order to make all the definitions from “Adding VLANs to the guest systems” on page 170 permanent, you need to code the information in the distribution-specific configuration member.

To create the VLAN definition member for the VLAN ID, copy one of the QDIO Ethernet definition files and name the new member ifcfg-vlan concatenated with the VLAN ID. Remove definitions from the file that relate to hardware, keeping only the statements that are network-related (see Example 11-25). Add your network definitions and the ETHERDEVICE=’interface name’ statement to the file. The ETHERDEVICE statement links the definition file to the actual network interface.

Example 11-25 SUSE member /etc/sysconfig/network/ifcfg-vlan980

ETHERDEVICE='eth1'BOOTPROTO='static'STARTMODE='auto'IPADDR='192.168.2.60'NETMASK='255.255.255.0'NETWORK='192.168.2.0'BROADCAST='192.168.2.255'PREFIXLEN=''

Permanent definitions for VLAN support - Red Hat In order to make all the definitions from “Adding VLANs to the guest systems” on page 170 permanent, you need to code the information in the distribution-specific configuration member.

To create the VLAN definition member for the VLAN ID, copy one of the QDIO Ethernet definition files and name the new member ifcfg-ethx. concatenated with the VLAN ID. Remove definitions from the file that relate to hardware, keeping only the statements that are network related (Example 11-26). Add your network definitions, the DEVICE=’interface name’ statement, and VLAN=yes to the file. The DEVICE statement links this definition file to the actual network interface.

Example 11-26 Red Hat member /etc/sysconfig/network-scripts/ifcfg-eth1.980

# Please read /usr/share/doc/initscripts-*/sysconfig.txt# for the documentation of these parameters.TYPE=EthernetDEVICE=eth1.980VLAN=yesBOOTPROTO=noneNETMASK=255.255.255.0IPADDR=192.168.3.61ONBOOT=yesUSERCTL=noIPV6INIT=noPEERDNS=yes


NETTYPE=qeth

11.4.4 Adding VLAN support to the z/OS TCP/IP stacksTo enable VLAN support for the z/OS TCP/IP stacks, we add the VLAN ID parameter to the LINK statements in the PROFILE member for the OSA port. Example 11-27 shows the configuration that we used to define the VLANs in the z/OS environment.

Example 11-27 z/OS TCPI/IP VLAN configuration

z/OS LPAR (SC81):

INTERFACE OSAE203I DEFINE IPAQENET PORTNAME OSAE200 IPADDR 192.168.3.65/24 MTU 1492 VLANID 980 VMAC ROUTEALL ;INTERFACE OSAE204I

DEFINE IPAQENET PORTNAME OSAE204

IPADDR 192.168.1.65/24 MTU 1492 VLANID 981 VMAC ROUTEALL ; INTERFACE OSAE205I DEFINE IPAQENET PORTNAME OSAE204

IPADDR 192.168.2.65/24 MTU 1492 VLANID 982 VMAC ROUTEALL

11.4.5 Configuring trunk mode in the Ethernet switch for the OSA connectionsIn the Ethernet switch, we defined trunk mode for port 2/7, which was directly connected to the OSA port (CHPID 0D) on the z/VM LPAR (Example 11-28). Port 1/2 was connected to the OSA port (CHPID 0A) on the z/OS LPAR, which was previously set to trunk mode.

Example 11-28 Ethernet switch configuration

SET TRUNK 2/7 ON DOT1Q 1-2005,1025-4094

11.4.6 Verifying the VLANAfter completing the configuration tasks, we verified the VLAN environment.

Note: In a production environment, multiple OSA ports should be connected to at least two different Ethernet switches to avoid single points of failure.


We checked the virtual switch to see the list of authorized user IDs. In Example 11-29, notice the VLAN-specific information that is displayed.

Example 11-29 Authorized user IDs for virtual switch

QUERY VSWITCH L2SW1 ACC VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Enabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Authorized userids: LNXRH5 Porttype: Trunk VLAN: 0980-0982 LNXSU10 Porttype: Trunk VLAN: 0980-0982 SYSTEM Porttype: Trunk VLAN: 0010 RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP Ready; T=0.01/0.01 14:35:54

Next we displayed the virtual switch to verify that our new VLAN information was defined correctly (see Example 11-30). Notice the VLAN and the Portype information. Toward the bottom of the display under the Adapter Owner sections, the Linux guests now reflect a port type of Trunk.

Example 11-30 Virtual switch display with VLAN capability

QUERY VSWITCH L2SW1 DET VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Enabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 VSWITCH Connection: RX Packets: 21 Discarded: 0 Errors: 0 TX Packets: 43 Discarded: 0 Errors: 0 RX Bytes: 1750 TX Bytes: 6385 Device: E200 Unit: 000 Role: DATA vPort: 0001 Index: 0001 Unicast IP Addresses: 192.168.3.2 MAC: 00-02-55-E4-5E-12 Remote 192.168.3.64 MAC: 02-00-12-34-56-78 Remote RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP Adapter Connections: Adapter Owner: LNXRH5 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 56 Discarded: 0 Errors: 0 TX Packets: 45 Discarded: 79 Errors: 0 RX Bytes: 7883 TX Bytes: 6533 Device: 8002 Unit: 002 Role: DATA vPort: 0066 Index: 0066


VLAN: 0980 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-06 IP: 192.168.3.61 Multicast MAC Addresses: 01-00-5E-00-00-01 01-00-5E-00-00-FB 33-33-00-00-00-01 33-33-00-00-00-FB 33-33-FF-00-00-06 Adapter Owner: LNXSU10 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 278 Discarded: 76 Errors: 0 TX Packets: 12 Discarded: 199 Errors: 0 RX Bytes: 54457 TX Bytes: 944 Device: 8002 Unit: 002 Role: DATA vPort: 0065 Index: 0065 VLAN: 0980 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-04 IP: 192.168.3.60 Multicast MAC Addresses: 01-00-5E-00-00-01 33-33-00-00-00-01 33-33-FF-00-00-04 Ready; T=0.01/0.01 14:24:02

Notice two IP addresses with the attribute Remote. One is the z/OS system, the other is the workstation that is connected to the external switch over an access port dedicated to VLAN ID 980.

We then looked at the interface configuration for LNXSU10 and LNXRH5, respectively. The changes in these displays are the absence of IP addresses on the eth1 interface. Only the VLAN interfaces (sub-interfaces) are associated with a valid IP address. The VLAN interfaces (IDs) use the real interface (eth1) to communicate with the LAN via the virtual switch. During this process, the eth1 interface adopts the IP address of the VLAN interface to establish connectivity to the virtual switch and beyond.

We also used OSA/SF to query the OSA CHPID 0A. Example 11-31 shows information about the VLAN IDs and the registered MAC addresses.

Example 11-31 OSA/SF query of CHPID 0A

************************************************************************ *** OSA address table for CHPID 0A *** ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************

00(E200) MPC 01 No4 No6 z/VM0001 (QDIO data) SIU ALL VLAN 980 VLAN 981 VLAN 982

020000000004 (VMAC) 020000000006 (VMAC)


01005E000001 (Group MAC) 01005E0000FB (Group MAC)

333300000001 (Group MAC) 3333000000FB (Group MAC)3333FF000004 (Group MAC)

3333FF000006 (Group MAC)

The configurations were displayed on the Linux guests with the ifconfig command. Example 11-32 shows the results for LNXSU10.

Example 11-32 Interface display for LNXSU10

ifconfig.......

eth1 Link encap:Ethernet HWaddr 02:00:00:00:00:04 inet6 addr: fe80::ff:fe00:4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:290 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:52373 (51.1 Kb) TX bytes:2308 (2.2 Kb)....

vlan980 Link encap:Ethernet HWaddr 02:00:00:00:00:04 inet addr:192.168.3.60 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::ff:fe00:4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:284 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:51981 (50.7 Kb) TX bytes:1364 (1.3 Kb)

We then issued PING commands from LNXSU10 and LNXRH5 to the IP addresses assigned to the appropriate VLAN IDs for the z/OS LPAR and workstation. In all cases, we received a positive response indicating a working infrastructure between the systems.

Lastly, we tried to ping the IP addresses that were not defined to the individual VLANs and vice versa. As expected, they were unsuccessful, verifying the intended isolation of the environment.

11.5 Enabling port isolationPort isolation prevents guest systems from sending data to other guests on the same virtual switch. Packets that are destined for another guest port on the VSWITCH are discarded. In addition, no direct LPAR-to-LPAR communication via a shared OSA port is permitted with guest ports on the VSWITCH. This is a very important security option; it forces all IP traffic to pass through a connected OSA port to the external LAN environment. After reaching an external Ethernet switch, packet filtering or other security-related actions can take place.


Port isolation works with a VSWITCH that is either in IP mode (Layer 3) or Ethernet mode (Layer 2). If a VSWITCH has isolation set on, guest systems that have a NIC connected to it cannot exchange data with each other. That is also true for two or more VSWITCHs with isolation set on that are sharing the same OSA port or ports.

In this section, we verified that the following occurs when VSWITCH port isolation is set on:

1. Packets between guest systems attached to the VSWITCH are dropped.

2. Packets destined for the VSWITCH guest ports from any LPAR sharing the connected OSA ports are dropped.

3. Packets from the VSWITCH destined for any LPAR sharing the connected OSA ports are dropped.

Figure 11-7 depicts the environment used to verify port isolation. Our VSWITCH is VLAN-aware only because we specified VLANs in our TCP/IP stacks, but this is not a prerequisite. We also added IP routing to our external Ethernet switch to allow connectivity between the VLANs.

Figure 11-7 Our VSWITCH environment with port isolation

Important: To provide support for VSWITCH port isolation, z/VM APAR VM64463 and TCP/IP APAR PK67610, along with updated OSA microcode were required for our environment. We recommend checking the appropriate Preventive Service Planning bucket for your environment.

eth1

VLAN 981192.168.1.61

VLAN 982192.168.2.61

VLAN 980192.168.3.61

eth1

VLAN 981192.168.1.60

VLAN 982192.168.2.60

VLAN 980192.168.3.60

eth0eth0


L2SW1L2SW2

Ethernet Switch


VLAN 980 - 999

VLAN 980

192.168.3.2

VTAM / TRL2E200-E202 E204-E206

z/OSV1R10


192.168.3.65/24VLAN 981 / OSAE204I

192.168.1.65/24VLAN 982 / OSAE205I

192.168.2.65/24

E200-E202 E204-E206

Port 0 Port 1

E200-E202 E204-E206

CHPID 0A

eth1

VLAN 981192.168.1.61

VLAN 982192.168.2.61

VLAN 980192.168.3.61

VLAN 981192.168.1.61

VLAN 982192.168.2.61

VLAN 980192.168.3.61

eth1

VLAN 981192.168.1.60

VLAN 982192.168.2.60

VLAN 980192.168.3.60

VLAN 981192.168.1.60

VLAN 982192.168.2.60

VLAN 980192.168.3.60

eth0eth0


L2SW1L2SW2

Ethernet Switch


VLAN 980 - 999

VLAN 980

VLAN 980 - 999

VLAN 980

192.168.3.2

VTAM / TRL2E200-E202 E204-E206

z/OSV1R10


192.168.3.65/24VLAN 981 / OSAE204I

192.168.1.65/24VLAN 982 / OSAE205I

192.168.2.65/24

E200-E202 E204-E206

Port 0 Port 1

E200-E202 E204-E206

CHPID 0A


All the definitions for this environment are described in “Configuring a Layer 2 VSWITCH” on page 158 and “Configuring VLAN support” on page 167.

11.5.1 Port isolation off - systems sharing the same VSWITCH and OSAExample 11-33 shows a query of virtual switch L2SW1 with port isolation set off (the default). LNXSU10 and LNXRH5 were sharing L2SW1, which was connected to an OSA port. The OSA port was shared by a z/OS LPAR as well. A workstation was connected to an external Ethernet switch.

The SET VSWITCH L2SW1 ISOL OFF command can be used to disable port isolation.

Example 11-33 Query L2SW1 - VSWITCH with port isolation off

QUERY VSWITCH L2SW1 DET VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Enabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 VSWITCH Connection: RX Packets: 123 Discarded: 0 Errors: 0 TX Packets: 301 Discarded: 0 Errors: 0 RX Bytes: 15428 TX Bytes: 41114 Device: E200 Unit: 000 Role: DATA vPort: 0001 Index: 0001 Unicast IP Addresses: 192.168.1.65 MAC: 02-00-02-B7-A1-65 Remote 192.168.2.65 MAC: 02-00-01-B7-A1-65 Remote 192.168.3.65 MAC: 02-00-03-B7-A1-65 Remote

192.168.3.2 MAC: 00-02-55-E4-5E-12 Remote RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP Adapter Connections: Adapter Owner: LNXRH5 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 387 Discarded: 0 Errors: 0 TX Packets: 218 Discarded: 66 Errors: 0 RX Bytes: 37217 TX Bytes: 32536 Device: 8002 Unit: 002 Role: DATA vPort: 0067 Index: 0067 VLAN: 0980 0981 0982 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-06 Multicast MAC Addresses: 01-00-5E-00-00-01 01-00-5E-00-00-FB 33-33-00-00-00-01 33-33-00-00-00-FB 33-33-FF-00-00-06 Adapter Owner: LNXSU10 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 436 Discarded: 0 Errors: 0 TX Packets: 131 Discarded: 74 Errors: 0


RX Bytes: 43121 TX Bytes: 13234 Device: 8002 Unit: 002 Role: DATA vPort: 0066 Index: 0066 VLAN: 0980 0981 0982 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-04 Multicast MAC Addresses: 01-00-5E-00-00-01 01-00-5E-00-01-16 01-00-5E-7F-FF-FD 33-33-00-00-00-01 33-33-FF-00-00-04

We used the PING command to verify connectivity between the workstation, the z/OS LPAR, LNXSU10, and LNXRH5 (via the virtual switch).

All pings were successful, as expected. Example 11-33 on page 178 also shows the IP and MAC addresses of the z/OS LPAR and workstation, marked as Remote.

11.5.2 Port isolation on - systems sharing the same VSWITCH and OSAExample 11-34 shows a query of virtual switch L2SW1 with port isolation set on. LNXSU10 and LNXRH5 were sharing L2SW1, which was connected to an OSA port. The OSA port was shared by a z/OS LPAR as well. A workstation was connected to an external Ethernet switch.

We used the SET VSWITCH L2SW1 ISOL ON command to enable port isolation on L2SW1.

Example 11-34 Query L2SW1 - VSWITCH with port isolation on

QUERY VSWITCH L2SW1 DET VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Enabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: ON RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 VSWITCH Connection: RX Packets: 145 Discarded: 0 Errors: 0 TX Packets: 485 Discarded: 0 Errors: 0 RX Bytes: 18094 TX Bytes: 51186 Device: E200 Unit: 000 Role: DATA vPort: 0001 Index: 0001 Unicast IP Addresses: 192.168.3.2 MAC: 00-02-55-E4-5E-12 Remote RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP Adapter Connections: Adapter Owner: LNXRH5 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 409 Discarded: 0 Errors: 0 TX Packets: 372 Discarded: 66 Errors: 0 RX Bytes: 39697 TX Bytes: 39956 Device: 8002 Unit: 002 Role: DATA vPort: 0067 Index: 0067 VLAN: 0980 0981 0982 Options: Ethernet Broadcast


Unicast MAC Addresses: 02-00-00-00-00-06 Multicast MAC Addresses: 01-00-5E-00-00-01 01-00-5E-00-00-FB 33-33-00-00-00-01 33-33-00-00-00-FB 33-33-FF-00-00-06 Adapter Owner: LNXSU10 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 466 Discarded: 0 Errors: 0 TX Packets: 161 Discarded: 74 Errors: 0 RX Bytes: 46859 TX Bytes: 15886 Device: 8002 Unit: 002 Role: DATA vPort: 0066 Index: 0066 VLAN: 0980 0981 0982 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-04 Multicast MAC Addresses: 01-00-5E-00-00-01 01-00-5E-00-01-16 01-00-5E-7F-FF-FD 33-33-00-00-00-01 33-33-FF-00-00-04

We used the PING command to test connectivity between the workstation, the z/OS LPAR, LNXSU10, and LNXRH5 via the virtual switch.

As anticipated, all pings failed except to the workstation (192.168.3.2), which was connected to the external Ethernet switch. From the workstation, we could ping LNXSU10 and LNXRH5 via the virtual switch. Note that Example 11-34 shows only the IP and MAC addresses of the workstation marked as Remote. This verified complete isolation within the VSWITCH and shared OSA port.

Example 11-35 is an excerpt of the OAT after port isolation was set on. We used OSA/SF to query OSA CHPIDs 0A and verify that the shared OSA port was also isolated.

Example 11-35 OSA/SF query OSA CHPIDs 0A - VSWITCH with port isolation on

************************************************************************ *** OSA address table for CHPID 0A *** ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************ 00(E200) MPC 0 No4 No6 z/VM0001 (QDIO data) Isolated SIU ALL VLAN 980 VLAN 981 VLAN 982 020000000004 (VMAC) 020000000006 (VMAC) 01005E000001 (Group MAC) 01005E0000FB (Group MAC) 01005E000116 (Group MAC)


01005E7FFFFD (Group MAC) 333300000001 (Group MAC) 3333000000FB (Group MAC) 3333000000FB (Group MAC) 3333FF000004 (Group MAC) 02(E202)* MPC n/a z/VM0001 (QDIO control) SIU ALL 03(E203) N/A N/A CSS 04(E204) N/A N/A CSS 05(E205) N/A N/A CSS 06(E206) N/A N/A CSS 07(E207) N/A N/A CSS 08(E208) N/A N/A CSS 09(E209) N/A N/A CSS 0A(E20A) N/A N/A CSS 0B(E20B) N/A N/A CSS

11.6 Configuring link aggregation supportThe z/VM virtual switch supports Link Aggregation Group (LAG) defined by IEEE 802.3ad. For the virtual switch, LAG is the grouping of multiple OSA ports to appear as a single logical link.

Link aggregation in the VSWITCH only works in ETHERNET mode, and has the following requirements:

� All OSA ports in the LAG must be connected to the same external Ethernet switch.

� The external Ethernet switch must support the IEEE 802.3ad standard.

� All ports must run in full duplex mode and use the same speed setting.

� For single port per CHPID (OSA features), all defined devices must be inactive on all LPARs; this also includes the z/VM LPAR where the VSWITCH is running.

� For multi-port per CHPID (OSA- features), if only one port is used for link aggregation, then the other ports can be used for other VSWITCHs or TCP/IP stacks.

11.6.1 Defining link aggregationFor our link aggregation environment, we reused virtual switch L2SW1 defined in Ethernet mode (Layer 2), with PORTType TRUNK and VLAN 10 (see Example 11-36).

Example 11-36 VSWITCH L2SW1

QUERY VSWITCH L2SW1 DET VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 0 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Disabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-10 State: Defined IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Ready; T=0.01/0.01 09:17:20

LNXSU10 and LNXRH5 were connected to the switch using trunk ports with VLAN ID 980.


Figure 11-8 depicts our VSWITCH environment with link aggregation.

Figure 11-8 Our VSWITCH environment with link aggregation

Setting up the port groupIf all prerequisites are met the link aggregation group can be defined with the following Class B SET PORT GROUP command:

SET PORT GROUP ITSO JOIN E200.P01 2D80.P01

Note that up to eight OSA device addresses can be added to the group. We defined two device addresses with port numbers E200.P01 and 2D80.P01.

Attaching the port group to the VSWITCHWe then connected our VSWITCH (L2SW1) to the PORT GROUP ITSO with the SET VSWITCH command:

SET VSWITCH L2SW1 GROUP ITSO

As we were adding OSA ports to the group we got the following message:

The device does not have the required attributes.

This was because one of the ports did not have the same speed and duplex settings as the other ports.

To determine the cause, we queried the ports using OSF/SF. We then compared the output of all ports.

The reason why those settings were different was because of a bad cable, which forced the port to negotiate a lower speed and half duplex.

OSA 2D80.P01OSA E200.P01

z/VMV5R4

LNXRH5LNXSU10

Port 1/16

Port 1/14

Port 2Port 1

Load Balancer Aggregator/Multiplexor

LACP

LACP

VSWITCH

EthernetSwitch

VSWITCHControllerDTCVSW2

VSWITCHControllerDTCVSW1NIC

Port

NIC

Port

OSA 2D80.P01OSA E200.P01

z/VMV5R4

LNXRH5LNXSU10

Port 1/16

Port 1/14

Port 2Port 1

Load Balancer Aggregator/Multiplexor

LACP

LACP

VSWITCH

EthernetSwitch

VSWITCHControllerDTCVSW2

VSWITCHControllerDTCVSW1NIC

Port

NIC

Port

NIC

Port

NIC

Port


11.6.2 Setting up the external Ethernet switchIn our external Ethernet switch we had to configure the ports (interfaces) and assign them to a channel-port number, as shown in Example 11-37 and Example 11-38 on page 183.

Example 11-37 Ethernet switch interface configuration

vm6509#configure terminalvm6509(config)#interface range gigabitEthernet 1/14vm6509(config-if-range)#no ip addressvm6509(config-if-range)#channel-protocol lacpvm6509(config-if-range)#channel-group 10 mode activeCreating a port-channel interface Port-channel 10vm6509(config-if-range)#exit

vm6509#configure terminalvm6509(config)#interface range gigabitEthernet 1/16vm6509(config-if-range)#no ip addressvm6509(config-if-range)#channel-protocol lacpvm6509(config-if-range)#channel-group 10 mode activeCreating a port-channel interface Port-channel 10vm6509(config-if-range)#exit

Example 11-38 Ethernet switch channel-port configuration

vm6509(config)#interface port-channel 10vm6509(config-if)#switchport trunk encapsulation dot1qvm6509(config-if)#switchport mode trunkvm6509(config-if)#no shutdownvm6509(config-if)#end

11.6.3 Verifying the configurationTo verify our link aggregation environment we issued PING commands from LNXSU10 (with IP address 192.168.3.60) to the following hosts:

� The z/VM TCP/IP stack with IP address 192.168.3.6 is using a port not associated to the ITSO port group.

� A workstation connected to a port on the Ethernet switch with IP address 192.168.3.2.

� LNXRH5 with IP address 192.168.3.61 (connected to L2SW1).

After issuing the PING commands, we did a query on the port group. All IP addresses pinged that are not connected to L2SW1 show up as type remote with their MAC address (see Example 11-39). The connections of the VSWITCH-attached systems are handled inside VSWITCH. The output from the QUERY PORT GROUP command includes information about the port group (ITSO) to which it is connected.

Example 11-39 QUERY PORT GROUP ITSO

QUERY PORT GROUP ITSO Group: ITSO Active LACP Mode: Active VSWITCH SYSTEM L2SW1 Interval: 300 ifIndex: 64 RDEV: 2D80.P01 VDEV: 2D80 Controller: DTCVSW1 VSWITCH Connection:


MAC address: 02-00-00-00-00-05 RX Packets: 21 Discarded: 4 Errors: 0 TX Packets: 162 Discarded: 0 Errors: 0 RX Bytes: 2494 TX Bytes: 21782 Device: 2D80 Unit: 000 Role: DATA vPort: 0002 Index: 0002 Unicast IP Addresses: 192.168.3.2 MAC: 00-02-55-E4-5E-12 Remote RDEV: E200.P01 VDEV: E200 Controller: DTCVSW2 VSWITCH Connection: MAC address: 02-00-00-00-00-04 RX Packets: 24 Discarded: 0 Errors: 0 TX Packets: 91 Discarded: 0 Errors: 0 RX Bytes: 2528 TX Bytes: 10094 Device: E200 Unit: 000 Role: DATA vPort: 0001 Index: 0001 Unicast IP Addresses: 192.168.3.6 MAC: 02-00-00-00-00-09 Remote Ready; T=0.01/0.01 11:15:48

Using the detail option on the QUERY VSWITCH command you will get additional information that could be helpful for problem determination purposes (see Example 11-40).

Example 11-40 Query VSWITCH L2SW1 detail

QUERY VSWITCH L2SW1 DET VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Enabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-10 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Group: ITSO Active LACP Mode: Active RDEV: 2D80.P01 VDEV: 2D80 Controller: DTCVSW1 VSWITCH Connection: MAC address: 02-00-00-00-00-05 RX Packets: 21 Discarded: 4 Errors: 0 TX Packets: 223 Discarded: 0 Errors: 0 RX Bytes: 2494 TX Bytes: 31542 Device: 2D80 Unit: 000 Role: DATA vPort: 0002 Index: 0002 RDEV: E200.P01 VDEV: E200 Controller: DTCVSW2 VSWITCH Connection: MAC address: 02-00-00-00-00-04 RX Packets: 24 Discarded: 0 Errors: 0 TX Packets: 154 Discarded: 0 Errors: 0 RX Bytes: 2528 TX Bytes: 19946 Device: E200 Unit: 000 Role: DATA vPort: 0001 Index: 0001 Adapter Connections: Adapter Owner: LNXRH5 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 123 Discarded: 0 Errors: 0 TX Packets: 233 Discarded: 20 Errors: 0 RX Bytes: 11828 TX Bytes: 36710 Device: 8002 Unit: 002 Role: DATA vPort: 0069 Index: 0069 VLAN: 0980 0981 0982 0983 Options: Ethernet Broadcast


Unicast MAC Addresses: 02-00-00-00-00-0E IP: 192.168.3.61 Multicast MAC Addresses: ...

Adapter Owner: LNXSU10 NIC: 8000.P00 Name: UNASSIGNED Porttype: Trunk RX Packets: 155 Discarded: 0 Errors: 0 TX Packets: 99 Discarded: 36 Errors: 0 RX Bytes: 13898 TX Bytes: 7202 Device: 8002 Unit: 002 Role: DATA vPort: 0068 Index: 0068 VLAN: 0980 0981 0982 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-0B IP: 192.168.3.60 Multicast MAC Addresses: ...

We also used OSA/SF to query the OSA CHPID. Example 11-41 shows information about the VLAN IDs and the registered MAC addresses.

Example 11-41 OSA/SF query of CHPID 0A

************************************************************************ *** Start of OSA address table for CHPID 0A *** ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************ 00(E200) MPC 01 No4 No6 z/VM0001 (QDIO data) SIU ALL VLAN 980 VLAN 981 VLAN 982 VLAN 983 020000000004 (VMAC) 02000000000B (VMAC) 02000000000E (VMAC) 020000000010 (VMAC) 01005E000001 (Group MAC) 01005E0000FB (Group MAC) 01005E000116 (Group MAC) 01005E7FFFFD (Group MAC) 0180C2000002 (Group MAC) 333300000001 (Group MAC)


Appendix A. OSA features

This appendix lists the OSA-Express3, OSA-Express2, and OSA-Express features that are available on the System z10 and System z9 servers.

A


OSA feature descriptionsTable A-1 lists the OSA-Express3, OSA-Express2 and OSA-Express features supported on System z servers. The OSA-Express3 LAN adapters provide increased throughput, delivers double port density per card, and has reduced latency and overhead on the network traffic compared to the OSA-Express2 adapters. Details for each feature that is supported on System z10 and System z9 servers are in the subsequent sections.

Table A-1 System z server support for OSA-Express

Feature name Feature code

Connector type

Cable type Maximumunrepeateddistancea

Server

OSA-ExpressGbE LX

1364 LC Duplex SM 9 µm 5 km z9 EC, z9 BCb

MCPc 550 m (500)

OSA-Express GbE LX

2364 SC Duplex SM 9 µm 5 km z9 EC, z9 BCb

MCPc 550 m (500)

OSA-Express GbE SX

1365 LC Duplex MM 62.5 µm 220 m (166)275 m (200)

z9 EC, z9 BCb

MM 50 µm 550 m (500)

OSA-Express GbE SX

2365 SC Duplex MM 62.5 µm 220 m (166)275 m (200)

z9 EC, z9 BCb

MM 50 µm 550 m (500)

OSA-Express 1000BASE-T

1366 RJ 45 UTP Cat5 100 m z9 EC, z9 BCb

OSA-Express3 GbE LX

3362 LC Duplex 9 µm 5 km z10 EC, z10 BC

MCPc 550 m (500)

OSA-Express3 GbE SX

3363 LC Duplex MM 62.5 µm 220 m (166)275 m (200)

z10 EC, z10 BC

MM 50 µm 550 m (500)

OSA-Express2GbE LX

3364 LC Duplex SM 9 µm 5 km z10 EC, z10 BC z9 EC, z9 BC

MCPc 550 m (500)

OSA-Express2GbE SX

3365 LC Duplex MM 62.5 µm 220 m (166)275 m (200)

z10 EC, z10 BC z9 EC, z9 BC

MM 50 µm 550 m (500)


3366 RJ 45 UTP Cat5 100 m z10 EC, z10 BC z9 EC, z9 BC


3367 RJ 45 UTP Cat5 100 m z10 EC, z10 BC

OSA-Express210 GbE LR

3368 SC Duplex SM 9 µm 10 km z10 EC, z10 BCb, z9 EC, z9 BC

OSA-Express3-2P 1000BASE-T

3369 RJ 45 UTP Cat5 100 m z10 BC


The transmission medium and cabling requirements for the OSA ports depend on the OSA feature, OSA port type, and LAN. Acquiring cables and other connectivity items is the customer’s responsibility.

OSA-Express3 10 Gigabit Ethernet Long Reach (10 GbE LR) featureFeature code 3370 is exclusive to the z10 servers and occupies one slot in the I/O cage. It has two ports that connect to a 10 Gbps Ethernet LAN via a 9 micron single mode fiber optic cable terminated with an LC Duplex connector and supports an unrepeated maximum distance of 10 km (6.2 miles).

The LC Duplex small form factor connector is a deviation from the SC Duplex connector used for the OSA-Express2 10 GbE LR feature.

The OSA-Express3 10 GbE LR feature does not support auto-negotiation to any other speed and runs in full duplex mode only. OSA-Express3 10 GbE LR supports 64B/66B encoding, whereas GbE supports 8B/10 encoding, making auto-negotiation to any other speed impossible.

The two ports of the OSA Express3 10 GbE LR feature have two CHPIDs assigned and must be defined as type OSD. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.

The following Ethernet standards are applicable for this feature:

10GBASE-LR (standard transmission scheme)

– IEEE 802.3ae– IEEE 802.1q– IEEE 802.3x - flow control– DIX Version 2

OSA-Express3 10 Gigabit Ethernet Short Reach (10 GbE SR) featureFeature code 3371 is exclusive to the z10 servers and occupies one slot in the I/O cage. It has two ports that connect to a 10 Gbps Ethernet LAN via a 62.5 micron or 50 micron multimode fiber optic cable terminated with an LC Duplex connector. The maximum supported unrepeated distance is 33 meters (108 feet) on a 62.5 micron multimode (200

OSA-Express310 GbE LR

3370 LC Duplex SM 9 µm 10 km z10 EC, z10 BC

OSA-Express3 10GbE SR

3371 LC Duplex MM 62.5 µm 33 m (200) z10 EC, z10 BC

MM 50 µm 300 m (2000)82 m (500)

OSA-Express3-2P GbE SX

3373 LC Duplex MM 62.5 µm 220 m (166)275 m (200)

z10 BC

MM 50 µm 550 m (500)

a. Minimum fiber bandwidth in MHz/km for multimode fiber optic links are included in parentheses where applicable.

b. Carried forward onlyc. Mode Conditioning Patch (MCP) cables enables the 1 Gbps single mode features to connect

to multimode fiber.

Note: DIX V2 and IEEE 802.3 frames can coexist on the same network; however, clients or servers not using the same protocol will not be able to communicate with each other.

Appendix A. OSA features 189

MHz) fiber optic cable, 82 meters (269 feet) on a 50 micron multimode (500 MHz) fiber optic cable, and 300 meters (984 feet) on a 50 micron multimode (2000 MHz) fiber optic cable.

The OSA-Express3 10 GbE SR feature does not support auto-negotiation to any other speed and runs in full duplex mode only. OSA-Express3 10 GbE LR supports 64B/66B encoding, whereas GbE supports 8B/10 encoding, making auto-negotiation to any other speed impossible.

The two ports of the OSA Express3 10 GbE SR feature have two CHPIDs assigned and must be defined as type OSD. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.


10GBASE-SR (standard transmission scheme)


OSA-Express3 Gigabit Ethernet long wavelength (GbE LX) featureFeature code 3362 is exclusive to the z10 servers and occupies one slot in the I/O cage. It has four ports that connect to a 1 Gbps Ethernet LAN via a 9 micron single mode fiber optic cable terminated with an LC Duplex connector, supporting an unrepeated maximum distance of 5 km (3.1 miles). Multimode (62.5 or 50 micron) fiber optic cable can be used with these features. The use of these multimode cable types requires a mode conditioning patch (MCP) cable at each end of the fiber optic link. Use of the single mode to multimode MCP cables reduces the supported distance of the link to a maximum of 550 meters (1084 feet).

The four ports of the OSA-Express3 GbE LX feature have two CHPIDs assigned, so two corresponding ports share one CHPID number. The use of both ports on a two-port CHPID, requires support by the operating system.

The OSA-Express3 GbE LX feature does not support auto-negotiation to any other speed and runs in full duplex mode only.

Each OSA-Express3 GbE LX port can be defined as CHPID type OSD or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.


1000BASE-LX (standard transmission scheme)

– IEEE 802.3ac– IEEE 802.1q– IEEE 802.3x– IEEE 802.3z– DIX Version 2

OSA-Express3 Gigabit Ethernet short wavelength (GbE SX) featureFeature code 3363 is exclusive to the z10 servers and occupies one slot in the I/O cage. It has four 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 four ports of the OSA-Express3 GbE SX feature have two CHPIDs assigned, so two corresponding ports share one CHPID number. The use of both ports on a two-port CHPID, requires support by the operating system.

The OSA-Express2 GbE SX feature does not support auto-negotiation to any other speed and runs in full duplex mode only.

Each OSA-Express2 GbE SX port can be defined as CHPID type OSD or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.


1000BASE-SX (standard transmission scheme)


OSA-Express3-2P Gigabit Ethernet short wavelength (GbE SX) featureFeature code 3373 is exclusive to the z10 BC server and occupies one slot in the I/O drawer. It has two 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 two ports of the OSA Express3-2P GbE SX feature have one CHPIDs assigned, so both ports share one CHPID number. The use of both ports on a two-port CHPID, requires support by the operating system.

The OSA-Express3-2P GbE SX feature does not support auto-negotiation to any other speed and runs in full duplex mode only.

Each OSA-Express3-2P GbE SX port can be defined as CHPID type OSD or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.




OSA-Express3 1000BASE-T Ethernet featureFeature code 3367 is exclusive to the z10 servers and occupies one slot in the I/O cage. It has four 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 four ports of the OSA Express3 1000BASE-T feature have two CHPIDs assigned, so two corresponding ports share one CHPID number. The use of both ports on a two-port CHPID, requires support by the operating system.


The OSA-Express3 1000BASE-T Ethernet feature supports auto-negotiation when attached to an Ethernet router or switch. If you allow the LAN speed and duplex mode to default to auto-negotiation, the OSA port and the attached router or switch auto-negotiate 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 router or switch does not support auto-negotiation, the OSA 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 of the following settings for the OSA-Express3 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 auto-negotiate, the OSA port will attempt 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 port will not connect.

LAN speed and duplex mode can be set explicitly, using OSA/SF or the OSA Advanced Facilities function of the hardware management console (HMC). The explicit settings will override the OSA feature port’s ability to auto-negotiate with its attached Ethernet switch.

Each OSA-Express3 1000BASE-T port can be defined as CHPID type OSD, OSE, OSC, or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.


� 10BASE-T (standard transmission scheme)

– IEEE 802.2– IEEE 802.3– ISO/IEC 8802-3– DIX Version 2

� 100BASE-TX (standard transmission scheme)

– IEEE 802.3u


– IEEE 802.1p– IEEE 802.1q– IEEE 802.3ab– IEEE 802.3ac– IEEE 802.3u– IEEE 802.3x

OSA-Express3-2P 1000BASE-T Ethernet feature

Feature code 3369 is exclusive to the System z10 BC server and occupies one slot in the I/O drawer. It has two ports that connect to a 1000 Mbps (1 Gbps), 100 Mbps, or 10 Mbps

Note: If CHPID type OSC is defined, only one of the two corresponding physical ports (port 0) can be used for OSA-ICC.


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 two ports of the OSA Express3-2P 1000BASE-T feature have one CHPIDs assigned, so the two corresponding ports share one CHPID number. The use of both ports on a two-port CHPID, requires support by the operating system.

The OSA-Express3-2P 1000BASE-T feature supports auto-negotiation when attached to an Ethernet router or switch. If you allow the LAN speed and duplex mode to default to auto-negotiation, the OSA port and the attached router or switch auto-negotiate 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 router or switch does not support auto-negotiation, the OSA 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 of the following settings for the OSA-Express3-2P 1000BASE-T feature port:



LAN speed and duplex mode can be set explicitly, using OSA/SF or the OSA Advanced Facilities function of the hardware management console (HMC). The explicit settings will override the OSA-Express3-2p 1000BASE-T feature port’s ability to auto-negotiate with its attached Ethernet switch.

Each OSA-Express3-2P 1000BASE-T port can be defined as CHPID type OSD, OSE, OSC, or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.





– IEEE 802.3u


– IEEE 802.1p– IEEE 802.1q– IEEE 802.3ab

Note: If CHPID type OSC is defined, only one of the two corresponding physical ports (port 0) can be used for OSA-ICC).


– IEEE 802.3ac– IEEE 802.3u– IEEE 802.3x

OSA-Express2 10 Gigabit Ethernet Long Reach (10 GbE LR) featureFeature code 3368 occupies one slot in the z10 or z9 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 and supports an unrepeated maximum distance of 10 km (6.2 miles).

The OSA-Express2 10 GbE LR feature does not support auto-negotiation to any other speed and runs in full duplex mode only.

The OSA-Express2 10 GbE LR port must be defined as CHPID type OSD. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.


10GBASE-LR (standard transmission scheme)


OSA-Express2 Gigabit Ethernet long wavelength (GbE LX) featureFeature code 3364 occupies one slot in the System z10 or z9 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, supporting an unrepeated maximum distance of 5 km (3.1 miles). Multimode (62.5 or 50 micron) fiber optic cable can be used with these features. The use of these multimode cable types requires a mode conditioning patch (MCP) cable at each end of the fiber optic link. Use of the single mode to multimode MCP cables reduces the supported distance of the link to a maximum of 550 meters (1084 feet).

The OSA-Express2 GbE LX feature does not support auto-negotiation to any other speed and runs in full duplex mode only.

The OSA-Express2 GbE LX ports can be defined as CHPID type OSD or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.


1000BASE-LX (standard transmission scheme)


OSA-Express2 Gigabit Ethernet short wavelength (GbE SX) featureFeature code 3365 occupies one slot in the System z10 or z9 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 auto-negotiation to any other speed and runs in full duplex mode only.

The OSA-Express2 GbE SX ports can be defined as CHPID type OSD or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.




OSA-Express2 1000BASE-T Ethernet featureFeature code 3366 occupies one slot in the System z10 or z9 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 auto-negotiation when attached to an Ethernet router or switch. If you allow the LAN speed and duplex mode to default to auto-negotiation, the OSA port and the attached router or switch auto-negotiate 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 router or switch does not support auto-negotiation, the OSA 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-Express2 1000BASE-T Ethernet feature port:



LAN speed and duplex mode can be set explicitly, using OSA/SF or the OSA Advanced Facilities function of the hardware management console (HMC). The explicit settings will override the OSA-Express2 feature port’s ability to auto-negotiate with its attached Ethernet switch.

The OSA-Express2 1000BASE-T ports can be defined as CHPID type OSD, OSE, OSC, or OSN. See 1.1.1, “Operating modes” on page 2 for details about modes of operation and supported traffic types.






– IEEE 802.3u


– IEEE 802.1p– IEEE 802.1q– IEEE 802.3ab– IEEE 802.3ac– IEEE 802.3u– IEEE 802.3x


Appendix B. OSA-Express Network Traffic Analyzer

The OSA-Express Network Traffic Analyzer OSAENTA trace facility runs in z/OS; it is a diagnostic method for obtaining frames flowing to and from an OSA feature. You can use the OSAENTA statement to copy frames as they enter or leave an OSA feature for an attached host.

B


OSA-Express Network Traffic Analyzer (OSAENTA)When data problems occur in a LAN environment, multiple traces are usually required. A sniffer trace might be required to see the data as it was received from or sent to the network. An OSA hardware trace might be required if the problem is suspected in the OSA, and z/OS Communications Server traces are required to diagnose VTAM or TCP/IP problems.

To assist in problem diagnosis, the OSA-Express network traffic analyzer (OSAENTA) function provides a way to trace inbound and outbound frames for OSA-Express3 and OSA-Express2 features. We will The OSAENTA trace function is controlled and formatted by z/OS Communications Server, but is collected in the OSA at the network port.

This section discusses the steps that are necessary for setting up and using OSAENTA:

� Determining the microcode level for OSA/OSAExpress3� Defining TRLE definitions� Checking TCPIP definitions� Customizing OSA-Express Network Traffic Analyzer (NTA)� Defining a resource profile in RACF� Allocating a VSAM linear data set� Starting the OSAENTA trace

Determining the microcode level for OSA There are many ways to determine the OSA microcode level: from the Hardware Management Console (HMC), using OSA/SF or by issuing the D NET,TRL,TRLE=OSAE200P command. We show you here the method for HMC and using the VTAM TRL command.

The method on how to retrieve data using OSA/SF is described in TWTW in the OSA/SF Chapter.

� From the HMC:

– Select your system.– Double-click OSA Advanced Facilities.– Select the appropriate PCHID.– Select View code level.

Figure B-1 shows the microcode level installed in one of our OSA-Express3 features.

Note: To enable the OSA-Express network traffic analyzer, you must be running at least an IBM System z10 or z9 server with OSA-Express3 and OSA-Express2 features in QDIO mode (CHPID type OSD). For z10, see the 2097DEVICE (EC) and 2098DEVICE (BC) and for z9 the 2094DEVICE (EC) and 2096DEVICE (BC) Preventive Service Planning (PSP) buckets for more information about these topics.


Figure B-1 View code level

� Or, you can issue the D NET,TRL,TRLE=OSAE200P command; Example B-1 shows the output.

Example: B-1 Output Display TRL

D NET,TRL,TRLE=OSAE200P IST097I DISPLAY ACCEPTED IST075I NAME = OSAE200P, TYPE = TRLE 277 IST1954I TRL MAJOR NODE = TRLE200 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE IST2263I PORTNAME = OSAE200 PORTNUM = 0 OSA CODE LEVEL = 0707IST1577I 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

Defining TRLE definitionsUse the D U,,,E200,16 command to ensure that you have defined enough devices; see Example B-2.

Appendix B. OSA-Express Network Traffic Analyzer 199

Example: B-2 Verifying the number of OSA devices

D U,,,E200,16 IEE457I 09.33.02 UNIT STATUS 279 UNIT TYPE STATUS VOLSER VOLSTATEE200 OSA A-BSY E201 OSA A E202 OSA A-BSY E203 OSA A-BSY E204 OSA A-BSY E205 OSA A E206 OSA A-BSY E207 OSA O E208 OSA A-BSY E209 OSA O E20A OSA O E20B OSA O E20C OSA O E20D OSA O E20E OSA O E20F OSAD O-RAL

The OSA port needs an additional DATAPATH statement on the TRL (see Example B-3).

Example: B-3 TRL definition

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

Checking TCPIP definitionsAn excerpt of the TCP/IP profile, displayed in Example B-4, shows the information that will be needed when starting the OSAENTA trace in a later step. Keep this information handy.

Example: B-4 TCP/IP definitions

;OSA DEFINITIONDEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VLANID 980 VMAC 020012345678HOME 192.168.1.64 OSAE200LNKSTART OSAE200

After TCP/IP is started, you can also see the OAT entries using OSA/SF (see Example B-5 on page 201).


Example: B-5 OAT entries

START OF OSA ADDRESS TABLE-------------------------- UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01) CULA 0000(E200)* MPC n/a OSAE200 (QDIO control) SIU ALL 02(E202) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL IPv4 VLAN 980 VMAC IP Address HOME 020012345678 192.168.1.64 HOME 020012345678 192.168.1.164 Group Address Multicast Address 01005E000001 224.0.0.1 03(E203) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL VMAC IP Address HOME 020087654321 192.168.1.4 HOME 020087654321 192.168.1.165 Group Address Multicast Address 01005E000001 224.0.0.1

Customizing OSA-Express Network Traffic Analyzer (NTA)Use this task to select an OSA-Express Network Traffic Analyzer (NTA) support element control, to customize the OSA-Express NTA settings in Advanced Facilities, or to check the current OSA-Express NTA authorization.

Customizing OENTA for the support element:

� Allows the support element to set up the OSA LAN Analyzer traces and capture data to the support element hard disk.

� Allows the support element to change authorization to allow host operating systems to enable the NTA traces outside their own partition.

1. Log on to the Support Element (SE) on the Hardware Management Console (HMC) through Single Object Operations (SOO).

2. Select the CPC you want to work with, as shown in Figure B-2 on page 202.

Note: The OSA-Express Network Traffic Analyzer is mutually exclusive with the OSA LAN Analyzer for tracing on a specified CHPID. Only one or the other can be enabled for a specified CHPID at any one time.

Important: Enabling the OSAENTA support could allow tracing of sensitive information. Therefore, the user ID used to do the following steps must have the “Access Administrator Tasks” role assigned.


Figure B-2 From the HMC, log on to SE

3. Select and open the Service task list; see Figure B-3.


Figure B-3 OSA-Express NTA

4. Double-click the OSA-Express NTA SE Controls task; see Figure B-4.

Figure B-4 OSA NTA Controls

5. Select the control to work with:

– Customize OSA-Express Network Traffic Analyzer Settings... provides the capability to allow or disallow the support element to change authorization to allow host operating systems to enable the Network Traffic Analyzer to trace outside their own partition.

– Check current OSA-Express Network Traffic Analyzer authorization... allows the support element to scan all the OSAs and reports back which OSAs are authorized for NTA to trace outside its own partition.


6. Click OK to change the current OSA-Express NTA control; see Figure B-5.

Figure B-5 Change the current OSA-Express NTA control

7. Click Allow the Support Element to allow Host Operating System to enable NTA.

8. Click OK; see Figure B-6.

Figure B-6 Command completed

9. Log off from the SE and from the HMC.

10.Log on to the SE on the HMC through SOO (Single Object Operations) using the SYSPROG user ID.

11.Select Channels work area (on the left side of the screen) and Channel Operation (on the right side of the screen).

12.Select the channel that you want to manage (see Figure B-7 on page 205).


Figure B-7 Channel Operations menu

13.In our case we selected PCHID 01C1 (CHPID 0A). We double-clicked Advanced Facilities; see Figure B-8.

Figure B-8 Advanced Facilities options

14.Select Card trace/log/dump facilities..., then click OK; see Figure B-9 on page 206.


Figure B-9 Card Trace/Log/Dump Facilities

15.Select OSA-Express Host Network Traffic Analyzer Authorization, then click OK; see Figure B-10.

Figure B-10 NTA Authorization

16.If your CHPID is shared between several LPARs, we suggest you select the option PORT as shown in Figure B-10, then click OK. Figure B-11 shows the results.

Figure B-11 Command completed


17.To verify whether the command has been set as required:

– Log off the SYSPROG user ID.

– Log on to the SE on the HMC through SOO; see Figure B-2 on page 202.

– Select Check current OSA-Express Network Traffic Analyzer Authorization, as shown in Figure B-4 on page 203.

– Click OK; see Figure B-12.

Figure B-12 OSA-Express NTA controls

18.Figure B-13 shows that PCHID 0390 is allowed to be traced.

Figure B-13 PCHID NTA Authorization

Defining a resource profile in RACFSee Example B-6 for the RACF commands needed to allow users to issue the VARY TCPIP command.

Example: B-6 RACF commands

RDEFINE OPERCMDS MVS.VARY.TCPIP.OSAENTA UACC(NONE) PERMIT MVS.VARY.TCPIP.OSAENTA ACCESS(CONTROL) CLASS(OPERCMDS) ID(CS03) SETR GENERIC(OPERCMDS) REFRESH SETR RACLIST(OPERCMDS) REFRESH

Important: For checking the authorization of OSAENTA support, the user ID must have the Access Administrator Tasks role assigned.


Allocating a VSAM linear data setExample B-7 shows how to create the VSAM linear data set. This VSAM linear data set is Optional; however, we recommend its use.

Example: B-7 Allocate VSAM linear dataset

//DEFINE EXEC PGM=IDCAMS//SYSPRINT DD SYSOUT=*//SYSIN DD *DELETE +(CS03.CTRACE.LINEAR) +CLUSTERDEFINE CLUSTER( +NAME(CS03.CTRACE.LINEAR) +LINEAR +MEGABYTES(10) +VOLUME(CPDLB0) +CONTROLINTERVALSIZE(32768) +) +DATA( +NAME(CS03.CTRACE.DATA) +)LISTCAT ENT(USER41.CTRACE.LINEAR)ALL

Starting the OSAENTA traceThe OSAENTA statement dynamically defines a QDIO interface to the OSA port being traced, called an OSAENTA interface. This interface is used exclusively for capturing OSA-Express Network Traffic Analyzer traces.

The OSAENTA statement enables an installation to trace data from other hosts connected to the OSA port.

To see the complete syntax of the OSAENTA command, refer to z/OS Communications Server: IP Configuration Reference, SC31-8776.

Components involved in z/OS CTRACEThe CTRACE component for collecting NTA trace data is called SYSTCPOT. The member in SYS1.PARMLIB is named CTINTA00. This member is used to define the size of the buffer space in the TCPIPDS1 data space reserved for OSAENTA CTRACE. The size can range from 1 MB to 624 MB, with a default of 64 MB.

Using the OSAENTA commandAn internal interface is created when PORTNAME is defined on the OSAENTA statement. The dynamically-defined interface name is EZANTA concatenated with the port name. These EZANTA interfaces are displayed at the end of the NETSTAT DEV output.

Important: The trace data collected should be considered confidential and TCP/IP system dumps and external trace files containing this trace data should be protected.

Note: Update CTINTA00 to set the CTRACE buffer size. Keep in mind that this will use up auxiliary page space storage.


When the ON keyword of the OSAENTA parameter is used, VTAM allocates the next available TRLE data path associated with the port. This data path is used only for inbound trace data.

When the OFF keyword of the OSAENTA parameter is used (or the trace limits of the TIME, DATA, or FRAMES keyword are reached), the data path is released.

Setting the OSAENTA tracesYou can set the OSAENTA trace in two ways: by coding the OSAENTA statement in the profile TCP/IP, or by issuing a command in z/OS. These methods are explained in this section.

� To code the OSAENTA statement in the profile TCP/IP, see Example B-8.

Example: B-8 TCP/IP profile

; set up the filters to trace for TCP packets on PORT 2323 with a source ;or destination ; IP address of 10.1.2.11 over MAC address 00096B1A7490 OSAENTA PORTNAME=OSA2080 PROT=TCP IP=10.1.2.11 PORTNUM=2323 OSAENTA PORTNAME=OSA2080 MAC=00096B1A7490 ; activate the tracing (the trace will self-deactivate after 20,000 frames) OSAENTA PORTNAME=OSA2080 ON FRAMES=20000 ; deactivate the tracingOSAENTA OFF PORTNAME=OSA2080

In this case, OSAENTA traces the portname OSA2080 only for traffic matching the following filters:

– Protocol = UDP– IP address = 10.1.2.11– Port number = 2323

There are seven filters available to define the packets to be captured:

– MAC address– VLAN ID– Ethernet frame type– IP address (or range)– IP protocol– Device ID– TCP/UDP

� To issue the following command in z/OS:

V TCPIP,TCPIPA,OSAENTA,ON,PORTNAME=OSA2080,IP=10.1.2.11,PORTNUM=2323

The messages you receive in response to this command are shown in Figure B-14.

Figure B-14 OSAENTA results

Note: Use filters to limit the trace records to prevent overconsumption of the OSA CPU resources, the LPAR CPU resources, the TCPIPDS1 trace data space, memory, auxiliary page space and the IO subsystem writing trace data to disk.

RESPONSE=SC30 EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPA,OSAENTA,ON,

RESPONSE=PORTNAME=OSA2080,IP=10.1.2.11,PORTNUM=2323

RESPONSE=SC30 EZZ0053I COMMAND VARY OSAENTA COMPLETED SUCCESSFULLY


The command NETSTAT DEVLINKS has been enhanced to show the OSAENTA definition; see Example B-9.

Example: B-9 Netstat Devlinks command output

OSA-EXPRESS NETWORK TRAFFIC ANALYZER INFORMATION: OSA PORTNAME: OSA2080 OSA DEVSTATUS: READY OSA INTFNAME: EZANTAOSA2080 OSA INTFSTATUS: READY OSA SPEED: 1000 OSA AUTHORIZATION: CHPID OSAENTA CUMULATIVE TRACE STATISTICS: DATAMEGS: 0 FRAMES: 0 DATABYTES: 0 FRAMESDISCARDED: 0 FRAMESLOST: 0 OSAENTA ACTIVE TRACE STATISTICS: DATAMEGS: 0 FRAMES: 0 DATABYTES: 0 FRAMESDISCARDED: 0 FRAMESLOST: 0 TIMEACTIVE: 0 OSAENTA TRACE SETTINGS: STATUS: ON DATAMEGSLIMIT: 1024 FRAMESLIMIT: 2147483647 ABBREV: 224 TIMELIMIT: 10080 DISCARD: EXCEPTION OSAENTA TRACE FILTERS: NOFILTER: NONE DEVICEID: * MAC: * VLANID: * ETHTYPE: * IPADDR: 10.1.2.11/32 PROTOCOL: * TCP PORTNUM: * 2323

The NETSTAT display for devices shows the Network Traffic Analyzer interfaces. The interface name has prefixed the OSA port name with EZANTA.

To display a specific NTA interface, use the INTFName=EZANTAosaportname keyword.

Traces are placed in an internal buffer, which can then be written out using a CTRACE external writer. The MVS TRACE command must also be issued for component SYSTCPOT to activate the OSAENTA trace.

Important: If you receive ERROR CODE 0003 it means that an attempt was made to enable OSA-Express Network Traffic Analyzer (OSAENTA) tracing for a specified OSA port, but the current authorization level does not permit it.

Refer to “Customizing OSA-Express Network Traffic Analyzer (NTA)” on page 201 for directions about how to change the authorization to allow OSAENTA to be used on this specified OSA. Also read Support Element Operations Guide, SC28-6860, for complete information about this topic.

Attention: If you receive ERROR CODE 0005 it means that an attempt was made to enable OSA-Express Network Traffic Analyzer tracing for a specified OSA that already has either OSAENTA or OSA LAN Analyzer tracing enabled elsewhere on the system for this OSA.

Only one instance of active tracing (either OSAENTA or LAN Analyzer) for a specified OSA is permitted on the system at any one time.


When the trace is started from OSA/SF, you can see that another device has been allocated for trace; see Example B-10.

Example: B-10 OAT with OSAENTA started

Image 2.3 (A23 ) CULA 0 00(2080)* MPC N/A OSA2080P (QDIO control) SIU ALL02(2082) MPC 00 No4 No6 OSA2080P (QDIO data) SIU ALL VLAN 10 (IPv4) Group Address Multicast Address 01005E000001 224.000.000.001 VMAC IP address HOME 00096B1A7490 010.001.000.010 HOME 00096B1A7490 010.001.001.010 HOME 00096B1A7490 010.001.002.010 HOME 00096B1A7490 010.001.002.011 REG 00096B1A7490 010.001.002.012 REG 00096B1A7490 010.001.003.011 REG 00096B1A7490 010.001.003.012 REG 00096B1A7490 010.001.004.011 REG 00096B1A7490 010.001.005.011 REG 00096B1A7490 010.001.006.011 REG 00096B1A7490 010.001.007.011 REG 00096B1A7490 010.001.008.010 REG 00096B1A7490 010.001.008.020 03(2083) MPC 00 No4 No6 OSA2080P (QDIO data) SIU ALL

You can also use the D NET,TRL,TRLE=OSA2080 command, as shown in Example B-11.

Example: B-11 Output Display TRLE

TRL MAJOR NODE = OSA2080 STATUS= ACTIV, DESIRED STATE= ACTIV TYPE = LEASED , CONTROL = MPC , HPDT = YES MPCLEVEL = QDIO MPCUSAGE = SHARE PORTNAME = OSA2080 LINKNUM = 0 OSA CODE LEVEL = 087A HEADER SIZE = 4096 DATA SIZE = 0 STORAGE = ***NA*** WRITE DEV = 2081 STATUS = ACTIVE STATE = ONLINE HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA*** READ DEV = 2080 STATUS = ACTIVE STATE = ONLINE DATA DEV = 2082 STATUS = ACTIVE STATE = N/A I/O TRACE = OFF TRACE LENGTH = *NA* ULPID = TCPIPA IQDIO ROUTING DISABLED READ STORAGE = 4.0M(64 SBALS) PRIORITY1: UNCONGESTED PRIORITY2: UNCONGESTED PRIORITY3: UNCONGESTED PRIORITY4: UNCONGESTED DEVICEID PARAMETER FOR OSAENTA TRACE COMMAND = 02-03-00-02 UNITS OF WORK FOR NCB AT ADDRESS X'0F4E7010' P1 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 P2 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 P3 CURRENT = 0 AVERAGE = 0 MAXIMUM = 0 P4 CURRENT = 0 AVERAGE = 2 MAXIMUM = 3 TRACE DEV = 2083 STATUS = ACTIVE STATE = N/A


Starting the CTRACE� Start the external writer (CTRACE writer):

TRACE CT,WTRSTART=CTWRT

� Start the CTRACE and connect to the external writer:

TRACE CT,ON,COMP=SYSTCPOT,SUB=(TCPIPA)

R xx,WTR=CTWTR,END

� Display the active component trace options with this command:

DISPLAY TRACE,COMP=SYSTCPOT,SUB=(TCPIPA)

Example B-12 shows the output of this command.

Example: B-12 Display Trace output

RESPONSE=SC30 IEE843I 16.45.15 TRACE DISPLAY 165 SYSTEM STATUS INFORMATION ST=(ON,0256K,00512K) AS=ON BR=OFF EX=ON MO=OFF MT=(ON,024K) TRACENAME ========= SYSTCPOT MODE BUFFER HEAD SUBS ===================== OFF HEAD 2 NO HEAD OPTIONS SUBTRACE MODE BUFFER HEAD SUBS -------------------------------------------------------------- TCPIPA ON 0128M ASIDS *NONE* JOBNAMES *NONE* OPTIONS MINIMUM WRITER CTWTR

To display information about the status of the component trace for all active procedures, issue the following command:

DISPLAY TRACE,COMP=SYSTCPOT,SUBLEVEL,N=8

Example B-13 displays the output.

Example: B-13 Status of Component Trace

IEE843I 10.35.04 TRACE DISPLAY 821 SYSTEM STATUS INFORMATION ST=(ON,0256K,00512K) AS=ON BR=OFF EX=ON MO=OFF MT=(ON,024K) TRACENAME ========= SYSTCPOT MODE BUFFER HEAD SUBS ===================== OFF HEAD 2 NO HEAD OPTIONS SUBTRACE MODE BUFFER HEAD SUBS -------------------------------------------------------------- TCPIPA ON 0128M ASIDS *NONE* JOBNAMES *NONE* OPTIONS MINIMUM WRITER CTWTR


-------------------------------------------------------------- TCPIP MIN 0016M ASIDS *NONE* JOBNAMES *NONE* OPTIONS MINIMUM WRITER *NONE*

� Reproduce the problem.

� Disconnect the external writer:

TRACE CT,ON,COMP=SYSTCPOT,SUB=(TCPIPA)

R xx,WTR=DISCONNECT,END

� Stop the component trace:

TRACE CT,OFF,COMP=SYSTCPOT,SUB=(TCPIPA)

� Stop the external writer:

TRACE CT,WTRSTOP=CTWRT

Analyzing the traceThere are two ways for formatting the CTRACE: you can use IPCS, or with a batch job. In this section, we explain how to use each method.

� Using IPCS to format CTRACE

You can format component trace records using IPCS panels or a combination of IPCS panels and the CTRACE command, either from a dump or from external writer files.

From the IPCS PRIMARY OPTION MENU, select: 0 DEFAULTS - Specify default dump and options; see Example B-14 for details.

Example: B-14 IPCS default value

------------------------- IPCS Default Values --------------------------------- Command ===> You may change any of the defaults listed below. The defaults shown before any changes are LOCAL. Change scope to GLOBAL to display global defaults. Scope ==> LOCAL (LOCAL, GLOBAL, or BOTH) If you change the Source default, IPCS will display the current default Address Space for the new source and will ignore any data entered in the Address Space field. Source ==> DSNAME('SYS1.SC30.CTRACE') Address Space ==> Message Routing ==> NOPRINT TERMINAL Message Control ==> CONFIRM VERIFY FLAG(WARNING) Display Content ==> NOMACHINE REMARK REQUEST NOSTORAGE SYMBOL

Modify the DSNAME and OPTIONS to match your environment, then select the following options:

� 2 ANALYSIS - Analyze dump contents� 7 TRACES - Trace formatting� 1 CTRACE - Component trace� D DISPLAY - Specify parameters to display CTRACE entries


Fill in the parameters necessary to format the OSAENTA trace; see Example B-15 on page 214.

Example: B-15 CTRACE parameters

-------------------- CTRACE DISPLAY PARAMETERS ------------------------COMMAND ===> System ===> (System name or blank) Component ===> SYSTCPOT (Component name (required)) Subnames ===> TCPIPA GMT/LOCAL ===> G (G or L, GMT is default) Start time ===> (mm/dd/yy,hh:mm:ss.dddddd or Stop time ===> mm/dd/yy,hh.mm.ss.dddddd) Limit ===> 0 Exception ===> Report type ===> SHORT (SHort, SUmmary, Full, Tally) User exit ===> (Exit program name) Override source ===> Options ===> To enter/verify required values, type any character Entry IDs ===> Jobnames ===> ASIDs ===> OPTIONS ===> SUBS ===> CTRACE COMP(SYSTCPOT) SUB((TCPIPA)) SHORT ENTER = update CTRACE definition. END/PF3 = return to previous panel. S = start CTRACE. R = reset all fields.

On the Command line, enter the S command. Example B-16 shows the trace formatted by IPCS.

Example: B-16 TRACE format

COMPONENT TRACE SHORT FORMAT SYSNAME(SC30) COMP(SYSTCPOT)SUBNAME((TCPIPA)) z/OS TCP/IP Packet Trace Formatter, (C) IBM 2000-2006, 2007.052 DSNAME('SYS1.SC30.CTRACE') **** 2007/09/11 RcdNr Sysname Mnemonic Entry Id Time Stamp Description ----- -------- -------- -------- --------------- ----------------------------- ------------------------------------------------------------------------------ 365 SC30 OSAENTA 00000007 15:01:23.356987 OSA-Express NTA To Interface : EZANTAOSA2080 Full=86 Tod Clock : 2007/09/11 14:25:44.160269 Sequence # : 0 Flags: Pkt Out Nta Vlan Lpar L3 Source : 10.1.2.11 Destination : 224.0.0.5 Source Port : 0 Dest Port: 0 Asid: 0000 TCB: 0000000 Frame: Device ID : 02030002 Sequence Nr: 372 Discard: 0 (OK) EtherNet II : 8100 IEEE 802.1 Vlan Len: 0x0044 (68 Destination Mac : 01005E-000005 () Source Mac : 00096B-1A7490 (IBM) Vlan_id : 10 Priority: 0 Type: 0800 (Int IpHeader: Version : 4 Header Length: 20 Tos : 00 QOS: Routine Normal Service


Packet Length : 68 ID Number: 0AFD Fragment : Offset: 0 TTL : 1 Protocol: OSPFIGP CheckSum: C253 Source : 10.1.2.11

Destination : 224.0.0.5 ------------------------------------------------------------------------------ 366 SC30 OSAENTA 00000007 15:01:33.360143 OSA-Express NTA To Interface : EZANTAOSA2080 Full=86 Tod Clock : 2007/09/11 14:25:54.163264 Sequence # : 0 Flags: Pkt Out Nta Vlan Lpar L3 Source : 10.1.2.11 Destination : 224.0.0.5 Source Port : 0 Dest Port: 0 Asid: 0000 TCB: 0000000 Frame: Device ID : 02030002 Sequence Nr: 373 Discard: 0 (OK) EtherNet II : 8100 IEEE 802.1 Vlan Len: 0x0044 (68 Destination Mac : 01005E-000005 () Source Mac : 00096B-1A7490 (IBM) Vlan_id : 10 Priority: 0 Type: 0800 (Int IpHeader: Version : 4 Header Length: 20 Tos : 00 QOS: Routine Normal Service Packet Length : 68 ID Number: 0B07 Fragment : Offset: 0 TTL : 1 Protocol: OSPFIGP CheckSum: C249 Source : 10.1.2.11 Destination : 224.0.0.5 ------------------------------------------------------------------------------

Using a batch job to format CTRACE:

We used a batch job to generate the TRACE file, as shown in Example B-17.

Example: B-17 CTRACE batch job format

//PKT2SNIF JOB (999,POK),'CS03',NOTIFY=&SYSUID, // CLASS=A,MSGCLASS=T,TIME=1439, // REGION=0M,MSGLEVEL=(1,1) // SET INDUMP='SYS1.SC30.CTRACE' //IPCSBTCH EXEC PGM=IKJEFT01,DYNAMNBR=30 //IPCSDDIR DD DISP=SHR,DSN=SYS1.DDIR //IPCSDUMP DD * //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //INDMP DD DISP=SHR,DSN=&INDUMP. //IPCSPRNT DD DSN=ENTA.CTRACE.SHORT,UNIT=SYSDA, // DISP=(NEW,CATLG),LRECL=133,SPACE=(CYL,(10,1)),RECFM=VBS,DSORG=PS//IPCSTOC DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * PROFILE MSGID IPCS NOPARM SETD PRINT NOTERM LENGTH(160000) NOCONFIRM FILE(INDMP) DROPD CTRACE COMP(SYSTCPOT) SUB((TCPIPA)) SHORT END


We received the output shown in Example B-18 from the batch job.

Example: B-18 Output from the batch job

COMPONENT TRACE SHORT FORMAT SYSNAME(SC30) COMP(SYSTCPOT)SUBNAME((TCPIPA)) z/OS TCP/IP Packet Trace Formatter, (C) IBM 2000-2006, 2007.052 FILE(INDMP) **** 2007/09/11 RcdNr Sysname Mnemonic Entry Id Time Stamp Description ----- -------- -------- -------- --------------- -------------------------------------------------------------------------------------------------------------- 365 SC30 OSAENTA 00000007 15:01:23.356987 OSA-Express NTA To Interface : EZANTAOSA2080 Full=86 Tod Clock : 2007/09/11 14:25:44.160269 Sequence # : 0 Flags: Pkt Out Nta Vlan Lpar L3 Source : 10.1.2.11 Destination : 224.0.0.5 Source Port : 0 Dest Port: 0 Asid: 0000 TCB: 00000000 Frame: Device ID : 02030002 Sequence Nr: 372 Discard: 0 (OK) EtherNet II : 8100 IEEE 802.1 Vlan Len: 0x0044 (68) Destination Mac : 01005E-000005 () Source Mac : 00096B-1A7490 (IBM) Vlan_id : 10 Priority: 0 Type: 0800 (Inter IpHeader: Version : 4 Header Length: 20 Tos : 00 QOS: Routine Normal Service

Packet Length : 68 ID Number: 0AFD Fragment : Offset: 0 TTL : 1 Protocol: OSPFIGP CheckSum: C253 FF Source : 10.1.2.11 Destination : 224.0.0.5 ------------------------------------------------------------------------------- 366 SC30 OSAENTA 00000007 15:01:33.360143 OSA-Express NTA To Interface : EZANTAOSA2080 Full=86 Tod Clock : 2007/09/11 14:25:54.163264 Sequence # : 0 Flags: Pkt Out Nta Vlan Lpar L3 Source : 10.1.2.11 Destination : 224.0.0.5 Source Port : 0 Dest Port: 0 Asid: 0000 TCB: 00000000 Frame: Device ID : 02030002 Sequence Nr: 373 Discard: 0 (OK) EtherNet II : 8100 IEEE 802.1 Vlan Len: 0x0044 (68) Destination Mac : 01005E-000005 () Source Mac : 00096B-1A7490 (IBM) Vlan_id : 10 Priority: 0 Type: 0800 (Inter IpHeader: Version : 4 Header Length: 20 Tos : 00 QOS: Routine Normal Service Packet Length : 68 ID Number: 0B07 Fragment : Offset: 0 TTL : 1 Protocol: OSPFIGP CheckSum: C249 FF Source : 10.1.2.11 Destination : 224.0.0.5

-------------------------------------------------------------------------------

Additional tools for diagnosing CS for z/OS IP problemsIBM and other vendors have developed tools to assist in diagnosing problems in the network from the perspective of z/OS. The tools often run as GUIs on a workstation, but retrieve their


problem diagnosis information using data from SNMP, SMF, and from MVS control blocks. Some of these tools also interface with the Network Management Interface API, provided by IBM.

Network Management Interface API (NMI)Figure B-15 depicts a high-level view of the NMI and its interfaces to network management products.

Figure B-15 Network Management Interface Architecture

The NMI API can interface with Tivoli OMEGAMON® XE for Mainframe Networks (or other products) to provide the following types of functions:

� Trace assistance

– Real-time tracing and formatting for packet and data traces

� Information gathering

– TCP connection initiation and termination notifications

– API for real-time access to TN3270 server and FTP event data and to IPSec

– APIs to poll information about currently active connections

– TCP listeners (server processes)

– TCP connections (detailed information about individual connections and UDP endpoints)

– CS storage usage

– API to receive and poll for Enterprise Extender management data

– Information and statistics for IP filtering and IPSec security associations on the local TCP/IP stacks.

– Information and statistics for IP filtering and IPSec security associations on remote Network Security Services (NSS) clients when using the NSS server.

CS z/OS and components

Remote monitor

Local monitor

Private protocol

APIs

Commands/Utilities

Exit points

SNMP

SMF and Syslogd

Exit point

I n s t r u m e n t a t i o n

Presentation

IBM Tivoli Software or other Network

Management vendorSNMP

z/OS


� Control activities

� Control the activation and inactivation of IPSec tunnels

� Loading policies for IP filtering and IPSec security associations on the local TCP/IP stacks

– Loading policies for IP filtering and IPSec security associations on remote Network Security Services (NSS) clients when using the NSS server

– Drop one or multiple TCP connections or UDP endpoints

ReferencesRefer to the following for more information regarding use of logs, standard commands, tools, and utilities:

� z/OS Communications Server: IP System Administrator’s Commands, SC31-8781� z/OS Communications Server: IP Diagnosis Guide, GC31-8782� z/OS Communications Server: IP Configuration Reference, SC31-8776� z/OS MVS Diagnosis: Tools and Service Aids, GA22-7589� z/OS Communications Server: SNA Diagnosis Vol. 1, Techniques and Procedures,

GC31-6850� z/OS Communications Server: SNA Operation, SC31-8779� MVS Installation Exits, SA22-7593� Support Element Operations Guide, SC28-6860

z/OS Communications Server product support information can be obtained at:

http://www-306.ibm.com/software/network/commserver/zos/support/

For information on IBM Tivoli OMEGAMON XE for Mainframe Networks, go to:

http://publib.boulder.ibm.com/tividd/td/IBMTivoliOMEGAMONXEforMainframeNetworks1.0.html


http://publib.boulder.ibm.com/tividd/td/IBMTivoliOMEGAMONXEforMainframeNetworks1.0.html

http://www-306.ibm.com/software/network/commserver/zos/support/

Appendix C. HMC and SE tasks for OSA

This appendix discusses the tools that you can use from a Hardware Management Console (HMC) or the Support Element (SE) of a System z10 or z9 server. First it describes the advanced facilities for OSA 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.

C


HMC advanced facilities for OSAThe advanced facilities (Open Systems Adapter Support Facility (OSA/SF)) available on the HMC are as follows.

� Set Trace Buffer� Read Trace Buffer� Export Trace/Dump file to diskette� Card-specific advanced facilities, with the following subdivisions:

– 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 C-1).

Figure C-1 Console logon

Then follow these steps to start the individual functions:

1. Open the CPC group work area.

2. In the Hardware Management Console Workplace window (Figure C-2 on page 221), switch to CPC Operational Customization in the Task Area. Select the appropriate CPC and drag and drop it to the OSA Advanced Facilities Task.

Note: These functions are used for troubleshooting under the guidance of IBM Product Engineering.


Figure C-2 HMC Workplace

3. The OSA Advanced Facilities window (Figure C-3) opens in the HMC console. Select the OSA CHPID that you want to work with and click OK.

Figure C-3 HMC OSA Advanced Facilities window

Appendix C. HMC and SE tasks for OSA 221

The Standard Channel Advanced Facilities window (Figure C-4) opens.

Figure C-4 Standard Channel Advanced Facilities window

Trace functions for OSAThese trace functions are used to troubleshoot under the guidance of IBM Product Engineering.

Setting Trace Mask on the OSA cardFollow these steps:

1. In the OSA Advanced Facilities window, select Card Trace/Log/Dump facilities.

2. In the Card Trace/Log/Dump Facilities window (Figure C-5), select Display and or alter trace mask and click OK.

Figure C-5 Card trace/Log/Dump Facilities


With guidance from IBM, complete the fields shown in the Display and/or alter trace mask window (Figure C-6).

Figure C-6 Display and/or alter trace mask window

Read Trace Buffer on the OSA cardFollow these steps:

1. In the OSA Advanced Facilities window (Figure C-4 on page 222), select Card Trace/Log/Dump facilities.

2. In the Card Trace/Log/Dump Facilities window (Figure C-7), select Read Trace Buffer and click OK.

Figure C-7 Read trace buffer confirmation window


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 shown in Figure C-8.

Figure C-8 Read trace buffer completed

Hardware functions for OSA-ExpressIn the OSA Advanced Facilities window, select Card specific advanced facilities.... The Advanced facilities window opens as shown in Figure C-9. The following sections explain the options on this window further.

Figure C-9 Card-specific advanced facilities


Enable or disable ports on OSA-Express CardsIn the Advanced facilities window, select Enable or disable ports and click OK. The Enable or disable ports window (Figure C-10) opens.

Figure C-10 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).

Query port status on an OSA-Express CardIn the Advanced facilities window, select Query port status and click OK. The Query port status window (Figure C-11) opens. To exit the window, simply click OK.

Figure C-11 Query port status window

Run diagnostics on an OSA-Express CardIn the Advanced facilities window (see Figure C-9 on page 224), select Run port diagnostics and click OK.

Note: Enabling or disabling the port is also possible with an OSA/SF function.


View port parameters on an OSA-Express CardIn the Advanced facilities window (see Figure C-9 on page 224), select View port parameters and click OK. For OSA-Express3 multi port cards, select port 0 or 1. The View port parameters window (Figure C-12) opens. You can use the scroll buttons of the window to view all port parameters. Then to exit the window, click OK.

Figure C-12 View port parameters window

Display or alter MAC address on an OSA-Express CardFollow 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 C-13 on page 227) opens. Change the MAC address, and click Apply to activate it.

To exit the window without any changes, click Cancel.

Note: You can use port diagnostics only if the port is disabled.


Figure C-13 Display or alter MAC address window

Settings for speed and mode on an OSA 1000BASE-T cardFollow these steps:

1. In the Advanced facilities window, select Set card mode and click OK.

2. In the Set card mode window (Figure C-14), 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.

Figure C-14 Ethernet Speed/Mode settings window

Note: The settings made here override the capability of the OSA 1000BASE-T auto negotiation facility.


OSA reset to defaultsFollow these steps:

In the OSA advanced facilities window, select Reset to defaults and click OK, as shown in Figure C-15. This function enables you to reset all your customized entries in the OSA card to the default settings, including the OSA Address Table (OAT).

Figure C-15 Advanced Facilities window at the Support Element

View code levelThe view code level task queries the OSA microcode level currently active in an OSA card. 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 related problem. You may be asked by the IBM Remote Technical Support Center, or your IBM Systems Services Representative (IBM CE) for the OSA 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 C-16).

Figure C-16 View code level

The four-digit code displayed will vary depending on the specific microcode EC and MCL level active in the OSA card. The code will change as microcode maintenance updates are applied to your System z10 or System z9 server by your IBM CE.

3. On the View Code Level panel, click OK. The Advanced Facilities panel is displayed.


Configuring OSA channels on/offWith the new design of the OSA cards, there is no longer a need to configure the OSA 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.

Logging on to the Support ElementTo 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 C-17), select the CPC involved, and then click OK.

Figure C-17 Single Object Selection

c. When the confirmation window opens, click OK.

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 C-18 on page 230 shows an example of that display. The System z10 pattern 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 in the lower left side.


Figure C-18 Support Element CPC Work Area

CHPID Configure on/offThe OSA CHPID is configured on or off by doing the following:

1. In the CPC Work Area, right-click the CPC object and select Channels.

2. The CPC CHPIDs Work Area is displayed (see Figure C-19 on page 231). 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.


Figure C-19 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 C-20 on page 232) opens. The Current state column shows the status of the channel for each logical partition.

Complete the following steps:

a. Read the warning information regarding configuring channels from the Support Element function rather than from an available operating system and type your password for confirmation.

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.

b. In all cases, click Apply to immediately change the desired channel state.

Note: The state Standby is the indicator of an offline CHPID to the LPAR.

Note: Before you click Apply in the next step, ensure that only the CHPID or CHPIDs that you want toggled are highlighted.


Figure C-20 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.

Logging off from the Support ElementWhen the work with the channels is finished, close the Support Element session as explained here:

1. In the Views area (Figure C-19 on page 231), double-click Console Actions.

2. The Console Action Work Area opens as shown in Figure C-21 on page 233. Double-click Log off to end the Support Element session.


Figure C-21 Logging off the Support Element


Appendix D. Useful 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.

D


z/OS commandsWe 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 D-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 (introduced with z/OS 1.4)

Purges ARP cache for the specified adapter (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.


Table D-2 TCP/IP TSO commands

Table D-3 VTAM 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

Command Description

D NET,VTAMOPTS Displays the current VTAM start options

F vtamname,VTAMOPTS,optionname=value

Modifies the current VTAM options (vtamname is the STC 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 D. Useful commands 237

z/VM commandsFor information about z/VM commands, refer to z/VM CP Command and Utility Reference, SC24-6008.

Table D-4 z/VM TCP/IP operations commands

Table D-5 z/VM TCP/IP 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 rdev|rdev-rdev

Changes the status of a path to devices

VARY OFF|ON CHPID cc Configures a CHPID off or on to both hardware and software

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.


Table D-6 z/VM Virtual Switch commands

Defining and coupling a NIC using CP commands

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

Table D-7 Operands for the DEFINE NIC command

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

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.

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 D. Useful commands 239

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 D-8 lists the operands that are accepted by the COUPLE command for the purpose of connecting a virtual NIC to a Guest LAN.

Table D-8 Operands for the Couple command

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 z TCP/IP commandsWhen using the Linux commands listed in Table D-9, enter them in lowercase, as shown.

Table D-9 TCP/IP commands

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.


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.


Command Description

arp Displays ARP cache; use -? for options

dmesg | more 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 up/down 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


Appendix E. Using the OSA/SF REXX interface

This appendix describes the steps required to configure an OSA CHPID using the TSO REXX interface for the non-QDIO modes.

E


Creating the OSA configurationThe Open Systems Adapter (OSA) configuration in the TSO environment is built with two z/OS sequential data sets. They contain statements that describe the OSA configuration and the OSA Address Table (OAT).

To build the OSA CHPID 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 configuration fileFollow these steps:

1. Create a skeleton configuration file:

– Example E-4 on page 246 shows a FENET/1000BASE-T configuration file. – Example E-5 on page 247 shows a token-ring configuration file.– Example E-6 on page 248 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 OAT fileComplete 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 E-1)– IOAOSHRS - SNA shared port (Example E-2)– IOAENTR - Default OAT with two ports


Example: E-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 supportslogical 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: E-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 supportslogical 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.

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.

The OSA port unit address was used by HCD when defining the OSA devices.

– 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: If you retrieve the OAT from the OSA card, the OAT obtained may contain several unneeded entries, especially if it is the default OAT.

Note: Only the even unit address entries are required for TCP/IP Passthru entries.

Appendix E. Using the OSA/SF REXX interface 243

– 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 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 E-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: E-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 supportslogical 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

Activating the OSA configurationOSA 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 to all partitions that are sharing this OSA port.

2. Log on to TSO from the system on which OSA/SF is running.

3. Enter the IOACMD command.

Note: The TSO user ID must be set up to use the OSA/SF TSO interface.


4. You see the choices shown in Figure E-1. Select option 2 to load a configuration.

Figure E-1 IOACMD menu

5. You now see the list shown in Figure E-2.

Figure E-2 IOACMD configure list

6. You are prompted through the configuration steps.

a. Enter the OSA 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.e. Enter the fully qualified data set name containing the OAT definitions.f. Enter the activation option, as shown in Figure E-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 feature.

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)

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 CHPIDIOACMD: 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 E-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 E-4, Example E-5, and Example E-6 on page 248 show sample configuration files.

Example: E-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) fenet.0.6.5 = 000000000000 /* Group address 5

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


/*======================================================================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 timersna.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: E-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)


Example: E-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)


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 F. TCP/IP Passthru mode

This appendix describes the process to configure an OSA-Express3 1000BASE-T port for TCP/IP Passthru mode, using the default OAT.

F


Default modeFigure F-1 shows a functional view of the connectivity as discussed in this chapter.

Figure F-1 TCP/IP in passthru mode

For this example, we use the OSA-Express3 1000BASE-T card, 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 z10 or z9 server sees the OSA-Express3 1000BASE-T 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.

HCD requirementsThe 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 35, for the procedure to create the definitions. Example F-1 shows the necessary definitions for the IOCDS used in this chapter. For future purposes, we use 31 OSA devices, although only two are needed in our configuration.

Channel Subsystem

LPAR 1

TCP/IP


Port 0 Port 1

"default OAT" (TCP/IP Passthru)

Ethernet Switch


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: F-1 IOCDS input for CHPID 0C example

ID MSG1='IODF29',MSG2='SYS6.IODF29 - 2008-10-08 12:04', * SYSTEM=(2098,1),LSYSTEM=SCZP202, * TOK=('SCZP202',00800006991E2094120450420108282F00000000,* 00000000,'08-10-08','12:04:50','SYS6','IODF29') RESOURCE PARTITION=((CSS(0),(A01,1),(*,2),(*,3),(*,4),(*,5),(** ,6),(*,7),(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F* )),(CSS(1),(A11,1),(A12,2),(*,3),(*,4),(*,5),(*,6),(*,7)* ,(*,8),(*,9),(*,A),(*,B),(*,C),(*,D),(*,E),(*,F))) CHPID PATH=(CSS(0),0C),SHARED,PARTITION=((A01),(=)),PCHID=230,* TYPE=OSE CNTLUNIT CUNUMBR=2E40,PATH=((CSS(0),0C)),UNIT=OSA IODEVICE ADDRESS=(2E40,031),UNITADD=00,CUNUMBR=(2E40),UNIT=OSAIODEVICE ADDRESS=2E5F,UNITADD=FE,CUNUMBR=(2E40),UNIT=OSAD

Displaying the default OATAlthough 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.




java IOAJAVA


2. In the Workstation Interface window, in the right panel under OSA/SF Commands, select CHPID View and select the CHPID, in our case 0C.

Appendix F. TCP/IP Passthru mode 253

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

Figure F-2 CHPID View Object

a. On the Settings tab (Figure F-3), you see that the CHPID is TCP/IP Passthru (OSE), online, shared, and the processor code level is displayed (07.07).

Figure F-3 Settings: CHPID 0C


b. Select the Performance tab. As shown in Figure F-4, you see performance data, like PCI bus utilization for all partitions that share the CHPID.

Figure F-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 F-5.

Figure F-5 Device information


5. Again return to the CHPID View window. This time click Selected Open OAT Information.

As shown in Figure F-6, you see image A01 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 F-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.

Customizing z/OS TCP/IPDefinitions are required in TCP/IP for the OSA-Express3 1000BASE-T in TCP/IP Passthru mode. For Passthru mode, you define one LINK statement for its related 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.


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

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

TCP/IP definitionsThe 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.

192.168.4.3HOME IP

DEVICE2E40,2E41

OSA/SF"FE" DEVICE

2E5F

LPAR

TCP/IP

A

00-01

CHPID 0C

100 Mbps

OSAD, UA FE

Ethernet Switch

Note: If you are using a OSA-Express3 1000 BASE-T multi-port card with two ports per CHPID, the port number specified on the LINK statement must relate to your OSA port, i.e. port 0 or port1


� A HOME IP address (in our example, we used IP address 192.168.4.3.

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

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 F-8 shows the TCP/IP profile definitions that we used to define OSA to TCP/IP A.

Figure F-8 TCP/IP profile definitions

ActivationActivation may require several tasks, such as:

� Ensuring that the devices are online� Activating an OSA/SF configuration� Activating VTAM resources� Activating TCP/IP

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.

DEVICE OSA2E40 LCS 2E40 LINK OSA2E40LNK ETHERNET 0 OSA2E40

HOME 192.168.4.3 OSA2E40LNK

BEGINROUTES ROUTE 192.168.4.0/24 = OSA2E40LNK MTU 1492 ENDROUTES START OSA2E40


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.

Verifying that devices are onlineTo verify that the required devices are online, enter the z/OS console display command:

D U,,,2E40,2IEE457I 11.08.20 UNIT STATUS 632 UNIT TYPE STATUS VOLSER VOLSTATE 2E40 OSA A-BSY 2E41 OSA A

If the devices are not online, enter the z/OS console VARY command:

V (2E40-2E41),ONLINE

Activating TCP/IPThere are three ways to make the added definitions to the TCP/IP profile effective.

� 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,TCPIPA,START,OSA2E40

We confirm the status of the TCP/IP devices using the NETSTAT DEV command as shown in Figure F-9 on page 260. Note that both the device and the link are in READY status.


Figure F-9 TCP/IP device, link status and statistics

For a summary of related commands, refer to Appendix D, “Useful commands” on page 235.

DEVNAME: OSA2E40 DEVTYPE: LCS DEVNUM: 2E40 DEVSTATUS: READY LNKNAME: OSA2E40LNK LNKTYPE: ETH LNKSTATUS: READY NETNUM: 0 QUESIZE: 0 IPBROADCASTCAPABILITY: YES MACADDRESS: 00145E74A950 ACTMTU: 1500 SECCLASS: 255 MONSYSPLEX: NO BSD ROUTING PARAMETERS: MTU SIZE: N/A METRIC: 00 DESTADDR: 0.0.0.0 SUBNETMASK: 255.255.255.0 MULTICAST SPECIFIC: MULTICAST CAPABILITY: YES GROUP REFCNT SRCFLTMD ----- ------ -------- 224.0.0.1 0000000001 EXCLUDE SRCADDR: NONE LINK STATISTICS: BYTESIN = 1536 INBOUND PACKETS = 24 INBOUND PACKETS IN ERROR = 0 INBOUND PACKETS DISCARDED = 0 INBOUND PACKETS WITH NO PROTOCOL = 0 BYTESOUT = 1536 OUTBOUND PACKETS = 24 OUTBOUND PACKETS IN ERROR = 0 OUTBOUND PACKETS DISCARDED = 2


Appendix G. Sample definitions

This appendix lists sample definitions for TCP/IP in various operating systems environments. It also includes VTAM definitions used in z/OS.

G


Sample environmentFigure G-1 is a logical representation of the environment used for the definition examples.

Figure G-1 Our hardware environment

z/OS definitionsThis section includes examples of the definitions that we used in our z/OS logical partitions (LPARs), starting with a diagram showing our ITSO lab environment from a z/OS perspective.

PCHID 231C HPID 0BO SD2D80 - 2D8FPort 0 Port 1

PCHID 1C1CHPID 0AO SDE200 - E20FPort 0 Port 1

LPARSC81

SCZP202

LCSS 0 LCSS1

LPARVM LINUX3

VM V5R4z/OS

V1R10

Ethernet Switch

PCHID 230CHPID 0CO SE2E40 - 2E4FPort 0 Port 1


Figure 11-9 Our z/OS environment

TCP/IP profilesThe TCP/IP profile for SC64 (Example G-1) only shows the lines that we added or changed.

Example: G-1 Profile of TCPIP A

ARPAGE 20 GLOBALCONFIG NOTCPIPSTATISTICS IPCONFIG NODATAGRAMFWD SYSPLEXROUTING SOMAXCONN 10 TCPCONFIG TCPSENDBFRSIZE 64K TCPRCVBUFRSIZE 64K SENDGARBAGE FALSE TCPCONFIG UNRESTRICTLOWPORTS UDPCONFIG UNRESTRICTLOWPORTS ; ; STATIC VIPA DEFINITIONS DEVICE VIPAA VIRTUAL 0 LINK VLINK1 VIRTUAL 0 VIPAA DEVICE VIPAB VIRTUAL 0 LINK VLINK2 VIRTUAL 0 VIPAB ; ; OSA DEFINITIONS FOR LCS TCPIP PATHTHRU PORT 0 DEVICE OSA2E40 LCS 2E40 LINK OSA2E40LNK ETHERNET 0 OSA2E40 ; ; OSA DEFINITIONS FOR LCS TCPIP PATHTHRU PORT 1 DEVICE OSA2E42 LCS 2E42 LINK OSA2E42LNK ETHERNET 1 OSA2E42 ; ; OSA DEFINITIONS QDIO 'CLASSIC'

.




z/OS z/OS

VTAM VTAM

TCP/IP A TCP/IP B

192.168.3.64

OSAE200 OSA2D84

E200-E20F 2D80-2D8F

OSAE204 OSA2D84

OSAE200 OSAE204

Device Number

IP Address

Device

TRLE

Portname

OSAnameOSA2D80 OSA2D84

CHPID 0A CHPID 0B

Ethernet Switch

192.168.1.65

OSAE204


192.168.3.4 192.168.1.5

OSA2D80

OSAE200 OSA2D80

Appendix G. Sample definitions 263

DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VLANID 980 VMAC 020012345678 ; INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.65/24 MTU 1492 MTU 1492 VLANID 981 VMAC ROUTEALL ; INTERFACE OSAE205I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK2 IPADDR 192.168.2.65/24 MTU 1492 VLANID 982 VMAC ROUTEALL ; HOME 192.168.1.164 VLINK1 192.168.2.164 VLINK2 192.168.3.64 OSAE200LNK 192.168.4.3 OSA2E40LNK 192.168.4.4 OSA2E42LNK ; BEGINROUTES ROUTE 192.168.3.0/24 = OSAE200LNK MTU 1492 ROUTE 192.168.1.0/24 = OSAE204I MTU 1492 ROUTE 192.168.2.0/24 = OSAE205I MTU 1492 ROUTE 192.168.4.0/24 = OSA2E40LNK MTU 1492 ROUTE 192.168.4.0/24 = OSA2E42LNK MTU 1492 ENDROUTES ; START OSAE200 START OSAE204I START OSAE205I START OSA2E40 START OSA2E42


The TCP/IP profile for SC65 (Example G-2) shows only the lines that we added or changed.

Example: G-2 Profile TCPIP B

ARPAGE 20 GLOBALCONFIG NOTCPIPSTATISTICS IPCONFIG NODATAGRAMFWD SYSPLEXROUTING SOMAXCONN 10 TCPCONFIG TCPSENDBFRSIZE 64K TCPRCVBUFRSIZE 64K SENDGARBAGE FALSE TCPCONFIG UNRESTRICTLOWPORTS UDPCONFIG UNRESTRICTLOWPORTS ; ; STATIC VIPA DEFINITIONS DEVICE VIPAA VIRTUAL 0 LINK VLINK1 VIRTUAL 0 VIPAA ; ; OSA DEFINITIONS DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET OSAE200 VMAC 020087654321 ; INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.5/24 MTU 1492 VMAC ROUTEALL ; HOME 192.168.1.165 VLINK1 192.168.3.4 OSAE200LNK ; BEGINROUTES ROUTE 192.168.3.0/24 = OSAE200LNK MTU 1492 ROUTE 192.168.1.0/24 = OSAE204I MTU 1492 ENDROUTES ; START OSAE200 START OSAE204I

VTAM definitionsThis section presents examples of VTAM definitions used for OSD and Enterprise Extender.

VTAM TRL definitionsWe used the same TRLs in both SC64 and SC65.

Example: G-3 TRL for CHPID 0A - OSA 1000BASE-T Port 0

* * QDIO TRLE FOR OSA-EXPRESS3 CHPID 0A PORT 0 * OSAE200 VBUILD TYPE=TRL OSAE200P TRLE LNCTL=MPC, READ=E200, WRITE=E201,

Note: TRLs are built dynamically for HiperSockets.


DATAPATH=(E202,E203), PORTNAME=OSAE200, PORTNUM=0, MPCLEVEL=QDIO

Example 11-42 TRL for CHPID 0A - OSA 1000BASE-T Port 1

* * QDIO TRLE FOR OSA-EXPRESS3 CHPID 0A PORT 1 * OSAE204 VBUILD TYPE=TRL OSAE204P TRLE LNCTL=MPC, READ=E204, WRITE=E205, DATAPATH=(E206,E207,E208,E209), PORTNAME=OSAE204, PORTNUM=1, MPCLEVEL=QDIO

Example: G-4 XCA Majornode XCAOSAX3 - used for our non-QDIO configuration

XCAOSA VBUILD TYPE=XCA OSAX3 PORT MEDIUM=CSMACD, X ADAPNO=0, X CUADDR=2E4A, X TIMER=60, X SAPADDR=04 *********************************************************************** OSAX3G GROUP DIAL=YES, X DYNPU=YES, X ANSWER=ON, X AUTOGEN=(3,L,P), X CALL=INOUT, X ISTATUS=ACTIVE

Example 11-43 Switched Majornode - used for our non-QDIO configuration

VBUILD TYPE=SWNET OSASW 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 OSASWL0 LU LOCADDR=0,MODETAB=MTAPPC,DLOGMOD=APPCMODE OSASWL1 LU LOCADDR=1 3270 SESSIONS OSASWL2 LU LOCADDR=2


z/VM TCP/IP profileThe TCP/IP profile in Example G-5 shows only the statements that are related to Open Systems Adapter-Express (OSA-Express) and HiperSockets.

Example: G-5 Sample z/VM TCP/IP profile

DEVICE OSA2188 OSD 2188 PORTNAME OSA2180 ; OSD Fast Ethernet devices on CHPID 09LINK OSA2188L QDIOETHERNET OSA2188 ; DEVICE HIPERDEF HIPERS 7300 PORTNAME HIPERPEF ; HiperSockets CHPID EFLINK 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


Appendix H. ARP takeover

This appendix describes Address Resolution Protocol (ARP) takeover, the definition requirements, and verification procedures.

H


ARP takeover descriptionARP takeover is a mechanism that allows traffic to be redirected from a failing Open Systems Adapter (OSA) connection to another OSA connection. When TCP/IP is started, all of the IP addresses for devices defined as connecting to an OSA port in QDIO mode (device type MPCIPA in the TCP/IP profile) are dynamically downloaded to the OSA. If the OSA 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 maintains the ARP table for all of the IP addresses to which it is connected. Maintaining the ARP table within the OSA 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.

� The TCP/IP profile must be defined properly.

Figure H-1 illustrates our test environment for ARP takeover. We defined CHPID 09 and 0B as OSD-type CHPIDs.

Figure H-1 Test environment before ARP takeover

zSeries CEC

TCPIPD

192.168.1.10

C : \ ping 192.168.1.64

CHPID 09

OAT192.168.1.4

192.168.1.64

CHPID 0BOAT192.168.1..64

192.168.1.4MAC ADDR 6296CA5BC MAC ADDR

6296C3690

z/OS -SC64

SWITCH

Before ARP Takeover


ARP takeover definitionsWe updated the TCP/IP profile to support ARP takeover. We also modified the our switch configuration to support ARP takeover.

TCP/IP definitionsExample H-1 shows the items that we changed or added in our TCP/IP profile for ARP takeover support.

Example: H-1 SC64 TCP/IP profile

IPCONFIG MULTIPATH IQDIOR DATAGRAMFWD

DEVICE OSA2180 MPCIPA ; OSD Devices on CHPID 09 LINK SC642180LINK IPAQENET OSA2180

DEVICE OSA2360 MPCIPA ; OSD 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 1492ENDROUTES

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 ports that we will switch between for the test. Notice the ROUTE statements that define two paths to get to the same network.

Ethernet switch definitionsWe used the 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 H-2 shows an example of executing the command.

Example: H-2 Set port host

6500-top> (enable) set port host 1/1Jan 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 toa single host. Connecting hubs, concentrators, switches, bridges, etc. to afast 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 H. ARP takeover 271

Verifying ARP takeover

We verified that ARP takeover worked by performing two different tasks:

� Pulling the CAT5 cable from the OSA port

� Stopping the device in the TCP/IP stack

Pulling the CAT5 cableFigure H-2 shows our environment after pulling the CAT5 cable, and the route that the ping takes as a result of this.

Figure H-2 Test environment after pulling the CAT5 cable

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

Figure H-3 Windows workstation APR cache (normal)

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.

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

zSeries CEC

TCPIPD

192.168.1.10

C : \ ping 192.168.1.64

CHPID 09

OAT192.168.1.4

192.168.1.64

CHPID 0BOAT192.168.1..64

192.168.1.4MAC ADDR 6296CA5BC MAC ADDR

6296C3690

z/OS -SC64

SWITCH

After ARP Takeover


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 H-4 shows the contents of the ARP table from the OSA before any error condition was introduced.

Figure H-4 ARP table from SC64 TCPIPD (normal)

We pulled the CAT5 cable that connects the OSA port of CHPID 09 from the switch. Figure H-5 shows the resulting messages from the z/OS console.

Figure H-5 z/OS console messages after pulling CHPID 09 CAT5 cable

Figure H-6 shows the contents of the ARP cache of the workstation after pulling the cable for CHPID 09.

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

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

EZZ4329I LINK SC642360LINK HAS TAKEN OVER ARP RESPONSIBILITY FOR INACTIVE LINK SC642180LINK EZZ4311I LINK SC642180LINK HAS FAILED ON DEVICE OSA2180

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 H-7 shows the contents of the ARP table on z/OS immediately after pulling the CAT5 cable for CHPID 09.

Figure H-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 H-8.

Figure H-8 z/OS TCP/IP ARP table minutes after CAT5 cable for CHPID 09 pulled

Then we cleaned up the ARP table with the purgecache command available in z/OS 1.4. Figure H-9 shows an example of the command.

Figure H-9 z/OS PURGECACHE command

When the CAT5 cable was plugged back into the switch, we received the messages shown in Figure H-10 at the z/OS operator’s console.

Figure H-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

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

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

V TCPIP,TCPIPD,PURGECACHE,SC642180LINK EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,PURGECACHE,SC642180LINKEZZ9786I PURGECACHE PROCESSED FOR LINK SC642180LINK EZZ0053I COMMAND PURGECACHE COMPLETED SUCCESSFULLY

EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180


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 stackIn this test, we created an error condition by stopping the device in the TCP/IP stack. Figure H-11 shows the command that was issued and the resulting messages.

Figure H-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 H-6 and Figure H-7.

We started the device again, as shown in Figure H-12.

Figure H-12 Starting the device in TCPIPD

Once again, the gratuitous ARP was sent to update existing ARP cache entries to the correct MAC addresses.

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

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


Appendix I. HiperSockets Accelerator

This appendix provides a description of HiperSockets Accelerator, definition requirements, and verification procedures.

I


HiperSockets Accelerator descriptionHiperSockets Accelerator allows a z/OS TCP/IP router stack to efficiently route IP packets from an OSA (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 (QDIO) to HiperSockets (iQDIO), and from HiperSockets (iQDIO) to OSA (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.

Figure I-1 shows our network configuration and the HiperSockets Accelerator flow.

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 I-1 HiperSockets Accelerator flow

HiperSockets definitionsImplementation of HiperSockets Accelerator is quite simple as indicated by our sample TCP/IP profile in Example I-1.

Example: I-1 TCP/IP Profile for HiperSockets Accelerator

IPCONFIG IQDIOR DATAGRAMFWD

DEVICE OSA2180 MPCIPA PRIRouter ; OSD 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

TCPIPD

AcceleratedQDIO - iQDIO routing

OSA-Express CHPID 09

CHPID EF HiperSockets iQDIO LAN

zSeries CEC

VTAM

External LAN

Linux 2TCP/IP

QDIO Device Driver

iQDIO Device Driver

192.168.1.64

192.168.1.10

10.10.1.64

10.10.1.60

C:\ ping 10.10.1.60

Appendix I. HiperSockets Accelerator 279

The profile in Example I-1 allows us to use the HiperSockets Accelerator to connect between the OSA on CHPID 09 and HiperSockets on CHPID EF.

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 AcceleratorWe 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 I-2, which confirmed that HiperSockets Accelerator was enabled.

Figure I-2 Message when starting TCP/IP

Next, we looked at the active TCP/IP configuration as shown in Figure I-3.

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

Figure I-4 HiperSockets TRLE

Note: HiperSockets must be defined in the IOCDS as CHPID type IQD.

EZZ0688I IQDIO ROUTING IS ENABLED

D TCPIP,TCPIPD,N,CONFIG EZD0101I NETSTAT CS V1R4 TCPIPD 841 TCP CONFIGURATION TABLE: DEFAULTRCVBUFSIZE: 00016384 DEFAULTSNDBUFSIZE: 00016384...IQDIOROUTE: YES QDIOPRIORITY: 1

D NET,TRL,TRLE=IUTIQDEF IST097I DISPLAY ACCEPTED IST075I NAME = IUTIQDEF, TYPE = TRLE 881 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE IST1716I PORTNAME = LINKNUM = 0 OSA CODE LEVEL = D3GFIST1577I 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


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 port and the IP network on the HiperSockets CHPID. Figure I-5 shows the HiperSockets routing table before any communication has taken place.

Figure I-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 I-6.

Figure I-6 Adding an indirect route to the workstation

The -p in Figure I-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 I-7 shows the results.

Figure I-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 I-5.

For more implementation information about HiperSockets and HiperSockets Accelerator, refer to HiperSockets Implementation Guide, SG24-6816.

D TCPIP,TCPIPD,N,ROUTE,IQDIO EZD0101I NETSTAT CS V1R4 TCPIPD 874 IPV4 DESTINATIONS DESTINATION GATEWAY INTERFACE 0 OF 0 RECORDS DISPLAYED

ROUTE ADD 10.10.1.0 MASK 255.255.255.0 192.168.1.64 -p

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

Appendix I. HiperSockets Accelerator 281

Appendix J. RMF in an OSA environment

Resource Measurement Facility (RMF) in z/OS 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 (OSA). It also provides statistics about the bus utilization and the transfer rate for both the read and write operations in the Channel Activity Report.

J


RMF for OSA RMF reports that are associated with OSA 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 CHPIDs (device types OSD and OSE), performance information is provided for three main components:

� 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 channel types.

RMF Monitor II outputThe support for OSA 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 ReportTo view the OSA channel activity, complete these steps:

1. In the TSO ISPF Primary Option Menu, enter 6 (Command).

2. In the TSO ISPF Command Shell, enter RMFMON 2, and then press Enter.

3. In the RMF Display Menu, press F4.


Figure J-1 shows an example of the Channel Activity Report.

Figure J-1 Channel Activity Report

4. To exit the report, enter QUIT.

For more information, see z/OS Resource Measurement Facility Report Analysis, SC33-7991.

16:42:43 CHANNEL UTILIZATION(%) READ(B/S) WRITE(B/S) MSG MSG SEND RECVID NO G TYPE S PART TOT BUS PART TOT PART TOT RATE SIZE FAIL FAIL08 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

Appendix J. RMF in an OSA environment 285

Appendix K. Authorization

This appendix discusses the topics regarding the authorization commands used in the z/VM-related chapters.

K


z/VM virtual switch authorizationYou can restrict the access to the virtual switch function of z/VM, using native Control Program (CP) security or an ESM.

Figure K-1 shows the authorization flow of the COUPLE logic.

Figure K-1 Authorization flow for COUPLE logic

Running with CP authorizationIf 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 K-1 shows the valid syntax for this command.

Example: K-1 SET VSWITCH command syntax

--------------------------------------------!-PORTType-defporttype-! !-VLAN-defvid-!>>--SET VSWITCH-switchname--.-GRAnt--userid-+----------------------+-+-------------+-->< ! ! ! ! <------<! ! '-PORTType---ACCESS----' '-VLAN-vlanid-' ! '-TRUNK------' !-REVoke--userid-----------------------! ! <-------------< ! ! (1) ! !-PORTname----portname-----------------!

Important: If an ESM is in place, the security definitions made by the SET VSWITCH command are overridden by the ESM definitions.

ProtectedResource

?

AuthorizeConnection

?

COUPLESPECIALNICDEF

ESMInstalled

?

AuthorizeConnection

?

ConnectionDenied

ConnectionPermitted

CPACCESS

LISTESM

YES NO

NO

YES

YES

NO NO

YES


! <---------< ! ! (2) ! !-RDEV--.---rdev------.----------------! ! '-NONE--------' ! !-CONnect------------------------------! !-DISCONnect---------------------------! !-QUEuestorage--numberM----------------! !-CONTRoller--.-*-------.--------------! ! '-userid1-' ! !-IPTimeout--nnn-----------------------! !-NONrouter----------------------------! !-PRIrouter----------------------------' '-ISOLAtion--.-OFF-.-------------------! '-ON--'

To check who has access to a virtual switch, use the QUERY VSWITCH command with the ACCESS option. In Example K-2, you can see the authorized list of user IDs that can connect to L2SW1.

Example: K-2 Query of the authorization list for L2SW1

QUERY VSWITCH L2SW1 ACC VSWITCH SYSTEM L2SW1 Type: VSWITCH Connected: 2 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Aware Default VLAN: 0010 Default Porttype: Trunk GVRP: Enabled Native VLAN: 0010 VLAN Counters: OFF MAC address: 02-00-00-00-00-02 State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Authorized userids: LNXRH5 Porttype: Trunk VLAN: 0980-0982 LNXSU10 Porttype: Trunk VLAN: 0980-0982 SYSTEM Porttype: Trunk VLAN: 0010 RDEV: E200.P00 VDEV: E200 Controller: DTCVSW2 RDEV: 2D80.P00 VDEV: 2D80 Controller: DTCVSW1 BACKUP Ready; T=0.01/0.01 15:03:48

To grant access to a virtual switch, use the SET VSWITCH GRANT command (see Example K-3).

Example: K-3 Granting access to L2SW1

SET VSWITCH L2SW1 GRANT LNXSU10Command complete Ready; T=0.01/0.01 11:32:59

If you want to prevent a user from connecting to a virtual switch, use the SET VSWITCH REVOKE command (see Example K-4).

Example: K-4 Revoking access to L2SW1

SET VSWITCH L2SW1 REVOKE LNXSU10Command 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 connect.

Appendix K. Authorization 289

Running with RACF authorizationSince z/VM 5.1, an additional resource class, called VMLAN, is available. This class is used to protect the COUPLE function to virtual switches and VLANs. To establish RACF security for virtual switch, you must perform the following actions on your system:

1. Define profiles for each virtual switch2. Permit access for guest systems3. Activate the VMLAN class

Defining profiles for each virtual switchTo protect a virtual switch via RACF, it is important to define a RACF profile for each virtual switch in your system. Example K-5 shows our definition for the virtual switch called L2SW1.

Example: K-5 Defining a RACF profile for a virtual switch

RAC RDEFINE VMLAN SYSTEM.L2SW1 UACC(NONE)

Furthermore, you can restrict access to a virtual switch being used with VLANs. In Example K-5, we define a RACF profile for virtual switch L2SW1 and VLAN ID 0001. This means that the only virtual guest machines can connect to VLAN ID 0001 must have at least a permission UPDATE for the profile shown in Example K-6.

Example: K-6 Defining a RACF profile for VLAN restrictions

RAC RDEFINE VMLAN SYSTEM.L2SW1.0001 UACC(NONE)Ready; T=0.01/0.01 15:18:43

Permitting access to guest systemsTo allow a guest system to establish a connection to a virtual switch, you must grant RACF permission to the appropriate profile. In our environment, the guest system connected to virtual switch L2SW1. Example K-7 shows the appropriate RACF command.

Example: K-7 Permitting access to a virtual switch

RAC PERMIT SYSTEM.L2SW1 CLASS(VMLAN) ACCESS(UPDATE) ID(LNXSU10)Ready; T=0.01/0.01 13:34:47

Once the RACF permission 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 K-8.

Example: K-8 Failed access to a virtual switch

couple c204 system L2SW1 HCPNDF6011E You are not authorized to COUPLE to SYSTEM L2SW1Ready(06011); T=0.01/0.01 08:25:51

If you want to revoke user access to a virtual switch, use the command shown in Example K-9.

Example: K-9 Revoking access to a virtual switch

Important: If you do not have a profile for your virtual switch, the CP ACCESS LIST determines the access. See “Running with CP authorization” on page 288, for more information.


RAC PERMIT SYSTEM.L2SW1 CLASS(VMLAN) ACCESS(UPDATE) ID(LNXSU10) DELETEReady; T=0.01/0.01 13:34:47

Activating the RACF VMLAN classAfter you define the RACF profile for your virtual switch, you must activate the RACF class (VMLAN). Example K-10 shows the activation command.

Example: K-10 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.

Appendix K. Authorization 291

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 RedbooksFor information about ordering these publications, see “How to get IBM Redbooks” on page 294. Note that some of the documents referenced here may be available in softcopy only.

� IBM Communication Controller for Linux on System z V1.2.1 Implementation Guide, SG24-7223

� Enterprise Extender Implementation Guide, SG24-7359

� IBM System z Connectivity Handbook, SG24-5444

� OSA-Express Integrated Console Controller Implementation Guide, SG24-6364

� IBM System z10 Enterprise Class Technical Guide, SG24-7516

� IBM System z10 Enterprise Class Technical Introduction, SG24-7515

Other publicationsThese publications are also relevant as further information sources:

� Open Systems Adapter-Express Customer's Guide and Reference, SA22-7935

� Resource Measurement Facility Report Analysis, SC28-1950

� Communications Server: IP Systems Administration Commands, SC31-8781

� Communications Server: IP Configuration Guide, SC31-8775

� Communications Server: IP Configuration Reference, SC31-8776

� Communications Server SNA Resource Definition Reference, SC31-8778

� Communications Server: SNA Network Implementation Guide, SC31-8563

� Communications Server: IPv6 Network and Application Design Guide, SC31-8885

� z/VM Connectivity Version 5, SC24-6080

� z/VM CP Commands and Utilities Reference, SC24-6081

� z/VM TCP/IP User’s Guide, SC24-6020

� z/VM TCP/IP Planning and Customization, SC24-6019

Online resourcesThese Web sites and URLs are also relevant as further information sources:

� System z Networking

http://www.ibm.com/servers/eserver/zseries/networking/




� System z Networking white papers

http://www.ibm.com/servers/eserver/zseries/networking/wpapers.html

� z/VM virtual networking

http://www.vm.ibm.com/virtualnetwork/

� IBM Resource Link

http://www.ibm.com/servers/resourcelink/

How to get IBM RedbooksYou 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 IBMIBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services




http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

http://www.ibm.com/servers/eserver/zseries/networking/wpapers.html

http://www.ibm.com/servers/resourcelink/

http://www.vm.ibm.com/virtualnetwork/

Index

Numerics50.0 micron 190, 19462.5 micron 190, 194802.1Q 1328021q.o module 145

Aaccess list 40

VSWITCH 162Access mode 133access port 133advanced facilities 219APPC 49APPCOSA 49APPCPMxx 49ARP

offload 16statistics 16takeover 16, 269

ARP cache 236, 272existing entries 275

ARP table 270MAC addresses 274

availabilityIP 16

BBEGINROUTES statement 102, 118, 258

static routes 258broadcast

in VLAN 134broadcast support 15

Ccandidate list 40CAT5 cable 272Channel Activity Report 284channel on/off 229Channel Path

List panel 38, 40Measurement Facility 284window 39

channel path 39definition 37

channel path identifier (CHPID) 35checksum 17CHPID 68, 78, 219, 242

On/Off 229CHPID 09 270, 279

Fast Ethernet port 273OSA-Express card 280

CHPID 0B 271

© Copyright IBM Corp. 1999, 2001, 2002, 2003, 2005, 2006, 2

CHPID number 59, 236command

Linux for System z TCP/IP 240Linux z/VM Virtual Switch 239TCP/IP for z/VM 238TCP/IP operations for z/VM 238TSO 237z/OS 236, 288z/VM 238z/VM Virtual Switch 239

component trace 217configuration name 89, 246Control Program (CP) 153control unit 35, 68, 78, 87, 108, 252

definition 40controller 161CTIEZB00 217CTRACE 217CTRACE command 213

Ddata router 5datapath 42DED 39device definition 41device number 42, 71, 99, 101, 115, 117, 257DEVICE OSA2180 MPCIPA PRIRouter 279device type 32, 42, 101, 117, 256device types 28Direct Memory Access 4DIX 190–191, 194–195DMA 4dot3StatsTable 14

EEE 21Enterprise Extender 21Enterprise Extender (EE) 31, 76ESM (External Security Manager) 288Ethernet switch 69, 79, 99, 115, 135, 156, 257

VLAN functionality 157even device number 101, 117external communications adapter (XCA) 99External Security Manager (ESM) 288external writer

file 213

FFast Ethernet (FENET) 31, 242FE,C UNUMBR 253FENET (Fast Ethernet) 31, 242FTP 52

007, 2008, 2009. All rights reserved. 295

GGbE LR 30Get and GetNext request 14grant access

virtual switch 160graphical user interface (GUI) 47gratuitous ARP 273GRE 124guest system 31, 68, 152

network connectivity 158Q NIC DETAILS command 162

Hhardware assists 6Hardware Configuration Definition (HCD) 35–36, 46, 68, 78, 252Hardware Management Console (HMC) 90, 219HCD (Hardware Configuration Definition) 35–37, 46, 68, 78, 252HiperSockets Accelerator 277HMC (Hardware Management Console) 219HPDT ATM 7HPDT MPC 7HPR 21hybrid mode 133

IIEEE 802.1q

VLANs 132inbound packet 135installing OSA/SF 47Internet Protocol Assist (IPA) 6IOAENTR 242IOAOSHRA 242IOAOSHRS 242IOAOSHRT 242IOCDS 35, 46, 252, 280IOCP

definition 87, 108IP address 53, 153, 170, 243, 256, 270, 280

192.16.1.20 101, 117192.16.1.24 91, 258conflict 170

IP assist 6IP router 134IPCONFIG IQDIOR 278IPv6 address 258IPv6 support 10iQDIO 278IST075I Name 280IST097I Display 280IST486I Status 280

LLAN Channel Station (LCS) 14, 99, 252large send 11Layer 2 157Layer 2 support 18, 31, 151

LCS device 99, 256link aggregation 19, 156–157LINK statement 271

parameter VLAN 148port number 257

Linuxcommands for TCP/IP 240VLAN support 145

Linux guest 147, 281VLAN support 170

locally administered address (LAA) 90logical partition 31, 47, 86, 109, 231, 243

LP number 91OSA-Express port 94

LP number 91LPAR 91, 229, 251LP-to-LP communication 6

MMAC 16MAC address 8, 56, 89–90, 98, 220, 273

ARP cache 274byte ID prefix 153of defined OSA-Express port 90same IP address 274

major node 70, 99, 115, 141, 237Management Information Base (MIB) 14Maximum IP addresses per OAT 8Maximum IP stacks and devices 8Maximum number of MAC addresses 8Maximum TCP/IP stacks and devices 8microcode 228MIF 28Missing Interrupt Handler (MIH) 68, 78mode conditioner patch (MCP) 190, 194modes of operation 3MTU size 278multicast support 15multiple IP addresses 270multiple TCP/IP stack 135

NNAT 124network interface card (NIC) 160, 239networking, policy-based 32NIC (network interface card) 160, 239NICDEF 160NICDEF statement 153non-QDIO 2–3non-QDIO mode 29, 48, 85, 107, 241, 270

default IP 48NONRouter 125non-shared mode 251

OOAT

dynamic 5OAT (OSA Address Table) 228, 242


OAT default status display 259Open Systems Adapter for NCP (OSA for NCP) 22Open Systems Adapter Support Facility (OSA/SF) 3, 47, 85, 107OSA

default mode 252OSA Address Table (OAT) 86, 109, 228, 242, 252OSA CHPID 108OSA configuration 96, 242

file 97, 246OSA device 68, 78, 87, 108, 153, 238, 243, 252

Display status 238OSA feature 89, 244

active sessions 244OSA port 86, 94, 109, 243, 252

MAC address 98OSA/SF 3, 9, 29, 220

GUI setup 51profile 50REXX 47set up 50TCP/IP 50

OSA/SF GUI 47, 51, 87, 253and very useful function 62code 52OSA feature configuration 87program 88, 253TCP/IP connection 53

OSA/SF hostsystem 53

OSA/SF REXX command interface 109OSAD 28, 49OSAD device 43, 86, 109, 244

unit address FE 44OSAENTA 198OSA-Express 2

cabling requirements 189channel on/off 229MAC address of defined port 90Network Traffic Analyzer 7Port 257

OSA-Express 1000BASE-Tsettings 192–193, 195

OSA-Express Address Table (OAT) 137OSA-Express ATM CHPID 245OSA-Express card 101, 270, 280

ARP table 270IP network 281

OSA-Express CHPID 28, 87, 229, 252new support 284

OSA-Express connection 138, 173, 270Ethernet switch ports 173trunk port 138

OSA-Express device 153OSA-Express devices 28OSA-Express Ethernet

feature 131OSA-Express feature 28, 35, 47, 67, 71, 77, 85, 89, 107, 136, 241

CAT5 cable 272

MAC address 90network connectivity 67, 77

OSA-Express port 28, 135active session 96DEVICE statement 101, 117Ethernet frame 152Ethernet LAN 99, 115HOME IP address 101, 118MAC address 98trunk mode 168

OSA-Express2 210 Gigabit Ethernet Long Reach (10 GbE LR) feature 1941000BASE-T 191concurrent LIC update 6features 189Gigabit Ethernet short wavelength 194

OSA-Express2 Gigabit Ethernet long wavelength 191OSC 2, 39OSD 2, 39OSE 2, 39, 85, 107

activation 258SNA definition 93switched major node 100, 117TCP/IP definitions 91TCP/IP profile 258VTAM setup 99, 115

OSN 2

PPAGENT 32permanent definitions 165physical channel identifier (PCHID) 35Physical Unit (PU) 99, 115policy-based networking 32Port isolation 156–157port number 101, 117, 243, 257ports

disable 225enable 225status 225

Preventive Service Planning (PSP) 125primary/secondary router function 10priority queuing 5PRIRouter 125pull-down menu 221

select CHPIDs 230Task List 230

purge ARP 16PVC (permanent virtual circuit)

name 248

QQDIO 2–3

Diagnostic Synchronization 7status displays 74, 82TCP/IP definitions 72, 80TCP/IP profile 72, 80TRLE 70, 141

Index 297

VTAM definitions 70, 141QDIO functions 6QDIO mode 48, 67, 77, 85, 107, 131, 152, 155, 270

OSA-Express feature 270OSA-Express port 139

QDIO priorities 8QDIO versus non-QDIO 3query ARP 16QUERY VSWITCH

command 164Detail 239name Access 239

RRACF

authorization 290profile 290security 290

Redbooks Web site 294Contact us xii

Resource Measurement Facility (RMF) 283REXX 241RMF (Resource Measurement Facility) 283RMF for OSA-Express 284RMF Monitor II output 284

SS/390 Open Systems Adapter-Express 2SE 219SECRouter 125shared port 94

activation 102, 118HCD 87, 108OSA/SF definitions 88, 253status displays 103, 119TCP/IP definitions 101, 117VTAM definitions 99, 115

SHR 39Simple Network Management Protocol (SNMP) 14SNA

mode 7QDIO 76

SNA application 76, 99, 115SNA traffic 76, 90SPAN 39Spanning 28startup profile 246static route 102, 118Support Element (SE) 219switched major node 100, 117System z server 36, 219, 252System z9 2, 35

Ttagged frames 134TCP/IP 48, 135, 236, 270, 278

network interfaces 238TCP/IP definition 32, 257

TCP/IP device 74, 82, 103, 119, 237, 257, 259TCP/IP Passthru 7TCP/IP profile 71, 101, 117, 256, 263, 270, 278

device type LCS 270device type MPCIPA 270IQDIORouting option 278OSA device 102, 118

TCP/IP stack 31configured VLAN IDs 137maximum 39untagged traffic 135

TN3270E Server 21, 76token ring, USE RING 100, 117token-ring configuration file 242trace function 222Transport Resource List (TRL) 70, 141traps and set 14TRLE 68, 71, 237

considerations 70trunk mode 133, 168, 171, 271trunk port 133, 138type of traffic 3

Uunit address 86, 109, 243, 255untagged frames 134USE RING for token ring 100, 117

Vview code level 228VIPA

takeback 10takeover 10

virtual (VMAC) 8Virtual IP address (VIPA) 10virtual MAC (VMAC) 20, 124virtual machine 239Virtual Medium Access Control (VMAC) 123virtual switch 31

controller 153detail information about 239display information about 239Layer 2 functionality 167Layer 2 support 152MAC address 153OSA-Express devices 153RACF profile 290RACF security 290VLAN capabilities 169, 171VLAN connectivity 168

VLAN 131–132, 135, 145design rules 135implementation 138, 145isolation 134

VLAN 200 136VLAN capability 168, 171

virtual switch 168, 171VLAN ID 14, 135, 169

OSA-Express registration process 131


parameter 173tag 133value 135

VLAN ID 1 135VLAN ID virtual switch 168VLAN support 12, 135, 138, 168

GVRP 13Layer 2 virtual switch configuration 167Linux 13z/OS 13z/VM 13

VMAC 124VMLAN 161VSWITCH VSWTCH1

GRA LNXSU1 VLAN 101 170GRA LNXSU2 VLAN 101 170GRANT LNXSU1 160GRANT LNXSU2 160GRANT LNXSU3 160

VTAM commands 237VTAM definition 32, 261VTAM resource 73, 102, 118, 258

XXCA 7XCA (external communications adapter) 99XCA major node 99, 115

Zz/OS 69, 79, 253, 273

VLAN support 138z/VM

TCP/IP command 238TCP/IP operations commands 238

z/VM V5.1 31z/VM Virtual Switch

commands 239Layer 2 support 151

Index 299

(0.5” spine)0.475”<

->0.873”

250 <->

459 pages

OSA-Express Implem

entation Guide

OSA-Express Implem

entation Guide

OSA-Express Implem

entation Guide

OSA-Express Implem

entation Guide

OSA-Express Implem

entation Guide

OSA-Express Implem

entation Guide

®

SG24-5948-05 ISBN 0738432555

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International 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

®


Product, planning, and quick start information

Realistic examples and considerations

Hardware and software setup definitions

This IBMÆ RedbooksÆ publication will help you to install, tailor, and configure the Open Systems Adapter (OSA) features that are available on IBM System z10ô and IBM System z9Æ servers. It focuses on the hardware installation and the software definitions that are needed to provide connectivity to LAN environments. WhitepaperRedpaper WhitepaperRedpaper WhitepaperRedpaper WhitepaperRedpaper It provides information to help you with planning and system setup. It also includes helpful utilities and commands for monitoring and managing the OSA features.The target audience for this document is system engineers, network administrators, and system programmers who will plan for and install OSA features. The reader is expected to have a good understanding of System zÆ hardware, HCD or IOCP, OSA/SF, SNA/APPN, and TCP/IP.

Back cover


