Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 1: Base Functions, Connectivity, and Routing

Chapter 4. Connectivity 113

During TCP/IP initialization, the stack joins the XCF group, ISTXCF, through VTAM. When

other stacks in the group discover the new stack, the definitions are created automatically,

the links are activated, and the remote IP address for each link is added to the routing table.

After the remote IP address has been added, IP traffic can flow across one of the following

interfaces:

򐂰 IUTSAMEH (within the same LPAR)

򐂰 HiperSockets (within the same server)

򐂰 XCF signaling (different server, either using the coupling facility link or a CTC connection)

Figure 4-6 Dynamic XCF support

For additional information about dynamic XCF, Sysplex Distributor, and nondisruptive

dynamic VIPA movement refer to Communications Server for z/OS V1R7 TCP/IP

Implementation, Volume 3 - High Availability, Scalability, and Performance, SG24-7171.

4.3 The common design scenarios for connectivity

To design a connectivity scenario in a z/OS environment we must take the following into

account:

򐂰 As a server environment, the network connectivity to the external corporate network

should be carefully designed to provide a high-availability environment avoiding

single-points of failures.

򐂰 If a z/OS LPAR is seen as a stand-alone server environment on the corporate network it

should be designed as an end-point.

򐂰 If a z/OS LPAR will be used as a front-end concentrator (for example, making use of

HiperSockets Accelerator), it should be designed as an intermediate network or node.

LPAR 1

Server 1

TCP/IP

Stack A

TCP/IP

Stack B

HiperSocketsIUTSAMEH

LPAR 2

TCP/IP

Stack C

Coupling Facility Link

(XCF Signaling)

LPAR 3

TCP/IP

Stack D

Server 2

CF

114 Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 1 - Base Functions, Connectivity, and Routing

Based on these considerations, we are going to show what we consider to be the

best-practice scenarios to build up a z/OS Communications Server TCP/IP configuration

scenario, using OSA-Express (QDIO), HiperSockets (iQDIO), and dynamic XCF.

This section focuses on the interface implementation only, which means establishing Layer 2

and a subset of Layer 3 (IP addressing) connectivity. For connectivity beyond the immediate

LAN environment, also refer to Chapter 5, “Routing” on page 139, for IP routing details.

To build our test scenario, we used the system environment shown in Figure 4-7 on page 115.

Note that we are defining our LPARs as end-points.

Recommendation: Although there are specialized cases where multiple stacks per LPAR

can provide value, we in general recommend implementing only one TCP/IP stack per

LPAR. The reasons for this recommendation are as follows:

򐂰 A TCP/IP stack is capable of exploiting all available resources defined to the LPAR in

which it is running. Therefore, starting multiple stacks will not yield any increase in

throughput.

򐂰 When running multiple TCP/IP stacks, additional system resources, such as memory,

CPU cycles, and storage, are required.

򐂰 Multiple TCP/IP stacks add a significant level of complexity to TCP/IP system

administration tasks.

򐂰 It is not necessary to start multiple stacks to support multiple instances of an application

on a given port number, such as a test HTTP server on port 80 and a production HTTP

server also on port 80. This type of support can instead be implemented using

BIND-specific support where the two HTTP server instances are each associated to

port 80 with their own IP address, via the BIND option on the PORT reservation

statement.

One example where multiple stacks can have value is when an LPAR needs to be

connected to multiple isolated security zones in such a way that there is no network level

connectivity between the security zones. In this case, a TCP/IP stack per security zone can

be used to provide that level of isolation, without any network connectivity between the

stacks.