On Wed, 16 Jun 2004, Paul Burke wrote: > I got it working but not in the manner I would have preferred. The MAN > device connecting to the M3000 H30 operates as a Lan Channel Station with > multiple virtual channels/connections. So I configured the Linux machine to > be a part of the same subnet and gave it ownership of a virtual > channel/connection. The benefit here is that I now know I have a working > linux instance and am not wondering whether Linux, VM TCPIP, gateway > statements, PC routing statements or the price of fish in Bratislava is the > problem!
I know, I have trouble keeping up with the fish market as well ;) You will obviously have limited numbers of "virtual channels" that you can assign to Linux guests, so depending on how many guests you want to run you may strike a problem with this method. While VM TCPIP (or a Linux guest) can provide the "software router" function that you spoke of, there is no real necessity to do this if your environment is simple enough. One alternative (which another poster previously mentioned) is Proxy ARP, which (basically) makes the Linux guest appear as if it is in your Ethernet segment so no routing is needed to reach it behind the VM TCPIP stack. Note, however, that Proxy ARP only works for guests at the end of CTC or IUCV links, so if you have a z/VM Guest LAN in your future you need to consider the "software router" approach now. To switch to Proxy ARP, return your VM TCPIP and Linux guest to the previous CTC configuration, add the ASSORTEDPARMS PROXYARP statement to your TCPIP PROFILE, and change the IP address of the Linux end of the CTC to an address that is within the 192.168.168.0/25 subnet of your Ethernet (you could use the IP address that you've given the Linux guest now for using the MAN). As I said, if you are looking at the possibility of using z/VM Guest LAN (either the so-called QDIO or the virtual HiperSockets) you will need to look at routing. You would set up your Guest LAN using the 192.168.168.128/25 subnet range you're already using, or you could get adventurous and break that range further into /26 or /27 subnets which would allow you to use multiple Guest LANs for different purposes. Hopefully this helps a little toward the "to-route-or-not-to-route" question, but I think Carlos hit the answer on the original connectivity problem. In my previous note I mentioned that there was work you would need to do if you had an OSA, and it seems like the Bustech box has a similar 'restriction'. These devices employ a "pre-routing" function. For packets that arrive on the LAN interface, they need to know which connection (LPAR, guest, etc) to send each packet to. The decision is made using the packet's destination IP address. The device keeps a table which maps IP destination to connection, and any packets for unknown destinations are trenched (the OSA has a 'wildcard entry', which I mention later). So, your device needs to know about any IP addresses that live either in *or past* the VM TCPIP stack in order for it to send the packet to VM TCPIP for forwarding. This is required regardless of whether you use Proxy ARP or software routing. > Whilst not a real requirement as yet I would like to have the option of > operating VM TCPIP as a gateway to Linux instances. If the Bustech box has an equivalent to the OSA's "primary router" function -- this is the 'wildcard entry'; nominate one connection that receives traffic for any IP address that I otherwise don't know how to handle -- I'd suggest setting that for your VM TCPIP connection. This will mean that any traffic arriving at the Bustech for which there is no specific address entry will be sent to VM TCPIP. The alternative is to have to make a config change to this box every time you add a Linux guest OR define the entire subnet of Linux addresses in advance; the latter was not possible with the OSA-2, because the OAT had a (quite small) limit on the number of addresses that could be defined there. Hoping this helps! Cheers, Vic Cross ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
