Cisco LocalDirector 400 Series

Configuring HTTP to HTTPS Redirection on the Cisco LocalDirector

Document ID: 44124

Updated: Jan 31, 2006



This document explains how to configure HTTP (non-secure site) to HTTPS (secure site) redirection on the Cisco Local Director. Please note the limitations in this example configuration.

Before You Begin


For more information on document conventions, see the Cisco Technical Tips Conventions.


There are no specific prerequisites for this document.

Components Used

The information in this document is based on the software and hardware versions below.

  • Local Director 416

  • Local Director Software Release 4.2.1

  • Microsoft Internet Explorer 5.5

  • Netscape Communicator 4.7

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Network Diagram

This document uses the network setup shown in the diagram below.


Important Information

There is a well known problem of keeping a session bound to one physical real server after the session is setup on HTTP (open) transport and later moved to HTTPS (secure) transport protocol. In this case, the HTTP redirection should be setup at the application level. The server can send a redirect (either a 302 or an HREF embedded in the actual web page itself) to HTTP, so no load balancing takes place at the Local Director.

Another possible solution would be to switch to HTTPS sooner, and perform the session opening encrypted. This is preferred also for encrypting the login username and password. If you keep the whole session running via HTTPS, the generic sticky can ensure that the same server will be used for a client.

The second solution and configuration is described in this document. The HTTP traffic is limited to first contact with the site (the client can type simple site name to address bar). When reaching Local Director, the browser receives a 302 redirect message with the URL configured, including the HTTPS tag, so there is the complete name of the server to reach. The session (on application level) is built from the beginning with the secure server (the real servers do not handle HTTP at all). Tthe session continues with the unique server name, so it is always reaching the same.

The dip, backup, and link commands, as shown in the example, are needed to solve bookmark problem when a user saves a URL with one server name and returns later when the server is down. The configured backup server will serve the session. If you expect to have a part of the session (on application level) handled via HTTP, then there is no possibility on the Local Director (or any other network device) to link the HTTPS connection to any of the preexisting HTTP connections. The only commonly used parameter can be the source IP address. The source IP address becomes unusable when you consider HTTP proxy, but direct HTTPS connections. All information stored in the URL or HTTP header (such as cookies) is encrypted, thus not accessible.

The only solution in this case is that the application itself uses specific server name when switching to HTTPS. As the application runs on the real server, and generates the HTTPS URL, it is the only place where the issue can be solved. The server simply sends a URL directed to the server itself. With the help of the backup command, you can solve the bookmark problem, as above. A disadvantage of both solutions is a need for different Secure Socket Layer (SSL) certificates in both real servers. The number of HTTP/HTTPS servers is not limited, and the Local Director remains balancing the initial session requests. After the session is established, however, the clients refer to one server only.

How to Configure HTTP to HTTPS Redirection on the Cisco Local Director

Use the following steps to configure HTTP to HTTPS redirection on the Local Director:

  1. Create a port-bound virtual IP (VIP) address and enter it in the Domain Name System (DNS). For example:

    virtual is
  2. Create a direct IP (DIP) address for each real server that will accept calls for this VIP address. Use an extra IP address in the first part of the statement, such as in the following:

    direct-ip is
    direct-ip is

    The system will create the following:

    real is
    real is

    Note: For port-bound or port-specific VIPs, DIPS, and real IP addresses, an additional IP address is needed for every real server to allow for continued outbound connections to the real IP addresses. Also, this additional address allows for safe VIP addresses if any TCP reset (RST) packets are sent for ports that are not to be load-balanced or redirected. Calls directed to the DIP addresses by their true address would be allowed while using other IP addresses for the DIP address' virtual.

  3. Create a URL redirect for each real server. These URLs are where the client will be redirected when a VIP address is hit. For example:

    url s2 302
    url s1 302
  4. Create a backup command for each DIP address to the common VIP address to solve potential bookmarking problems. If a client bookmarks the URL of a DIP address and that DIP address (real server) is unavailable (FAILED), then the backup command is used to call the VIP address again.


    Note: You cannot backup a TCP/443 with a TCP/80, therefore, you have two options:

    • Backup a DIP address with another DIP address, or in a full mesh sytle (each DIP address has a backup to every other DIP address).

    • Backup a DIP address with a VIP/443 that is bound to the real/443.

  5. Bind the VIP address to each URL command. For example:

    bind s1
    bind s2
  6. Create a link command for each URL to the first part of the DIP address.

    This creates an association between the DIP address and the URLs associated with that nickname. The link ensures that Local Director does not redirect clients to a failed DIP address, which is mapped one-to-one with a real server. If a DIP address fails, do not redirect to the URL that would send a call to the failed DIP address.

    link s2
    link s1


This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

  • show version - Displays the software version the Local Director is running.

  • show configuration - Displays the current running configuration on the Local Director.

  • show dip - Displays DIP pairings.

  • show real - Displays the real servers' statistics and states.

  • show statistics - Displays the real and virtual server statistics.

  • show syslog - Displays log messages to the syslog server.

  • show url - Displays connection information to the URLs.

The following is the output of the show version command:

localdirector#show version
LocalDirector 416 Version 4.2.1

The following is the output of the show configuration command:

localdirector#show configuration
Building configuration...
: Saved
: LocalDirector 416 Version 4.2.1
syslog output 23.7
no syslog console
enable password 000000000000000000000000000000 encrypted
hostname localdirector
no shutdown ethernet 0
no shutdown ethernet 1
shutdown ethernet 2
interface ethernet 0 auto
interface ethernet 1 auto
interface ethernet 2 auto
mtu 0 1500
mtu 1 1500
mtu 2 1500
multiring all
no secure 0
no secure 1
no secure 2
no ping-allow 0
no ping-allow 1
no ping-allow 2
ip address
route 1
arp timeout 30
no rip passive
rip version 1
failover ip address
no failover
failover hellotime 30
password 636973636f004661696c6f766572204e encrypted
snmp-server enable traps
snmp-server community public
no snmp-server contact
no snmp-server location
virtual is
real is
real is
direct-ip is
direct-ip is
url s2 302
url s1 302
bind s1
bind s2
link s2
link s1
: end

The following is the output of the show dip command:

localdirector#show dip
Direct IPs:
Virtual Real Conns State Predictor Slowstart 0 IS leastconns roundrobin* 0 IS leastconns roundrobin*

The following is the output of the show real command:

localdirector#show real
Real Machines:
No Answer TCP Reset DataIn
Machine Connect State Thresh Reassigns Reassigns Conns
(DIP) 1 IS 8 0 0 0
(DIP) 1 IS 8 0 0 0

The following is the output of the show statistics command:

localdirector#show statistics
Real Machine(s) Bytes Packets Connections
(DIP) 480 8 1
(DIP) 240 4 1
Virtual Machine(s) Bytes Packets Connections
(DIP) 480 8 1
(DIP) 240 4 1 10215 80 6

The following is the output of the show syslog command:

OUTPUT ON (23.7)
<189> July 2 13:07:40 LD-NOTICE Begin Configuration: reading from terminal
<189> July 2 13:07:45 LD-NOTICE End Configuration: OK
<186> July 2 13:08:00 LD-CRIT Switching '' 
from 'slowstart' to 'leastconns'
<186> July 2 13:10:25 LD-CRIT Switching '' 
from 'slowstart' to 'leastconns'
<186> July 2 13:10:41 LD-CRIT Switching '' 
from 'slowstart' to 'leastconns'

The following is the output of the show url command:

localdirector#show url
Id Connect Rcode State Url
s2 2 302 IS
s1 2 302 IS


There is currently no specific troubleshooting information available for this configuration.

Related Information

Updated: Jan 31, 2006
Document ID: 44124