Do you have the console log from the startup...  check the  device
statement for the OSA.



             "Piotrowicz,
             Ronald J."
             <piotrowicz.ronal                                          To
             [EMAIL PROTECTED]>               [email protected]
             Sent by: Linux on                                          cc
             390 Port
             <[EMAIL PROTECTED]                                     Subject
             ist.edu>                  Re: Networking question after
                                       Saturday's upgrade attempt... With
                                       pictures
             01/04/2006 03:03
             PM


             Please respond to
             Linux on 390 Port
             <[EMAIL PROTECTED]
                 ist.edu>






Bob, why is the MTU size 1800?

> _____________________________________________
> From:            Nix, Robert P.
> Sent:            Tuesday, December 20, 2005 8:05 AM
> To:        Barber, Erik A.; Piotrowicz, Ronald J.; 'Linux on 390 Port'
> Subject:         Networking question after Saturday's upgrade attempt...
With pictures
>
>  << File: network1.jpg >>
>
> Attached is a picture of the three "states" of the zVM / zLinux network.
The bottom is a picture of the routing that is happening now and in the
past. The center is what we tried to get to on Saturday and couldn't get to
work, and the top is the way it will ultimately be routed.
>
> What happened Saturday was that we could talk between several zLinux
images, could talk from zLinux to zVM, and could talk to zVM from outside
the router. But we couldn't talk from the zLinux images to the outside or
from the outside to the zLinux images.
>
> Below is the device and routing portion of zVM's TCPIP definitions:
>
> DEVICE [EMAIL PROTECTED]  OSD 8100  PRIROUTER
> LINK MFLINUX1 QDIOETHERNET [EMAIL PROTECTED]  MTU 1800
>
> DEVICE HIPR1 HIPERS 1D00 PORTNAME GRIZZLY AUTORESTART
> LINK HIP1 QDIOIP HIPR1
>
> DEVICE TUX18 CTC F180
> LINK TU18 CTC 0 TUX18
>
> DEVICE TUX24 IUCV 0 0 TUX24 A
> LINK TU24 IUCV 0 TUX24
>
> ; (End DEVICE and LINK statements)
> ; ----------------------------------------------------------------------
> ; ----------------------------------------------------------------------
> HOME
> 129.176.250.8   MFLINUX1
> 192.168.37.100  HIP1
> ; (End HOME Address information)
> ; ----------------------------------------------------------------------
> GATEWAY
> ; Network       First           Link             MTU   Subnet
Subnet
> ; Address       Hop             Name             Size  Mask
Value
> ; ------------- --------------- ---------------- ----- ---------------
---------------
> 192.168.37.18   =               TU18             1500  HOST
> 192.168.37.24   =               TU24             1500  HOST
> 192.168.0.0     =               HIP1             1500  0.0.255.0
0.0.37.0
> 129.176.0.0     =               MFLINUX1         1800  0.0.254.0
0.0.248.0
> DEFAULTNET      129.176.248.1   MFLINUX1         1800  0
> ; (End GATEWAY Static Routing information)
> ; ----------------------------------------------------------------------
> START [EMAIL PROTECTED]
> START HIPER1
> START TUX18
> START TUX24
> ; (End START statements)
> ; ----------------------------------------------------------------------
>
> IBM's idea of netmasks is a bit squirreled, but my interpretation is that
anything in the 192.168.37 network (except 18 and 24) should be able to
talk to anyone else in the network directly, and that anything in the
129.176.248-250 network should be able to talk to anyone else directly.
Anything that VM sees that it can't directly route should go to
129.176.248.1. The default route for the Linux guests go to 192.168.37.100,
so it should flow through here to VM's default route to get to the outside
world.
>
> I've specified "Primary router" on the definition for the VSwitch
connection ([EMAIL PROTECTED]) This definition, through the "magic" of VM and
virtual devices, points eventually to real device 8200. Everything was put
together when I thought I was going to end up on 8100, and it was easier to
"fake" it with the virtual address than to go back and change all the
places it was specified.
>
> The actual VSwitch definition in the system config is as follows:
>
>  GRIZZLY:  Define VSWITCH VSWG rdev 8200 IP prirouter portname OSAHAL2
>
> I'm not sure how much more I know about the problem> ...>  Is there a
static route somewhere that would keep the 192.168.37 IP addresses from
routing through the new VM 129.176.250.8 IP address? Do I have my routing
horked in some way? In either case, what do I need to do to fix the
problem?
>
> Help from any quarter will be deeply appreciated...
>
> --
> Robert P. Nix>                     Mayo Foundation
> RO-OC-1-13 (new loc)         200 First Street SW
> 507-284-0844                       Rochester, MN 55905
> -----
> "In theory, theory and practice are the same, but
>  in practice, theory and practice are different."
>

----------------------------------------------------------------------
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 message and its attachments may contain  privileged and
confidential information.  If you are not the intended recipient(s),
you are prohibited from printing, forwarding, saving or copying this
email.  If you have received this e-mail in error, please immediately
notify the sender and delete this e-mail and its attachments from your
computer.

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