Overview of the Cisco DistributedDirector 2500 Series
This chapter provides an overview of the Cisco DistributedDirector 2500 Series in the following sections:
•Cisco DistributedDirector Services
•DNS Caching Name Server Mode
•HTTP Session Redirector Mode
•DRP Security Features
Cisco DistributedDirector Services
The Cisco DistributedDirector 2500 Series (called the Director throughout this guide) is a device that efficiently distributes Internet services among topologically dispersed servers on the Internet or an intranet. It provides scalable, transparent, and network-intelligent traffic load distribution.
Using the Director Response Protocol (DRP), a simple User Datagram Protocol (UDP)-based application developed by Cisco, the Director can query properly configured Cisco routers in the field for Exterior Gateway Protocol (EGP) and Internal Gateway Protocol (IGP) topological "distance" metrics. With this information and other configuration metrics, the Director can assign an optimal distributed server to each client. As a result, users can be transparently and automatically assigned a distributed server anywhere on the Internet.
In addition to the Director device, the following equipment participates in the Director system:
•A Cisco router for each distributed server. The router should be topologically close to the server, have full Border Gateway Protocol (BGP) or IGP tables (or both), and be configured as a DRP server agent, which has DRP enabled. A DRP server agent can support more than one server.
•One or more Domain Name System (DNS) servers, depending on the mode you use to configure the Director.
The Director can operate in two modes: DNS caching name server mode or HTTP session redirector mode. Distributed servers are assigned to a subdomain or host name that is serviced by the Director. The Director can support multiple subdomains and host names that are configured separately, and they can use different modes.
DNS Caching Name Server Mode
In DNS caching name server mode, the Director acts as the DNS caching name server for a specific subdomain. Here is how a request can be serviced (see ):
1 A client requests a named service that triggers a DNS resolve—for example, asking for the IP address associated with the host name www.sleet.com.
2 The client's local DNS server issues a recursive DNS request for the IP address associated with www.sleet.com.
3 The primary DNS server for the sleet.com domain receives the request. The primary DNS server refers the client's local DNS server to the Director as the authoritative name server for the www.sleet.com subdomain.
4 The client's local DNS server queries the Director for the IP address associated with www.sleet.com.
5 The Director receives the query and performs an internal table lookup for configuration information identifying the IP addresses of the DRP server agents and the servers they support.
6 If the subdomain is configured with certain DRP metrics (DRP metrics are described in the "Metrics" section of this chapter), the Director issues DRP requests to each DRP server agent to choose the best server according to configured criteria.
7 From the responses and the configured metrics, the Director chooses the "best" distributed server and returns this IP address to the client's local DNS server.
8 The client's local DNS server returns the IP address to the client.
9 The client transparently connects to this IP address to obtain the requested service.
Figure 1-1 Example of DNS Caching Name Server Mode
HTTP Session Redirector Mode
In HTTP session redirector mode, the Director provides HTTP session redirection services. Here is how a request can be serviced (see ):
1 A client issues an HTTP request to a specific URL-embedded host name.
2 The Director accepts the HTTP connection, appearing to be the requested web server. The Director determines the host name requested by the client based on the IP address on which the HTTP request arrives.
3 If the information is not already in the Director cache, the Director requests resource records from the primary DNS server. These records identify the IP addresses of the DRP server agents as well as the web servers they support.
4 If the subdomain is configured with certain DRP metrics (DRP metrics are described in the "Metrics" section of this chapter), the Director issues DRP requests to each DRP server agent to choose the best web server according to configured criteria.
5 From the responses and the configured metrics, the Director chooses a web server and forms a new URL for it. The Director returns the URL to the client, along with the HTTP status code 302, "Moved Temporarily."
6 The client transparently connects to the new URL.
Figure 1-2 Example of HTTP Session Redirector Mode
You can configure the Director with one or more of the following metrics:
•DRP external. This metric determines the number of BGP autonomous system hops between the client requesting service and the DRP server agent. (See .)
•DRP internal. This metric finds the IGP distance between the DRP server agent and the closest border router at the edge of the autonomous system. These metrics are determined by the IGP protocol which is in use. Normally, these metrics are a combination of multiple metric values: bandwidth, delay, and so on, that are then combined into a single composite metric. This is the value that the Director uses to make topological distance decisions. (See .)
•DRP server. This metric finds the IGP value metric between the DRP server agent and the associated server. These metrics are determined by the IGP protocol which is in use. Normally, these metrics are a combination of multiple metric values: bandwidth, delay, and so on, that are then combined into a single composite metric. This is the value that the Director uses to make topological distance decisions.
•Random. This metric is used to randomly chose between each distributed server. It does not require routing table information. This metric does not trigger DRP queries.
•Administrative cost. This metric specifies a statistical preference of one server over another. It is also used to take a server out-of-service. This metric does not trigger DRP queries.
Figure 1-3 DRP Internal and External Metrics
The metrics in the list apply per subdomain or host name. You can weight these metrics so that one is more important than another or prioritize the metrics so that if multiple servers are equally suitable another metric is applied to find the best server, or both.
The effectiveness of the DRP external metric is determined by the quality of data in the BGP routing tables. The effectiveness of the DRP internal metric is determined by the quality of data in the IGP routing tables. All DRP server agents assigned to a subdomain or host name should use the same type of IGP, such as Routing Information Protocol (RIP or RIP2), Interior Gateway Routing Protocol (IGRP), or Open Shortest Path First (OSPF).
When the server availability parameter is enabled for a distributed server, the Director uses periodic, temporary TCP connections to verify that the server is available and prevents the Director from redirecting clients to a server that cannot respond.
To increase performance, the Director caches the sorting information for each client on a per-local-DNS basis for a default period of one minute. This means that an initial request to the Director from a specific local DNS server triggers DRP querying and DRP reply sorting. The Director caches the sorted DRP replies, along with the IP address of the querying local DNS server. Subsequent Director queries issued by the same local DNS server (within the one-minute window) are fulfilled by sending this cached entry. This is efficient because the local DNS server will probably issue DNS requests for large numbers of clients, and the caching eliminates DRP querying for multiple users in the same topological proximity as their shared DNS server. Performance is improved and network overhead is decreased.
To prevent a local DNS from caching information it receives from the Director, resource records returned by the Director have a default time-to-live (TTL) value of zero seconds. However, the TTL attached to DNS replies is configurable.
DRP Security Features
To help prevent DRP-based denial-of-service attacks on DRP server agents, the Director supports these security features, which can be used separately or together to provide robust DRP-related security:
•Access Control Lists (ACLs). Access lists enable the network administrator to limit DRP server agent access to devices having specific source IP addresses.
•Message digest 5 algorithm (MD5) digital signature authentication (RFC 1321). This technique enables DRP devices to authenticate the identities of DRP query and response sources.
The Director has the following hardware features:
•Ethernet attachment unit interface (AUI) DB-15 port (Cisco DistributedDirector 2501 only)
•Token Ring DB-9 port (Cisco DistributedDirector 2502 only)
•Dynamic random-access memory (DRAM) for main memory and shared memory
•Nonvolatile random-access memory (NVRAM) for storing configuration information
•Flash memory for running the Cisco IOS software
•EIA/TIA-232 console port for local system access using a console terminal
•EIA/TIA-232 auxiliary port for remote system access using a modem
Note EIA/TIA-232 and EIA/TIA-449 were known as recommended standards RS-232 and RS-449 before their acceptance as standards by the Electronic Industries Association (EIA) and Telecommunications Industry Association (TIA).
shows the front panel of the Cisco DistributedDirector 2501. shows the rear panel.
Figure 1-4 Cisco DistributedDirector 2501 Front Panel
Figure 1-5 Cisco DistributedDirector 2501 Rear Panel
shows the rear panel of the Cisco DistributedDirector 2502.
Figure 1-6 Cisco DistributedDirector 2502 Rear Panel
Table 1-1 lists the system specifications for the Director.
Table 1-1 System Specifications
Dimensions (H x W x D)
1.75 x 17.5 x 10.56 in. (4.44 x 44.45 x 26.82 cm),
one rack unit
10 lb (4.5 kg)
Input voltage, AC power supply
100 to 240 VAC
1.2 to 0.6A
40W (maximum), 135.5 Btus1 /hr
Input voltage, DC power supply
40W, 40 to 72 VDC
1.5 to 1.0A
40W (maximum), 135.5 Btus/hr
20-MHz Motorola 68EC030
•Ethernet AUI (IEEE2 802.3) (DB-15)
32 to 104×F (0 to 40×C)
-40 to 185×F (-40 to 85×C)
5 to 95 percent, noncondensing
34 dBa @ 3 feet (0.914 m)
FCC Class A, VDE Class B, and Canadian DOC Class A
For more regulatory information, refer to the Public Network Certification publication.