In our other load-balancing environments the load-balancer-cookie contains the encrypted (real) servername or ip-address.
We think it's the same on the cisco, for that reason it's in theory not possible, that there are two 'green'-cookies with different values in the same request.
There are only two possibilities how this could happen:
a) The healthmonitor (http_probe) fails, the loadbalancer 'thinks' that the realserver is down and redistributes the traffic.
But in that case we would expect, that the old cookie will be overwritten by the new one and not simply added to the http-header.
b) The predictor in the serverfarm chooses a new realserver within the same request.
If that is really the cause of that problem this would be bug in the cisco ace.
What we found out, is that the loadbalancer performs a 'Set-Cookie'-Operation an every request even if the client submits the cookie correctly.
For example:
GET /ips-opdata/scripts/jquery.js HTTP/1.1
Host: www.xxxxx.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110303 Ubuntu/10.04 (lucid) Firefox/3.6.15
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.xxxxx.com/
Cookie: green=R339366665; JSESSIONID=28D91FC6FD62A3921354BB36826294C4
HTTP/1.1 200 OK
Set-Cookie: green=R339366665; path=/; expires=Tue, 29-Mar-2011 06:33:00 GMT
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5
ETag: W/"72181-1298537508000"
Last-Modified: Thu, 24 Feb 2011 08:51:48 GMT
Content-Type: text/javascript
Content-Length: 72181
Date: Mon, 28 Mar 2011 06:15:19 GMT
As you can see the cookies: green=R339366665 is transmitted from the client, but the loadbalancer does a Set-Cookie Operation of the same cookie once again. This is an unexpected behaviour.
We hope that this helps you to figure out the reason of the problem.
