This follows on from setting up VIPA for the Liberty web server to provide High Availability. I had a few problems setting it up, and this blog post is about some of the commands I used to get it working.
I cover
- Is the VIPA active?
- Where is it running
- Are applications processing requests
Some IP basics.
- Every connection has an IP address at each end. An address looks like 10.3.4.15 or 4 * 8 bit numbers.
- My machine has several connections, ethernet, wireless, and a tunnelling connection to z/OS. Each connection has a different IP address.
- Packets get routed through the network depending on the destination IP address. The router has logic like, packets going to 10.4.5.* go does this connection, packets for 17.2.2.* go down that connection, any other packets – try sending them to down the connection 11.13.6.6.
- The router uses a netmask to calculate which connection to use.
- A net mask is a string of 1’s followed by 0s. For example 255.255.255.0 – or 3 * 8 =24 ones.
- A router takes a packet IP address and a netmask and logically ands them together, and uses the result to decide where to route the packet.
- A connection handling 10.4.1.0 to 10.4.1.255 would have a netmask of 255.255.255.0 (also written /24 bits) a default connection may handle all packets for 10.* with a netmask of 255.0.0.0 or /8.
My scenario
- I have my desktop machine running Ubnutu Linux
- I have z/OS (called SOW1) running on my desktop using the zPDT.
- I have 3 TCPIP images (stacks) running on the z/OS image
- TCPIP running as the front end
- TCPIP2 running as a backend – this could be on another LPAR
- TCPIp3 running as a backend
- I have a VIPA defined with address 10.1.3.10
What configuration does Ubuntu have?
There are many commands to display network configuration information on Linux.
What address does Ubuntu have?
ip address gives a lot of information – but I did not use it
What packet routing does my desktop have?
the command ip route gives
- 10.1.0.0/24 dev eno1 proto kernel scope link src 10.1.0.3 metric 100
- 10.1.1.0/24 dev tap0 proto kernel scope link src 10.1.1.1
- 10.1.2.0/24 dev tap1 proto kernel scope link src 10.1.2.1
- 10.1.3.0/24 dev tap0 scope link
- 10.20.2.4 dev tap0 scope link
- 192.168.1.0/24 dev wlxd037450ab7ac proto kernel scope link src 192.168.1.67 metric 600
Bold line(2) shows
- Traffic for any address between 10.1.1.0 and 10.1.1.255 (remember the netmask /24 means 24 bits or 255.255.255.0) goes to device(connection) tap0
- The IP address for the desktop end of the connection is 1.1.1.1
Bold line(4) shows
- that any traffic 10.1.3.0 to 10.1.3.255 goes to device tap0
The command used to set this up was sudo ip route add 10.1.3.0/24 dev tap0
Bold line(5) shows
- that traffic to 10.20.2.4 goes to device tap0.
The command used to set this up was sudo ip route add 10.20.2.4 dev tap0
What is the routing for an IP address ?
You can use traceroute command to display which route a packet would take. For example
- traceroute 10.1.3.10
- traceroute to 10.1.3.10 (10.1.3.10), 30 hops max, 60 byte packets
- 1 10.1.3.10 (10.1.3.10) 4.963 ms 4.980 ms 5.887 ms
For a connection that is not defined
traceroute 10.20.2.5 traceroute to 10.20.2.5 (10.20.2.5), 30 hops max, 60 byte packets 1 bthub.home (192.nnn.1.mmm) 3.170 ms 4.742 ms 6.379 ms 2 * * *
So we can see it went to my bt hub wireless router.
You can also use the ping command. On linux there is the -R option for display route.
ping -R 10.1.3.10
PING 10.1.3.10 (10.1.3.10) 56(124) bytes of data.
64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=2.54 ms
NOP
RR: 10.1.1.1
10.1.1.2
10.1.1.1
The request went to 10.1.1.1. 10.1.1.2 caught it, and sent the reply back, via 10.1.1.1
I was looking for my VIPA address, 10.1.3.10, and we can see it got to 10.1.1.2.
For the ping to work, there must be a server processing the ping request. If there are no applications processing the VIPA, the VIPA is not active, so a ping will fail.
A successful ping to a VIPA address means a packet can get to the LPAR, be processed and the reply set back. If the ping does not respond it could be
- The VIPA is not active
- The VIPA is active and a packet was sent to the LPAR hosting the VIPA, but it could not send a response back due to a set up error.
How to issue change TCPIP configuration on z/OS
You can change the configuration of a TCPIP image using the operator command
V TCPIP,TCPIPn,OBEY,filename
Where
- V TCPIP tells z/OS to route this TCPIP
- TCPIPn is the name of the TCPIP address space to direct the command to, for example V TCPIP,TCPIP2. If there is only one TCPIP running you can use V TCPIP,,
- OBEY this is the TCP command
- filename is the parameter passed to the OBEY command. The filename containing the commands/configuration to be executed.
How to display information on z/OS
There are three ways of displaying TCPIP information, for example the IP address(es) of the TCP image
- The operator command D TCPIP,TCPIP2,NETSTAT,HOME… similar in syntax to the V TCPIP command above
- The TSO command NETSTAT HOME TCP TCPIP2
- The USS command netstat -h -p tcpip The commands are similar to but different from Linux commands!
The output is usually similar between the commands.
What is the IP address of my TCPIP image?
From the TSO NETSTAT HOME command
EZZ2350I MVS TCP/IP NETSTAT CS V2R4 TCPIP Name: TCPIP2 17:15:53 EZZ2700I Home address list: EZZ2701I Address Link Flg EZZ2702I ------- ---- --- EZZ2703I 10.1.1.3 ETH1 P EZZ2703I 10.1.2.3 ETHB EZZ2703I 172.1.1.2 EZASAMEMVS EZZ2703I 10.1.3.10 VIPL0A01030A I EZZ2703I 127.0.0.1 LOOPBACK
10.1.1.3 ties up with the information on the desktop which had IP addresses had 10.1.1.1 for device tap0, and 10.1.2.3 ties up with 10.1.2.1 for device tap1.
For the links
- I configured link ETH1 and ETHB.
- The VIPL0A01030A takes the IP address and converts it to hex so 10.1.3.10 becomes VIPL 0A 01 03 0A
- EZASAMEMVS is prefix EZA and “SAME MVS”. This is generated by TCPIP from the DYNAMIXCF configuration.
What routing is there?
The command TSO command NETSTAT ROUTE TCP TCPIP2 or the USS command netstat -r -p tcpip gives
MVS TCP/IP NETSTAT CS V2R4 TCPIP Name: TCPIP2 16:15:43 Destination Gateway Flags Refcnt Interface ----------- ------- ----- ------ --------- Default 10.1.1.1 UGS 0000000000 ETH1 10.0.0.0/8 0.0.0.0 US 0000000000 ETH1 10.1.1.3/32 0.0.0.0 UH 0000000000 ETH1 10.1.2.0/24 0.0.0.0 US 0000000000 ETHB 10.1.2.3/32 0.0.0.0 UH 0000000000 ETHB 127.0.0.1/32 0.0.0.0 UH 0000000000 LOOPBACK 172.1.1.1/32 0.0.0.0 UHS 0000000000 EZASAMEMVS 172.1.1.2/32 0.0.0.0 UH 0000000000 EZASAMEMVS 172.1.1.3/32 0.0.0.0 UHS 0000000000 EZASAMEMVS
This shows that to get to 10.1.2.0 to10.1.2.255 (with a netmask of /24 or 255.255.255.0) it goes by link(interface) ETHB
What is happening to my VIPA on z/OS?
On the OSA connection (think ethernet connection) from the desktop to my z/OS environment there could be several LPARs using the OSA, each with multiple TCP images.
The operator command D TCPIP,TCPIP2,SYSPLEX,VIPADYN issued on any LPAR on any active TCPIP image gives a Sysplex view of the VIPA configuration
11.54.05 STC09473 EZZ8260I SYSPLEX CS V2R4 387 C VIPA DYNAMIC DISPLAY FROM TCPIP AT S0W1 IPADDR: 10.1.3.10 LINKNAME: VIPL0A01030A ORIGIN: VIPADEFINE TCPNAME MVSNAME STATUS RANK ADDRESS MASK NETWORK PREFIX DIST -------- -------- ------ ---- --------------- --------------- ---- TCPIP S0W1 ACTIVE 255.255.255.0 10.1.3.0 DIST TCPIP2 S0W1 BACKUP 001 DEST TCPIP3 S0W1 ACTIVE DEST IPADDR: 10.1.4.10 TCPNAME MVSNAME STATUS RANK ADDRESS MASK NETWORK PREFIX DIST -------- -------- ------ ---- --------------- --------------- ---- TCPIP3 S0W1 ACTIVE 255.255.255.0 10.1.4.0 TCPIP2 S0W1 MOVING 255.255.255.0 0.0.0.0
IPADDR:10.1.3.10
The VIPA 10.1.3.10 was created using a VIPADEFINE.
We see that TCPIP on S0W1 “owns” the VIPA 10.1.3.10 and is responsible for distributing requests. This image is DISTributing requests to other TCPIP Images.
The DEST means it is a target for connections ( a DESTination) and has a server processing requests. BOTH means it is a DESTination and DISTributing connections, and has a server processing them.
IPADDR:10.1.4.10
We can see that TCPIP3 is processing request. TCPIP2 is not processing requests, it does not have a network prefix.
How are DVIPA connection requests distributed?
You need to ask the TCP that owns the VIPA. In my case, from the previous section, this is TCPIP.
The TSO command NETSTAT VDPT TCP TCPIP or the USS command netstat -O -p tcpip gives
MVS TCP/IP NETSTAT CS V2R4 TCPIP Name: TCPIP 16:49:42 Dynamic VIPA Destination Port Table for TCP/IP stacks: Dest IPaddr DPort DestXCF Addr Rdy TotalConn WLM TSR Flg ----------- ----- ------------ --- --------- --- --- --- 10.1.3.10 08443 172.1.1.2 001 0000000005 01 100 DistMethod: Roundrobin TCSR: 100 CER: 100 SEF: 100 ActConn: 0000000000 10.1.3.10 08443 172.1.1.3 000 0000000000 01 100 DistMethod: Roundrobin TCSR: 100 CER: 100 SEF: 100 ActConn: 0000000000
We have a heading showing the TCPIP image name, and we are looking at Dynamic VIPA Destination Port Table for TCP/IP stacks.
When report was generated the application on 172.1.1.2 (TCPIP2) was active, and the application on TCPIP3 had been stopped.
From
Dest IPaddr DPort DestXCF Addr Rdy TotalConn WLM TSR Flg ----------- ----- ------------ --- --------- --- --- --- 10.1.3.10 08443 172.1.1.2 001 0000000005 01 100 ActConn: 0000000000
We can see
- Dest IPaddr: 10.1.3.10 is our VIPA address
- DPort :08443 is the destination port
- DestXCF Addr: 172.1.1.2 is where the request is going – we know this is TCPIP2. It would be good if it could say SOW1.TCPIP2
- Rdy: 001 there is one active application listening
- TotalConn: 0000000005 there have been 5 requests to this application
- ActConn: 0000000000 there are no active connections to this application
As TotalConn is greater than 0, this means there have been connections to the application, so is a good sign to show the set-up is working.
Because the front end TCPIP is distributing the requests using Roundrobin – each TCPIP should get a connection in turn.
When I started the application on TCPIP3, and started another application on TCPIP2. When I ran a workload I had 10 requests go to TCPIP3 and 10 requests go to TCPIP2. On TCPIP2 the requests were evenly distributed between the two servers. It looked like round robin, but I do know know if this was design or chance
How do I know if I have a backup configuration defined?
I set up TCPIP with a VIPABACKUP configuration. The operator command d tcpip,tcpip,sysplex,vipadyn gave me
VIPA DYNAMIC DISPLAY FROM TCPIP AT S0W1 IPADDR: 10.1.3.10 LINKNAME: VIPL0A01030A ORIGIN: VIPADEFINE TCPNAME MVSNAME STATUS RANK ADDRESS MASK NETWORK PREFIX DIST -------- -------- ------ ---- --------------- --------------- ---- TCPIP S0W1 ACTIVE 255.255.255.0 10.1.3.0 DIST TCPIP2 S0W1 BACKUP 001 DEST TCPIP3 S0W1 ACTIVE DEST
We can see that TCPIP2 is defined as being the backup.
What connections does this TCPIP have
You can use the TSO command NETSTAT ALLCONN TCP TCPIP2 or the USS command netstat -a -p tcpip2 to show what sessions are active.
MVS TCP/IP NETSTAT CS V2R4 TCPIP Name: TCPIP2 07:19:15 User Id Conn Local Socket Foreign Socket State ------- ---- ------------ -------------- ----- MYSERVER 0000003F 10.1.3.10..8443 0.0.0.0..0 Listen MYSERVER 0000003C 10.1.3.10..8443 0.0.0.0..0 Listen MYSERVER 0000004B 10.1.3.10..8443 0.0.0.0..0 Listen
This shows there are 3 instances of MYSERVER running using IP address 10.1.3.10 and port 8443.
There will usually be a lot of output. You can filter the request by
- tso netstat allconn tcp tcpip2 (ipaddr 10.1.3.10
- tso netstat allconn tcp tcpip2 (port 8443
- uss netstat -a -p tcpip2 -I 10.1.3.10
- uss netstat -a -p tcpip2 -P 8443
- operator D TCPIP,tcpip2,netstat,allconn,ipaddr=10.1.3.10
- operator D TCPIP,tcpip2,netstat,allconn,port=8443
What VIPA stuff does this TCPIP have?
USS netstat -v -p tcpip3 or TSO NETSTAT VIPADYN TCP TCPIP3
MVS TCP/IP NETSTAT CS V2R4 TCPIP Name: TCPIP3 10:21:04
Dynamic VIPA:
IP Address AddressMask Status Origination DistStat
---------- ----------- ------ ----------- --------
10.1.3.10 255.255.255.0 Active Dest
ActTime: 08/30/2020 10:40:10
10.1.4.10 255.255.255.0 Active VIPARange Bind
ActTime: 08/30/2020 11:03:05 JobName: MYSERVER
The 10.1.3.10 VIPA is created using VIPADEFINE. VIPA 10.1.4.10 was create by means of VIPARANGE.
There may be multiple jobs processing the port. MYSERVER is just one of them.
ColinPaice 
One thought on “How do I find out about my VIPA configuration?”