Do keepalives / heartbeats use same TCP sequence numbers?

[deeze6]

Hello all,

I am analyzing sessions between two servers for which the sniffer is showing hundreds of Non-Responsive Station and Too Many Retransmissions alerts.

When I filter on any one of these TCP sessions, I see the retransmissions occur at constant intervals of 5.107 seconds even though all packets are aknowledged by both sides. Also the same sequence numbers are used in each packet.

Being that the retransmissions are at such a regular interval, this leads me to believe that these retransmissions are keepalives or heartbeats use to keep the session open.
But if that is the case, shouldn't the TCP sequence numbers increment?

Thank You

 

[JasonDeckard]

Five seconds is a rather short keep-alive interval. I believe the default interval is two hours on most operating systems (RFC 1122 says the default interval should be no less than 2 hours).

The purpose of a keep-alive packet is to ellicit a RST from the remote if the session is no longer valid. The remote may, but is not required to, respond to a keep-alive if the session is connected (the remote can ACK it or do nothing). That being said, a keep-alive isn't really intended to keep the session active - it is intended to test for "stale sockets" (where one host thinks the session is connected while the other believes it to be in some other state).

The sequence number may or may not increment with a keep-alive packet (it varies by OS).

 

[deeze6]

Thanks Jason for the fast reply. When I type netstat -s to show the TCP statistics on that Windows 2000 server, it shows the Segments Retransmitted counter incrementing by hundreds every minute. Do you think this number would increment from the keepalives being sent?

 

[JasonDeckard]

Nah - a segment is retransmitted if an ACK is not received in a certain amount of time (your time of ~5 seconds sounds appropriate for this). An ACK would not be sent to the remote if the CRC failed or if it did not receive the segment in the first place. It is possible the remote is sending the ACK, but it is getting lost on the way back.

I'm a little puzzled because you are seeing the ACKs both ways. Can you show us a a little bit of the log showing a packet being sent, acknowledged, and then resent? Thanks.

 

[deeze6]

Sorry, let me rephrase. Each server is getting the other servers' packets. I know this by placing a separate sniffer on each server's port and seeing the packets being sent and aknowledged at each end. It is ServerA that is always doing the retransmitting and ServerB always aknowledging. Here is the output from sniffer:

Frame Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary
1372 [ServerA] ServerB 60 00:00.0 0.000.000 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
1378 ServerB [ServerA] 60 00:00.0 0.000.441 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176
3607 [ServerA] ServerB 60 00:05.1 5.107.278 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
3609 ServerB [ServerA] 60 00:05.1 0.000.067 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176
5750 [ServerA] ServerB 60 00:10.2 5.107.640 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
5753 ServerB [ServerA] 60 00:10.2 0.000.054 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176
8194 [ServerA] ServerB 60 00:15.3 5.107.575 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
8196 ServerB [ServerA] 60 00:15.3 0.000.062 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176
10434 [ServerA] ServerB 60 00:20.4 5.119.972 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
10437 ServerB [ServerA] 60 00:20.4 0.000.010 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176
12710 [ServerA] ServerB 60 00:25.5 5.095.336 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
12712 ServerB [ServerA] 60 00:25.5 0.000.060 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176
14944 [ServerA] ServerB 60 00:30.6 5.107.704 8/14/2003 7:14 TCP: D=1164 S=1750 ACK=2054334128 SEQ=1500333749 LEN=1 WIN=57960
14946 ServerB [ServerA] 60 00:30.6 0.000.066 8/14/2003 7:14 TCP: D=1750 S=1164 ACK=1500333750 WIN=35176

Note the delta time is just over 5 seconds and the sequence numbers never change. Also there are dozens of these sessions going on at once, each causing retransmissions. Here is what my sniffer expert analysis window looks like:

8/14/2003 07:16:07.397 24s 382ms Too Many Retransmissions TCP: [ServerB] - [ServerA] Port 1164 - 1584
8/14/2003 07:16:07.242 <1ms Non-Responsive Station TCP: [ServerB] - [ServerA] Port 1164 - 1607
8/14/2003 07:16:07.241 <1ms Non-Responsive Station TCP: [ServerB] - [ServerA] Port 1164 - 1607
8/14/2003 07:16:07.216 49s 300ms Too Many Retransmissions TCP: [ServerB] - [ServerA] Port 1168 - 1774
8/14/2003 07:16:07.215 30s 103ms Too Many Retransmissions TCP: [ServerB] - [ServerA] Port 1168 - 1642
8/14/2003 07:16:07.141 <1ms Non-Responsive Station TCP: [ServerB] - [ServerA] Port 1164 - 1688

Hope this clarifies my question.
Thanks again!