ACE ignoring class map depending on source???

[federicovt]

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

[Daniel Arrondo Ostiz]

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

[federicovt]

Thank you.

I forgot to mention that we are not using the module but the appliance.

As we are not using all ports on it, can one of the ports be configured in "monitoring" mode to sniff the traffic. I can otherwise place some virtual sniffing machine "in front" of the ACE.

We already have persistance rebalance enabled. From a "sh service-policy detail"

class: VIP-app

     VIP Address:    Protocol:  Port:

     192.168.138.39  tcp        eq    80  

      loadbalance:

        L7 loadbalance policy: VIP-app-loadbalance

        Regex dnld status    : SUCCESSFUL

        VIP ICMP Reply       : ENABLED

        VIP State: INSERVICE

        Persistence Rebalance: ENABLED

Any other clues? Ideas?

/F

[Daniel Arrondo Ostiz]

Hi Federico,

My answer would be the same in the case of the appliance. We would also need to get captures on both sides of the ACE. In this case, instead of doing a SPAN session on the switch for the internal interface, you would need to do it for the ports or vlans connecting to the ACE appliance. Unfortunately, you cannot use the ACE ports themselves for this.

If you still cannot figure out the issue from the capture yourself, you can always open a TAC case to have this investigated further.

Daniel