01-09-2013 09:44 AM
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
01-09-2013 01:44 PM
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
01-09-2013 01:48 PM
You could also use the " show sticky cookie-insert group scook-ghh" to list just the cookies for your configured sticky group.
01-10-2013 05:06 AM
I tried the sho sticky database group scook-ghh and it came back blank
01-10-2013 05:05 AM
I'll try this
01-10-2013 01:54 AM
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:
Hope it helps,
Francesco
01-10-2013 05:10 AM
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.
01-10-2013 05:15 AM
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.
01-10-2013 05:15 AM
Unfortunately that does make sense as why its not working. No way for the ACE to extract the cookie
.
01-10-2013 08:23 AM
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.
01-10-2013 08:30 AM
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.
01-10-2013 12:31 PM
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:
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
01-10-2013 12:38 PM
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
01-10-2013 12:45 PM
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.
01-10-2013 12:58 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide