It has taken me a while to recall why I havn't been using more than 1
HOME statement.
I did this many years ago and got the same result.
When I update the configuration to:
HOME
205.235.227.74 255.255.255.000 QDIO1
192.168.099.227 255.255.255.000 LLINUX27
192.168.099.024 255.255.255.000 LNEWESA4
192.168.099.010 255.255.255.000 LY2KESA2
; (End HOME Address information)
Everything comes up. I can ping from VM to each of the IP addresses,
fine, or so it seemed.
I can also ping from the network to all the devices, fine, or so it
seemed.
But when I FTP from the network to one of the VSE addresses, it is the
VM FTPSERVER that responds.
Also, I can't ping from VSE up to VM or the LAN side.
So with the old VM IP stack, I left out the home statements for the VSE
networks. And we have run like this, on the MP3000 and later on the
z/890. I do believe that the network folks have a hard route of the
192.168.99 network directed to/thru the 205.235.227.74 address. Perhaps
that is what made the prior, not exactly perfect, config file work.
So, I think I need a way to route the 192.168.99.24 traffic to the
LNEWESA4 link. So I have:
GATEWAY
; Network Subnet First Link MTU
; Address Mask Hop Name Size
; ------------- --------------- --------------- ---------------- -----
205.235.227 255.255.255.0 = QDIO1 1500
192.168.099.24 HOST = LNEWESA4 1500
192.168.099.10 HOST = LY2KESA2 1500
192.168.099.227 HOST = LLINUX27 1500
DEFAULTNET 205.235.227.41 QDIO1 1500
And the ifconfig -a for this link shows:
LNEWESA4 inet addr: 192.168.99.24 P-t-P: 192.168.99.24 mask:
255.255.255.255
UP BROADCAST MULTICAST POINTOPOINT MTU: 9216
vdev: 0922 type: CTC portnumber: 0
connects to: NEWESA4 0983
cpu: 0 forwarding: ENABLED
RX bytes: 920 TX bytes: 0
That looked good. However, a FTP from DOS to VSE, ends up in VM:
C:\>>ftp 192.168.99.24
Connected to 192.168.99.24.
220-FTPSERVE IBM VM Level 520 at STLMP11.STLOUISCITY.COM, 14:59:35 CST
MOND
07-01-15
220 Connection will close if idle for more than 5 minutes.
User (192.168.99.24:(none)):
Am I correct, in the belief that this is a routing issue?
Don't say that it is a network design issue. It grew on its own. OK I
did water it a little.
Thanks
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 1/14/2007 11:44 PM >>>
On Saturday, 01/13/2007 at 03:56 CST, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
> I'm in the mist of converting from z/VM 5.1 to z/VM 5.2 and having an
IP
> problem.
> Actually, I couldn't just take my ZVMV5R10 TCPIP statements and put
> them on the newer system. I had to rewrite many of them.
Eh? Other than a nag message that your profile is in the old format,
everything should have worked, subject to any tighter enforcement of
general network design priniciples in the 5.2 stack.
> HOME
>
> 205.235.227.74 255.255.255.000 QDIO1
>
> ; (End HOME Address information)
> With the VM startup, I got the same errors I've normally had. Of
> course, they may be more serious now.
>
> 15:03:21 DTCPAR123I LINE 231: NO IPV4 HOME ADDRESS FOR DEVICE
NEWESA4
> 15:03:21 DTCPDO069I ADDBSDINFO: NO IPV4 HOME ADDRESS FOR LINK
LNEWESA4
> 15:03:21 DTCPAR106I DEVICE:NEWESA4, TYPE:CTC
> 15:03:21 DTCPAR107I LINK: LNEWESA4, TYPE: CTC, NETWORK NUMBER: 0
> 15:03:21 DTCPDO076I 192.168.99.24 <DIRECT> LINK NAME:
LNEWESA4
I infer from those messages and your PROFILE that you are missing the
HOME
address for NEWESA4. Make sure it is in the VSE subnet, not the OSA
subnet. It is required that each link have a unique IP address. An
ifconfig -a will likely show the device as "down".
Alan Altmark
z/VM Development
IBM Endicott
