Table Of Contents

Overview of the Cisco DistributedDirector 4700-M

Cisco DistributedDirector Services

DNS Caching Name Server Mode

HTTP Session Redirector Mode

Metrics

Server Availability

Caching

Time-to-Live Values

DRP Security Features

Hardware Features

Specifications

Software Compatibility

Memory Systems

Memory Requirements

Shared Memory Requirements

Main Memory Requirements

Overview of the Cisco DistributedDirector 4700-M

---

This chapter provides an overview of the Cisco DistributedDirector 4700-M in the following sections:

•Cisco DistributedDirector Services

•DNS Caching Name Server Mode

•HTTP Session Redirector Mode

•Metrics

•DRP Security Features

•Server Availability

•Caching

•Time-to-Live Values

•Hardware Features

•Specifications

•Memory Systems

Cisco DistributedDirector Services

The Cisco DistributedDirector 4700-M (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

Metrics

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).

Server Availability

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.

Caching

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.

Time-to-Live Values

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.

Hardware Features

The Cisco DistributedDirector 4700-M is a configurable modular platform using network processor modules—individual modules that when installed in the Director are ready for external network connections.

For maximum performance, the Cisco DistributedDirector 4700-M contains a 133-MHz RISC microprocessor, 32 MB main memory, and a 512-KB secondary cache. The Director's fast speed allows higher throughput for high-speed interfaces.

The Director provides flexibility, allowing network managers to easily reconfigure the Director when changes are required.

The Director supports up to three network processor modules at a time. The network processor modules supported are as follows:

•Dual-port Ethernet with 10BaseT and attachment unit interface (AUI) connectors provided for each port

•Single-port FastEthernet with 100BaseTX connector and 100BaseT4 connectors

•Single-port and dual-port Token Ring

•Dual attachment Multimode Fiber Distributed Data Interface (FDDI)

shows the front panel of the Cisco DistributedDirector 4700-M.

Figure 1-4 Cisco DistributedDirector 4700-M Chassis—Front Panel

Specifications

Design specifications for the Cisco DistributedDirector 4700-M are as follows:

•Modular hardware platform

•Flash memory capability

•User-upgradable network processor modules, shared memory, and processor local memory

•Hardware thermal alarm to warn of excessively high operating temperature

•Rack-mountable in either a standard 19-inch rack or a telco rack

•Mountable on a wall or placed on a desk or table

•Support for up to three network processor modules at a time. Network processor modules can be placed in any of the three available positions in almost any desired combination.

The Cisco DistributedDirector 4700-M can support:

•Two FDDI network processor modules. If you are only using one FDDI module, install it in the center slot for optimum heat dissipation.

•Up to three six-port Ethernet network processor modules.

---

Note   The Cisco DistributedDirector 4700-M supports all network processor modules except the single-port Ethernet network processor module.

---

lists the available network processor module interface options.

Table 1-1 Network Processor Module Interface Options

Interface Options	Port Options	Part Numbers
Ethernet	Single port, dual port, or six port	NP-1E=, NP-2E=, NP-6E=
Token Ring	Dual port or single port	NP-1RV2=, NP-2R=
Multimode FDDI	Single attachment or dual attachment	NP-1F-D-MM=, NP-1F-S-M=
Single-mode FDDI	Dual attachment	NP-1F-D-SS=

lists the specifications of the Cisco DistributedDirector 4700-M.

Table 1-2 System Specifications  

Description	Specification
Dimensions (H x W x D)	3.4 x 17.6 x 17.7 in. (8.6 x 44.7 x 45 cm)
Weight	24 lb (10.9 kg) (including the chassis and network processor modules)
Power	100 to 240 VAC, 50 to 60 Hz, 3.0 to 1.5A or 40 to 72 VDC, 5 to 2.8A
Wire gauge for DC-input power connections	14 AWG1
Network interface options	Ethernet, Token Ring, FDDI
Console port	EIA/TIA-232 DB-25 female connector
Auxiliary port	EIA/TIA-232 DB-25 male connector
Nonoperating temperature	- 40 to 185×F (- 40 to 85×C)
Operating humidity	5 to 95 percent, noncondensing
Operating temperature	32 to 104×F (0-40×C)
Regulatory compliance	FCC Class A, FCC Part 68, Canadian DOC Class A, CS-03, UL 1950 2nd edition, CAN/CSA 950-M93, EN60950 with Amendments 1 and 2, AN/NZS 3260, NOM 019 Additional regulatory compliance is in the Public Network Certification document that shipped with your unit.

1 AWG = American Wire Gauge.

Software Compatibility

Network processor modules must be supported by the appropriate level of system software. The minimum system software version is Cisco DistributedDirector System Software (Cisco IOS Release 11.1(9)IA).

lists the processor and memory specifications of the Cisco DistributedDirector 4700-M.

Table 1-3 Cisco DistributedDirector 4700-M Processor and Memory Specifications  

Description	Specification
Processor	133-MHz IDT Orion RISC
Main memory (DRAM)1	32 MB
Secondary cache memory	512 KB
Shared memory (DRAM)	16 MB
Flash memory	16 MB
NVRAM2	128 KB
Boot ROM	128-512 KB
Boot Flash	4-16 MB

1 DRAM = dynamic random-access memory. 2 NVRAM = nonvolatile random-access memory.

Memory Systems

The Cisco DistributedDirector 4700-M memory systems (see ) have the following functions:

•Main memory—Stores the running configuration and cache tables. The Cisco IOS software executes from main memory.

•Shared memory—Used for packet buffering by the Director's network interfaces.

•Flash memory—Stores the operating system software image and the boot helper software.

•NVRAM—Stores the system configuration file and the virtual configuration register.

•Boot EPROM—The ROM monitor is EPROM based. The boot helper image allows you to boot the Director when Flash memory does not contain a valid system image. The ROM monitor allows you to boot a system image from Flash memory if a boot helper image is not present in boot Flash memory.

---

Note   See the appendixes "Virtual Configuration Register" and "ROM Monitor" for more information on the ROM monitor.

---

Figure 1-5 Cisco DistributedDirector 4700-M Memory Systems and Software Images

Memory Requirements

Each module can change memory configurations to accommodate internetworking demands. The memory requirements are affected by the following factors:

•The number of Cisco IOS software images a system stores can be increased by adding Flash memory.

•Network expansion, the use of additional protocols or Cisco IOS services, or newer Cisco IOS releases may require additional main memory.

•I/O performance or more physical or virtual interfaces may require additional shared memory.

Shared Memory Requirements

The standard configuration for shared memory is 4 MB, which is enough memory for most configurations with fewer than 24 physical or virtual interfaces. Directors with 24 or more physical and virtual interfaces require 8 to 16 MB of shared memory. shows the per-module shared memory requirements for network processor modules.

---

Note   The types and numbers of network processor modules installed in a system do not affect main or Flash memory requirements.

Table 1-4 Cisco DistributedDirector 4700-M Shared Memory Requirements

Network Processor Module	Per-Module Shared Memory Requirements
Dual-port Ethernet	0.4 MB
Dual-port Token Ring	0.6 MB
Six-port Ethernet	1.2 MB
One FDDI1	2.0 MB
Two FDDI1	3.0 MB

1 FDDI modules are an exception in that two FDDI modules do not require double the shared memory of one FDDI module.

---

Main Memory Requirements

The amount of main memory required by the Director is affected by the size of the network and by the access list configurations. Therefore, it is difficult to quantify the exact main memory requirements based only on network size. For most applications, 32 MB of main memory in the Cisco DistributedDirector 4700-M is sufficient.

---

Note   If your memory requirements fall near the upper end of one of the available main memory options, consider installing the next larger memory option to allow for network growth.

---