ACE not creating session to rserver (sending a RST)

Question

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 ?

Answer 1

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).