Skip to content

Basic TCP/IP

Goals

In this tutorial we're configuring your basic VM TCP/IP stack wired directly to an emulated OSA. This isn't what I'm going to settle on for my final configuration, but it is the easiest and most out-of-the-box setup you can accomplish. I'm also going to be leveraging the configuration we get at the end of this stage to move the TCP/IP stack to a VSWITCH in a later tutorial.

OSA Address

For the sake of this tutorial, our OSA triplet is defined starting at adress 0400. For anyone playing along with zD&T, my devmap is:

[manager]
name awsosa 0003 --path=F0 --pathtype=OSD
# tcpip
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2

For the curious among us, here's the relevant find_io output:

         Interface         Current          MAC                IPv4              IPv6
 Path    Name              State            Address            Address           Address
------   ----------------  ---------------- -----------------  ----------------  --------------
  F0     eno1              UP, RUNNING      34:17:eb:dc:5c:40  10.0.80.23        fe80::3617:ebff:fedc:5c40%eno1

This interface is shared with my linux host's network stack, so all traffic is going through one pipe. If you need VLAN awareness you may need to stand up a separate trunked interface -- can't say I've given that too much thought just yet.

zD&T Caveat!

The way I'm configuring TCP/IP here means that you will NOT be able to communicate to the z/VM TCP/IP stack from the linux host running the z1090 emulator. In fact, in my experience, attempting to communicate with your emulated z/VM's TCP/IP from the linux host (e.g., pinging the z/VM IP) may actually crash the z1090 emulator. If you have a need to communicate to z/VM TCP/IP, you'll need to do some additional work to configure a second tunnel interface. While out of scope of this tutorial, it should be well documented by IBM. TODO: Add reference to IBM docs!

A wizard did it

Accessing IPWIZARD

Notice

The following steps are preformed as MAINT710

IBM made this part exceedingly easy, as it should be. They helpfully provided a program to get us online.

IPWIZARD EXEC is located on MDISK 193

ACCESS 193 Z

Once you've accessed 198, simply issue the IPWIZARD command:

IPWIZARD

TCP/IP Configuration

PF8 to proceed through the wizard, PF7 to return to a prior screen.

The values in the wizard should all be specific to your network. User ID should stay TCPIP unless you've got some custom death wish.

Screenshot

The interface name has no specific meaning, choose what you like.

Device Number is populated with the starting address of your OSA triplet. 0400 in my case, from the configuration at the beginning of this page.

I haven't experimented with L3 QDIO on zD&T, but L2 is a safe bet anyway.

Screenshot

I'm not trunking to a VLAN so I left that field blank. MTU is appropriate to your environment. As I write this I'm reminded I have jumbo frames enabled on this network so my setting of 1500 is both conservative, but also now I'm uncertain whether I should have entered 1492, as a network configured for jumbo frames shouldn't balk at 1501+, but a network limited to 1500 may. If you have any issues, try 1492 here.

Screenshot

At this point you can PF5 to let the wizard do some magic, and you will eventually be asked to cycle TCPIP:

  The TCP/IP stack (TCPIP) must be restarted as part of this procedure. Would
  you like to restart TCPIP and continue?
  Enter 0 (No), 1 (Yes)

The wizard will also attempt to do some basic sanity checking by pinging your gateway and nameservers. If any of these reject ICMP it will ask you whether you'd like to re-enter settings. If you're sure that the hosts don't accept ICMP, or only some fail the test, you can pretty safely proceed forward.

Autolog TCPIP VM

Connectivity should now be established, you ought to be able to ping your z/VM host from any node on the network (except the zD&T host itself), and from z/VM to any routable IP. Now we'll configure the TCPIP stack to come up at IPL time by adding it to AUTOLOG1's PROFILE EXEC.

We need to access AUTOLOG1's 191 MDISK which contains PROFILE EXEC:

LINK AUTOLOG1 191 091 MR
ACCESS 091 W
XEDIT PROFILE EXEC W

Your AUTOLOG1 PROFILE EXEC may look somewhat different as I've already customized a few things, but you are looking for the line /* "PIPE CP XAUTOLOG TCPIP" */.

Screenshot

Strip the comment marks from the line to leave just "PIPE CP XAUTOLOG TCPIP":

Screenshot

In my example above, you'll see I also added "PIPE CP SLEEP 5 SEC" and something about FTPSERVE. This is unnecessary at this stage, but reasoning is that FTPSERVE autologs too quickly and fails to start because TCPIP hasn't had a chance to properly finish. No dependency trees in AUTOLOG1's PROFILE EXEC unfortunately. Don't worry about this for now, all you really care about at this point is "PIPE CP XAUTOLOG TCPIP".

And that's it! At this point you should be up and running. Try a SHUTDOWN REIPL to verify TCPIP restarts with the system.

Any networking errors at this point will require some site specific troubleshooting, so there's not much I can speak to there.

In the next tutorial I'm going to be moving our TCP/IP stack to a shared VSWITCH. Stay tuned!

TODO: 05 per https://groups.io/g/zPDT/topic/how_can_you_use_a_single_nic/41245668