ACE 4710 Can not confirm http cookie sticky connections

[dlance]

We are using a ACE 4710 with A3(2.6) software release.

I had to change our sticky load balancing method for HTTPS to cookie based.

However while connections appear to work if I look at the sho sticky database table I can not see or confirm sticky entries for the cookie based connections.

Here or config snippets to show the config

sticky http-cookie ghh-www scook-ghh

  cookie insert browser-expire

  serverfarm ghh-www-443

class-map match-all ghh-www-443_CLASS

  2 match virtual-address 172.16.1.21 tcp eq https

class-map type http loadbalance match-any ghh-www-443_CLASSURL

  2 match http url [.]*

policy-map type loadbalance first-match ghh-sticky-443_POLICY

  class class-default

    sticky-serverfarm scook-ghh

policy-map multi-match POLICY

class ghh-www-443_CLASS

      loadbalance vip inservice

      loadbalance policy ghh-sticky-443_POLICY

      loadbalance vip icmp-reply active

      appl-parameter http advanced-options CASE_PARAM

[Alex Rickard]

Since you have your ACE configured to insert the cookie, use the "show sticky database static". This will show you the cookie value that corresponds to the rserver.

-Alex

[Alex Rickard]

You could also use the " show sticky cookie-insert group scook-ghh" to list just the cookies for your configured sticky group.

[dlance]

I tried the sho sticky database group scook-ghh and it came back blank

[dlance]

I'll try this

[Francesco Casotto]

Hello,

it might just be missing the right snippet in the config you posted but I still want to double check it:

from the snippet it would seem that you are not performing SSL termination on the ACE, if this is the case then there is no way that the ACE can perform stickiness based on cookies or balancing based on URL because both of those fields belong to the HTTP protocol which is contained inside the encrypted payload of the SSL protocol, so unless the ACE has been configured to be terminating SSL and so decrypting its contents, there is not way that the ACE can inspect any HTTP field.

To know how it would look like this is an example of ssl termination configuration:

http://docwiki.cisco.com/wiki/SSL_Termination_on_the_Cisco_Application_Control_Engine_Using_an_Existing_Chained_Certificate_and_Key_in_Routed_Mode_Configuration_Example

Hope it helps,

Francesco

[dlance]

We are not doing any SSL termination on the ACE, we just pass through the requests to the rservers.

If we have to do SSL termination it is going to make our config much more complicated.

[Alex Rickard]

Without doing SSL termination on the ACE there is no way for the ACE to insert the cookie. This is due to the fact that the stream is encrypted.

[dlance]

Unfortunately that does make sense as why its not working. No way for the ACE to extract the cookie

.

[dlance]

OK. 2 more dumb questions

1. Can I just import the certifcate from one of the web servers to use on the ACE or does it have to be obtained from RSA or another authority.

2. Since we are running a failover pair of ACE's do each of the ACE's have to get their own certifcate from RSA.

[Alex Rickard]

You can import the certificate and key into the ACE. Just make sure to verify that the key is the appropriate key for the given certificate. Each ACE will need a SSL cert and key for SSL termination on a VIP to work. Whether or not you need a license for each certificate installed on the SSL termination point (both active and backup) would depend upon your license aggreement with you CA.

[Francesco Casotto]

Another point: please check whether your servers are listening only for HTTPS traffic or also for HTTP traffic:

in the first case the ACE will have to: decrypt the traffic from the client, inspect the http header to take the loadbalance decision and then re-encrypt it and send it to the server

in the second case the ACE would have to: decrypt the traffic from the client, inspect the http header to take the loadbalance decision and send it out as it is unencrypted to the server

the second solution would have the benefit of being easier to configure and to require less resoucerces both on the ACE (only decryption to be performed) and on the servers (no need for SSL operations at all there) but it might be that your company or business sector have requirements for which this traffic should never flow unencrypted, in which case you would have to go for the first solution.

Here you have a config example for the first solution:

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c6f37.shtml

I would not expect you to have to pay extra for importing the cert and kepair into the ace, it would be just a copy, however as Alex said that may still depend on the license agreement with the CA.

Cheers,

Francesco

[dlance]

Yes it would be solution 1. I believe this to be true because the web servers pages are different for http and https.

I will look at that document. Thanks

[dlance]

Also I do not believe we need this part.

serverfarm redirect REDIRECT-Serverfarm
  rserver HTTP-to-HTTPS
    inservice



!--- Serverfarm to redirect http connections to https.

We dont want normal http client calls to be converted to https.

[Alex Rickard]

The section of the config you reference is indeed to send a 301 redirect to the originator and have them come back on HTTPS using the same hostname and URL path string. If you do not want your client requests, that come in on port 80 to this VIP, to be redirected then you would not need to configure redirection.  Not sure if you already have it, but you would need a port 80 rule for this VIP to load balance the this traffic (port 80) according to your requirements.

-Alex