Osa Express - Implemantation Guide - RedBook IBM

Front cover

OSA-Express Implementation Guide Product, planning, and quick start information Realistic examples and considerations Hardware and software setup definitions

Bill White Joerg Haertel Thomas Wienert

ibm.com/redbooks

International Technical Support Organization OSA-Express Implementation Guide April 2009

SG24-5948-05

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

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.

© 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 Schedule Contract with IBM Corp.

Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Chapter 1. OSA overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3 Non-QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.4 OSA addressing support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.5 OSA/SF support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 OSA capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2.1 Virtual IP address (VIPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2.2 Primary/secondary router function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2.3 IPv6 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2.4 Large send for TCP/IP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.5 VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.6 SNMP support for z/OS and Linux on System z . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.7 TCP/IP multicast and broadcast support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2.8 ARP cache management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2.9 IP network availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2.10 Checksum offload support for z/OS and Linux on System z. . . . . . . . . . . . . . . . 17 1.2.11 Layer 2 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.12 QDIO data connection isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.13 Layer 3 VMAC for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.14 Enterprise Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.15 TN3270E Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.16 OSA for NCP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Chapter 2. Quick start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Software support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 OSA definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Modes of operation and addressing support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 OSA/SF requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Quick start tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 OSA function support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Quick start tables for z/OS and z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Policy-based networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25 26 28 29 29 30 30 31 32

Chapter 3. Hardware configuration definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Configuration chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Channel path definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Control unit definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Device definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 36 36 37 40 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Setup requirements and overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Setting up OSA/SF in the z/OS environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Setting up APPC and VTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Setting up OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Communicating with OSA/SF using TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Installing OSA/SF GUI on a workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Checking the hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Checking the software configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Downloading and installing the Java runtime and JavaHelp files . . . . . . . . . . . . . 4.3.4 Downloading the code from z/OS using FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.5 Defining the CLASSPATH environment variable . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.6 Starting the OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Using the OSA/SF GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47 48 48 49 50 50 51 51 51 52 52 52 53 53

Chapter 5. QDIO mode for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 QDIO environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Missing Interrupt Handler for QDIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Defining OSA devices to z/OS Communications Server for QDIO . . . . . . . . . . . . 5.4.2 VTAM definitions (TRL major node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 TCP/IP devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 SNA support for QDIO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67 68 68 68 69 70 70 72 73 73 73 74 74 76

Chapter 6. QDIO mode for z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 QDIO environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Hardware Configuration Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Missing Interrupt Handler for QDIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Customizing the z/VM network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77 78 78 78 79 80 80 81 82 82

Chapter 7. Non-QDIO mode for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.1 Configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 7.2 Hardware definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.3 Creating and activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.3.1 TCP/IP definitions in OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.3.2 SNA definition in OSA/SF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.3.3 Activating the OSA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 7.3.4 Displaying the MAC address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 7.4 Customizing the z/OS network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 7.4.1 VTAM definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 7.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 iv

OSA-Express Implementation Guide

7.5 Activating the connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

102 103 103 103 103

Chapter 8. Non-QDIO mode for z/VM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Hardware definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 OSA configuration and OAT definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Creating and activating our OSA configuration and OAT . . . . . . . . . . . . . . . . . . 8.4 Network definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 VTAM definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.2 TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Activating the connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.1 Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.2 VTAM activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 TCP/IP activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Relevant status displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107 108 108 109 109 115 115 117 118 118 119 119 119

Chapter 9. z/OS VMAC support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Virtual MAC overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Virtual MAC concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.2 Virtual MAC address assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Virtual MAC implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

123 124 124 125 125 127

Chapter 10. VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 VLAN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Types of connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 VLAN tagging basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 General VLAN design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 VLAN configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 Sharing an OSA port with the same VLAN ID. . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 Primary and secondary router support with VLANs . . . . . . . . . . . . . . . . . . . . . 10.2.4 Operating system support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 VLAN support for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 VLAN implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 Configuring OSA with VLAN ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 VLAN support for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 VLAN implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 VLAN support in z/VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.1 z/VM native VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

131 132 132 134 135 136 137 137 138 138 138 139 143 145 145 147 148 148 149

Chapter 11. z/VM virtual switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Virtual switch description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 VSWITCH controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Network interface card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3 VSWITCH capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Our VSWITCH environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Configuring a Layer 2 VSWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

151 152 153 153 154 156 158

Contents

v

11.3.1 Defining the virtual switch environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.2 Authorizing the guest system access to the virtual switch . . . . . . . . . . . . 11.3.3 Connecting the guest systems to the VSWITCH . . . . . . . . . . . . . . . . . . . . . 11.3.4 Verifying the virtual switch configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.5 Setting up Layer 2 for the guest systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.6 Creating definitions for Layer 2 support - SUSE and Red Hat . . . . . . . . . . . . . 11.3.7 Making permanent device and network definitions . . . . . . . . . . . . . . . . . . . . . . 11.4 Configuring VLAN support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.1 Defining VLAN capabilities to the virtual switch . . . . . . . . . . . . . . . . . . . . . . . . 11.4.2 Authorizing Linux guests access to the virtual switch with VLAN IDs . . . . . . . . 11.4.3 Adding VLANs to the guest systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.4 Adding VLAN support to the z/OS TCP/IP stacks. . . . . . . . . . . . . . . . . . . . . . . 11.4.5 Configuring trunk mode in the Ethernet switch for the OSA connections . . . . . 11.4.6 Verifying the VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Enabling port isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5.1 Port isolation off - systems sharing the same VSWITCH and OSA . . . . . . . . . 11.5.2 Port isolation on - systems sharing the same VSWITCH and OSA . . . . . . . . . 11.6 Configuring link aggregation support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6.1 Defining link aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6.2 Setting up the external Ethernet switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6.3 Verifying the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

158 159 160 161 163 163 165 167 168 169 170 173 173 173 176 178 179 181 181 183 183

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

vi

Appendix B. OSA-Express Network Traffic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . OSA-Express Network Traffic Analyzer (OSAENTA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining the microcode level for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Additional tools for diagnosing CS for z/OS IP problems . . . . . . . . . . . . . . . . . . . . . . . . . . Network Management Interface API (NMI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197 198 198 199 200 201 207 208 208 216 217 218

Appendix C. HMC and SE tasks for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HMC advanced facilities for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace functions for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware functions for OSA-Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . View code level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring OSA channels on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging on to the Support Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHPID Configure on/off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging off from the Support Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

219 220 222 224 228 229 229 230 232

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

235 236 238 239 240


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

241 242 242 242 244

Appendix F. TCP/IP Passthru mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HCD requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying the default OAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customizing z/OS TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying that devices are online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activating TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

251 252 252 253 256 257 258 259 259

Appendix G. Sample definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . z/OS definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VTAM definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . z/VM TCP/IP profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

261 262 262 263 265 267

Appendix H. ARP takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ARP takeover description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ARP takeover definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP/IP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ethernet switch definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying ARP takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pulling the CAT5 cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping the device in the TCP/IP stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

269 270 271 271 271 272 272 275

Appendix I. HiperSockets Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HiperSockets Accelerator description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HiperSockets definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying HiperSockets Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

277 278 279 280

Appendix J. RMF in an OSA environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RMF for OSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RMF Monitor II output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Channel Activity Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

283 284 284 284

Appendix K. Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . z/VM virtual switch authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running with CP authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running with RACF authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

287 288 288 290

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

293 293 293 293 294 294

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Contents

vii

viii


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.


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


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 book This 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 Goldman System z (OSA firmware) Development, IBM Poughkeepsie Susan Farrell and Angelo Macchiano z/VM Networking Development, IBM Endicott Cliff Laking Technical Support - z/VM and Linux on System z, IBM UK


xi

Become a published author Join 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 welcome Your 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 Organization Dept. HYJ Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400

xii


1

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. Terminology: If not specifically stated otherwise, the term OSA applies to the OSA-Express3 and OSA-Express2 features throughout this book. The following topics are covered: 򐂰 Functional description 򐂰 Operating modes 򐂰 OSA capabilities


1

1.1 Functional description The 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.

z10 BC z9 BC E-T BAS 0 0 10 GbE

10 00 BA SE -T GbE 10

10

GbE

Ethernet 10

z10 EC GbE E-T 1000BAS

10

E Gb

GbE

z9 EC Gb E

Gb E 10 00 BA SE -T

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

2


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 CHPID type

Feature

SNA/APPN/ HPR traffic

TCP/IP traffic

3270 traffic

OSA/SF

OSD

OSA-Express3 10GbE LR OSA-Express3 10GbE SR OSA-Express2 10GbE LR OSA-Express3 GbE OSA-Express2 GbE OSA-Express3 1000BASE-T OSA-Express2 1000BASE-T

Noa,b Noa,b Noa,b Noa,b Noa,b Noa,b Noa,b

Yes Yes Yes Yes Yes Yes Yes

No No No No No No No

Optional Optional Optional Optional Optional Optional Optional

OSE

OSA-Express3 1000BASE-T OSA-Express2 1000BASE-T

Yes Yes

Yes Yes

No No

Required Required

OSC

OSA-Express3 1000BASE-T OSA-Express2 1000BASE-T

No No

No No

Yes Yes

n/a n/a

OSN

OSA-Express3 GbE OSA-Express2 GbE OSA-Express3 1000BASE-T OSA-Express2 1000BASE-T

Yesc Yesc Yesc Yesc

No No No No

No No No No

Optional Optional Optional Optional

a. SNA over IP with the use of Enterprise Extender or TN3270 (see “Enterprise Extender” on page 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). c. Supports SNA PU Type 5 and PU Type2.1 (see “OSA for NCP support” on page 22).

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

Chapter 1. OSA overview

3

Non-QDIO (LCS) Host Memory

QDIO

QDIO

Host Memory

Host Memory

Store and forward OSA-Express2

Data router OSA-Express3

LAN

LAN

Channel

Control Unit

NIC OSA-Express

LAN 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 mode QDIO 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. 4


Data router With 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 queuing Priority queuing is a capability supported by the QDIO architecture and introduced with the Service Policy Server (for z/OS environments only). It sorts outgoing IP message traffic according to the service policy you have set up for the specific priority assigned in the IP header. 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. 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).

Dynamic OSA Address Table (OAT) update With 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.


5

LPAR-to-LPAR communication Access 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) functions OSA 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 functions The 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 update The 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 assists Complementary 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 6


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/OS OSA-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 mode Like 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 Passthru In 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 support In 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.


7

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

Maximum IP addresses per OAT The 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) addresses When 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 subchannels A 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.

8


1.1.5 OSA/SF support OSA/SF includes a Java™-based Graphical User Interface (GUI) in support of the client application. The Java GUI is independent of any operating system or server (transparent to the operating system), and is expected to operate wherever the 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 capabilities This section discusses the capabilities that exploit the OSA-Express3 and OSA-Express2 features.


9

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 Takeback Since a VIPA is associated with a TCP/IP stack and not a physical network attachment, it can be moved to any TCP/IP stack within its network. If the TCP/IP stack that the VIPA is on fails (due to an outage), the same VIPA can be brought up automatically on another TCP/IP stack (VIPA Takeover) to allow end users to reach the backup server and applications. The original session between the end user and original server is not disrupted. Once the failed TCP/IP stack is restored, the same VIPA can be moved back automatically (VIPA Takeback).

1.2.2 Primary/secondary router function The primary/secondary router function enables an OSA 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. 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

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:

10


򐂰 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 traffic Large 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).

Application send buffer

Ethernet frame

Jumbo frame

TCP large send

63 KB

63 KB

63 KB

1.5 KB

TCP Stack

OSA-Express2 or OSA-Express3

9 KB

.. .. .

9 KB

1.5 KB

9 KB

1.5 KB

.. .. .

63 KB

..

1.5 KB

1.5 KB

.. .. .

1.5 KB

..

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

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

11

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. Tip: Applications that use large TCP send buffers will obtain the most benefit from large send. 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 support Virtual 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).

12


LP 1 z/OS TCP/IP IPv4 VLAN 28

LP 2 z/OS TCP/IP IPv4 IPv6 VLAN16 VLAN37

port 1

LP 3 Linux TCP/IP IPv6 IPv4 VLAN37 VLAN4

port 2

LP 4 z/VM TCP/IP IPv4 VLAN12

OSA-Express Ethernet ports in QDIO mode

Ethernet Switch

VLAN28

VLAN4

VLAN16

VLAN12

Common physical network

Figure 1-4 VLAN support

VLAN support for z/OS Full 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/VM z/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 z VLAN 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 GVRP GVRP is defined in the IEEE 802.1p standard for the control of IEEE 802.1q VLANs. It can be used to help simplify networking administration and management of VLANs.


13

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

OSA-Express2 OSA-Express3 VLAN22 VLAN33 VLAN44

VLAN 22

VLAN33

GVRP support dynamically registers VLAN IDs to the physical LAN

VLAN44

Physical LAN 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 z SNMP 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.

14


For more information about SNMP support, refer to: http://www.ibm.com/servers/eserver/zseries/networking/dsnmp.html

Tip: If you subscribe to the document “OSA-Express Direct SNMP MIB module” through Resource Link™, you will receive e-mail notification of document changes. 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).

Agents (servers)

Managers (clients)

z/OS

z/OS UNIX Shell User's Address Space osnmp command Tivoli NetView Address Space SNMP command

OSAD device with subagent

OSNMPD SNMP Agent's Address Space TCP/IP Address Space

TCP

OSA proxy Subagent

SNMP Subagent

System z OSA-Express

Figure 1-6 SNMP support - z/OS example

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

Multicast support For 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 z Broadcast 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).


15

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 management The 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 z The 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 z Purging of entries in the ARP cache is supported using IPv4. The TCP/IP stack already has an awareness of IPv6 addresses.

ARP takeover ARP takeover provides the capability of switching OSA 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 statistics QDIO 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 availability There 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.

16


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 z z/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. Note: Linux on System z only supports inbound checksum offload (inbound 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: http://www.ibm.com/developerworks

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.


17

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.

z/VM Linux guest

z/VM guest

02-00-00-00-00-01 02-00-00-00-00-02

TCP/UDP Appl. Linux

SNA Appl.

Virtual Switch (Layer 2) 02-00-00-00-00-03

Ethernet Switch

NetBIOS Appl.

02-00-00-00-00-01 02-00-00-00-00-02 02-00-00-00-00-03

OSA-Express

Figure 1-7 Layer 2 support 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.

18


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 mode Link 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). Note: Target links for aggregation must be of the same type (for example, Gigabit Ethernet to Gigabit Ethernet).

1.2.12 QDIO data connection isolation The 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).


19

z/VM LPAR Linux Guest

z/OS Guest

Virtual Switch port isolation

Linux Guest

z/OS Guest

OSA-Express3

Ethernet Switch

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/OS To 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: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

20

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


򐂰 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 Extender The 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 Server The TN3270E Server is supported by z/OS. It allows desktop users to connect through an IP network directly to SNA applications. The following support is provided: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

Secure access using 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.


21

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

22


Linux on System z

NCP CCL

OSD or OSE

z/OS, z/TPF

VTAM CDLC

OSN

Traffic between the LPs Traffic between CCL and LAN environment

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


23

24


2

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


25

2.1 Software support Table 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 N x

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

z10

z9

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

z/OS V1R9

z/OS V1R8

z/OS V1R7

z/VM V5R4

z/VM V5R3

z/VM V5R2

x

x

Y

Y

Y

Y

Y

Y

Y

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

Function ARP takeover ARP cache management

26


Function

z10

OSA-Express3 10 Gigabit Ethernet SR CHPID type OSD

z/OS V1R9

z/OS V1R8

z/OS V1R7

z/VM V5R4

z/VM V5R3

z/VM V5R2

x

Y

Y

Y

Y

Y

Y

Y

OSA-Express3 Gigabit Ethernet LX using two ports per CHPID types OSD

x

Y

Ya

Ya

N

Y

Ya

Ya

OSA-Express3 Gigabit Ethernet LX using one port per CHPID type OSD

x

Y

Y

Y

Y

Y

Y

Y

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

x

Y

Ya

Ya

N

Y

Ya

Ya

OSA-Express3 Gigabit Ethernet SX using one ports per CHPID type OSD OSA-Express3-2P Gigabit Ethernet SX using one ports per CHPID type OSD

x

Y

Y

Y

Y

Y

Y

Y

OSA-Express3 1000BASE-T Ethernet using two ports per CHPID type OSD OSA-Express3-2P 1000BASE-T Ethernet using two ports per CHPID type OSD

x

Y

Ya

Ya

N

Y

Ya

Ya

OSA-Express3 1000BASE-T Ethernet using one ports per CHPID type OSD OSA-Express3-2P 1000BASE-T Ethernet using one ports per CHPID type OSD

x

Y

Y

Y

Y

Y

Y

Y

OSA-Express3 1000BASE-T Ethernet using two ports per CHPID type OSE OSA-Express3-2P 1000BASE-T Ethernet using two ports per CHPID type OSE

x

Y

Y

Y

Y

Y

Y

Y

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

x

Y

Y

Y

Y

Y

Y

OSA-Express2 10 Gigabit Ethernet LR CHPID 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 SX CHPID type OSD

x

x

Y

Y

Y

Y

Y

Y

Y

OSA-Express2 1000BASE-T Ethernet CHPID 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

z9

z/OS V1R10

Y

a. Support for guest use only b. PTFs required

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 definitions Before 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 types The different types of OSA channels (CHPID types) require the following device types: 򐂰 OSA devices for QDIO (OSD) and non-QDIO (OSE) CHPID types 򐂰 3270-X and 3287 devices for the OSA-ICC (OSC) CHPID type 򐂰 3745 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 channels OSA 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.

28


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 OSA-Express

OSA-Express2

OSA-Express3a

IP addresses per CHPID

2048

4096

4096

Multicast addresses

1024

2048

2048

ARP table size

8192

16384

16384

MAC addresses

2048b

2048

2048

2

2c

2c

TCP/IP stacks per CHPID

120

120c

120c

SNA PUs per CHPID

4096

4096c

4096c

Subchannels per CHPID

240

240c

240c

1

1c

1c

3

3

3

TCP/IP stacks per CHPID

84 / 160

640d

640d

Subchannels per CHPID

254 / 480

1920d

1920d

1 / 16

16

16

Addresses

non-QDIO (OSE) Subchannels per TCP/IP link

CUs per CHPID QDIO (OSD) Subchannels per TCP/IP link

CUs per CHPID

a. Applies to System z10 only b. Supported by Ethernet features only (excluding FC 2366) c. 1000BASE-T feature only d. If multiple priority queues are enabled, the maximum is reduced to 160 TCP/IP stacks and 480 subchannels per CHPID.

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.

2.3 OSA/SF requirements Open 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).


29

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 OSA feature

OSD (QDIO)

10 GbE LR 10 GbE SR

OSE (non-QDIO)

OAT built

OSA/SF required

Yes

Dynamic

No

GbE GbE 2P

Yes

Dynamic

No

1000BASE-T Ethernet 1000BASE-T 2P Ethernet

Yes

Dynamic

No

Manual

Yes

Yes

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 tables This 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 support Table 2-4 lists the functions that are supported based on an OSA feature. Table 2-4 OSA function support

30

Function

GbE

1000BASE-T

GbE

1000BASE-T

OSA-Express

10 GbE

OSA-Express2 and OSA-Express3

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


Function

GbE

1000BASE-T

GbE

1000BASE-T

OSA-Express

10 GbE

OSA-Express2 and OSA-Express3

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

x

xa

n/a

n/a

QDIO data connection isolation

x

a. Only in QDIO mode

2.4.2 Quick start tables for z/OS and z/VM When 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.


31

z/OS quick start table Table 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 OSA feature

Operation mode

CHPID type

TCP/IP device type

TCP/IP link type

VTAM definitions

10 GbE LR 10 GbE SR

QDIO TCP/IP

OSD

MPCIPA

IPAQENET

TRLE

GbE GbE 2P

QDIO TCP/IP

OSD

MPCIPA

IPAQENET

TRLE

QDIO TCP/IP

OSD

MPCIPA

IPAQENET

TRLE

Non-QDIO TCP/IP

OSE

LCS

ETHERNet, 802.3, or ETHEROR802.3

Non-QDIO SNA

OSE

1000BASE-T 1000BASE-T 2P

XCA, SWNET

Go to...

Chapter 5, “QDIO mode for z/OS” on page 67

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

z/VM quick start table Table 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 OSA feature

Operation mode

CHPID type

TCP/IP device type

TCP/IP link type

10 GbE LR 10 GbE SR

QDIO TCP/IP

OSD

OSD

QDIOETHERNET

GbE GbE 2P

QDIO TCP/IP

OSD

OSD

QDIOETHERNET

QDIO TCP/IP

OSD

OSD

QDIOETHERNET

Non-QDIO TCP/IP

OSE

LCS

ETHERNET, 802.3 or ETHEROR802.3

Non-QDIO SNA

OSE

1000BASE-T 1000BASE-T 2P

VTAM definitions

Go to...

Chapter 6, “QDIO mode for z/VM” on page 77

XCA and SWNET

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

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 networking The 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

32


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.


33

34


3

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.


35

3.1 Configuration chart The 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.

SCZP202 z/OS V1R10

z/VM V5R4

LPAR SC81

LPAR VMLINUX3

CSS 0

CSS 1

PCHID 1C1 CHPID 0A OSD E200 - E20F Port 1 Port 0

PCHID 231 CHPID 0B OSD 2D80 - 2D8F Port 1 Port 0

Ethernet

Figure 3-1 HCD definitions for OSA CHPIDs

3.2 Hardware Configuration Definition HCD is used to define OSAs to the I/O hardware configuration. Examples of the following definitions are included: 򐂰 Channel path 򐂰 Control unit 򐂰 Devices

36


3.2.1 Channel path definition We 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. z/OS V1.10 HCD Command ===> ________________________________________________________________ Hardware Configuration Select one of the following. 1

1. 2. 3. 4. 5. 6. 7. 8. 9.

Define, modify, or view configuration data Activate or process configuration data Print or compare configuration data Create or view graphical configuration report Migrate configuration data Maintain I/O definition files Query supported hardware and installed UIMs Getting started with this dialog 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'

+

Figure 3-2 HCD main menu

2. In the Define, modify, or view configuration data panel, select option 3 (Processors) and press Enter. 3. In the next display (Figure 3-3), select the processor that you want to update by using action code S. Then press Enter. Note: We identify the panel selection options using the action code, rather than the item number, to avoid confusion when a particular HCD menu changes.

Chapter 3. Hardware configuration definitions

37

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.

/ _ _ _ _ _ _ s _ _

Proc. ID B706STP1 B706STP2 ISGSYN ISGS11 SCZP101 SCZP201 SCZP202 SCZP801 SCZP901

Type + 2097 2097 2064 2064 2094 2097 2098 2064 2084

Model + E26 E26 1C7 1C7 S18 E26 E10 1C7 C24

Mode+ LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR LPAR

Serial-# + __________ __________ __________ __________ 02991E2094 01DE502097 052B622098 010ECB2064 026A3A2084

Description ________________________________ ________________________________ ________________________________ ________________________________ ________________________________ ________________________________ ________________________________ ________________________________ ________________________________

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. 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 / ID s 0 _ 1

Devices in SS0 Devices in SS1 Maximum + Actual Maximum + Actual Description 65280 6774 65535 0 ________________________________ 65280 5736 65535 0 ________________________________

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.

38


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 . Number of CHPIDs . Channel path type Operation mode . . Managed . . . . . Description . . .

. . . . . .

. . . . . .

. . . . . .

0A + PCHID . . . 1C1 1 OSD + SPAN + No (Yes or No) I/O Cluster ________ OSA-Express3 1000BASE-T_________

Specify the following values Dynamic entry switch ID __ Entry switch ID . . . . __ Entry port . . . . . . . __

+

only if connected to a switch: + (00 - FF) + +

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. ___________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 Figure 3-6 Allow TCP/IP stacks


39

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. ______________________________ Define Access List ________________________ Select one or more partitions for inclusion in the access list. Channel subsystem ID : 0 Channel path ID . . : 0A Operation mode . . . : SPAN / / _ /

CSS ID Partition Name 0 A01 1 A11 1 A12

Channel path type . : OSD Number of CHPIDs . . : 1

Number 1 1 2

Usage OS CF OS

Description SC81 alternate CF8C VMLINUX3 alternate

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 definition From the Channel Path List panel, follow these steps. 1. Type an S next to the CHPID that you just defined (0A, in our example), and press Enter. 2. Press F11 to add a control unit. 3. In the Add Control Unit display (Figure 3-8), enter the required information. a. For Control unit number, we chose E200. b. Control unit type must be OSA. c. Press Enter. _________________________ Add Control Unit _____________________ Specify or revise the following values. Control unit number . . . . E200 + Control unit type . . . . . OSA__________ + Serial number . . . . . . . __________ Description . . . . . . . . ________________________________ Connected to switches . . . __ __ Ports . . . . . . . . . . . __ __

__ __

__ __ __ __

1. 2.

Yes No

1. 2.

Yes No

If connected to a switch: Define more than eight ports . . 2 Propose CHPID/link addresses and unit addresses . . . . . . . . . 2

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

40


__ __ __ __

__ __

+ +

4. As shown in Figure 3-9, type an S next to the processor for the control unit. Then press Enter. 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

/ _ _ _ _ S _ _ _ _

Proc.CSSID SCZP201.0 SCZP201.1 SCZP201.2 SCZP201.3 SCZP202.0 SCZP202.1 SCZP801 SCZP901.0 SCZP901.1

Control unit type . . . : OSA

---------------Channel Path ID . Link Address + 1------ 2------ 3------ 4------ 5------ 6-----_______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______

--------------7------ 8-----_______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______

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. ______________________________ Add Control Unit ___________________________ Specify or revise the following values. Control unit number . : E200 Processor ID . . . . . : SCZP202 Channel Subsystem ID . : 0

Type . . . . . . : OSA

Channel path IDs . . . . 0A Link address . . . . . . ____

__ ____

__ __ ____ ____

__ __ ____ ____

__ ____

__ + ____ +

Unit address . . . . . . 00 Number of units . . . . 255

__ ___

__ ___

__ ___

__ ___

__ ___

Logical address

. . . . __

Protocol . . . . . . . . __ I/O concurrency level . _

__ ___

__ ___

+

+ (same as CUADD) + (D,S or S4) + (1, 2 or 3)

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 definition From the Control Unit List panel, follow these steps: 1. Type an S to select the control unit. Then press Enter. 2. Press F11 to add devices. Chapter 3. Hardware configuration definitions

41

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

For Device number, we choose E200. For Number of devices, we choose 15. Device type must be OSA. 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

____ ____

____ ____

____

____ ____

+

Figure 3-11 Add Device display

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

42


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. ______________________ Device / Processor Definition ____________________ Select processors to change device/processor definitions, then press Enter. Device number . . : E200 Device type . . . : OSA

/ Proc.CSSID SS+ / SCZP202.0 _

Number of devices

UA+ Time-Out STADET __ No No

. : 15

Preferred Device Candidate List CHPID + Explicit Null __ No ___

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. ___________________________Define Device / Processor_________________________ Specify or revise the following values. Device number . . . Device type . . . . Processor ID . . . . Channel Subsystem ID

: : : :

E200 OSA SCZP202 0

Subchannel set ID . . . . . . . 0 Unit address . . . . . . . . . . 00 Time-Out . . . . . . . . . . . . No STADET . . . . . . . . . . . . . No Preferred CHPID . . . . . . . . __ Explicit device candidate list . No

Number of devices . . . . : 15

+ + (Only necessary when different from the last 2 digits of device number) (Yes or No) (Yes or No) + (Yes or No)

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.


43

12.In the Add Device display, define the new device as shown in Figure 3-14. __________________________________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

____ ____

____ ____

____

____ ____

+

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. ___________________________Define Device / Processor______________________ Specify or revise the following values. Device number . . . Device type . . . . Processor ID . . . . Channel Subsystem ID

: : : :

E20F OSAD SCZP202 0

Subchannel set ID . . . . . . . 0 Unit address . . . . . . . . . . FE Time-Out . . . . . . . . . . . . No STADET . . . . . . . . . . . . . No Preferred CHPID . . . . . . . . __ Explicit device candidate list . No Figure 3-15 OSAD definition (Part 2 of 2)

44


Number of devices . . . . : 1

+ + (Only necessary when different from the last 2 digits of device number) (Yes or No) (Yes or 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. _____________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 Device type . . : OSAD / _ / _ _ _

Config. ID ALLDEV L06RMVS1 MVSW1 OPENMVS1 TEST2094

Type MVS MVS MVS MVS MVS

Number of devices : 1

SS Description All devices Sysplex systems Production systems OpenEdition MVS Sysplex systems

Defined

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. ______________________Define Device Parameters / Features_____________________ Row 1 of 3 Command ===> ___________________________________________ Scroll ===> PAGE Specify or revise the values below. Configuration ID . : L06RMVS1 Device number . . : E20F Device type . . . : OSAD Parameter/ Feature OFFLINE DYNAMIC LOCANY

Value + No Yes No

Sysplex systems Number of devices : 1

R Description Device considered online or offline at IPL Device has been defined to be dynamic UCB can reside in 31 bit storage

Figure 3-17 Defining Device Parameters / Features display


45

3.2.4 Generating the input IOCDS from HCD You can generate input for IOCDS from HCD. It is then used to write the macro definitions to the System 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

46

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


4

Chapter 4.

Setting up and using OSA/SF The Open Systems Adapter Support Facility (OSA/SF) is an application that helps you to customize and manage your 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.


47

4.1 Setup requirements and overview OSA/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.

REXX REXX Command Command Line Line (IOACMD) (IOACMD)

OSA/SF GUI

LP A

LP 1

LP B

Host Programs

Host Programs

LP 2

Host Programs

OSA/SF

OSA/SF

OSA

OSA

LP 3

Host Programs

OSA/SF

Host Programs

OSA/SF

Channel Subsystem

OSA

OSA

OSA

OSA

OSA

OSA

OSA

OSA

Figure 4-1 OSA/SF communication path

This integrated version of OSA/SF is applicable to the in-service releases of z/OS, z/VM, and 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 environment This 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.

48


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.

4.2.1 Setting up APPC and VTAM Before 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, APPC=YES,AUTOSES=0,DDRAINL=NALLOW, DMINWNL=5,DMINMNR=5,DRESPL=NALLOW, DSESLIM=10,LMDENT=19,MODETAB=MTAPPC

X X X

2. Define an APPC local LU for OSA/SF by editing member APPCPMxx in the SYS1.PARMLIB and adding the statements shown in Example 4-2. Note: There is no dependency on the APPC scheduler for OSA/SF. Example 4-2 APPCPM00 from SYS1.PARMLIB

LUADD ACBNAME(IOASERV) NOSCHED

TPDATA(SYS1.APPCTP)

/* /* /* /* /* /* /* /* /*

Specify the name of the LU to be added Specify that the APPC/MVS transaction scheduler is associated with this LU name Specify that VSAM data set SYS1.APPCTP is the permanent repository for the TP profiles for this LU

*/ */ */ */ */ */ */ */ */

Note: SYS1.APPCTP is a VSAM data set. It must be allocated using job ATBTPVSM, included in SYS1.SAMPLIB. 3. Add the APPC procedure to the SYS1.PROCLIB, as shown in Example 4-3. Example 4-3 APPC from SYS1.PROCLIB

//APPC PROC APPC=00 //APPC EXEC PGM=ATBINITM,PARM='APPC=&APPC',REGION=0K 4. For automatic startup of the APPC environment, add the 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'

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

AUTOLOG . IOASRV .

b. Add the port statement, as shown in Example 4-6. Example 4-6 Port number from TCP/IP profile

PORT . 2000 TCP IOASRV .

50


; 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 workstation We used the following steps to install and set up the OSA/SF GUI on a Windows workstation after we installed and set up OSA/SF on the host system.

4.3.1 Checking the hardware configuration To use the OSA/SF GUI interface, a workstation with the following minimum hardware features is required: 򐂰 A Pentium® 200 MHz (or equivalent), 32 MB of RAM 򐂰 An SVGA display with a resolution of 1024 by 768 with 16-bit colors 򐂰 A communications adapter that supports the TCP/IP communications protocol In our configuration, we used: 򐂰 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 configuration To 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


51

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 FTP Before you download the IOAJAVA GUI code, create a directory on your Windows workstation where you can place the code for the GUI (ioajava.jar). To download the OSA/SF GUI to the workstation, use these steps: 1. Open a DOS session on your workstation. 2. Change to the directory where you want the exec stored, by typing CD. 3. Enter the File Transfer Protocol (FTP) command, using the IP address of your Host (for example, FTP 192.168.14.32) 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.

52


c. Click OK.

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

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

4.4 Using the OSA/SF GUI After you 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 Chapter 4. Setting up and using OSA/SF

53

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

54


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.


55

Figure 4-6 CHPID View

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

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

56


Figure 4-7 Port settings


57

Figure 4-8 on page 58 shows the details of the Statistics tab. Use the scroll bar to see more statistics. Note: The SNA tab is not applicable in QDIO mode.

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.

58


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


59

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.

60


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


61

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.

62


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)


63

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

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

64


Figure 4-18 OAT Information


65

66


5

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.


67

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

TCP/IP A

TCP/IP B

VTAM

VTAM

OSA-Express3 1000BASE-T

OSA-Express3 1000BASE-T Port Port 00

Port11 Port

Port 0

Port 1

Ethernet

Figure 5-1 QDIO mode example for z/OS

5.2 Hardware Configuration Definition The 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 QDIO The WRITE devices (as defined in the TRLE) should have a Missing Interrupt Handler (MIH) value of at least 15 seconds (or 30 seconds, if running as a guest system on 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 68


To set these values at IPL time, update the IECIOSxx member in PARMLIB. 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.

5.4 Customizing the z/OS network environment Figure 5-2 shows the network configuration, which consists of two z/OS LPARs, each with two connections to an Ethernet switch through OSA ports. 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.

TCP/IP A

TCP/IP B

192.168.3.64

192.168.1.65

OSAE200

OSAE204

IP Address

192.168.3.4

192.168.1.5

Device

OSA2D80

OSA2D84

VTAM

VTAM TRLE OSAE200

OSAE204

Portname

OSA2D80

z/OS

z/OS E200-E20F

Port 0

2D80-2D8F

Device Number

CHPID 0A

OSAE200

OSA2D84

Port 1

OSAE204

CHPID 0B OSAname


Port 0

Port 1

OSA2D80

OSA2D84


Ethernet IP Address 192.168.3.2

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.

Chapter 5. QDIO mode for z/OS

69

5.4.1 Defining OSA devices to z/OS Communications Server for QDIO To 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 * OSAE200P TRLE LNCTL=MPC, READ=E200, WRITE=E201, DATAPATH=(E202,E203), PORTNAME=OSAE200, PORTNUM=0, MPCLEVEL=QDIO * * QDIO TRLE FOR OSA-EXPRESS3 CHPID 0A * OSAE204P TRLE LNCTL=MPC, READ=E204, WRITE=E205, DATAPATH=(E206,E207), PORTNAME=OSAE204, PORTNUM=1, MPCLEVEL=QDIO

PORT 0 * * * * * *

PORT 1 * * * * * *

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.

70


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

TRLE considerations For 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.


71

򐂰 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. Note: We discuss the setup of z/OS V1R10 multiple VLAN support in more detail in Chapter 10, “VLAN support” on page 131.

5.4.3 TCP/IP definitions TCP/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. 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. 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 ; DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET ; 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 192.168.3.64

OSAE200 VLANID 980

VLINK1 OSAE200LNK

BEGINROUTES ROUTE 192.168.3.0/24 ROUTE 192.168.1.0/24 ENDROUTES START OSAE200 START OSAE204I

72

VIPAA


= OSAE200LNK MTU 1492 = OSAE204I MTU 1492

The following definitions are used when defining OSA port 0: OSAE200 OSAE200LNK 192.168.1.64

Device name; must match port name (port 0 of CHPID 0A) in TRLE on TCP/IP A The link name of port 0 of CHPID 0A in TCP/IP A 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 OSAE204 SOURCEVIPAINT IPADDR

Interface name The OSA portname Specifies the link name of an IPv4 static VIPA for source VIPA processing Specifies the home IP address and the number of bits in the subnet mask

5.5 Activation Normally the CHPID should be online. If the CHPID is offline, configure it online using the following command: CF CHP(0A),ONLINE After all the definitions are added to 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 online The 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 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

VOLSTATE

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 activation Next, activate the corresponding TRL using the following VTAM command: V NET,ACT,ID=OSAE200P and V NET,ACT,ID=OSAE204P


73

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 devices There 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 displays Example 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

74


ARPOFFLOAD: YES CFGMTU: 1492 IPADDR: 192.168.1.65/24 VLANID: 981 DYNVLANREGCFG: NO READSTORAGE: GLOBAL (4096K) CHECKSUMOFFLOAD: YES SECCLASS: 255 MULTICAST SPECIFIC:

ARPOFFLOADINFO: YES ACTMTU: 1492 VLANPRIORITY: DISABLED DYNVLANREGCAP: YES INBPERF: BALANCED MONSYSPLEX: NO

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 = 0707 IST1577I HEADER SIZE = 4096 DATA SIZE = 0 STORAGE = ***NA*** IST1221I WRITE DEV = E201 STATUS = ACTIVE STATE = ONLINE IST1577I HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA*** IST1221I READ DEV = E200 STATUS = ACTIVE STATE = ONLINE IST1221I DATA DEV = E202 STATUS = ACTIVE STATE = N/A IST1724I I/O TRACE = OFF TRACE LENGTH = *NA* IST1717I ULPID = TCPIPA IST1815I IQDIO ROUTING DISABLED 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


75

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

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.

76


6

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.


77

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

TCPIP

TCPIP01



Port Port 0

Port 11 Port

Port 0

Port 1

Ethernet

Figure 6-1 QDIO mode example for z/VM

6.2 Hardware Configuration Definition The 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 QDIO The 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. 78


6.4 Customizing the z/VM network environment Figure 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. 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.

z/VM V5R4 (LPAR) TCPIP

TCPIP01

192.168.3.10 DEVICE E200 00

192.168.3.6 DEVICE 2D80 00

192.168.1.11 DEVICE E204 01

192.168.1.7 DEVICE 2D84 00

E200-E202 E204-E206

2D80-2D82 2D84-2D86

CHPID 0A Port 0

CHPID 0B

Port 1

Port 0

Port 1

Ethernet Switch 192.168.3.2

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. Chapter 6. QDIO mode for z/VM

79

6.4.1 TCP/IP definitions TCP/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 LINK DEV_E200 QDIOETHERNET DEV_E200 ; DEVICE DEV_E204 OSD E204 PORTNUMBER LINK DEV_E204 QDIOETHERNET DEV_E204 ; HOME 192.168.1.11 255.255.255.0 DEV_E204 192.168.3.10 255.255.255.0 DEV_E200 ; START DEV_E200 START DEV_E204

00 MTU 1500 ETHERNET 01 MTU 1500 ETHERNET

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 ; DEVICE DEV_2D84 OSD 2D84 LINK DEV_2D84 QDIOETHERNET DEV_2D84 ; 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

MTU 1500 ETHERNET

MTU 1500 ETHERNET

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

6.5 Activation Normally the CHPID should be online. If the CHPID is offline, configure it online using the following command: VARY ON CHPID 0A

80


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 online With 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 OSA 2980 OSA 2981 OSA 2982 OSA 2984 OSA 2985 OSA 2986 OSA 2988 OSA 2989 OSA 298A OSA 2D80 OSA 2D81 OSA 2D82 OSA 2D84 OSA 2D85 OSA 2D86 OSA E200 OSA E201 OSA E202 OSA E204 OSA E205 OSA E206 OSA 2983 OSA 298D OSA 2D88

ALL ATTACHED TO TCPIP 2980 ATTACHED TO TCPIP 2981 ATTACHED TO TCPIP 2982 ATTACHED TO DTCVSW1 2984 ATTACHED TO DTCVSW1 2985 ATTACHED TO DTCVSW1 2986 ATTACHED TO TCPIP01 2988 ATTACHED TO TCPIP01 2989 ATTACHED TO TCPIP01 298A ATTACHED TO TCPIP01 2D80 ATTACHED TO TCPIP01 2D81 ATTACHED TO TCPIP01 2D82 ATTACHED TO TCPIP01 2D84 ATTACHED TO TCPIP01 2D85 ATTACHED TO TCPIP01 2D86 ATTACHED TO TCPIP E200 ATTACHED TO TCPIP E201 ATTACHED TO TCPIP E202 ATTACHED TO TCPIP E204 ATTACHED TO TCPIP E205 ATTACHED TO TCPIP E206 FREE , OSA 2987 FREE FREE , OSA 298E FREE FREE , OSA 2D89 FREE

DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE , OSA , OSA , OSA

OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA OSA 298B FREE 2D83 FREE 2D8A FREE

CHPID 02 CHPID 02 CHPID 02 CHPID 02 CHPID 02 CHPID 02 CHPID 02 CHPID 02 CHPID 02 CHPID 0B CHPID 0B CHPID 0B CHPID 0B CHPID 0B CHPID 0B CHPID 0A CHPID 0A CHPID 0A CHPID 0A CHPID 0A CHPID 0A , OSA , OSA , OSA

OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD 298C FREE 2D87 FREE 2D8B FREE

Chapter 6. QDIO mode for z/VM

81

OSA 2D8C FREE , OSA 2D8D OSA E203 FREE , OSA E207 OSA E20A FREE , OSA E20B OSA E20E FREE , OSA E20F 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

FREE FREE FREE FREE

, OSA , OSA , OSA

2D8E FREE E208 FREE E20C FREE

, OSA , OSA , OSA

2D8F FREE E209 FREE E20D FREE

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

6.6 Relevant status displays To 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 Queue size: 0 CPU: 0 Link DEV_E200 Transport Type: Ethernet Speed: 100000000 BytesIn: 43804 Forwarding: Enabled IPv4 Path MTU Discovery: IPv4 VIPA ARP Multicast Group --------------224.0.0.1

Type: OSD Address: E200 Type: QDIOETHERNET

Status: Ready Port name: UNASSIGNED Port number: 0

BytesOut: 3636 MTU: 1500 Disabled

IPv6: Disabled

Members ------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 82


--------------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 Queue size: 0 CPU: 0 Link DEV_2D80 Transport Type: Ethernet Speed: 1000000000 BytesIn: 43840 Forwarding: Enabled IPv4 Path MTU Discovery: IPv4 VIPA ARP Multicast Group --------------224.0.0.1

Type: OSD Address: 2D80 Type: QDIOETHERNET



IPv6: Disabled

Device DEV_2D84 Queue size: 0 CPU: 0 Link DEV_2D84 Transport Type: Ethernet Speed: 1000000000 BytesIn: 404 Forwarding: Enabled IPv4 Path MTU Discovery: IPv4 VIPA ARP Multicast Group --------------224.0.0.1 Ready; T=0.01/0.01 08:02:07

Type: OSD Address: 2D84 Type: QDIOETHERNET



IPv6: Disabled

Members ------1

Members ------1

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 ------192.168.1.11 192.168.3.10

Subnet Mask ----------255.255.255.0 255.255.255.0

Link -----DEV_E200 DEV_E204

VSWITCH ------

Chapter 6. QDIO mode for z/VM

83

IPv6 Home address entries: None

84


7

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.


85

7.1 Configuration information Figure 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

z/OS LPAR TCP/IP

VTAM

Channel Subsystem

OAT Table OSA-Express3 1000BASE-T Port 0

Port 1

Connectivity definitions: - TCP/IP Passthru - SNA

Ethernet

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.

86


7.2 Hardware definitions The 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 configuration In 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

TCP/IP A IP Address

Device

192.168.4.3

192.168.4.4

OSA2E40

OSA2E42

VTAM XCA Node

XCAOSAX3

Switch Maj.

SWOSAX3

Devices Port + Port 1 2E40, 2E41, 2E4A

2E42, 2E43, 2E4B

CHPID 0C Port 0

OSA2E40

Port 1

OSA2E42

Unit Address used by TCP/IP: 00-01

Unit Address used by TCP/IP: 02-03

Unit Address used by VTAM: 0A

Unit Address used by VTAM: 0B

OAT 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


Ethernet

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.

88


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. 4. From the OSA/SF menu bar, choose Selected  Configurations  Configuration. 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.

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.


89

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

90


7.3.1 TCP/IP definitions in OSA/SF To set the TCP/IP definitions in OSA/SF, follow these steps: 1. To proceed to the TCP/IP setup, click Add... (see Figure 7-4), under the TCP/IP section. 2. The TCP/IP Passthru OAT Entry Definition window (Figure 7-5) opens. In Shared Port mode, more than one LPAR can share an OSA 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. Reminder: If you are using a CHPID dedicated to one LPAR, the LP number must be 0. b. For Even unit address, enter the address for this port. The unit address can be any even address, but unit address 00,01 is associated with OSA port 0 in the default OAT. For this example, we type 00. Note: The OSA port unit address was used by HCD in Chapter 3, “Hardware configuration definitions” on page 35, when defining the OSA devices. c. For Default entry indicator, you can select Primary for one of the LPARs using this port. The LPAR designated as the Primary receives any datagrams that are not specifically addressed to any of the home IP addresses associated with this OSA 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


91

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

92


7.3.2 SNA definition in OSA/SF Since 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


93

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. Note: Defining multiple LPARs to use the same port is known as a shared port. In SNA mode, no additional information is required in the OAT definition. This is unlike TCP/IP Passthru mode, which requires the IP address to be added to the OAT. Shared port is only possible when the VTAMs that are sharing the OSA port each use a unique SAP address. Enter the unit address for this port.

Figure 7-8 SNA OAT Entry Definition

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

94


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.


95

7.3.3 Activating the OSA configuration All TCP/IP and SNA mode configuration changes are disruptive. Before you activate the TCP/IP and SNA mode configurations, you must stop all devices having an active session through the OSA 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. 2. Start the OSA/SF GUI program: a. Open a DOS window. b. Enter the following command: java IOAJAVA c. At the prompt, type your password to obtain a connection. 3. In the Workstation Interface window, in the right panel under OSA/SF Commands, select CHPID View. 4. In the CHPID View window, select CHPID 0C. Then, from the menu bar, choose Selected  Configurations  Configuration. 5. In the window that opens, click File  Open saved configuration. 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

96


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.


97

7.3.4 Displaying the MAC address In SNA mode, any downstream workstation doing a dial-in operation, such as PCOM as a 3270 terminal, needs to know the MAC address of the OSA port. To display this address, you can use the OSA/SF GUI. 1. From the CHPID View window (Figure 7-3 on page 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. 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.

Figure 7-12 Reviewing the MAC address values

98


7.4 Customizing the z/OS network environment In 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. Reminder: Port sharing is set up in OSA/SF, not in TCP/IP or VTAM.

7.4.1 VTAM definitions This section describes the definitions required in VTAM to allow SNA applications to access the LAN via the OSA 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 node Define one XCA major node for each SNA OSA device with: 򐂰 The node type (VBUILD definition statement) 򐂰 The port used by the LAN (Port definition statement) 򐂰 The switched peripheral nodes (type 2) attached to an Ethernet LAN through an OSA 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 OSAX3

VBUILD TYPE=XCA 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


99

Table 7-1 lists the Port parameters. Table 7-1 XCA major node Port definition for XCAOSAX3 Required parameters

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.

Table 7-2 identifies the significant Group parameters. Table 7-2 XCA major node Group definition for 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.

Switched major node Define one switched major node for each switched connection to the peripheral nodes attached on the LAN. Code the following items: 򐂰 A remote physical unit (PU definition statement) 򐂰 The corresponding logical units (LU definition statements) 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, IDBLK=05D, IDNUM=12863, CPNAME=OSANT, IRETRY=YES, MAXOUT=7, MAXPATH=1, MAXDATA=1024, PACING=0, 100


X X X X X X X X X

OSASWL0 LU OSASWL1 LU OSASWL2 LU

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

X X X X X X X

Table 7-3 lists the important parameters in the LU definition for SWOSA63. Table 7-3 Switched major node LU definition for SWOSA63 Parameters

Explanation

Remarks

LOCADDR=0

LU’s local address at the PU

LOCADDR=0 denotes an independent LU.

MODETAB=MTAPPC

Logon mode table

Code a separate logon mode table for APPC.

LOCADDR=2

LOCADDR=2 denotes a dependent LU.

7.4.2 TCP/IP definitions TCP/IP uses the OSA 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. 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. 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. 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. 3. Define the HOME IP address of the OSA port.


101

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 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 ; 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 connections After all the definitions are added to OSA/SF, VTAM, and TCP/IP, we can activate the configuration. Activation may require several tasks, such as: 򐂰 Verifying that the devices are online 򐂰 Activating VTAM resources 򐂰 Activating TCP/IP

102


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

D U,,,2E40,2 IEE457I 17.33.33 UNIT STATUS 699 UNIT TYPE STATUS VOLSER 2E40 OSA A-BSY 2E41 OSA A D U,,,2E4A,1 IEE457I 17.34.12 UNIT STATUS 701 UNIT TYPE STATUS VOLSER 2E4A OSA A

VOLSTATE

VOLSTATE

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 activation VTAM 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,ACT V NET,ID=SWOSAX3,ACT

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

7.6 Relevant status displays We 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.


103

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

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

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

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 Figure 7-16 Display of TCP/IP device and link

104


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 Configuration name LAN traffic state Port disabled state Service mode Modes configured Local MAC address Universal MAC address Configured speed/mode Active speed/mode TCP port name

1000Base-T Ethernet non qdio chpid 0C (ip+sna) Enabled N/A No SNA, TCP/IP Passthru 00145E74A950 00145E74A950 Auto negotiate 1000 Mbps full duplex 1GIGPCIe

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


105

106


8

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.


107

8.1 Configuration information Figure 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

z/VM LPAR TCP/IP

VTAM

Channel Subsystem

OAT Table OSA-Express3 1000BASE-T Port 0

Port 1

Connectivity definitions: - TCP/IP Passthru - SNA

Ethernet

Figure 8-1 Non-QDIO mode shared port

8.2 Hardware definitions The 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)*

108


,(*,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 definitions To 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 OAT In 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

z/VM V5R4

OSA/SF

OSADMIN1 IOACMD Query O Get A Put T

TCPIP01

192.168.3.20 IUCV

IOACMAIN

2E5F

VTAM

XCAP0E

192.168.3.30

2E44-2E45 2E46-2E47

OSAD

XCAP1E

2E4A

2E4B

CHPID 0C Port 0

Port 1

Ethernet Switch

SNA terminal

192.168.3.2

Figure 8-2 Connectivity layout

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. 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 features) IOAOSHRT SAMPPROF E2 F LPARs) IOAOSHRS SAMPPROF E2 F

110


(Configuration file for OSA Fast Ethernet and 1000BASE-T (OAT template for TCP/IP only for shared ports across (OAT template for SNA only for shared ports across LPARs)

IOAOSHRA SAMPPROF E2 F LPARs) ....

(OAT template for TCP/IP and SNA for shared ports across

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 IOACMD: 1 IOACMD: 2 IOACMD: 3 IOACMD: 4 IOACMD: 5 IOACMD: 6 IOACMD: 7 IOACMD: 8 IOACMD: 9 IOACMD:10 IOACMD:11 IOACMD:12 IOACMD:13 IOACMD:14

-

End IOACMD Clear Debug Configure OSA CHPID Convert OAT Get Configuration File Get Debug Get OSA Address Table Install Put OSA Address Table (OSA-2 only) Query Set Parameter Shutdown (VM only) Start Managing Stop Managing 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 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 Chapter 8. Non-QDIO mode for z/VM

111

/* 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 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 = 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 CHPIDs fenet.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 timer sna.1.3 = 10.00 /* Response timer (t1) /* .20-51 in increments of .20 sna.1.4 = 1.04 /* Acknowledgement timer (t2) /* .08-20.4 in increments of .08 sna.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.

112


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 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 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. 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: -ORIOACMD: '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: -ORIOACMD: Enter 0 to exit this EXEC Chapter 8. Non-QDIO mode for z/VM

113

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 Tip: All options can be issued in one IOACMD command, for example: ioacmd config_osa#7#0c#n#0c cnfg#0c oat#1# 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

114


8.4 Network definitions In 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. Reminder: Port sharing is set up in OSA/SF, not in TCP/IP or VTAM.

8.4.1 VTAM definitions This 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 node Define one XCA major node for each SNA OSA device with: 򐂰 The node type (VBUILD definition statement) 򐂰 The port used by the LAN (Port definition statement) 򐂰 The switched peripheral nodes (type 2) attached to an Ethernet LAN through an OSA 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, ADAPNO=0, CUADDR=2E4A, TIMER=60, SAPADDR=8 **************************************** OSAX3GP0 GROUP DIAL=YES, DYNPU=YES, ANSWER=ON, AUTOGEN=(3,L,P), CALL=INOUT, ISTATUS=ACTIVE XCAP1E VBUILD TYPE=XCA OSAX3P1E PORT MEDIUM=CSMACD,

X X X X

X X X X X

X


115

ADAPNO=1, CUADDR=2E4B, TIMER=60, SAPADDR=8 **************************************** OSAX3GP1 GROUP DIAL=YES, DYNPU=YES, ANSWER=ON, AUTOGEN=(3,L,P), CALL=INOUT, ISTATUS=ACTIVE Table 8-1 on page 117 lists the PORT parameters.

116


X X X

X X X X X

Table 8-1 XCA major node Port definition for XCAOSAX3 Required parameters

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.

Table 8-2 identifies the significant GROUP parameters. Table 8-2 XCA major node Group definition for 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.

8.4.2 TCP/IP definitions TCP/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.


117

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. 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 connections After 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 online The z/VM console display command (CP Q OSA) can verify that the required devices are online (see Figure 8-3).

CP Q OSA OSA OSA OSA OSA OSA

OSA 2E44 2E45 2E46 2E47 2E4A 2E4B

ATTACHED ATTACHED ATTACHED ATTACHED ATTACHED ATTACHED

TO TO TO TO TO TO

TCPIP01 TCPIP01 TCPIP01 TCPIP01 VTAM VTAM

Figure 8-3 z/VM Q OSA command

118


2E44 2E45 2E46 2E47 2E4A 2E4B

DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE DEVTYPE

OSA OSA OSA OSA OSA OSA

CHPID CHPID CHPID CHPID CHPID CHPID

0C 0C 0C 0C 0C 0C

OSE OSE OSE OSE OSE OSE

If they are not online, enter the z/VM console VARY ON on command: VARY ONLINE 2E4A 2E4B

8.5.2 VTAM activation VTAM 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,ACT V NET,ID=XCAP1E,ACT

8.5.3 TCP/IP activation There are two ways to activate TCP/IP devices: 򐂰 Restart the TCP/IP stack. 򐂰 Use the TCP/IP obeyfile command.

8.6 Relevant status displays We 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


119

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

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 Queue size: 0 CPU: 0 Address: 2E46 Link DEV_2E46 Type: ETHERNET Speed: 10000000 BytesIn: 0 BytesOut: 0 Forwarding: Enabled MTU: 1500 IPv4 Path MTU Discovery: Disabled Broadcast Capability: Yes Multicast Capability: Unknown

Status: Inactive Net number: 1

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 120


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 Configuration name LAN traffic state Port disabled state Service mode Modes configured Local MAC address Universal MAC address Configured speed/mode Active speed/mode TCP port name

1000Base-T Ethernet non qdio chpid 0C (ip+sna) Enabled N/A No SNA, TCP/IP Passthru 00145E74A950 00145E74A950 Auto negotiate 1000 Mbps full duplex 1GIGPCIe

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


121

122


9

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.


123

9.1 Virtual MAC overview Prior 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 concept Figure 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.

LPAR B

LPAR C

LPAR D

OSA 10.1.2.11

OSA 10.1.2.21

OSA 10.1.2.31

OSA 10.1.2.41

Device OSA

Device OSA

Device OSA

Device OSA

VMAC [ ]

VMAC [ ]

VMAC [ ]

VMAC [ ]

LPAR A

OSA 10.1.2.11

OSA 10.1.2.31

OSA 10.1.2.21

VMAC [ ]

VMAC [ ]

VMAC [ ]

OSA 10.1.2.41

VMAC [ ]

10.1.2.0/24

ARP Cache

Switch

10.1.2.11

vmac1

10.1.2.21

vmac2

10.1.2.31

vmac3

10.1.2.41

vmac4

Connect to 10.1.2.31 Connect to 10.1.2.41

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.

124


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

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

TCP/IP A

TCP/IP B

IP Address 192.168.3.64

192.168.1.65

IP Address 192.168.3.4

192.168.1.5

Device/

OSAE204I

Device/

OSAE204I

02000D74AA6D

VMAC

INTERFACE

VMAC

OSAE200 020012345678

INTERFACE

OSAE200 020087654321

VTAM Portname

OSAE200

Device Number

E200-E203

02000B74AA6D

VTAM OSAE204

Portname

OSAE200

E204-E207

Device Number

E200-E203

z/OS 1.10

z/OS 1.10

Port 1 OSAE204

Port 0 OSAE200

OSAE204 E204-E207

CHPID 0A shared between TCPIPA and TCPIPB


Ethernet Switch

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.

126


Example 9-1 DEVICE/LINK (OSA port 0) and INTERFACE (OSA port1) VMAC definition for TCPIPA DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET ; INTERFACE OSAE204I DEFINE IPAQENET PORTNAME OSAE204 SOURCEVIPAINT VLINK1 IPADDR 192.168.1.65/24 MTU 1492 VMAC ROUTEALL 2 HOME 192.168.3.164 VLINK1 192.168.3.64 OSAE200LNK

OSAE200 VMAC 020012345678 1

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

OSAE200 VMAC 020087654321 1

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.

9.2.1 Verification We 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).


127

Example 9-3 Display VMACs of both OSA-Express3 ports on TCPIPA D TCPIP,,N,DEV DEVNAME: 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,DEV DEVNAME: 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.

128


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 Local MAC address Universal MAC address

1000Base-T Ethernet 00145E74AA6C 00145E74AA6C

INFORMATION FOR PORT 1 ---------------------Port type Local MAC address Universal MAC address

1000Base-T Ethernet 00145E74AA6D 00145E74AA6D 5

START OF OSA ADDRESS TABLE -------------------------UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01) CULA 00 00(E200)* MPC n/a OSAE200 (QDIO control) SIU ALL 02(E202) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL

HOME HOME

03(E203)

VMAC 020012345678 020012345678

IP Address 192.168.3.64 192.168.3.164

Group Address Multicast Address 01005E000001 224.0.0.1 MPC 0 No4 No6 OSAE200 (QDIO data)

HOME HOME

VMAC 020087654321 020087654321

IP Address 192.168.3.4 192.168.3.165

Group Address 01005E000001

Multicast Address 224.0.0.1

04(E204)* MPC n/a OSAE204 (QDIO control) 06(E206) MPC 1 No4 No6 OSAE204 (QDIO data)

HOME HOME

N/A MPC 1

HOME HOME

ALL

SIU ALL SIU ALL

VMAC IP Address 02000D74AA6D 7 192.168.1.65 02000D74AA6D 192.168.1.164 Group Address 01005E000001

07(E207) 08(E208)

SIU


No4 No6 OSAE204 (QDIO data)

N/A SIU

CSS ALL

VMAC IP Address 02000B74AA6D 7 192.168.1.5 02000B74AA6D 192.168.1.165


129

130


10

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.


131

10.1 VLAN overview A VLAN is a group of workstations with a common set of requirements, independent of physical location. VLANs have the same attributes as a physical LAN, even though they may not be located physically on the same LAN segment. VLANs can be used to increase bandwidth and reduce overhead by allowing networks to be organized for optimum traffic flow. Figure 10-1 shows an example of VLANs segmented into logically defined networks.

Engineering VLAN

Marketing VLAN

Accouting VLAN

Switch 3

Switch 2

Switch 1

Figure 10-1 Logically defined networks using VLANs

10.1.1 Types of connections IEEE 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

132


generated by VLAN-aware equipment are marked with a tag, which identifies the frame to the VLAN.

Trunk mode Trunk mode indicates that the switch should allow all VLAN ID tagged packets to pass through the switch port without altering the VLAN ID. This mode is intended for servers that are VLAN capable, and filters and processes all VLAN ID tagged packets. In trunk mode, the switch expects to see VLAN ID tagged packets inbound to the switch port.

Access mode Access mode indicates that the switch should filter on specific VLAN IDs and only allow packets that match the configured VLAN IDs to pass through the switch port. The VLAN ID is then removed from the packet before it is sent to the server. That is, VLAN ID filtering is controlled by the switch. In access mode, the switch expects to see packets without VLAN ID tags inbound to the switch port.

Hybrid mode Hybrid mode is a combination of the previous two modes. This is a port where both VLAN-aware and VLAN-unaware devices are attached. A hybrid port can have both tagged and untagged frames. Figure 10-2 shows a logical diagram of a VLAN environment with two switches and a number of VLANs.

VLAN 101

Server

HUB 1 Access ports

Trunk port

Access port TRUNK PORT

Switch 1

VLAN 100

Switch 2

VLAN 102

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.

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 VLANs All ports that are members of the same VLAN, including trunk ports, operate as though they are part of the same physical network. When a multicast or broadcast frame is received from a device on a particular VLAN, the switch transmits the frame to all ports (both trunk and access ports) belonging to the same VLAN. The only difference between the trunk and access port in this case is that the frame transmitted onto the trunk port will have the VLAN tag intact, so that the VLAN-aware equipment at the other end of the link knows how to handle it.

VLAN isolation An important point about VLANs in general is that they provide isolation. VLANs behave like separate physical networks, even though they may be contained within the same switch. In order for devices in different VLANs to communicate, IP routing must occur. In the network shown in Figure 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 basics In a VLAN environment, you find two types of frames: 򐂰 Untagged frames There is no tag header following the source MAC address. 򐂰 Tagged frames – Priority-tagged frame The tag header includes only VLAN priority information, but no VLAN ID. (VLAN ID is zero and is referred to as a null-tagged frame.) – VLAN-tagged frame The tag header includes both VLAN priority information and VLAN ID.

134


Figure 10-3 illustrates these descriptions.

Dest MAC address

Source MAC address

Type/Length

Ethernet header (untagged)

Dest MAC address

Source MAC address

Tag Control Info (4 Bytes)

Type/Length

Ethernet header (tagged) VLAN Tag x'8100'

3-bit Priority

1-bit Canonical (always zero)

12-bit VLAN ID

Figure 10-3 VLAN tagging

10.2 General VLAN design considerations We 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 . 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. 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. 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.


135

10.2.1 VLAN configuration example When 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)

z/VM LINUX1

z/OS

z/OS

z/VM

LINUX2

IP-stack #1

IP-stack #2

IP-stack #3

IP-stack #4

IP-stack #5

VLAN ID 100

VLAN ID 200

VLAN ID 300

No VLAN ID

No VLAN ID

OSA #2

OSA #1 VLAN aware (Tagged frames)

VLAN unaware (Untagged frames)

Trunk connection for VLAN 100, 200 and 300

Trunk Mode

Ethernet Switch

Access Mode VLAN 100



Clients 1 and 2

Clients 3 and 4

Clients 5 and 6

Access connection for VLAN 400


Router

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


10.2.2 Sharing an OSA port with the same VLAN ID Figure 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.

z/VM

LINUX1

LINUX2

z/OS

IP-stack #1

IP-stack #2

IP-stack #4

VLAN ID 2

VLAN ID 3

VLAN ID4

z/OS IP-stack #4

z/OS IP-stack #5

10.1.0.1/24

10.2.0.1/24

VLAN ID 100

VLAN ID 100

OSA

OSA

ETHERNET Switch Access Mode VLAN 2

Trunk Mode Access Mode VLAN 3

Access Mode VLAN 4

Router

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

10.2.3 Primary and secondary router support with VLANs OSA 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. 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.


137

10.2.4 Operating system support As 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. 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.

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

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


TCP/IP A

LNXSU10

IP Address

192.168.3.64

DEVICE INTERFACE

OSAE200

OSAE204I

OSAE205I

VLAN IDs

980

981

982

VTAM Portname Device Number

OSAE200

TCPIP01

VLAN 982 192.168.3.60 VLAN984 192.168.5.60

VLAN 981 192.168.1.10

Linux

Linux

z/VM V5.4

NIC

NIC

NIC

VSWITCH (Layer 2)

OSAE204

TCP/IP

z/OS V1R10 E200-E203

CHPID 0A Port 0

LNXRH5

VLAN 981 192.168.1.60 OSA2D80 VLAN982 192.168.2.60

192.168.1.65 192.168.2.65

OSAE200

z/VM

E204-E207

Shared OSA ports in QDIO mode Port 1

OSAE204



Ethernet Switch

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 ID The 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 ports It 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 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 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.


139

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 address speed 1000

Define a TRLE in VTAM to represent each OSA port 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 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, 140


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 ; HOME 192.168.1.164 VLINK1 192.168.3.64 OSAE200LNK ; BEGINROUTES ROUTE 192.168.3.0/24 ENDROUTES ; START OSAE200

OSAE200 VLANID 980

= OSAE200LNK MTU 1492

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.


141

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 ROUTE 192.168.2.0/24 ENDROUTES ; START OSAE204I START OSAE205I

= OSAE204I MTU 1492 = OSAE205I MTU 1492

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

142


10.3.3 Verification After 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 Chapter 10. VLAN support

143

CFGROUTER: NON ARPOFFLOAD: YES CFGMTU: 1492 IPADDR: 192.168.2.65/24 VLANID: 982 DYNVLANREGCFG: NO READSTORAGE: GLOBAL (4096K) CHECKSUMOFFLOAD: YES SECCLASS: 255 MULTICAST SPECIFIC: MULTICAST CAPABILITY: YES

ACTROUTER: NON ARPOFFLOADINFO: YES ACTMTU: 1492 VLANPRIORITY: DISABLED DYNVLANREGCAP: YES INBPERF: BALANCED MONSYSPLEX: NO

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 00 00(E200)* MPC n/a OSAE200 (QDIO control) SIU ALL 02(E202) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL IPv4 VLAN 980

HOME HOME HOME

VMAC 020012345678 020012345678 020012345678

IP Address 192.168.1.164 192.168.2.164 192.168.3.64

Group Address Multicast Address 01005E000001 224.0.0.1 03(E203) MPC n/a No4 No6 OSAE200 (QDIO data) 04(E204)* MPC n/a OSAE204 (QDIO control) 06(E206) MPC 1 No4 No6 OSAE204 (QDIO data) IPv4 VLAN 981

HOME HOME

VMAC 02001B74AA6D 02001B74AA6D

IP Address 192.168.1.65 192.168.1.164

Group Address Multicast Address 01005E000001 224.0.0.1 07(E207) MPC 1 No4 No6 OSAE204 (QDIO data) IPv4 VLAN 982

HOME 144

VMAC 02001C74AA6D


S ALL SIU ALL SIU ALL

IP Address 192.168.2.65

SIU

ALL

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 Linux VLAN 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 All bugs added by David S. Miller

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.


145

LINUX 2: vconfig add eth1 200 ifconfig eth1.200 200.1.1.1 netmask 255.255.255.0 up

LINUX2

LINUX3 LINUX3

ETH1 VLAN 200 200.1.1.1

ETH1 VLAN 210 210.1.1.1

z/VM

LINUX 3: OSA

vconfig add eth1 210 ifconfig eth1.210 210.1.1.1 netmask 255.255.255.0 up

Trunk connection to support VLAN 200 and 210 traffic

Ethernet Switch

Trunk Mode



Client 1

Client 2

Port assigment for the Ethernet Switch Port Type

VLAN ID

Connection

2/1 2/5 2/6

n/a VLAN 200 VLAN 210

OSA-Express Client 1 Client 2

TRUNK ACCESS ACCESS

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 commands On LINUX2 and LINUX3, we defined the VLAN configurations and brought up the interfaces, using the following commands: 򐂰 LINUX2 vconfig add eth1 200 ifconfig eth1.200 200.1.1.1 netmask 255.255.255.0 up

򐂰 LINUX3 vconfig add eth1 210 ifconfig eth1.210 210.1.1.1 netmask 255.255.255.0 up

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 down vconfig rem eth1.200

146


Startup configuration Configuring VLANs is a manual process that must be scripted to take place when the Linux guests are booted. As VLAN usage grows, you can expect to see that Linux distributors will automatically include VLAN boot-time configuration in their network scripts.

Ethernet switch configuration We 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 Verification We 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

ifconfig eth1.210 Link encap:Ethernet HWaddr 00:06:29:6C:A5:BC inet addr:210.1.1.1 Mask:255.255.255.0 inet6 addr: fe80::6:2900:56c:a5bc/10 Scope:Link UP RUNNING MULTICAST MTU:1492 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:148 (148.0 b) We 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 #vtp set vtp domain itso_network set vtp mode transparent set vlan 1 name default type ethernet mtu 1500 said 100001 state active set vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state active set vlan 210 name VLAN0300 type ethernet mtu 1492 said 100201 state active #spantree #portfast set spantree global-default bpdu-guard enable ! #module 2 : 48-port 10/100BaseTX Ethernet set vlan 200 2/5 set vlan 210 2/6 set trunk 2/1 set trunk 2/2

on dot1q 1-1005,1025-4094 on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enable set spantree guard none 2/1-48


147

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 support In 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. PROFILE TCP/IP

z/VM V5R4 TCP/IP

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


VLAN ID 200 OSA

Port assigment for the Ethernet Switch Port Type

VLAN ID

Connection

2/1 2/5

n/a VLAN 200

OSA-Express Client 1

TRUNK ACCESS

Trunk connection to support VLAN 200 traffic

Ethernet Switch

Trunk Mode Access Mode VLAN 200

Client 1

Figure 10-8 z/VM VLAN configuration

Ethernet switch configuration We 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.

148


10.5.2 Verification After 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 #vtp set vtp domain itso_network set vtp mode transparent set vlan 1 name default type ethernet mtu 1500 said 100001 state active set vlan 200 name VLAN0200 type ethernet mtu 1492 said 100200 state active #spantree #portfast set spantree global-default bpdu-guard enable ! #module 2 : 48-port 10/100BaseTX Ethernet set vlan 200 2/5 set trunk 2/1

on dot1q 1-1005,1025-4094

set spantree portfast 2/1-48 enable set spantree guard none 2/1-48 We successfully 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.


149

150


11

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.


151

11.1 Virtual switch description The 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).

z/VM Control Program Guest 1

Guest 2

Guest 3

NIC

NIC

NIC

Port 1

Port 2

Port 3 Real Device

Virtual Switch

Ethernet Switch OSA Port

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.

152


11.1.1 VSWITCH controller VSWITCH 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. 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.

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 addresses A 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 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 capabilities In 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 support Layer 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 mode In 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 mode In 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.

154


򐂰 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 support VLAN 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 mode An 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 support Through 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.

Chapter 11. z/VM virtual switch

155

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 support Link 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 environment Figure 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. 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. 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)

156


z/OS V1R10

z/VM V5R4

LNXSU10

eth1

eth0

LNXRH5

eth0

eth1

L2SW1 L2SW2

VTAM / TRL

E200-E202 E204-E206

2D80-2D82 2D84-2D86

CHPID 0A Port 0

Port 1

CHPID 0B Port 0

Port 1

Ethernet Switch T = Trunk Mode A = Access Mode

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 Tip: We recommend checking the appropriate Preventive Service Planning buckets for required APARs and PTFs before implementing the VSWITCH in your environment. 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.


157

11.3 Configuring a Layer 2 VSWITCH In 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.

z/OS V1R10

z/VM V5R4

LNXSU10

TCP/IP OSAE200I 192.168.3.65/24 OSAE204I 192.168.1.65/24 OSAE205I 192.168.2.65/24 VTAM / TRL2 E200-E202 E204-E206

LNXRH5

192.168.3.60

192.168.3.61

192.168.1.60

192.168.1.61

192.168.2.60

192.168.2.61

eth1

eth0

eth0

eth1

L2SW1 L2SW2

E200-E202 E204-E206 2D80-2D82 2D84-2D86

CHPID 0A Port 0

Port 1

CHPID 0B Port 0

Port 1


192.168.3.2

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

158


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. 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 VMLAN In addition, you can add a VMLAN statement to the CP SYSTEM CONFIG file, which overrides the system-wide MAC address definitions used when generating local MAC addresses for 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 Tip: If you run multiple z/VM systems on a System z server, change the MACPREFIX of each system to avoid MAC address duplication. 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 switch To 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


159

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

VSWITCH VSWITCH VSWITCH VSWITCH

L2SW1 L2SW2 L2SW1 L2SW2

GRANT GRANT GRANT GRANT

LNXSU10 LNXSU10 LNXRH5 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 SET SET SET

VSWITCH VSWITCH VSWITCH VSWITCH

L2SW1 L2SW2 L2SW1 L2SW1

GRANT GRANT GRANT GRANT

LNXSU10 LNXSU10 LNXRH5 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 VSWITCH To 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. 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. 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 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.

160


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

Checking the controller To 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: * Capability: IP ETHERNET VLAN_ARP GVRP LINKAGG SYSTEM L2SW1 Backup Controller: * Controller DTCVSW2 Available: YES VDEV Range: * Capability: IP ETHERNET VLAN_ARP GVRP LINKAGG SYSTEM L2SW1 Primary Controller: *

Level ISOLATION VDEV: Level ISOLATION VDEV:

540 2D80 540 E200

Checking the VSWITCH To 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 VMLAN If 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).


161

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 authorization To 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 NICs To 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: 162


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 systems We 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 up ifconfig 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. 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. 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 Hat For 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


163

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 eth1 Oct 20 15:48:55 linux-su10 ifup: eth1 Oct 20 15:48:55 linux-su10 ifup: eth1 configuration: qeth-bus-ccw-0.0.8000 Oct 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 rtr4 rtr6 ----------------------------- ---0.0.7000/0.0.7001/0.0.7002 no no 0.0.8000/0.0.8001/0.0.8002 no no

CHPID interface

cardtype

port chksum prio-q'ing

----- ---------- -------------- ---- ------ ---------x03

eth0

GuestLAN QDIO

0

sw

always_q_2

x04

eth1

GuestLAN QDIO

0

sw

always_q_2

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 164


TX Packets: 34 Discarded: 0 Errors: 0 RX Bytes: 0 TX Bytes: 8028 Device: E200 Unit: 000 Role: DATA vPort: 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 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 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

Index: 0001

Index: 0067

Index: 0066

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 definitions SUSE 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 Chapter 11. z/VM virtual switch

165

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'

166


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 QETH DEVICE=eth1 VSWITCH=1 OPTIONS="layer2=1" BOOTPROTO=none IPADDR=192.168.1.61 NETMASK=255.255.255.0 NETTYPE=qeth ONBOOT=yes SUBCHANNELS=0.0.8000,0.0.8001,0.0.8002 TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=yes

11.4 Configuring VLAN support To 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. Chapter 11. z/VM virtual switch

167

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.

z/VM V5R4

z/OS V1R10

LNXSU10

TCP/IP VLAN 980 / OSAE200I 192.168.3.65/24 VLAN 981 / OSAE204I 192.168.1.65/24 VLAN 982 / OSAE205I 192.168.2.65/24 VTAM / TRL2 E200-E202 E204-E206

E200-E202 E204-E206

eth0

LNXRH5

VLAN 980

VLAN 980

192.168.3.60

192.168.3.61

VLAN 981

VLAN 981

192.168.1.60

192.168.1.61

VLAN 982

VLAN 982

192.168.2.60

192.168.2.61

eth1

eth0

L2SW1 L2SW2

E200-E202 E204-E206

2D80-2D82 2D84-2D86

CHPID 0A

CHPID 0B Port 0


eth1

Port 1

Port 0

Port 1

VLAN 980 - 999 VLAN 980

192.168.3.2

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 switch When 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

168


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.

Define Virtual Switch

YES

Porttype Trunk ?

NO

Define Virtual Switch (Access Mode and default VLAN ID )

Authorize Guest access to default Porttype & VLAN ID ......

Done

Define Virtual Switch (Trunk Mode)

SET VSWITCH VSWTCH1 GRA LNXSU1

DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CONR * ETH VLAN 100 PORT OSACHP0D OSACHP0E

Go to flowchart in:

Figure 11-6 on page 170

DEFINE VSWITCH VSWTCH1 RDEV 2D40 3D44 CONR * ETH VLAN 100 PORTT TRUNK PORT OSACHP0D OSACHP0E

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 IDs You 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 Chapter 11. z/VM virtual switch

169

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.

Virtual Switch defined in TRUNK Mode with VLAN ID

Guest inherits Virtual Switch defaults ?

NO

Change both defaults ?

Change VLAN ID ?

YES

YES Authorize Guest access with default Portype & VLAN ID ......

NO

Authorize Guest access with new Porttype and VLAN ID ......

YES

Authorize Guest access with new VLAN ID .....

NO

Authorize Guest access with new Porttype .....

Prepare LINUX Setup

Done Prepare LINUX Setup

Done

Done

SET VSWITCH VSWTCH1 GRA LNXSU1 SET VSWITCH VSWTCH1 GRA LNXSU1 PORTT ACCESS VLAN 200

Done

SET VSWITCH VSWTCH1 GRA LNXSU1 PORTT ACCESS SET VSWITCH VSWTCH1 GRA LNXSU1 VLAN 200

Figure 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-982 SET VSWITCH L2SW1 GRA LNXRH5 VLAN 980-982

11.4.3 Adding VLANs to the guest systems To 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. 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.

170


Defining VLAN support for SUSE and Red Hat Previous 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. 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. 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 980 Added VLAN with VID == 990 to IF -:eth1:linux-su10:/ # ifconfig vlan980 192.168.3.60 netmask 255.255.255.0 linux-su10:/ # ifconfig vlan980 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: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 980 Added 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.980 eth1.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


171

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=Ethernet DEVICE=eth1.980 VLAN=yes BOOTPROTO=none NETMASK=255.255.255.0 IPADDR=192.168.3.61 ONBOOT=yes USERCTL=no IPV6INIT=no PEERDNS=yes 172


NETTYPE=qeth

11.4.4 Adding VLAN support to the z/OS TCP/IP stacks To enable VLAN support for the z/OS TCP/IP stacks, we add the VLAN ID parameter to the 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 connections In 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 Note: In a production environment, multiple OSA ports should be connected to at least two different Ethernet switches to avoid single points of failure.

11.4.6 Verifying the VLAN After completing the configuration tasks, we verified the VLAN environment.


173

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 174


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

No6

z/VM0001 (QDIO data)

SIU ALL

980 981 982

020000000004 020000000006

(VMAC) (VMAC) Chapter 11. z/VM virtual switch

175

01005E000001 01005E0000FB 333300000001 3333000000FB 3333FF000004 3333FF000006

(Group (Group (Group (Group (Group

MAC) MAC) MAC) MAC) MAC)

(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 isolation Port 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.

176


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.

z/OS V1R10

z/VM V5R4

LNXSU10

TCP/IP VLAN 980 / OSAE200I 192.168.3.65/24 VLAN 981 / OSAE204I 192.168.1.65/24 VLAN 982 / OSAE205I 192.168.2.65/24 VTAM / TRL2 E200-E202 E204-E206

E200-E202

eth0

LNXRH5

VLAN 980

VLAN 980

192.168.3.60

192.168.3.61

VLAN 981

VLAN 981

192.168.1.60

192.168.1.61

VLAN 982

VLAN 982

192.168.2.60

192.168.2.61

eth1

eth0

eth1

L2SW1 L2SW2

E204-E206

E200-E202

E204-E206

Port 0

Port 1

CHPID 0A Ethernet Switch T = Trunk Mode A = Access Mode

VLAN 980 - 999 VLAN 980

192.168.3.2

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.


177

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 OSA Example 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 178


RX Bytes: 43121 TX Bytes: 13234 Device: 8002 Unit: 002 Role: DATA vPort: 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

Index: 0066

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 OSA Example 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 Chapter 11. z/VM virtual switch

179

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

Index: 0066

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

180


020000000004 020000000006

(VMAC) (VMAC)

01005E000001 01005E0000FB 01005E000116

(Group MAC) (Group MAC) (Group MAC)

02(E202)* 03(E203) 04(E204) 05(E205) 06(E206) 07(E207) 08(E208) 09(E209) 0A(E20A) 0B(E20B)

MPC N/A N/A N/A N/A N/A N/A N/A N/A N/A

n/a

01005E7FFFFD (Group MAC) 333300000001 (Group MAC) 3333000000FB (Group MAC) 3333000000FB (Group MAC) 3333FF000004 (Group MAC) z/VM0001 (QDIO control)

SIU N/A N/A N/A N/A N/A N/A N/A N/A N/A

ALL CSS CSS CSS CSS CSS CSS CSS CSS CSS

11.6 Configuring link aggregation support The 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 aggregation For 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.


181

Figure 11-8 depicts our VSWITCH environment with link aggregation.

z/VM V5R4

LNXSU10

LNXRH5

NIC

NIC

Port

Port

VSWITCH Controller DTCVSW1

VSWITCH Controller DTCVSW2

Load Balancer Aggregator/Multiplexor

VSWITCH LACP

Ethernet Switch

LACP

Port 1

Port 2

OSA E200.P01

OSA 2D80.P01

Port 1/14

Port 1/16

Figure 11-8 Our VSWITCH environment with link aggregation

Setting up the port group If 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 VSWITCH We 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.

182


11.6.2 Setting up the external Ethernet switch In 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 terminal vm6509(config)#interface range gigabitEthernet 1/14 vm6509(config-if-range)#no ip address vm6509(config-if-range)#channel-protocol lacp vm6509(config-if-range)#channel-group 10 mode active Creating a port-channel interface Port-channel 10 vm6509(config-if-range)#exit vm6509#configure terminal vm6509(config)#interface range gigabitEthernet 1/16 vm6509(config-if-range)#no ip address vm6509(config-if-range)#channel-protocol lacp vm6509(config-if-range)#channel-group 10 mode active Creating a port-channel interface Port-channel 10 vm6509(config-if-range)#exit

Example 11-38 Ethernet switch channel-port configuration

vm6509(config)#interface port-channel 10 vm6509(config-if)#switchport trunk encapsulation dot1q vm6509(config-if)#switchport mode trunk vm6509(config-if)#no shutdown vm6509(config-if)#end

11.6.3 Verifying the configuration To 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:


183

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 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 Unicast IP Addresses: 192.168.3.6 MAC: 02-00-00-00-00-09 Remote Ready; T=0.01/0.01 11:15:48

Index: 0002

Index: 0001

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 184


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 VLAN: 0980 0981 0982 Options: Ethernet Broadcast Unicast MAC Addresses: 02-00-00-00-00-0B IP: 192.168.3.60 Multicast MAC Addresses: ...

Index: 0068

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

980 981 982 983

020000000004 02000000000B 02000000000E 020000000010

(VMAC) (VMAC) (VMAC) (VMAC)

01005E000001 01005E0000FB 01005E000116 01005E7FFFFD 0180C2000002 333300000001

(Group (Group (Group (Group (Group (Group

MAC) MAC) MAC) MAC) MAC) MAC)


185

186


A

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.


187

OSA feature descriptions Table 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 code

Connector type

Cable type

Maximum unrepeated distancea

Server

OSA-Express GbE LX

1364

LC Duplex

SM 9 µm

5 km

z9 EC, z9 BCb

MCPc

550 m (500)

OSA-Express GbE LX

2364

SM 9 µm

5 km

MCPc

550 m (500)

OSA-Express GbE SX

1365

MM 62.5 µm

220 m (166) 275 m (200)

MM 50 µm

550 m (500)

MM 62.5 µm

220 m (166) 275 m (200)

MM 50 µm

550 m (500)

Feature name

OSA-Express GbE SX

188

2365

SC Duplex

LC Duplex

SC Duplex

z9 EC, z9 BCb

z9 EC, z9 BCb

z9 EC, z9 BCb

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

OSA-Express3 GbE SX

3363

c

OSA-Express2 GbE LX

3364

OSA-Express2 GbE SX

3365

LC Duplex

LC Duplex

LC Duplex

MCP

550 m (500)

MM 62.5 µm

220 m (166) 275 m (200)

MM 50 µm

550 m (500)

SM 9 µm

5 km

MCPc

550 m (500)

MM 62.5 µm

220 m (166) 275 m (200)

MM 50 µm

550 m (500)

z10 EC, z10 BC

z10 EC, z10 BC z9 EC, z9 BC z10 EC, z10 BC z9 EC, z9 BC


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-Express2 10 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


OSA-Express3 10 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

MM 62.5 µm

220 m (166) 275 m (200)

MM 50 µm

550 m (500)

LC Duplex

z10 BC

a. Minimum fiber bandwidth in MHz/km for multimode fiber optic links are included in parentheses where applicable. b. Carried forward only c. Mode Conditioning Patch (MCP) cables enables the 1 Gbps single mode features to connect to multimode fiber.

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

OSA-Express3 10 Gigabit Ethernet Long Reach (10 GbE LR) feature Feature 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) feature Feature 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

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. The following Ethernet standards are applicable for this feature: 10GBASE-SR (standard transmission scheme) – – – –


OSA-Express3 Gigabit Ethernet long wavelength (GbE LX) feature Feature 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. The following Ethernet standards are applicable for this feature: 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) feature Feature 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).

190


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. The following Ethernet standards are applicable for this feature: 1000BASE-SX (standard transmission scheme) – – – – –


OSA-Express3-2P Gigabit Ethernet short wavelength (GbE SX) feature Feature 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. The following Ethernet standards are applicable for this feature: 1000BASE-SX (standard transmission scheme) – – – – –


OSA-Express3 1000BASE-T Ethernet feature Feature 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. Appendix A. OSA features

191

Note: If CHPID type OSC is defined, only one of the two corresponding physical ports (port 0) can be used for OSA-ICC. 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. The following Ethernet standards are applicable for this feature: 򐂰 10BASE-T (standard transmission scheme) – – – –

IEEE 802.2 IEEE 802.3 ISO/IEC 8802-3 DIX Version 2

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

IEEE 802.1p IEEE 802.1q IEEE 802.3ab IEEE 802.3ac IEEE 802.3u IEEE 802.3x

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 192


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. Note: If CHPID type OSC is defined, only one of the two corresponding physical ports (port 0) can be used for OSA-ICC). 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: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰


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-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. The following Ethernet standards are applicable for this feature: 򐂰 10BASE-T (standard transmission scheme) – – – –


򐂰 100BASE-TX (standard transmission scheme) – IEEE 802.3u 򐂰 1000BASE-T (standard transmission scheme) – IEEE 802.1p – IEEE 802.1q – IEEE 802.3ab Appendix A. OSA features

193

– IEEE 802.3ac – IEEE 802.3u – IEEE 802.3x

OSA-Express2 10 Gigabit Ethernet Long Reach (10 GbE LR) feature Feature 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. The following Ethernet standards are applicable for this feature: 10GBASE-LR (standard transmission scheme) – – – –


OSA-Express2 Gigabit Ethernet long wavelength (GbE LX) feature Feature 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. The following Ethernet standards are applicable for this feature: 1000BASE-LX (standard transmission scheme) – – – – –


OSA-Express2 Gigabit Ethernet short wavelength (GbE SX) feature Feature 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).

194


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. The following Ethernet standards are applicable for this feature: 1000BASE-SX (standard transmission scheme) – – – – –


OSA-Express2 1000BASE-T Ethernet feature Feature 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: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰


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

Appendix A. OSA features

195

The following Ethernet standards are applicable for this feature: 򐂰 10BASE-T (standard transmission scheme) – – – –


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

196

IEEE 802.1p IEEE 802.1q IEEE 802.3ab IEEE 802.3ac IEEE 802.3u IEEE 802.3x


B

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.


197

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

198


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 = 0707 IST1577I HEADER SIZE = 4096 DATA SIZE = 0 STORAGE = ***NA*** IST1221I WRITE DEV = E201 STATUS = ACTIVE STATE = ONLINE IST1577I HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA*** IST1221I READ DEV = E200 STATUS = ACTIVE STATE = ONLINE IST1221I DATA DEV = E202 STATUS = ACTIVE STATE = N/A IST1724I I/O TRACE = OFF TRACE LENGTH = *NA* IST1717I ULPID = TCPIPA

Defining TRLE definitions Use 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 E200 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

VOLSTATE

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 definitions An 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 DEFINITION DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET HOME 192.168.1.64 OSAE200LNK START OSAE200

OSAE200 VLANID 980 VMAC 020012345678

After TCP/IP is started, you can also see the OAT entries using OSA/SF (see Example B-5 on page 201).

200


Example: B-5 OAT entries START OF OSA ADDRESS TABLE -------------------------UA(Dev) Mode Port Entry specific information Entry Valid ******************************************************************************** Image 0.1 (A01) CULA 00 00(E200)* MPC n/a OSAE200 (QDIO control) SIU ALL 02(E202) MPC 0 No4 No6 OSAE200 (QDIO data) SIU ALL IPv4 VLAN 980

HOME HOME

03(E203)

VMAC 020012345678 020012345678

IP Address 192.168.1.64 192.168.1.164

Group Address Multicast Address 01005E000001 224.0.0.1 MPC 0 No4 No6 OSAE200 (QDIO data)

HOME HOME

VMAC 020087654321 020087654321

IP Address 192.168.1.4 192.168.1.165



SIU

ALL

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. 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. 1. Log on to the Support Element (SE) on the Hardware Management Console (HMC) through Single Object Operations (SOO). 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. 2. Select the CPC you want to work with, as shown in Figure B-2 on page 202.


201

Figure B-2 From the HMC, log on to SE

3. Select and open the Service task list; see Figure B-3.

202


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. Appendix B. OSA-Express Network Traffic Analyzer

203

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

204


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.


205

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

206


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. Important: For checking the authorization of OSAENTA support, the user ID must have the Access Administrator Tasks role assigned. – 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 RACF See 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


207

Allocating a VSAM linear data set Example 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) + CLUSTER DEFINE 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 trace The 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. 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. 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 CTRACE The 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. Note: Update CTINTA00 to set the CTRACE buffer size. Keep in mind that this will use up auxiliary page space storage.

Using the OSAENTA command An 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.

208


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 traces You 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 tracing OSAENTA 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 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.

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

Figure B-14 OSAENTA results


209

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

210


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 02(2082) MPC 00 No4 No6 OSA2080P VLAN 10 (IPv4)

HOME HOME HOME HOME REG REG REG REG REG REG REG REG REG 03(2083)

(QDIO control) (QDIO data)



VMAC 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490 00096B1A7490

IP address 010.001.000.010 010.001.001.010 010.001.002.010 010.001.002.011 010.001.002.012 010.001.003.011 010.001.003.012 010.001.004.011 010.001.005.011 010.001.006.011 010.001.007.011 010.001.008.010 010.001.008.020

MPC 00 No4

No6

OSA2080P

(QDIO data)

SIU SIU

ALL ALL

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


211

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

212


-------------------------------------------------------------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 trace There 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 dump and options; see Example B-14 for details.

- Specify default

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 Address Message Message Display

==> DSNAME('SYS1.SC30.CTRACE') Space ==> Routing ==> NOPRINT TERMINAL Control ==> CONFIRM VERIFY FLAG(WARNING) Content ==> NOMACHINE REMARK REQUEST NOSTORAGE SYMBOL

Modify the DSNAME and OPTIONS to match your environment, then select the following options: 򐂰 򐂰 򐂰 򐂰

2 7 1 D

ANALYSIS - Analyze dump contents TRACES - Trace formatting CTRACE - Component trace DISPLAY - Specify parameters to display CTRACE entries


213

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 Component Subnames

------------------------

===> (System name or blank) ===> SYSTCPOT (Component name (required)) ===> TCPIPA

GMT/LOCAL ===> G Start time ===> Stop time ===> Limit ===> 0 Report type ===> SHORT User exit ===> Override source ===> Options ===>

(G or L, GMT is default) (mm/dd/yy,hh:mm:ss.dddddd or mm/dd/yy,hh.mm.ss.dddddd) Exception ===> (SHort, SUmmary, Full, Tally) (Exit program name)

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

214


Packet Length Fragment TTL Source Destination

: : : : :

68 1 10.1.2.11 224.0.0.5

ID Number: 0AFD Offset: 0 Protocol: OSPFIGP

CheckSum: C253

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


215

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 problems IBM 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

216


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. IBM Tivoli Software or other Network Management vendor

Remote monitor SNMP

CS z/OS and components

I n s t r u m e Exit n point t a t i o n

APIs

Private protocol

Presentation

Local monitor

Commands/Utilities Exit points SNMP

SMF and Syslogd

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


217

򐂰 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

References Refer 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/IBMTivoliOMEGAMONXEforMainframeNetworks 1.0.html

218


C

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.


219

HMC advanced facilities for OSA The advanced facilities (Open Systems Adapter Support Facility (OSA/SF)) available on the HMC are as follows. Note: These functions are used for troubleshooting under the guidance of IBM Product Engineering. 򐂰 򐂰 򐂰 򐂰

Set Trace Buffer Read Trace Buffer Export Trace/Dump file to diskette Card-specific advanced facilities, with the following 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.

220


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 OSA These trace functions are used to troubleshoot under the guidance of IBM Product Engineering.

Setting Trace Mask on the OSA card Follow 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

222


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 card Follow 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


223

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-Express In 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

224


Enable or disable ports on OSA-Express Cards In the Advanced facilities window, select Enable or disable ports and click OK. The Enable or disable ports window (Figure C-10) opens. Note: Enabling or disabling the port is also possible with an OSA/SF function.

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 Card In 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 Card In the Advanced facilities window (see Figure C-9 on page 224), select Run port diagnostics and click OK.


225

Note: You can use port diagnostics only if the port is disabled.

View port parameters on an OSA-Express Card In 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 Card Follow these steps: 1. In the Advanced facilities window, select Display or alter MAC address and click OK. 2. The Display or alter MAC address window (Figure 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.

226


Figure C-13 Display or alter MAC address window

Settings for speed and mode on an OSA 1000BASE-T card Follow these steps: 1. In the Advanced facilities window, select Set card mode and click OK. 2. In the Set card mode window (Figure 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. Note: The settings made here override the capability of the OSA 1000BASE-T auto negotiation facility.

Figure C-14 Ethernet Speed/Mode settings window


227

OSA reset to defaults Follow 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 level The 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.

228


Configuring OSA channels on/off With 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 Element To gain access to all channel functions, start a session from the HMC to the SE as follows: 1. From the Defined CPCs Work Area on the HMC, complete these steps: a. Select the appropriate CPC Object and drag and drop it onto the Single Object Operations icon in the CPC Recovery task list. b. In the Single Object Selection window (Figure 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.


229

Figure C-18 Support Element CPC Work Area

CHPID Configure on/off The 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.

230


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. Note: The state Standby is the indicator of an offline CHPID to the LPAR. Complete the following steps: a. Read the warning information regarding configuring channels from the Support Element function rather than from an available operating system 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. Note: Before you click Apply in the next step, ensure that only the CHPID or CHPIDs that you want toggled are highlighted.

b. In all cases, click Apply to immediately change the desired channel state. Appendix C. HMC and SE tasks for OSA

231

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

232


Figure C-21 Logging off the Support Element


233

234


D

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.


235

z/OS commands We used the following z/OS commands in this publication. For a complete list and description of TCP/IP Console and TSO commands, refer to IP Systems Administration Commands, SC31-8781. Table 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.

236


Table D-2 TCP/IP TSO commands Command

Description

NETSTAT ?

Displays Netstat options

NETSTAT ARP ALL

Displays ARP cache

NETSTAT DEV

Displays the TCP/IP devices and links

NETSTAT HOME

Displays the TCP/IP Home IP addresses

NETSTAT GATE

Displays the TCP/IP Gateway addresses

PING ipaddress

Performs one PING to specified address

TRACERTE ipaddress

Traces router hops to a specified address

OBEYFILE

Executes selected TCP/IP profile statements

Table D-3 VTAM commands 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 commands For 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 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

Table D-5 z/VM TCP/IP commands Command

Description

NETSTAT ?

Displays Netstat options

NETSTAT ARP

Displays the ARP cache

NETSTAT DEV

Displays the TCP/IP devices and links

NETSTAT HOME

Displays the TCP/IP Home IP addresses

NETSTAT GATE

Displays the TCP/IP Gateway addresses

NETSTAT OBEY START|STOP DEV

Starts or stops the device name identified in NETSTAT DEV output

IFCONFIG (z/VM4.3)

Displays the TCP/IP devices and links (similar to the NETSTAT DEV command, but has other uses; see note)

PING ipaddress

Performs one PING to a specified address

TRACERTE ipaddress


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.

238


Table D-6 z/VM Virtual Switch commands Command

Description

DEFINE VSWITCH

Defines the virtual switch and attributes

DEFINE NIC

Defines the simulated network interface card (NIC)

COUPLE

Helps to connect the NIC to the virtual switch

SET VSWITCH

Controls the attributes of an existing virtual switch

QUERY CONTROLLER

Displays the controller service machines

QUERY VSWITCH

Displays information about the virtual switch

QUERY VSWITCH DETAILS

Displays detail information about the virtual switch

QUERY VSWITCH name ACCESS

Displays authorized user IDs

QUERY VMLAN

Displays system-wide MAC addresses

Defining and coupling a NIC using CP commands Tip: You may choose to use the DEFINE NIC and COUPLE approach instead of the NICDEF z/VM user directory statement. In this case, consider adding these two commands into your guest’s PROFILE EXEC file so they are automatically executed at IPL time or whenever the guest logs on. To create a virtual NIC, use the following command syntax: DEFINE NIC vdev [ operands ]

In this syntax, vdev specifies the base virtual device address for the adapter, and operands defines the characteristics of the virtual NIC. Operands accepted by the DEFINE NIC command are listed in Table D-7. Table D-7 Operands for the DEFINE NIC command Operands

Description

HIPERsockets

This operand defines this adapter as a simulated HiperSockets NIC. This adapter functions similar to the HiperSockets internal adapter. A HiperSockets NIC can function without a z/VM Guest LAN connection or can be coupled to a HiperSockets Guest LAN.

QDIO

This operand defines this adapter as a simulated QDIO NIC. This adapter functions similar to the OSA-Express (QDIO) adapter. A QDIO NIC is only functional when it is coupled to a QDIO Guest LAN.

DEVices devs

Determines the number of virtual devices associated with this adapter. For a simulated HiperSockets adapter, devs must be a decimal value between 3 and 3072 (inclusive). For a simulated QDIO adapter, devs must be a decimal value between 3 and 240 (inclusive). The DEFINE NIC command creates a range of virtual devices from vdev to vdev + devs -1 to represent this adapter in your virtual machine. The default value is 3.

Appendix D. Useful commands

239

Operands

Description

CHPID nn

A two-digit hexadecimal number that represents the CHPID number that the invoker wants to allocate for this simulated adapter. If the requested CHPID number is available, all of the virtual devices belonging to this adapter share the same CHPID number. This option is useful only if you need to configure a virtual environment with predictable CHPID numbers for your simulated devices.

Use the COUPLE CP command to attach the virtual NIC to a compatible Guest LAN. The syntax of the COUPLE command for this scenario is: COUPLE vdev TO [ operands ]

In this syntax, vdev specifies the base virtual device address for the adapter, and operands defines where to connect the NIC. Table 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 Operands

Description

vdev

This is the base address of the network adapter.

ownerid lanname

The ownerid is the name of the owner of the Guest LAN (such as SYSTEM). The lanname is the name of the Guest LAN.

Remember that a virtual NIC can only be coupled to a compatible Guest LAN. For example, a QDIO NIC cannot be coupled to a Guest LAN of type “HiperSockets”

Linux on System z TCP/IP commands When using the Linux commands listed in Table D-9, enter them in lowercase, as shown. Table D-9 TCP/IP commands

240

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



E

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.


241

Creating the OSA configuration The 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 file Follow 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 file Complete the following steps: 1. Create a skeleton OAT by using the OSA/SF GET_OAT command or by using the sample OAT file from the IOA.SIOASAMP data set. The names of the sample OAT files are: – – – –

242

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


Note: If you retrieve the OAT from the OSA card, the OAT obtained may contain several unneeded entries, especially if it is the default OAT. Example: 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 supports logical channel subsytems. Image 0.5 and Image 0.7 are sharing port 0. Each OAT entry has more than one IP address associated with it. ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************ Image 0.5 00(1800)* passthru 00 Pri 105.001.005.005 SIU ALL 105.001.005.015 ************************************************************************ Image 0.7 00(1800)* passthru 00 Sec 107.001.007.007 SIU ALL 107.001.005.017

Example: 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 supports logical channel subsytems. Image 0.5 and Image 0.7 are sharing port 0. ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************ Image 0.5 0A(180A) SNA 00 SIU ALL Image 0.7 0A(180A) SNA 00 SIU ALL

2. Copy the required parts of the OAT entry obtained into a new data set. Note: Only the even unit address entries are required for TCP/IP Passthru entries. 3. Update the OAT records for your logical partitions (LPARs) with the unit address, port mode and port number, default entry indicator, and IP address for each required device. – Partition - Enter the partition number that is used for that entry. If you are running in basic mode or if the CHPID is dedicated, the partition number is 0. – UA - The unit address can be any even address for TCP/IP Passthru, but unit address 00,01 is associated with OSA port 0 in the default OAT. Unit address 0A is usually associated with OSA port 0 in SNA mode. 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.

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 supports logical channel subsytems. Image 0.5 and Image 0.7 are sharing port 0. ************************************************************************ * UA(Dev) Mode Port Entry specific information Entry Valid ************************************************************************ Image 0.5 00(1800)* passthru 00 Pri 105.001.005.005 SIU ALL 105.001.005.015 105.001.005.025 105.001.005.035 02(1802)* passthru 00 No 100.100.100.100 SIU ALL 0A(180A) SNA 00 SIU ALL ************************************************************************ Image 0.7 00(1900)* passthru 00 No 107.001.075.075 SIU ALL 107.100.075.085 02(1902)* passthru 00 Sec 107.005.035.035 SIU ALL 0A(180A) SNA 00 SIU ALL

Activating the OSA configuration OSA configuration changes are disruptive, so all applications running via OSA devices must not have active sessions. Also, the OSAD device must be online to the host on which OSA/SF is running. 1. Vary all OSA devices offline (except the OSAD device), or at least those devices that have active sessions to all partitions that are sharing this OSA port. 2. Log on to TSO from the system on which OSA/SF is running. Note: The TSO user ID must be set up to use the OSA/SF TSO interface. 3. Enter the IOACMD command. 244


4. You see the choices shown in Figure E-1. Select option 2 to load a configuration.

IOACMD: Enter the command to be issued IOACMD: 0 IOACMD: 1 IOACMD: 2 IOACMD: 3 IOACMD: 4 IOACMD: 5 IOACMD: 6 IOACMD: 7 IOACMD: 8 IOACMD: 9 IOACMD:10 IOACMD:11 IOACMD:12 IOACMD:13 IOACMD:14

-

End IOACMD Clear Debug Configure OSA CHPID Convert OAT Get Configuration File Get Debug Get OSA Address Table Install Put OSA Address Table (OSA-2 only) Query Set Parameter Shutdown (VM only) Start Managing Stop Managing Synchronize (OSA-2 only)

Figure E-1 IOACMD menu

5. You now see the list shown in Figure E-2.

IOACMD: IOACMD: IOACMD: IOACMD: IOACMD: IOACMD: IOACMD:

Enter Enter Enter Enter Enter Enter Enter

'quit' to end IOACMD 0 for help 1 to configure an OSA-2 ATM CHPID 2 to configure an OSA-2 FDDI, ENTR, fast Ethernet CHPID 3 to configure an OSA-Express gigabit Ethernet CHPID 4 to configure an OSA-Express ATM CHPID 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-2 IOACMD configure list

6. You are prompted through the configuration steps. a. b. c. d. e. f.

Enter the OSA feature type. Enter the OSA CHPID number to which the CONFIG and OAT is to be downloaded. Respond to the prompt: Is CHPID nn of type OSD (QDIO)? (Y./N). Enter the fully qualified data set name containing the CONFIG definitions. Enter the fully qualified data set name containing the OAT definitions. 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.


245

IOACMD: 0 - Quit IOACMD: 1 - Activate IOACMD: Sets up all the files and transfers the data to the CHPID IOACMD: 2 - Activate, no Install IOACMD: Only sets up the files, but does not transfer them to the CHPID IOACMD: You must issue the Install command at a later time IOACMD: to complete the activation Figure 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

246


/*====================================================================== sna.0.1 = Configuration name /* Configuration name (32-char max) sna.0.2 = 90.00 /* Inactivity timer (ti) /* .24-90 in increments of .12 /* 0 disables the inactivity timer sna.0.3 = 10.00 /* Response timer (t1) /* .20-51 in increments of .20 sna.0.4 = 1.04 /* Acknowledgement timer (t2) /* .08-20.4 in increments of .08 sna.0.5 = 4 /* N3 (1-4) sna.0.6 = 8 /* TW (1-16)

Example: 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)


247

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)

248


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

= Configuration name = 90.00

/* Configuration name (32-char max) /* 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) /*======================================================================


249

250


F

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.


251

Default mode Figure F-1 shows a functional view of the connectivity as discussed in this chapter.

LPAR 1

TCP/IP

Channel Subsystem

"default OAT" (TCP/IP Passthru) OSA-Express3 1000BASE-T

Port 0

Port 1

Ethernet Switch

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 requirements The OSA-Express CHPID, the control unit, and the OSA devices must be defined to HCD and activated. Refer to Chapter 3, “Hardware configuration definitions” on page 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.

252


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=OSA IODEVICE ADDRESS=2E5F,UNITADD=FE,CUNUMBR=(2E40),UNIT=OSAD

Displaying the default OAT Although we do not need to use OSA/SF for the activities in this chapter, we thought it would be instructive to view the default OAT. The OSA/SF GUI must be connected to a z/OS host that has OSA/SF running. In addition, the OSA CHPID must be defined by HCD, and the HCD must be activated. This step does not require the CHPID to be installed or online. It only creates and saves an OSA-Express configuration. 1. Start the OSA/SF GUI program: a. Open a DOS window. b. Enter the following command: java IOAJAVA

c. At the prompt, type your password to obtain a connection. 2. In the Workstation Interface window, in the right panel under OSA/SF Commands, select CHPID View 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

254


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


255

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/IP Definitions 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.

256


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

CHPID 0C

L P A R

T C P / I P

00-01

HOME IP 192.168.4.3

100 Mbps Ethernet Switch

DEVICE 2E40,2E41 OSAD, UA FE

A

OSA/SF

"FE" DEVICE 2E5F

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

TCP/IP definitions The z/OS device addresses used for port 0 are 2E40 and 2E41. We defined: 򐂰 One DEVICE statement per OSA-Express Port, with the even device number of the two device addresses assigned to the hardware for the port Note the following considerations: – Even though you define only one port, you use two device numbers per OSA-Express Port for TCP/IP Passthru mode. One device is used by TCP/IP for reading, and the other device is used for writing. – Using the DEVICE statement, you define the DEVICE name, the DEVICE type (LCS) for the OSA-Express Port, and the DEVICE number (the read device number, which is the even device number). 򐂰 One LINK statement per OSA TCP/IP DEVICE statement Using the LINK statement, you define the LINK name, the LINK type (in our example, ETHERNET), the PORT number, and the DEVICE name. Although the OSA Express Port is known by the device number, the port number in the LINK statement must match the actual OSA Express Port number. 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


257

򐂰 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 BEGINROUTES statement: If you are migrating your TCP/IP profile from an earlier release, the profile may use the GATEWAY statement to define static routes instead of the BEGINROUTES - ENDROUTES statements. GATEWAY is recognized and used, but consider replacing it with BEGINROUTES. We recommend that you use the BEGINROUTES method to define static routes for the following reasons: 򐂰 򐂰 򐂰 򐂰

It is compatible with UNIX® standards. It is easier to code than GATEWAY. It accepts both IPv4 and IPv6 addresses. It has enhanced functionality.

Future static route enhancements will be available only with the BEGINROUTES statement. Dynamic routing can be accomplished using the OMPROUTE daemon, or the BSDROUTINGPARMS statement can be used in conjunction with the RouteD daemon. We do not recommend the use of the BEGINROUTES statement (static routes) with the OMPROUTE or OROUTED routing daemons. 򐂰 One START statement per OSA device The START device statement entry uses the DEVICE statement name. Figure F-8 shows the TCP/IP profile definitions that we used to define OSA to TCP/IP A.

DEVICE OSA2E40 LCS 2E40 LINK OSA2E40LNK ETHERNET

0

OSA2E40

HOME 192.168.4.3 OSA2E40LNK BEGINROUTES ROUTE 192.168.4.0/24 ENDROUTES

= OSA2E40LNK

START OSA2E40 Figure F-8 TCP/IP profile definitions

Activation Activation may require several tasks, such as: 򐂰 򐂰 򐂰 򐂰

258

Ensuring that the devices are online Activating an OSA/SF configuration Activating VTAM resources Activating TCP/IP


MTU 1492

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 online To verify that the required devices are online, enter the z/OS console display command: D U,,,2E40,2 IEE457I 11.08.20 UNIT STATUS 632 UNIT TYPE STATUS VOLSER 2E40 OSA A-BSY 2E41 OSA A

VOLSTATE

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

Activating TCP/IP There 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.


259

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

260


G

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.


261

Sample environment Figure G-1 is a logical representation of the environment used for the definition examples.

SCZP202 z/O S V 1R 1 0

VM V5R4

LP A R SC81

LPAR V M L IN U X 3

LC SS 0

LC SS1

P C H ID 1 C 1 C H P ID 0 A O SD E 20 0 - E 2 0 F P ort 0 P o rt 1

P C H ID 2 30 C H P ID 0 C OSE 2 E 40 - 2E 4 F P o rt 0 P o rt 1

P C H ID 23 1 C H P ID 0B OSD 2D80 - 2D8F P o rt 0 P ort 1

E th ern et S w itch

Figure G-1 Our hardware environment

z/OS definitions This 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.

262


TCP/IP A

TCP/IP B

.

192.168.3.64

192.168.1.65

OSAE200

OSAE204

IP Address

192.168.3.4

Device

OSA2D80

192.168.1.5 OSA2D84

VTAM

VTAM TRLE OSAE200

OSAE204

Portname

OSA2D80

E200-E20F

Port 0

2D80-2D8F

Device Number

CHPID 0A

OSAE200

OSA2D84

z/OS

z/OS

Port 1

OSAE204

CHPID 0B OSAname


Port 0

Port 1

OSA2D80

OSA2D84


Ethernet Switch


Figure 11-9 Our z/OS environment

TCP/IP profiles The 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'

Appendix G. Sample definitions

263

DEVICE OSAE200 MPCIPA LINK OSAE200LNK IPAQENET ; 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 ROUTE 192.168.1.0/24 ROUTE 192.168.2.0/24 ROUTE 192.168.4.0/24 ROUTE 192.168.4.0/24 ENDROUTES ; START OSAE200 START OSAE204I START OSAE205I START OSA2E40 START OSA2E42

264


OSAE200 VLANID 980 VMAC 020012345678

= = = = =

OSAE200LNK MTU 1492 OSAE204I MTU 1492 OSAE205I MTU 1492 OSA2E40LNK MTU 1492 OSA2E42LNK MTU 1492

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 definitions This section presents examples of VTAM definitions used for OSD and Enterprise Extender.

VTAM TRL definitions We used the same TRLs in both SC64 and SC65. Note: TRLs are built dynamically for HiperSockets. Example: G-3 TRL for CHPID 0A - OSA 1000BASE-T Port 0 * * QDIO TRLE FOR OSA-EXPRESS3 CHPID 0A * OSAE200 VBUILD TYPE=TRL OSAE200P TRLE LNCTL=MPC, READ=E200, WRITE=E201,

PORT 0


265

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 OSAX3

VBUILD TYPE=XCA 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, IDBLK=05D, IDNUM=12863, CPNAME=OSANT, IRETRY=YES, MAXOUT=7, MAXPATH=1, MAXDATA=1024, PACING=0, VPACING=0, PUTYPE=2, DISCNT=(NO), ISTATUS=ACTIVE, MODETAB=NEWMTAB, DLOGMOD=DYNTRN, USSTAB=USSLDYN, SSCPFM=USSSCS OSASWL0 LU LOCADDR=0,MODETAB=MTAPPC,DLOGMOD=APPCMODE OSASWL1 LU LOCADDR=1 3270 SESSIONS OSASWL2 LU LOCADDR=2

266


X X X X X X X X X X X X X X X X

z/VM TCP/IP profile The 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 LINK ; DEVICE LINK ; HOME

OSA2188 OSD 2188 PORTNAME OSA2180 OSA2188L QDIOETHERNET OSA2188

; OSD Fast Ethernet devices on CHPID 09

HIPERDEF HIPERS 7300 PORTNAME HIPERPEF HIPERLEF QDIOIP HIPERDEF

; HiperSockets CHPID EF

192.168.1.62 10.10.1.62 ; GATEWAY ; (IP) Network ; Address ; ----------; ; THESE ARE THE 192.168.1 10 ; START HIPERDEF START OSA2188

OSA2188L HIPERLEF

First Link Hop Name ------------ -------

Max. Packet Size (MTU) -----------

Subnet Subnet Mask Value ----------- --------

CURRENT GATEWAYS THAT ARE BEING USED TODAY IN PRODUCTION = OSA2188L 1500 0 = HIPERLEF 8192 0.255.255.0 0.10.1.0


267

268


H

Appendix H.

ARP takeover This appendix describes Address Resolution Protocol (ARP) takeover, the definition requirements, and verification procedures.


269

ARP takeover description ARP 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.

Before ARP Takeover zSeries CEC z/OS -SC64

TCPIPD CHPID 09

CHPID 0B

OAT

OAT

192.168.1.4

192.168.1..64

192.168.1.64

192.168.1.4

MAC ADDR 6296CA5BC

MAC ADDR 6296C3690

SWITCH

C : \ ping 192.168.1.64

192.168.1.10

Figure H-1 Test environment before ARP takeover

270


ARP takeover definitions We updated the TCP/IP profile to support ARP takeover. We also modified the our switch configuration to support ARP takeover.

TCP/IP definitions Example 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 LINK SC642180LINK IPAQENET

; OSD Devices on CHPID 09 OSA2180

DEVICE OSA2360 MPCIPA LINK SC642360LINK IPAQENET OSA2360 HOME 192.168.1.64 SC642180LINK 192.168.1.4 SC642360LINK

; OSD Devices on CHPID 0B

BEGINROUTES ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492 ROUTE 192.168.1.0/24 = SC642360LINK MTU 1492 ROUTE DEFAULT 192.168.1.64 SC642180LINK MTU 1492 ROUTE DEFAULT 192.168.1.64 SC642360LINK MTU 1492 ENDROUTES

In the IPCONFIG statement, we added MULTIPATH to allow multiple path definitions to the same network (or subnetwork). A DEVICE and LINK statement was needed for each of the two OSA 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 definitions We 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/1 Jan 15 04:01:32 %SYS-6-CFG_CHG:Module 1 block changed by Console// Port(s) 1/1 channel mode set to off. Warning: Spantree port fast start should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc. to a fast start port can cause temporary spanning tree loops. Use with caution. Spantree port 1/1 fast start enabled. Port(s) 1/1 trunk mode set to off.

Appendix H. ARP takeover

271

Verifying ARP takeover Note: The results documented here are for our test with a specific switch. You should consult the documentation provided by the manufacturer of your switch to determine the requirements to support ARP takeover. We verified that ARP takeover worked by performing two different tasks: 򐂰 Pulling the CAT5 cable from the OSA port 򐂰 Stopping the device in the TCP/IP stack

Pulling the CAT5 cable Figure H-2 shows our environment after pulling the CAT5 cable, and the route that the ping takes as a result of this.

After ARP Takeover

zSeries CEC z/OS -SC64

TCPIPD CHPID 09

CHPID 0B

OAT

OAT

192.168.1.4

192.168.1..64

192.168.1.64

192.168.1.4

MAC ADDR 6296CA5BC

MAC ADDR 6296C3690

SWITCH

C : \ ping 192.168.1.64

192.168.1.10

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

C:\>arp -a Interface: 192.168.1.10 Internet Address 192.168.1.4 192.168.1.64

on Interface 0x3000004 Physical Address Type 00-06-29-6c-36-90 dynamic 00-06-29-6c-a5-bc dynamic

Figure H-3 Windows workstation APR cache (normal)

272


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.

MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: TCPIPD Querying ARP cache for address 192.168.1.4 Link: SC642360LINK ETHERNET: 0006296C3690

15:34:44

Querying ARP cache for address 192.168.1.64 Link: SC642180LINK ETHERNET: 0006296CA5BC Querying ARP cache for address 192.168.1.10 Link: SC642180LINK ETHERNET: 0004AC1D18E9 Figure 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.

EZZ4329I LINK SC642360LINK HAS TAKEN OVER ARP RESPONSIBILITY FOR INACTIVE LINK SC642180LINK EZZ4311I LINK SC642180LINK HAS FAILED ON DEVICE OSA2180 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.

C:\>arp -a Interface: 192.168.1.10 Internet Address 192.168.1.4 192.168.1.64

on Interface 0x3000004 Physical Address Type 00-06-29-6c-36-90 dynamic 00-06-29-6c-36-90 dynamic

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.


273

Figure H-7 shows the contents of the ARP table on z/OS immediately after pulling the CAT5 cable for CHPID 09.

MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: TCPIPD Querying ARP cache for address 192.168.1.64 Link: SC642180LINK ETHERNET: 0006296CA5BC

15:37:16

Querying ARP cache for address 192.168.1.10 Link: SC642180LINK ETHERNET: 0004AC1D18E9 Querying ARP cache for address 192.168.1.4 Link: SC642360LINK ETHERNET: 0006296C3690 Figure 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.

MVS TCP/IP NETSTAT CS V1R4 TCPIP Name: TCPIPD Querying ARP cache for address 192.168.1.64 Link: SC642180LINK ETHERNET: 0006296CA5BC

15:39:23

Querying ARP cache for address 192.168.1.10 Link: SC642180LINK ETHERNET: 0004AC1D18E9 Querying ARP cache for address 192.168.1.4 Link: SC642360LINK ETHERNET: 0006296C3690 Querying ARP cache for address 192.168.1.64 Link: SC642180LINK ETHERNET: 0006296C3690 Figure 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.

V TCPIP,TCPIPD,PURGECACHE,SC642180LINK EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,PURGECACHE,SC642180LINK EZZ9786I PURGECACHE PROCESSED FOR LINK SC642180LINK EZZ0053I COMMAND PURGECACHE COMPLETED SUCCESSFULLY Figure 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.

EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180 EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180 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

274


ARP updated only existing entries in ARP cache. It did not create entries for IP addresses that were not currently in ARP cache.

Stopping the device in the TCP/IP stack In this test, we created an error condition by stopping the device in the TCP/IP stack. Figure H-11 shows the command that was issued and the resulting messages.

V TCPIP,TCPIPD,STOP,OSA2180 EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,STOP,OSA2180 EZZ0053I COMMAND VARY STOP COMPLETED SUCCESSFULLY EZZ4315I DEACTIVATION COMPLETE FOR DEVICE OSA2180 EZZ4329I LINK SC642360LINK HAS TAKEN OVER ARP RESPONSIBILITY FOR INACTIVE LINK SC642180LINK Figure 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.

V TCPIP,TCPIPD,START,OSA2180 EZZ0060I PROCESSING COMMAND: VARY TCPIP,TCPIPD,START,OSA2180 EZZ0053I COMMAND VARY START COMPLETED SUCCESSFULLY EZZ4313I INITIALIZATION COMPLETE FOR DEVICE OSA2180 Figure 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.


275

276


I

Appendix I.

HiperSockets Accelerator This appendix provides a description of HiperSockets Accelerator, definition requirements, and verification procedures.


277

HiperSockets Accelerator description HiperSockets 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. 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 shows our network configuration and the HiperSockets Accelerator flow.

278


zSeries CEC TCPIPD

QDIO Device Driver

VTAM

iQDIO Device Driver

CHPID EF HiperSockets iQDIO LAN

External LAN

10.10.1.64 192.168.1.64 OSA-Express CHPID 09

Accelerated QDIO - iQDIO routing

Linux 2 TCP/IP 10.10.1.60

192.168.1.10

C:\ ping 10.10.1.60

Figure I-1 HiperSockets Accelerator flow

HiperSockets definitions Implementation 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 LINK SC642180LINK IPAQENET OSA2180

; OSD Devices on CHPID 09

DEVICE IUTIQDEF MPCIPA LINK HIPERLEF IPAQIDIO IUTIQDEF

; HiperSockets CHPID EF

HOME 192.168.1.64 10.10.1.64

SC642180LINK HIPERLEF

BEGINROUTES ROUTE 192.168.1.0/24 = SC642180LINK MTU 1492 ROUTE 10.10.1.0/24 = HIPERLEF MTU 16384 ROUTE DEFAULT 192.168.1.64 SC642180LINK MTU 1492 ENDROUTES START IUTIQDEF START OSA2180

Appendix 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: HiperSockets must be defined in the IOCDS as CHPID type IQD. Note the following points: 򐂰 IQDIOR activates HiperSockets Accelerator. 򐂰 DATAGRAMFWD is required to forward the datagrams between the two networks. 򐂰 PRIRouter is required to route IP addresses between the networks.

Verifying HiperSockets Accelerator We verified that HiperSockets Accelerator was working by issuing z/OS console commands and reviewing the resulting messages. When TCP/IP was started, we saw the message shown in Figure I-2, which confirmed that HiperSockets Accelerator was enabled.

EZZ0688I IQDIO ROUTING IS ENABLED Figure I-2 Message when starting TCP/IP

Next, we looked at the active TCP/IP configuration as shown in Figure I-3.

D TCPIP,TCPIPD,N,CONFIG EZD0101I NETSTAT CS V1R4 TCPIPD 841 TCP CONFIGURATION TABLE: DEFAULTRCVBUFSIZE: 00016384 DEFAULTSNDBUFSIZE: 00016384 . . . IQDIOROUTE: YES QDIOPRIORITY: 1 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.

D NET,TRL,TRLE=IUTIQDEF IST097I DISPLAY ACCEPTED IST075I NAME = IUTIQDEF, TYPE = TRLE 881 IST486I STATUS= ACTIV, DESIRED STATE= ACTIV IST087I TYPE = LEASED , CONTROL = MPC , HPDT = YES IST1715I MPCLEVEL = QDIO MPCUSAGE = SHARE IST1716I PORTNAME = LINKNUM = 0 OSA CODE LEVEL = D3GF IST1577I HEADER SIZE = 4096 DATA SIZE = 65536 STORAGE = ***NA*** IST1221I WRITE DEV = 7301 STATUS = ACTIVE STATE = ONLINE IST1577I HEADER SIZE = 4092 DATA SIZE = 0 STORAGE = ***NA*** IST1221I READ DEV = 7300 STATUS = ACTIVE STATE = ONLINE IST1221I DATA DEV = 7302 STATUS = ACTIVE STATE = N/A IST1724I I/O TRACE = OFF TRACE LENGTH = *NA* IST1717I ULPID = TCPIPD IST1814I IQDIO ROUTING ENABLED Figure I-4 HiperSockets TRLE

280


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.

D TCPIP,TCPIPD,N,ROUTE,IQDIO EZD0101I NETSTAT CS V1R4 TCPIPD 874 IPV4 DESTINATIONS DESTINATION GATEWAY 0 OF 0 RECORDS DISPLAYED

INTERFACE

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.

ROUTE ADD 10.10.1.0 MASK 255.255.255.0 192.168.1.64 -p 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.

D TCPIP,TCPIPD,N,ROUTE,IQDIO EZD0101I NETSTAT CS V1R4 TCPIPD 902 IPV4 DESTINATIONS DESTINATION GATEWAY 10.10.1.60/0 10.10.1.60 10.10.1.61/0 10.10.1.61 2 OF 2 RECORDS DISPLAYED

INTERFACE HIPERLEF HIPERLEF

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.

Appendix I. HiperSockets Accelerator

281

282


J

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.


283

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 output The 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 Report To 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.

284


Figure J-1 shows an example of the Channel Activity Report.

16:42:43 ID NO G 08 09 0A 0B 0C 0D 0E 10 11 12 13 14 15 16 17 18 19

CHANNEL UTILIZATION(%) TYPE S PART TOT BUS OSD Y 0.0 12.1 16.0 OSD Y 6.8 11.9 15.6 OSD Y 0.0 3.6 15.8 OSD Y 7.9 11.9 13.0 OSD Y 0.0 0.0 8.6 OSD Y 0.0 0.0 8.6 OSE Y 0.0 1.4 12.4 OSD Y 0.8 3.5 15.6 OSD Y 0.0 12.4 16.3 OSD Y 0.0 3.5 15.6 OSE Y 0.0 0.4 10.8 OSD Y 0.0 0.0 8.6 OSD Y 0.0 0.0 8.6 OSD Y 0.0 3.5 15.6 OSE Y 0.0 0.4 10.8 OSE Y 0.0 0.4 10.8 OSD Y 0.0 3.1 15.6

READ(B/S) PART TOT 0 21K 0 0 0 3K 0 0 0 0 0 0 0 0 0 717 0 127K 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

WRITE(B/S) MSG MSG SEND RECV PART TOT RATE SIZE FAIL FAIL 0 118K 0 0 0 68K 0 0 0 0 0 0 0 0 0 0 0 24K 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

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.

Appendix J. RMF in an OSA environment

285

286


K

Appendix K.

Authorization This appendix discusses the topics regarding the authorization commands used in the z/VM-related chapters.


287

z/VM virtual switch authorization You can restrict the access to the virtual switch function of z/VM, using native Control Program (CP) security or an ESM. Important: If an ESM is in place, the security definitions made by the SET VSWITCH command are overridden by the ESM definitions. Figure K-1 shows the authorization flow of the COUPLE logic.

COUPLE SPECIAL NICDEF

YES

ESM

Protected Resource ?

ESM Installed ?

CP ACCESS LIST

NO

NO

YES

Authorize Connection ?

NO

YES

Connection Denied

Connection Permitted

NO

Authorize Connection ?

YES

Figure K-1 Authorization flow for COUPLE logic

Running with CP authorization If you do not have an ESM (such as RACF) in place, you can use the CP access authorization function in z/VM. You can control the access to the virtual switch using the SET VSWITCH command. Example 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-+----------------------+-+-------------+-->< ! ! ! ! <------
288


! <---------< ! ! (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 LNXSU10 Command 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 LNXSU10 Command complete Ready; T=0.01/0.01 11:35:17

Furthermore, you can grant or revoke access to VLANs identified by a VLAN ID. This means that you can determine to which VLANs the user can connect.

Appendix K. Authorization

289

Running with RACF authorization Since 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 switch 2. Permit access for guest systems 3. Activate the VMLAN class

Defining profiles for each virtual switch To protect a virtual switch via RACF, it is important to define a RACF profile for each virtual switch in your system. Example 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)

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. 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 systems To 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 L2SW1 Ready(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

290


RAC PERMIT SYSTEM.L2SW1 CLASS(VMLAN) ACCESS(UPDATE) ID(LNXSU10) DELETE Ready; T=0.01/0.01 13:34:47

Activating the RACF VMLAN class After you define the RACF profile for your virtual switch, you must activate the RACF class (VMLAN). Example 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

292


Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.

IBM Redbooks For information about ordering these publications, see “How to get IBM Redbooks” on page 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 publications These 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 resources These Web sites and URLs are also relevant as further information sources: 򐂰 System z Networking http://www.ibm.com/servers/eserver/zseries/networking/


293

򐂰 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 Redbooks You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: ibm.com/redbooks

Help from IBM IBM Support and downloads ibm.com/support

IBM Global Services ibm.com/services

294


Index Numerics 50.0 micron 190, 194 62.5 micron 190, 194 802.1Q 132 8021q.o module 145

A access list 40 VSWITCH 162 Access mode 133 access port 133 advanced facilities 219 APPC 49 APPCOSA 49 APPCPMxx 49 ARP offload 16 statistics 16 takeover 16, 269 ARP cache 236, 272 existing entries 275 ARP table 270 MAC addresses 274 availability IP 16

CHPID number 59, 236 command Linux for System z TCP/IP 240 Linux z/VM Virtual Switch 239 TCP/IP for z/VM 238 TCP/IP operations for z/VM 238 TSO 237 z/OS 236, 288 z/VM 238 z/VM Virtual Switch 239 component trace 217 configuration name 89, 246 Control Program (CP) 153 control unit 35, 68, 78, 87, 108, 252 definition 40 controller 161 CTIEZB00 217 CTRACE 217 CTRACE command 213

D

BEGINROUTES statement 102, 118, 258 static routes 258 broadcast in VLAN 134 broadcast support 15

data router 5 datapath 42 DED 39 device definition 41 device number 42, 71, 99, 101, 115, 117, 257 DEVICE OSA2180 MPCIPA PRIRouter 279 device type 32, 42, 101, 117, 256 device types 28 Direct Memory Access 4 DIX 190–191, 194–195 DMA 4 dot3StatsTable 14

C

E

B

candidate list 40 CAT5 cable 272 Channel Activity Report 284 channel on/off 229 Channel Path List panel 38, 40 Measurement Facility 284 window 39 channel path 39 definition 37 channel path identifier (CHPID) 35 checksum 17 CHPID 68, 78, 219, 242 On/Off 229 CHPID 09 270, 279 Fast Ethernet port 273 OSA-Express card 280 CHPID 0B 271

EE 21 Enterprise Extender 21 Enterprise Extender (EE) 31, 76 ESM (External Security Manager) 288 Ethernet switch 69, 79, 99, 115, 135, 156, 257 VLAN functionality 157 even device number 101, 117 external communications adapter (XCA) 99 External Security Manager (ESM) 288 external writer file 213

F Fast Ethernet (FENET) 31, 242 FE,C UNUMBR 253 FENET (Fast Ethernet) 31, 242 FTP 52


295

G GbE LR 30 Get and GetNext request 14 grant access virtual switch 160 graphical user interface (GUI) 47 gratuitous ARP 273 GRE 124 guest system 31, 68, 152 network connectivity 158 Q NIC DETAILS command 162

H hardware assists 6 Hardware Configuration Definition (HCD) 78, 252 Hardware Management Console (HMC) HCD (Hardware Configuration Definition) 78, 252 HiperSockets Accelerator 277 HMC (Hardware Management Console) HPDT ATM 7 HPDT MPC 7 HPR 21 hybrid mode 133

35–36, 46, 68, 90, 219 35–37, 46, 68,

219

I IEEE 802.1q VLANs 132 inbound packet 135 installing OSA/SF 47 Internet Protocol Assist (IPA) 6 IOAENTR 242 IOAOSHRA 242 IOAOSHRS 242 IOAOSHRT 242 IOCDS 35, 46, 252, 280 IOCP definition 87, 108 IP address 53, 153, 170, 243, 256, 270, 280 192.16.1.20 101, 117 192.16.1.24 91, 258 conflict 170 IP assist 6 IP router 134 IPCONFIG IQDIOR 278 IPv6 address 258 IPv6 support 10 iQDIO 278 IST075I Name 280 IST097I Display 280 IST486I Status 280

L LAN Channel Station (LCS) 14, 99, 252 large send 11 Layer 2 157 Layer 2 support 18, 31, 151

296


LCS device 99, 256 link aggregation 19, 156–157 LINK statement 271 parameter VLAN 148 port number 257 Linux commands for TCP/IP 240 VLAN support 145 Linux guest 147, 281 VLAN support 170 locally administered address (LAA) 90 logical partition 31, 47, 86, 109, 231, 243 LP number 91 OSA-Express port 94 LP number 91 LPAR 91, 229, 251 LP-to-LP communication 6

M MAC 16 MAC address 8, 56, 89–90, 98, 220, 273 ARP cache 274 byte ID prefix 153 of defined OSA-Express port 90 same IP address 274 major node 70, 99, 115, 141, 237 Management Information Base (MIB) 14 Maximum IP addresses per OAT 8 Maximum IP stacks and devices 8 Maximum number of MAC addresses 8 Maximum TCP/IP stacks and devices 8 microcode 228 MIF 28 Missing Interrupt Handler (MIH) 68, 78 mode conditioner patch (MCP) 190, 194 modes of operation 3 MTU size 278 multicast support 15 multiple IP addresses 270 multiple TCP/IP stack 135

N NAT 124 network interface card (NIC) 160, 239 networking, policy-based 32 NIC (network interface card) 160, 239 NICDEF 160 NICDEF statement 153 non-QDIO 2–3 non-QDIO mode 29, 48, 85, 107, 241, 270 default IP 48 NONRouter 125 non-shared mode 251

O OAT dynamic 5 OAT (OSA Address Table) 228, 242

OAT default status display 259 Open Systems Adapter for NCP (OSA for NCP) 22 Open Systems Adapter Support Facility (OSA/SF) 3, 47, 85, 107 OSA default mode 252 OSA Address Table (OAT) 86, 109, 228, 242, 252 OSA CHPID 108 OSA configuration 96, 242 file 97, 246 OSA device 68, 78, 87, 108, 153, 238, 243, 252 Display status 238 OSA feature 89, 244 active sessions 244 OSA port 86, 94, 109, 243, 252 MAC address 98 OSA/SF 3, 9, 29, 220 GUI setup 51 profile 50 REXX 47 set up 50 TCP/IP 50 OSA/SF GUI 47, 51, 87, 253 and very useful function 62 code 52 OSA feature configuration 87 program 88, 253 TCP/IP connection 53 OSA/SF host system 53 OSA/SF REXX command interface 109 OSAD 28, 49 OSAD device 43, 86, 109, 244 unit address FE 44 OSAENTA 198 OSA-Express 2 cabling requirements 189 channel on/off 229 MAC address of defined port 90 Network Traffic Analyzer 7 Port 257 OSA-Express 1000BASE-T settings 192–193, 195 OSA-Express Address Table (OAT) 137 OSA-Express ATM CHPID 245 OSA-Express card 101, 270, 280 ARP table 270 IP network 281 OSA-Express CHPID 28, 87, 229, 252 new support 284 OSA-Express connection 138, 173, 270 Ethernet switch ports 173 trunk port 138 OSA-Express device 153 OSA-Express devices 28 OSA-Express Ethernet feature 131 OSA-Express feature 28, 35, 47, 67, 71, 77, 85, 89, 107, 136, 241 CAT5 cable 272

MAC address 90 network connectivity 67, 77 OSA-Express port 28, 135 active session 96 DEVICE statement 101, 117 Ethernet frame 152 Ethernet LAN 99, 115 HOME IP address 101, 118 MAC address 98 trunk mode 168 OSA-Express2 2 10 Gigabit Ethernet Long Reach (10 GbE LR) feature 194 1000BASE-T 191 concurrent LIC update 6 features 189 Gigabit Ethernet short wavelength 194 OSA-Express2 Gigabit Ethernet long wavelength 191 OSC 2, 39 OSD 2, 39 OSE 2, 39, 85, 107 activation 258 SNA definition 93 switched major node 100, 117 TCP/IP definitions 91 TCP/IP profile 258 VTAM setup 99, 115 OSN 2

P PAGENT 32 permanent definitions 165 physical channel identifier (PCHID) 35 Physical Unit (PU) 99, 115 policy-based networking 32 Port isolation 156–157 port number 101, 117, 243, 257 ports disable 225 enable 225 status 225 Preventive Service Planning (PSP) 125 primary/secondary router function 10 priority queuing 5 PRIRouter 125 pull-down menu 221 select CHPIDs 230 Task List 230 purge ARP 16 PVC (permanent virtual circuit) name 248

Q QDIO 2–3 Diagnostic Synchronization 7 status displays 74, 82 TCP/IP definitions 72, 80 TCP/IP profile 72, 80 TRLE 70, 141

Index

297

VTAM definitions 70, 141 QDIO functions 6 QDIO mode 48, 67, 77, 85, 107, 131, 152, 155, 270 OSA-Express feature 270 OSA-Express port 139 QDIO priorities 8 QDIO versus non-QDIO 3 query ARP 16 QUERY VSWITCH command 164 Detail 239 name Access 239

R RACF authorization 290 profile 290 security 290 Redbooks Web site 294 Contact us xii Resource Measurement Facility (RMF) 283 REXX 241 RMF (Resource Measurement Facility) 283 RMF for OSA-Express 284 RMF Monitor II output 284

S S/390 Open Systems Adapter-Express 2 SE 219 SECRouter 125 shared port 94 activation 102, 118 HCD 87, 108 OSA/SF definitions 88, 253 status displays 103, 119 TCP/IP definitions 101, 117 VTAM definitions 99, 115 SHR 39 Simple Network Management Protocol (SNMP) 14 SNA mode 7 QDIO 76 SNA application 76, 99, 115 SNA traffic 76, 90 SPAN 39 Spanning 28 startup profile 246 static route 102, 118 Support Element (SE) 219 switched major node 100, 117 System z server 36, 219, 252 System z9 2, 35

T tagged frames 134 TCP/IP 48, 135, 236, 270, 278 network interfaces 238 TCP/IP definition 32, 257

298


TCP/IP device 74, 82, 103, 119, 237, 257, 259 TCP/IP Passthru 7 TCP/IP profile 71, 101, 117, 256, 263, 270, 278 device type LCS 270 device type MPCIPA 270 IQDIORouting option 278 OSA device 102, 118 TCP/IP stack 31 configured VLAN IDs 137 maximum 39 untagged traffic 135 TN3270E Server 21, 76 token ring, USE RING 100, 117 token-ring configuration file 242 trace function 222 Transport Resource List (TRL) 70, 141 traps and set 14 TRLE 68, 71, 237 considerations 70 trunk mode 133, 168, 171, 271 trunk port 133, 138 type of traffic 3

U unit address 86, 109, 243, 255 untagged frames 134 USE RING for token ring 100, 117

V view code level 228 VIPA takeback 10 takeover 10 virtual (VMAC) 8 Virtual IP address (VIPA) 10 virtual MAC (VMAC) 20, 124 virtual machine 239 Virtual Medium Access Control (VMAC) 123 virtual switch 31 controller 153 detail information about 239 display information about 239 Layer 2 functionality 167 Layer 2 support 152 MAC address 153 OSA-Express devices 153 RACF profile 290 RACF security 290 VLAN capabilities 169, 171 VLAN connectivity 168 VLAN 131–132, 135, 145 design rules 135 implementation 138, 145 isolation 134 VLAN 200 136 VLAN capability 168, 171 virtual switch 168, 171 VLAN ID 14, 135, 169 OSA-Express registration process 131

parameter 173 tag 133 value 135 VLAN ID 1 135 VLAN ID virtual switch 168 VLAN support 12, 135, 138, 168 GVRP 13 Layer 2 virtual switch configuration 167 Linux 13 z/OS 13 z/VM 13 VMAC 124 VMLAN 161 VSWITCH VSWTCH1 GRA LNXSU1 VLAN 101 170 GRA LNXSU2 VLAN 101 170 GRANT LNXSU1 160 GRANT LNXSU2 160 GRANT LNXSU3 160 VTAM commands 237 VTAM definition 32, 261 VTAM resource 73, 102, 118, 258

X XCA 7 XCA (external communications adapter) 99 XCA major node 99, 115

Z z/OS 69, 79, 253, 273 VLAN support 138 z/VM TCP/IP command 238 TCP/IP operations commands 238 z/VM V5.1 31 z/VM Virtual Switch commands 239 Layer 2 support 151

Index

299

300






(0.5” spine) 0.475”<->0.873” 250 <-> 459 pages



Back cover

®

OSA-Express Implementation Guide ®

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.

INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION

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 SG24-5948-05

ISBN 0738432555

Osa Express - Implemantation Guide - RedBook IBM

Recommend Documents