On 14th June Vic Cross wrote

> Paul, did you get this working?  If not, a suggestion or three inline...

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 think my difficulty may have been that most documentation I was reading
was implying that Linux had to operate as a subnet and by implication there
is a router in the configuration. We do not have a router and presently have
no requirement to operate subnets. However, taking these assumptions to be
truisms I was coding appropriate VM TCPIP gateway statements thinking these
would operate as a 'software' router (IP forwarding is enabled in the VM
TCPIP stack).

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 anyone would care to shed light on my (mis)understanding I would
appreciate it.

Thanks for all your help up to this point.

Paul

On Thu, 10 Jun 2004, Paul Burke wrote:

> Configuring my first Linux under S/390 and cannot get Linux to
> communicate with the network. Following is a brief overview of the
> environment.
>
> We run a class C network 192.168.168. with a subnet mask of
> 255.255.255.128. Existing network runs on low order, Linux network
> runs on the high order. Connectivity between the network to z/VM on a
> Multiprise 3000 H30 is provided by a Bustech MAN device owned by VM
> TCP/IP.

I'm not familiar with this guy...  If it's a 'smart' device like an OSA
-- if you can call any OSA smart ;) -- it might need some configuration to
know that there are addresses behind the VM IP stack.  On an OSA we'd be
talking about PRIROUTER or manipulation of the OAT...

> 192.168.168.20 is the VM stack
> 192.168.168.129 is the Linux stack
> 192.168.168.35 is a PC on the network
>
> >From a Z/VM CMS virtual machine I can ping all resources. From Linux,
> >I can ping VM but not the PC. From the PC, I can ping VM but not
> >Linux.

<some snippage>
>
> netstat gate
>
> VM TCP/IP Netstat Level 420
>
> Known gateways:
>
> NetAddress      FirstHop   Flgs PktSz Subnet Mask  Subnet Value  Link
> ----------      --------   ---- ----- -----------  ------------  ------
> 192.168.168.0   <direct>   US   1500  0.0.0.128    0.0.0.0       VMLINK
> 192.168.168.129 <direct>   UHS  1500  HOST                       LINUX1V
> Ready; T=0.02/0.03 10:50:49

You don't appear to have a default gateway in z/VM TCPIP -- not critical for
this, perhaps, as you have specific routes for the networks you need, but if
Linux needs to get to other places (the Internet for example) you will need
to set this up using a DEFAULTNET in your GATEWAY statement.

> Linux (192.168.168.129 - Debian distribution)
>
> route
>
> Kernel IP routing table
> Destination     Gateway        Genmask         Flags Metric Ref Use Iface
> 192.168.168.20  *              255.255.255.255 UH    0      0   0   ctc0
> 192.168.168.129 *              255.255.255.255 UH    0      0   0   ctc0
> 127.0.0.0       *              255.0.0.0       U     0      0   0   lo
> default         192.168.168.20 0.0.0.0         UG    0      0   0   ctc0

This looks okay.

> ping -c 1 192.168.168.129
<snip working>
> ping -c 1 192.168.168.20
<snip working>
> ping -c 1 192.168.168.35
<snip not working>

Definitely somebody's not routing...

> PC (192.168.168.35)
>
> C:\>ipconfig /all
>
> Ethernet adapter Local Area Connection:
>
>         Connection-specific DNS Suffix  . :
>         Description . . . . . . . . . . . : 3Com 3C920 Integrated Fast
> Ethernet Controller (3C905C-TX Compatible)
>         Physical Address. . . . . . . . . : 00-06-5B-12-99-19
>         DHCP Enabled. . . . . . . . . . . : No
>         IP Address. . . . . . . . . . . . : 192.168.168.35
>         Subnet Mask . . . . . . . . . . . : 255.255.255.128
>         Default Gateway . . . . . . . . . : 192.168.168.1
>         DNS Servers . . . . . . . . . . . : 154.15.243.2
>                                             154.15.244.2
>         Primary WINS Server . . . . . . . : 192.168.168.3
>
> C:\>route print
> ======================================================================
> =====
> Interface List
> 0x1 ........................... MS TCP Loopback interface
> 0x1000003 ...00 06 5b 12 99 19 ...... 3Com EtherLink PCI
>
===========================================================================
>
===========================================================================
> Active Routes:
> Network Destination        Netmask          Gateway       Interface
Metric
>           0.0.0.0          0.0.0.0    192.168.168.1  192.168.168.35
1
>         127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1
1
>     192.168.168.0  255.255.255.128   192.168.168.35  192.168.168.35
1
>    192.168.168.35  255.255.255.255        127.0.0.1       127.0.0.1
1
>   192.168.168.128  255.255.255.128   192.168.168.20  192.168.168.35
1
>   192.168.168.255  255.255.255.255   192.168.168.35  192.168.168.35
1
>         224.0.0.0        224.0.0.0   192.168.168.35  192.168.168.35
1
>   255.255.255.255  255.255.255.255   192.168.168.35  192.168.168.35
1
> Default Gateway:     192.168.168.1
>
===========================================================================
> Persistent Routes:
>   None

Right.  This lot tells me that the Windows machine is okay too.  You have
the correct subnet mask on the Ethernet, and an appropriate route to direct
the 192.168.168.128 network to the VM IP stack (so, changing the default
router at 192.168.168.1 to add this might help other machines, but not this
one in this case).

Also, Proxy ARP will not assist either, because the Linux guest is not in
the 192.168.168.0/25 network that the Ethernet is configured for (this
network stops at .127 - the broadcast address - and the Linux guest is at
.129).

My suggestions: double-check that there is no firewall product on the PC, or
a firewall configuration on the Linux guest, that is stopping the traffic
flowing.  If that's clear, check that IP forwarding is enabled in the VM IP
stack (ASSORTEDPARMS NOFWD must not appear in PROFILE TCPIP, and you should
see "IP forwarding is enabled" in the TCPIP service machine's spool output).

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



This e-mail, and any attachment, is confidential. If you have received it in
error, please delete it from your system, do not use or disclose the
information in any way, and notify the sender immediately. The contents of
this message may contain personal views which are not the views of Adare
Intellidata Limited. Any representations or commitments expressed in this
email are subject to contract and confirmation in writing.

----------------------------------------------------------------------
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

Reply via email to