Please help verify this strange packet loss problem

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
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!

Re: Please help verify this strange packet loss problem
On Sat, 23 Feb 2008, in the Usenet newsgroup comp.security.firewalls, in article
cn.wangxuejun@gmail.com wrote:

Quoted text here. Click to load it

'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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 <mss 3544>
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.

Quoted text here. Click to load it

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

        Old guy

Site Timeline