Cisco DistributedDirector

Document ID: 22148

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Function and Purpose of the DistributedDirector
      Why use a DistributedDirector?
      What will a DistributedDirector Do?
Starting with a Brand-New Router or a Router with a Default Configuration
      Hardware Requirements
      Software Requirements
      Initial Configuration
Adding the Necessary Components to Answer DNS Queries with no Particular Address
      Basic Distributed Director Configuration
      Behavior
      Configuration
Adding the Necessary Changes to Give a Specific Percentage of Answers to Each Server
      Sharing Traffic
      Behavior
      Configuration
Adding the Necessary Components to Answer DNS Queries with One of Two Primary Servers Using a Third Server as a Backup
      Primary / Backup Service Configuration
      Behavior
      Configuration
Adding the Use of Routing Information to Select Servers Nearest the User
      Routing Tables to Find the Best Site (DRP-E, DRP-I)
      Configuring the DRP Server Agent on a Router
      Distributed Director Configuration
      DRP Router Configuration
Adding the Use of Round-Trip-Time Probes to Find the Server with the Shortest Route-Trip-Time
      Round-Trip-Time Probes to Find the Best Server (DRP-R)
      What is the DRP-R Probe?
      Configuration
HTTP Redirection to an Appropiate Server
      HTTP Redirects
      What is Required?
      Configuration
Related Information

Introduction

This document provides a step-by-step overview of a DistributedDirector configuration, each section building upon that of the last, until a full understanding of the operation and configuration of the equipment has been attained.

After reading this document, you should have a strong understanding of these DistributedDirector functions:

• Splitting traffic proportionally between several servers.

• Sending users to the server closest to them (according to routing information).

• Sending users to the server with the fastest round-trip-time response.

Given that each section builds upon the concepts discussed in the previous section, it is recommended that you read this document in order.

Prerequisites

Requirements

Readers of this document should have knowledge of these topics:

• Basic Cisco IOS® configuration (how to enter, remove, and save commands)

• Domain Name System-Start of Authority (DNS - SOA) records and their values

• DNS-Name Server (NS) records for delegating a subdomain

• DNS - Address records (A records )

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Function and Purpose of the DistributedDirector

Why use a DistributedDirector?

As your business grows, and the functions your servers provide become more critical, it is important to duplicate the function of the servers, in a separate location, to ensure continuous operation. This provides several key benefits:

• Scalability — Duplicate servers allow for an increase in the number of users able to access the service at any one time. Every time a server is added to the farm, the number of users that can be served increases incrementally. This can be done at a single location, or across multiple locations. At a single location, load balancing products, such as the Cisco LocalDirector or Cisco Content Services Switch (CSS) can be implemented. If your servers span multiple locations, DistributedDirector would be the product of choice. It is important to note that the DistributedDirector can be used in conjunction with the aforementioned load-balancing products.

• Redundancy — Installing duplicate servers in multiple locations protects your business from local issues, such as power-failure, network-outage, and natural-disaster. All of these are considerations that need to be addressed as your business grows. DistributedDirector can detect an unreachable service and instead, send users to one that is available

• Efficiency — By providing geographically dispersed servers, users of the service can select a server that is nearest them. For example, if you conduct business in the UK, Australia, and the United States, you can provide customers in each region better service if you direct them to a server in their region.

What will a DistributedDirector Do?

DistributedDirector will do one of these two things:

1. Answer DNS queries.

2. Respond with an HTTP 302 redirect message for an HTTP query.

DistributedDirector will return an A record for a specific DNS subzone. By returning the address of a server that has been found to be reachable, you can prevent problems with servers that are out of service. Provided that you have access to routers near the servers, you can return the address of a server that is topologically close to the user wishing to use the service.

Using the same selection criteria as for DNS responses, you can issue an HTTP 302 redirect response, sending users to an appropriate server. Follow the instructions provided in the sections below.

Starting with a Brand-New Router or a Router with a Default Configuration

Hardware Requirements

DistributedDirector software runs on a limited number of Cisco routers. Initially, the software ran only on the Cisco 2500 series (specifically 2501 and 2502) and the Cisco 4000. As of March 2001, support was widened to include these platforms:

• Cisco 2500 **

• Cisco 2600

• Cisco 3600

• Cisco 4500 **

• Cisco 7200

Note: ** The Cisco 2500 and Cisco 4500 will continue to have dedicated DistributedDirector software designated by the -w3- feature-set.

Software Requirements

DistributedDirector software is based on Cisco IOS. DistributedDirector functionality in IOS started with the 11.1IA train, followed by 12.1 and 12.1(T), all of which supported only the Cisco 2500 and Cisco 4500 router platforms. With these versions, other IOS functionality on DistributedDirectors is generally ignored and not supported.

With the release of IOS 12.2(1)T, the DistributedDirector functionality became available in the Enterprise Plus feature-set for the routers listed above (except Cisco 2500 and Cisco 4500). This indicates that the other IOS functions are now recognized, and that the DistributedDirector functionality can be used in addition to such features. You should make a careful evaluation of the platform performance and implementation requirements before attempting to use DistributedDirector functions on a router currently performing other duties.

Initial Configuration

On startup and initial configuration, your router output should look similar to this sample.

Note: If the router already has an existing configuration, issue the write erase command to return the router to the default configuration.

System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1) 
Copyright (c) 1999 by cisco Systems, Inc. 
TAC:Home:SW:IOS:Specials for info 
C2600 platform with 65536 Kbytes of main memory 

program load complete, entry point: 0x80008000, size: 0xc04e84 

Self decompressing the image : ################################ 
############################################################### 
############################################################### 
############################################################### 
######################################################## [OK] 

Smart Init is enabled 
smart init is sizing iomem 
ID MEMORY_REQ TYPE 
000092 0X000B9D00 C2600 Dual Ethernet 
000024 0X00019950 Four port Async/Sync 
0X000F34A8 public buffer pools 
0X00211000 public particle pools 
TOTAL: 0X003D7AF8 

If any of the above Memory Requirements are 
"UNKNOWN", you may be using an unsupported 
configuration or there is a software problem and 
system operation may be compromised. 
Rounded IOMEM up to: 4Mb. 
Using 6 percent iomem. [4Mb/64Mb] 

Restricted Rights Legend 

Use, duplication, or disclosure by the Government is 
subject to restrictions as set forth in subparagraph 
(c) of the Commercial Computer Software - Restricted 
Rights clause at FAR sec. 52.227-19 and subparagraph 
(c) (1) (ii) of the Rights in Technical Data and Computer 
Software clause at DFARS sec. 252.227-7013. 

cisco Systems, Inc. 
170 West Tasman Drive 
San Jose, California 95134-1706 



Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-JSX-M), Experimental Version 12.2(20010117:234426) 
   [mdavison-FLT_011701 106] 
Copyright (c) 1986-2001 by cisco Systems, Inc. 
Compiled Wed 17-Jan-01 19:20 by mdavison 
Image text-base: 0x80008088, data-base: 0x81570CD4 

cisco 2611 (MPC860) processor (revision 0x203) with 61440K/4096K bytes of memory. 
Processor board ID JAD045103AB (3449430142) 
M860 processor: part number 0, mask 49 
Bridging software. 
X.25 software, Version 3.0.0. 
SuperLAT software (copyright 1990 by Meridian Technology Corp). 
TN3270 Emulation software. 
Basic Rate ISDN software, Version 1.1. 
2 Ethernet/IEEE 802.3 interface(s) 
2 Serial(sync/async) network interface(s) 
4 Low-speed serial(sync/async) network interface(s) 
1 ISDN Basic Rate interface(s) 
32K bytes of non-volatile configuration memory. 
16384K bytes of processor board System flash (Read/Write) 


--- System Configuration Dialog --- 

Would you like to enter the initial configuration dialog? [yes/no]: no 


Press RETURN to get started! 

00:00:37: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up 
00:00:37: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up 
00:00:37: %LINK-3-UPDOWN: Interface Serial0/0, changed state to down 
00:00:37: %LINK-3-UPDOWN: Interface Serial0/1, changed state to down 

00:00:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up 
00:00:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down 
00:00:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down 
00:00:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down 
00:04:59: %SYS-5-RESTART: System restarted -- 
Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-JSX-M), Experimental Version 12.2(20010117:234426) 
   [mdavison-FLT_011701 106] 
Copyright (c) 1986-2001 by cisco Systems, Inc. 
Compiled Wed 17-Jan-01 19:20 by mdavison 

Router>
Router> 
Router>show version



!--- The show version command provides information on the current 
!--- version of code on the device, as well as the hardware configuration.


Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-JSX-M), Experimental Version 12.2(20010117:234426) 
   [mdavison-FLT_011701 106] 
Copyright (c) 1986-2001 by cisco Systems, Inc. 
Compiled Wed 17-Jan-01 19:20 by mdavison 
Image text-base: 0x80008088, data-base: 0x81570CD4 

ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1) 

Router uptime is 7 minutes 
System returned to ROM by reload 
System image file is "flash:c2600-jsx-mz" 

cisco 2611 (MPC860) processor (revision 0x203) with 61440K/4096K bytes of memory. 
Processor board ID JAD045103AB (3449430142) 
M860 processor: part number 0, mask 49 
Bridging software. 
X.25 software, Version 3.0.0. 
SuperLAT software (copyright 1990 by Meridian Technology Corp). 
TN3270 Emulation software. 
Basic Rate ISDN software, Version 1.1. 
2 Ethernet/IEEE 802.3 interface(s) 
2 Serial(sync/async) network interface(s) 
4 Low-speed serial(sync/async) network interface(s) 
1 ISDN Basic Rate interface(s) 
32K bytes of non-volatile configuration memory. 
16384K bytes of processor board System flash (Read/Write) 

Configuration register is 0x2102 

Router> 
Router>enable
Router#show run



!--- The show run command displays the current running configuration, 
!--- which, in this case, will be a blank (or default) configuration.


Building configuration... 

Current configuration : 1070 bytes 
! 
version 12.2 
no service single-slot-reload-enable 
service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 
hostname Router 
! 
logging rate-limit console 10 except errors 
! 
! 
! 
ip subnet-zero 
! 
! 
no ip finger 
! 
no ip dhcp-client network-discovery 
no mgcp timer receive-rtcp 
call rsvp-sync 
! 
! 
! 
! 
! 
! 
! 
! 
interface Ethernet0/0 
no ip address 
shutdown 
half-duplex 
! 
interface Serial0/0 
no ip address 
shutdown 
no fair-queue 
! 
interface BRI0/0 
no ip address 
shutdown 
! 
interface Ethernet0/1 
no ip address 
shutdown 
half-duplex 
! 
interface Serial0/1 
no ip address 
shutdown 
! 
interface Serial1/0 
no ip address 
shutdown 
! 
interface Serial1/1 
no ip address 
shutdown 
! 
interface Serial1/2 
no ip address 
shutdown 
! 
interface Serial1/3 
no ip address 
shutdown 
! 
ip kerberos source-interface any 
ip classless 
ip http server 
! 
! 
! 
! 
snmp-server packetsize 4096 
snmp-server manager 
! 
dial-peer cor custom 
! 
! 
! 
! 
gatekeeper 
shutdown 
! 
! 
line con 0 
transport input none 
line aux 0 
line vty 5 15 
! 
no scheduler allocate 
! 
end 

Router#config terminal



!--- The config terminal command allows you to enter configuration mode,
!--- so that you can proceed with configuring the device.


Enter configuration commands, one per line. End with CNTL/Z. 
Router(config)#hostname dd2600


!--- Set the host name for the device.


dd2600(config)#enable password letmein


!--- Set the enable password.


dd2600(config)#interface Ethernet0/0
dd2600(config-if)#ip address 172.17.63.102 255.255.255.224
dd2600(config-if)#no shutdown
dd2600(config-if)#exit


!--- Set the IP address for the Ethernet 0/0 interface.
 

dd2600(config)#ip route 0.0.0.0 0.0.0.0 172.17.63.97


!--- Set the default route.


dd2600(config)#line con 0
dd2600(config-line)#password letmein
dd2600(config-line)#line vty 0 133
dd2600(config-line)#password letmein
dd2600(config-line)#end


!--- Set passwords for console and Telnet for additional security.


dd2600# 
00:11:37: %SYS-5-CONFIG_I: Configured from console by console 
00:11:39: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up 
00:11:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up

In the sections that follow, the address configuration of the other interfaces is provided.

Adding the Necessary Components to Answer DNS Queries with no Particular Address

Basic Distributed Director Configuration

In basic mode, the DistributedDirector will hold a list of IP addresses for which it will return a subdomain name.

ip host www.devon.com 192.168.1.5 172.16.1.5 10.3.4.5

DistributedDirector will also be authoritative for the subdomain www.devon.com.

Note:  The name server for devon.com must already have NS record entries delegating the subdomain www.devon.com to the DistributedDirector at 172.17.63.102.

ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com

When a DNS query requesting an A record for www.devon.com is received, the DistributedDirector needs to know how to determine which of the three possible addresses it should return. To make that decision as simple as possible, you can randomly select a server address. Although random is given a priority of 20, given that it is the only metric listed, it will be the method of choice. The default weight for all metrics is one.

ip director hosts www.devon.com priority random 20

In order to ensure that you direct requests only to available servers, add a connect test to verify that the server is running. The test is a TCP handshake on the specified port (80 in this example) that will be immediately reset by the DistributedDirector.

Note: For testing purposes, you may want to leave out the connect test until you actually have a server at those addresses.

ip director hosts www.devon.com connect 80 interval 300

Unless otherwise specified, each query is cached for one minute. Subsequent requests from a DNS server during that time will be answered from the cache. You may wish to turn that cache off to evenly balance your answers to the DNS requests, particularly when using the portion metric that will be discussed in the following section.

no ip director cache

Behavior

Each DNS A record query to the 172.17.63.102 address for www.devon.com will get one of three addresses as an answer. Those addresses are 192.168.1.5, 172.16.1.5, and 10.3.4.5. The address received will be randomly selected.

% /bin/nslookup
> server 172.17.63.102
Default Server: dd2600.devon.com
Address: 172.17.63.102

> www.devon.com
Name: www.devon.com
Address: 192.168.1.5

> www.devon.com
Name: www.devon.com
Address: 192.168.1.5

> www.devon.com
Name: www.devon.com
Address: 10.3.4.5

> www.devon.com
Name: www.devon.com
Address: 192.168.1.5

> www.devon.com
Name: www.devon.com
Address: 10.3.4.5

> www.devon.com
Name: www.devon.com
Address: 192.168.1.5

Configuration

ip host www.devon.com 192.168.1.5 172.16.1.5 10.3.4.5 
! 
ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com 21600 900 7776000 86400 
! 
no ip director cache 
ip director hosts www.devon.com priority ran 20 
ip director hosts www.devon.com connect 80 interval 300 
!


!--- Notice how the DistributedDirector added default values to the SOA, and 
!--- how it abbreviated random on the priority line.

Adding the Necessary Changes to Give a Specific Percentage of Answers to Each Server

Sharing Traffic

One of the most common uses of the DistributedDirector is to divide the traffic directed to the servers in some regular fashion. This is simply a process of assigning a portion size to each server in your list, and specifying that you wish to use the portion as the deciding factor when choosing an A record to return. In this example, three out of five connections will be directed to one server, and one out of five requests will go to each of the other two servers.

ip director server 192.168.1.5 portion 1
ip director server 172.16.1.5 portion 3
ip director server 10.3.4.5 portion 1
ip director hosts www.devon.com priority portion 15

Behavior

You should see that out of every five connections, three will get the same address and the other to requests will get different responses. To find the percentage of traffic directed to any server, use the portion as the numerator and the sum of all portions as the denominator. This does not guarantee any specific pattern in the distribution, which is why very large portion values (50+) should be avoided.

% /bin/nslookup
> server 172.17.63.102
Server: dd2600.devon.com
Address: 172.17.63.102

> www.devon.com
Name: www.devon.com
Address: 172.16.1.5

> www.devon.com
Name: www.devon.com
Address: 192.168.1.5

> www.devon.com
Name: www.devon.com
Address: 10.3.4.5

> www.devon.com
Name: www.devon.com
Address: 172.16.1.5

> www.devon.com
Name: www.devon.com
Address: 172.16.1.5

> www.devon.com
Name: www.devon.com
Address: 10.3.4.5

> www.devon.com
Name: www.devon.com
Address: 172.16.1.5

> www.devon.com
Name: www.devon.com
Address: 192.168.1.5

> www.devon.com
Name: www.devon.com
Address: 172.16.1.5

> www.devon.com
Name: www.devon.com
Address: 172.16.1.5

Note that the 10.3.4.5 address was returned twice in less than five responses. This behavior may be new to 12.2 code, however, the two servers with a portion of one each take turns having their extra announcement out of turn. From looking at the output, the ratio is always correct for ten queries (or more).

Configuration

! 
ip host www.devon.com 192.168.1.5 172.16.1.5 10.3.4.5 
! 
ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com 21600 900 7776000 86400 
! 
no ip director cache 

ip director server 192.168.1.5 portion 1 
ip director server 172.16.1.5 portion 3 
ip director server 10.3.4.5 portion 1 
ip director hosts www.devon.com priority ran 20 por 15 
ip director hosts www.devon.com connect 80 interval 300 
! 


!-- Note that even though the portion command was entered on a line by itself, 
!--- the configuration just added it to the existing priority line.

Adding the Necessary Components to Answer DNS Queries with One of Two Primary Servers Using a Third Server as a Backup

Primary / Backup Service Configuration

Another common use of the DistributedDirector is to allow a hot-standby server to automatically be used if a primary server(s) fails. You can accomplish this by assigning preferences to each server, then specify that you wish to use this preference at the appropriate point in the decision making process. In this example, 192.168.1.5 and 172.16.1.5 are used as the primary servers. Users are sent to 10.3.4.5 only if they are not responding.

Note: The decision between which primary server is selected is proportional, as defined in the previous example.

ip director server 192.168.1.5 preference 3
ip director server 172.16.1.5 preference 3
ip director server 10.3.4.5 preference 5

ip director hosts www.devon.com priority admin 10

Behavior

% /bin/nslookup 
> server 172.17.63.102
Server: 172.17.63.102
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 192.168.1.5 
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 192.168.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 192.168.1.5 
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 172.16.1.5
> www.devon.com
Address: 192.168.1.5

Configuration

! 
ip host www.devon.com 192.168.1.5 172.16.1.5 10.3.4.5 
! 
ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com 21600 900 7776000 86400 
! 
no ip director cache 
ip director server 192.168.1.5 preference 3 
ip director server 192.168.1.5 portion 1 
ip director server 172.16.1.5 preference 3 
ip director server 172.16.1.5 portion 3 
ip director server 10.3.4.5 preference 5 
ip director server 10.3.4.5 portion 1 
ip director hosts www.devon.com priority ran 20 por 15 admin 10 
ip director hosts www.devon.com connect 80 interval 300 
! 

Adding the Use of Routing Information to Select Servers Nearest the User

Routing Tables to Find the Best Site (DRP-E, DRP-I)

In order to quickly find which server is closest to a client, you can use routing tables. This assumes (often incorrectly) that the client is close to the DNS-proxy server they are using. Hence, if you select a router that you know is near your servers, you can make a query to that router, have it do a routing table lookup, and return the distance (routing metric) to the client. These queries work with the via the Director Response Protocol (DRP).

The remote router needs to have the DRP Server Agent configured, and you need to configure the associations between the DRP server and the server that your client is trying to reach. Each time a DNS query is made to the DistributedDirector, the DistributedDirector will make a DRP query to each of the DRP servers, and compares the metrics returned to select the server that is closest to your client.

ip director server 192.168.1.5 drp-association 192.168.1.1
ip director server 172.16.1.5 drp-association 172.16.1.1
ip director server 10.3.4.5 drp-association 10.3.4.1

ip director hosts www.devon.com priority drp-i 3 drp-e 5

Each DRP query that is made will return the routing metric specific to the request, either the exterior routing metric (the BGP AS hop count), or the interior routing metric (IGRP or EIGRP routing metric). Thus, you can decide if one metric is more important than the other, and consider the metrics in appropriate order.

In the example above, first consider the interior routing metric, and if you have two or more servers that have the same internal distance, consider the exterior routing metric for those two or more servers to break the tie. On the Internet today, there are often many ties on the drp-e metric calculation, and so some subsequent tie breaker should be selected. Typically, a portion metric is a good choice.

It is also important to consider the drp-s metric. This is the routing metric between the DRP Server Agent router and the server itself. This is useful only if the distance between the nearest router that is capable of DRP and the server is different at any of the sites. Typically, you see the DRP Server Agents and the servers on the same network or only one hop away, and it is consistent from site to site.

Configuring the DRP Server Agent on a Router

You need to enable the router to answer the queries from the DistributedDirector. This is simply a matter of adding the ip drp server global configuration command:

You may want to consider restricting the DRP queries to your router. Queries can be restricted via a standard access-list, and/or by using authentication. The access-list is very simple, and only requires configuration of an access-list on the DRP Server Agent router, as well as the ip drp access-group access-list-number command to enable the access-list.

Authentication requires configuring both the DistributedDirector and the DRP Server Agents with a keychain and keys.

Distributed Director Configuration

! 
ip host www.devon.com 192.168.1.5 172.16.1.5 10.3.4.5 
! 
ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com 21600 900 7776000 86400 
! 
no ip director cache 
ip director server 192.168.1.5 preference 3 
ip director server 192.168.1.5 portion 1 
ip director server 192.168.1.5 drp-association 192.168.1.1 
ip director server 172.16.1.5 preference 3 
ip director server 172.16.1.5 portion 3 
ip director server 172.16.1.5 drp-association 172.16.1.1 
ip director server 10.3.4.5 preference 5 
ip director server 10.3.4.5 portion 1 

ip director server 10.3.4.5 drp-association 10.3.4.1 
ip director hosts www.devon.com priority ran 20 por 15 admin 10 drp-i 3 drp-e 5 
ip director hosts www.devon.com connect 80 interval 300 
!

DRP Router Configuration

Config: (DRP router)
! 
ip drp server 
! 


!--- Note that the DRP router should have BGP and EIGRP (or IGRP) configured 
!--- so that you can use the routing tables.

Adding the Use of Round-Trip-Time Probes to Find the Server with the Shortest Route-Trip-Time

Round-Trip-Time Probes to Find the Best Server (DRP-R)

Often a stronger measurement of which site is best is necessary. Also, it is not always possible to have access to a router which holds all the necessary routing tables. The DRP-R metric uses the same DRP Server Agent as described in the previous section, however, rather than doing a lookup in the routing table, the DRP Server Agent will send a probe to the client and measure the round-trip-time to determine the distance to the client. This probe is a very accurate measurement of network distance between the server and the clients DNS-proxy server. It is important to note that the actual client may not be anywhere near its DNS-proxy server. The only line that is different from the prior configuration would be ip director hosts www.devon.com priority drp-r 7.

There may be circumstances where you wish to combine the routing metrics with the round-trip-time measurement. If so, the round-trip-time measurement will be performed only after the routing metric lookups, due to the fact that the round-trip-time measurement takes significantly longer than the table lookups.

One caveat to note here is that DistributedDirector releases prior to 12.x(y)T wait for all measurements and lookups to complete prior to returning an answer, regardless of the results of higher priority metrics. For example, if you know instantly that you prefer one server based on a drp-i metric, you will still wait until the drp-r metric is returned, even though you ignore that response. Another enhancement is the maximum time you will wait before giving a response. Refer to the documentation on the ip director drp timeout commands.

What is the DRP-R Probe?

The DRP probe is a TCP SYN-ACK packet that is sent to the client's DNS-proxy server. The DNS-proxy receives a SYN-ACK, yet never sent a SYN to this server, so it sends a Reset (RST) to shut down the illegitimate connection. Once the RST packet is received, the DRP server now knows the round-trip-time. The probe is initiated with a destination port of 53, however, the probe port can be configured on the DRP Server Agent, using one or two of these commands:

ip drp rttprobe sourceport static port-number
ip drp rttprobe sourceport dynamic 
ip drp rttprobe destination port port-number

You can also configure a tolerance and the number of probes sent. Tolerance allows you to select servers that are nearly as close as another. This is implemented by receiving the DRP response, and those that are within the tolerance percent of the minimum round-trip-time are considered to be tied for this metric. The defaults are 10% tolerance and three probes. You can increase the tolerance to 15% and send five probes by doing this configuration on the DistributedDirector:

ip director host name drp-rtt tolerance 15
ip director host name drp-rtt probes 2

Configuration

! 
ip host www.devon.com 192.168.1.5 172.16.1.5 10.3.4.5 
! 
ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com 21600 900 7776000 86400 
! 
no ip director cache 
ip director server 192.168.1.5 preference 3 
ip director server 192.168.1.5 portion 1 
ip director server 192.168.1.5 drp-association 192.168.1.1 
ip director server 172.16.1.5 preference 3 
ip director server 172.16.1.5 portion 3 
ip director server 172.16.1.5 drp-association 172.16.1.1 
ip director server 10.3.4.5 preference 5 
ip director server 10.3.4.5 portion 1 
ip director server 10.3.4.5 drp-association 10.3.4.1 
ip director hosts www.devon.com priority ran 20 por 15 admin 10 drp-i 3 drp-e 5 drp-r 7 
ip director hosts www.devon.com connect 80 interval 300 

ip director hosts www.devon.com drp-rtt tolerance 15 
ip director hosts www.devon.com drp-rtt probes 2 
!

HTTP Redirection to an Appropiate Server

HTTP Redirects

As previously mentioned, selecting a server based on network-distance to a DNS-proxy server is less than ideal. If a client machine is configured to use a DNS-proxy server that is topologically far away from itself, the DNS distances may be significantly different to that of the actual distance you wish to measure. The solution to this is to have the client machine attempt to make a connection to the DistributedDirector. Once an HTTP connection is made to the DistributedDirector, you can determine the best server, and send a HTTP-redirect to the IP address of the best server for that client. The potential problem with this is the fact that now the IP address of the best server is displayed as the URL for the site. This can be accommodated by actually giving each site a unique name, and redirecting the client to that unique-site-specific name.

What is Required?

DistributedDirector needs to become an HTTP server, and listen on port 80 for a specific IP address.

ip director ip-address 172.17.63.98

This address will now be the one entered for the generic site name (for example, www.devon.com) in the primary DNS server, unlike the previous configurations, where the sub-domain www.devon.com was delegated to the DistributedDirector. There is no problem if that domain has already been delegated to the DistributedDirector because you will have both the SOA and the A records configured.

ip host www.devon.com 172.17.63.98
ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com

At this point, you need to specify the servers to which you wish to redirect the connections. The name of this group of servers will be derived by adding the string -severs to the host name portion of the FQDN you created for that IP address. You must also be the SOA for that new sub-domain, however, it will never be known outside this device.

ip host www-servers.devon.com 192.168.1.5 172.16.1.5 10.3.4.5
ip dns primary www-servers.devon.com soa dd2600.devon.com dheron.devon.com

From this point on, configure everything as though you were doing DNS mode responses for the subdomain www-servers.devon.com.

In order to keep a neat URL, you can specify the hostnames for each site.

ip director server 192.168.1.5 server-name server1.devon.com
ip director server 172.16.1.5 server-name server2.devon.com
ip director server 10.3.4.5 server-name server3.devon.com

Configuration

! 

ip host www.devon.com 172.17.63.98
ip host www-servers.devon.com 192.168.1.5 172.16.1.5 10.3.4.5 
! 

ip dns primary www.devon.com soa dd2600.devon.com dheron.devon.com 21600 900 7776000 86400 
ip dns primary www-servers.devon.com soa dd2600.devon.com dheron.devon.com 
! 
! 
no ip director cache 
ip director ip-address 172.17.63.98
ip director server 192.168.1.5 portion 1 
ip director server 192.168.1.5 drp-association 192.168.1.1
ip director server 192.168.1.5 server-name server1.devon.com
ip director server 172.16.1.5 portion 3 
ip director server 172.16.1.5 drp-association 172.16.1.1
ip director server 172.16.1.5 server-name server2.devon.com
ip director server 10.3.4.5 portion 1 
ip director server 10.3.4.5 drp-association 10.3.4.1
ip director server 10.3.4.5 server-name server3.devon.com
ip director hosts www-servers.devon.com priority drp-i 3 drp-e 5 drp-r 7 por 15 ran 20 
ip director hosts www-servers.devon.com connect 80 interval 300 
!

Related Information

• DistributedDirector Product Support
• DistributedDirector Software Download Page (registered customers only)
• Technical Support - Cisco Systems