This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Large number of TCP RST

0

I'm seeing a large number of tcp rst and am not quite sure what is causing it. I would appreciate any help. Below is that capture.

No. Time Source Destination Protocol Length Info
2939 2013-03-15 15:40:40.304765 10.1.4.2 208.89.168.x TCP 60 50090 > Frame 2939: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
WTAP_ENCAP: 1
Arrival Time: Mar 15, 2013 15:40:40.304765000 Mountain Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1363383640.304765000 seconds
[Time delta from previous captured frame: 0.000012000 seconds]
[Time delta from previous displayed frame: 0.000012000 seconds]
[Time since reference or first frame: 0.282367000 seconds]
Frame Number: 2939
Frame Length: 60 bytes (480 bits)
Capture Length: 60 bytes (480 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP RST]
[Coloring Rule String: tcp.flags.reset eq 1]
Ethernet II, Src: Dell_0b:b3:6c (f0:4d:a2:0b:b3:6c), Dst: Dell_fd:78:06 (00:13:72:fd:78:06)
Destination: Dell_fd:78:06 (00:13:72:fd:78:06)
Address: Dell_fd:78:06 (00:13:72:fd:78:06)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Dell_0b:b3:6c (f0:4d:a2:0b:b3:6c)
Address: Dell_0b:b3:6c (f0:4d:a2:0b:b3:6c)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Padding: 000000000000
Internet Protocol Version 4, Src: 10.1.4.2 (10.1.4.2), Dst: 208.89.168.x (208.89.168.x)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 40
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (6)
Header checksum: 0x3a76 [correct]
[Good: True]
[Bad: False]
Source: 10.1.4.2 (10.1.4.2)
Destination: 208.89.168.x (208.89.168.x)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 50090 (50090), Dst Port: https (443), Seq: 608, Len: 0
Source port: 50090 (50090)
Destination port: https (443)
[Stream index: 49]
Sequence number: 608 (relative sequence number)
Header length: 20 bytes
Flags: 0x004 (RST)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...0 .... = Acknowledgment:

asked 19 Mar '13, 10:03

mp84057's gravatar image

mp84057
1113
accept rate: 0%

edited 19 Mar '13, 10:14

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850

I'm seeing a large number of tcp rst and am not quite sure what is causing it.

with only a single packet, it's hard to give any meaningful answer. You say a "large numver" of tcp reset. Here are some questions:

  • what exactly is a "large number"?
  • are those packets all from the same IP?
  • who sends the first reset? client or server?
(19 Mar '13, 13:55) Kurt Knochner ♦

One Answer:

1

With my little experience with load balancers i can think of these reasons for cause of RSTs

1)Max-connection limit reached on load balancer.

2)Real Server/Application is down.

3)May be 80 is handled by one load balancer and 443 by other load balancer breaking the session persistence which will trigger resets.

If My answer sounds vague so is the question.

Point is , please be informative with your question.The packet capture you provided won't help much in analyzing the situation(atleast for me).Please try to get the information from client side-Network Side and Server side traces for other experts to analyze.

answered 19 Mar '13, 10:33

krishnayeddula's gravatar image

krishnayeddula
629354148
accept rate: 6%

edited 19 Mar '13, 11:47

I also believe that it has something to do with our load balancer configuration. The following is the current setup of our load balancer:

Prod_Insecure 10.1.1.3 81 (Layer 4)
Prod_Redirect_To_Secure 10.1.1.3 80 (HTTP)(Layer 4)
Prod_Secure 10.1.1.3 443 Standard
Public_Insecure 10.1.1.4 81 (Layer 4)
Public_Redirect_To_Secure 10.1.1.4 80 (Layer 4)
Public_Secure 10.1.1.4 443 Standard

(19 Mar '13, 12:06) mp84057