Hi, Hans,

You should check out APAR PK25362 for IPFORMAT.   I believe that should 
help with your error situation.  Good luck. 

Tracy (Bolinda) Adams
[EMAIL PROTECTED]
z/VM Development - Virtual Networking





Hans Rempel <[EMAIL PROTECTED]> 
Sent by: The IBM z/VM Operating System <[email protected]>
04/10/2007 07:17 PM
Please respond to
[EMAIL PROTECTED]


To
[email protected]
cc

Subject
Re: Tracing VSWITCH - SAG broker problem






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: [email protected]
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 <[email protected]> 
04/10/2007 02:04 PM 


Please respond to
The IBM z/VM Operating System <[email protected]>



To
[email protected] 
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

Reply via email to