I'm suspecting you are trying to migrate from a topology using vCTC or IUCV, or you've used an example based on vCTC or IUCV as a model for your configuration.
In configurations such as these where point-to-point connections are used, it is possible for the IP addresses used at the VM end to be the same. This simplifies your addressing structure and reduces the number of IP addresses you need to use. If you replace the vCTC with HiperSockets, you can no longer use the same IP address for all the VM devices. All IP addresses, and network numbers that they attach to, must be unique (forgetting for the moment about Proxy ARP). Choose another network number for the HiperSockets guest LAN. This means that the HiperSockets network would use addresses from (for example) 192.168.2.x -- a different network from the network attached via the OSA. Your PCs out on the LAN would then be instructed to use the IP address of the OSA (192.168.1.50, in your example) to reach the 192.168.2.0/24 network (this would usually be done by router reconfiguration, either statically in all the netowrk routers or by using a dynamic routing protocol such as OSPF, but you could test your configuration from a single PC on the 192.168.1.0/24 subnet by just adding the route to the PC route table). On Mon, 24 Feb 2003, Alan Altmark wrote: > You will never be able to ping from your PC to linux03. Your config files > describe a network that looks like: > .------. > |router| > ---192.168.1 / 24 ----| |=== 192.168.1.120 === LINUX03 > | (VM) | > '......' > The problem is that the machines on the 192.168.1 subnet think that Which 192.168.1 subnet? ;-) > LINUX03 is on the same LAN segment. How do they know that LINUX03 is > "behind" 192.168.1.50? Unless you are going to explicitly tell those > machines that .120 is routed through .50, all attempts by those machines > to find (via ARP) .120 will fail. I suspect that it's not even getting that far. When LINUX03 tries to ping VM, VM will be trying to send the ICMP replies out the OSA, instead of to the HiperSockets. Regardless of the exact reason, the config as it stands can't work. > If you used a point-to-point link (IUCV, virtual CTC), then VM TCP/IP > could perform Proxy ARP functions to help you, but using a Guest LAN > prevents that. Ok, didn't realise that... So Proxy ARP is not usable at all in this configuration? Even to hide another network behind VM TCP/IP? Forget about Proxy ARP a bit longer, then... ;-) Cheers, Vic Cross
