Hi Rafael,
For what purpose are you using "predictor hash address" or planning to use. Please share your scenario along with if it is CSM or ACE.
Are you using it to load balance firewall.
For FWLB, it is recommend that you use only the hash address source and the hash address destination predictors. Using any other predictor with FWLB may fail and block traffic, especially for applications that have separate control and data channels, for example, FTP.
Source IP hashing also provides a simple stateless way to stick a client to the same real server in SLB environments.
A benefit of source address hashing in some environments is that the client connects to the same server for every request, causing the client to stick to the same real server for all requests to the virtual server. This benefit proves useful for e-commerce applications that store client-specific information across content requests.
When using hash address as the predictor, the load balancer selects the real server by using a hash value that is calculated by using both the source and destination IP address. This predictor can be used to achieve session persistence when no proxy servers are in front of the clients. The proxy servers issue the requests on behalf of the clients, thus changing the client IP address. The hash value is calculated so that there is statistical distribution based on source and destination IP addresses, which works best when there is a wide range of source or destination IP addresses.
Hashing the packet's source IP address is useful only in environments where there are vast numbers of clients, because the same keys provide the same hash value. A small number of clients may cause an over-selection of particular real servers. Additionally, some ISPs use mega-proxy servers to NAT hundreds or even thousands of clients to a single IP address. As a result, your load balancer will forward all requests from clients behind the proxy to the same real server, potentially causing that real server to overload.
Typically, the default balancing method, round robin is used. Since support of multiconnection protocols, such as FTP as I said above, is required in firewall loadbalancing design, you have to use predictor hash address Source | Destination in your configuration. For multiconnection protocols where some connections are open by clients and others by servers and you need to make sure all the connections belonging to the same session go through the same firewall, you will have to use source IP hash for incoming connection and destination IP hash for outgoing, or vice versa.
The hash algorithm is something like this:
((_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.
Source or destination IP hash method maps the IP address in the request to a real in a server farm. The configuration options are shown below.
predictor hash address [source | destination] [netmask]
!--- Source/Destination IP hash or predictor hash address.
The default (netmask) is 255.255.255.255. The hash value is produced with the following algorithm:
ip_addr = (Src_or_Dest_Ip_addr & Cfg_Netmask) hash_index = (ip_addr) + (ip_addr >> 8) + ip_addr >> 16) + (ip_addr >> 24);
Also for detail configuration examples for hash predictor kindly refer the below mentioned URL:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/configuration/slb/guide/fwldbal.html#wpxref70632
---
For Least connections— it selects the server with the fewest number of active connections based on the server weight. For the least-connections predictor, you can configure a slow-start mechanism to avoid sending a high rate of new connections to servers that you have just put into service.
For Least loaded— as it selects the server with the lowest load based on information obtained from Simple Network Management Protocol (SNMP) probes. To use this predictor, you must associate an SNMP probe with it.
You can configure stickiness when you require load balancing multiple TCP flows of a session to the same server as the original flow, to retain information stored about the flow on the server. The same principle is true with FWLB. For applications that require multiple connections in the same direction within the same application session, such as HTTP and Passive-FTP, you can use IP session stickiness or distribution via address hashing to ensure that multiple TCP sessions stick to the same firewall.
Kindly rate.
HTH
Sachin Garg
'
