Cisco LocalDirector 400 Series

Cisco LocalDirector Product Bulletin v 3.3 Software

Product Bulletin, No. 1045

Cisco LocalDirector Version 3.3 Software

This product bulletin provides an overview of the feature set for Cisco LocalDirector Version 3.3. LocalDirector Version 3.3 software is backward-compatible with all Cisco LocalDirector hardware, including the Cisco LocalDirector 410, 415, 416, 420, and 430.

  • Cisco LocalDirector Version 3.3 beta is available to registered Cisco Connection Online (CCO) users at
  • LocalDirector 3.3 will be available March 2000

  • Expect Version 3.3 to ship with every physical LocalDirector 416 or 430 in May 2000

Cookie Sticky

The "Cookie Sticky" feature in Cisco LocalDirector 3.3 is designed to give web managers and developers a way for the load-balancing appliance to keep clients directed to the same physical or real server using standard Hypertext Transfer Protocol (HTTP) cookie technology. "Cookies" are strings passed using http from servers to browsers. After a client has received a cookie as the result of a "set cookie" HTTP command, any server can poll that cookie, providing they know its structure, with a "get cookie" command. This allows the querying server to positively identify the client as the one that received the cookie earlier. In this fashion, programmers can identify clients and reconstruct session state after a new TCP connection from that client is initiated. In the LocalDirector implementation, this technology is used to route users back to the same physical server based on the cookie the client shows the LocalDirector.

This feature works very much like the current Secure Socket Layer (SSL) feature of LocalDirector with the exception that when "Cookie Sticky" is set, it has an additional option of being able to issue cookies itself. These two modes of the "Cookie Sticky" feature are "Cookie-Insert Mode" and "Cookie Passive" mode.

LocalDirector—DistributedDirector Communication

LocalDirector can now communicate load and availability to DistributedDirector. This is possible because DistributedDirector supports Dynamic Feedback Protocol (DFP) and LocalDirector now has the ability to act as a DFP server. In other words, LocalDirector's load and availability is communicated to DistributedDirector via DFP. The benefit of this feature is increased site availability. DistributedDirector now has all the application-aware technology that LocalDirector has through DFP and content verification. Additionally this increases DistributedDirector's scalability limit by placing the health check burdens on each LocalDirector at each site.