Doesn't fix app problems, but have you looked at TCP offload/chimney/RSS options, and maybe disabled them?
-Bonnie From: Steve Ens [mailto:[email protected]] Sent: Thursday, May 17, 2012 10:42 AM To: NT System Admin Issues Subject: Re: TCP/IP stack reset Yah, that is what I'm trying to explain to him....At this point, I've got six staff that rely on this application and they generate logs that tell our automation what to playout to air...so...I have to do my due diligence and eliminate any issues I can find before I can point finger(s). On Thu, May 17, 2012 at 12:34 PM, Michael B. Smith <[email protected]<mailto:[email protected]>> wrote: Sounds like a poorly implemented solution. From: Steve Ens [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, May 17, 2012 12:20 PM To: NT System Admin Issues Subject: Re: TCP/IP stack reset This was his reply... In windows there is only one TCP/IP stack even if a server (or workstation) has multiple NIC cards in it. Therefore the reset of ANY NIC card on a windows computer causes the TCP/IP stack on the computer to reset. The problem is that BroadView uses two communications methods. One, the newer one, does not care or is bothered by the stack resets. Unfortunately the other method, the older one, is based on DCOM (a Microsoft technology) which is sensitive to a TCP/IP stack reset. When a reset happens it effectively breaks that part of BroadView. Thus some parts of BroadView (like form operations) continue after a TCP/IP stack reset, but other parts are broken and can only be fixed by restarting BroadView and can cause the BroadView application server to outright crash. So, if the NIC on the server was going bad and kept resetting it would break BroadView. If the switch port that the server is connected to resets, it would cause the stack to reset and again break BroadView. If the cable between the server and the switch is failing it can cause the stack to reset and again, BroadView would break. On Thu, May 17, 2012 at 11:03 AM, Daniel Chenault <[email protected]<mailto:[email protected]>> wrote: If the stack is resetting than it is dropping all current connections. This would be evident in the trace by workstationA sending a packet to ServerA with a response of RST. Following that would be the standard 3-way TCP handshake. I question the robustness of an app that cannot gracefully handle a reset from another layer. I also question why the stack would be resetting frequently enough to be an issue. Resetting a specific connection, sure, but the whole stack? Dubious allegation. Check the trace. Daniel Chenault [email protected]<mailto:[email protected]> [cid:[email protected]] From: Steve Ens [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, May 17, 2012 10:55 AM To: NT System Admin Issues Subject: TCP/IP stack reset Morning/afternoon all... I have a particular application that is giving me headaches. It is client/server based app that is constantly crashing. The vendor is saying it is a network issue: that the network stack is resetting causing one of the services to crash. I've updates the NIC drivers, the HP team drivers and checked the switches and even changed the ports on the switch. I've install wireshark, but am having some difficulty interpreting the capture logs. Any ideas on what to look for would be greatly appreciated. Thanks ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
<<inline: image001.jpg>>
