TCP reset issue

Hello,

I am in the process of testing a rather simple load balancing pool, but am experiencing TCP resets (as verified with a tcpdump during connection)

the virtual server is setup on 10.14.0.154 and the nodes themselves are on 10.14.0.152 and 10.14.0.153

when i hit the nodes directly (HTTP request on port 8000) it works fine, so we know that the back-end setup is okay. the traffic all staying in the 10.14.0/24 subnet.

health monitors for both nodes to http on 8000 show green (up) and the web pool that serves them shows green.

the virtual server shows green as well and listens on port 8000

config is standard

protocol is tcp

protocol profile client is tcp

protocol profile server is use client profile

oneconnect profile is none

http profile is http

address and port translation are both checked

SNAT pool is auto map

everything else is defaults.

we are on 9.1.1 build 54.6

config

design

18 Replies

Phillip_Blatzhe
Nimbostratus
Dec 06, 2010
In the process of setting up an F5 Virtual Server on version 9.4.8 HF4 using Endeca Solution Article for 2006.

Will update when I have it up and tested.
Chris_Miller
Altostratus
Dec 06, 2010
I'm an Endeca customer and am load balancing their app just fine. What's the issue you guys are having right now?
LTU_Group_95344
Nimbostratus
Feb 17, 2011
Hi Marc/Others,

We were experiencing this exact same issue, and we found that the TCP Reset Packets (RST) were related to our OneConnect profile.

I notice that you have "oneconnect profile is none" so this is probably not related to your issue, however...

...reading this post was extremely exciting for us while we were diagnosing the problem, but very deflating when we got to the end, and there was no answer/resolution. So we thought we would post our findings, in case others happen upon this thread and are saved some time.

The OneConnect profile's TCP pooling and connection configuration needs to be honoured by the back-end nodes in your pool.

That is, whatever the back-end webserver application, it needs to have similar settings for Persistent Connection Pooling.

In our case, with apache/httpd on Red Hat Enterprise Linux 5 and 6, it was the "KeepAlive On" and requests, timeouts that were most important.

Hope this helps someone!
Chris_Miller
Altostratus
Feb 17, 2011
From what I saw, Endeca uses HTTP 1.0 so OneConnect wouldn't do much anyways. I guess I could see that being an issue...
Hamish
Cirrocumulus
Feb 17, 2011
HTTP/1.0 doesn't preclude the use of HTTP Keepalive...

H
Chris_Miller
Altostratus
Feb 17, 2011
Posted By Hamish on 02/17/2011 01:54 AM

HTTP/1.0 doesn't preclude the use of HTTP Keepalive...

H

It does when the company tells you their implementation doesn't allow for it.
Hamish
Cirrocumulus
Feb 17, 2011
Posted By Chris Miller on 02/17/2011 06:37 AM
Posted By Hamish on 02/17/2011 01:54 AM
HTTP/1.0 doesn't preclude the use of HTTP Keepalive...

H

It does when the company tells you their implementation doesn't allow for it.

Ha ha... I love it 🙂
Anyway. The monitor quoted above
~~/admin?op=ping HTTP/1.1\r\nHost: www.myhost.com:portnumber\r\nConnection: close\r\n~~

~~appears to be missing the blank line that tells the listener that the HTTP/1.1 request has finished... Does~~

~~/admin?op=ping HTTP/1.1\r\nHost: www.myhost.com:portnumber\r\nConnection: close\r\n\r\n~~

~~make a difference...~~

H
hoolio
Cirrostratus
Feb 17, 2011
The HTTP 400 response might indicate incorrect termination of the HTTP request from the send string. The monitoring daemon, bigd, behavior has changed over the versions. You can check SOL10655 for details on formatting HTTP/S send strings:

sol10655: Change in Behavior: CR/LF characters appended to the HTTP monitor Send string

http://support.f5.com/kb/en-us/solutions/public/10000/600/sol10655.html

Aaron