Large number of TCP RST

Question

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:

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.