Thanks Tracy. I did find a webpage from Paul Giordano talking about tracing
VSWITCH but ran into problem/time with IPFORMAT exec. I used sample ETC
and Config files from IBM.
ipformat debug file a
228 +++
40 +++
DMSRTL2103E Error in compiled CMS system Rexx file; additional information:
4100
41 IPFORMAT EXEC 228
Ready(20041); T=0.27/0.27 17:50:09
Allan. Thanks for your comments. Nothing has changed or broke in production.
We are trying to setup a test environment with new TCPIP stack and network
server with new software. I would like to prove that the VSWITCH and OSA are
not the problem because I use the same VSWITCH and OSA in the production
TCPIP stack. The traces seem to show that data is heading onto the VSWITCH.
Why the network folks don't see it is a mystery to me.
I have a few tests planned for Thursday morning which I hope will shed more
light on the situation.
Hans
_____
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Tracy J Adams
Sent: April 10, 2007 2:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Tracing VSWITCH - SAG broker problem
For more information on using the 'SNIFFER' support added in z/VM 5.2.0,
please see the Troubleshooting a Virtual Switch or Guest LAN section of the
z/VM Connectivity Guide.
Tracy (Bolinda) Adams
[EMAIL PROTECTED]
z/VM Development - Virtual Networking
Alan Altmark/Endicott/[EMAIL PROTECTED]
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
04/10/2007 02:04 PM
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Tracing VSWITCH - SAG broker problem
On Tuesday, 04/10/2007 at 12:39 AST, Hans Rempel <[EMAIL PROTECTED]>
wrote:
> Hi all. Sorry for the lengthy post.
>
> I have a problem trying to get SAG broker in VSE to talk to SAG broker
on a
> windows platform. For legacy reasons we wish to keep the environment the
same
> so there is NO VSE TCPIP stack involved. This does make it more
complicated but
> that is how it has/is been running in production for 4 years.
If it has been working, what changed?
> 1) Is there some documentation/tools on reading QDIO traces to I can
> analyze this captured trace?
No. To get that level of help you need to open a PMR.
> 2) Is there a trace I can setup to trace traffic leaving the VSWITCH
to
> the OSA card or trace certain channels (ports) on the OSA card?
Currently one
> LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is
monitored by
> DTCVSW1 userid.
You can trace the *VSWITCH* by putting a Linux guest on the VSWITCH with
sniffer (promiscuous mode) authority and gather a TCPDUMP. You'll see all
the traffic on *that* VSWITCH. Tracing the traffic leaving the OSA itself
is done exactly as your network guys are doing - with sniffers.
Beware that OSA port sharing enables the OSA to "short cut" the packets if
it recognizes the destination MAC or IP address as belonging to the OSA.
And you know how I am about providing pictures, IP addys, and subnet
masks. I can't tell if the various hosts are [supposed to be] in the same
subnet or not. I get sleepy when I read ankle-bone-leg-bone-hip-bone
configuration descriptions, particularly where shared OSAs come into play.
:-D
Alan Altmark
z/VM Development
IBM Endicott
