ACE sticky configuration based on http header

[jeremie_delattre]

Hy,

I have a web application hosted on two web server. The application need a session persistence between the client and the server in order to work.

.

This persistence could not be implemented throught cookies persistence. All the request between clients and server web are realised throught a reverse proxy. I want to loadbalance request between the two servers.

I try to configure a Source IP base persistence. But, as all my request pass througt a reverse proxy, all the trafic go to the serverfarm 1, and no trafic to the second server.

So I would like to configure a IP and port source persistence

I try the following configuration but it do not work :

access-list ANY_WEB line 10 extended permit tcp any host eq www

rserver host server1

ip address xxx.xxx.xxx.xxx

inservice

rserver host server2

ip address xxx.xxx.xxx.xxx

inservice

serverfarm host SF_test

     probe HTTP-PROBE

     rserver server1

     inservice

     rserver server2

     inservice

sticky http-header x-forward ST_IP_PORT_SOURCE

     serverfarm SF_test

     replicate sticky

policy-map type loadbalance http first-match WEB_L7_POLICY

     class class-default

     sticky-serverfarm ST_IP_PORT_SOURCE

     insert-http x-forward header-value "%is %ps"

policy-map multi-match WEB-TO-VIPS

     class L4-WEB-IP

          loadbalance vip inservice

          loadbalance policy WEB_L7_POLICY

          loadbalance vip icmp-reply active

interface vlan xxx

ip adress xxx.xxx.xxx.xxx yyy.yyy.yyy.0

acces-group input ANY_WEB

service-policy input WEB-TO-VIPS

no shutdown

The ace add the x-forward attribute in the client request, but the http header persistence based on ip and port source don't work.

The sticky database is empty. It seems that the ace insert the header after the sticky loadbalncing. Is there a way to insert header and then make loadbalancing based on this header.

Is there a solution to make a ip and port source persistence. Where is my mistake ?

[Surya ARBY]

This is not the way you should implement it.

If your application is web-based, use a custom cookie insertion method with a timeout 0 ("browser expire") (this method always works with web browsers, no exception)

If it's not web-based but still based on HTTP, your reverse proxy must be configured to insert the source IP address of the client into a custom field in the HTTP header, and then on the ACE; you have to dynamically match the values embedded into this field, this will be strictly equivalent to a source IP method, but instead of learning the source IP at the socket level, it will be learnt within the HTTP header.