|
Posted by Moe Trin on February 23, 2008, 11:27 am
If you were Registered and logged in, you could reply and use other advanced thread options
On Sat, 23 Feb 2008, in the Usenet newsgroup comp.security.firewalls, in article
cn.wangxuejun@gmail.com wrote:
>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.
'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.
>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.
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.
>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.
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.
>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!
Find out why the "other" host is attempting to connect to a server
that doesn't exist.
Old guy
| 
XML site map