I was just(!) trying to get my Liberty web server running on z/OS to be able to be moved to a different LPAR, and get it working. Moving it was easy, but the server’s certificate needs the IP address of the TCP/IP stack – with RACF you can only have one “Subject Alternative Name”. A SAN of IP:10.1.2.4 works fine when it comes from TCP/IP stack 10.1.2.4 – but not from TCP/IP stack 10.1.2.5. The web browser checks, and complains if they do not match.
To get this to work I read the z/OS TCP/IP documentation. There is lots of it, but it seems to be written for people who are experts in it. There is a saying “Question: how do you eat an elephant? Answer: A bit at a time”. This post takes a small bit area – and expands it in terms I understand. It may not be accurate – but the concepts should be right.
What is a TCP/IP stack?
This is another name of a TCP/IP instance, a started address space.
What is HOME?
Each connection coming into to a TCP/IP instance has an IP address. On TCPIP1 I have a connection (a virtual bit of wire) defined for IP address 10.1.1.2
On Linux if I use the command ip route get 10.1.1.2 it says
10.1.1.2 dev tap0 src 10.1.1.1 uid 1000
So 10.1.1.2 is going via device tap0 (which is a tunnel device, TAP = Tunnelling Application Protocol?). The Linux machine has IP address 10.1.1.1. Through some configuration magic this ends up in my TCP/IP instance as
DEVICE PORTA MPCIPA
LINK ETH1 IPAQENET PORTA
HOME 10.1.1.2 ETH1
Where 10.1.1.2 is the address for a link called ETH1 on the TCPIP instance on my LPAR. The magic is a bit like the Negro spirtual song Dem Bones which has “Thigh bone connected to the hip bone, Hip bone connected to the back bone, Back bone connected to the shoulder bone Now hear the word of the Lord”. ETH1 is defined as being on PORTA, and PORTA is a device which maps to a tunnelled device using protocol MPCIPA. … maps to a VTAM TRL definition, Now hear the word of the Lord.
I can use the TSO netstat command for TCP address space called TCPIP1 netstat home tcp tcpip1
Home address list: Address Link Flg ------- ---- --- 10.1.1.2 ETH1 P 192.168.0.61 ETH2 10.1.1.5 EZASAMEMVS 127.0.0.1 LOOPBACK
For external connections the IP address, 10.1.1.2, must match with the definition on Linux. This may be pointed to from outside Linux. The other “home” connections are described below.
I have multiple instances working together.
I have three TCP/IP instances on my LPAR. You might have an instance to talk to your internal network,(the intranet), and an instance talking to the internet, facing out from your enterprise.
You can also have TCP/IP instances with different security profiles, and provide total isolation.
You can set up connections between your enterprise and my enterprise, these definitions will need a DEVICE, and a LINK etc as above (or an INTERFACE definition).
Setting up multiple instances within a Sysplex, or within an LPAR.
In your TCP/IP definitions you can set up
IPCONFIG DYNAMICXCF 10.1.1.6 255.255.255.0 2
and another instance with 10.1.1.5 etc. The DYNAMICXCF says this is within the Sysplex(LPAR). The software is smart enough to generate the device and link statements automatically. In the netstat home command above, it gave 10.1.1.5 EZASAMEMVS which is eza_SAME_ MVS, and it has found a second TCP instance in the same LPAR. See here for dynamic XCF, and here for the IPCONFIG statement.
I think you can use any unused IP address range; so you could use 184.108.40.206 and 220.127.116.11 instead of 10.1.1.5 and 10.1.1.6. I believe these address are only used within the Sysplex. So as long as these addresses are consistent and not being used else where, the values are not critical.
For a TCP/IP instance TCPIP3 on my LPAR with no external connections netstat home tc tcip3 gave me
Home address list: Address Link Flg ------- ---- --- 10.1.1.7 EZASAMEMVS P 127.0.0.1 LOOPBACK
This has the ever present LOOPBACK, and a virtual connection 10.1.1.7 to a TCP/IP instance in the same LPAR because of the ezaSAMEmvs definition