ACE ignoring class map depending on source???

Question

I have a problem with a the load balancing "not working" properly depending on the source.
The load balancing decision is done with a secondary cookie (?ld=fe1 or ?ld=fe2). If it appears and the value is fe1 the request should go to serverfarm FE1-app. If the value is fe2 then serverfarm FE2-app should be choosen. If it is not present in the http request then serverfarm FE-app in the class-default is taking over.
This approach works if "surfing" to the VIP from a certain part of the internal network. It does not work from another part of the network. It seems that cookie is ignored and only the class default triggers.
The strange thing is that the same approach works for another setup that looks identical (with different rservers and different VIP of course). There the class map for the cookie triggers always.
My question is now: Why does the ACE seem to ignore the class map for the cookie when coming from a certain part of the network? How can I debug/follow a certain connection or load balancing decision?
Here is the config:
rserver host FE1-app
  description frontend app
  ip address 192.168.137.69
  inservice
rserver host FE2-app
  description frontend app
  ip address 192.168.137.74
  inservice
serverfarm host FE1-app
  rserver FE1-app 80
    inservice
serverfarm host FE2-app
  rserver FE2-app 80
    inservice
serverfarm host FE-app
  rserver FE1-app 80
    inservice
  rserver FE2-app 80
    inservice
class-map type http loadbalance match-all COOKIE-FE1
  2 match http cookie secondary ld cookie-value "fe1"
class-map type http loadbalance match-all COOKIE-FE2
  2 match http cookie secondary ld cookie-value "fe2"
class-map match-all VIP-app
  2 match virtual-address 192.168.138.39 tcp eq www
policy-map type loadbalance first-match VIP-app-loadbalance
  class COOKIE-FE1
    serverfarm FE1-app
  class COOKIE-FE2
    serverfarm FE2-app
  class class-default
    serverfarm FE-app
policy-map multi-match INT470
  class VIP-app
    loadbalance vip inservice
    loadbalance policy VIP-app-loadbalance
    loadbalance vip icmp-reply
interface vlan 470
  description lb_rpfedrift
  ip address 192.168.138.36 255.255.255.240
  alias 192.168.138.35 255.255.255.240
  peer ip address 192.168.138.37 255.255.255.240
  service-policy input remote_mgmt_allow_policy
  service-policy input INT470
  no shutdown

Answer 1

Hi Federico,
The source of the request has no relation with the way ACE handles the connections, so, there are probably other differences in the traffic.
The best way to troubleshoot these kind of connections is taking a traffic capture on the TenGigabit interface connecting the ACE with the switch backplane. Once you have it, you can try to look for differences between the working and failing connections.
From what you describe, I wouldn't be surprised if the issue comes from the fact that there are several HTTP requests inside the same TCP flow (in which case, by default, the ACE will look only at the first one), so I would suggest you to enable "persistence rebalance" for this VIP. For more details, check the link below:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/slb/guide/classlb.html#wp1062907
I hope this helps
Daniel