IT Employment

Gary, Many thanks for the reply. Sadly the Windows event log doesn't time things quite so accurately as my packet sniffer! Yup - the write errors do occur in the same second, but there is an awful lot of other stuff goin on at the same time.
It's interesting what you say about "in HTTP environments". The number of RST packets is fairly evenly distributed through all types of protocols - however the majority is Kerberos. I think there is only one or two HTTP RST packets.
In my investigations this week, the evidence is pointing towards an issue with the firewall that sits between the client PCs and the servers. I have a feeling that is not coping with the quantity of traffic and complex routing that we make it carry out!
Gary - Many thanks again.

Let me know what your questions are. I deal with TCP primarily as it relates to or affects application performance, so may not have all the answers, but also have some additional resources (friends).

I'm trying to find a resource that will help explain acceptable and unacceptable levels of TCP "errors". Some of my monitoring software is showing a large number of TCP Slow ACK, TCP Reset Connection, etc... but none of them are actually listed as errors.

Also while looking at netdiag logs, I've only found one document that explains how to interpret network statistics, but I've not found anything that explains TCP, ICMP, and datagram errors.

Not sure how to ask spefically, but that's kind of what I'm looking for.

Hi Marv,
Just got back from a bit of a break so sorry for not getting back in here sooner.
This kind of thing does seem to be a really grey area that is buried in the brown stuff! Finding anything out is a real mission. I think I am surprised at how much many people don't actually know!!!
Luckily we had a consultant come in to look at some of the issues we were having. He reckoned that 20-30 RSTs over 4 hours is not a problem. Regarding my question about whether an RST is ACKed, he said it depends on whether an ACK is requested. Apparently in some applications the programmer may not write that bit in, so we get no ACK.
I don't know what anyone else thinks but I am begining to think that "if it's not broken, don't try to fix it"! So if your boxes that are generating TCP errors are not stressing themselves (CPU etc) and the network traffic is not overloaded (remember that a simple RST is going to be a tiny datagram), don't worry about it!
No, I don't like it either!!!!!