Discovered today that clock drift in an LTM-VE can cause all kinds of nastiness...
TCPDUMPS:
LTM and Server:
11:41:49.990078 IP LTM-SELF-IP.63495 > LB-HOST-IP.http: . 1:1461(1460) ack 1 win 4380
11:41:49.990093 IP LTM-SELF-IP.63495 > LB-HOST-IP.http: P 1461:1924(463) ack 1 win 4380
11:41:50.001701 IP LB-HOST-IP.http > LTM-SELF-IP.63495: . ack 1461 win 2190
11:41:50.001753 IP LB-HOST-IP.http > LTM-SELF-IP.63495: . ack 1924 win 2920
11:40:57.553309 IP LTM-SELF-IP.63495 > LB-HOST-IP.http: R 1924:1924(0) ack 1 win 4380
LTM and Workstation:
11:41:49.980407 IP CLIENT-IP.63495 > LTM-VIRTUAL-SVR.https: P 1603:2211(608) ack 127 win 16600
11:41:50.081404 IP LTM-VIRTUAL-SVR.https > CLIENT-IP.63495: . ack 2211 win 6368
11:40:57.553236 IP LTM-VIRTUAL-SVR.https > CLIENT-IP.63495: R 127:127(0) ack 2211 win 6368
Check out the time stamp. Evidently NTP was correcting the drifty system time around then, and presumably causing the LTM-VE to send out a connection reset to server and client. Note to self: SSL is NOT time-travel compatible.
Unset the NTP client settings in the LTM-VE and the issue hasn't happened again.
If you wish to be the best man, you must suffer the bitterest of the bitter.
Posted by: moncler shop | October 22, 2011 at 04:45 AM