> Of course this throws things off even more as on the z/VM 5.1 system, I
> only had the single HOME entry (for 205.235.227.74) and I had (working
> correctly) about 3 dozen other interfaces. Attached is the old config
> file for z/VM 5.1. I agree that I may have gotten away with things that
> now, the newer code won't let me. And that may be a great part of my
> confusion.
>
Looking at the config file, and the IFCONFIG output you've added, I see
what you're trying to do. If this *exact* same configuration worked on
z/VM 5.1, I'm not sure that we've *explicitly* changed anything to prevent
it from working now. That's not to say we haven't made changes that cause
it not to work because we very well may have. Note that you're really
running (or trying to run) with an invalid configuration, and this is why
it's important to have pictures of the network and a decent understanding
of what all of the information on your network picture corresponds to.
Below, I'll "draw" a basic diagram of what I understand your network to
look like based on what you've told us and explain why your configuration
doesn't make sense.
----------
| Linux |
| Guest |
----------
o - Linux Guest's IUCV interface (IP address: 192.168.99.227)
|
|
|
|
|
o - VM System's IUCV interface (IP address: ???)
----------
| VM |
| System |
----------
o - VM System's QDIO interface (IP address: 205.235.227.74)
|
|
|
|
-----------------------
| Outside Network |
-----------------------
So...based on this picture, 192.168.99.227 has no *real* direct connection
to 205.235.227.74. It may be possible (depending on how strict the IP
stack's implementation is) to trick this configuration into working. But
relying on such a trick to continue working in the future is probably not
a great idea. The only way to truly ensure connectivity is to assign an
IP address to the VM System's IUCV interface(s).
> 1. Do I need a HOME statement for each interface? It seems that on
> z/VM 5.2, if I don't have one, I can't connect to the adjecent host.
To really be a *valid* configuration, yes you do.
> 2. If I need a HOME statement for each interface, can the IP address
> for that interface be any unused IP address? One that is on the same
> class C network (such as 192.168.99.1xx for the 2xx hosts)? Or do I
> need to spread out the HOST addresses out so that a .252 subnet can
> address a unique network along with a single unique host (that is,
> instead of consequitive IP addresses for hosts, every 4th IP address)?
It depends. If you're running a dynamic router (MPRoute) on VM, you're
most likely going to have to resort to the .252 subnets (a good reason to
think about ditching the point to point links and start implementing guest
LANs). If you're not running a dynamic router, you can go with a less
drastic "trick" and, like you said, use 192.168.99.1xx IP address on your
VM system. If you do this, you should probably NOT put a subnet mask on
the HOME statement for the IUCV links. Since they aren't really on the
same subnet (physically), you don't want a subnet route for them. Simply
add the appropriate HOST routes to your GATEWAY statement.
> 3. Then on the GATEWAY side. What I got use to (or got away with) on
> z/VM 5.1, was the first parm being the IP address of the HOST I was
> going to. The manual says that this isn't an IP address, but rather as
> subnet address. Getting those confused is part of my mistake. But it
> worked. Why? Is this a case of the code being tighten? However, as I
> now reread the manual, the first parm is the IP address of the host that
> is on the destination network and HOST is used to specify a host entry.
> So I would seem that my GATEWAY entry:
> 192.168.099.227 HOST = LLINUX27 9216
> is correct.
>
Yes, this is correct. If you read further in the description of the first
operand the doc says: "Alternatively, ipv4_dest can be specified as the IP
address, in dotted-decimal form, of any host that is on the destination
network." Which is really what applies in this case.
Regards,
Miguel Delapaz
z/VM TCP/IP Development
