Sticky session reset by ¿ACE or real server?

Question

Hello team.
I am looking for hints to debug cookie-based sessions that are failing to work across my ACE. Basically, the user types http://10.150.3.130/iwsupport, and that shoud be distributed across a farm of servers hidden behind the ACE.The servers set a cookie PHPSESSID=<value> when this URL is requested.
The customer tells me that he thinks that the problem arises when he requests access to the VIP with the POST command (please see the attached wireshark capture, line 52). His browser receives the following message:
Based on the original requirements, I configured the ACE, whose related section of the configuration is the following:
sticky http-cookie PHPSESSID STICKY_SERVERS
  timeout 720
  serverfarm TEST_SERVERFARM
  replicate sticky
class-map type http loadbalance match-all iwsupport
  match http url /iwsupport.*
policy-map type loadbalance http first-match TEST_POLICY
    class iwsupport
    sticky-serverfarm STICKY_SERVERS
  class class-default
    serverfarm TEST_SERVERFARM
class-map match-all VIP-130
  match virtual-address 10.150.3.130 tcp eq www
policy-map multi-match CLIENT_VIPS
  class VIP-130
    loadbalance vip inservice
    loadbalance policy TEST_POLICY
    loadbalance vip icmp-reply active
I would appreciate your hints to get session information, debugs, or whatever it could be useful in order to see why this is not working properly.
Thank you very much in advance
Rogelio Alvez
Argentina

Answer 1

Hi Rogello,
Do you see on server itself if POST request sent by client reached server or not? And if yes what did server reply? If you don't see POST request on the server then most probably it is the ACE which is sending the RST.
the outputs suggested by Jorge should help us and of course the suggested changes.
The changes will ensure that ACE parses upto 65535 bytes which is to ensure that ACE doesn't drop connection because it couldn't read which it was told to because it was way too far in the packet. By default ACE parses up to 4096 bytes.
Regarding persistence rebalance, When the first HTTP request comes in, the ACE will match the request to a layer-7 class-map  and load balance it to one of the servers within the serverfarm associated with that class-map.   The ACE will then also match all subsequent requests on the same TCP connection to a layer 7  class-map.  If the subsequent request matches the same layer 7 class-map as the previous  request, then it will be sent to the same server as the previous request.  If it matches a  different layer 7 class-map, then it will be load balanced to one of the servers within the  serverfarm of the newly matched layer-7 class-map according to the serverfarm’s predictor.
I doubt this will make any difference since without rebalance the traffic would be sent to the same server which i guess is not a problem here.
switch/Admin(config-parammap-http)# parsing non-strict--->This is a valid command and should work fine.
For allocating resources you can go to resource class and use limit resource command to allocate resources.
You can send the data at [email protected] Also, it would be good to have 2-3 instances of outputs while you do testing so that we can see the difference if any fail counter is increasing.
Regards,
Kanwal