I'm hoping that there is a fix for this, because a known fix, is easier
to fix then changing our network <G>.
I have two LPARs,
LPAR0, is the 390 side.
z/VM 5.1 IP address 205.235.227.74
Runs mostly VSE guests, IP address 192.168.99.xxx
OSA ports 2000 - 2005
LPAR1, is the IFL side.
z/VM 5.1 IP address is 192.168.193.3 (this is a supernet
192.168.192/22)
Runs mostly zLinux guests, IP address 192.168.193.xxx
OSA ports 2010-2015
Both LPARs are using vswitch.
Instead of installing z/VM 5.2 in another LPAR, I installed it, second
level, under LPAR0.
VMTEST on the 390 side
z/VM 5.2 IP address 192.168.194.4 (note that this address is covered
by the supernet, but LPAR1 isn't using this Class C network).
OSA ports 2016-2018.
Note all addresses are on the same OSA card, and the same port on the
card. If the network types are doing any routing for me, everything
should be getting to the same, physical cable. So I'm hoping that any
routing problems can be solved on my side.
I can ping myself 192.168.194.4.
I cannot ping 192.168.194.1, 205.235.227.41, 205.235.227.74,
192.168.3.21 (my PC).
And it doesn't seem that anyone can ping me (192.168.194.4).
netstat home
VM TCP/IP Netstat Level 520
IPv4 Home address entries:
Address Subnet Mask Link
------- ----------- ------
192.168.194.4 255.255.255.0 QDIO1
IPv6 Home address entries: None
Ready; T=0.02/0.04 11:14:00
netstat gate
VM TCP/IP Netstat Level 520
Known IPv4 gateways:
Subnet Address Subnet Mask FirstHop Flgs PktSz Metric Link
-------------- ----------- -------- ---- ----- ------
------
Default <none> 205.235.227.41 UGS 1500 <none>
QDIO1
192.168.194.0 255.255.255.0 <direct> UT 1500 <none>
QDIO1
205.235.227.0 255.255.255.0 <direct> US 1500 <none>
QDIO1
Known IPv6 gateways: None
Ready; T=0.02/0.04 11:14:16
netstat dev
VM TCP/IP Netstat Level 520
Device [EMAIL PROTECTED] Type: OSD Status: Ready
Queue size: 0 CPU: 0 Address: 2016 Port name:
UNASSIGNED
IPv4 Router Type: NonRouter Arp Query Support: Yes
Link QDIO1 Type: QDIOETHERNET Net number: 0
BytesIn: 0 BytesOut: 308
Forwarding: Enabled MTU: 1500 IPv6: Disabled
Broadcast Capability: Yes
Multicast Capability: Yes
Group Members
----- -------
224.0.0.1 1
Ready; T=0.02/0.03 11:14:31
The config file:
;
----------------------------------------------------------------------
DEVICE [EMAIL PROTECTED] OSD 2016
LINK QDIO1 QDIOETHERNET [EMAIL PROTECTED] MTU 1500
; (End DEVICE and LINK statements)
;
----------------------------------------------------------------------
;
----------------------------------------------------------------------
HOME
192.168.194.4 255.255.255.000 QDIO1
; (End HOME Address information)
;
----------------------------------------------------------------------
GATEWAY
; Network Subnet First Link MTU
; Address Mask Hop Name Size
; ------------- --------------- --------------- ---------------- -----
205.235.227 255.255.255.0 = QDIO1 1500
DEFAULTNET 205.235.227.41 QDIO1 1500
; (End GATEWAY Static Routing information)
;
----------------------------------------------------------------------
START [EMAIL PROTECTED]
; (End START statements)
;
----------------------------------------------------------------------
I thought that LPAR1, with the supernet, might be interferring with my
using part if it's network. So last night I took LPAR1 down and IPL'ed
z/VM 5.2 in LPAR1. I got the same problems.
I'm not using vswitch, but vswitch came up by default with addresses on
another port of the same card:
q osa
OSA 2016 ATTACHED TO TCPIP 2016 DEVTYPE OSA CHPID 11 OSD
OSA 2017 ATTACHED TO TCPIP 2017 DEVTYPE OSA CHPID 11 OSD
OSA 2018 ATTACHED TO TCPIP 2018 DEVTYPE OSA CHPID 11 OSD
OSA 2200 ATTACHED TO DTCVSW1 2200 DEVTYPE OSA CHPID 31 OSD
OSA 2201 ATTACHED TO DTCVSW1 2201 DEVTYPE OSA CHPID 31 OSD
OSA 2202 ATTACHED TO DTCVSW1 2202 DEVTYPE OSA CHPID 31 OSD
So, in all of this, my attempt was, that the VMTEST machine, wasn't
going to depend of any 1st level VM services, such as connecting to the
first level vswitch. I wanted to be in a position that when I'm ready
to go live with z/VM 5.2, I just IPL that system in the LPAR. We would
use a different set of OSA addresses, no problem. The object was to try
to as complete testing as possible while under 2nd level and have the
minimum number of changes when we go production.
Apparently the CONFIG file for z/VM 5.2 has sufficient number of
changes, that I can't just take the CONFIG file from the z/VM 5.1
system, and run it when we go production.
Most of my CONFIG file was generated by IPWIZARD, but IPWIZARD couldn't
handle a supernet. It has been problem reported. But it never produced
a good CONFIG file that worked. Which means this problem might not be a
TCPIP problem, but rather a CP problem? A hardware problem? A network
problem?
I'm out of things to try.
Thanks
Tom Duerbusch
THD Consulting
