Configuring Advanced Features

This chapter describes the following advanced configuration topics:

Parameters That Can be Configured in the Default DNS or in the Director

The following parameters can be configured either in the Director itself using the software command-line interface (CLI) or in the Director's default DNS server using ciscoDD DNS TXT records:

DRP-associations
Host-specific weights
Metric priorities
Server connection parameter
Administrative costs

Cisco recommends that when you configure these parameters, you perform all configurations in the same location; either in the Director or in the default DNS server.

Note Configuration information entered via the Director's command-line interface (CLI) overrides any configuration information retrieved from DNS TXT records found in the default DNS server.

Setting Metrics and the Server Connection Parameter

There are many criteria that the Director can use when choosing a server for a client. To collect information, the Director uses one or more of its built-in metrics. There are many different ways to put this information together to determine the "best" server. In addition, the server connection parameter helps the Director determine whether a server is operational. This section covers the following topics:

Types of Weight and Priority Metrics

Following are descriptions of metric options:

DRP-external metric (drp-ext n). Sends a DRP request to all DRP server agents, asking them for the BGP distance between them and the client originating the DNS query. This distance represents the number of BGP hops between the autonomous system of the DRP server agent and the autonomous system of the client originating the DNS query. Because this is BGP information, the DRP server agents need to have access to full Internet BGP information for this to be useful.
DRP-internal metric (drp-int n). Sends a DRP request to all DRP server agents, asking them for the IGP routing table metric value from themselves to the edge of their BGP autonomous system in the direction of the client originating the DNS query. This metric can be used along with the DRP external metric (drp-ext) to help determine the nearest service to the client originating the DNS query. Internet Service Providers (ISPs) might want to minimize this metric in an effort to keep external traffic off their network as much as possible. If the client and the DRP server agent are in the same autonomous system, this metric returns the IGP cost metric between the requesting client and the DRP server agent.
DRP-server metric (drp-ser n). Sends a DRP request to all DRP server agents, asking them for the IGP route metric between them and the distributed server(s) that they support. This distance can be used with the DRP-Internal metric in order to get a finer distance calculation between the distributed servers and edge of the BGP autonomous system in the direction of the client originating the Director query. If a true BGP border router is used as a DRP server agent, the DRP-server metric will return the IGP route metric between the distributed server and the BGP border router (autonomous system edge). ISPs might choose to minimize this metric to keep external traffic off their network backbones as much as possible (for example, a server closer to the autonomous system edge is preferred over a server farther from the autonomous system edge). Because DRP-server metrics should not change frequently, the Director issues DRP-server queries (and caches the results) every 10 minutes.
Administrative metric (admin n). Specifies a simple preference of one server over another. If the administrative metric has been explicitly set to zero, the Director will not consider the server, so the server is taken out of service. The administrative metric does not trigger DRP requests to the DRP server agents.
Random metric (random n). Selects a random number for each distributed server and defines the "best" server as the one with the smallest random number assignment. Using this metric by itself results in random redirection of clients to the distributed servers. Because this metric requires no routing table information, it does not trigger DRP requests to the DRP server agents.

You can give each of these metrics a weight value, a priority value, or both. You can use any combination of metrics and omit those you do not want to use.

Using Metrics

The following conditions apply to specifying metrics:

You can set metrics that apply to a group of distributed servers associated with a subdomain or host name.
You can specify default weights that apply to all distributed servers that the Director supports, unless a weight was specified for a specific subdomain or host name.
If you specify a weight value, a priority value, or both for a metric, the Director consideres the specified metric in its determination. The metric raw value is multiplied by the weight value (if specified) to obtain the weighted metric used to determine the server to provide to a client. Thus, the weight value can increase the importance of one metric over another. The distributed server with the smallest metric value is selected as the "best" server.

Note IGP metrics returned from different autonomous systems must be obtained from the same IGP and have the same scaling factor to be directly comparable.

The priority value tells the Director in what order to consider metrics when picking a server. If multiple servers end up with the same metric value, the next metric is considered to determine the "best" server. If multiple metrics have the same priority value, the metrics are added together to obtain a composite metric. For example, if two metrics have the same priority value, they are first multiplied by their weight values (if specified) and then added to form the composite metric.
If you do not specify weights for a group of metrics, and there are no default weights for those metrics, but you have specified priority values for them, the weight values for those metrics are set to 1.
Any metrics that have a nonzero weight and are assigned no priority value are set to a priority value of 101. They are considered after all other metrics that have priority values. As a result, if no priority values are specified for any metrics, metrics are treated additively to form one composite metric.
If you do not use priority and multiple servers have the same metric value, the last server IP address looked at will be returned as the "best" server. If you want to return a random IP address in the case of a tie, use the metric priority with the random metric as the last criterion.

See the "Sample Configurations" section for examples that demonstrate these principles.

Setting W eights

There are two ways that you can specify weight values for one or more metrics:

Default weights. Default weights apply to all servers supported by the Director. They take effect whenever there are no host-specific weights. They are configured using the ip director default-weights configuration command:

ip director default-weights {[drp-int n] [drp-ext n] [drp-ser n] [random n] [admin n]}

: To examine the default weights, use the show ip director default-weights command.

Host-specific weights. Host-specific weights apply to servers assigned to a specific virtual host name. For example, you would use host-specific weights if you wanted to use different metric weights for different virtual host names (for example, www.sleet.com and ftp.sleet.com). Host-specific weights are configured on the Director using the ip director host name weights command:

ip director host name weights {[drp-int n] [drp-ext n] [drp-ser n] [random n] [admin n]}

: If desired, host-specific weights can instead be configured on the Director's default DNS server. For example, you could configure host-specific weights with the following ciscoDD weights TXT record:

hostname in txt "ciscoDD: weights {[drp-int n] [drp-ext n] [drp-ser n] [random n] [admin n]}"

: When the associated metric is referenced in the sorting decision, it will always be multiplied by its metric weight, if specified. In this way, you can specify that some metrics have more influence than others. You can determine the weights you want to use through experimentation. The weights do not need to add to 100.
: To examine host-specific metric weights configured in the Director, use the show ip director host [hostname] command
: This command does not report host-specific information about hosts which were configured using TXT records. To see host-specific information, use the show hosts command, after the DNS TXT records have been loaded into the Director's cache.

Setting Metric Priority

Metric priority can be configured on the Director with the ip director host priority command:

ip director host name priority {[drp-int n] [drp-ext n] [random n] [admin n]}

If desired, metric priority can instead be configured on the Director's default DNS server using a ciscoDD priority TXT record. The full syntax of this TXT record is:

hostname in txt "ciscoDD: priority {[drp-int n] [drp-ext n] [drp-ser n] [random n] [admin n]}"

Metric priority must be configured explicitly.

Note If a metric uses priority but not a weight, the weight is assumed to be 1. So whenever you want to use priority only, you do not need to specify weights.

For example, you may want all clients to be assigned to the server that is closest to them according to the BGP hop count, and if two or more servers deterined to be "closest" are at the same BGP autonomous system hop distance, the choice should be according to administrative preference. This would be done by specifying the metric priority as follows:

ip director host www.sleet.com priority drp-ext 1 admin 2

or on the default DNS server:

www.sleet.com. in txt "ciscoDD: priority drp-ext 1 admin 2"

With this configuration, the DRP-external metric of all potential servers would first be compared (including the appropriate weights if specified and default weights otherwise). If there are two or more best choices, the administrative preference metrics would next be compared (again multiplying them by the appropriate weights). If, in this example, the administrative metrics once again appeared to be equivalent, the last server whose metric was looked at would be arbitrarily selected.

Setting Administrative Preferences

Administrative preferences are set with the following command on the Director:

ip director server [hostname | host-ip-address] preference [cost]

hostname or host-ip-address is the host name or IP address specification of the server, and cost is the metric value. This command overrides any other value for the administrative metric for this host. Specifying a cost of 0 (zero) removes this server from the list of available servers.

Specifying the Server Connection Parameter

The server connection parameter lets the Director empirically verify that a server is available and thus prevents the Director from redirecting clients to servers that cannot respond. To configure this parameter, specify the port number for making connections, and the minute interval for checking availability. When configured with this information, the Director establishes a connection to the server port once every configured minute interval. If the server is down, the Director cannot connect to it and will not direct clients to this server.

You can configure this parameter in three ways:

In the Director with the ip director host name connect port connection-interval command.
In the Director's default DNS server with ciscoDD DRP association (drp-assoc) TXT records:

subdomain-name. in txt "ciscoDD: drp-assoc distr-server-addr DRP-agent-addr port [connection-interval]"

: For example, this records tells the Director to try to connect to port 80 every 5 minutes:

www.sleet.com. in txt "ciscoDD: drp-assoc 11.0.0.2 11.0.0.3 80 5"

In the Director's default DNS server with the following ciscoDD server TXT record:

subdomain-name. in txt "ciscoDD: server distr-server-addr port# connection-interval"

: For example:

www.sleet.com. in txt "ciscoDD: server 11.0.0.2 80 5"

How the Director Uses the Server Connection Parameter

The Director will establish a TCP connection to the server and after being successful will end the connection, having determined the server is up. This metric may be used with or without DRP metrics. When this parameter is configured, the Director will attempt to create a TCP connection to each of the distributed servers on a configured port (for example, port 80 for HTTP servers) over a configurable time interval. Servers that yield unsuccessful TCP connection attempts will be marked as unavailable. Following a failed TCP connection, the Director will use a linear-backoff algorithm to create subsequent TCP connections to the server to determine when it is again available. This algorithm is used to smoothly handle changes in server or network availability.

What the algorithm does when the server connection is first unsuccessful

The initial connection trial to a server labeled "up" is done three times in rapid succession. If no connection is successful, the percentage confidence that the server is down is set to 10 percent. The retry interval is calculated as the configured interval multiplied by the confidence percentage with a minimum of 1 minute. Each successive connection attempt is done once, and each time the attempt is unsuccessful the confidence percentage is incremented by 10 percent until it reaches 100 percent.

For example, if you have configured the Director to create a TCP connection to port 80 on a certain server every 10 minutes to check server availability, and the TCP connection fails, the following scenario occurs:

(a) On the first retry after a successful connection, the Director will attempt to create a successful TCP connection three times in rapid succession before declaring a failure.

(b) If these three attempts are unsuccessful, the Director will remove this server from its list of viable choices (and from the Director per-client cache if it is there) to guarantee that no client will be redirected to this unresponsive server. (Note that this connection failure may result from a server failure or from network congestion.)

(c) Using its linear-backoff algorithm, the Director will scale the configured time interval to 10 percent (the confidence percentage, which is 1 minute in this example) and attempt to complete a TCP connection to the server 1 minute after the last attempt.

(d) If the connection again fails, the Director will scale the configured time interval to 20 percent (the confidence percentage, which is now 2 minutes) and attempt to complete a TCP connection to the server 2 minutes after the last attempt.

This procedure will continue until either 10 failures occur or the server yields a successful TCP connection. Either way, the Director will resume using the original configured time interval (the 100 percent confidence percentage scaling factor, which is 10 minutes in this example) when attempting TCP connections to a server. This algorithm is designed to quickly determine server availability following a failed TCP connection.

Note Although TCP connection state information may take up to 4 minutes to be cleared, TCP connection timeouts usually occur within about 30 seconds. As a result, the minimum configurable TCP connection time interval on the Director is 1 minute. The minimum retry interval in the Director's linear-backoff algorithm is also 1 minute.

Sample Configurations

This section contains simple and advanced examples of Director metrics configurations. For each example, specific criteria for metric configuration are stated, followed by the appropriate Director configuration command(s) and the ciscoDD DNS TXT record entries. Metrics should be configured either all in the Director using CLI commands, or all in the Director's default DNS server using ciscoDD DNS TXT records. Do not configure metrics in both locations.

DRP External Metrics Example

Metric Criteria

Use the DRP external metric to determine the best server.
Do not use TCP connections to verify the health of a server.

Command(s) in the Director	DNS TXT record in the Director's default DNS server
`DD(config)# ip director default-weights drp-ext 1` The weight value of 1 is arbitrary because there is just one metric.	`www.sleet.com. in txt "ciscoDD: weights drp-ext 1"`

If all servers return the same DRP external metric value, the last server whose metric was examined would be arbitrarily selected.

DRP External and Internal Metrics Example

Metric Criteria on Distributed HTTP Servers

Use a DRP external and internal composite metric to find the best server.
Make sure that users are directed to an operational server by performing TCP connection attempts every 5 minutes.

Command(s) in the Director	DNS TXT record in the Director's default DNS server
`DD(config)# ip director default-weights drp-ext 80 drp-int 10` The proper weights would need to be determined, perhaps through experimentation.	`www.sleet.com. in txt "ciscoDD: weights drp-ext 80 drp-int 10"`
The TCP connection parameter can be configured on the Director using the following command: `DD(config)# ip director host www.sleet.com connect 80 5`	Alternatively, you could configure this in the Director's default DNS server with the following ciscoDD drp-assoc TXT record: `www.sleet.com. in txt "ciscoDD: drp-assoc A.B.C.D W.X.Y.Z 80 5"`

Note The TCP connection parameter port number and connection-interval information should be configured on each ciscoDD drp-assoc TXT record.

One other configuration option for this example is to configure metrics in the server DNS TXT record separately, using an entry similar to the following:

www.sleet.com. in txt "ciscoDD: server A.B.C.D 80 5"

This record causes the Director to attempt a TCP connection to port 80 at IP addresses A.B.C.D every 5 minutes.

If you configure the TCP connect parameter, any server marked as "down" is removed from the list of valid servers, and is also removed from the Director per-client DRP cache, if it is there.

If all servers return the same composite metric, the last server whose metric was looked at is arbitrarily selected.

Multiple Priority Metrics Example

Metric Criteria

Use the DRP external metric as the primary factor to make the decision.
If all servers have the same DRP external metric value, make the decision based on the DRP internal metric as the secondary factor.
If all servers have the same DRP internal metric value, choose an operational server randomly as the last factor.

Command(s) in the Director	DNS TXT record in the Director's default DNS server
`DD(config)# ip director host www.sleet.com priority drp-ext 1 drp-int 2 random 3`	`www.sleet.com. in txt "ciscoDD: priority drp-ext 1 drp-int 2 random 3"`

This tells the Director to use the DRP external metric value to make the decision. If multiple servers have the same DRP external value, use the DRP internal metric value to make the decision. If multiple servers have the same DRP internal value, use the random metric value to make the decision. In this case, the Director picks a random number for each server and chooses the server with the lowest random metric as the "best" server. In the unlikely event that the random metric is the same for all servers, the last server whose metric was looked at would be arbitrarily be selected.

Remember that if a metric has a priority value but no weight value, the weight is set to 1. So in this example, you really do not need to specify weights at all.

To guarantee that each server is operational, you need to configure the TCP connect parameter as described previously for the other examples.

Note that in this example if the random metric had not been explicitly configured, the behavior would have been different. In that case, if there were ties for both the DRP external and internal metrics (which means that all servers are equal candidates), the Director would have returned the IP address of the server whose metric was last examined, instead of picking a random server.

Combined Weighted and Priority Metrics Example

Metric Criteria Using Default Weights

Use the DRP external and internal metrics together (as a composite metric) as the primary factor to choose the best server.
If all servers have the same composite metric value, pick an operational server using the random metric as the secondary factor.

This example requires weighting and priority, but is different than the last example because it uses a composite metric (a linear combination of several metrics) instead of a single metric for each decision point.

Command(s) in the Director	DNS TXT record in the Director's default DNS server
To set the default weights: `DD(config)# ip director default-weights drp-ext 80 drp-int 10 random 1` To set the metric priority: `DD(config)# ip director host www.sleet.com priority drp-ext 1 drp-int 1 random 2`	To set the default weights: `www.sleet.com. in txt "ciscoDD: weights drp-ext 80 drp-int 10 random 1"` To set the metric priority: `www.sleet.com. in txt "ciscoDD: priority drp-ext 1 drp-int 1 random 2"`

Notice the "1"s for both the DRP external and DRP internal metrics. This means that the primary factor for choosing the server is to take the linear combination of these metrics, which is (drp-ext * 80) + (drp-int * 10). If all servers have the same value, they are equally suitable. In this case, the priority record specifies that the random metric is the next factor to consider. The Director will randomly choose the best server. Again, you need to configure the TCP connect parameter to ensure that each server is operational.

Specifying a Time-to-Live Value on DNS Resource Records Returned by the Director

To specify a time-to-live (TTL) value, in seconds, to be placed on all DNS resource records issued by the Director, use the following command:

ip director ttl seconds

This command tells the end-user clients how long to keep DNS records received from the Director. In most situations, the default value of 0 seconds is appropriate in order to prevent local DNS caching.

Enabling and Disabling the Director's Per-Client DRP Metric Cache

The Director caches the sorting decision made and the requester's IP address each time it processes a query. This way, if a client repeats a request for a specific address within a specified caching time period, the Director can respond from the cache. This interval is configurable. The default Director caching interval is 1 minute, and is recommended for most environments.

The caching mechanism increases performance by reducing the amount of DRP querying to DRP server agents when answering client requests. With the caching functionality, the Director can answer a request from its own local memory instead of asking the DRP server agents for this information.

Use a long per-client caching value if you can assume that the state of the network is relatively static (for example, you do not expect it to change within the caching time interval).

To enable the Director cache (which is the default), use this command:

ip director cache

To disable the Director cache, use the no form of this command:

no ip director cache

To configure the Director's per-client DRP caching interval, use the following command:

ip director cache-time [seconds]

Setting Up Multiple Subdomains and Host Names

Multiple subdomains and host names can be configured on the Director in one of three possible scenarios:

All subdomains configured in DNS caching name server mode
All host names configured in HTTP session redirector mode
Some subdomains configured in DNS caching name server mode and some host names configured in HTTP session redirector mode

For example, if you wanted to set up a distributed FTP server called ftp.sleet.com and a distributed web (HTTP) server called www.sleet.com, you could configure the Director using the first or last methods listed. You cannot configure all host names in HTTP session redirector mode, because the distributed FTP server application requires the Director to be configured in DNS caching name server mode.

For ease of configuration management, we recommend that multiple subdomains be configured either in the Director or in the primary DNS server. For example, the configurations specifying weights, priorities, and so on for www.sleet.com and ftp.sleet.com should both be placed in either the Director or in the primary DNS server.

Note Remember that for DNS caching name server mode, ftp.sleet.com is treated as a subdomain name; for HTTP session redirector mode, www.sleet.com is treated as a host name. For simplicity, in some parts of this section a host name may be referred to as a subdomain name.

The sections that follow show how to configure these names:

ftp.sleet.com (distributed, mirrored FTP servers)
www.sleet.com (distributed, mirrored HTTP servers).

Configuring more than two subdomains and host names is simply an extension of the tasks given.

Configuring Two Subdomains in DNS Caching Name Server Mode

Configuring multiple subdomains in DNS caching name server mode involves setting up the Director as a name server that is authoritative for multiple subdomains.

Configuring the Director

Step 1 Configure the Ethernet interface, as described in the chapter "Configuring the Director Software Interfaces."

Step 2 Specify the primary DNS server to which the Director should send requests using the ip name-server DNS-server-IP-address global configuration command. DNS-server-IP-address is the IP address of the default DNS server (usually the primary domain's primary server).

Step 3 In the Director, add a Start of Authority (SOA) record that gives the Director authority for the subdomain:

ip dns primary domain soa primary contact [refresh retry expire minimum]

For example, the following command makes the primary DNS server authoritative for the www.sleet.com subdomain:

ip dns primary www.sleet.com soa dd.sleet.com sysadmin.sleet.com 21600 900 7776000 86400

The command shown tells the Director that it is the primary DNS server authoritative for the www.sleet.com domain, the DNS host name of the Director is dd.sleet.com, and the administrative contact for this zone is sysadmin@sleet.com. The refresh-interval (the time interval that must elapse between each poll of the primary by the secondary name server) is 6 hours, a retry-interval (the time interval used between successive connection attempts by the secondary to reach the primary name server in case the first attempt failed) is 15 minutes, the expire-ttl (the time interval after which the secondary expires its data if it cannot reach the primary name server) is 90 days, and a minimum-ttl (the minimum TTL value, which specifies how long other servers should cache data from the name server) is 1 day.

The values listed are suggested default values. You can configure the Director with the listed default values by simply using the ip dns primary domain soa primary contact command.

In our example, you would use:

ip dns primary www.sleet.com soa dd.sleet.com sysadmin.sleet.com

Note Although the Director can be configured as an authoritative DNS name server, it does not support zone transfers.

Step 4 Use the following commands to define the virtual host names to be used for the sets of distributed servers:

ip host name [tcp-port-number] address1 [address2 ...address8]

ip director host name

Step 5 Repeat Step 3 and Step 4 for the ftp.sleet.com domain name.

Configuring the sleet.com Primary DNS Server

Instead of placing one name server (NS) record on the sleet.com primary DNS server, you would use two. These NS records pass DNS authority for both subdomains to the Director. The single A record defines the IP address of the Director.

Here is an example of the configuration you would use for the sleet.com primary DNS server:

ftp.sleet.com. in ns dd.sleet.com.
www.sleet.com. in ns dd.sleet.com.
dd.sleet.com. in a 10.0.0.1

The first two records tell the sleet.com servers that the Director is the name server to which queries about the www.sleet.com and ftp.sleet.com subdomains must be directed. The third record says that the interface IP address for the Director is 10.0.0.1.

Note Be careful to include the period (.) at the end of each subdomain name located at the beginning of each resource record. It keeps named from trying to append the default subdomain name. The default subdomain is the subdomain associated with the database file in the named.boot file. Without the trailing period, the resolver would be confused by the expansion of the subdomain name to www.sleet.com.sleet.com.

Metric weights, priorities, DRP associations, and the server connection parameter are all configured as previously described, either in the Director or in the primary DNS.

Configuring Two Host Names in HTTP Session Redirector Mode

Configuring multiple host names in HTTP mode involves configuring the Director to listen to multiple IP addresses, with each address corresponding to a particular host name. The Director then redirects the client web browser to the appropriate real web server.

The descriptions that follow configure two web server host names (www1.sleet.com and www2.sleet.com) in HTTP session redirector mode.

Configuring the Director

Perform these steps to configure the Director.

Step 1 Configure the sleet.com primary DNS server as the default name server for the Director with this command:

ip name-server DNS-server-IP-address

The interface IP address of the Director is configured as described in the chapter "Configuring the Director Software Interfaces." For this example, the address is 10.0.0.1.

Step 2 Set up the Director to accept queries to the virtual HTTP server IP addresses for the host names. In this example, the following commands specify 10.0.0.4 and 10.0.0.5 as virtual addresses:

ip director ip-address 10.0.0.4
ip director ip-address 10.0.0.5

These IP addresses must be unused and on the same subnet as the interface IP address, 10.0.0.1 in this example.

The primary DNS server has pointer records (PTRs) that map virtual IP addresses to host names. The Director will identify any DNS requests received on IP addresses 10.0.0.4 and 10.0.0.5 as requests for the www1.sleet.com and www2.sleet.com host names, respectively.

Configuring the sleet.com Primary DNS Server

Recall that we wish to configure two web server host names, www1.sleet.com and www2.sleet.com. To do this, four resource records must begin the configuration of the sleet.com primary DNS server:

www1.sleet.com. in a 10.0.0.4
www2.sleet.com. in a 10.0.0.5
4.0.0.10.in-addr.arpa. in ptr www1.sleet.com. 
5.0.0.10.in-addr.arpa. in ptr www2.sleet.com.

These records tell the Internet the IP addresses associated with the host names www1.sleet.com and www2.sleet.com. This information can also be configured in the Director itself using the ip host command. Remember that reverse-mapping PTR records are required by the Director.

In addition, the sleet.com primary DNS server has the following resource records:

www1-servers.sleet.com. in a 20.0.0.2
	in a 21.0.0.2
	in a 22.0.0.3
www2-servers.sleet.com. in a 10.0.0.2
	in a 11.0.0.2
	in a 12.0.0.2

Another way to configure the primary DNS server is to bind the distributed server IP addresses to the virtual host name in the Director itself using the ip host command:

ip host new-virtual-hostname address1 [address2...address8]

For example:

ip host www1-servers.sleet.com 20.0.0.2 21.0.0.2 22.0.0.2
ip host www2-servers.sleet.com 10.0.0.2 11.0.0.2 12.0.0.2

In HTTP session redirector mode, the Director appends the string "-servers" to the first part of the host name, creating a new host name for querying the primary DNS server. In this example, this results in the creation of the host names www1-servers.sleet.com and www2-servers.sleet.com.

The distributed web servers in the www1.sleet.com host name have the IP addresses 20.0.0.2, 21.0.0.2, and 22.0.0.2. The Director will return one of these IP addresses as a result of an A query to the www1.sleet.com host name.

The distributed web servers in the www2.sleet.com host name have the IP addresses 10.0.0.2, 11.0.0.2, and 12.0.0.2. The Director will return one of these IP addresses as a result of a DNS "A" query to the www1.sleet.com host name.

Metric weights, priorities, DRP associations, and the server connection parameter are all configured as previously described, either in the Director or in the primary DNS.

How the Configuration Works

Following are the steps that show how the Director works with two host names in HTTP session redirector mode.

For the www1.sleet.com host name:

The client web browser tries to retrieve URL http://www1.sleet.com.
The Internet DNS system maps this name to 10.0.0.4 (the Director HTTP session redirector system).
The Director listens for connections to port 80 (the HTTP port) at IP address 10.0.0.4 (an IP address on the Director subnet that has been assigned for use by the HTTP session redirector system).
The Director sends a DNS PTR query for the host name associated with 10.0.0.4, then finds and caches the host name www1.sleet.com. This query is sent only when the host name information cannot be found in the Director local cache.
The Director now formulates a new host name by searching from the left-hand side of the returned host name for a period. When it finds the period, it places the text "-servers" just before it. The host name www1.sleet.com becomes www1-servers.sleet.com.
The Director then sends a DNS query for the IP addresses associated with the new host name www1-servers.sleet.com. This results in the normal Director sorting of addresses using all of the metrics configured for this host name. The Director selects the best server IP address for the client that requested the initial connection.
The Director then makes up the new URL that points to the real web server (for example, http://20.0.0.2) and sends the web client the code "302 Temporary Relocation," which specifies the new URL location.
The client web browser receives the temporary relocation code and retrieves the web page.

For the www2.sleet.com host name:

The client web browser tries to retrieve URL http://www2.sleet.com.
The Internet DNS system maps this name to 10.0.0.5 (the Director HTTP session redirector system).
The Director listens for connections to port 80 (the HTTP port) at IP address 10.0.0.5 (an IP address on the Director subnet that has been assigned for use by the HTTP session redirector system).
The Director sends a DNS PTR query for the host name associated with 10.0.0.5 and finds the host name www2.sleet.com. This query is sent only when the host name information cannot be found in the Director local cache.
The Director now formulates a new host name by searching from the left-hand side of the returned host name for a period. When it finds the period, it places the text "-servers" just before it. So the host name www2.sleet.com becomes www2-servers.sleet.com.
The Director then sends a DNS query for the IP addresses associated with the new host name www2-servers.sleet.com. This results in the normal Director sorting of addresses using all of the metrics configured for this host name. The Director selects the best server IP address to use for the client that requested the initial connection.
The Director constructs a new URL that points to the real web server (for example, http://10.0.0.2) and sends the web client the code "302 Temporary Relocation," which specifies the new URL location.
The client web browser receives the temporary relocation code and retrieves the real web page.

Configuring a Combination of Modes

In this example, the ftp.cisco.com subdomain is configured in DNS caching name server mode and the www.sleet.com host name in HTTP session redirector mode.

Configuring one subdomain in DNS caching name server mode and one host name in HTTP session redirector mode involves separately configuring them as described in the previous sections "Configuring Two Subdomains in DNS Caching Name Server Mode" and "Configuring Two Host Names in HTTP Session Redirector Mode."

Configuring the Director

Configure the Director as the authoritative name server using the ip dns primary command for the ftp.sleet.com domain as previously described in this chapter. Configure weights, priorities, DRP associations, and the server connection parameter either in the Director or in the primary DNS server (with TXT records) as previously described in this chapter.

Configure the virtual IP address for the www.sleet.com domain using the ip director ip-address command. Configure weights, priorities, DRP associations, and the server connection parameter either in the Director or in the primary DNS server (with TXT records).

Configuring the sleet.com Primary DNS Server

For the ftp.sleet.com domain (which will be serviced in DNS mode), add the following NS records to the sleet.com primary DNS server:

ftp.sleet.com. in ns dd.sleet.com.
dd.sleet.com. in ns w.x.y.z

where w.x.y.z is the IP address of the Director's network interface. These records indicate that the Director is the authoritative name server for the ftp.sleet.com domain.

For the www.sleet.com domain (which will be serviced in HTTP redirect mode), add the following A and PTR records to the sleet.com primary DNS server:

www.sleet.com. in a a.b.c.d
d.c.b.a.in-addr.arpa. in ptr www.sleet.com.
www-servers.sleet.com. in a p1.q1.r1.s1
www-servers.sleet.com. in a p2.q2.r2.s2
www-servers.sleet.com. in a p3.q3.r3.s3

The first A record defines the virtual IP address (a.b.c.d) to be used for all HTTP requests for the www.sleet.com domain name. This IP address must be on the same subnet as that of the Director's network interface.

The second resource record provides a means for the Director to translate the virtual IP address to the requested domain name.

The remaining A records are used to define the IP addresses of the distributed web servers for which Director processing is required.

Table of Contents