01-27-2011 06:19 AM
Having a ACE-Deployed for loadbalancing web-requests which are coming from a reverse-proxy. The session persistency is based on the x-forwarded-for HTTP-header entry.
The situation works fine but in certain situations it looks like the ACE (172.16.3.200) is sending a RST shortly after an ACK in direction of the reverse-proxy (172.16.2.10).
Investigating this RST shows me that ACE is not creating a session towards to the real-server, meaning session from reverse-proxy to ACE is there but session from ACE to real-server doesn’t get created (no SYN sent from ACE).
Example:
(1) 11:20:07.677541 src:172.16.2.10 dst:172.16.3.200 proto:TCP info: 38776 > http (SYN)
(2) 11:20:07.677891 src:172.16.3.200 dst:172.16.2.10 proto:TCP info: http > 38776 (SYN, ACK)
(3) 11:20:07.677920 src:172.16.2.10 dst:172.16.3.200 proto:TCP info: 38776 > http (ACK)
(4) 11:20:07.677979 src:172.16.2.10 dst:172.16.3.200 proto:HTTP info: GET /media/global/stylesheets/class.css?v=0.20 HTTP/1.1
(5) 11:20:07.678553 src:172.16.3.200 dst:172.16.2.10 proto:TCP info: http > 38776 (ACK)
(6) 11:20:07.678553 src:172.16.3.200 dst:172.16.2.10 proto:TCP info: http > 38776 (RST, ACK)
Normally, for every session from the reverse-proxy to ACE, ACE creates a session to the real-server. In this particular trace, ACE only creates the incoming one but not the outgoing to the real-server. The real-server is alive at this time, requests just some milliseconds before and after packet four (4) are processed to the same real-server correctly.
Normalization is disabled and we’re running in routed mode.
Any idea why ACE itself doesn’t creates this new session ?
01-27-2011 06:31 AM
without config and contents of get request cannot tell what the problem is.
the ace is obviously configured for layer 7 load balancing (since persistence is on a header) and whatever else you may be looking for in the get.
you may want to look at
"show stats http" and see if static parse errors or max parselen errors are incrementing.
if you attach config and capture I can take a look, but the problem is something in the get request that the ace is rejecting either because it is not rfc compliant or too long or is not matching the match criteria for l7 loadbalancing.
01-28-2011 03:09 AM
I just verified "show stats http" and there is a zero (0) for max parslen errors and static parse errros, so we should be fine on the length and on the value we're expecting.
Here the relevant snippets from the configuration.
!
sticky http-header X-Forwarded-For STICKY_HTTP-HEADER
timeout 180
serverfarm SF_FRONTEND
!
class-map type http loadbalance match-all CM_STICKY_HTTP-HEADER
2 match http header X-Forwarded-For header-value ".*"
!
class-map match-any CM_VIP_FRONTEND
description VIP for FRONTEND
5 match virtual-address 172.16.3.200 tcp eq www
!
policy-map type loadbalance first-match PM_LB_FRONTEND
class CM_STICKY_HTTP-HEADER
sticky-serverfarm STICKY_HTTP-HEADER
class class-default
serverfarm SF_FRONTEND
I would love to share the broken capture with you (see attached).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide