nettl Gyrations to confirm TCP Frozen Windows Issue?

[Alzhy]

Does anyone have a "recipe" to make use of nettl to capture logs to prove/disprove allegations that sniffers are seeing TCP Frozen Windows?

Our infrastructure consists of Windows 2000 Servers acting as App/Web servers running WebLogic and a large back end HP-UX machine running a Oracle DB and core apps. There've been an uptick in disconnects and failed restarts (of agents) between the windows servers and our UNIX machine. A sniffer was brought into the picture and initial analysis point to the UNIX as the culprit saying there are a lot of frozen windows in transactions coming from Windows to the UNIX server and back. We've not been provided with specific details of the sniffer runs.

Our UNIX box runs APA in failover mode.

Are there any nettl logging that can be called upon to check if this is indeed the case and to monitor the health of our network subsystem on the UNIX side?

Thanks.

[Steven E. Protter]

I think you may be better off using tcpdump or ethereal to collect the data.

Then you will have data, which you can compare to the sniffer data.

You're going to need to see the data. If Windows 2000 and HP-UX networking have been set up properly and there is no conflicting IP addresses I can see no reason(blind as I am here) for HP-UX/Unix to cause this problem.

A far more likely cause of trouble is the collision domain being too large, ie too many machines in the same subnet. Windows machines tend to cause congestion.

I have seen if you were running a heavy end user applicaion with java on your HP-UX machine(using it like a workstation) there congestion can be caused but not freezing.

Windows is far more often the culprit in these situations.

The bottom line is you need to sit down and compare any data you collect with the sniffer people's data.

SEP

[rick jones]

I'll second the suggestion to use tcpdump or ethereal. Either can be installed from the HP Internet Express bundles from software.hp.com.

"TCP Frozen Windows" sounds like the assertion is the Windows system isn't getting window updates from the back-end or something? Odd that someone out there would feel compelled to give it a name :)

You might also check the TCP statistics and the lanadmin statistics on the UX system. Best if taken over an interval and then "diffed" as it were - beforeafter from ftp.cup.hp.com dist/networking/tools/ can subtract one file of netstat (or lanadmin) statistics from another to give the deltas.

Of course, the usual song and dance about being up on the latest patches (on both ends) likely applies :)

[Jeff Schussele]

And I'd add that it always much better to run nettl or ethereal on another very lightly loaded server in the subnet. Sometimes they just can't capture all the data you may need if it's also receiving the same traffic. It just can't keep up on a busy subnet.

My 2 cents,
Jeff

[rick jones]

If you do run tcpdump or ethereal (does nettl do promiscuous mode?) on another system, and you have a _switched_ network, you will need to designate the port on your sniffing system as a monitor port so it will see the traffic you want it to see. That, or interpose a hub (a _real_ hub, not some badly named oxymoronic "switching hub").

I suspect Nelson or his networking people already knows about that since they are using sniffers, but just so the other folks reading know...

[Alzhy]

Just finished studying nettl and usage of filters so I can do logging on the specific ports the apps use. I was hoping someone already had automated scripts to do this.

Our Fluke/sniffer folks do seem to kow whatthey're talking so whatever logs I will get I'll hand over to them. Learning opportunity as well.

I will also be looking at Ethereal - the tool of choice espoused by the lecturer during one of HP World 2004's Networking sessions.