We found that Linux is trying to own the IP address which we have given to z/OS. We came to this conclusion because we found that IP address given to Linux and z/OS both shows the same mac address.
We run the arp –a from one windows server which is part of the same subnet. Windows IP was 170.248.90.131 and output of command is as below:
C:\Users\>arp -a

Interface: 170.248.90.131 --- 0xa
Internet Address Physical Address Type
170.248.90.129 00-10-db-ff-20-50 dynamic
**170.248.90.130 00-50-56-83-3e-84 dynamic --- Linux IP**
**170.248.90.134 00-50-56-83-3e-84 dynamic --- z/OS IP**
170.248.90.143 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static

Both IP has same mac address. Is it expected? As per my understanding it looks like Linux try to own the z/OS IP as well when we try to connect to z/OS IP address since it shows same mac address.
Linux should allow to pass the traffic till z/OS rather than accepting it by owing the IP address which is given to z/OS.

Request you to please suggest above behavior is normal or something is wrong?.

Please describe exactly what you are trying to do. When creating a TCP/IP network for use with RD&T, in the most common configuration, seperate TCP/IP networks with corresponding IP addresses are required for z/OS and the hosting linux OS. Note these are completely separate networks. The z/OS simulator actually shares the physical adapter used by linux to route its z/OS OSA traffic. If you have configured the same IP address for linux and for z/OS, you will have problems.

RDzJohn

IP of the Linux Machine is 170.248.90.130 and we have assingned the ip 170.248.90.134 for z/OS TCPIP.

We are able to connect to mainframe using Coax session(i.e linux ip 170.248.90.130 and port 3270)

We want to use TCPIP to connect to mainframe(i.e 170.248.90.134 and port 3273).

but the IP defined for TCPIP 170.248.90.134 gets the linux MAC address and linux trying to own the TCPIP IP as well.

This is normal behavior. As mentioned in the previous post, both linux and z/OS OSA share the same adapter. Your problem is likely not with the network adapter, but with the z/OS TCP/IP network definitions. I assume you are using the aws3274 driver to connect to linux port 3270. This is a simulated SNA 3274 connection that does not use TCP/IP.

To use z/OS TCP/IP you must use the awsosa driver to define OSA connections in your device map correctly, define VTAM TRLE endpoints correctly, and define TCPIP.PROFILE and TCPIP.DATA datasets correctly. This is described in zPDT Redbook Vol. 2. Network scenario 4 is the easiest to implement.

RDzJohn

Thanks for the help and valuable information. I have RDz manuals with me and I have gone through that. Let me explain you about the environment, issue and troubleshooting we have performed.

1. We have implemented the scenario 4 and I am able to connect using 3270 terminal emulator. I referred to Coax as local channel connected 3270s. In Coax we use the linux IP address using port 3270 which is mentioned in configuration file as below:

3270port 3270 # port number for non-SNA 3270
Name aws3274 C700 # non-SNA 3270 terminal

Using Coax I get login in TSO.
2. We have three interface on linux eth0 , lo and tap0.

a. Tap0 ( 192.168.10.1 ) is the tunnel interface on linux which is corresponding to z/OS eth1 interface ( 192.168.10.20 ). I am able to telnet it from linux and it is working fine.
b. Lo is loopback and I think no issue with that.
c. Eth0 interface on linux with IP address 170.248.90.130 is corresponding to z/OS interface ETH2 with IP address 170.248.90.134. We use this IP to access the z/OS through TCPIP and telnet. I am able to ping this IP address through network but I can't connect it using TCPIP through 3270 emulator. When I run the netstat I could see in z/OS that request reached till z/OS TCPIP and it is SynRcvd state as below.

EZZ2587I TN3270 00000055 170.248.90.134..3273 172.31.82.186..55948 SynRcvd

But it always remain same in this state and after some time it get disconnected due to time out I assume.

Sometimes I can see in netstat the established connection as below but telnet session at emulator is disconnected:

TN3270 0000005E 170.248.90.134..3273 172.31.82.186..50193 Establsh
TN3270 0000000F 0.0.0.0..3273 0.0.0.0..0 Listen

TN3270 0000005A 170.248.90.134..3273 172.31.82.186..56011 Establsh

3. Linux netstat output is as below:

Tue Aug 14 05:30:30 ibmsys1@amozpdt01:/z1>netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
170.248.90.128 * 255.255.255.240 U 0 0 0 eth0
192.168.10.0 * 255.255.255.0 U 0 0 0 tap0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 170.248.90.129 0.0.0.0 UG 0 0 0 eth0
Tue Aug 14 05:30:34 ibmsys1@amozpdt01:/z1>

4. The z/OS TCPIP config is as below:

HOME 192.168.10.20 ETH1
HOME 170.248.90.134 ETH2

ROUTE 192.168.10.0 255.255.255.0 = ETH1 MTU 1492
ROUTE 170.248.90.128 255.255.255.240 = ETH2 MTU 1492
ROUTE DEFAULT 170.248.90.129 ETH2 MTU DEFAULTSIZE

So the issue I think is either with the network, linux interface or static route we have in z/OS TCPIP configuration which is not allowing the packet to send back to network. Network folks says there is no packet drop at any firewall/router so now we are stuck, not sure where is the problem.

Troubleshooting we have performed:

---

1. I did the telnet on 170.248.90.134 from z/OS itself which I connected through Coax and it worked fine which shows to me telnet is running fine on MF.
2. I tried telnet and FTP from linux ( IP address : 170.248.90.130 ) to z/OS ( IP address : 170.248.90.134 ) , I got immediate response of connection refused but when I did the same for the IP address 192.168.10.20 it went through.
3. From linux I am able to ping z/OS IP address ( 170.248.90.134 ), even from outside linux from the network I am able to ping z/OS IP address.

So need your help to understand where is the glitch. Please let me know if you need further information from my end.

A few points.

• You cannot use the host linux to communicate with the hosted z/OS using the OSA connection. The simulated OSA does not support this communication. I would expect all pings, etc... to fail in this situation. You must use the tunnel address to communicate between z/OS and hosting linux. You could also access the z/OS from another machine on your LAN.
• Use the linux find_io command to ensure that you are using the right chpids in your device map definition.
• tap0 defaults to ip address 10.1.1.1. The tunnel address on z/OS is usually set to 10.1.1.2. In your case you are using different values for your tunnel so you need to specify them in your device map.
• look in the VTAM joblog on z/OS and ensure your TRLE definitions and endpoints were defined correctly.
• look in the TCPIP joblog and ensure that all TCPIP devices started properly.

These are the proper steps to diagnose a network problem on RD&T.

RDzJohn

We had found that we are able to ping the TCPIP Defined ip 170.248.90.134, when tcpip is up and down as well.
Usually we wont be able to ping the IP address defined to TCPIP when its done. Does some other machine is owning the IP?

Find the output of find_io Command
on Aug 27 02:21:21 ibmsys1@amozpdt01:/z1>find_io

Interface Name tap0 -> MAC addr 2:a0:a0:a0:a0:a0 Flags = 0
Interface Name tap1 -> MAC addr 2:a1:a1:a1:a1:a1 Flags = 0
Interface Name tap2 -> MAC addr 2:a2:a2:a2:a2:a2 Flags = 0
Interface Name tap3 -> MAC addr 2:a3:a3:a3:a3:a3 Flags = 0
Interface Name eth0 -> MAC addr 0:50:56:83:3e:84 Flags = 0
====== Start of Chpid Registry Information =====

Total Interfaces Found = 5
Chpid Num Type State Slot Num Port Num Card Interface Name
========= ==== ===== ======== ======== ======== ==============
a0 0 808 ff 0 Tun/Tap tap0
a1 0 808 ff 0 Tun/Tap tap1
a2 0 808 ff 0 Tun/Tap tap2
a3 0 808 ff 0 Tun/Tap tap3
f0 0 808 ff 1 Wired eth0
====== End of Chpid Registry Information =====

====== io_slot.dat file created with registry information==

Profile definition:
3270port 3270 # port number for non-SNA (coax) 3270

manager
#name aws3274 0002 # define non-SNA (coax) 3270 terminals
name aws3274 C700 # define non-SNA (coax) 3270 terminals
device 0700 3279 3274 mstcon
device 0701 3279 3274 tso
device 0702 3279 3274 tso
device 0703 3279 3274 tso
device 0704 3279 3274 tso
device 0705 3279 3274 tso
device 0706 3279 3274 tso
device 0707 3279 3274 tso
device 0708 3279 3274 tso
device 0709 3279 3274 tso
device 0710 3279 3274 tso
device 0711 3279 3274 tso
device 0712 3279 3274 tso
device 0713 3279 3274 tso
device 0900 3279 3274 tso
device 0901 3279 3274 tso
device 0902 3279 3274 tso
manager # define 3490 tape drive
name awsscsi 7000
#device 0580 3490 3490 /dev/sg0
#device 0581 3490 3490 /dev/sg1
#device 0582 3490 3490 /dev/sg2
#device 0583 3490 3490 /dev/sg3

manager # define network adapter (OSA)
#name awsosa 24 --path=F0 --pathtype=OSD # QDIO mode
#name awsosa 24 --path=F1 --pathtype=OSD # QDIO mode
#name awsosa 22 --path=A1 --pathtype=OSD --tunnel_intf=y # QDIO mode
name awsosa 24 --path=A0 --pathtype=OSD --tunnel_intf=y --tunnel_ip=192.168.10.1 --
tunnel_mask=255.255.255.0
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2

manager # define network adapter (OSA)
name awsosa 22 --path=F0 --pathtype=OSD
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
Please give your suggestions.

Please send VTAMLST member, TCPIP.PROFILE and TCPIP.DATA datasets you are using. Also VTAM and TCPIP JOBLOGs, and SYSLOG.

RDzJohn

could you tell me how can i attach the required documents in this thread?

Hello RDzJohn, I had dropped the mail to you.

I have reviewed your documentation. I see no errors in your devmap, your VTAMLST, your TCPIP.DATA, or your TCPIP.PROFILE. Linux is working properly. VTAM is activating the TRLE endpoints correctly, and TCP/IP encounters no errors when it starts the OSA adapters. This leaves your TCPIP.DATA as the likely problem area. I am not a TCPIP Routing expert so you'll probably need your z/OS networking programmers to help you verify the routes are correct for your environment.

Until TCP/IP is working properly, you must use the 3274 terminal for interacting with z/OS. I open an OMVS session and use ping to verify the host linux across the tunnel address. I then open a linux command window and ping z/OS across the tunnel address. Assuming these work, you can assume the tunnel is configured correctly. If they don't work, you'll need to verify your tunnel configuration in the devmap and in your TCPIP.DATA file.

I use the same OMVS session to ping another workstation ip address on my LAN. If this works, your ROUTEs are correct. If not, you need to fix up your ROUTE statements. From the workstation I ping the z/OS across the OSA IP address. If this works, your HOME is set correctly. If it doesn't you need to fix up your HOME statement.

One suggestion I would make for you is to cleanup your configuration files and eliminate/ delete unused statements and parameters where they are not needed. It makes the files easier to read. In your devmap, I don't see the need for so many 3270 definitions. I usually have one for the master console and a max of 3 for VTAM sessions. I also have never had a need to change the default cunmbr (0002). This is a meaningless parameter as control units have no meaning in this simulated environment. If there is no requirement to change the tunnel address, why not use the default of 10.1.1.1 ? Again, this makes things simpler and you know you're travelling a path that many others have.

RDzJohn

Thanks John.
Our TCPIP is working now. we are able to connect.
The problem was with the ip .134. we found that ip was assigned to Linux machine as well.
We used new IP .136 and everything worked as expected.