Connecting a zPDT z/OS to the internet to using IPV6

I needed to get my ZD&T machine connected to the internet so it could download some files as part of an install. Note, this allows my z/OS to contact the internet, externals machines cannot contact my machine.

I blogged

It took a while to get it working. It is based on scenario 4 of the zD&T documentation.

The configuration uses the wireless connection from my Linux server.

You need to know/configure the address of various end points. Some addresses are configured by the systems, some addresses you need to configure.

Before you start

You need to know what the IP address of your z/OS image is

I used the GUA permanent address

   INTERFACE WIRE6 
DEFINE IPAQENET6
CHPIDTYPE OSD

IPADDR 2001:DB7:8::1
PORTNAME PORTB

INTERFACE WIRE6
ADDADDR BT:a:b:c:B8CE:404B:3360:3644
START WIRE6

What’s my TCP configuration on Linux?

The command ip addr gave (displaying only the IP V6 entries)

1: lo: <LOOPBACK,UP,LOWER_UP> ...    
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eno1:...
...
inet6 fe80::2d8:61ff:fee9:312a/64 scope link ...
3: wlxcc641aee92c5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...

inet6 BT:a:b:c:8b43:7ce6:34d1:c0fe/64 scope global temporary dynamic ...

inet6 BT:a:b:c:9824:30b:2f3d:acdb/64 scope global dynamic mngtmpaddr noprefixroute ...
inet6 fe80::7bfc:5da1:8c80:37a4/64 scope link noprefixroute ...
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ...
link/ether ...
...
inet6 fe80::48f6:deff:fef4:c8d4/64 scope link valid_lft forever preferred_lft forever

Where

  • lo is the loop back address.
  • eno1 is the connection over an Ethernet cable to my laptop
  • wlxcc641aee92c5 is the wireless connection to my router and the outside world. The IP address of the Linux server end is BT:a:b:c… . This value is used in the z/OS configuration.
  • tap0 is the tunnel interface to z/OS from the base linux machine. It has address fe80::48f6:deff:fef4:c8d4 This address is internal to the subnet.

I think these end point addresses were all generated for me.

My devmap

The devmap file contains the definitions of the emulated devices. For the OSA I had

[manager]  # tap0 define network adapter (OSA) for communication with Linux
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y # QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2

name awsosa 0010 --path=F1 --pathtype=OSD --interface=wlxcc641aee92c5
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5

Where the –interface is the same name as my wireless interface (see above).

Find_io

The find_io command gives the network configuration known by the emulation code.

FIND_IO for "colin@colin-ThinkCentre-M920s" 
Interface Current MAC IPv4 IPv6
Path Name State Addr Addr Address
---- ---------------- ----------- ---- ------ --------------
F0 eno1 UP,RUNNING 00... 10.... fe80::2d8:61ff:fee9:312a%eno1
F1 wlxcc641aee92c5 UP,RUNNING cc... 192.... BT:a:b:c:8b43:7ce6:34d1:c0fe

We have the same information as the ip addr command

The OSAs

In the devmap file the OSAs were defined as starting at 400 and 404. They each use 3 “wires”. One for reading, one for writing, and one for data (addresses 400, 401 and 402).

[manager]  # tap0 define network adapter (OSA) for communication with Linux
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y # QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2
device 403 osa osa --unitadd=3


name awsosa 0010 --path=F1 --pathtype=OSD --interface=wlxcc641aee92c5
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5
device 40a osa osa --unitadd=6

Where wlxcc641aee92c5 is the name of the wireless interface on Linux.

In the z/OS file ADCD.Z31B.VTAMLST(OSATRL2) is

OSATRL1 VBUILD TYPE=TRL                                                 
OSATRL1E TRLE LNCTL=MPC,READ=(0400),WRITE=(0401),DATAPATH=(0402), X
PORTNAME=PORTA, X
MPCLEVEL=QDIO
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406,407), X
PORTNAME=PORTB, X
MPCLEVEL=QDIO

Where we have the same addresses 400 and 404.
You refer to these definitions using PORTA and PORTB.

PORTB uses data paths 0406 for the TCPIP IPv4 inerface, and 0407 for the IPv6 Interface.

You can use the VTAM command D NET,TRL to display the status of them

          d net,trl                                         
STC05323 IST097I DISPLAY ACCEPTED
STC05323 IST350I DISPLAY TYPE = TRL
------------------------------------------------------------
TRL MAJOR NODE = ISTTRL
TRLE = IUTIQDIO STATUS = NEVAC CONTROL = MPC
TRLE = IUTSAMEH STATUS = NEVAC CONTROL = MPC
2 TRLE(S) DISPLAYED
------------------------------------------------------------
TRL MAJOR NODE = OSATRL2
TRLE = OSATRL1E STATUS = ACTIV CONTROL = MPC
TRLE = OSATRL2E STATUS = ACTIV CONTROL = MPC

Define the TCP/IP interfaces

Current levels of TCP define interfaces with the “INTERFACE” statement. DEVICE and LINK statements are deprecated.

My wireless definitions ar

                                                
INTERFACE WIRE
DEFINE IPAQENET
CHPIDTYPE OSD
IPADDR 192.168.1.61
PORTNAME PORTB
START WIRE

INTERFACE WIRE6
DEFINE IPAQENET6
CHPIDTYPE OSD
IPADDR BT:a:b:c::2
PORTNAME PORTB
; INTERFACE WIRE6
; ADDADDR BT:a:b:c::1

START WIRE6

This defines both IPv4 and IPv6 interfaces, both using the same port PORTB

The interfaces are started

I chose these two addresses myself. These address show up in the NETSTAT HOME command.

After it has started

The TSO NETSTAT HOME command gave

Home address list: 
LinkName: LOOPBACK
Address: 127.0.0.1
Flags:
IntfName: TAP0
Address: 10.1.1.2
Flags: Primary
IntfName: WIRE
Address: 192.168.1.61
Flags:
IntfName: WIRE6
Address: BT:a:b:c::2
Type: Global
Flags:
Address: fe80::cc64:1a02:ee:92c5
Type: Link_Local
Flags: Autoconfigured
IntfName: LOOPBACK6
Address: ::1
Type: Loopback
Flags:

Where we see the interfaces and their IP addresses.

Define the TCP Routes

I created COLIN.TCPPARMS(S5ROUTE) with content

BEGINRoutes 
; Destination SubnetMask FirstHop LinkName Size
ROUTE 10.0.0.0 255.0.0.0 10.1.1.1 TAP0 MTU 1492
; Default to the internet
ROUTE DEFAULT 192.168.1.254 WIRE MTU 1492
;ROUTE DEFAULT6 fe80::6a2:22ff:feae:2871 WIRE6 MTU 5000
ENDRoutes

Note there is no DEFAULT6 entry – TCPIP works this out for itself. If you have more than one IPv6 interface you should uncomment the DEFAULT6 statement to ensure the traffic goes the right way.

I used the TCPIP console command v tcpip,,obey,COLIN.TCPPARMS(S5ROUTE) to activate the routing table. If you get it wrong, edit the member, save the changes, and issue the command again.

The TSO NETSTAT ROUTE command gave me

IPv4 Destinations 
Destination Gateway Flags Refcnt Interface
----------- ------- ----- ------ ---------
Default 192.168.1.254 UGS 0000000000 WIRE
10.0.0.0/8 0.0.0.0 US 0000000000 TAP0
10.1.1.2/32 0.0.0.0 UH 0000000000 TAP0
127.0.0.1/32 0.0.0.0 UH 0000000000 LOOPBACK
192.168.1.61/32 0.0.0.0 UH 0000000000 WIRE
IPv6 Destinations
DestIP: Default
Gw: fe80::6a2:22ff:feae:2871
Intf: WIRE6 Refcnt: 0000000000
Flgs: UGD MTU: 1492
DestIP: ::1/128
Gw: ::
Intf: LOOPBACK6 Refcnt: 0000000000
Flgs: UH MTU: 65535
DestIP: BT:a:b:c::/64
Gw: ::
Intf: WIRE6 Refcnt: 0000000000
Flgs: UD MTU: 1492
DestIP: BT:a:b:c::2/128
Intf: WIRE6 Refcnt: 0000000000
Flgs: UH MTU: 1492
DestIP: fe80::cc64:1a02:ee:92c5/128
Gw: ::
Intf: WIRE6 Refcnt: 0000000000
Flgs: UH MTU: 1492

Where fe80::6a2:22ff:feae:2871 is from the BT Hub IPv6 LAN details: Link local address:.

The command TSO NETSTAT ND gives the neighbour discovery. This gave me

Query Neighbor cache for fe80::6a2:22ff:feae:2871 
IntfName: WIRE6 IntfType: IPAQENET6
LinkLayerAddr: 04A222AE2871 State: Reachable
Type: Router AdvDfltRtr: Yes

Which shows what IPv6 neighbours have been discovered.

And finally – test it

I could use the TSO PING command to ping a server the internet. Check you can ping the address from Linux before you try it from z/OS, because some servers do not respond to ping requests.

Doing a wireshark trace of a successful ping showed the originator IP address was BT:a:b:c::2, the home address of interface WIRE6 in TCPIP on my z/OS image.

Connecting a zPDT z/OS to the internet using IPv4

I needed to get my ZD&T machine connected to the internet so it could download some files as part of an install. Note, while this allows my z/OS to contact the internet, externals machines cannot contact my machine.

As a follow-on to this Blog post I wrote Connecting a zPDT z/OS to the internet to using IPV6 which extends this post.

As usual there are many strands to this, so I wrote Understanding BT home hub and my IPv6 addresses to cover some of the background knowledge.

It took a while to get it working. It is based on scenario 4 of the zD&T documentation.

The configuration uses the wireless connection from my Linux server.

You need to know/configure the address of various end points. Some addresses are configured by the systems, some addresses you need to configure.

What’s my TCP configuration on Linux?

The command ip addr gave (displaying only the IP V4 entries)

1: lo: <...> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

2: eno1: <...> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:...
altname enp0s31f6
inet 10.1.0.3/24 brd 10.1.0.255 scope global eno1
valid_lft forever preferred_lft forever

3: wlxcc641aee92c5: <...> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether cc:...
inet 192.168.1.139/24 brd 192.168.1.255 scope global dynamic noprefixroute wlxcc641aee92c5
valid_lft 80179sec preferred_lft 80179sec
noprefixroute
valid_lft 263sec preferred_lft 83sec
inet6 fe80::7bfc:5da1:8c80:37a4/64 scope link noprefixroute
valid_lft forever preferred_lft forever
5: tap0: <...> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 46:...
inet 10.1.1.1/24 brd 10.1.1.255 scope global tap0
valid_lft forever preferred_lft forever

Where

  • lo is the loop back address.
  • eno1 is the connection over an Ethernet cable to my laptop with the address (on this linux machine) 10.1.0.3. The address of the other end of the Ethernet, on my laptop, is 10.1.0.2
  • wlxcc641aee92c5 is the wireless connection to my router and the outside world. The IP address of the Linux server end is 192.168.1.139.
  • tap0 is the tunnel interface to z/OS from the base linux machine. It has address 10.1.1.1

I think these end point addresses were all generated for me.

Linux Settings

I believe that you need some Linux settings. Having repeated the scenario, it works even when the values described where set to 0, so the guidance in this section may not be relevant.

sysctl net.ipv4.ip_forward

to display the value. It needs to be 1. You can set it using

sudo sysctl -w net.ipv4.ip_forward=1
#sudo sysctl -w net.ipv6.conf.all.forwarding=1

You can do commands like

sysctl -a |grep v4
sysctl -a |grep v6

My devmap

The devmap file contains the definitions of the emulated devices. For the OSA I had

[manager]  # tap0 define network adapter (OSA) for communication with Linux
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y # QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2

name awsosa 0010 --path=F1 --pathtype=OSD --interface=wlxcc641aee92c5
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5

Where the –interface is the same name as my wireless interface (see above).

When I used IPv6 as well as IPv4, there were two TCPIP Interface on the same OSA. I need address 406 and 407 for one interface, and 408 and 409 for the other interface. The TCPIP documentation does not say this.

Find_io

The find_io command gives the network configuration known by the emulation code.

FIND_IO for "colin@colin-ThinkCentre-M920s" 

Interface Current MAC IPv4 IPv6
Path Name State Addr Address Address
------ ---------------- ---------------- ---- ------------- --------------
F0 eno1 UP, RUNNING 00:.. 10.1.0.3 fe80::...%eno1
F1 wlxcc641aee92c5 UP, RUNNING cc:.. 192.168.1.139 2a00:...
A0 tap0 UP, RUNNING 46:.. 10.1.1.1 fe80::...@tap0
...

End of FIND_IO

This is the same information as the ip addr command

The OSAs

In the devmap file the OSAs were defined as starting at 400 and 404. One for reading, one for writing, and several for data.

In the z/OS VTAM file ADCD.Z31B.VTAMLST(OSATRL2) (below) defines two OSAs.

The first is for my Ethernet. This has one TCPIP Interface, and so paths 402 and 403 for the data.

The second is for the wireless connection. This has two TCPIP interfaces one for IPV4 and one for IPv6. One uses path (406,407), the other uses(408,409). These addresses must match the devmap definitions.

OSATRL1 VBUILD TYPE=TRL                                                 
OSATRL1E TRLE LNCTL=MPC,READ=(0400),WRITE=(0401),DATAPATH=(0402), X
PORTNAME=PORTA, X
MPCLEVEL=QDIO
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406,407), X
PORTNAME=PORTB, X
MPCLEVEL=QDIO


You refer to these definitions using PORTA and PORTB in the TCPIP interfaces

You can use the VTAM command D NET,TRL to display the status of them

          d net,trl                                         
STC05323 IST097I DISPLAY ACCEPTED
STC05323 IST350I DISPLAY TYPE = TRL
------------------------------------------------------------
TRL MAJOR NODE = ISTTRL
TRLE = IUTIQDIO STATUS = NEVAC CONTROL = MPC
TRLE = IUTSAMEH STATUS = NEVAC CONTROL = MPC
2 TRLE(S) DISPLAYED
------------------------------------------------------------
TRL MAJOR NODE = OSATRL2
TRLE = OSATRL1E STATUS = ACTIV CONTROL = MPC
TRLE = OSATRL2E STATUS = ACTIV CONTROL = MPC

Define the TCP/IP interfaces

Current levels of TCP define interfaces with the “INTERFACE” statement. DEVICE and LINK statements are deprecated.

My definitions for IPv4 are

 INTERFACE TAP0 
DEFINE IPAQENET
CHPIDTYPE OSD
IPADDR 10.1.1.2
PORTNAME PORTA
START TAP0

INTERFACE WIRE
DEFINE IPAQENET
CHPIDTYPE OSD
IPADDR 192.168.1.61
PRIROUTER
PORTNAME PORTB
START WIRE

This defines an interface TAP0 using the PORTA definitions above, and gives the z/OS end of the connection the address 10.1.1.2. From my laptop I can ping 10.1.1.2, it gets routed to the Linux server, and into z/OS.

The interface is started

Another interface WIRE is defined using PORTB and the z/OS end of the connection is 192.168.1.61

I chose these two addresses myself. These address show up in the NETSTAT HOME command.

After it has started

The TSO NETSTAT HOME command gave

MVS TCP/IP NETSTAT CS 3.1     
Home address list:
LinkName: LOOPBACK
Address: 127.0.0.1
Flags:
IntfName: TAP0
Address: 10.1.1.2
Flags: Primary
IntfName: WIRE
Address: 192.168.1.61
Flags:

Where we see the interfaces and their IP addresses.

Define the TCP Routes

I created COLIN.TCPPARMS(S5ROUTE) with content

BEGINRoutes 
; Destination SubnetMask FirstHop LinkName Size
ROUTE 10.0.0.0 255.0.0.0 10.1.1.1 TAP0 MTU 1492
ROUTE 192.168.1.0 255.255.255.0 = WIRE MTU 1492
ROUTE DEFAULT 192.168.1.254 WIRE MTU 1492
ENDRoutes

This says for the destination IP address if it is

  • anything beginning with 10. (from the subnet mask 255.0.0.0) send it over interface TAP0. The command ip addr shows tap0 with inet 10.1.1.1/24 brd 10.1.1.255
  • anything with address 192.168.1.something (from the subnet mask 255.255.255.0) sent it over interface WIRE (note: in this case this definition is redundant because of the default below).
  • anything else, send it down the DEFAULT definition over interface WIRE. The IP address of my wireless router is 192.168.1.254. Initially I had a different address – the address in the find_io. After several pings which timed out, ping worked. It is better to specify the address of the router/hub.

I used the TCPIP console command v tcpip,,obey,COLIN.TCPPARMS(S5ROUTE) to activate the routing table. If you get it wrong, edit the member, save the changes, and issue the command again.

The TSO NETSTAT ROUTE command gave me

IPv4 Destinations 
Destination Gateway Flags Refcnt Interface
----------- ------- ----- ------ ---------
Default 192.168.1.254 UGS 0000000000 WIRE
10.0.0.0/8 0.0.0.0 US 0000000000 TAP0
10.1.1.2/32 0.0.0.0 UH 0000000000 TAP0
127.0.0.1/32 0.0.0.0 UH 0000000000 LOOPBACK
192.168.1.61/32 0.0.0.0 UH 0000000000 WIRE

And finally – test it

I could use the TSO PING command to ping a server the internet. Check you can ping the address from Linux before you try it from z/OS, because some servers do not respond to ping requests.

Useful commands

On Linux

  • ip addr
  • ip route

On z/OS

VTAM operator commands
  • D NET,TRL
  • d net,trl,trle=OSATRL2E This gives information such as which OSA data ports are being used, by with TCPIP interfaces.
  • D NET,ID=…
  • D NET,ID=…,E
  • V NET,ACT,ID=….
  • V NET,INACT,ID=….
TCPIP operator commands
  • v tcpip,,obey,… for example COLIN.TCPPARMS(S5ROUTE)

TSO commands

  • TSO NETSTAT HOME
  • TSO NETSTAT ROUTE
  • TSO PING x.x.x.x
  • TSO TRACERTE x.x.x.x

Some problems I experienced

A ping did not get a response back

A wireshark trace of the wireless interface showed the ping request had an originator IP address of 10.1.1.2. This was caused by having the wrong routing table

MVS TCP/IP NETSTAT CS 3.1       TCPIP Name: TCPIP           17:10:28 
IPv4 Destinations
Destination Gateway Flags Refcnt Interface
----------- ------- ----- ------ ---------
Default 10.1.1.1 UGS 0000000000 TAP0
10.0.0.0/8 0.0.0.0 US 0000000000 TAP0
10.1.0.0/24 10.1.1.1 UGS 0000000000 TAP0
10.1.1.2/32 0.0.0.0 UH 0000000000 TAP0
127.0.0.1/32 0.0.0.0 UH 0000000000 LOOPBACK
192.168.1.61/32 0.0.0.0 UH 0000000000 WIRE

The default routing was via TAP0

The NETSTAT HOME gave

 MVS TCP/IP NETSTAT CS 3.1       TCPIP Name: TCPIP       
Home address list:
LinkName: LOOPBACK
Address: 127.0.0.1
Flags:
IntfName: TAP0
Address: 10.1.1.2
Flags: Primary
IntfName: WIRE
Address: 192.168.1.61
Flags:

So the IP address of the TAP0 interface was 10.1.1.2, and this was used as the originating end point.

Any nodes on the route to the destination do not know where 10.1.12 is located …. 10.*.*.* it is usually an address on the local machine, and so you get no response back.

With the address 192.168.1.xx the wireless router converts it to the router’s own address, and so the intermediate nodes on the journey can use the hub’s IP address, and the reply gets back to the wireless router.

Ping failed – nothing in wireshark

  INTERFACE WIRE 
DEFINE IPAQENET
CHPIDTYPE OSD
IPADDR 192.168.1.60
PRIROUTER
VLANID 2
PORTNAME PORTB

I had VLANID 2 … when I removed this statement it worked.

Sessions failed to start

When I started TCPIP I got the message

EZZ4336I ERROR DURING ACTIVATION OF INTERFACE WIRE – CODE 8010002A DIAGNOSTIC CODE 02

Using the command D U,,,400,8 showed

UNIT TYPE STATUS        VOLSER     VOLSTATE      SS  
0400 OSA A-BSY 0
0401 OSA A 0
0402 OSA A-BSY 0
0403 OSA O 0
0404 OSA OFFLINE 0
0405 OSA OFFLINE 0
0406 OSA OFFLINE 0
0407 OSA OFFLINE 0

This shows the second OSA was not available (it was offline). I found I had misconfigured the OSA with addresses (404, 405, and 406) in my devmap.

How does my network interface get an IP address, and is a generated address ok to use?

This article has some good concepts about IP V6 addresses.

What addresses does an interface have?

An interface (think end of an Ethernet cable) typically has one IP V4 address which is usually manually assigned to it, and/or multiple IPV6 addresses.

An interface can have multiple IPV6 addresses – why?

You can explicitly define it

You can assign your own IP address(es) to the interface. You can do this so it has a global address, reachable from other networks.

Dynamic Host Configuration Protocol (DHCP)

If you are using a DHCP client, it communicates with a DHCP server which gives it configuration information, such as an IP address, and subnet, the client then configures the interface.

There has been a shortage of IP V4 addresses for many years. Consider an office which has a “drop-in area”. Rather than give each of the potential uses an IP address, the office is given as many IP addresses as there are desks in the drop-in area. This means perhaps 10 ip addresses are needed instead of 100. This is the advantage of DHCP.

For client devices this is fine. Your machine connects to the server and passes its IP address. The server does some work and sends the response back to the requester.

Tomorrow you may get a different IP address. It works. This means no IP address information is saved across different days. It is stateless.

A server needs either

  • a fixed IP address so clients can contact it,
  • a dynamic address, and an update to the DNS router to say “today megabank.com is on IP address 9.99.99.1”. It can take time to propagate an IP address across the worldwide DNS network.

IPv6 Stateless Address Auto-configuration (SLAAC)

The ideas behind DHCP have been extended in IPV6, the concepts are similar. Stateless Address Auto-configuration is well documented here

Within a network or router domain the system can generate an address, and it is only used within this domain, it could have a different address every time the interface is started. This is known as Stateless Address Autoconfiguration.

When an interface is started it generates an “internal use” address composed of FE00 + a mangled MAC address.

The interface then asks all devices on the local network, does anyone have this address FE00… This is for Duplicate Address Detection (DAD). There should be no reply. If there is a reply, then there is a duplicate address on the network (and the interface generates another address and repeats the process).

The interface then sends out a Router Solicitation request asking “Are there any routers out there?”. A router will then reply giving information. It will contain the “global IP prefix” such as 2001:db8::. which means to the outside world, my the address of the router is 2001:db8::/64. From this information plus the MAC address the interface can generate its IP address. The router also contains the address of the gateway (the address of the router with connections to the outside world) so traffic can now be routed externally.

This means you configure the router, and not the individual devices. If you have many devices this can save you a lot of work. If you change the router configuration, it is propagated to all the devices attached to it.

IPV6 privacy extensions will generate a “random address” (within the subnet). This is to prevent bad actors from monitoring traffic and using your IP address to monitor what sites you visit. By having a different IP address every day means they cannot correlate the traffic for a user.

Does it matter if my address is auto generated?

This is another of the “it depends” answers.

For machines that initiate work, it may not matter that the allocated IP address is different everyday or the same every day. Your IP address is passed with the request to the server. The server does the work, and sends the response back through the network. Assuming the network is configured properly the response will get back to you.

If your machine is a server machine, clients need to know the server’s address. If this changes your clients may need to use DNS to find the new address, and not use the dotted IP address. You may want to allocate a permanent IP address (within the router’s subnet).

Routers, firewalls and filters.

If your machines address is within the router’s subnet, traffic should be able to get to your router and so to your machine. If you change the subnet, traffic may not get to your router.

A firewall can be configured to allow traffic to and from specified addresses (and ports). If you use a different address, either at client or the server, the firewall may not let your packets through. Similarly with a network filter.

I was playing around with configuring IP V6 on my laptop, and the connection to z/OS failed. This was because I had been using one IP address, which I could see flowing to the back-end. When I tried some other configuration, there were more IP addresses allocated to the client, and a different IP address was used as the originator’s IP address in the ping request. The back-end server did not know how to route traffic back to this address, and so the return packets were thrown away and the ping timed out.

You need to be aware which addresses are used for your work. With some IP programs you can bind to a specific local IP address, and force the application to use a particular IP address. For example the Linux Ping command -I interface option.

Real time monitor for z/OS TCPIP interface statistics

Ive put up on Github a program which provides real time statistics for z/OS TCPIP interfaces.  For example

Interface       ,HH:MM:SS,IBytes,OBytes,IB/sec,OB/sec,,IUP   ,OUP   ,,...
TAP0 ,09:11:12, 0, 0, , ,, 0, 0,,...
TAP0 ,09:11:22, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:11:32, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:11:42, 348, 348, 34, 34,, 3, 3,,
TAP0 ,09:11:52, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:12:02, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:12:12, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:12:22, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:12:32, 0, 0, 0, 0,, 0, 0,,
TAP0 ,09:12:42, 0, 0, 0, 0,, 0, 0,,

Where the values are deltas from the previous time interval

  • IBytes is input bytes during that interval
  • OBytes is output bytes
  • IB/Sec is rate of input bytes
  • OB/Sec is rate of output byte
  • IUP is count of Input Unicast packets
  • OUP is count of Output Unicast packets.

You get one output file per interface.

The output file can be downloaded and used as input to a spread sheet, to graphically display the data.

I’m working on some code to display the global TCPIP stats, but I do not think they are very interesting.  If they are interesting to you, please let me know and I’ll add my code.

Converting from TCP/IP devices to interfaces

TCP/IP supports devices for IP V4 using statements like

DEVICE PORTA MPCIPA
  LINK ETH1 IPAQENET PORTA
...
HOME ...
     10.1.1.2 ETH1
...

BEGINRoutes 
...
ROUTE DEFAULT      10.1.1.1 ETH1 MTU 1492 
ENDRoutes 
                                                                   

START PORTA

z/OS TCP has said these DEVICE and LINK statements should be converted these to use the INTERFACE statement, because the LINK and DEVICE statements will be withdrawn in a future release.

The interface statement basically merges the DEVICE, LINK and the relevant part of HOME into one INTERFACE statement. You can use Interface statements for IP V4 and IP V6. They are easier to configure and activate than DEVICE and LINK statements

The equivalent interface statement is

INTERFACE ETH1 
    DEFINE IPAQENET 
    CHPIDTYPE OSD 
    IPADDR 10.1.1.2 
    PORTNAME PORTA         
                 

The command can be written on one (or more lines). You can have

   INTERFACE JFPORTCP4
DEFINE IPAQENET
; this is a comment 
CHPIDTYPE OSD IPADDR 10.1.1.2 PORTNAME PORTA

( Personally I would not; I prefer the command to start in column 1, and following lines indented).

If you name the interface the same as the LINK statement, you will not need to change any routing statements.

The easiest way of implementing the change is to make the change and restart TCP/IP.

The changes you need to make are

  • Replace the DEVICE and LINK statements with the INTERFACE statement
  • Remove the IP address from the HOME
  • Change the START from the port to the interface name

Check it has been defined

After you have restarted TCP/IP

tso netstat home 

gave

MVS TCP/IP NETSTAT CS V2R4       TCPIP Name: TCPIP   
Home address list: 
LinkName:   LOOPBACK 
  Address:  127.0.0.1
    Flags: 
IntfName:   ETH1 
  Address:  10.1.1.2 
    Flags:  Primary 
IntfName:   LOOPBACK6
  Address:  ::1 
    Type:   Loopback 
    Flags: 

The command

tso netstat devlinks 

Gave

IntfName: ETH1              IntfType: IPAQENET   IntfStatus: Ready
    PortName: PORTA     Datapath: 0402     DatapathStatus: Ready 
    CHPIDType: OSD            SMCR: Yes 
    PNetID: *None*            SMCD: Yes 
    TRLE: OSATRL1E 
    Speed: 0000001000 
    IpBroadcastCapability: No 
    CfgRouter: Non                   ActRouter: Non 
    ArpOffload: Yes                  ArpOffloadInfo: Yes 
    CfgMtu: None                     ActMtu: 8992 
    IpAddr: 10.1.1.2/0 
    VLANid: None                     VLANpriority: Disabled 
    ReadStorage: GLOBAL (4096K) 
    InbPerf: Balanced 
    ChecksumOffload: Unsupported     SegmentationOffload: No 
    SecClass: 255                    MonSysplex: No 
    Isolate: No                      OptLatencyMode: No 
  Multicast Specific: 
    Multicast Capability: Yes 
    Group             RefCnt        SrcFltMd 
    -----             ------        -------- 
    224.0.0.1         0000000001    Exclude 
      SrcAddr: None 
  Interface Statistics: 
...
                                                            
IPv4 LAN Group Summary 
LanGroup: 00001 
  Name              Status      ArpOwner          VipaOwner 
  ----              ------      --------          --------- 
  ETH1              Active      ETH1              Yes 
                                                                                                                     
                                                         

where interesting fields are

  • IntfName: ETH1 the interface name
  • IntfType: IPAQENET the interface type
  • IntfStatus: Ready the status of the interface
  • PortName: PORTA the port name
  • Datapath: 0402 what device is being used
  • IpAddr: 10.1.1.2/0 the IP address of the z/OS end of the connection

If you are using DEVICE and LINK the output will have LnkName: ETH1 instead of IntfName: ETH1.

If you are brave…

you can remove the LINK and DEVICE definitions from the active system and activate the INTERFACE, then at a later date, update the TCP/IP configuration file.

You need to

  • stop the existing definition
  • remove the HOST entry for the device
  • delete the DEVICE and LINK from the running configuration
  • activate the interface statement
  • start the interface

Stop the device

V TCPIP,TCPIP,STOP,PORTA

You cannot use V TCPIP,TCPIP,STOP,ETH1 because it says device not found.

Remove the HOME entry for the link

Copy the home statements into a file, remove the entry you do not want, then issue the V…OBEY… on that file. This replaces the active HOME entries.

If you use TSO NETSTAT HOME, the IP address should not be present.

Delete the link and device from the active configuration

One you have removed the HOME statements, and TSO NETSTAT HOME does not show any entries for the device, you can create members DELLINK

DELETE LINK ETH1

and member DELDEV

DELETE DEVICE PORTA

Use the V…OBEY… in turn on each file. You cannot put both commands in one file, as the commands are processed asynchronously and the delete link command may still be executing when the delete device is executed, and then so fail.

The TSO NETSTAT DEVLINKS command should show the link is not in the output.

Activate the interface

Put your interface definition statements into a file and activate it using

V TCPIP,TCPIP,OBEY,USER.Z24C.TCPPARMS(JFACE41)

My definition defines an interface with name JFPORTCP4.

Start the interface

V TCPIP,TCPIP,STA,JFPORTCP4

Test it

TSO NETSTAT HOME should show the IP address, and you should be able to ping it.

You can use TSO NETSTAT DEVLINKS (INTFNAME JFPORTCP4 to display the interface.

Make the change permanent

You will need to:

  • Comment out/remove the PATH and LINK definitions
  • Remove/comment out the IP address and link from the HOME statement
  • Remove the start of the device
  • Add the interface definition. This could be done using an INCLUDE statement
  • Add a start of the interface (or add it to the include file).
  • Use V…OBEY… with the start-up configuration file, or restart TCP/IP
  • Change your documentation!