Timeout on request to F5 pool

Plumtree: it's a little bit hard to ferret this out from the information here, but on the surface it sounds like you may be running into PAWS dropped SYNS (see RFC 1323), which exhibit the same behavior and are really hard to track down. SNAT scenarios are exactly where you'd run into them too. If you all are still running into this and you've got a capture, hit my inbox and we'll take this off forum.

 

 

The basic idea here is that you've got the same 4-tuple (src_ip:src_port, dst_ip:dst_port) being used for these flows, but the timestamp slid backwards. The stack expects the TS option to always increase, "monotonically", in RFC speak, over the course of a flow. If it sees the same 4-tuple with a timestamp in the past it'll do a silent discard and show the same behavior. Here's a quote from the RFC:

 

 

"The basic idea is that a segment can be discarded as an old duplicate if it is received with a timestamp SEG.TSval less than some timestamp recently received on this connection."

 

 

And that discard is the killer, because it's silent and you'll see bizarro stalls that last for minutes. One way to rule this in or out is define specific SNAT addresses for the hosts having the problem and see if it goes away.

 

 

PS: I suspect that this PAWS problem can be worse in VMware environments because clock skew is so common. It'll affect those timestamps and potentially increase the chances you'll hit this with automap snats.

 

 

--Matt