Right...eventually, I was going to have all the VSE systems as well as
the TCPIP machine, attach directly to the Guest LAN that the Vswitch is
on.
However, I was trying to do "baby steps". Something I could easily
back out of. Also, I'm not sure of OSA support with TCP/IP 1.5 B
running on VSE/ESA 2.3.2. My older machines use so little IP, that I
was going to leave them VCTCA to TCPIP until they die.
Origionally I had:
OSA > TCPIP > NEWESA4 > DOSESA2
which worked fine.
Then:
OSA > Vswitch/Guest LAN > TCPIP > NEWESA4 > DOSESA2
didn't work, but only for DOSESA2. It seems Vswitch/Guest LAN could do
2 hops to NEWESA4 but not the third hop to DOSESA2. If Guest LAN
required nodes to be directly connected, then why does NEWESA4 work just
fine?
Of course I agree that nodes should be directly connected. That is one
of the purposes of Guest LANs is to reduce complexity and eliminate
routing overhead, but....baby steps...
And yep, I might have to take bigger steps. In this case:
OSA > Vswitch/Guest LANs > TCPIP > NEWESA4
DOSESA2
etc.
Tom Duerbusch
THD Consulting
>>> Hans Rempel <[EMAIL PROTECTED]> 11/15/05 12:26 PM >>>
Hi Tom. Alan can answer this much better than I can but I'll give it a
try. In the first diagram you have VM TCP/IP controlling the OSA card
and you have routing information in there to get access to the lower set
of guests.
In the second situation you have the VSWITCH controlling the OSA card
and VSWITCH is just a switch - no routing. Your diagram is not quite
right since VM TCP/IP should be on the same line as NEWESA4. Your
Newesa4 and STLESA2 are all part of the local subnet as is NEWESA4. The
others are not (physically/virtually) on the same segment. Moving
testesa4 to the VSWITCH solved your problem for that reason.
Hope that makes since.
Hans
-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Duerbusch
Sent: November 14, 2005 2:36 PM
To: [email protected]
Subject: vswitch routing problem?
Prior to bring up vswitch, my network had routes such as:
|
|
OSA
|
|
vm TCP/IP
|
_____________________
| |
(NEWESA4 VSE) (STLESA2 VSE)
|
____________________________
| | | |
| | | |
DOSESA2 GEAC4 TSTESA4 TSTESA2
VSE VSE VSE VSE
The first phase of bringing up Vswitch, is just to have it control the
hardware. So the network now looks like:
|
|
OSA
|
|
Vswitch
|
|
vm TCP/IP
|
________________________
| |
(NEWESA4 VSE) (STLESA2 VSE)
|
____________________________
| | | |
| | | |
DOSESA2 GEAC4 TSTESA4 TSTESA2
VSE VSE VSE VSE
At this point, vswitch has the OSA hardware, and only has a single
node
on it's guest lan (TCPIP, the VM stack).
All seemed to be fine. except....
No one on the LAN can get to the DOSESA2, GEAC4, etc machines. But
they can get to the STLESA2 machine. So, I took the TSTESA4 machine
and
connected directly to TCPIP, instead of being routed thru the NEWESA4
machine. And now it works.
It seems to be a routing problem, but I don't understand why.
If a LAN user can be routed as:
LAN > TCPIP > NEWESA4 > TSTESA4
what difference is there when Vswitch in put in the mix as:
LAN > Vswitch > TCPIP > NEWESA4 > TSTESA4
As NEWESA4 is directly connected to TCPIP, no one has problems
connecting to it.
I would like to be able to understand just what "networking" changes
went into effect with the addition of vswitch.
I can ping from TCPIP to all the machines, which means I have active
connections. It is only when I added vswitch to the mix, that
machines
that were 2 hops over from TCPIP, had problems communicating.
Thanks for any insight.
Tom Duerbusch
THD Consulting
[This E-mail scanned for viruses]
________________________________________________________________
Sent via the WebMail system at hmrconsultants.com
[This E-mail scanned for viruses]
