Hold Connection / No Pool

Interesting. I don't expect that on a standard virtual server. Below I do a telnet to my virtual server (a standard HTTP virtual server on port 80). The source IP is 10.100.100.1 and dest is 10.100.100:80

 

 

10:34:42.137449 IP 10.100.100.1.4770 > 10.100.100.80.http: S 3192099991:3192099991(0) win 65535

 

10:34:42.137839 IP 10.100.100.80.http > 10.100.100.1.4770: S 3328880791:3328880791(0) ack 3192099992 win 4380

 

10:34:42.137898 IP 10.100.100.1.4770 > 10.100.100.80.http: . ack 1 win 65535

 

 

So the 3 way handshake is set up. I don't push any data and just let it sit there idle. It stays pinned up, and no RST occurs. 12 or so seconds later I quit my telnet session and we do a graceful close:

 

 

10:35:02.970000 IP 10.100.100.1.4770 > 10.100.100.80.http: F 1:1(0) ack 1 win 65535

 

10:35:02.971151 IP 10.100.100.80.http > 10.100.100.1.4770: . ack 2 win 4380

 

10:35:02.972023 IP 10.100.100.80.http > 10.100.100.1.4770: F 1:1(0) ack 2 win 4380

 

10:35:02.972196 IP 10.100.100.1.4770 > 10.100.100.80.http: . ack 2 win 65535

 

 

In other words, assuming they're not sending data and you're using a standard tcp profile (I'd expect to see [PSH] in your capture, above) the connection shouldn't reset.

 

 

-Matt

 

I set up a test VIP with the connection limited to one, and the dev who made the original request just got around to testing. Watching connections via Wireshark, it appears that the LTM is sending a RST almost immediately after finishing the three-way handshake, presumably because there's no pool behind the VIP. Any ideas on what we can do to prevent that?

 

 

 

The easiest thing you can do is add an HTTP profile. Long story short, the TCP profile doesn't wait for any data to tell the TCP proxy in the BIG-IP that a new connection has arrived, so it will try to load-balance it, which will fail (no pool) and reset the connection as you found. HTTP, on the other hand, will wait for an HTTP request before alerting the TCP proxy about a new connection. Since your clients aren't sending any data, it shouldn't hurt anything.

 

 

Thanks for clarifying Spark. I also remembered the behavior Matt had described--but I guess that's because I'm normally testing with HTTP VIPs.

 

 

Aaron

Sure enough. Good catch Spark, I was testing via the exact same method (with an HTTP VS). For posterity, here's the same routine with a vanilla tcp-profile only VS. As soon as the handshake is done the LTM sends a reset, as you describe:

 

 

03:22:55.971484 IP 10.100.100.1.gvcp > 10.100.100.2.distinct: S 3698065870:3698065870(0) win 65535

 

03:22:55.971485 IP 10.100.100.2.distinct > 10.100.100.1.gvcp: S 1871870510:1871870510(0) ack 3698065871 win 4380

 

03:22:55.971488 IP 10.100.100.1.gvcp > 10.100.100.2.distinct: . ack 1 win 65535

 

03:22:55.972470 IP 10.100.100.2.distinct > 10.100.100.1.gvcp: R 1:1(0) ack 1 win 4380

 

 

-Matt

 

Just wanted to say thanks - adding the HTTP profile is exactly the simple fix I needed, verified w/Wireshark working perfectly. My dev is (very) happy. :-)