Why should destination-IP hash be used to load balance CacheFlow 5000 traffic?

<< Back to Knowledge Search



In general a caching solution is a combination of an L4/L7 switch and multiple caches.

The traffic distribution in a caching solution not only affects the balance of load across all caches, but it can also impact bandwidth savings.  This is because caching effectiveness is a function of ensuring that the whole deployment fetches each content object as few times as possible, and serves that content from cache as frequently as possible.  If the same content is fetched by multiple caches, bandwidth savings is decreased.  The optimum savings is achieved when only one cache acquires each individual object.

For example:  if the switch used a simple round-robin algorithm to distribute requests to the caches it is highly likely that multiple users’ requests for the same object would be directed to different caches, and as a result a copy of that object would be acquired by multiple caches.

So, optimizing bandwidth savings is a matter of minimizing the number of caches that field requests for a given piece of content.


This is a very complex problem and there is no perfect solution; mainly since not all web content is uniquely identifiable.

Research has shown that distributing requests by destination IP address is generally the most effective algorithm.  This kind of algorithm is usually implemented as destination-IP hash.

Web content is generally associated with the actual server that provides it.  Since a server is identified by its IP address, the affinity between the content and the server’s IP address – in other words the destination IP address – is strong.

This holds true in the case of large providers that use content delivery networks or similar distribution schemes.  They tend to structure their content in a manner that leaves this content-server affinity intact.

It is sometimes claimed that CARP (IETF draft is located at http://tools.ietf.org/id/draft-vinod-carp-v1-03.txt) is preferable to destination-IP hashing when load-balancing traffic to caching devices.  CARP was in fact designed for this task; however, CARP is an obsolete protocol developed in 1998; Blue Coat has conclusively determined that it does not provide good performance when used with the contemporary advanced caching techniques employed by the CacheFlow 5000.

An additional advantage of using a distribution algorithm based on IP addresses rather than URLs or similar is that the information is available at layer 4.  Load-balancing at L4 is more efficient and requires fewer resources on the switch, so a given switch can typically load balance more traffic.

In some cases using other algorithms in addition to destination-IP hash can enhance bandwidth savings or otherwise benefit the caching solution.  Keep in mind though that this comes at a cost of increased complexity of the solution and increased computational demands on the switch.

In the following examples layer 7 inspection can be useful:

  • Adding layer 7 logic for large and popular content providers that are transparent in how they route requests to the nodes (YouTube et al) can potentially increase bandwidth savings.
  • Adding layer 7 logic to avoid redirecting non-HTTP traffic to the caches.  If non-HTTP traffic is a significant percentage of the port 80 traffic, there is a potential to reduce load on caches without decreasing bandwidth savings.

Additional information on how to configure L4/L7 switches is available in the Deployment Guide and in the Sample Switch Configurations available from https://bto.bluecoat.com/cacheflow.

Additional Information
Bug Number
InQuira Doc IdKB4340

Article Feedback

Hide Properties
First Published      10/01/2014
Last Modified      10/01/2014
Last Published      10/01/2014
Article Audience
Software      CacheFlow
Topic      Configuration / WUI / CLI, Networking, Performance, Usability
Article Number      000016641
Was this helpful?
Previous MonthNext Month