Cisco ACNS Software Caching Configuration Guide, Release 4.2 - Chapter 17: Miscellaneous Features [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Miscellaneous Features

Configuring the Content Engine as a Content Routing Agent

Examples

Browser Autoconfiguration

Configuring Healing Mode

Examples

Content Preloading

HTTP, FTP, and MMS Protocols

Resuming Content Preloading

Bandwidth Control

ToS and DSCP

Examples

Miscellaneous Features

This chapter describes miscellaneous features associated with the Content Engine. This chapter contains the following sections:

•Configuring the Content Engine as a Content Routing Agent

•Browser Autoconfiguration

•Configuring Healing Mode

•Content Preloading

Configuring the Content Engine as a Content Routing Agent

ACNS 4.2 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 the no dns-ttl command 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 sub-command 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.

Examples

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
Browser Autoconfiguration

ACNS 4.2 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, proxy 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.

Configuring Healing Mode

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:

•http cluster misses 0

•no http cluster misses

•http max-delay 0

•no http cluster max-delay

Examples

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
Content Preloading

ACNS software can read a file of URLs and preload the specified URL content to the Content Engine. This preloading feature is enabled using the pre-load enable global configuration command. Content preloading can then be scheduled with the pre-load schedule global configuration command, or triggered immediately with the pre-load force EXEC command.

You can configure the maximum number of preload processes to run at the same time using the pre-load concurrent-requests option. 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.

HTTP, FTP, and MMS Protocols

ACNS 4.2 software supports content preloading of WMT streaming media files. In other words, the MMS protocol, as well as HTTP and FTP, is supported in the URL list file. All configured HTTP, FTP, and MMS parameters and rules apply to the preloaded objects.

Note You must enable WMT on your Content Engine before preloading WMT streaming media files. See the "Enabling WMT on the Content Engine" section.

A list file of URLs to be preloaded is maintained by the administrator. This URL list must be created on a remote system and can either be transferred to the Content Engine for preloading access or accessed from the remote server using the pre-load url-list-file option when content preloading is enabled. This list is also accessed with a frequency set by the pre-load schedule command.

You can place the list of URLs in a file under a local disk. You can also make a sub-directory that contains the list file with the mkdir command. For instance, the mkdir /local1/preload-directory command creates a subdirectory called preload-directory under local disk /local1 . You can then use the copy ftp disk command to ftp over the list file. For more information on this command refer to the Cisco ACNS Software Command Reference, Release 4.2.

The URL list file 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 preload depth level default of 3 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>
mms://www.aol.com/<dir>/<streaming-file>
http://www.yahoo.com <cr>
. . .
<cr>
If the administrator wants to preload authenticated content to the Content Engine, the URL list file entry must be written as follows:
http://username:password@www.authenticatedsite.com/ <depth level>
Resuming Content Preloading

If content preloading is not completed before the scheduled end time, you can resume the preloading process to capture content intended using the pre-load resume global configuration command. In other words, using this command allows you to resume downloading from the breakpoint of the previous preload, instead of starting again from the very beginning of the URL list file.

Note If pre-load resume is not configured on the Content Engine and content preloading is aborted before the scheduled end time, the next scheduled content preloading starts from the beginning of the URL list file.

Bandwidth Control

You can configure a maximum bandwidth for the preloading process using the pre-load max-bandwidth global configuration command. Previous versions of ACNS software did not allow for bandwidth control, so the user had no way to ensure that bandwidth consumption during preloading did not exceed the user-specified bandwidth limits. ACNS 4.2 software also allows for preloading of WMT streaming media files that may have different bit rates at the URL specified for content preloading.

Note You can also control WMT bandwidth and bit-rates using the wmt max-bandwidth and wmt max-bitrate global configuration commands.

ToS and DSCP

Setting the Type of Service (ToS) or differentiated services code point (DSCP) is called packet marking, allowing you to partition network data into multiple priority levels or types of service. You can set the ToS or DSCP values in IP packets based on a URL match, a file type, a domain, a destination IP address, a source IP address, or a destination port.

ACNS 4.2 software includes ToS or DSCP support for HTTP, FTP, and MMS preload traffic. Since content preloading is initiated by the Content Engine and not by the requesting client when a connection is made to an origin server, the ToS or DSCP code point on the traffic going toward the server needs to be set before contact is made with the origin server. Use the pre-load dscp global configuration command to set the ToS value as well as the DSCP code point for all preload traffic.

Note Using the pre-load dscp command takes precedence over any use of the Rules Template configuration commands involving DSCP server configurations.

Examples

This example enables the preload feature:
ContentEngine(config)# pre-load enable
This example specifies the local path name of the preload URL list file myurllist.txt:
ContentEngine(config)# pre-load url-list-file /local1/preload-directory/myurllist.txt
This example specifies the FTP server from which a URL list file is accessed:
ContentEngine(config)# pre-load url-list-file ftp://ftpserver/ftpdirectory/myurllist.txt
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.

This example allows the Content Engine to resume content preloading from the URL where content preloading was terminated:
ContentEngine#(config)# pre-load resume
The following are examples of preload-related show commands. This example shows the statistics of the preloading operation while content preloading is taking place.
ContentEngine# show statistics pre-load
Statistics of last Preloading operation
---------------------------------------
Preloading is in progress.
List of preloaded URLs are in /local1/preload_dir/downloaded_urls.
1811 objects downloaded, 35506616 bytes transferred.
This example shows the statistics of the preloading operation after the content preloading process has been disabled using the no pre-load enable global configuration command. The show statistics pre-load command is also used to show the statistics of the successful content preloading operation.
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 
This example shows how to set ToS support to normal:
ContentEngine(config)# pre-load set-tos normal
This example shows how to set maximum bandwidth for content preloading to be 50000 kbps.
ContentEngine(config)# pre-load max-bandwidth 50000
This example shows the status of the current preloading operation after using the pre-load set-tos and pre-load max-bandwidth commands:
ContentEngine# show pre-load
Preloading is enabled
Number of concurrent sessions: 10
Depth level: 4
URL List File: /local1/url.txt
DSCP: set-tos normal 
Max Bandwidth: 50000 Kbps
Previous preloading operation will be continued.
Preload will not traverse other domains.
Fetch Domains: 
Fetch Suffix: 
Fetch Directory: 
No-fetch Domain: 
No-Fetch Suffix: 
No-Fetch Directory: 
Scheduling on all days
	Start Time: 00:00
	End Time  : Till completion
This example shows the statistics associated with current preloading.
ContentEngine# show statistics pre-load
Statistics of last Preloading operation
---------------------------------------
Preloading is in progress.
List of preloaded URLs are in /local1/preload_dir/downloaded_urls.
79 objects downloaded, 2684000 bytes transferred.
This example shows updated statistics from previous example using the show statistics pre-load command.
ContentEngine# show statistics pre-load
Statistics of last Preloading operation
---------------------------------------
Preloading is in progress.
List of preloaded URLs are in /local1/preload_dir/downloaded_urls.
83 objects downloaded, 2842292 bytes transferred.

	Cisco ACNS Software Caching Configuration Guide, Release 4.2
	Chapter 17: Miscellaneous Features
Cisco ACNS Software Caching Configuration Guide, Release 4.2 Cisco ACNS Software Caching Configuration Guide, Release 4.2 Preface Chapter 1: Cisco Cache Application Product Overview Chapter 2: Content Engine Management Configuration and Features Chapter 3: HTTP Caching Parameter Settings Chapter 4: Streaming Media Overview Parameter Settings Chapter 5: Transparent Caching Chapter 6: Proxy-Style Caching Chapter 7: Reverse Proxy Caching Chapter 8: Configuring a Primary Proxy Server Chapter 9: Configuring Windows Media Technologies Streaming Media Caching Chapter 10: Configuring RealProxy Streaming Media caching Chapter 11: Configuring URL Filtering Chapter 12: Configuring the Rules Template Chapter 13: Configuring Authentication Chapter 14: Configuring Transaction Logging Chapter 15: Configuring Network Management Chapter 16: Configuring TCP Stack Parameters Chapter 17: Miscellaneous Features Appendix A: Web Cache Communication Protocol Version 1 Appendix B: Web Cache Communication Protocol Version 2 Index	Download this chapter Chapter 17: Miscellaneous Features Download the complete book Cisco ACNS Software Caching Configuration Guide, Release 4.2 (PDF - 3 MB) Table Of Contents Miscellaneous Features Configuring the Content Engine as a Content Routing Agent Examples Browser Autoconfiguration Configuring Healing Mode Examples Content Preloading HTTP, FTP, and MMS Protocols Resuming Content Preloading Bandwidth Control ToS and DSCP Examples Miscellaneous Features This chapter describes miscellaneous features associated with the Content Engine. This chapter contains the following sections: •Configuring the Content Engine as a Content Routing Agent •Browser Autoconfiguration •Configuring Healing Mode •Content Preloading Configuring the Content Engine as a Content Routing Agent ACNS 4.2 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 the no dns-ttl command 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 sub-command 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. Examples 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 Browser Autoconfiguration ACNS 4.2 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, proxy 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. Configuring Healing Mode 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: •http cluster misses 0 •no http cluster misses •http max-delay 0 •no http cluster max-delay Examples 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 Content Preloading ACNS software can read a file of URLs and preload the specified URL content to the Content Engine. This preloading feature is enabled using the pre-load enable global configuration command. Content preloading can then be scheduled with the pre-load schedule global configuration command, or triggered immediately with the pre-load force EXEC command. You can configure the maximum number of preload processes to run at the same time using the pre-load concurrent-requests option. 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. HTTP, FTP, and MMS Protocols ACNS 4.2 software supports content preloading of WMT streaming media files. In other words, the MMS protocol, as well as HTTP and FTP, is supported in the URL list file. All configured HTTP, FTP, and MMS parameters and rules apply to the preloaded objects. Note You must enable WMT on your Content Engine before preloading WMT streaming media files. See the "Enabling WMT on the Content Engine" section. A list file of URLs to be preloaded is maintained by the administrator. This URL list must be created on a remote system and can either be transferred to the Content Engine for preloading access or accessed from the remote server using the pre-load url-list-file option when content preloading is enabled. This list is also accessed with a frequency set by the pre-load schedule command. You can place the list of URLs in a file under a local disk. You can also make a sub-directory that contains the list file with the mkdir command. For instance, the mkdir /local1/preload-directory command creates a subdirectory called preload-directory under local disk /local1 . You can then use the copy ftp disk command to ftp over the list file. For more information on this command refer to the Cisco ACNS Software Command Reference, Release 4.2. The URL list file 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 preload depth level default of 3 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> mms://www.aol.com/<dir>/<streaming-file> http://www.yahoo.com <cr> . . . <cr> If the administrator wants to preload authenticated content to the Content Engine, the URL list file entry must be written as follows: http://username:password@www.authenticatedsite.com/ <depth level> Resuming Content Preloading If content preloading is not completed before the scheduled end time, you can resume the preloading process to capture content intended using the pre-load resume global configuration command. In other words, using this command allows you to resume downloading from the breakpoint of the previous preload, instead of starting again from the very beginning of the URL list file. Note If pre-load resume is not configured on the Content Engine and content preloading is aborted before the scheduled end time, the next scheduled content preloading starts from the beginning of the URL list file. Bandwidth Control You can configure a maximum bandwidth for the preloading process using the pre-load max-bandwidth global configuration command. Previous versions of ACNS software did not allow for bandwidth control, so the user had no way to ensure that bandwidth consumption during preloading did not exceed the user-specified bandwidth limits. ACNS 4.2 software also allows for preloading of WMT streaming media files that may have different bit rates at the URL specified for content preloading. Note You can also control WMT bandwidth and bit-rates using the wmt max-bandwidth and wmt max-bitrate global configuration commands. ToS and DSCP Setting the Type of Service (ToS) or differentiated services code point (DSCP) is called packet marking, allowing you to partition network data into multiple priority levels or types of service. You can set the ToS or DSCP values in IP packets based on a URL match, a file type, a domain, a destination IP address, a source IP address, or a destination port. ACNS 4.2 software includes ToS or DSCP support for HTTP, FTP, and MMS preload traffic. Since content preloading is initiated by the Content Engine and not by the requesting client when a connection is made to an origin server, the ToS or DSCP code point on the traffic going toward the server needs to be set before contact is made with the origin server. Use the pre-load dscp global configuration command to set the ToS value as well as the DSCP code point for all preload traffic. Note Using the pre-load dscp command takes precedence over any use of the Rules Template configuration commands involving DSCP server configurations. Examples This example enables the preload feature: ContentEngine(config)# pre-load enable This example specifies the local path name of the preload URL list file myurllist.txt: ContentEngine(config)# pre-load url-list-file /local1/preload-directory/myurllist.txt This example specifies the FTP server from which a URL list file is accessed: ContentEngine(config)# pre-load url-list-file ftp://ftpserver/ftpdirectory/myurllist.txt 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. This example allows the Content Engine to resume content preloading from the URL where content preloading was terminated: ContentEngine#(config)# pre-load resume The following are examples of preload-related show commands. This example shows the statistics of the preloading operation while content preloading is taking place. ContentEngine# show statistics pre-load Statistics of last Preloading operation --------------------------------------- Preloading is in progress. List of preloaded URLs are in /local1/preload_dir/downloaded_urls. 1811 objects downloaded, 35506616 bytes transferred. This example shows the statistics of the preloading operation after the content preloading process has been disabled using the no pre-load enable global configuration command. The show statistics pre-load command is also used to show the statistics of the successful content preloading operation. 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 This example shows how to set ToS support to normal: ContentEngine(config)# pre-load set-tos normal This example shows how to set maximum bandwidth for content preloading to be 50000 kbps. ContentEngine(config)# pre-load max-bandwidth 50000 This example shows the status of the current preloading operation after using the pre-load set-tos and pre-load max-bandwidth commands: ContentEngine# show pre-load Preloading is enabled Number of concurrent sessions: 10 Depth level: 4 URL List File: /local1/url.txt DSCP: set-tos normal Max Bandwidth: 50000 Kbps Previous preloading operation will be continued. Preload will not traverse other domains. Fetch Domains: Fetch Suffix: Fetch Directory: No-fetch Domain: No-Fetch Suffix: No-Fetch Directory: Scheduling on all days Start Time: 00:00 End Time : Till completion This example shows the statistics associated with current preloading. ContentEngine# show statistics pre-load Statistics of last Preloading operation --------------------------------------- Preloading is in progress. List of preloaded URLs are in /local1/preload_dir/downloaded_urls. 79 objects downloaded, 2684000 bytes transferred. This example shows updated statistics from previous example using the show statistics pre-load command. ContentEngine# show statistics pre-load Statistics of last Preloading operation --------------------------------------- Preloading is in progress. List of preloaded URLs are in /local1/preload_dir/downloaded_urls. 83 objects downloaded, 2842292 bytes transferred.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.