This method aims to provide pseudo persistency with the backend servers. In this method the NetScaler bases its selection of a server based on a token extracted from client requests. Using advanced policy expression you can configure the token to be extracted from HTTP request. Policy expression has ability to look inside request URL, Header, Body or any part of HTTP payload to identify the token.

As can be seen in the above example, Request with Token”34567898” is load balanced by LB Vserver1 to Server1 and Request with Token”123464789” is load balanced by LB Vserver1 to Server2 maintaining the persistency level. For subsequent requests with the same token, the virtual server chooses the same server that handled the initial request.

For HTTP services, the virtual server searches for the configured token in the first 24 kilobytes (KB) of the TCP payload. For non-HTTP (TCP) services, the virtual server searches for the configured token in the first 16 packets if the total size of the 16 packets is less than 24 KB. But if the total size of the 16 packets is greater than 24 KB, the NetScaler searches for the token in the first 24 KB of payload.

Use Case:Efficient load balancing for dynamic URLs

Here is an example of URL which goes through the CDN network and adds up tokens generated dynamically on the path. Thus the object may remain same but URLs would look different and would confuse the classic URL hash based LB algorithms.

Request1:

http://v22.nonxt1.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor%2Coc%&ipbits=0&

burst=40&sver=3&expire=169728675840&key=yt1&factor=1.25&id=106b536e54d1d185&redirect_counter=1

Request2:

http://v22.nonxt1.c.youtube.com/videoplayback?ip=10.10.0.1&id=106b536e54d1d185&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor%2

Coc%&ipbits=0&burst=40&sver=3&expire=1294587600&%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor%2

Coc%&key=yt1&factor=1.25&redirect_counter=1

Request3:

http://v22.nonxt1.c.youtube.com/videoplayback?ip=10.10.0.1&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor

%2Coc%&id=106b536e54d1d185&ipbits=0&burst=40&sver=3&expire=1272387600&key=yt3&factor=1.25

&redirect_counter=1

Note that all the 3 dynamic requests are requesting for the same object with id=106b536e54d1d185.

As can be seen with above example, at times the URL Hash LB Method might not be able to generate the same unique Hash Value for all the three requests requesting for the same YouTube video with id=106b536e54d1d185.

This Method with the different Hash values for all the above mentioned requests will end up directing the requests to different back end servers. Which is undesirable, as these requests should be directed to the same backend server.

To counter this, a need to extract only the relevant data from the request for identifying unique object requested arises.

With the below mentioned rule configured on NetScaler, based on the values of the “id=”, the Token LB Method configured on NetScaler, we can extract the relevant data i.e. id=106b536e54d1d185 in this case.

HTTP.REQ.URL.QUERY.VALUE(“id”)

This expression will direct the requests to the same back end server using the Token Load Balancing Metho