|
|
ACNS 4.1 software adds support that allows you to configure a Content Engine as a content routing agent. A content routing agent is used in conjunction with the Cisco Content Router 4430 (CR-4430) running Content Routing software. The Content Router redirects a user request to the "closest" (best) replicated-content site, based on network delay and other parameters, using a technology called boomerang.
Before you configure the Content Engine as a content routing agent, configure the Content Router as described in the Cisco Content Routing Software Configuration Guide and Command Reference.
Use the boomerang dns enable command to enable content routing software on a Content Engine that you want to configure as a content routing agent. Use the boomerang dns domain command to configure the Content Engine as a content routing agent for a specified domain and to enter the domain configuration mode to establish operating parameters for the specified domain name.
Boomerang agents support multiple domains, where each agent domain may be associated with a different boomerang server. Other than memory limits, there are no limits to the number of domains supported on the agent. For more information on the boomerang agent, refer to the current release of the Cisco Content Routing Software Configuration and Command Reference.
Use the boomerang dns domain domain-name alias alias-name command to set alternate boomerang domain names that share the same operating parameters. If you are using the Content Engine as a content routing agent, use this command on both the Content Router and the Content Engine to establish an alternative name for a domain.
 |
Note Corresponding alias domain names must also be configured on the boomerang server. Each client domain can be associated with a different boomerang server. |
If the Content Engine is not used to serve web pages, use the content-server ip-address file filename option to specify the address of the cache to be used. If it wins the race, the content server is the local web cache or mirror cache that serves content for the requesting web client that initiated the DNS race. The boomerang agent probes the content server periodically to ensure that it is running and able to serve web pages. The probe consists of an HTTP GET request for the configured filename. A response of 200 OK indicates that the content server is running. If a filename is not given, attempts to connect are made only through port 80.
If you are using the Content Engine as a content routing agent, use the boomerang dns domain domain-name dns-ttl command to specify the DNS TTL value contained in the DNS response generated by the agent. In general, a lower DNS TTL value ensures more recent content, whereas a higher DNS TTL value reduces the Content Router load. The higher the DNS TTL value, the less the load on the Content Router. A lower value means an increased Content Router load, but also means that the addresses of Content Engines that won DNS races are used for a shorter length of time in the annealing process. For example, if the DNS TTL is set at 60 seconds, a DNS server returns to the Content Router to look up a domain name no more than once a minute. In other words, the name server uses the winning Content Engine address for 60 seconds before consulting the Content Router again. Use no dns-ttl to reset the delay to its default value.
|
Note A dns-ttl command entered on a Content Engine boomerang agent overrides a dns-ttl command entered on the Content Router. |
The number of hops to live value of the DNS response is generated by the client. The value specified by the hops option overrides the value specified by the boomerang server.
The key shared secret string specifies the secret that is matched against the secret contained in the packets sent by the server. The shared secret configured on the client domain needs to be the same as the secret configured on the server.
Use the origin-server ip-address subcommand if the Content Engine is used as a cache rather than mirror site. If the web cache does not have the requested content, or there is a cache miss, it must get the content from the origin server and cache it for future requests. Because the Content Engine web cache does not have the IP address of the origin server, this subcommand must be set to provide the IP address to get content from the origin server.
 |
Caution A Content Engine can be used simultaneously for transparent caching and as a content routing agent. Make sure that you use the boomerang origin-server command to configure the Content Engine to cache requests. |
The boomerang log-races enable command enables logging of the DNS IP address resolution timing results between the boomerang server and the agent. To disable the command, enter the no boomerang log-races command.
To delete a domain, enter the no boomerang command. It is not necessary to enter arguments and variables before deleting the current domain name.
In the following example, assume that a domain is named www.foobar.com. It is given the domain name www.foobar.com on the Content Router.
Console(config)# boomerang dns enable
Console(config)# boomerang dns domain www.foobar.com
In the following example, assume that a domain is named www.foobar.com. It is given the alias www.foobar.net on the Content Router.
Console(config-boomerang)# alias www.foobar.net
When configuring www.foobar.com on the agent, enter the alias on the Content Engine as follows.
Console(config-bomerang)# alias www.foobar.net
ACNS 4.1 software provides support for proxy automatic configuration files (.pac files). A browser obtains proxy IP address and port configuration information from the proxy automatic configuration file when the browser's autoconfiguration URL field is configured with the Content Engine IP address, incoming port number, file directory, and .pac filename.
The proxy-auto-config download EXEC command downloads an automatic configuration file from an FTP server to the present working directory of the Content Engine. To enable the proxy automatic configuration file feature, enter the proxy-auto-config enable global configuration command. Each time you download a new automatic configuration file to the Content Engine, enter a no proxy-auto-config enable and proxy-auto-config enable command.
|
Note You must configure disks /local1 or /local2 as a sysfs volume before downloading the autoconfiguration file to either of these two disk locations. |
The autoconfiguration feature is supported by the Microsoft Internet Explorer and Netscape browsers. The browser must be manually configured for automatic proxy configuration.
This example demonstrates how to download an automatic configuration file from an FTP server to the Content Engine:
ContentEngine# proxy-auto-config download 172.16.10.10 remotedirname theproxyfile.pac
This example enables browser autoconfiguration on the Content Engine:
ContentEngine(config)# proxy-auto-config enable
This example demonstrates the URL syntax to enter in the browser's automatic proxy configuration
URL field:
http://ContentEngine-IPaddress:portnumber/theproxyfile.pac
|
Note Use the port number specified by the http proxy incoming portnumber global configuration command for configuring proxy incoming ports. For instance, if port 8080 is specified with the http proxy incoming 8080 command, then use 8080 as your port number in the example shown. |
When a Content Engine is added to an existing WCCP Version 2 cache group (cluster), it can receive requests for content that was formerly served by another cache in the cluster. This event is termed a "near-miss," because if the request had been sent to the former Content Engine, it would have been a cache hit. A near-miss lowers the overall cache hit rate of the Content Engine cluster.
The Content Engine in healing mode is called a healing client. The caches in the cluster that respond to healing client requests are called healing servers. Healing mode allows the newly added Content Engine to query and obtain cache objects from all other caches in the cluster on a cache miss event. If the object is found in the cluster, one of the healing servers sends back a response saying that it has the object in its cache and that the healing client can request an object from it. If the object is not found in the cluster, the Content Engine processes the request through the outgoing proxy or origin server.
|
Note Healing mode is only invoked on a healing client when the request is transparently redirected to the Content Engine. Healing mode is not invoked when the request is sent to the Content Engine in proxy mode. |
The http cluster command modifies the healing mode parameters. The http cluster http-port command specifies the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster.
|
Note The default port number is 80. If you choose to configure a port other than the default, you must ensure that the port configured matches the port specified in the http proxy incoming command on healing servers in the farm. Otherwise, the healing client is not able to retrieve objects from the healing servers. |
The http cluster misses command specifies the maximum number of misses that the healing
Content Engine can receive from the cluster after the last healing mode hit response until the healing process is disabled. The http cluster max-delay command specifies the maximum time interval in seconds for which a healing Content Engine waits for a healing response from the cluster before considering the healing request a miss.
To enable the healing client, you should, at the least, configure the max-delay and misses options. The default port number for http-port is 80; therefore, if you use the default port, you do not have to configure http-port.
To disable the healing client, you should, at the least, configure either misses or max-delay to 0, or you can use the no form of the command:
This example enables the healing mode feature by setting the HTTP port for forwarding HTTP requests to a healing server, setting the maximum delay to wait for a response from the cluster in seconds before considering the healing request a miss, and setting the maximum number of misses that the healing Content Engine can receive from the cluster before healing mode is disabled at the healing client.
Console(config)# http cluster http-port 8080
Console(config)# http cluster max-delay 5
Console(config)# http cluster misses 5
In this example, the show statistics http cluster command displays the statistics of the healing client and the healing server. The clear statistics http cluster command resets the healing mode statistics:
Console(config)# show statistics http cluster
Healing mode max attempts = 0
Healing mode max latency = 0
Healing mode current cumulative misses = 0
Healing mode client statistics
------------------------------
Client Requests Sent = 0
Client Responses Received = 0
Client Responses Hit = 0
Client Responses Miss = 0
Client Responses Error = 0
Client Responses Timeout = 0
Healing mode server statistics
------------------------------
Server Requests Received = 0
Server Responses Sent = 0
Server Responses Hit = 0
Server Responses Miss = 0
Server Responses Error = 0
The show http cluster command displays max-delay, misses, and HTTP port values. In the first example, the values are set to 0 and the healing client is disabled.
Console(config)# show http cluster
Healing client is disabled
Timeout for responses = 0 seconds
Max number of misses allowed before stop healing mode = 0
Http-port to forward http request to healing server is not configured
ACNS 4.1 software can read a file of URLs and download the specified content to the Content Engine. This preloading can be scheduled with the pre-load schedule global configuration command, or triggered immediately with the pre-load force EXEC command.
A list file of URLs to be preloaded (URL list) is maintained by the administrator. If the administrator wants to preload authenticated content to the Content Engine, the URL list file entry must be written as follows:
http://username:passwrod@www.authenticatedsite.com/ <depth level>
The URL list must be created on a remote system. This list is accessed from this remote system with a frequency set by the pre-load schedule command. In other words, whenever a pre-loading is scheduled to run, this URL list is fetched from the remote system.
|
Note The URL list is not cached by the Content Engine. It must be fetched from the remote system every time content preloading is scheduled. |
The ftp/http URL location of the URL list file can be specified in the pre-load url-list-file option. The URL list can also be transferred to a sysfs volume on the Content Engine, in which case, the path of the URL list is specified by the pre-load url-list-file option. The URL list is a list of URLs, each with an optional depth parameter. The depth parameter specifies how many levels down the preloading will be performed. For example, http://www.espn.com 3 means download http://www.espn.com and all content three levels deep. If the depth level is not specified, then the pre-load depth level default is used. The URLs are delimited with a carriage return as follows:
<cr>
. . .
http://www.cnn.com 3 <cr>
ftp://ftp.lehigh.edu/ 2 <cr>
http://www.yahoo.com <cr>
. . .
<cr>
Use the pre-load schedule command to specify the time intervals at which the preload event executes, or use the pre-load force EXEC command to launch a preload event at any time.
|
Note If content preloading does not complete before the scheduled end time you must restart the preloading process to capture content intended. |
If the content to be preloaded is already in the Content Engine, then the Content Engine revalidates the freshness of the stored copy.
A preload request process (wget) is spawned for every URL in the list. These processes operate concurrently. Use the pre-load concurrent-requests option to configure the maximum number of preload processes to run at the same time. If the number of URLs in the URL list file is less than the number of specified concurrent requests, then the lesser number is active.
All configured HTTP parameters and rules apply to the preloaded objects.
This example enables the preload feature:
ContentEngine(config)# pre-load enable
This example specifies the path name of the preload URL list file:
ContentEngine(config)# pre-load url-list-file /local1/myurllist
This example specifies the depth level for URL retrieval at 4:
ContentEngine(config)# pre-load depth-level-default 4
This example creates a filter for the objects to be excluded:
ContentEngine(config)# pre-load no-fetch suffix .mil .su .ca
This example specifies a filter for the domain to be fetched:
ContentEngine(config)# pre-load fetch domain cisco.com
This example specifies that other domains in an HTML page should be traversed (by default, other domains in an HTML page are not traversed):
ContentEngine(config)# pre-load traverse-other-domains
This example specifies the maximum number of concurrent connections:
ContentEngine(config)# pre-load concurrent-requests 5
This example specifies a daily interval for scheduling the preload:
ContentEngine(config)# pre-load schedule every-day start-time 01:00 end-time 02:00
This example specifies an hourly interval for scheduling the preload:
ContentEngine(config)# pre-load schedule every-hour start-time 8 end-time 20
The pre-load schedule every-week option permits configuring a preload on more than one day of the week. This example specifies a biweekly interval for scheduling the preload:
ContentEngine#(config)# pre-load schedule every-week Sun Wed start-time 01:00 end-time
06:00
The default start time for the preloading operation is 00:00 (that is, the start of the day). If the end time is not specified, the preload operation is completed after all the objects have been downloaded.
The following are examples of preload-related show commands:
ContentEngine# show statistics pre-load
Statistics of last Preloading operation
---------------------------------------
Preloading was initiated by cron.
Preloading started at Sat Feb 10 21:00:01 2001
Preloading ended at Sun Feb 11 00:45:25 2001
Number of invalid entries in URL list file = 0
Total number of preloaded objects = 44178
Total number of preloaded bytes = 895723727
ContentEngine# show pre-load
Preloading is enabled
Number of concurrent sessions: 10
Depth level: 3
URL List File: /local1/preload/preload.txt
Preload will not traverse other domains.
Fetch Domains:
Fetch Suffix:
Fetch Directory:
No-fetch Domain:
No-Fetch Suffix:
No-Fetch Directory:
Scheduling on:
Sunday
Start Time: 00:00
End Time : Till completion
Posted: Mon Nov 18 11:32:40 PST 2002
Copyright 1989-2000©Cisco Systems Inc.