CSS loadbalancing based on a string in the URL

[wassim.sharbek]

Hi guys,

I have CSS11503 running 08.10.1.06 and I’m trying to configure loadbalancing based on a string in the URL. Our goal is that the CSS will forward a customer request to the same server always depending on a unique customer ID found in the URL, and without using the sticky table. I have build the config below to perform the following, but it seems not function as expected:

Assuming customers will use the links below:

http://10.1.1.30:8080/opensso/subjectid2w2w2w2wxzxzxzxzxzxz

http://10.1.1.30:8080/opensso/subjectid12345678asasasasasasasasas

1-      CSS  will take a string from the 1^st  to 100 character out of the URL after the "/opensso/ 

2-      CSS will look for the string prefix (subjectid),

3-      CSS will pick up  a 8 bytes string right after the prefix (subjectid) to apply the URL advanced load balancing. For example: CSS will depend on the  string (user ID) “2w2w2w2w” from the first user’s URL above, and send the request to a server. Next time when the user sends a request to the CSS, the request will be sent to the same server because it always include the same user ID ““2w2w2w2w” after the prefix (subjectid)  for that user.

I notice this is not functioning as expected. When I do continues test ( keep refreshing my browser to go to the mentioned URL) the CSS directs the request to the same server. If I stop testing for few minutes, or If I clear my browser cash, the CSS directs all requests to the other server even I’m not changing the URL.

Any idea if I'm missing anything in the config?

Considering the following:

-We don’t want a loadbalancing  solution based on cookies. Our customers may clear the cookies at anytime, or they don’t want to accept cookies.

-I’m wondering about the difference between “balance urlhash” and “advanced-balance url “?

With “balance urlhash”, will the CSS hash the whole URL, or we can configure the String parameters so the CSS will hash only 8 bytes after the prefix (subjectid) in my configuration?

!*************************** OWNER ***************************

owner Test-SSO

  content 8080

    vip address 10.1.1.30

    add service test.sticky.app1.sso.int-8080

    add service test.sticky.app2.sso.int-8080

    advanced-balance url

    string process-length 8

    string prefix "subjectid"

    protocol tcp

    port 8080

    url "/opensso/*"

    active

service test.sticky.app1.sso.int-8080

  ip address 10.1.1.31

  port 8080

  keepalive http-rspcode 302

  keepalive type http non-persistent

  keepalive port 8080

  protocol tcp

  keepalive uri "/opensso"

  active

service test.sticky.app2.sso.int-8080

  ip address 10.1.1.32

  port 8080

  keepalive http-rspcode 302

  keepalive type http non-persistent

  keepalive port 8080

  protocol tcp

  keepalive uri "/opensso"

  active

Thanks

[Gilles Dufour]

The CSS does not learn any cookie or url string.

It only does a hash of the value and send the same hash to the same server.

The problem is that since we do not learn anything from the server response, there is no guarantee that the first request (which does not contain the url stiky info) and the subsequent requests (which do contain the sticky info) will go to the same server.

In other words, the first request for "www.mysite.com/" goes to server A because the CSS didn't see any sticky info and just did some random loadbalancing.  The response from the server contains links with www.mysite.com/....sticky_info.....

This time the request contains the sticky info, we do hash a decide this hash is associated to server B.

ll requests from this client will now be sent to serverB...unfortunately this is not the same as the initial server.

There is nothing you can do about this.

The best way to do stickyness on the css for http traffic is arrowpoint cookie.

Gilles.