On Jan 19, 2008 8:22 PM, Andrew Miehs <andrew@xxxxxxxxx> wrote: > What exactly was the three second delay? and what did F5 do to fix this? > > Thanks > > Andrew Sorry Andrew for the delay.. I believe I posted this when I first had the issue, but reposting so that it can be logged .42 = Squid .153 = apache web server "FROM F5" Looking through cache01-new, every instance of a 3 second delay that I find, I see where 10.13.200.42 sends the SYN, which is sent through the BIG-IP to 10.13.200.153. In each instance, I find that 10.13.200.153, rather than replying to the SYN with a SYN-ACK, simply sends an ACK. This, bing incorrect, gets a RST response from 10.13.200.42. After all, 10.13.200.42 was expecting SYN-ACK, not ACK. After a three second delay, 10.13.200.42 initiates the handshake again, and this time 10.13.200.153 sends the SYN-ACK response, which allows the handshake to carry on. I had iniitially thought that this was the fault of 10.13.200.42, but looking over the w04-new tcpdump, and matching up the delay packets, it's very clear that there is no SYN-ACK, resulting in this 3 second delay. As to why 10.13.200.153 would respond to a SYN with just an ACK, I believe that this may be due to a port reuse issue. The server believes that port to still be in use, while the BIG-IP believes it to be closed. To get around this, I would suggest the use of incrementing autoport, where the BIG-IP does not try to use the same ephemeral port that the client uses, but rather makes use of some other ephemeral port. To set this, from the command line issue the command: b internal use_incrementing_autoport 1 Which will enable this immediately, and does not require a reboot at all. ".. Again this fixed the 3 second delay but I still have a ton of connections sitting in Time_wait on the apache servers. I've tried to use a sysctl recycle option, but squid via the lb seems to have some issues with it (again I think it's in the LB) Tory
