Hi B-Cunningham,
Very simple !!
When you need the same user to be always sent to the same server, you need some sort of stickyness.
There are many different ways to achieve this.
Some predictor algorithms will by definition always select the same server for a given client. This is the case with the source ip hashing predictor.
But very often you will need to configure a sticky method in combination with your predictor algorithm.
What is the source ip hash predictor a sticky method ?
Actually, this is not a sticky method. But since the hash algorithm always give the same result for a given source ip address, it guarantees that a client using the same ip address will always be sent to the same server.
The advantage is that it does not require to configure a specific sticky method. It also works without the need for a sticky table. So it does preserve resources.
But the hash function will have different results when you add or remove a server. Therefore, when your rserver list is modified your clients might be sent to different servers breaking stickyness.
Is sticky source ip a good solution ?
Because of the changing hash results mentioned above, most people will prefer to use a standard predictor (roundrobin , leastconn, ...) and add a sticky source ip option.
The idea is to also use the source ip address to identify the client and select the corresponding server.
Unlike the hash method, the stick source ip solution will need sticky resources to save the information necessary for ACE to remember which client uses which server.
The advantage of the sticky option is that the sticky table is not affected when the rserver list is modified.
Why not use sticky source ip ?
Very often this solution is enough to guarantee stickyness.
But because a lot of clients do not have a static ip address, this method does not work.
There is also the problem of proxy servers hiding many clients behind a single ip address resulting in rserver overload when using sticky source ip.
For HTTP the solution is to use information contained in the client HTTP request and server HTTP response.
An HTTP Cookie is an object used by a server to identify HTTP clients. A loadbalancer can therefore also use this information to map a client to a server.
One drawback of hash predictor is that the hash predictor methods do not recognize the weight value you configure for real servers. The ACE uses the weight that you assign to real servers only in the round-robin and least-connections predictor methods.
Here is the hash algorithm
((_key) + (_key >> 8) + (_key >> 16) + (_key >> 24))The _key in this case is the source ip address has an unsigned 32 bits number.You then do rserver_index = hash % number_of_rserver.
Session persistence (stickiness) based on client source IP address or HTTP cookies are recommended to be configured on the Cisco ACE for this flow.
IP Address Stickiness
You can use the source IP address, the destination IP address, or both to uniquely identify individual clients and their requests for stickiness purposes based on their IP netmask. However, if an enterprise or a service provider uses a megaproxy to establish client connections to the Internet, the source IP address no longer is a reliable indicator of the true source of the request. In this case, you can use cookies or one of the other sticky methods to ensure session persistence.
Here can be the sample configuration:
resource-class websrv
limit-resource all minimum 0.00 maximum unlimited
limit-resource sticky minimum 20.00 maximum equal-to-min
rserver host webserver1
ip address 10.10.10.1
inservice
rserver host webserver2
ip address 10.10.10.2
inservice
rserver host webserver3
ip address 10.10.10.3
inservice
serverfarm host werbsrv1only
probe websrv
rserver webserver1 1000
inservice
serverfarm host werbsrv123
probe websrv
rserver webserver1 1000
inservice
rserver webserver2 1000
inservice
rserver webserver3 1000
inservice
ACE receives requests to the VIP on port 80 and translates them to port 1000 using the server farm configuration shown above.
The link to the websrv home page is http://websrv:1000/index.html. A probe to this link is configured on ACE as follows:
probe http websrv
port 1000
interval 2
faildetect 2
passdetect interval 2
request method get url /index.html
expect status 200 200
Session persistence can be established by tying the session to an IP address, that uniquely identifies the client.
Create a sticky-group
sticky ip-netmask 255.255.255.255 address source Client_subnet_1
timeout 10
serverfarm werbsrv1only
Change the server farm to the sticky-group:
policy-map type loadbalance first-match basic-slb
class class-default
sticky-serverfarm werbsrv1only
sticky ip-netmask 255.255.255.255 address source Client_subnet_2
timeout 10
serverfarm werbsrv123
sticky ip-netmask 255.255.255.255 address source Client_subnet_3
timeout 10
serverfarm werbsrv123
Here you can find the details in the below url :
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/sticky.html#wp1004411
I have also attached a jpeg for your reference.
Hope you will get the idea how to use the sticky based on IP address.
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/sticky.html#wp1004411
Here you can find sample config of similar type:
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/ps6906/prod_white_paper0900aecd804edab0.html
HTH .
Please rate if you find it useful.
Thanks and regards,
Sachin Garg
Senior Specialist Security
HCL Comnet Ltd.
http://www.hclcomnet.co.in
A-10, Sector 3, Noida- 201301
INDIA
