Guest

Cisco LocalDirector 400 Series

LocalDirector FAQ

Document ID: 15062

Updated: Jan 31, 2006

   Print

Introduction

Local Director is a high-availability, Internet-scalable solution that intelligently load balances TCP/IP traffic across multiple servers. Servers can automatically and transparently go in or out of service. Local Director comes with a hot standby failover mechanism, eliminating all points of failure for the server farm.

This document provides answers to Frequently Asked Questions (FAQ) about Local Director.

Q. How many Local Director interfaces are needed?

A. A minimum of two interfaces are needed; these should be separated by different virtual LANs (VLANs) in a switch, or by two separate hubs

Q. How do I assign a secondary address to a Local Director?

A. Issue the alias ip address command, which first appeared in Local Director software version 3.1.3. If you are in failover mode, you also need to issue the failover alias ip address command.

Q. How does Local Director cause a real server failure?

A. By default, Local Director tracks two metrics (No Answer Reassign and TCP Reset Reassign) when determining server availability. You can use the threshold values and the reassign values to adjust the server failure mechanism.

Q. Why does Local Director 3.1.3 not reassign failed SSL sticky connections?

A. This issue first appeared in Local Director 3.1.3, when Secure Sockets Layer (SSL) sticky was first introduced. This issue is addressed by Cisco bug ID CSCdp03095 ( registered customers only) .

Q. Why does Local Director 3.1.3 not decrement connections correctly when using the least connection predictor?

A. This issue is addressed by Cisco bug ID CSCdp09265 ( registered customers only) .

Q. Local Director 3.1.3 does not replicate its configuration to the standby unit correctly. Why?

A. This issue first appeared in LocalDirector version 3.1.3. Refer to the Cisco bug ID CSCdm47752 ( registered customers only) .

Q. What is the workaround for the problem with SSL sticky and Internet Explorer 5.0?

A. This problem affects clients who use IE 5.0 as their browser and initiate a SSL session through any Local Director that uses Local Director code 3.1.x and higher. When Local Director is configured to use SSL sticky to maintain session persistence, an SSL ID is created. Local Director maps the SSL Session ID (SID) to a specific real server. IE 5.0 resets the SSL SID from between 30 seconds to two minutes. This makes the information LocalDirector uses to maintain session persistence useless.

See HTTP Redirection or Generic Sticky to maintain session persistence with SSL applications.

Q. When I run Local Director 3.1.3 code, SSL sticky is not working. Why?

A. Little can be done about this issue; however, consider trying the following:

  1. Make make sure that the web servers are configured to support SSL version 3 only
  2. Configure a default route on the Local Director, because it will proxy the initial connection. It is strongly recommended that you upgrade to the latest release available at this point (check the Release Notes for details).
  3. As a last resort, you could perform a sniffer trace to exactly confirm the appropriate issues.
  4. Verification - Final checks take place on the server and client side to ensure transfers have not been interfered with by a third party. When the server and client side confirm the validity of the transfers, the handshake is complete. If confirmation fails to occur, the handshake starts over in an attempt to correct an interception or a problem that may have occurred in the original handshake.

Q. What is SSL sticky used for?

A. SSL sticky in Local Director maintains session persistence when SSL applications are used. Because SSL is an encrypted means of transport, Local Director is limited to what variables it can use to identify traffic from a client to make sure it goes to the same real server. Local Director uses a SSL SID, which is created between client and server during the SSL Handshake Protocol. The simplified SSL Handshake Protocol is as follows:

  1. Client Hello - Informs the server what cryptographic algorithms the client can support and asks for verification of the server's identity. The SSL SID is generated.
  2. Server Hello - Sends the client its digital ID and determines what cryptographic and compression algorithms to use for the session. The SSL session ID is confirmed and used in reply.
  3. Client Approval - Validates a server's authenticity. Once the server is verified, the client generates a secret key and encrypts it with the server's public key that is provided in the Server Hello. The client then sends the encrypted secret key back to the server.
  4. Verification - Final checks take place on the server and client side to ensure transfers have not been interfered with by a third party. When the server and client side confirm the validity of the transfers, the handshake is complete. If confirmation fails to occur, the handshake starts over in an attempt to correct an interception or a problem that may have occurred in the original handshake.

Q. Can my real servers be on a different subnet than the Local Director's virtual subnet?

A. Yes. There are at least two possible network setups to make this happen.

locdirfaq-1.gif

If:

  • The IP address of Local Director is 192.1.1.10 255.255.255.0.

  • The router's interface towards Local Director is 192.1.1.1 255.255.255.0.

  • The real server(s) is 204.1.1.20.

Then:

  • Add a secondary address on the router's interface; for example, 204.1.1.1 255.255.255.0. This address has to be on the same subnet as the real servers.

  • Change the default gateway of the real server to 204.1.1.1.

  • Make sure the default gateway of Local Director is 192.1.1.1.

  • If you are running 3.x code on Local Director, add the alias IP address 204.1.1.10 as well.

locdirfaq-2.gif

If:

  • The IP address of Local Director is 192.1.1.10 255.255.255.0.

  • Router 1's interface towards Local Director is 192.1.1.1 255.255.255.0.

  • Router 2's interface towards Local Director is 192.1.1.2 255.255.255.0.

  • The real server(s) is 204.1.1.20.

Then:

  • Add route 204.1.1.0 255.255.255.0 192.1.1.2 in Local Director to enable it to direct any traffic for real servers to the second router.

Q. What do you do when you detect that packets from real servers pass through the Local Director and are dropped by the firewall?

A. It is possible that there are some retransmission of FIN (or ACK) packets from the servers after the Local Director removed the connection from the table. You can configure the Local Director to block this kind of request by adding the secure command to your configuration. This would block all packets not belonging to the load balanced connections. Another solution is to add the delay command your configuration. This command removes the connection some minutes later. See the Command Reference for the 4.2 version of the Local Director software for more command information.

Related Information

Updated: Jan 31, 2006
Document ID: 15062