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 Cisco Technical Tips Conventions.
A. The DD image does not support routing.
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?.
A. Perform one of these two procedures to verify that the DRP agents are able to receive messages from the DD:
On the DD:
- Issue the show ip dir command. This command shows the number of DRP queries and the number of responses to the queries.
- Issue the debug ip dir queries command. 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 access list 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.
On the DRP agent:
- Issue the show ip drp command. This command shows the number of DRP queries and the types of responses.
- Issue the debug ip drp command. This command prints debugs about queries that the DRP agent received as well as the replies.
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 same hosts.
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?.
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 these:
The weight assignment for the host on the LD
The last time the DD received a status update from the LD
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 redirector mode.
Q. 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 Cisco LocalDirector 400 Series Product Support for information on how to set these features.
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 DNS.
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.
Q. 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.
Q. 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.
Q. Some of my Director Response Protocol (DRP) agents fail to communicate after my recent installation of the latest DD image. What can I do?
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.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.