This document addresses various conditions that you can experience when
you use the DistributedDirector (DD). The document also describes how to
resolve the problems.
For more information on document conventions, see the
Technical Tips Conventions.
If the DD works correctly, why is routing between the ports on the DD not
A. The DD image does not support routing.
If I have set up Director Response Protocol (DRP) on a router, why is DRP
A. Only the images that include Border Gateway Protocol (BGP) include the
DRP code. See Some of my Director Response Protocol (DRP)
agents fail to communicate after my recent installation of the latest DD image.
What can I do?.
What do I do if the Director Response Protocol (DRP) agents fail to
A. Perform one of these two procedures to verify that the DRP agents are
able to receive messages from the DD:
Issue the show ip dir
This command shows the number of DRP queries and the number of
responses to the queries.
Issue the debug ip dir queries
This command prints debugs about queries that went to the DRP
agents and the DRP agent replies.
When you issue the debug commands in
large configurations, define an access list and use the
version of the command. Use
of this version of the command reduces the amount of output. "Large"
configurations are configurations that have many DRP agents.
Note: Send the output to a log buffer and then print the buffer, rather
than print the debug output directly. Never print debug
output directly on the console because a print to the console seriously affects
Cisco IOS® Software performance. But you can print to a vty.
Issue the show ip drp
This command shows the number of DRP queries and the types of
Issue the debug ip drp
This command prints debugs about queries that the DRP agent
received as well as the replies.
Why does the DD not respond to Domain Name System (DNS)
A. If you have set up the DD only in HTTP redirect mode, the DD does not
respond. You can set up the DD to work in redirect and DNS modes at the same
time. This setup directs "a12b3c.com" and "www.a12b3c.com", for example, to the
The DD has a small built-in DNS server that caches. You can also
configure the DD with some types of DNS information directly in the box. These
record types include Address (A), Start of Authority (SOA), and Mail Exchange
(MX). You can put in a test address to see if there is a resolution. A records
already exist for the hosts that you have configured. Set the DD as the DNS
server on your client to test these directly. Many IP utilities packages
include a DNS resolver, so you can see how the resolution of host names occurs.
If the DD points you directly to the host, DD is not the problem. If DD
does not point you to the host, either you have entered the host incorrectly in
the DD or the metrics are wrong.
If the DD responds when you have set the DD as the DNS server, the Name
Service (NS) records in the server that register the name are wrong.
Note: The design of the DD is to help load balance an address or set of
addresses within a domain. The intention of the DD is not to be a primary DNS
server for an entire domain. See the section What can I do
if I have overloaded the DD?.
I use the LocalDirector (LD) and DD together. Why does the LD not
A. The DD polls the virtual address of the LD. If the LD failed, issue the
show ip director server command to show the failure.
If you use LD-DD interaction via Dynamic Feedback Protocol (DFP), the
show ip director server command also shows
I am in director mode/HTTP redirect mode. What can I do if the director
does not respond?
With the assumption that you ping the DD, issue the ip
director address command to see if the HTTP address is correct.
This address is different than the interface addresses that reply to the pings.
Try to directly reach the hosts to which you redirect.
Determine if there are routing issues, such as access lists, that can
prevent HTTP access to the DD. These lists are not often in the same network
area as the servers.
Remember that Secure HTTP (HTTPS) is not directly for the DD
In a browser session, I lose information that previously went to the
server—for example, my shopping cart becomes empty—or a Secure Socket Layer
(SSL) session terminates unexpectedly. What can I do?
A. A redirect to another host that does not have state information about
the browsing session has occurred. You can usually fix this problem with use of
the LocalDirector (LD) with DD if you set some of the LD
sticky features. Refer to
LocalDirector 400 Series Product Support for information on how to set
DDs do not usually experience this problem. Most Internet Service
Providers (ISPs) set the Time To Live (TTL) on Domain Name System (DNS) records
to 5 or 10 minutes. So, even if a browser issues a new DNS request during this
period, the browser receives the same record.
If the hosts have direct connection to the DD, set the TTL on the
records to a higher value. In the future, there will be a variable cache
feature for the DD that addresses this issue. The feature will cache replies to
What can I do if I have overloaded the DD?
A. Do not use the DD as the primary Domain Name System (DNS) for an entire
site. When you use the DD in this way, the DD receives much more traffic than
necessary. Create a "www.companyABC.com" subdomain and have the DD serve as
primary for that subdomain. The name "www.companyABC.com" can be a subdomain
and a host name at the same time.
You can have configured too many hosts or Director Response Protocol
(DRP) agents. Multiple DD configurations can also produce a lot of interbox
traffic and load if the configuration is fully meshed. For example, if you have
a DD in New York, you would not have the DRP or host in India if you have a DD
in Asia. If a DNS server in India references a DNS server in New York, which is
not likely, the inquiry works. The network connectivity between the sites is
very good. But, the DD in New York does not need entries for the India servers
and DRP agents as long as there are one or two DDs in the network that are
closer, in a network context, to most India sites.
Also, response time metrics are very DD workload-intensive.
How long does a failure between sites take? In other words, how long does
a change of DD response to Domain Name System (DNS) queries between director
hosts take when one host goes down?
A. If you use LocalDirector (LD)-DD interaction, the changeover is very
fast. The LD tells the DD to take the host out of service within 1 or 2
seconds. No test or other action is necessary.
At the receipt of information that the original site is down, the site
is online. There was once a confidence test of a site that
was not in use. But this test is not in the new code. The certainty
value is no longer in use.
The change is not as fast if you do not use LD-DD interaction or an LD
is not in use and you use the connect method to verify server functionality. In
this case, the DD waits for the TCP connection request to time out after the
send of a probe before the DD fails the host. If you set the connect timeout to
30 seconds, the DD fails over to the next best server after 1 minute.
I have set up DD in a simple failover mode, but Domain Name System (DNS)
queries return only the primary address, even when the primary site fails. What
can I do?
A. Make sure that you select a priority for your queries. If you do not
select a priority, the DD DNS code operates but returns the first address that
the host list defines for that address.
Some of my Director Response Protocol (DRP) agents fail to communicate
after my recent installation of the latest DD image. What can I
A. If you run a DD image of Cisco IOS® Software Release 11.1(18)AI or
later, verify that all your DRP agents run an image of Cisco IOS Software
Release 11.3(2)T or later.
If you run a DD image that is earlier than Cisco IOS Software Release
11.1(18)AI, use one of the Cisco IOS Software Release 11.2(x)F images.