Please help verify this strange packet loss problem

recently company network experienced packet loss problem when pinging external websites, 10% packet loss rate. Now I'm sure it's due to internal access behavior after lots of tests. but I just could not find out why and how. I had done some sniffer works by Ethereal. It seemed there were too many TCP packets which flag were set to RST, when these packets appeared, the delay to external website increased, sometimes packet loss happened. The destination port of these TCP packets with RST flag was 80(http) and all these packets were sent from our internal users' WIN XP system.

I could not tell if it's these TCP packets with RST that caused packet loss and delay jitter. Here I hope someone would show me lights on such problem and if only there is a solution.Thanks in advance!

'ping' is a different service (ICMP types 8/0) from the normally used TCP, and may be treated differently (lower priority) as it's rarely carrying "useful" data. I'd be more concerned with TCP packet loss which would show up as retransmission requests.

RST is the TCP flag that says "I do not want to talk to you", so you may be seeing some Denial Of Service attack.

Not enough information. What is _causing_ these RST packets? For example, here is a tcpdump that occurs when I try to connect to a web server on this system - but it's not running a web server.

09:10:48.80 192.168.10.54.9562 > 192.168.10.31.80: S 1130717347:1130717347(0) win 512 09:10:48.96 192.168.10.31.80 > 192.168.10.54.9562: R 0:0(0) ack 1130717348 win 0

In the first line, 192.168.10.54 sends a SYN packet from it's port 9562 to 192.168.10.31 port 80. Because 192.168.10.31 is not running a web server, it sends back a RST packet, telling 192.168.10.54 to go away. Note that the port numbers (shown here as the 5th number of the IP address) match up, and that 192.168.10.31 is acknowledging the 32 bit sequence number one count beyond (1130717348) that sent by 192.168.10.54 (1130717347). The source of the problem here is 192.168.10.54 trying to connect to 192.168.10.31 - the RST packet is the result of this.

Find out why the "other" host is attempting to connect to a server that doesn't exist.

Old guy