According to RFC 793, which specifies an Option in the Flags portion of the TCP header called Reset (or RST). The Reset bit is designed to allow a station to abort the TCP connection with another station. This can happen for a number of reasons.
If a station involved in a TCP session notices that it is not receiving acknowledgements for anything it sends, the connection is now unsynchronized, and the station should send a reset. This is a half-open connection where only one side is involved in the TCP session. This cannot work by definition of the protocol.
Protocol Expert can track the number of TCP RST frames.
TCP RST Packets is a counter of all TCP RST Packets over a period of time per segment. This variable counts the number of RST responses to monitor resets in TCP/IP. A count of all TCP RST packets displays in the Overview counters of Expert View. A threshold for this counter can be set in Expert Alarms.
RST packets are a sign that the TCP connections are half open. One station or the other stopped sending information or ACKs for some reason. There are acceptable times for RST packets, however, if there are a large number of RST packets in a conversation, this is definitely something to troubleshoot. Which side is sending the RST? What is causing it to send the RST? Does this happen right away in the TCP setup, or is it later in the session? If later, is there any reason that the station would abort the session in the middle of the data transfer?
For more information about TCP RST Packets, see RFC 793 at www.rfc-editor.org.
|