Cisco ACNS Software Deployment and Configuration Guide, Release 5.0 - Chapter 8: Configuring Services on CDN Devices [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring Services on CDN Devices

Configuring HTTP and HTTPS Settings

Configuring HTTP Connection Settings

Configuring HTTP Cache Settings

Configuring HTTP Cache Freshness Settings

Configuring Authenticated HTTP Cache Settings

Configuring Advanced HTTP Cache Settings

Configuring Outgoing Proxy Exclusion Settings

Configuring ICP Settings

ICP Client Settings

ICP Remote Client Settings

ICP Server Settings

ICP Remote Server Settings

Configuring Client Proxy Autoconfiguration Settings

Configuring WCCP Bypass

Authentication Traffic Bypass

Configuring WCCP Bypass Settings

Viewing WCCP Bypass Lists

Configuring HTTPS Proxy Settings

Configuring Caching Protocols

Configuring FTP Connection Settings

Setting FTP Cache Freshness

Configuring Licensing and Enabling Streaming Servers

About the RTSP Gateway

Configuring the RTSP Gateway

Enabling RealProxy

Enabling RealSubscriber

Enabling the Cisco Streaming Engine

About Windows Media Technologies

Enabling WMT

Configuring WMT General Settings

Configuring WMT Multicasting

Configuring WMT Station Schedules

Configuring Platform and System Settings

Configuring the Domain Name System Server

Configuring System Logging

Using CiscoWorks2000

Configuring NTP Settings

Configuring CDP Settings

Configuring Content Services for the Content Engine

Configuring Content Services Bandwidth Settings

Configuring Service Rules

Understanding Actions and Patterns

Rules Template Processing Considerations

Configuring the Rules Template Using the Content Distribution Manager GUI

Configuring the Rules Template Using CLI Commands

Configuring URL Filtering

Custom Blocking Messages

Configure URL Filtering Using the Content Distribution Manager GUI

URL Filtering with URL Lists

URL Filtering with the N2H2 Server

URL Filtering with the Websense Enterprise Server

URL Filtering with SmartFilter Software

Configuring Transaction Log Settings

Squid-Style Format

Extended Squid Format

Apache-Style Format

Custom Format

Transaction Logging and NTLM Authentication

Sanitized Transaction Logs

Exporting Log Files

Exporting Transaction Logs to External FTP Servers

Exporting Transaction Logs to External Secure FTP Servers

Enabling Transaction Logging with the Content Distribution Manager GUI

Configuring Authentication

About Authentication

Configuring Authentication Login Settings

Configuring Content Authentication

Authentication Cache Size Adjustments

Setting the Authentication Scheme

Configuring LDAP Server Settings

Configuring NTLM Server Settings

Configuring RADIUS Server Settings

Configuring TACACS+ Server Settings

Configuring Simple Network Management Protocol

Supported MIBs

Key SNMP CLI Commands

Configuring SNMP Traps

Configuring Services on Content Routers

Configuring Services on CDN Devices

A Content Delivery Network (CDN) is a coordinated system made up of three types of devices: Content Distribution Managers, Content Engines, and, if necessary, Content Routers. In order to deliver requested content using these devices, proper configuration using the Content Distribution Manager GUI is necessary. ACNS 5.0 software also allows you to configure Content Engines into device groups so that content services can be configured for an entire group of Content Engines at one time. Device groups and Content Engines share the same configuration features and options.

The following sections describe how to define and configure these various features:

•Configuring HTTP and HTTPS Settings

•Configuring Caching Protocols

•Configuring Platform and System Settings

•Configuring Content Services for the Content Engine

•Configuring Authentication

•Configuring Simple Network Management Protocol

•Configuring Services on Content Routers

Configuring HTTP and HTTPS Settings

You can configure, modify, and view HTTP and HTTPS settings for Content Engines and device groups by completing the following tasks:

•Configuring HTTP connection settings

•Configuring HTTP cache settings

•Configuring HTTP cache freshness settings

•Configuring authenticated HTTP cache settings

•Configuring advanced HTTP cache settings

•Configuring outgoing proxy exclusion settings

•Configuring ICP client settings

•Configuring ICP remote client settings

•Configuring ICP server settings

•Configuring ICP remote server settings

•Configuring client proxy autoconfiguration settings

•Configuring WCCP bypass settings

•Viewing WCCP bypass lists

•Configuring HTTPS proxy settings

Configuring HTTP Connection Settings

A proxy-style request arrives with the same destination IP address as the Content Engine; it has been specifically routed to the Content Engine by the client. The Content Engine supports up to eight incoming ports each for File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Microsoft Media Server (MMS), and Real-Time Streaming Protocol (RTSP) proxy modes. The incoming proxy ports can be the same ports that are used by transparent mode services. The incoming proxy ports can be changed without stopping any WCCP services running on the Content Engine or on other Content Engines on a Content Engine farm or in the network.

To configure HTTP connection settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose HTTP/S > HTTP Connections. (See Figure 8-1.)

Figure 8-1 HTTP Connection Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable Incoming Proxy check box to accept incoming requests on ports in addition to port 80.

Step 6 In the List of Incoming Ports field, enter the port numbers used by the proxy server or Content Engine to receive requests.

Step 7 Check the Enable Outgoing Proxy check box to allow an outgoing proxy server or another Content Engine to receive HTTP cache miss request traffic.

Step 8 In the Outgoing Connection Timeout field, enter a value in microseconds for the timeout period to use when probing for outgoing proxy servers.

Step 9 In the Outgoing Monitor Period field, enter an interval in seconds for monitoring an outgoing proxy server.

Step 10 Check the Use Origin Server check box to direct requests to the origin server specified in the user request if all outgoing proxy servers fail.

Step 11 Check the Preserve 407 headers check box to enable this feature.

Step 12 Enter the host name or IP address for the outgoing proxy host names in the Outgoing Proxy Host Name field.

Step 13 In the Port field, enter a port number corresponding to the outgoing proxy host names from Step 11.

Step 14 Check the Primary check box if you wish to designate a particular outgoing proxy server as the primary server.

Step 15 Click Submit to save the settings.

Table 8-1 describes Content Distribution Manager GUI parameters and corresponding CLI commands to help you configure HTTP connection settings.

Table 8-1 HTTP Connection Settings GUI Fields

GUI Field

Description

CLI Command

Enable Incoming Proxy

Configures the Content Engine to accept incoming requests on ports in addition to port 80.

http proxy incoming

List of Incoming Ports

Port numbers used by the proxy server or Content Engine to receive requests. This number ranges from 1 to 65535. You can specify up to 8 ports.

http proxy incoming portnumber

Enable Outgoing Proxy

Configures an outgoing proxy server or another Content Engine, without using ICP or WCCP, to receive HTTP cache miss request traffic.

http proxy outgoing

Outgoing Connection Timeout

Timeout period to use when probing for outgoing proxy servers in microseconds. The range is from 200 to 5000000. The default value is 300 microseconds.

http proxy outgoing connection-timeout

Outgoing Monitor Period

Specifies the interval in seconds at which to monitor one outgoing proxy server. If multiple outgoing proxy servers are configured, they are monitored sequentially. The default value is 200 seconds.

http proxy outgoing monitor

Use Origin Server

When enabled, requests are handled by the origin server if all outgoing proxy servers fail. If disabled, the user receives an error message if all outgoing proxy servers fail.

http proxy outgoing origin-server

Preserve 407 headers

Preserves 407 HTTP authentication headers. These headers indicate that the client must first authenticate itself with the proxy server to request cache miss traffic.

http proxy outgoing preserve-407

Outgoing Proxy Host Name

Configures multiple outgoing proxy servers using the host name or IP address for the outgoing proxy server.

http proxy outgoing host {hostname | ipaddress}

Port

Port number corresponding to the outgoing proxy host names.

http proxy outgoing host {hostname | ipaddress} ports 1-65535

Primary

Designates a particular outgoing proxy server as the primary server.

http proxy outgoing host {hostname | ipaddress} ports 1-65535 primary

Configuring HTTP Cache Settings

The HTTP Cache Settings window allows you to configure caching parameters for the caching of HTTP requests.

To configure HTTP caching parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 Choose HTTP/S > HTTP Caching. (See Figure 8-2.)

Figure 8-2 HTTP Cache Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the L4 Switch Support check box to enable redirection using a Layer 4 switch.

Step 6 Check the Anonymize Requests check box to enable stripping of the requesting IP address.

Step 7 Check the Cache Binaries with Cookies check box to enable caching of objects that are served with cookies attached.

Step 8 Check the Enforce Max Object Size check box to enable this feature. An object with a size above the configurable upper limit is not stored by the Content Engine.

Step 9 In the Max Object Size field, specify the maximum object size.

Step 10 Check the URL Validation check box to revalidate every object requested in the cache with the origin server.

Step 11 Choose an option from the Client No Cache drop-down list.

Step 12 Check the Enable Smart Range check box to cache an entire HTTP response even if you issue a Range request and the object is not in the cache.

Step 13 Specify the maximum starting offset of Range request to be cached in the Max Start field. Enter a starting offset value in bytes. The range is 0 to 2147483647. The default is 16384.

Step 14 Specify the maximum interval between any subrange in the Range request in the Max Interval field. Enter a starting offset value in bytes. The range is 0 to 2147483647. The default is 16384.

Step 15 Click Submit to save the settings.

Configuring HTTP Cache Freshness Settings

You can configure HTTP cache object freshness parameters for Content Engines on the CDN network using the HTTP Cache Freshness Settings window from the Content Distribution Manager GUI. These parameters can be configured for either directory listings or particular objects in the cache.

To configure HTTP freshness parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose HTTP/S > HTTP Cache Freshness. (See Figure 8-3.)

Figure 8-3 HTTP Cache Freshness Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Specify a value in the Text Object Age Multiplier field.

The age multiplier value enables the Content Engine to guess the life of a text object by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent results cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 30 percent.

Step 6 Specify a value in the Binary Object Age Multiplier field.

The age multiplier value enables the Content Engine to guess the life of a binary object by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent results cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 60 percent.

Step 7 Choose a value from the Maximum Time-to-Live (TTL) Scale drop-down list.

The TTL sets a ceiling on estimated expiration dates. If an object has an explicit expiration date, this takes precedence over the configured TTL.

Step 8 Specify a value in the Max Text Object TTL field.

The valid range of values is given in Table 8-2.

Table 8-2 Time To Live Range of Values for HTTP Freshness

Scale

Range

Days

1-1825

Hours

1-43800

Minutes

1-2628000

Seconds

1-157680000

Step 9 Specify a value in the Max Binary Object TTL field.

See Table 8-2 for a list of maximum values depending on the scale used.

Step 10 Specify a value in the Minimum TTL field.

A minimum TTL is the minimum time to live for objects in the cache. The range of values is from 0 to 86400 minutes. The default value is 30 minutes.

Step 11 Choose how reevaluation requests are to be handled from the Re-evaluate Request drop-down list.

This allows you to apply these parameters to either the directory listing (text) or both objects and directory listing (all). You can also choose not to apply a TTL scale to these parameters (none). In this case, a TTL is not applied and objects in the cache have no expiration dates.

Step 12 Check the Enable If-Modified-Since check box to specify text and age modifiers in the next two steps.

Step 13 Specify a value in the IMS Text Age Modifier (%) field.

Step 14 Specify a value in the IMS Binary Age Modifier (%) field.

Step 15 Click Submit to save the settings.

Configuring Authenticated HTTP Cache Settings

The authenticated HTTP caching feature allows basic and NT LAN Manager (NTLM) authenticated content to be cached and served to more than one user, while maintaining security. If an authenticated object is cached, then subsequent requests for that object (from new users) require authentication. The cached object is revalidated with the origin server through the authorization header for the new user. If the user is not authorized, the server sends a 401 (Unauthorized) response. If the user is authorized and the object is not modified, the cached object is served to the client.

To configure authenticated HTTP caching parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose HTTP/S > Authenticated HTTP Caching. (See Figure 8-4.)

Figure 8-4 Authenticated HTTP Cache Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Choose an authentication method to cache authenticated content from the Cache Authenticated Content drop-down list.

Step 6 Check the Strip NTLM Headers check box to strip the NTLM headers from the authenticated content.

Step 7 Enter a value for the maximum number of entries that is maintained in the cache in the Max Cached Authenticated Entries field. The default value is 32000 entries.

Step 8 In the Time Authenticated Entries are cached field, enter a value for the amount of time between last access and cache removal from the Content Engine. The range is from 1 to 1440 minutes and the default value is 480 minutes.

Step 9 Click the Re-Authenticate Header type drop-down list and choose a header type message to send to the requesting client when authorization has failed.

Choose to send a 401 (Unauthorized Auth Header) or 407 (Proxy Authorization Required) message when authorization has failed.

Step 10 Check the Append Response Headers check box to enable this feature.

Step 11 Enter the host name or IP address that is receiving the Proxy Authorization header in the Proxy Authorization header field.

Step 12 Check the Use Via Headers check box to include "Via" header in response and replies.

Step 13 Enter the host name or IP address that is receiving the WWW authorization header in the WWW Authentication Server field.

Step 14 Check the use X-FWD-Headers check box to notify the web server of the client's IP address through the X-Forwarded-For header.

Step 15 Click Submit to save the settings.

Configuring Advanced HTTP Cache Settings

Use the Advanced HTTP Caching window to configure advanced cache settings.

To configure advanced HTTP cache settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose HTTP/S > Advanced HTTP Caching. (See Figure 8-5.)

Figure 8-5 Advanced HTTP Cache Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Under the Cache on Abort heading, check the Enable Cache on Abort check box to continue to cache an object if the client has aborted the request.

Step 6 Check the Use Max Threshold check box to cache an object if the number of kilobytes remaining to download from the server is less than the maximum threshold value.

Step 7 Enter a value for the maximum threshold in the Abort Max Threshold field. The default value is 256 kilobytes.

Step 8 Check the Use Min Threshold check box to cache an object if the number of kilobytes remaining to download from the server is greater than the minimum threshold value.

Step 9 Enter a value for the minimum threshold in the Abort Min Threshold field. The default value is 32 kilobytes.

Step 10 Check the Use Percent Threshold check box to cache an object if the percentage of the object already downloaded is greater than the percentage threshold value entered.

Step 11 Enter a value for the percentage threshold in the Abort Percent Threshold field. The default value is 80 percent.

Step 12 Under the Cluster Settings heading, check the Enable Clustering check box to allow a Content Engine in a Content Engine farm to query and obtain cache objects from other Content Engines in the cluster.

Step 13 Enter a value for the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster in the Cluster Heal Port field, if you are not using the default HTTP port value of 80.

The Content Engine that responds to queries from another Content Engine in a Content Engine cluster is called a healing server. The Content Engine that requests a cache object from the cluster is called a healing client.

Step 14 Enter a value for the HTTP port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster in the Cluster HTTP Port field. The default port value for the HTTP healing port is 80.

Step 15 Enter a value for the maximum time in seconds that a healing Content Engine waits for a healing Content Engine response in the Cluster Max Delay field.

Step 16 Enter a value for the maximum number of misses that the healing Content Engine can receive from the cluster after the last healing mode hit response in the Cluster Misses field.

Step 17 Under the Persistent Connections Settings heading, check the Enable Persistent Connections check box to allow persistent connections on the Content Engine. Persistent Connections can be set for client-only, server-only and all connections on the Content Engine.

Step 18 Choose a persistent connection type from the Persistent Connections Type drop-down list. A persistent connection can be set for client-only, server-only and all connections on the Content Engine.

Step 19 Enter a value for the number of seconds that the Content Engine should keep an idle persistent connection open before it closes the connection in the Persistent Connection Timeout field. The default value is 600 seconds.

Step 20 Click Submit to save the settings.

Configuring Outgoing Proxy Exclusion Settings

When in transparent caching mode, the Content Engine can intercept requests sent to another proxy and send these requests to one of the following two destinations:

•Default server—This is the default option. The Content Engine retrieves the objects from the web server itself, or if it is configured to use an outgoing proxy for this protocol, it forwards the request to its outgoing proxy. In this scenario, the client browser configuration is ignored, and the Content Engine configuration is used to retrieve the object from the server.

•Original proxy—The Content Engine forwards the request to the proxy that the client originally addressed the request to. This may be different from the Content Engine's own outgoing proxy for the specified protocol.

ACNS 5.0 software also has an option that allows the administrator to specify a single domain name, host name, or IP address to be globally excluded from proxy forwarding. Domains are entered as an ASCII string, separated by spaces. The wildcard character * (asterisk) can be used for IP addresses (for instance, 172.16.*.*). Requests with a destination specified with wildcard characters bypass the Content Engine proxy as well as the failover proxies.

To configure proxy protocol parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose HTTP/S > Outgoing Proxy Exclusions. (See Figure 8-6.)

Figure 8-6 Outgoing Proxy Exclusions Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable Outgoing Proxy Exclusion check box to intercept requests sent to another proxy and send these requests to either the origin server or a specified proxy server.

Step 6 Enter a single domain name, IP address, or host name in the Outgoing Proxy Exclude List field. The item entered here is globally excluded from proxy forwarding.

Step 7 Choose default-server, original proxy, or reset from the Transparent Proxy Mode drop-down list. See Table 8-3 for an explanation of these choices.

Step 8 Click Submit to save the settings.

Table 8-3 describes the proxy protocols parameters that appear in the Content Distribution Manager GUI and provides the corresponding CLI commands.

Table 8-3 Proxy Protocols Key Parameters

Key Parameter

Description

CLI Command

Default server

The Content Engine retrieves objects from the web server itself. With this option, a proxy-style request can be sent to an outgoing proxy server if such a server is configured.

proxy-protocols transparent default-server

Original-proxy

The Content Engine forwards the request to the original proxy that the client addressed the request to.

proxy-protocols transparent original-proxy

Outgoing proxy exclusion

The domain name, host name, or IP address specified here is to be excluded from proxy forwarding.

proxy-protocols outgoing proxy-exclude

Configuring ICP Settings

Internet Cache Protocol (ICP) is a lightweight message format used for communicating among Content Engines and for supporting interoperability with older proxy protocols. ICP is used to exchange hints about the existence of URLs in neighboring caches in a Content Engine farm. Content Engines exchange ICP queries and replies to gather information for use in selecting the most appropriate location from which to retrieve an object.

Although ICP has traditionally been a way to scale the overall size of a cluster of caches beyond a single unit, history has shown ICP to be a poor way of scaling a cache clustering solution. In fact, because of the way that traffic is currently directed toward a transparent network cache cluster, the requirement for ICP is all but negated for the majority of cache deployments.

The ICPv2 protocol is documented in two standards documents:

•RFC 2186: Internet Cache Protocol (ICP), version 2

•RFC 2187: Application of Internet Cache Protocol (ICP), version 2

Note The ability to act as both an ICP server (servicing requests from neighboring caches) and an ICP client (sending requests to neighboring caches) is supported.

ICP Client Settings

You can configure your Content Engine Farm to generate ICP queries before retrieving requested objects from the Internet using the ICP client functionality.

With ICP functionality, you can configure parent and sibling Content Engines in a hierarchy. ICP parents are essentially one step higher than ICP siblings in a hierarchy of Content Engines.

You can configure a Content Engine to be either a parent or a sibling. Parent Content Engines are able to retrieve data during a cache miss, whereas sibling Content Engines cannot retrieve data and instead forward the request to the parent Content Engines.

To configure ICP client functionality, follow these steps.

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 From the Contents pane, choose HTTP/S > ICP Client. (See Figure 8-7.)

Figure 8-7 ICP Client Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable check box to enable ICP client queries.

Step 6 Specify a value for the timeout period for ICP responses in seconds in the Maximum Reply Wait Time field. The range is from 1 to 30 seconds and the default value is 2 seconds.

Step 7 In the Number of Failures field, specify a value for the number of failures that each Content Engine allows an unresponsive ICP server before it removes that ICP server from the list. The range is from 0 to 100 and the default value is 20 failures.

Step 8 Enter a domain to be excluded from ICP queries in the Excluded Domains field.

Step 9 Click Submit to save the settings.

Use Table 8-4 to help you configure the ICP client using CLI global configuration commands.

Table 8-4 ICP Client CLI Command Summary

Command

Description

icp client enable

Enables client ICP.

icp client add-remote-server

Adds a remote ICP client server.

icp client exclude

Excludes local domains from ICP caching services.

icp client max-fail

Configures the number of failures that each Content Engine allows an unresponsive ICP server before it removes that ICP server from the list.

icp client max-wait

Configures how long the Content Engine waits before retrieving the requested data directly from the Internet.

icp client modify-remote-server

Modifies an ICP server from the list.

ICP Remote Client Settings

To add a remote ICP client to the ICP client list using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > ICP Remote Client.

Step 4 Click the Create New ICP Remote Client icon. (See Figure 8-8.)

Figure 8-8 ICP Remote Clients

Step 5 Enter the host name or IP address for the ICP remote client in the Client Name field.

Step 6 Check the Fetch Misses check box to configure the Content Engine to act as a parent server to the designated client. If the Content Engine cannot satisfy the client's request, it forwards the request to another server or the Internet.

Step 7 Click Submit to save the settings.

ICP Server Settings

You can also configure a Content Engine to act as an ICP server. This allows the Content Engine to probe the hierarchy of Content Engines by multicasting an ICP message to ICP parent and sibling clients in the hierarchy.

To configure ICP server functionality, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > ICP Server. (See Figure 8-9.)

Figure 8-9 ICP Server Settings Window

Step 4 Click the Add Group Settings button if no settings have been established.

Step 5 Check the Enable check box to enable ICP server queries.

Step 6 In the ICP Port field, designate a port that will listen for ICP requests on the server.

Step 7 In the HTTP Port field, specify a value for the HTTP port to listen for ICP-generated requests on the server.

Step 8 Click Submit to save the settings.

Table 8-5 describes the ICP server parameters that appear in the Content Distribution Manager and provides the corresponding CLI global configuration commands.

Table 8-5 ICP Server CLI Command Summary

Command

Description

icp server enable

Enables sever ICP.

icp server http-port

Configures HTTP proxy port to listen for ICP-generated requests. The range is from 0 to 65535. The default port number is 3128.

icp server port

Configures ICP server port on a Content Engine to listen for ICP requests. The range is from 0 to 65535. The default port number is 3130.

icp server remote-client

Modifies an ICP client from the list.

ICP Remote Server Settings

To add a remote ICP server to the ICP server list using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > ICP Remote Server. Click the Create New ICP Remote Server icon. (See Figure 8-10.)

Figure 8-10 ICP Remote Server Settings Window

Step 4 Enter the host name or IP address for the ICP remote server in the Server Name field.

Step 5 Check the Parent check box to enable the configured ICP server to act as a parent server and retrieve cache miss data. If this box is not checked, the configured ICP server will not retrieve cache miss data.

Step 6 In the ICP Port field, enter the ICP port to which ICP queries are directed at this ICP server. The range is from 0 to 65535 and the default port is 3130.

Step 7 In the HTTP Port field, enter the HTTP port on the ICP server to which proxy-style requests are forwarded. The range is from 0 to 65535 and the default port is 3128.

Step 8 Enter a list of excluded domains in the Excluded Domains field, if you want to limit ICP requests directed toward this ICP server to a specific set of domains. Otherwise, all ICP requests (aside from those specified as "local domains") are forwarded to this ICP server.

Step 9 Click Submit to save the settings.

Configuring Client Proxy Autoconfiguration Settings

ACNS 5.0 software supports 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.

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 proxy 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 the URL syntax to enter in the proxy automatic configuration URL field of the browser:

http://ContentEngine-IPaddress:portnumber/theproxyfile.pac

Note Use a port number specified by the proxy incoming settings for configuring proxy incoming ports. For instance, if port 8080 is specified, then use 8080 as your port number in the example shown.

To configure proxy autoconfiguration, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > Client Proxy Autoconfig. (See Figure 8-11.)

Figure 8-11 Client Proxy Auto Config Settings Window

Step 4 Click the Add Group Settings button if no settings have been established.

Step 5 Check the Enable check box to enable proxy autoconfiguration.

Step 6 Enter a host name or an IP address in the Remote FTP Server Host Name Field if you are downloading the .pac file from a remote FTP server.

Step 7 Enter the name of the autoconfiguration file to be accessed in the remote FTP server in the Remote File (full pathname) field.

Step 8 Enter a username or ID in the User name field to gain access to the FTP server.

Step 9 Enter a password used to access the file in the remote FTP server.

Step 10 Enter the password again in the Confirm Password field.

Step 11 Click Submit to save the settings made.

Configuring WCCP Bypass

One of the fundamental principles of transparent network request redirection and caching solution is that the Content Engine must remain transparent to the end user at all times. A transparent caching solution in a CDN environment must not introduce any possible failure conditions or side effects in the network.

The Cisco CDN transparent caching solution uses a WCCP-enabled router and various advanced techniques to ensure that the Content Engine remains transparent, even if web browsers are nonoperational or web servers are not HTTP-compliant.

If a Content Engine becomes overwhelmed with traffic, it can use the overload bypass feature to reroute the overload traffic. When the Content Engine is overloaded and the bypass load command is enabled, the Content Engine refuses additional requests and forwards them to the origin servers. If the load remains too high, more traffic is bypassed to the servers, and so on until the Content Engine can handle the load. The time interval between one bucket being bypassed and the next is set by the out-interval option. The default is 4 seconds. (See Figure 8-12.)

Figure 8-12 Overload Bypass

When the first bucket bypass occurs, a set interval must elapse before the Content Engine begins to again service the bypassed buckets. The duration of this interval is set by the time-interval option. The default is 10 minutes.

When the Content Engine begins to service the bypassed traffic again, it begins with a single bypassed bucket. If the load is serviceable, it picks up another bypassed bucket, and so on. The time interval between picking up one bucket and the next is set by the in-interval option. The default is 60 seconds.

Authentication Traffic Bypass

Because of IP authentication, some websites do not allow the Content Engine to connect directly on behalf of the client. In order to preserve cache transparency and avoid disruption of service, the Content Engine can use authentication traffic bypass to automatically generate a dynamic access list for the selected client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in the case of hierarchical caching.

Note The bypass feature is only available when WCCP Version 2 is enabled in your local network.

Configuring WCCP Bypass Settings

To configure WCCP bypass settings, follow these steps.

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > WCCP Bypass Settings. (See Figure 8-13.)

Figure 8-13 WCCP Bypass Settings Window

Step 4 Click the Add Group Settings button if no settings have been established.

Step 5 Check the Load Bypass Enable check box to enable traffic bypass.

Step 6 Specify a value (in seconds) for the Interval between bypassing buckets field.

When the Content Engine is overwhelmed with traffic and the bypass option is enabled, it bypasses traffic one bucket at a time until it is no longer overloaded. This field represents the amount of time between the bypassing of one bucket and the next. The default value is 4 seconds.

Note A bucket is defined as a certain subsection of the allotted hash assigned to each Content Engine in a Content Engine farm. If only one Content Engine exists in this environment, it has 256 buckets assigned to it.

Step 7 Specify a value (in minutes) for the Time that a bucket is bypassed field.

Once a bucket is bypassed and the Content Engine remains in bypass mode, it does not attempt to pick up the bypassed load for the number of minutes specified in this field. The default value is 10 minutes.

Step 8 Specify a value (in seconds) for the Time interval between buckets coming back field.

Once the time interval allotted to bypass mode has been surpassed, the Content Engine begins to pick up bypassed traffic one bucket at a time. The time between the pickup of each bucket is measured in seconds. The default value is 2 seconds.

Step 9 Check the Authentication Bypass check box to enable this feature.

Note Some websites may not allow the Content Engine to connect directly on behalf of the client. In order to avoid a disruption of service when traffic is bypassed, the Content Engine can use authentication bypass to generate a dynamic access list for these client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in a CDN environment.

Step 10 Specify a value (in minutes) for the Bypass entry expiration time field.

This value represents the number of minutes that an idle client/server pair remains on the bypass access list. The default value is 20 minutes.

Step 11 Choose a method for handling errors from the drop-down list. Choose transparent, reset-connection, or send-cache-error.

Step 12 Click Submit to save the settings.

Viewing WCCP Bypass Lists

The Content Engine can use authentication bypass to generate a dynamic access list for client-server pairs. To generate these lists with the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > WCCP Bypass List.

Step 4 Click the Create New WCCP Bypass List Entry Remote Server icon. (See Figure 8-14.)

Figure 8-14 Creating New Static WCCP Bypass List Entry Window

Step 5 Enter the IP address for the client in the Client Address field.

Step 6 Enter the IP address for the server in the Server Address field.

Step 7 Check Submit to save the settings.

Configuring HTTPS Proxy Settings

Cisco ACNS 5.0 software supports HTTPS in the following two scenarios:

•The Content Engine receives an HTTPS request sent by a web client configured to use the Content Engine as an HTTPS proxy server.

•The Content Engine in transparent mode intercepts a request sent by a web client to another HTTPS proxy server.

In both cases the Content Engine creates a connection to the origin server (directly or through another proxy server) and allows the web client and origin server to set up a Secure Socket Layer (SSL) tunnel through the Content Engine.

Note A Domain Name System (DNS) server must be configured in order to support HTTPS proxy requests. See the "Configuring the Domain Name System Server" section for more information.

To configure HTTPS proxy parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose HTTP/S > HTTPS Proxy. (See Figure 8-15.)

Figure 8-15 HTTPS Proxy Settings Window

Step 4 Click the Add Group Settings button if no settings have been established.

Step 5 Check the Enable Incoming Proxy check box to allow the Content Engine to accept incoming requests on ports in addition to port 80.

Step 6 Enter the port numbers used by the proxy server in the List of Incoming Ports field.

Step 7 Check the Enable Outgoing Proxy check box to enable the use of an outgoing proxy, if needed.

Step 8 Enter an IP address or host name in the Outgoing Proxy Hostname field.

Step 9 Enter a port number in the Outgoing Proxy Port field that will be used by the outgoing proxy server to accept proxy HTTPS requests.

Step 10 Choose the desired level of security (allow or deny) from the Handle HTTPS Traffic drop-down list.

Step 11 Enter a list of port numbers in the Port List field. Enter all if all ports are to be allowed or denied access.

Step 12 Click Submit to save the settings.

Table 8-6 shows key GUI parameters and CLI commands associated with HTTPS proxy features. The order in which the CLI commands are entered is not important.

Table 8-6 HTTPS Proxy Features

Key GUI Parameter

HTTPS Proxy Features

CLI Command (Abbreviated Syntax)

Enable incoming proxy

Configures the Content Engine to accept incoming HTTPS traffic request on ports in addition to port 80.

https proxy incoming

List of incoming ports

Supports up to 8 incoming proxy ports.

https proxy incoming ports 1-65535, port, . . .

Enable outgoing proxy

Enables outgoing HTTPS proxy server.

https proxy outgoing host {hostname | ipaddress} ports 1-65535

Outgoing proxy hostname

IP address or host name of the HTTPS outgoing proxy server.

https proxy outgoing host {hostname | ipaddress}

Outgoing proxy port

Port of the HTTPS outgoing proxy server.

https proxy outgoing host {hostname | ipaddress} ports 1-65535

Note HTTPS traffic is encrypted and cannot be interpreted by the Content Engine or any other device between the web client and the origin server. HTTPS objects are not cached.

Configuring Caching Protocols

You can configure caching protocols such as FTP, RTSP, and WMT for the Content Engine and device groups. Tasks include:

•Configuring FTP Connection Settings

•Configuring Licensing and Enabling Streaming Servers

•About the RTSP Gateway

•About Windows Media Technologies

Configuring FTP Connection Settings

The Content Engine has the ability to handle FTP-style requests over HTTP transport when configured in proxy mode. When the Content Engine receives an FTP request from a client, it processes the request by searching its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server if this proxy server has been configured, or it fetches the object directly from the origin FTP server.

To configure FTP connection settings using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose FTP > FTP Connections. (See Figure 8-16.)

Figure 8-16 FTP Connection Settings Window

Step 4 Check the Enable Incoming Proxy check box to accept incoming FTP requests on ports in addition to port 80.

Step 5 Check the Enable Incoming Active Mode check box to enable the Content Engine to act in FTP active mode.

Step 6 In the List of Incoming Ports field, enter port numbers used by the FTP proxy server or Content Engine to receive requests.

Step 7 Check the Enable Outgoing Proxy check box to allow an outgoing FTP proxy server or another Content Engine to receive FTP cache miss request traffic.

Step 8 Enter the host name or IP address for the outgoing FTP proxy host name in the Outgoing Proxy Host Name field.

Step 9 In the Outgoing Proxy Port field, enter a port number corresponding to the outgoing proxy host name from Step 7.

Step 10 Enter the password needed to access the FTP proxy server in the Outgoing Proxy Password field.

Step 11 Reenter the password needed to access the FTP proxy server in the Confirm Outgoing Proxy
Password field.

Step 12 Click Submit to save the settings.

Table 8-7 describes the FTP connection setting parameters that appear in the Content Distribution Manager GUI, and provides the corresponding CLI commands.

Table 8-7 FTP Connection Settings GUI Fields

GUI Field

Description

CLI Command

Enable Incoming Proxy

Configures the Content Engine to accept incoming FTP requests on ports in addition to port 80.

ftp proxy incoming

Enable Incoming Active Mode

Configures the Content Engine to support FTP active mode. By default, the FTP mode supported is passive.

fttp proxy active-mode enable

List of Incoming Ports

Port numbers used by the proxy server or Content Engine to receive FTP requests. This number ranges from 1 to 65535. You can specify up to 8 ports.

ftp proxy incoming portnumber

Enable Outgoing Proxy

Configures an outgoing proxy server or another Content Engine, without using ICP or WCCP, to receive FTP cache miss request traffic.

ftp proxy outgoing

Outgoing Proxy Host Name

Configures multiple outgoing proxy servers. Enter the host name or IP address for the outgoing FTP proxy server.

ftp proxy outgoing host {hostname | ipaddress}

Outgoing Proxy Port

Port number corresponding to the outgoing FTP proxy host names.

ftp proxy outgoing host {hostname | ipaddress} ports 1-65535

Outgoing Proxy Password

Password required to access outgoing FTP proxy server.

Confirm Outgoing Proxy Password

Repeat the password required to access outgoing FTP proxy server.

Setting FTP Cache Freshness

You can configure FTP cache object freshness parameters for Content Engines on the CDN network using the FTP Cache Freshness Settings window from the Content Distribution Manager GUI. These parameters can be configured for either directory listings or particular objects in the cache.

To configure FTP freshness parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose FTP > FTP Cache Freshness. (See Figure 8-17.)

Figure 8-17 FTP Cache Freshness Settings Window

Step 4 Click the Add Group Settings button if no settings have been established.

Step 5 Specify a value for the Directory Listing Age Multiplier field.

The age multiplier value enables the Content Engine to guess the life of a directory by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent requests for the object cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100 percent. The default value is 30 percent.

Step 6 Specify a value for the File Object Age Multiplier field.

The age multiplier value enables the Content Engine to guess the life of an object by multiplying the time since the object was last modified by a percentage to obtain an approximate expiration date. After this date, the object is considered stale, and subsequent results cause a fresh retrieval by the Content Engine. Valid values range from 0 to 100%. The default value is 60%.

Step 7 Choose a value for the Max Time to Live (TTL) Scale field from the drop-down list.

The TTL sets a ceiling on estimated expiration dates. If an object has an explicit expiration date, this takes precedence over the configured TTL.

Step 8 Specify a value for the Max Directory Listing TTL field.

The valid range of values is given in Table 8-8.

Table 8-8 Time To Live Range of Values for FTP Freshness

Scale

Range

Days

1-1825

Hours

1-43800

Minutes

1-2628000

Seconds

1-157680000

Step 9 Specify a value for the Max File Object TTL field.

See Table 8-8 for a list of maximum values depending on the scale used.

Step 10 Specify a value (in minutes) for the Minimum TTL field.

A minimum TTL is the minimum time to live for objects in the cache. The range of values is 0 to 86400 minutes. The default value is 30 minutes.

Step 11 Check the Enforce Max Object Size check box to enforce the maximum object size specified in the next step.

Step 12 Specify a value in the Max Object Size field.

This value represents the maximum object size (in kilobytes) that can be stored. The range of values is 1 to 1048576 kilobytes. The default value is set to the maximum value of 1048576 kilobytes.

Step 13 Choose a method for handling reevaluation requests from the Re-eval Request drop-down list.

You can apply these FTP cache freshness parameters to the directory listing or to objects as well as the directory listing. You can also choose not to apply a TTL scale to these parameters. In this case, a TTL is not applied, and objects in the cache have no expiration dates.

Step 14 Click Submit to save the settings.

Configuring Licensing and Enabling Streaming Servers

Cisco ACNS devices support a wide variety of streaming media types, including RealNetworks RealMedia, Microsoft Windows Media Server, and Apple QuickTime.

In order for your CDN devices to be able to serve these media types, you must tell the CDN that a particular media player type is present.

Note You must enable licenses for streaming media on each Content Engine individually in the CDN network before you can enable these streaming licenses on a device group.

If there is a particular media type that you do not want to serve through your CDN, you need to disable the corresponding media player so that your CDN devices do not attempt to serve that media type.

Using the media player mappings in the manifest file, you can customize your content type mappings from MIME content types or file extensions to configured media players. See the "Working with Manifest Files" section for more information on configuring manifest files.

Note Modifying the configuration of any media players causes any CDN devices running that media player software to restart and register the configuration change. Depending on the number and location of devices that restart following a media player configuration change, you may experience a temporary interruption in service for the time it takes your devices to come back online—usually a few minutes.

About the RTSP Gateway

Real-Time Streaming Protocol (RTSP) is a standard Internet streaming control protocol (RFC 2326). It is a widely used application-level protocol that controls the delivery of data with real-time properties, such as video and audio. Apple QuickTime, RealNetworks, and the Cisco Streaming Engine use RTSP as a streaming control protocol.

The RTSP gateway is a process running on the Content Engine that accepts an RTSP request and performs the initial RTSP contact with RTSP-based clients (RealMedia, QuickTime, and so on) on behalf of the RTSP-based streaming servers available on the Content Engine. From information derived from the initial request operation, the RTSP gateway queries the URL filtering, rules, authentication, and unified name space (UNS) agents to determine whether or not the content is pre-positioned.

Note Pre-positioned content requests are only accepted and served on the RTSP gateway (for both RealMedia and the Cisco Streaming Engine) default port number 554. If the default RTSP port number is changed to any other port number on the Content Engine when the Content Engine is waiting for RTSP pre-positioned content from the origin server, the Content Engine will be unable to serve the content.

The RTSP gateway is always enabled and cannot be disabled. Based on the properties of the incoming request, including such properties as user agent, final destination, and media file type, the RTSP gateway performs these tasks:

•Forwards the incoming request to the RealProxy that resides on the same Content Engine as the RTSP gateway

•Forwards the incoming request to the RealSubscriber that resides on the same Content Engine as the RTSP gateway

•Forwards the incoming request to the Cisco Streaming Engine

•Redirects the incoming request

•Rejects the incoming request

Note If the request is a WCCP transparently redirected request, the RTSP gateway cannot process the request and instead redirects it and adds bypass entries. For those requests that are forwarded to content servers, and for which an acknowledgement is received, responses are passed on to the client.

The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RealPlayer client software. The RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy window of the Content Engine management GUI. Detailed configuration, statistics, and reporting of RealProxy status are obtained through the RealAdministrator GUI. Table 8-9 lists RealProxy-related features of ACNS 5.0 software.

A RealProxy window has been added to the Content Engine management GUI. See the "Enabling RealProxy" section. The Admin button is active on the Content Engine Management GUI when the RealProxy software is installed and enabled. You will be provided with a default username and password to access this administration window from the Content Engine GUI.

Note You must configure disk space to include mediafs storage with the disk config EXEC command before you can run streaming media using RealProxy.

Configuring the RTSP Gateway

To configure RTSP gateway parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose RTSP > RTSP Gateway. (See Figure 8-18.)

Figure 8-18 RTSP Gateway Settings Window

Step 4 Click the Add Group Settings button if no settings have been established.

Step 5 In the Incoming Port field, enter the port number used by the RSTP proxy to receive requests.

Step 6 In the IP-Address field, enter the IP address of the RTSP gateway. This is usually the Content Engine that is serving the requested content.

Step 7 Check the Enable L4 Switch Support check box to enable redirection using a Layer 4 switch.

Table 8-9 describes the RTSP gateway parameters that appear in the Content Distribution Manager GUI and provides the corresponding CLI commands.

Table 8-9 RTSP Gateway-Related Features

Key Parameter

Function

CLI Command

Incoming Port

Specifies the ports on which to listen for RTSP requests.

rtsp ports

IP Address

Specifies the IP address of the RTSP gateway.

rtsp ip-address

Layer 4 Switch Support

Enables redirection with a Layer 4 switch, such as a Cisco CSS 11000 series switch.

rtsp L4-switch enable

Enabling RealProxy

RealProxy software is configured using the RealSystem administrator GUI, which is accessed from the RealProxy page of the Content Engine management GUI. See the Cisco ACNS Caching Configuration Guide, Release 5.0 for more information on how to access the RealProxy GUI from the Content Engine GUI.

ACNS 5.0 software includes RealServer Version 8.0.2.471 as an optional component that is used as a streaming media engine.

Note You must enable a RealProxy streaming license on each Content Engine on the CDN network before you can enable RealProxy on a device group.

To enable RealProxy on a Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. If you have registered Content Engines, the Content Engines window appears.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose RTSP > Real Proxy. The Real Proxy License Settings window appears. (See Figure 8-19.)

Figure 8-19 Real Proxy License Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable check box to activate the RealProxy license.

Step 6 Alternatively, check the Evaluate check box to use a temporary 60-day license.

Step 7 In the License Key field, enter the license key number to obtain a permanent RealProxy license.

Step 8 Click Submit to save the settings.

Enabling RealSubscriber

ACNS 5.0 software includes RealServer Version 8.0.2.471 as an optional component that is used as a streaming media engine. When RealServer software is configured for subscriber-only mode, it is referred to as RealSubscriber.

To enable RealSubscriber on a Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. If you have registered Content Engines, the Content Engines window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 Click RTSP > Real Subscriber. The RealSubscriber License Settings window appears. (See Figure 8-20.)

Figure 8-20 Real Subscriber License Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable check box to activate a RealSubscriber license.

Step 6 Alternatively, check the Evaluate check box to use a temporary 60-day license.

Step 7 In the License Key field, enter the license key number to obtain a permanent RealSubscriber license.

Step 8 Click Submit to save the settings.

Enabling the Cisco Streaming Engine

ACNS 5.0 software includes support for a standard RTSP server, also known as the Cisco Streaming Engine solution for RTSP streaming media protocol.

Note You do not need a license to use the Cisco Streaming Engine to deliver RTSP streaming media.

To configure Cisco Streaming Engine parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose RTSP > Cisco Streaming Engine. (See Figure 8-21.)

Figure 8-21 Cisco Streaming Engine Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable check box to allow use of the Cisco Streaming Engine for RTSP protocols.

Step 6 Click Submit to save the settings.

About Windows Media Technologies

Microsoft Windows Media Technologies (WMT) Version 7.01 is a set of streaming solutions for creating, distributing, and playing back digital media files on the Internet. WMT includes the end user application (Windows Media Player) and the server and distribution application (Windows Media Server). To disseminate live and pre-positioned Windows Media content on a Content Delivery Network (CDN), you need WMT caching proxy and server capabilities on the Content Engine.

Enabling WMT

Note You must configure disk space to include mediafs storage with the disk config EXEC command before you can run streaming media using WMT.

Note You must enable a WMT streaming license on each Content Engine on the CDN network before you can enable WMT on a device group.

To configure WMT parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. If you have registered Content Engines, the Content Engines window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 Click WMT > WMT License. The WMT License Settings window appears. (See Figure 8-22.)

Figure 8-22 WMT License Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable WMT Services check box to enable WMT.

Step 6 Check the Enable WMT Proxy check box to enable WMT caching proxy functionality.

Step 7 Alternatively, check the Evaluate check box to use a temporary 60-day license.

Step 8 In the License Key field, enter the license key number to obtain a permanent WMT license.

Step 9 Click Submit to save the settings.

Configuring WMT General Settings

The Content Engine acting as a WMT proxy supports a basic proxy feature—it accepts incoming WMT streaming requests from clients and acts on behalf of the clients communicating with an origin server. The WMT proxy accepts and serves the streaming requests over the Microsoft Media Server (MMS) protocol as well as the HTTP protocol. (See Figure 8-23.) MMS is the protocol that WMT uses for communication between players and servers.

Figure 8-23 Content Engine as Conventional WMT Caching Proxy

When possible, the WMT proxy also caches streaming content and serves the request from the cache instead of from the origin server. It accepts transparently intercepted requests (through WCCP or Layer 4 [L4] redirect) as well as manual proxy requests (clients configured to use an upstream proxy).

The WMT proxy also supports multicasting and splitting of live streams (that is, it splits a single inbound feed to multiple clients).

Note For MMS over TCP and UDP, the proxy always fetches the stream from a server using TCP (MMST), so that the item cached is reliable and complete for future delivery. Streams requested using HTTP will be fetched using HTTP.

To configure WMT general settings parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose WMT > WMT General. (See Figure 8-24.)

Figure 8-24 WMT General Settings Window

Step 4 Under the WMT Settings heading, click the Add Settings button if no settings have been established.

Step 5 Under the WMT Proxy Settings heading, check the Enforce Max Object Size check box to allow the maximum size for an object to be cached.

Step 6 Enter a value (in megabytes) in the Max Object Size field. The default value is 1024 megabytes.

Step 7 Check the Enable L4 Switch Support check box to enable redirection using a Layer 4 switch.

Step 8 Under the WMT General Settings heading, disable WMT traffic accordingly.

a. Check the Disable HTTP WMT Traffic check box to disallow HTTP WMT traffic (streaming over http://).

b. Check the Disable TCP WMT Traffic check box to disallow TCP WMT traffic (mmst://).

c. Check the Disable UDP WMT Traffic check box to disallow UDP WMT traffic (mmsu://).

Step 9 In the Port to handle WMT Traffic field, enter the port number used by WMT to receive requests. The default port number used for WMT traffic is 1755.

Step 10 Enter a value in the Maximum Concurrent Connections field. The default value is 3000 sessions.

Step 11 Check the Enforce Maximum Bitrate check box to allow the maximum bit rate that can be served.

Step 12 Enter a value in kilobytes per second in the Maximum Bitrate field.

Step 13 Click Submit to save the settings.

Use Table 8-10 to help you configure WMT general settings using both GUI parameters and CLI global configuration commands.

Table 8-10 WMT General Settings Window

Key GUI Parameter

Description

CLI Command

Enforce Max Object Size

Maximum object size that can be cached.

wmt cache max-obj-size

Enable L4 Switch Support

Enables redirection with a Layer 4 switch, such as a Cisco CSS 11000 series switch.

wmt l4-switch

Max Object Size (MB)

Specifies maximum value of streaming media object in megabytes (MB).

wmt cache max-obj-size

Disable HTTP WMT Traffic

Disallows HTTP (streaming over http://).

wmt disallowed-client-protocols HTTP

Disable TCP WMT traffic

Disallows TCP (mmst://).

wmt disallowed-client-protocols TCP

Disable UDP WMT Traffic

Disallows UDP (mmsu://).

wmt disallowed-client-protocols UDP

Port to handle WMT Traffic

Port number used by WMT to receive requests, between 1 and 65535. If a particular port is not specified, port 1755 is used as the default.

wmt incoming port number 1-65535

Maximum Concurrent Connections

Number of maximum unicast clients that can be served. The range depends on the physical limitations of the platform. The default value is 2500.

wmt max-concurrent-sessions

Enable Maximum Bitrate

Enables enforcement of the maximum stream bit rate that can be served.

wmt max-bitrate

Maximum Bitrate (Kbps)

Maximum stream bit rate that can be served. The range is 0 to 2147483647 kbps. There is no default value.

wmt max-bitrate

Configuring WMT Multicasting

IP multicasting is a bandwidth-conserving technology that reduces network traffic by simultaneously delivering a single stream of datagrams to multiple hosts that belong to a group application and which are interested in the same stream of datagrams. Traditional IP communication allows for a single source to send packets to a single host (unicast transmission) or to all hosts (broadcast transmission). IP multicasting allows for a third possibility: allowing a host to send packets to a subset of all hosts as a group transmission.

Multicasting Scenarios

Based on the capabilities and limitations of the network, a Content Engine can receive and deliver WMT streaming content through IP multicast in the following three configuration scenarios:

•Configuring Unicast-In Multicast-Out

•Configuring Multicast-In Multicast-Out

•Configuring Multicast-In Unicast-Out

The unicast-in multicast-out multicast delivery feature enables you to distribute streaming media efficiently by allowing different devices on the IP multicast to receive a single stream of media content from the Content Engine simultaneously. This can save significant network bandwidth consumption, because a single stream is sent to many devices, rather than sending a single stream to a single device every time that this stream is requested. This multicast delivery feature is enabled by setting up a multicast address on the Content Engine to which different devices, configured to receive content from the same channel, can subscribe. The delivering device sends content to the multicast address set up at the Content Engine, from which it becomes available to all subscribed receiving devices.

The multicast-in multicast-out multicast receive feature enables you to receive multicast WMT streams delivered through IP multicasting and then relay them to end users through another delivery channel (unicast or multicast).

The two WMT multicast-out features combined enable you to receive and deliver WMT streaming media content through IP multicasting, and to do conversions from multicast to unicast (and vice versa).

The multicast-in unicast-out scenario enables you to create a broadcasting publishing point to deliver an incoming stream live to requesting clients using multicast as the source of the streaming media.

Note You must accept a WMT license and enable WMT on the Content Engine and Device Groups before you can use enable WMT multicasting in your ACNS 5.0 network. See the "Enabling WMT" section.

Each station needs a multicast IP address. You must enter a valid Class D IP address multicast address in the range 224.0.0.0 to 239.255.255.255, except for the reserved IP ranges based on RFC 1700 and related documents as follows:

•224.0.0.0 to 224.0.6.255

•224.0.13.0 to 224.0.13.255

•224.1.0.0 to 224.2.255.255

•232.0.0.0 to 232.255.255.255

Note You must choose a multicast IP address that does not conflict internally within the same multicast-enabled network configuration. This multicast IP address is not related to the IP address of the Content Engine. (See the "Unusable IP Multicast Addresses" section.)

The allowed multicast port range defined ranges from 1 through 65535. However, the multicast-enabled network may impose certain restrictions on your choice of port. Normally, port numbers below 1024 should be avoided, but the Content Engine does not enforce any restrictions.

Note If a live stream is interrupted at the server side, you must stop the multicast station and then restart the same station to resume live multicasting.

Configuring Unicast-In Multicast-Out

To enable WMT multicasting for unicast-in multicast-out, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose WMT > WMT Multicast Stations. (See Figure 8-25.)

Figure 8-25 WMT Multicast Station Configuration

Step 4 Click the Create New Multicast Station icon.

Step 5 In the Station Name field, enter a name for the multicast station.

Step 6 In the Address field, enter a Class D IP address to be used as the multicast station IP address.

Step 7 In the Port field, enter the port number to be used by this station.

Step 8 In the Media field, enter the source of the WMT streaming media.

Step 9 Check the Repeat Forever check box if you want this source to play the media files without interruption. The multicast stream stops playing once the end of the source.nsc file has been reached, unless this check box has been checked.

Step 10 Click Submit to save the settings.

In this example a multicast station named Multicast Station 1 is configured and used by the Content Engine as the multicast source file. Its Class D IP address is 233.33.33.33 and the multicast port is 3333. The Repeat Forever option is enabled. When the input source.asf file is a VOD file, the multicast automatically restarts from the beginning of the source.asf file once the end of this file has been reached.

Note This source file source.asf can be located on any WMT server, including a Windows server, or the Content Engine. In the case of the Content Engine, pre-positioned media files should be stored in the /local1/wmt_vod directory. In this scenario, the media source is represented by mms://CEIPaddress/wmt_vod/source.asf, where CEIPaddress is the IP address of the Content Engine.

Step 11 Open your WMT player and choose File > Open URL. Enter the following URL:

http://CEIPaddress/MulticastStation1.nsc

Step 12 Click OK. The WMT player should retrieve the multicast description .nsc file and join the multicast station that is specified in Step 5.

Note The use of port 80 is implied in the URL for WMT multicasting. An equivalent URL is http://CEIPaddress:80/test1.nsc.

Configuring Multicast-In Multicast-Out

In this multicasting scenario, a description file *.nsc is created that is accessible through multicast-out to clients. This is similar to the unicast-in multicast-out scenario except that the input source is multicast. The clients use this description file to subscribe to the multicast.

To enable WMT multicasting for multicast-in multicast-out, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose WMT > WMT Multicast Stations. (See Figure 8-26.)

Figure 8-26 WMT Multicast Station Configuration

Step 4 Click the Create New Multicast Station icon.

Step 5 In the Station Name field, enter a name for the multicast station.

Step 6 In the Address field, enter a Class D IP address to be used as the multicast station IP address.

Step 7 In the Port field, enter the port number to be used by this station.

Step 8 In the Media field, enter the multicast source *.nsc file.

Step 9 Check the Repeat Forever check box if you want this source to play the media files without interruption. The multicast stream stops playing once the end of the source*.nsc file has been reached, unless this check box has been checked.

Step 10 Click Submit to save the settings.

In this example, a multicast station named Multicast Station 2 is configured and used by the Content Engine as the multicast source file. Its class D IP address is 233.33.33.34 and the multicast port is 3334. The multicast stream stops playing once the end of the source*.nsc file has been reached, unless Repeat Forever has been enabled.

Note This source file source.asf can be located on any WMT server, including a Windows server, or the Content Engine. In the case of the Content Engine, pre-positioned media files should be stored in the /local1/wmt_vod directory. In this scenario, the media source is represented by mms://CEIPaddress/wmt_vod/source.asf, where CEIPaddress is the IP address of the Content Engine.

Step 11 Open your WMT player and choose File > Open URL. Enter the following URL:

http://CEIPaddress/MulticastStation2.nsc

Step 12 Click OK. The WMT player should retrieve the multicast description .nsc file and join the multicast station that is specified in Step 5.

Note The use of port 80 is implied in the URL for WMT multicasting. An equivalent URL is http://CEIPaddress:80/test1.nsc.

Configuring Multicast-In Unicast-Out

In this scenario, a unicast-out publishing point is created to deliver the incoming stream live to requesting clients. This converts the multicast stream to unicast and sends it to the requesting client.

To enable WMT multicasting for multicast-in unicast-out, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose WMT > WMT Broadcast Alias. (See Figure 8-27).

Figure 8-27 WMT Broadcast Alias Window

Step 4 Click the Create New WMT Broadcast Alias icon.

Step 5 In the Broadcast Alias field, enter an alias for the station name.

Step 6 In the Source URL field, enter the URL of the station to be used for the broadcast.

Step 7 Click Submit to save the settings.

In Figure 8-27, a unicast publishing point with the alias name broadcast1 is configured with a multicast source station.nsc file. This source is a server sending out WMT multicast streams. The source of an alias in the format http://server/file.nsc signals the Content Engine to treat this source as a multicast input source.

Step 8 Open your WMT player and choose File > Open URL. Enter the following URL:

mms://CEIPaddress/broadcast1

Step 9 Click OK. The WMT player should receive the MMS media source specified in Step 5. Note that in this scenario, an MMS URL is used to access the streaming media, and that only the alias-name is specified instead of the *.nsc files as in the multicast-out scenarios.

This converts the multicast stream to unicast and sends it to the requesting client.

Configuring WMT Station Schedules

To configure WMT station schedules for the Content Engine, follow these steps:

Step 1 Choose Devices > Content Engines. The Content Engine window appears.

Step 2 Click the Edit icon next to the Content Engine whose station schedule you want to set. The Contents pane appears on the left.

Step 3 From the Contents pane, choose WMT > WMT Station Schedules. The WMT Station Schedule for Content Engine window appears.

Step 4 Click the Create New WMT Station Schedule icon. The Creating New WMT Station Schedule for Content Engine window appears.

Step 5 Choose a multicast station from the Station Name drop-down list.

Step 6 Enter the month (1-12) in the Month field.

Step 7 Enter the day (1-31) in the Day field.

Step 8 Enter hour (0-23) in the Hour field.

Step 9 Enter the minute (0-59) in the Minute field.

Step 10 Click Submit to save the settings.

Configuring Platform and System Settings

You can configure the file system, system log settings, Network Time Protocol (NTP) server, and Cisco Discovery Protocol (CDP) server for the Content Engine. Tasks include:

•Configuring the Domain Name System Server

•Configuring System Logging

•Configuring NTP Settings

•Configuring CDP Settings

Configuring the Domain Name System Server

To configure the Domain Name System (DNS) server settings, go to the DNS Settings window. DNS allows the network to translate domain names entered in requests into their associated IP addresses.

To configure DNS server settings for a Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Platform > DNS. (See Figure 8-28.)

Figure 8-28 DNS Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable DNS Caching check box to enable DNS caching.

Step 6 Enter a value in the Maximum Cached DNS Entries field.

Step 7 Enter a local domain name in the Local Domain Name field.

Step 8 Enter a list of DNS servers used by the network in the List of DNS Servers field.

Step 9 Click Submit to save the settings.

Use Table 8-11 to help you configure DNS using both GUI parameters and CLI global configuration commands.

Table 8-11 DNS Server Settings Window Parameters

Key Parameter

Description

CLI Command

Enable DNS Caching

Enables DSN caching in the system.

dns enable

Maximum Cached DNS Entries

Defines the size of the DNS cache hash table used for temporarily saving DNS records.

dns max-cache-memory

Local Domain Name

Enters the local domain name to be DNS cached.

List of DNS Servers

DNS servers that are used by the network to translate requested domains into IP addresses.

Configuring System Logging

Use the system logging option to set specific parameters for the system log file (syslog). This file contains authentication entries, settings of privilege levels, and administrative details. System logging is always enabled internally. The system log file is located on the system file system (sysfs) partition as /local1/syslog.txt.

See Table 8-12 for a list of the key system logging parameters, descriptions, and CLI commands.

Table 8-12 System Logging Parameter Settings

Parameter

Description

CLI Command

Host Server

IP address or host name of the host that receives syslog messages from the device group.

logging host

Console

Enables sending syslog files to the console.

logging console

Disk

Enables sending syslog files to disk.

logging disk

Cw2k

Enables sending syslog files to CiscoWorks2000 log.

logging cw2k

Priority

Determines priority level when system logging is enabled to disk, console, or host.

logging disk, logging console, logging host

Syslog file

Path of the syslog file in the hard drive.

logging disk

Recycle

Rewrites the syslog file when it surpasses the specified recycle size.

logging recycle

Logging can be configured to send various levels of messages to disk, console, or host using the priority option of the logging command. Table 8-13 lists the different priority levels of detail to send to the recipient of the syslog messages for a corresponding event.

Table 8-13 System Logging Priority Levels and Descriptions

Priority Code

Condition

Description

0

Emergency

System is unusable.

1

Alert

Immediate action needed.

2

Critical

Critical condition.

3

Error

Error conditions.

4

Warning

Warning conditions.

5

Notice

Normal but significant conditions.

6

Information

Informational messages.

7

Debug

Debugging messages.

Using CiscoWorks2000

CiscoWorks2000 (CW2K) is a Cisco product that provides a suite of management applications used to manage most Cisco devices. The Content Engine can interoperate with CiscoWorks2000 without any modification in the following ways:

•CW2K can list the Content Engine under "Generic SNMP" devices.

•The CW2K inventory module lists the Content Engine with the device name, system name, description (including the software version), uptime, and network interface information.

•The CW2K syslog module can understand Content Engine syslogs.

•The CW2K availability module can track the Content Engine.

You can enable or disable syslog message generation in CiscoWorks2000-compliant format through either the CLI or the GUI.

Use the logging cw2k command to enable CiscoWorks2000 syslog message generation using the CLI. Use the no logging cw2k command to disable CiscoWorks2000 syslog message generation.

To enable system logging, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the desired Content Engine. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Platform > Sys Logs. The Syslog Settings for Content Engine window appears. (See Figure 8-29.)

Figure 8-29 Syslog Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Under the Syslog settings heading, check the Enable check box to enable system logging.

Step 6 Check the Enable Cisco Works 2000 Support check box to allow for logging of files under the CiscoWorks2000 format.

Step 7 Choose the appropriate facility for CW2K support.

Step 8 Click Submit to save the settings.

Under the Console Settings heading, follow these steps:

Step 1 Check the Enable check box to enable sending syslog files to the console.

Step 2 Choose a priority level from the drop-down list. See Table 8-13 for a list of priority levels.

Step 3 Click Submit to save the settings.

Under the Disk Settings heading, follow these steps:

Step 1 Check the Enable check box to enable sending syslog files to disk.

Step 2 Enter a path and a filename where the syslog files will be stored on disk in the File Name field.

Step 3 Choose a priority level from the drop-down list. See Table 8-13 for a list of priority levels.

Step 4 Enter the size of the syslog file that can be recycled when it is stored on disk in the Recycle field.

Step 5 Click Submit to save the settings.

Under the Host Settings heading, follow these steps:

Step 1 Check the Enable Host Settings check box to enable sending syslog files to a host.

Step 2 Enter a host name or IP address in the Host Name field.

Step 3 Choose a priority level from the drop-down list. See Table 8-13 for a list of priority levels.

Step 4 Click Submit to save the settings.

Configuring NTP Settings

Cisco ACNS 5.0 software allows you to configure the Content Engine time and date settings using an NTP (Network Time Protocol) host on your network. This allows for the synchronization of time and date settings for the different geographical locations of the Content Engines on your CDN.

To configure Content Engine or device group NTP settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Platform > NTP. (See Figure 8-30.)

Figure 8-30 NTP Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable check box to enable NTP settings.

Step 6 Enter a host name or IP address in the NTP Server field.

Step 7 Click Submit to save the settings.

Configuring CDP Settings

CDP (Cisco Discovery Protocol) is a device discovery protocol that runs on all Cisco-manufactured devices. With CDP, each device within a network sends periodic messages to all devices within the network. These devices listen to periodic messages sent by others in order to learn about neighboring devices and determine the status of their interfaces.

With CDP, network management applications can learn the device type and the Simple Network Management Protocol (SNMP) agent address of neighboring devices. Applications are then able to send SNMP queries within the network. Also, CiscoWorks2000 discovers the Content Engine by noticing the CDP packets that are sent by the Content Engine after booting.

Content Engine-related tasks require that the Content Engine platform support CDP in order to be able to notify the system manager of the existence, type, and version of the Content Engine platform.

The following example shows you how to enable CDP using the cdp enable CLI command.
ContentEngine(config)# interface FastEthernet 0/0 cdp enable
To configure CDP settings using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Platform > CDP. The CDP Settings window appears. (See Figure 8-31.)

Figure 8-31 CDP Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable check box to enable CDP support.

Step 6 In the Hold Time field, enter the time (in seconds) between sending CDP packets.

Step 7 In the Packet Send Rate field, enter the rate at which CDP packets are sent.

Step 8 Click Submit to save the settings.

Configuring Content Services for the Content Engine

You can configure content services for your device such as bandwidth settings, rules, URL filters, and transaction logs for the Content Engine. Tasks include:

•Configuring Content Services Bandwidth Settings

•Configuring Service Rules

•Configuring URL Filtering

•Configuring Transaction Log Settings

Configuring Content Services Bandwidth Settings

Content services bandwidth settings control the amount of bandwidth that each content service uses to stream content to users. To configure content services bandwidth settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Content Services > Content Service Bandwidth. The Content Service Bandwidth Settings window appears.

Step 4 Click the Add Bandwidth Specifications icon. The Create New Content Service Bandwidth Settings window appears. (See Figure 8-32.)

Although there are no default values for any of the following bandwidth configuration fields, the values that you enter depend upon the bandwidth license in effect for your specific system. If you enter a value that is beyond the allowable bandwidth based on your system's license, the value is accepted but a warning message is displayed. Internally, your system bandwidth is limited to the maximum value granted by the license. All values entered are in kilobits per second (kbps).

Figure 8-32 Create New Content Service Bandwidth Settings Window

Step 5 In the WMT Limit field, enter the amount of bandwidth permitted by the system license for streaming WMT content to end users.

Step 6 In the Real Proxy Limit field, enter the amount of bandwidth permitted by the system license for streaming RealProxy content to end users. RealProxy content refers to RealMedia content that has been cached after a request from an end user.

Step 7 In the Real Server Limit field, enter the amount of bandwidth permitted by the system license for streaming RealServer content to an end user. RealServer content refers to RealMedia content that has been pre-positioned.

Step 8 In the Cisco Streaming Engine Limit field, enter the amount of bandwidth permitted by the system license for the Cisco Streaming Engine to stream content to an end user.

The Total Limit field automatically displays the total content service bandwidth of the above fields.

Step 9 In the Start Time field, enter the time of day for the bandwidth rate setting to begin, using a 24-hour clock in local time (hh:mm).

Step 10 In the End Time field, enter the time of day for the bandwidth rate setting to end, using a 24-hour clock in local time (hh:mm).

Step 11 In the Day Selection field, check the check boxes next to the days on which bandwidth settings apply.

Step 12 Click Submit to save settings.

Configuring Service Rules

The Rules Template feature provides a flexible mechanism to specify configurable caching requests by allowing these requests to be matched against an arbitrary number of parameters, with an arbitrary number of policies applied against the matches. You can specify a set of rules, each clearly identified by an action and a pattern. Subsequently, for every incoming request, if a pattern for a rule matches the given request, the corresponding action for that rule is taken.

Requests can be matched against regular expressions symbolizing domain names, source IP addresses and network masks, destination IP addresses and network masks, destination port numbers, MIME types, or regular expressions symbolizing a URL.

Note You can configure service rules using the Content Distribution Manager GUI or CLI commands. This section provides instructions for both methods.

Note The Rules Template feature is mostly applicable to HTTP, FTP, and HTTPS protocols. Policies that support streaming media object protocols such as MMS and RTSP, in addition to HTTP, FTP, and HTTPS, are indicated below.

Policies that can be applied include:

•Blocking the request (MMS, RTSP also)

•Overriding the HTTP response header and caching the object

•Bypassing authentication for the request (MMS, RTSP also)

•Resetting the request

•Using a specific object freshness calculation factor

•Not caching an object

•Bypassing an upstream proxy for the request

•Redirecting the request to a different URL (RTSP also)

•Revalidating the object with the origin server

•Rewriting the URL (MMS, RTSP also)

•Selectively caching the object (MMS also)

•Using a specific upstream proxy (MMS also)

•Using a specific server for the request

•Setting ToS/DSCP in the response sent to the client

•Setting ToS/DSCP in the response sent to the server

Note To enter a question mark (?) character in a rule regular expression from the command-line interface, use the escape character followed by a question mark (?) character. This prevents the command-line interface from displaying context-sensitive help.

Understanding Actions and Patterns

A rule is specified by an action and a pattern. An action is performed on a request if this request matches the pattern specified in your configuration.

An action is a process that the Content Engine performs when processing a request, for instance, blocking the request, using an alternative proxy, and so forth.

A pattern defines the limits of a request; for instance, a pattern may specify that the source IP address fall in the subnet range 172.16.*.*.

Rules can be dynamically added, displayed, or deleted from the Content Engine. The rules are preserved across reboots because they are written into persistent storage such as NVRAM using the appropriate CLI commands or the Content Engine GUI. Only the system resources limit the number of rules that the Content Engine can support. Because rules consume resources, the more rules there are defined, the more Content Engine performance may be affected.

Actions

The Rules Template feature supports the following types of actions:

•Block—Blocks this request.

•Cache—Overrides the HTTP response headers and caches the objects.

Note The rule cache command cannot cache objects if the objects are authenticated. That is, for authenticated objects, some origin servers do not send the Last-Modified or ETag entity headers. Revalidation of those authorized objects therefore cannot be performed by the Content Engine. Those authenticated objects are served only from the origin server. If the server does send the Last-Modified and ETag headers for authenticated objects, then they are properly revalidated and served from the cache.

•DSCP client—Configures the IP ToS/DSCP code point field.

–cache-hit—Sets the IP ToS/DSCP code point bits for the client-side connection to the configured value for cache-hit responses to the client.

–cache-miss—Sets the IP ToS/DSCP code point bits for the client-side connection to the configured value for cache-miss responses to the client.

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. With the ACNS 5.0 release, 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.

You can set specific ToS or DSCP values for the following:

–Requests from the Content Engine to the server

–Responses to the client on a cache hit

–Responses to the client on a cache miss

The ToS or DSCP may be set based on any of the policies matching the src-ip s_ipaddress s_subnet, dst-ip d_ipaddress d_subnet, dst-port port, domain LINE, url-regex LINE, or mime-type LINE options. In addition, you can now configure global ToS or DSCP settings with the ip dscp command.

Note The Rules Template configuration takes precedence over the ip dscp command, and the url-filter command takes precedence over the rule command to the extent that even the rule no-block command is executed only if the url-filter command has not blocked the request.

•DSCP server—Configures the IP ToS or DSCP code point field for requests to the origin server.

•Freshness-factor—Determines the Time To Live if the request URL matches a specified regular expression. The refresh configuration takes priority over freshness-factor configurations.

•Insert-no-cache—Inserts a no-cache header in the response.

•No-auth—Does not authenticate.

Note that the no-auth rules result in the display of multiple authentication windows in the following scenario:

–When the main page (for example, index.htm) is excluded from proxy authentication by using no-auth rules

–When the user entry is not already included in the Content Engine authentication cache

–When the index.htm page contains objects belonging to different domains

To avoid multiple authentication windows, enter the hidden http avoid-multiple-auth-prompts command in global configuration mode. Once it is configured, check the configuration with the hidden show http avoid-multiple-auth-prompts command as shown the following example.
ContentEngine# show http avoid-multiple-auth-prompts
Avoiding multiple authentication prompts due to no-auth rules is enabled
Note The commands in the example are hidden because they are applicable only to this specific scenario.

•No-cache—Does not cache this object. If both the no-cache and selective-cache actions are matched, no-cache takes precedence.

•No-proxy—For a cache miss, does not use the configured upstream proxy but rather contacts the server directly.

•Redirect—Redirects the original request to a specified URL. Redirect is relevant to the RADIUS server only if the RADIUS server has been configured for redirect.

•Redirect-url-for-cdn—Redirects an original request to an alternative URL for Content Delivery Network (CDN) content.

•Refresh—For a cache hit, forces an object freshness check with the server.

•Reset—Issues a TCP RST. This reset request in useful when resetting Code Red or Nimda virus requests.

•Rewrite—Rewrites the original request as a specified URL. The Content Engine searches for the rewritten URL in cache, and then on a cache miss, fetches the rewritten URL and returns the object transparently to the client. It is preferable to use a redirect rule rather than rewrite because of possible performance impacts.

The URL rewrite could change the domain name of the URL, which necessitates a DNS lookup to find the destination (dst) IP address of the new rewritten server to which the request must be sent. The original dst IP address derived from the WCCP redirect packet cannot be used.

•Selective-cache—Caches this object only if it is a match and is allowed to be cached by HTTP. If one or more rules specify this action, an object is cached if and only if it matches at least one of the selective-cache rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check. If the object does not match any of the selective-cache rules, the object is not cached.

•Use-dns-server—Uses the DNS specified server.

•Use-proxy—For a cache miss, uses a specific upstream proxy. Specify the upstream proxy IP address (or domain name) and port number. If both no-proxy and use-proxy are matched, no-proxy takes precedence.

•Use-proxy-failover—Supports failover capability. The use-proxy-failover rule is similar to the use-proxy rule, except that if the connection attempt on the configured outgoing proxy fails, the requests fail over to the outgoing proxies configured with the HTTP proxy outgoing configuration. The rule requests use the http proxy outgoing origin-server option, if it is configured. The use-proxy-failover rule takes precedence over the use-proxy rule. If both no-proxy and use-proxy-failover are matched, no-proxy takes precedence.

The HTTP failover does not apply if the destination is on the exclude list. When in transparent mode, the setting for the original proxy takes precedence.

•Use-server—Sends server-style HTTP requests from the Content Engine to the specified IP address and port on a cache miss.

Among use-server, no-proxy, and use-proxy rules, the use-server rule is the first one to be checked. If it results in a rule miss, no-proxy and use-proxy rules are executed in succession (use-proxy is not checked if a no-proxy rule matches).

If a rule is configured with a fully qualified domain name (FQDN) and a request is received with the partial domain name in transparent mode, the rule fails to be executed, because the FQDN is not in the request URL. In transparent mode, if a request is destined for a particular domain (for which a domain rule is configured) and does not contain the Host header, the rule pattern match fails.

Patterns

The Rules Template feature supports the following types of patterns:

•Domain—Matches the domain name in the URL or the Host header against a regular expression. For example, ".*ibm.*" matches any domain name that contains the "ibm" substring. "\.foo\.com$" matches any domain name that ends with the ".foo.com" substring.

Note In regular expression syntax, the dollar sign "$" metacharacter directs that a match is made only when the pattern is found at the end of a line.

•Dst-ip—Matches the request's destination IP address and netmask. Specify an IP address and a netmask. In proxy mode, the Content Engine does a DNS lookup to resolve the destination IP address of the HTTP request, making the response time longer, and possibly negating the benefit of setting a dst-ip rule. When an outgoing proxy is configured, cache miss requests are forwarded by the Content Engine to the outgoing proxy without examination of the destination server IP address, making the dst-ip rule unenforceable on the first Content Engine.

•Dst-port—Matches the request's destination port number. Specify a port number.

•Mime-type—Matches the MIME type of the response. Specify a MIME type string, for example, "image/gif," as defined in RFC 2046 (http://www.faqs.org/rfcs/rfc2046.html). The administrator can specify a substring, for example, "java" and have it apply to all MIME types with the "java" substring, such as "application/x-javascript."

•Src-ip—Matches the request's source IP address and netmask. Specify an IP address and a netmask.

•URL-regex—Matches the URL against a regular expression. The match is case insensitive. Specify a regular expression whose syntax can be found at the following URL:

http://yenta.www.media.mit.edu/projects/Yenta/Releases/Documentation/regex-0.12/.

•Header-field—Requests header field pattern.

Request header field patterns referer, request-line, and user-agent are supported for actions block, reset, redirect, and rewrite. The referer pattern is matched against the Referer header in the request, the request-line pattern is matched against the first line of the request, and the user-agent pattern is matched against the User-Agent header in the request.

•Header-field-sub—Matches a regular expression with a request header referer pattern and the pattern substitution specification.

•URL-regsub—For the rewrite and redirect actions, matches the URL against a regular expression to form a new URL per pattern substitution specification. The match is case insensitive. The valid substitution index range is from 1 to 9.

Rules Template Processing Considerations

There is a predefined order of execution among the actions and the patterns. In other words, a group of rules with the same action will always be executed either before or after another group of rules with a different action. See the "Execution Order of Rule Actions" section for the order in which rule actions are executed. This order is not affected by the order in which the rules are entered using CLI commands.

Among rules of the same action, there is a predefined execution order among the rule patterns. This means that within a group of rules of the same action, one group of rules with the same pattern is always executed either before or after another group of rules with a different pattern. See the "Execution Order of Rule Patterns" section for the order in which rule patterns are executed. This order is not affected by the order in which the rules are entered using CLI commands.

Execution Order of Rule Actions

The order in which rule actions are executed is as follows:

1. No-auth—Before authentication using RADIUS, LDAP, NTLM, or TACACS+

2. Reset—Before cache lookup

3. Block—Before cache lookup

4. Redirect—Before cache lookup

5. Rewrite—Before cache lookup

6. Refresh—On cache hit

7. Freshness-factor—On cache hit

8. Use-server—On cache miss

9. No-proxy—On cache miss

10. Use-proxy-failover—On cache miss

11. Use-proxy—On cache miss

12. Use-dns-server—On cache miss

13. DSCP server—On cache miss

14. DSCP client—On cache hit

15. Insert-no-cache—On cache miss or cache hit (checked while variable headers are appended to the reply header)

16. No-cache—On cache miss

17. Cache—For noncacheable objects

18. Selective-cache—On cache miss

Note The commands rule action no-proxy, rule action use-proxy-failover, and rule action use-proxy take precedence over https proxy outgoing, http proxy outgoing, and ftp proxy outgoing commands.

During a request using the Rules Template CLI commands, rule actions 1 through 4 use the original URL request for pattern matches. After a URL rewrite (rule action 5), rule actions 6 through 18 use the transformed URL for rule executions.

The commands rule action reset, rule action block, rule action rewrite, and rule action redirect support the following additional patterns for Rules Template requests:

•Request-line—Matches first line

•Referer—Matches Referer header

•User-agent—Matches User-Agent header

Execution Order of Rule Patterns

The order in which rule patterns are executed is as follows:

1. Dst-port—Destination port check

2. Src-ip—Source IP address check

3. URL-regex—URL regular expression check

4. Domain—Domain rule check

5. Dst-ip—Destination IP address check

6. Mime-type—MIME-type regular expression check

Note Because the MIME type exists only in the response, only the actions freshness-factor, refresh, no-cache, and selective-cache apply to a rule of MIME type.

A search for a rule match with the remaining pattern list is not performed if a match has already been found. For instance, if a match for the rule action block action command is found with a URL-regex request, then the remaining patterns domain, dst-ip, or MIME-type are not searched. Not all patterns are applicable for the actions rewrite and redirect. Only the URL-regex pattern search is applicable for the actions rewrite and redirect.

Rules are ORed together. Multiple rules may all match a request; then all actions are taken, with precedence set among conflicting actions based on the execution order of rule actions as defined in the "Execution Order of Rule Actions" section. A rule action command can contain more than one pattern as configured by the rule pattern-list command.

It is possible to circumvent some rules. For example, to circumvent a rule with the domain pattern, enter the web server IP address instead of the domain name in the browser. A rule may have unintended effects. For instance, a rule with the domain pattern specified as "ibm" that is intended to match "www.ibm.com" can also match domain names like www.ribman.com.

Note A src-ip rule may not apply as intended to requests that are received by a Content Engine from another proxy or Content Engine because the original client IP address is in an X-Forwarded-For header. This means that the original request's source IP address has been transparently replaced with the sending ContentEngine's IP address on its way to the origin server.

If a rule pattern match occurs, then the rest of the patterns are not searched. If the server has already marked an object as noncacheable, no-cache rules are not checked at all, because the server already recognizes that this object is not cached. Any no-cache rule checks are performed only for cacheable requests.

Configuring the Rules Template Using the Content Distribution Manager GUI

These sections describe how to configure patterns and actions for the Rules Template using the Content Distribution Manager GUI.

•Enabling Rule Settings Using the Content Distribution Manager GUI

•Configuring Service Rules Using the Content Distribution Manager GUI

Enabling Rule Settings Using the Content Distribution Manager GUI

To enable rule settings for the Content Engine, follow these steps:

Step 1 Choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears.

Step 3 From the Contents pane, choose Content Services > Enabling Rules. The Enable Rule Settings window appears.

Step 4 Click the Add Settings button.

Step 5 Check the Enable check box to enable the use of rule settings.

Step 6 Click Submit to save the settings.

Configuring Service Rules Using the Content Distribution Manager GUI

Configuring a service rule consists of the following: configuring a pattern list, adding a pattern to an existing pattern list, and associating an action with an existing pattern list.

To configure service rule parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Content Services > Service Rules.

Step 4 Click the Create New Service Rule icon. The Creating New Service Rule window appears.

Step 5 Choose an action from the Rule Type drop-down list. See Table 8-14 for a description of rule actions.

Step 6 Define the rule.

For example, to create pattern list number 72 with the domain yahoo.com as the pattern type and the domain to be acted on by an action, enter 72 domain yahoo.com in the Rule Parameters field. (See Figure 8-33.)

Figure 8-33 Creating New Service Rule for Device Group Window

Step 7 Click Submit.

Step 8 Now enter a pattern for the service rules action configured in Step 5. See Table 8-15 for a description of pattern types, or choose pattern-list from the Rule Type drop-down list to display the available patterns.

For example, if you want to block access to yahoo.com, then choose block from the Rule Type drop-down list and enter pattern-list 72 in the Rule Parameters field. (See Figure 8-34.)

Figure 8-34 Service Rule Settings Window

Step 9 Click Submit to save the settings.

Table 8-14 describes the service rule action types used in the Content Distribution Manager GUI Creating New Service Rule window.

Table 8-14 Action Types

Action Types

Description

block

Blocks this request.

cache

Overrides the HTTP response headers and caches the objects.

dscp

Configures the IP ToS/DSCP code point field.

cache-miss—Sets the IP ToS/DSCP code point bits for the client-side connection to the configured value for cache-miss responses to the client.

cache-hit—Sets the IP ToS/DSCP code point bits for the client-side connection to the configured value for cache-hit responses to the client.

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. With the ACNS 5.0 releases, 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.

You can set specific ToS or DSCP values for the following:

•Requests from the Content Engine to the server

•Responses to the client on a cache hit

•Responses to the client on a cache miss

The ToS or DSCP may be set based on any of the policies matching the src-ip s_ipaddress s_subnet, dst-ip d_ipaddress d_subnet, dst-port port, domain LINE, url-regex LINE, or mime-type LINE options. In addition, you can now configure global ToS or DSCP settings with the ip dscp command.

The Rules Template configuration takes precedence over the ip dscp command, and the url-filter command takes precedence over the rule command to the extent that even the rule no-block command is executed only if the url-filter command has not blocked the request.

freshness-factor

Determines the Time To Live if the request URL matches a specified regular expression. The refresh configuration takes priority over freshness-factor configurations.

insert-no-cache

Inserts a no-cache header in the response.

no-auth

Does not authenticate.

no-cache

Does not cache this object. If both the no-cache and selective-cache actions are matched, no-cache takes precedence.

no-proxy

For a cache miss, does not use the configured upstream proxy but rather contacts the server directly.

redirect

Redirects the original request to a specified URL. Redirect is relevant to the RADIUS server only if the RADIUS server has been configured for redirect.

redirectUrlforCdn

Redirects the original request to a specified URL for the CDN.

refresh

For a cache hit, forces an object freshness check with the server.

reset

Issues a TCP RST. This reset request in useful when resetting Code Red or Nimda virus requests.

rewrite

Rewrites the original request as a specified URL

selective-cache

Caches this object only if it is a match and is allowed to be cached by HTTP.

If one or more rules specify this action, an object is cached if and only if it matches at least one of the selective-cache rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check. If the object does not match any of the selective-cache rules, the object is not cached

use-dns-server

Caches this object only if it is a match and is allowed to be cached by HTTP. If one or more rules specify this action, an object is cached if and only if it matches at least one of the selective-cache rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check. If the object does not match any of the selective-cache rules, the object is not cached.

use-proxy

For a cache miss, uses a specific upstream proxy. Specify the upstream proxy IP address (or domain name) and port number. If both no-proxy and use-proxy are matched, no-proxy takes precedence.

use-proxy-failover

Supports failover capability.

use-server

Sends server-style HTTP requests from the Content Engine to the specified IP address and port on a cache miss.

pattern list

Lists all patterns.

Table 8-15 describes service rule pattern types used in the Content Distribution Manager GUI Creating New Service Rule window.

Table 8-15 Pattern Types

Pattern Types

Description

domain

Matches the domain name in the URL or the Host header against a regular expression. For example, ".*ibm.*" matches any domain name that contains the "ibm" substring. "\.foo\.com$" matches any domain name that ends with the ".foo.com" substring.

In regular expression syntax, the dollar sign "$" metacharacter directs that a match is made only when the pattern is found at the end of a line.

dst-ip

Matches the request's destination IP address and netmask. Specify an IP address and a netmask. In proxy mode, the Content Engine does a DNS lookup to resolve the destination IP address of the HTTP request, making the response time longer, and possibly negating the benefit of setting a dst-ip rule. When an outgoing proxy is configured, cache miss requests are forwarded by the Content Engine to the outgoing proxy without examination of the destination server IP address, making the dst-ip rule unenforceable on the first Content Engine.

dst-port

Matches the request's destination port number. Specify a port number.

header-field

Requests header field pattern.

Request header field patterns referer, request-line, and user-agent are supported for actions block, reset, redirect, and rewrite. The referer pattern is matched against the Referer header in the request, the request-line pattern is matched against the first line of the request, and the user-agent pattern is matched against the User-Agent header in the request.

header-field-sub

Requests header field sub pattern.

mime-type

Matches the MIME type of the response.

Specify a MIME type string, for example, "image/gif," as defined in RFC 2046 (http://www.faqs.org/rfcs/rfc2046.html). The administrator can specify a substring, for example, "java" and have it apply to all MIME types with the "java" substring, such as "application/x-javascript."

scr-ip

Matches the request's source IP address and netmask. Specify an IP address and a netmask.

url-regex

Matches the URL against a regular expression. The match is case insensitive. Specify a regular expression whose syntax can be found at the following URL:

http://yenta.www.media.mit.edu/projects/Yenta/Releases/Documentation/regex-0.12/.

url-regsub

For the rewrite and redirect actions, matches the URL against a regular expression to form a new URL per pattern substitution specification. The match is case insensitive. The valid substitution index range is from 1 to 9.

Configuring the Rules Template Using CLI Commands

These sections describe how to configure pattern lists and actions for the Rules Template using CLI commands.

•Configuring a Pattern List

•Adding a Pattern to an Existing Pattern List

•Associating an Action with an Existing Pattern List

Configuring a Pattern List

To create a new pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule enable
Enables the Rules Template.
Step 2
ContentEngine(config)# rule pattern-list 1-100 
pattern-type pattern
Creates a pattern list.
Step 3
ContentEngine# show rule pattern-list 1-100 
pattern-type pattern
Displays the Rules Template configuration.
In the following example, the rule pattern-list command is configured to create a pattern list to block all domains that contain .foo.com in the URL request using the domain \.foo.com pattern.
ContentEngine(config)# rule pattern-list 10 domain foo.com
ContentEngine# show rule pattern-list 10 domain 
Rules Template Configuration
----------------------------
Rule Processing Enabled
Pattern-Lists : 
rule pattern-list 10 domain foo.com
ContentEngine#
Adding a Pattern to an Existing Pattern List

To add a a new pattern to an already existing pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule pattern-list 1-100 
pattern-type pattern
Adds a pattern to a pattern list.
Step 2
ContentEngine# show rule pattern-list 1-100 
pattern-type pattern
Displays the Rules Template configuration.
In the following example, the rule pattern-list command is configured to add a pattern to an existing pattern list to perform an action yet to be defined on the destination IP address 172.16.25.25 using the dst-ip pattern.
ContentEngine(config)# rule pattern-list 10 dst-ip 172.16.25.25 255.255.255.0
ContentEngine# show rule pattern-list 10 all 
Rules Template Configuration
----------------------------
Rule Processing Enabled
Pattern-Lists : 
rule pattern-list 11 dst-ip 172.16.25.25 255.255.255.0
rule pattern-list 11 domain foo.com
ContentEngine#
Associating an Action with an Existing Pattern List

To associate an action with an existing pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule action action-type 
pattern-list 1-100 protocol protocol-type | all
Associates an action with an existing pattern list.
Step 2
ContentEngine# show rule action action-type protocol 
protocol-type | all
Displays the Rules Template configuration.
In the following example, the rule action block command is configured and associated with an existing pattern list.
ContentEngine(config)# rule action block pattern-list 10 protocol all
ContentEngine# show rule action block 
Rules Template Configuration
----------------------------
Rule Processing Enabled
Actions : 
rule action block pattern-list 10 protocol all 
ContentEngine#
Verifying an Action Performed on a Pattern List

To verify the response sent by the Content Engine to confirm that a certain action is performed on a pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule action action-type 
pattern-list 1-100 protocol protocol-type | all
Associates an action to an existing pattern list.
Step 2
ContentEngine# show rule action action-type protocol 
protocol-type | all
Displays the Rules Template configuration after new action has been added.
Step 3
ContentEngine# show statistics rule action 
action-type 
Displays the local Rules Template configuration statistics after a request is issued on which an action should be performed.
In the following example, the rule action block command is configured and associated with an existing pattern list, which lists as its pattern the domain yahoo.com.
ContentEngine(config)# rule pattern-list 30 domain yahoo.com
ContentEngine(config)# rule action block pattern-list 30 protocol all
ContentEngine# show statistics rule action block 
Rules Template Statistics
-------------------------
Rule hit count = 3 Rule: rule action block pattern-list 30 protocol all
ContentEngine#
In this example, the request to yahoo.com was denied three times.

Configuring URL Filtering

Some enterprises have a requirement to monitor, manage, and restrict employee access to nonbusiness and objectionable content on the Internet. Employees or students can be allowed or denied access to websites, or can be coached with information about acceptable use of the Internet. By having a URL filtering scheme on Content Engines, organizations realize an immediate return on investment as a result of increased productivity and recaptured network bandwidth, while reducing legal liability.

The URL filtering features presented in this section allow the Content Engine to control client access to websites in any of the following ways:

•Deny access to URLs specified in a list (HTTP, MMS, and RSTP traffic).

•Permit access only to URLs specified in a list (HTTP, MMS, and RSTP traffic).

•Direct traffic to an N2H2 server for filtering (HTTP traffic only).

•Direct traffic to a Websense enterprise server for filtering (HTTP traffic only).

•Filter traffic with Secure Computing Corporation SmartFilterSoftware, Release 3.1.2 for Cisco Content Engine ACNS Software, Release 5.0 (HTTP traffic only).

Note Although only one form of URL filtering scheme per protocol can be active, many URL filtering schemes can be supported at one time. In other words, if an N2H2 filter is applied to HTTP URLs, no other URL filtering scheme can be applied to this protocol such as Websense, or SmartFilter. However, the use of good and bad lists can be applied to the streaming media protocol. The scheme enabled for a particular protocol is independent of that of other protocols.

Custom Blocking Messages

The Content Engine can be configured to return a customized blocking message to the client. The custom message must be an administrator-created HTML file named block.html. Make sure to copy all embedded graphics associated with the custom message HTML window to the same directory that contains the block.html file. To enable the customized blocking message, use the url-filter http custom-message command and specify the directory name.

To disable the custom message, use the no url-filter http custom-message command.

The url-filter http custom-message command can be enabled and disabled without affecting the good-sites-allow and bad-sites-deny configuration.

Note Do not use local1 or local2 as directories for custom blocking messages. Create a separate directory under local1 or local2 for holding the custom message file.

In the example shown, a block.html file displays the following custom message:
This page is blocked by the Content Engine
when the Content Engine intercepts a request to the blocked site.

In the block.html file shown, objects (such as .gif, .jpeg, and so on) must be referenced within the custom message directory string /content/engine/blocking/url, as shown in the example below.

Note Contact your administrator if you have any questions concerning access to the blocked site that you requested.
<TITLE>Cisco Content Engine example customized message for url-filtering</TITLE>

<H1>
<CENTER><BLINK>
P
R
A
D
E
E
P
'
S
</BLINK>
Blocked Page
</CENTER>
</H1>


<IMG src="/content/engine/blocking/url/my.gif">

This page is blocked by the Content Engine.

If the block.html file is updated, it will automatically display its new message without your having to reenter the url-filter http custom-message command.

Configure URL Filtering Using the Content Distribution Manager GUI

To configure URL filter settings for the Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines. The Content Engines window appears.

Step 2 Click the Edit icon next to the desired Content Engine. The Contents pane appears on the left.

Step 3 Click Content Services > URL Filter. The URL Filter Settings window appears.

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Enter information for general URL filter settings, HTTP URL filter settings, RTSP URL filter settings, and WMT filter settings in the appropriate fields.

Step 6 Click Submit to save the settings.

Table 8-16 describes filter-setting parameters.

Table 8-16 URL Filtering General Settings Window

Key GUI Parameter

Description

CLI Command

General URL Filter Settings

FTP Server Hostname

DNS name or IP address of the FTP server from which the URL filter files are downloaded.

FTP Server Username

Username of the FTP server from which the URL filter files are downloaded.

FTP Server Password

Password of the FTP server from which the URL filter files are downloaded.

Confirm Password

Confirms the FTP server password.

Remote Custom Msg File Pathname

Path name of remote file that contains the custom message directory.

Custom Msg Directory

Creates a customized URL blocking message to display to the client. This custom message must be an administrator-created HTML file named block.html. Required field.

url-filter http custom-message dirname

HTTP URL Filter Settings

FTP Server Hostname

DNS name or IP address of the FTP server from which the URL filter files are downloaded.

FTP Server Username

Username of the FTP server from which the URL filter files are downloaded.

FTP Server password

Password of the FTP server from which the URL filter files are downloaded.

Confirm password

Confirms the FTP server password.

Enable Bad Site Filtering

Enables the use of local list filtering for bad sites

url-filter http bad-sites-deny enable

Remote Bad Site File Pathname

Path name of remote bad site file.

Bad Site Filename

File containing URLs to which access is denied. Required field.

url-filter http bad-sites-deny file filename

Enable Good Site Allow

Enables URL filtering of the local good sites list over HTTP.

url-filter http good-sites-allow enable

Remote Good Site File Pathname

Path name of remote good site file.

Good Site Filename

File contains URLs which to which access is permitted. Required field.

url-filter http good-sites-allow file filename

Enable SmartFilter Filtering

Enables the use of SmartFilter software.

url-filter http smartfilter enable

Enable N2H2 Filtering

Enables the use of an N2H2 server for URL filtering.

url-filter http N2H2 enable

N2H2 Server Hostname

Host name or IP address of the N2H2 server. Required field.

url-filter http N2H2 server

N2H2 Port

Port number on which the N2H2 server is accepting requests. Required field.

url-filter http N2H2 server IPaddress or hostname port

Enable N2H2 Allow Mode

Allows the request to be served if there is no response from the N2H2 server. Required check box.

url-filter http N2H2 allowmode enable

N2H2 Request Timeout

Number of seconds that the Content Engine should wait for a response from the N2H2 server. Required field.

url-filter http N2H2 server IPaddress or hostname port 1-65535 timeout

Enable Websense Filtering

Enables the use of a Websense server for URL filtering. Required check box.

url-filter http websense enable

WebSense Server Hostname

Host name or IP address of the Websense server Required field.

url-filter http websense server hostname

WebSense Port

Port number on which the Websense server is accepting requests. Required field.

url-filter http websense server hostname or IP address port 1-65535

Enable WebSense Allow Mode

Allows the request to be served if there is no response from the Websense server Required check box.

url-filter http websense allowmode enable

WebSense Request Timeout

Number of seconds the Content Engine should wait for a response from the Websense server. Required field.

url-filter http websense server IPaddress or hostname port 1-65535 timeout

RTSP URL Filter Settings

FTP Server Hostname

DNS name or IP address of the FTP server from which the URL filter files are downloaded.

FTP Server Username

Username of the FTP server from which the URL filter files are downloaded.

FTP Server password

Password of the FTP server from which the URL filter files are downloaded.

Enable Bad Site Filtering

Enables the use of local list filtering for bad sites.

url-filter rtsp bad-sites-deny enable

Remote Bad Site File Pathname

Path name of remote bad site file.

Bad Site Filename

File containing URLs to which access is denied. Required field.

url-filter rtsp bad-sites-deny file filename

Enable Good Site Allow

Enables URL filtering of the local good sites list over RTSP.

url-filter rtsp good-sites-allow enable

Remote Good Site File Pathname

Path name of remote site file.

Good Site Filename

File contains URLs which to which access is permitted. Required field.

url-filter rtsp good-sites-allow file filename

WMT URL Filter Settings

FTP Server Hostname

DNS name or IP address of the FTP server from which the URL filter files are downloaded.

FTP Server Username

Username of the FTP server from which the URL filter files are downloaded.

FTP Server password

Password of the FTP server from which the URL filter files are downloaded.

Confirm password

Confirms the FTP server password.

Enable Bad Site Filtering

Enables the use of local list filtering for bad sites.

url-filter wmt bad-sites-deny enable

Remote Bad Site File Pathname

Path name of remote bad site file.

Bad Site File Name

File containing URLs to which access is denied. Required field.

url-filter wmt bad-sites-deny file filename

Enable Good Site Allow

Enables URL filtering of the local good sites list over WMT.

url-filter wmt good-sites-allow enable

Remote Good Site File Pathname

Path name of remote good site file.

Good Site Filename

File contains URLs which to which access is permitted. Required field.

url-filter wmt good-sites-allow file filename

URL Filtering with URL Lists

You can configure the Content Engine to deny client requests for URLs that are listed in a badurl.lst file, or configure it to fulfill only requests for URLs in a goodurl.lst file.

The use of URL lists applies to requests in HTTP, HTTPS, and FTP format as well as streaming media protocols such as MMS and RTSP.

Note The local list file per protocol should not contain URLs that belong to other protocols. For instance, the HTTP local list file should only contain HTTP. HTTPS or FTP URLs and the WMT local list file should contain only MMS URLs.

Caution If the size of the local list file is too large, it can affect device performance, because the file is loaded into memory when the local list file filtering is enabled. If the size of the file is larger than 5 megabytes, a warning is issued by the device to notify you of its impact on performance.

To deny requests for specific HTTP URLs, follow these steps:

Step 1 Create a plain text file named badurl.lst.

In this file, enter the URLs that you want to block. The list of URLs in the badurl.lst file must be written in the form http://www.domain.com/ and delimited with carriage returns.

Step 2 Copy the badurl.lst file to the /local1 system file system (sysfs) directory of the Content Engine.

Note We recommend creating a separate directory under local1 to hold the bad lists, for example, /local1/filtered_urls.

Step 3 Use the url-filter http bad-sites-deny file command to point to the bad URL list.
Console(config)# url-filter http bad-sites-deny file local/local1/badurl.lst
Step 4 Use the url-filter http bad-sites-deny enable command to actively deny the URLs.
Console(config)# url-filter http bad-sites-deny enable 
To permit specific HTTP URLs to the exclusion of all other URLs, follow these steps:

Step 1 Create a plain text file named goodurl.lst.

In this file, enter the URLs that you want to exclusively allow. The list of URLs in the goodurl.lst file must be written in the form http://www.domain.com and delimited with carriage returns.

Step 2 Copy the goodurl.lst file to the /local1 sysfs directory of the Content Engine.

Note We recommend creating a separate directory under local1 to hold the good lists, for example, /local1/filtered_urls.

Step 3 Use the url-filter http good-sites-allow file command to point to the goodurl.lst file.
Console(config)# url-filter http good-sites-allow file local/local1/goodurl.lst
Step 4 Use the url-filter http good-sites-allow enable command to actively permit only the good URLs.
Console(config)# url-filter http good-sites-allow enable
Note Only one good sites file or one bad sites file can be active at a time per protocol.

Note When you update the badurl.lst or goodurl.lst file, use the url-filter local-list-reload EXEC command to recopy the URL list file from any protocol to the Content Engine.

Use the no form of the command to disable blocking, Websense, or N2H2 permission requests (for example, no url-filter bad-sites-deny).

URL Filtering with the N2H2 Server

Note URL filtering with the N2H2 server, Websense server, and SmartFilter software only applies to HTTP, FTP, or HTTPS protocols.

N2H2 is a globally deployed URL-filtering software that can filter HTTP, FTP, or HTTPS requests based on destination host name, destination IP address, and username and password. It relies on a sophisticated URL database exceeding 15 million sites and is organized into over 40 categories using both Internet technology and human review.

The Content Engine can perform URL filtering based on the N2H2 server. (See Figure 8-35.) The Content Engine and the N2H2 server use the Internet Filtering Protocol (IFP) Version 1 to communicate with each other. When the Content Engine receives a URL request, it sends an IFP request to the N2H2 server with the requested URL. The N2H2 server does some necessary lookups for the URL and sends back an IFP response. Based on the N2H2 server's IFP response, the Content Engine either blocks the HTTP request by redirecting the browser to a block page or proceeds with normal HTTP processing by sending the URL request to an origin server.

Figure 8-35 N2H2 Filtering

URL filtering using an N2H2 server is applied to HTTP, FTP, or HTTPS traffic before the service rule mechanism is applied, regardless of whether the requested object is in the cache or not. Filtering is applied to these traffic types:

•Proxy-style or transparent-style HTTP or HTTPS requests

•Proxy-style and transparent redirect proxy-style FTP over HTTP requests

N2H2 Features Supported

N2H2 supports three filtering methods. Table 8-17 lists the N2H2 features supported by the Content Engine. One N2H2 server can support multiple Content Engines simultaneously.

Table 8-17 N2H2 Features Supported

N2H2 Feature Name

Description

Global filtering

Applies filtering to all HTTP, FTP, or HTTPS requests.

User-based filtering

Applies filtering to specific users or groups.

Client IP-based filtering

Applies filtering to specific client IP addresses.

Transparent Authentication

Performs transparent authentication by passing back the initial response header to the client using the HTML page in the IFP responses.

N2H2 CLI Commands

The url-filter http N2H2 server IP address [port 1-65535] [timeout 1-120] command configures the Content Engine to query the N2H2 server. The optional port field specifies the port on the N2H2 server to which the Content Engine should send IFP requests. The default port number is 4005. The optional timeout field (in seconds) specifies how long the Content Engine should wait for an IFP response from the N2H2 server. The default timeout is 5 seconds.

This command does not verify whether or not an N2H2 server is accessible at the specified IP address in the current implementation. The configuration can be changed while N2H2 is enabled. The Content Engine will adopt the new configuration at run time.

The url-filter http N2H2 enable command enables the N2H2 server as the current URL filtering scheme. The command will not succeed if the server IP address is not configured, or if another URL filter is already enabled with N2H2 or other filtering schemes.

The url-filter http N2H2 allowmode enable command allows HTTP or HTTPS requests to pass when the N2H2 server is enabled but the Content Engine has problems communicating with the N2H2 server. With allowmode enabled, if the Content Engine fails to receive responses from the N2H2 server successfully, the Content Engine still allows all traffic through (it proceeds with normal traffic processing). With allowmode disabled, on the other hand, the Content Engine blocks all traffic through the Content Engine. By default, allowmode is enabled.

The allowmode option can be configured with or without N2H2 enabled and is independent of the N2H2 server configuration. The Content Engine adopts the new configuration for allowmode if N2H2 is already running.

N2H2 Status and Statistics Commands

The show url-filter http command shows the URL filtering scheme enabled on the Content Engine and the configurations for each URL filtering scheme, such as the configuration data for N2H2.

In this example, the show url-filter http command is used to display the status of all HTTP URL filtering schemes presently configured on the Content Engine:
ContentEngine# show url-filter http
URL filtering is set to use bad-list
Local list configurations
==================================
Good-list file name : 
Bad-list file name : /local1/url-filter/badlist.http
Custom message directory : 
Websense server configuration
==================================
Websense server IP : 172.16.193.165
Websense server port : 15868
Websense server timeout: 20 (in seconds)
Websense allow mode is ENABLED 
N2H2 server configuration
==============================
N2H2 server IP : 172.16.193.165
N2H2 server port : 4005
N2H2 server timeout : 5 (in seconds)
N2H2 allow mode is ENABLED 
ContentEngine#
The show statistics url-filter http n2h2 command shows the request-reply statistics of the communication between the Content Engine and the N2H2 server. These statistics show the number of requests sent, replies received, pages blocked, pages allowed, and failure cases. More detailed URL filtering statistics are available on the N2H2 server.
ContentEngine# show stat url-filter http n2H2 
N2H2 URL Filtering Statistics:
 Lookup requests transmitted = 144
 Lookup response received = 144
 Requests timed out = 0
 Number of retransmits = 0
 Requests BLOCKed by N2H2 = 52
 Requests OKed by N2H2 = 92
Allow Mode Statistics:
 No available connection = 0
 Error sending lookup requests = 0
 Error receiving lookup responses = 0
 Server error in responses = 0
Server Error in Responses:
 Error in Filter Server = 0
 Error in IFP server = 0
 Seq number mismatch = 0
 Multiple responses rcvd = 0
TCP error statistics:
 Bad network endpoint = 0
 Network unreachable = 0
 Underlying connection broken = 0
 Timeout specified is reached = 0
 Address already in use = 0
 Client connection broken = 0
 Client connection timeout = 0
 Server connection broken = 0
 Server connection timeout = 0
 Register read cancelled = 0
 Other errors = 0
Queue statistics:
 Number of xacts in Queue = 0
Overhead statistics:
 Avg total process time = 17
 Avg response time = 17
 Socket update count = 0
ContentEngine#
The statistics shown can be cleared using the clear statistics url-filter N2H2, clear statistics urlfilter, and clear statistics all commands.

The clear statistics url-filter N2H2 command resets the statistics counters for the N2H2 server. All the statistics counters are reset to 0.

N2H2 Configuration and Restrictions

Only one URL filtering scheme can be active per protocol. In order to enable N2H2 URL filtering, you should first make sure that no other URL filtering scheme is configured. You can then configure the server information for N2H2 using the url-filter N2H2 server IP address [port 1-65535] [timeout 1-120] command and enabling the N2H2 server.

The server IP address and port number configured in the Content Engine must match the IP address of the N2H2 server and the port that N2H2 server listens to for IFP requests. If the configuration on the Content Engine does not match the configurations on the N2H2 server, the Content Engine will time out all HTTP, FTP, or HTTPS requests and either block or allow all HTTP traffic based on the allowmode option configuration.

URL Filtering with the Websense Enterprise Server

The Content Engine can use a Websense enterprise server as a filtering engine and enforce the filtering policy configured on the Websense server. (See Figure 8-36.) Refer to the Websense documentation for further information on Websense filtering policies.

Figure 8-36 URL Filtering with a Websense Server

Websense CLI Commands

To enable Websense URL filtering on the Content Engine, specify the Websense server IP address or host name using the url-filter http websense enable command. The timeout option sets the maximum amount of time that the Content Engine will wait for a Websense response. The timeout default is 20 seconds. The port option specifies the port number on which the server will accept requests from the Content Engine (the default port is 15868). Use the no url-filter http websense enable command to disable Websense URL filtering.

The url-filter http websense allowmode enable command permits the Content Engine to fulfill the client request after a Websense server timeout. The Websense server returns its own blocking message when a request is denied. With allowmode disabled, on the other hand, the Content Engine blocks all traffic through the Content Engine. By default, allowmode is enabled.

To use Websense URL filtering with a cluster of Content Engines, make sure to enable it with the url-filter http websense enable command, and configure the url-filter http websense server command on each Content Engine in the cluster to ensure that all traffic is filtered.

Websense Status and Statistics Commands

The show url-filter http command shows the URL filtering scheme enabled on the Content Engine for HTTP traffic and the configurations for each URL filtering scheme, such as the configuration data for Websense.

In this example, the show url-filter http command is used to display the status of all HTTP URL filtering schemes presently configured on the Content Engine:
ContentEngine# show url-filter http
URL filtering is set to use bad-list
Local list configurations
==================================
Good-list file name : 
Bad-list file name : /local1/url-filter/badlist.http
Custom message directory : 
Websense server configuration
==================================
Websense server IP : 172.16.193.165
Websense server port : 15868
Websense server timeout: 20 (in seconds)
Websense allow mode is ENABLED 
N2H2 server configuration
==============================
N2H2 server IP : 172.16.193.165
N2H2 server port : 4005
N2H2 server timeout : 5 (in seconds)
N2H2 allow mode is DISABLED 
ContentEngine#
The show statistics url-filter http websense command shows the request-reply statistics of the communication between the Content Engine and the Websense server. These statistics show the number of requests sent, replies received, pages blocked, pages allowed, and failure cases. More detailed URL filtering statistics are available on the Websense server.
ContentEngine# show statistics url-filter http websense 
Websense URL Filtering Statistics:
Transmission statistics:
 Lookup requests transmitted = 1
 Lookup requests timed-out = 1
 Lookup responses received = 1
 Lookup responses received with error = 0
 Multiple response received = 0
 Sequence number mismatch = 0
TCP errors:
 Connection reset = 0
 Connection timeout = 3
 Other errors = 0
Filter results:
 Requests BLOCKed by Websense = 1
 Requests OKed by Websense = 0
 Sent to Allowmode ok = 1
 Sent to Allowmode block = 0
 desc_filtered_and_passed = 0
 desc_category_blocked = 1
 desc_category_not_blocked = 0
 desc_category_blocked_custom_deny = 0
 desc_category_not_blocked_custom_permit = 0
Websense log statistics:
 Logs sent successfully = 1
 Connection error = 0
 Error during log processing = 0
 Log not complete = 1
 Log not sent because Websense disabled = 0
 No available connection = 0
Congestion statistics:
 Pending requests = 0
 Pending log requests = 0
ContentEngine# 
The statistics shown can be cleared using the clear statistics url-filter http websense, and clear statistics all commands. All the statistics counters are then reset to 0.

Websense Configuration and Restrictions

Only one URL filtering scheme can be active per protocol. In order to enable Websense URL filtering, you should first make sure that no other URL filtering scheme is enabled on the same protocol. You can then configure the information for the Websense server using the url-filter http websense server IP address [port 1-65535] [timeout 1-120] command and enabling the Websense server with the url-filter http websense enable command.

The server IP address and port number configured in the Content Engine must match the IP address of the Websense server and the port that Websense server listens to for filtering requests. If the configuration on the Content Engine does not match the configurations on the Websense server, the Content Engine will time out all HTTP, FTP, or HTTPS requests and either block or allow all HTTP traffic based on the allowmode option configuration.

URL Filtering with SmartFilter Software

SmartFilter software for the Content Engine provides employee Internet management (EIM) functionality with proxy servers, firewalls, and caching appliances. The integrated Content Engine and SmartFilter product preserves all functionality available in a regular Content Engine. The SmartFilter filtering capability is available as an add-on service on the Content Engine, and the service may be enabled or disabled as desired through the Content Engine CLI or GUI.

The integrated Content Engine and SmartFilter product provides a one-box solution for server functionality. The Content Engine uses a suite of plug-in APIs to allow the SmartFilter software to implement hooks at strategic points during an HTTP transaction and thus provide URL filtering.

The integrated Content Engine and SmartFilter product provides two end user management tools called the SmartFilter Administration Console and the SmartFilter Administration Server. This GUI components download configurations into the Content Engine for use by the SmartFilter process.

To use SmartFilter URL filtering with a cluster of Content Engines, make sure to enter the url-filter http smartfilter enable command on each Content Engine in the cluster to ensure that all traffic is filtered. Refer to the SmartFilter for Cisco Content Engine User's Guide, Release 3.1 for more information on how to configure the SmartFilter software in the ACNS 5.0 release.

Configuring Transaction Log Settings

Transaction logs allow administrators to view the traffic that has passed through the Content Engine. Typical fields in the transaction log are the date and time when a request was made, the URL that was requested, whether it was a cache hit or a cache miss, the type of request, the number of bytes transferred, and the source IP.

In ACNS 5.0 software, the user can choose among Squid, Extended Squid, Apache, or customized log format.

Squid-Style Format

The Squid-style log format is the default format for transaction logging in the Content Engine. The Squid log file format used is the native log file format associated with the Squid-1.1 access.log file format. For details on the Squid-1.1 native log file format, refer to the Squid documentation "Frequently Asked Questions", section 6.6, access.log heading at the following URL: http://www.squid-cache.org/doc/FAQ/FAQ.html

The Squid log file format is:

time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type

A Squid log format example looks like this:

1012429341.115 100 172.16.100.152 TCP_REFRESH_MISS/304 1100 GET http://www.cisco.com/images/homepage/news.gif - DIRECT/www.cisco.com -

Extended Squid Format

The Extended Squid format logs the associated username for each record in the log file in addition to the fields logged by the Squid-style format, and is used for billing purposes. In this format the Rfc931 field associated with the Squid format is used to log the authorized user. This field always contains a "-" (dash) if no user information is available.

An Extended Squid-style log format example looks like this:

1012429341.115 100 172.16.100.152 TCP_MISS/302 184 GET http://www.cisco.com myloginname DIRECT/www.cisco.com

Apache-Style Format

The Apache format is the Common Log File (CLF) format defined by the World Wide Web Consortium (W3C) working group. This format is compatible with many industry-standard log tools. For more information, see the W3C Common Log Format website at the following URL:

http://www.w3.org/Daemon/User/Config/Logging.html.

The Apache-style log file format is:

remotehost rfc931 authuser date request status bytes

An Apache-style log file format example looks like this:

172.16.100.152 - - [Wed Jan 30 15:26:26 2002] "GET/http://www.cisco.com/images/homepage/support.gif HTTP/1.0" 200 632

Custom Format

The transaction-logs format custom command allows you to use a log format string to log additional fields that are not included in the predefined native Squid or Extended Squid formats, or the Apache CLF format. The log format string is a string which can contain the tokens listed in Table 8-18 and which mimics the Apache log format string. The log format string can contain literal characters that are copied into the log file. Double backslashes (\\) can be used to represent a literal backslash, and a backslash followed by a single quote (\') can be used to represent a literal single quote. A literal double quote cannot be represented as part of the log format string. The control characters \t and \n can be used to represent a tab and a new line character, respectively.

Table 8-18 lists the acceptable format tokens for the log format string. The "..." portion of the format tokens shown in this table represents an optional condition. This portion of the format token can be left blank, as in %a. If an optional condition is included in the format token and the condition is met, then what is shown in the Value column of Table 8-18 is included in the transaction log output. If an optional condition is included in the format token but the condition is not met, the resulting transaction log output is replaced with a hyphen (-). The form of the condition is a list of HTTP status codes, which may or may not be preceded by an exclamation point (!). The exclamation point is used to negate all of the status codes that follow it, meaning that the value associated with the format token is logged if none of the status codes listed after the ! match the HTTP status code of the request. If any of the status codes listed after the ! match the HTTP status code of the request, then a hyphen (-) is logged.

For example, "%400,501{User-Agent}i" logs the User-Agent header value on 400 errors and 501 errors (Bad Request, Not Implemented) only, whereas "%!200,304,302{Referer}i" logs the Referer header value on all requests that did not return a normal status.

The custom format currently supports the following request headers:

•User-Agent

•Referer

•Host

•Cookie

The output of each of the following Request, Referer, and User-Agent format tokens specified in the custom log format string is always enclosed in double quotation marks in the transaction log entry:

%r

%{Referer}i

%{User-Agent}i

The %{Cookie}i format token is generated without the surrounding double quotation marks, because the Cookie value itself can contain double quotes. The Cookie value can contain multiple attribute-value pairs that are separated by spaces. For this reason, it is recommended that when the Cookie format token is used in a custom format string, it be positioned as the last field in the format string. This positioning of the Cookie format token allows it to be more easily parsed by transaction log reporting tools. Alternatively, if you use the format token string "\'%{Cookie}i\'", the Cookie header can be surrounded by single quotes.

The following command can be entered to generate the well-known Apache Combined Log Format:

transaction-logs format custom "[%{%d}t/%{%b}t/%{%Y}t:%{%H}t:%{%M}t:%{%S}t %{%z}t] %r %s %b %{Referer}i %{User-Agent}i"

The following transaction log entry example in the Apache Combined Format is configured using the preceding custom format string:
[11/Jan/2003:02:12:44 -0800] "GET http://www.cisco.com/swa/i/site_tour_link.gif HTTP/1.1" 
200 3436 "http://www.cisco.com/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
Table 8-18 Custom Format Log Format String Values

Format Token

Value

%...a

IP address of the requesting client.

%...A

IP address of the Content Engine.

%...B
%...b

Bytes sent, excluding HTTP headers.

%...c

Connection status when response is completed, where:

X = Connection was aborted before the response was completed.
+ = Connection can be kept alive after the response is sent.
- = Connection is closed after the response is sent.

%...f

Filename.

%...h

Remote host (IP address of the requesting client is logged).

%...H

Request protocol.

%...{Foobar}i

Contents of Foobar: header lines in the request that is sent to the server. The value of Foobar can be one of the following headers: User-Agent, Referer, Host, or Cookie.

%...l

Remote log name. Not implemented on the Content Engine, so a hyphen (-) is logged.

%...m

Request method.

%...p

Canonical port of the server servicing the request. Not applicable on the Content Engine, so a hyphen (-) is logged.

%...P

Process ID of the child that serviced the request.

%...q

Query string (that is preceded by a ? if a query string exists; otherwise, it is an empty string).

%...r

First line of the request.

%...s

Status. The translog code always returns the HTTP response code for the request.

%...t

Time in common log time format (or standard English format).

%...{format}t

Time in the form given by the format token specified in Table 8-19.

%...T

Time consumed to serve the request in seconds (a floating point number with 3 decimal places).

%...u

Remote user.

%...U

URL path requested, not including query strings.

%...v
%...V

Value of the host request header field reported if the host appeared in the request. If the host did not appear in the host request header, the IP address of the server specified in the URL is reported.

Table 8-19 specifies the format token for the date and time of the format token %...{format}t listed in Table 8-18.

Table 8-19 Format Token for Date and Time

Format Token

Value

%a

Abbreviated weekday name.

%A

Full weekday name.

%b

Abbreviated month name.

%B

Full month name.

%c

Date and time representation.

%C

Century number (year/100) as a 2-digit integer.

%d

Day of the month as a decimal number (range 01 to 31).

%D

Equivalent to %m/%d/%y. (Note that in countries other than the USA, %d/%m/%y is rather common. This means that in international context this format is ambiguous and should not be used.)

%e

Like %d, the day of the month as a decimal number, but a leading zero is replaced by a space.

%G

ISO 8601 year with the century as a decimal number. The 4-digit year corresponding to the ISO week number (see %V). This has the same format and value as %y, except that if the ISO week number belongs to the previous or next year, that year is used instead.

%g

Like %G, but without century; that is, with a 2-digit year (00-99).

%h

Equivalent to %b.

%H

Hour as a decimal number using a 24-hour clock (range 00 to 23).

%I

Hour as a decimal number using a 12-hour clock (range 01 to 12).

%j

Day of the year as a decimal number (range 001 to 366).

%k

Hour (24-hour clock) as a decimal number (range 0 to 23); single digits are preceded by a blank. (See also %H.)

%l

Hour (12-hour clock) as a decimal number (range 1 to 12); single digits are preceded by a blank. (See also %I.)

%m

Month as a decimal number (range 01 to 12).

%M

Minute as a decimal number (range 00 to 59).

%n

New line character.

%p

Either AM or PM according to the given time value, or the corresponding strings for the current locale. Noon is treated as pm and midnight as am.

%P

Like %p but in lowercase: am or pm or a corresponding string for the current locale.

%r

Time in a.m. or p.m. notation. This is equivalent to `%I:%M:%S %p.'

%R

Time in 24-hour notation (%H:%M). For a version including the seconds, see %T below.

%s

Number of seconds since the epoch, i.e., since 1970-01-01 00:00:00 UTC.

%S

Second as a decimal number (range 00 to 61).

%t

Tab character.

%T

Time in 24-hour notation (%H:%M:%S).

%u

Day of the week as a decimal, range 1 to 7, Monday being 1. See also %w.

%U

Week number of the current year as a decimal number, range 00 to 53, starting with the first Sunday as the first day of week 01. See also %V and %W.

%V

ISO 8601:1988 week number of the current year as a decimal number, range 01 to 53, where week 1 is the first week that has at least 4 days in the current year, and with Monday as the first day of the week. See also %U and %W.

%w

Day of the week as a decimal, range 0 to 6, Sunday being 0. See also %u.

%W

Week number of the current year as a decimal number, range 00 to 53, starting with the first Monday as the first day of week 01.

%x

Date representation without the time.

%X

Time representation without the date.

%y

Year as a decimal number without a century (range 00 to 99).

%Y

Year as a decimal number, including the century.

%z

Time zone as hour offset from GMT. Required to emit RFC822-conformant dates (using "%a, %d %b %Y %H:%M:%S %z").

%Z

Time zone or name or abbreviation.

%%

Literal % character.

Transaction Logging and NTLM Authentication

If your device is configured for NT LAN Manager (NTLM) authentication and uses Apache-style or Extended Squid-style format, you can record the Windows domain name and username in the "authenticated username" field of the transaction log. If the domain name is available, both the domain name and the username are recorded in the "authenticated username" field, in the form domain\username. If only the username is available, only the username is recorded in the "authenticated username" field. If neither a domain name nor a username is available, a "-" (dash) is recorded in the field.

Sanitized Transaction Logs

You can disguise the IP address and usernames of clients in the transaction log file. The default is that transaction logs are not sanitized. A sanitized transaction log disguises the network identity of a client by changing the IP address in the transaction logs to 0.0.0.0.

Exporting Log Files

In order to facilitate the postprocessing of cache log files, it is possible to export transaction logs to an external host. This feature allows for log files to be automatically exported by FTP to an external host at configurable intervals. The username and password used for FTP are configurable, as is the directory to which the log files are uploaded.

The log files automatically have a filename of:

<type>_<ipaddr>_yyyymmdd_hhmmss.txt

where

•<type> represents the type of log file with celog for cache logs such as HTTP, HTTPS, and FTP, and mms_export for Windows Media Technologies (WMT) logs.

•<ipaddr> represents the Content Engine IP address.

•yyyymmdd_hhmmss represents the date and time when the log was archived for export.

Note For MMS type logs there is no .txt extension in the filename.

Exporting Transaction Logs to External FTP Servers

To export transaction logs to an FTP server, you must first enable exporting of transaction logs and then configure the FTP server parameters. This option can support up to four FTP servers. The following information is required for each target FTP server:

•Server IP address or the host name

The Content Engine translates the host name with a DNS lookup and then stores the IP address in the configuration.

•FTP user login and user password

•Path of the directory where transferred files are written

Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.

You can also compress archived log files into gzip format before exporting them to external FTP servers. The compressed filename has a .gz extension in the filename. This compression feature uses less disk space than that required for noncompressed archived files on both the Content Engine and the FTP export server and also requires less bandwidth during export because of the smaller size of the files to be exported.

Restarting Export After Receiving a Permanent Error from the External FTP Server

When an FTP server returns a permanent error to the Content Engine, the archive transaction logs are no longer exported to that server. You must reenter the Content Engine transaction log export parameters for the misconfigured server to clear the error condition.

A permanent error (Permanent Negative Completion Reply, RFC 959) occurs when the FTP command to the server cannot be accepted, and the action does not take place. Permanent errors can be caused by invalid user logins, invalid user passwords, and attempts to access directories with insufficient permissions or directories that do not exist.

Exporting Transaction Logs to External Secure FTP Servers

You can also export transaction logs to a secure FTP (SFTP) server. You must first enable the feature and configure the SFTP server parameters. The following information is required for each target SFTP server:

•SFTP server IP address or the host name

The Content Engine translates the host name with a DNS lookup and then stores the IP address in the configuration.

•SFTP user login and user password

•Path of the directory where transferred files are written

Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.

Enabling Transaction Logging with the Content Distribution Manager GUI

To enable transaction logging, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Content Services > Transaction Logs. The Transaction Logs settings window appears. (See Figure 8-37.)

Figure 8-37 Transaction Log Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Under the General Settings heading, check the Transaction Log Enable check box to activate transaction logging on your device.

Step 6 Check the Enable Sanitize Transaction Logs check box to disguise the IP address and username of clients.

Step 7 Check the Enable File-Marker check box to add entries to the transaction logs, indicating where the files begin and end.

Step 8 Check the Log Windows Domain check box to record the Windows domain name and username in the "authenticated username" field of the transaction log.

Note This option is operational if your device is configured for NT LAN Manager (NTLM) authentication and uses either the Apache-style or the Extended Squid-style transaction log format.

Step 9 Check the Compress Files before Export check box.

This enables compression of archived log files into gzip format before exporting them to external FTP servers.

Step 10 Click the Log File Format radio button and choose a log file format from the drop-down list. Choose Squid, Extended Squid, or Apache.

Alternatively, click the Log Format Custom radio button if you want to use a custom format for the transaction log.

Step 11 Under the Archive Settings heading, specify a value for the maximum size of the archive file in kilobytes in the Maximum Size of Archive field.

This is the value of the maximum size of the archived file to be maintained on the local disk.

Step 12 Choose the interval when the working log should be cleared by moving data into the archive log. Schedule the interval using the time options shown.

If you want to enable exporting to an FTP server, follow these steps:

Step 1 Under the Export Settings heading, check the Enable Export check box.

Step 2 Specify the interval when the working log should be cleared by moving data into the FTP server. Schedule the interval using the time options shown.

Step 3 Enter an IP address or host name information for the FTP server in the FTP Export Server field.

Note The FTP export feature can support up to four servers. Each server must be configured with a username, password, and directory that are valid for that server.

Step 4 Enter a user ID in the Name field.

Step 5 In the password field, enter a password for the user specified in Step 4.

Step 6 Enter the name of a working directory that will contain the transaction logs in the Directory field.

Note The user specified in the Name field must have write permission to the specified directory.

Step 7 Check the SFTP check box if the server chosen is a secure FTP server.

Step 8 Click Submit to save the settings.

Configuring Authentication

You can set authentication settings and configure external authentication servers for the Content Engine. Tasks include the following:

•Configuring Authentication Login Settings

•Setting the Authentication Scheme

•Configuring LDAP Server Settings

•Configuring NTLM Server Settings

•Configuring RADIUS Server Settings

•Configuring TACACS+ Server Settings

About Authentication

Authentication, also referred to as "login," is the act of verifying usernames and passwords. Authorization, or "configuration," refers to the setting of privileges for authenticated users in a network. Generally, authentication precedes authorization in a network.

Login and configuration privileges are maintained in three databases in ACNS 5.0 software: the local database, TACACS+ database, and RADIUS database. If all databases are enabled, then all databases are queried; if the user data cannot be found in the first database queried, then the second and third databases are queried.

By default, the local database is enabled, with TACACS+ and RADIUS both disabled for login and configuration. Whenever TACACS+ and RADIUS are disabled, local is automatically enabled. However, TACACS+, RADIUS, and local databases can be enabled at the same time. The primary option specifies the first database to attempt for login and configuration purposes; the secondary option specifies the database to use if the primary database fails. The tertiary option specifies the database to use if both primary and secondary databases fail.

Configuring Authentication Login Settings

To configure login authentication and authorization, follow these steps. In this example, local is configured as the primary database, TACACS+ as the secondary database, and RADIUS as the tertiary database.

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Authentication > Login Authentication. The Login Authentication Settings window appears. (See Figure 8-38.)

Figure 8-38 Login Authentication Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Authentication Login Servers check box.

This enables authentication privileges using the local, TACACS+, or RADIUS databases.

Step 6 From the drop-down list, choose local as the selection for the Primary Login Server.

Step 7 From the drop-down list, choose TACACS+ as the selection for the Secondary Login Server.

Step 8 From the drop-down list, choose RADIUS as the selection for the Tertiary Login Server.

Step 9 Check the Authentication Config Servers check box.

This enables authorization privileges using the local, TACACS+, or RADIUS databases.

Step 10 From the drop-down list, choose local as the selection for the Primary Config Server.

Step 11 From the drop-down list, choose TACACS+ as the selection for the Secondary Config Server.

Step 12 From the drop-down list, choose RADIUS as the selection for the Tertiary Config Server.

Step 13 Click Submit to add authentication and authorization settings for the Content Engine.

Note You must configure TACACS+ and RADIUS servers before you submit these settings. See the "Configuring TACACS+ Server Settings" section and the "Configuring RADIUS Server Settings" section for information on how to configure these servers.

Configuring Content Authentication

This section outlines the requirements for the Content Distribution Manager management authentication and authorization system and the integration with back-end access control servers.

The ACNS 5.0 software Cache application supports TACACS+, Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server HTTP request authentication. In the case of NTLM, HTTP request authentication authenticates a user's domain, username, and password with a preconfigured primary domain controller (PDC) before allowing requests from the user to be served by the Content Engine.

Authentication Cache Size Adjustments

If the authentication cache is not large enough to accommodate all authenticated users at the same time, the Content Engine purges older entries that have not yet timed out. The Content Engine has a timeout value range from 1 to 1440 minutes (24 hours). Its default timeout value is 480 minutes.

The default time interval between the user's last Internet access and the removal of that user's entry from the authorization cache is 480 minutes. The minimum time interval is 1 minute, and the maximum is 24 hours. The Content Engine forces reauthentication with the access control server once this time interval expires.

When LDAP, RADIUS, and TACACS+ are used in proxy redirection mode, the authentication record kept in the authentication cache is indexed by the username and the password entered. When LDAP, RADIUS, and TACACS+ are used in WCCP-enabled router redirection mode, the authentication record indexed is the IP address of the Content Engine sending the request in transparent mode.

When an NTLM server is used in either proxy redirection mode or WCCP-enabled router redirection mode, all authentication records are indexed by using the IP address of the requesting Content Engine.

Setting the Authentication Scheme

To enable an authentication scheme, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Authentication > Authentication Scheme. (See Figure 8-39.)

Figure 8-39 Authentication Scheme Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Choose an authentication scheme from the Authentication Scheme drop-down list.

Note You must configure and enable an authentication server before you can save the authentication scheme settings from this window.

Step 6 Click Submit to save the settings.

Configuring LDAP Server Settings

System administrators can use the Content Engine to restrict user Internet access using an LDAP server for authentication purposes. With an HTTP query, the Content Engine obtains a set of credentials from the user (user ID and password) and compares them against those in an LDAP server database. When the Content Engine authenticates a user through the LDAP server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is kept, subsequent attempts to access restricted Internet content by that user do not require LDAP server lookups.

The default time interval between the user's last Internet access and the removal of that user's entry from the authorization cache is 480 minutes. The minimum time interval is 1 minute, and the maximum is 1440 minutes (24 hours). The Content Engine forces reauthentication with the LDAP server once this time interval expires.

The Content Engine supports LDAP authentication for both proxy mode and transparent (WCCP) mode access. In proxy mode, the Content Engine uses the client's user ID as a key for the authentication database, whereas in transparent mode, the Content Engine uses the client's IP address as a key for the authentication database. The Content Engine uses simple (nonencrypted) authentication to communicate with the LDAP server.

ACNS 5.0 software supports LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).

To configure LDAP server settings using the Content Distribution Manager GUI, follow these steps.

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Authentication > LDAP Server. The LDAP Server Settings window appears. (See Figure 8-40.)

Figure 8-40 LDAP Server Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable LDAP Servers check box.

Step 6 Choose the LDAP protocol version to be used from the LDAP Version drop-down list.

Step 7 Specify a value in the Time to wait field.

Step 8 Specify a value in the Number of Retransmits field.

Step 9 In the User-id Attribute field, enter the user ID attribute.

Step 10 In the Filter field, enter the filter string to be used by the LDAP server.

Step 11 In the Base Distinguished Name field, enter the base distinguished name string for the search in the LDAP server.

Step 12 In the Administrative DN field, enter the administrative distinguished name.

Step 13 In the Administrative DN password field, enter the administrative distinguished name password.

Step 14 Check the Allow mode check box to enable access to users when the LDAP server is unavailable.

Step 15 Check the Active Directory Groups check box to allow the use of Windows Active Directory groups.

Step 16 Specify a value for the server port. The default port value of 389 is suggested.

Step 17 Enter the IP address of the primary LDAP server in the Primary Host field.

Step 18 Enter the IP address of the secondary LDAP server in the Secondary Host field.

Step 19 Click Submit to save the settings.

See Table 8-20 for a list of the LDAP server GUI parameters, descriptions, and CLI commands.

Table 8-20 LDAP Server Key Parameter Settings

Parameter

Description

CLI Command

Enable LDAP Servers

Enables HTTP authentication using LDAP servers.

ldap server enable

LDAP Version

LDAP protocol version to be used. Choose either Version 2 or Version 3.

ldap server version

Time to wait

Number of seconds that the Content Engine waits for a response before timing out on a connection to a particular LDAP server. The default value is 5 seconds.

ldap server time-out

Number of Retransmits

Number of times that a connection to an LDAP server is attempted before this connection is made. The default value is 2 times.

ldap server retransmit

User-id Attribute

Name of the user ID attribute at the LDAP server. The default user ID attribute is "uid".

ldap server userid-attribute

Filter

LDAP filter string. There is no default value.

ldap server filter

Base Distinguished Name

Base distinguished name of the starting point for the search of the LDAP server. This allows for a search on a particular string, such as the domain "com".

ldap server base

Administrative DN

Administrative distinguished name. This allows for a search on a particular user belonging to the base distinguished name chosen.

ldap server administrative-dn

Administrative DN Password

Password for the administrative distinguished name.

ldap server administrative-passwd

Allow-Mode

Allows access to users when the LDAP server is unavailable.

ldap server allow-mode

Active Directory Group

Allows access to Windows Active Directory groups.

ldap server active-directory-group

Server Port

Port number on which the LDAP server is listening. The default port number is 389.

ldap server port

Primary Host

IP address of the primary LDAP server.

ldap server host

Secondary Host

IP address of the secondary LDAP server.

ldap server host

Configuring NTLM Server Settings

The NTLM protocol can be used to authenticate and block user access to the Internet. When a user logs in to a Windows NT or a Windows 2000 domain and starts a browser, the authentication information is stored by the browser and later used as NTLM credentials to access the Internet. The browser sends the NTLM credentials with the domain name to the ACNS software cache, which in turns sends a request to the Windows NT domain controller to check the validity of the user in the domain. If the user is not a valid user in the domain, then the request to access the Internet is denied. If authentication succeeds, the source IP address is entered in the authentication cache. Future requests from this IP address are not challenged until the authentication cache entry expires, or is cleared.

Before invoking an NTLM authentication request, make sure that the following conditions exist.

•The NTLM primary domain controller has an entry in the DNS that matches its NetBIOS-named computer account.

•The primary domain controller is both forward and reverse DNS-resolvable.

•The domain name configured on the Content Engine should be a domain that can be authenticated through the primary domain controller (PDC).

Note This domain can be either a domain hosted by the PDC, or a trusted domain that the PDC can authenticate by contacting other PDCs.

To configure NTLM server settings using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Authentication > NTLM Server. The NTLM Server Settings window appears. (See Figure 8-41.)

Figure 8-41 NTLM Server Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable NTLM Servers check box.

Step 6 In the Domain Name field, enter the domain name in which users should be authenticated.

Step 7 In the Primary Domain Server field, enter the IP address for the primary domain server.

Step 8 In the Secondary Domain Server field, enter the IP address for the secondary domain server.

Step 9 Click Submit to save the settings.

See Table 8-21 for NTLM server GUI parameters, descriptions, and CLI commands.

Table 8-21 NTLM Server Key Parameter Settings

Key Parameter

Description

CLI Command

Domain Name

Domain name in which the user should be authenticated.

ntlm server domain name

Primary Domain Server

NTLM server that serves as the primary host.

ntlm server host hostname or ip-address primary

Secondary Domain Server

NTLM server that serves as the secondary host.

ntlm server host hostname or ip-address secondary

Configuring RADIUS Server Settings

RADIUS authentication clients reside on devices running ACNS 5.0 software. When enabled, these clients send authentication requests to a central RADIUS server, which contains user authentication and network service access information.

To configure RADIUS server settings using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Authentication > RADIUS Server. The RADIUS Server Settings window appears. (See Figure 8-42.)

Figure 8-42 RADIUS Server Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable RADIUS Servers check box to enable RADIUS authentication.

Step 6 Enter a value in the Time to wait field. The default value is 5 seconds.

Step 7 Enter a value in the number of retransmits. The default value is 2.

Step 8 Check the Enable Redirect check box to enable RADIUS redirection.

Step 9 Enter a redirect message for the user in the Redirect Message field. Three redirect messages are allowed.

Step 10 In the Location field, enter a location where the redirect message should be sent. Three separate locations are allowed.

Step 11 Enter the secret key that is used to communicate with the RADIUS server in the Shared Encryption Key field.

Step 12 Enter an IP address or host name information in the Server Name field. Five different hosts are allowed.

Step 13 Enter a port number on which the RADIUS server is listening in the Server Port field. Five different ports are allowed.

Step 14 Click Submit to save the settings.

See Table 8-22 for RADIUS server GUI parameters, descriptions, and CLI commands.

Table 8-22 RADIUS Server Key Parameter Settings

Key Parameter

Description

CLI Command

Enable RADIUS Servers

Enables HTTP authentication using RADIUS servers.

radius-server enable

Time to wait

Number of seconds to wait for a response before timing out on a connection to a particular RADIUS server. The range is from 1 to 20 seconds. The default value is 5 seconds.

radius-server timeout

Number of retransmits

Number of times that a connection to an LDAP server is attempted before a connection is made. The default value is 2 times.

radius-server retransmit

Enable redirect

Redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails.

radius-server redirect

Redirect Message

Message sent to the user if redirection occurs.

radius-server redirect

Shared Encryption Key

Encryption key shared with the RADIUS server.

radius-server key keyword

Server Name

IP address or host name of the RADIUS server.

radius-server host hostname

Server Port

Port number on which the RADIUS server is listening.

radius-server host auth-port port

Configuring TACACS+ Server Settings

The TACACS+ database validates users before they gain access to a Content Engine. TACACS+ is derived from the United States Department of Defense (RFC 1492) and is used by Cisco Systems as an additional control of nonprivileged and privileged mode access. ACNS 5.0 software supports TACACS+ only and not TACACS or Extended TACACS.

To enable TACACS+ for HTTP request authentication, use the tacacs enable global configuration configuration command. This authentication is independent of the user authentication and authorization options shown in the "Configuring HTTP and HTTPS Settings" section.

To configure TACACS+ server settings using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Authentication > TACACS+ Server. The TACACS+ Server Settings window appears. (See Figure 8-43.)

Figure 8-43 TACACS+ Server Settings Window

Step 4 Click the Add Settings button if no settings have been established.

Step 5 Check the Enable TACACS+ Server check box to enable TACACS+ authentication.

Step 6 Enter a value in the Time to wait field. The default value is 5 seconds.

Step 7 Enter a value in the number of retransmits in the Number of retransmits field. The default value is 2.

Step 8 In the Security Word field, enter the secret key that is used to communicate with the TACACS+ server.

Step 9 In the Primary Server field, enter an IP address or host name information for the primary TACACS+ server.

Step 10 In the Secondary Server field, enter an IP address or host name information for a secondary TACACS+ server.

Step 11 In the Tertiary Server field, enter an IP address or host name information for a tertiary TACACS+ server.

Step 12 Click Submit to save the settings.

See Table 8-23 for RADIUS server parameters, descriptions, and CLI commands.

Table 8-23 TACACS+ Server Key Parameter Settings

Key Parameter

Description

CLI Command

Enable TACACS+ Servers

Enables TACACS+ authentication.

tacacs enable

Time to wait

Number of seconds to wait for a response before timing out on a connection to a particular TACACS+ server. The range is from 1 to 20 seconds. The default value is 5 seconds.

tacacs timeout

Number of retransmits

Number of times that a connection to a TACACS+ server is attempted before a connection is made. The default value is 2 times.

tacacs retransmit

Security Word

Encryption key shared with the TACACS+ server.

tacacs key

Primary Server

IP address or host name of the primary TACACS+ server.

tacacs server IPaddress or hostname [primary]

Secondary Server

Tertiary Server

IP address or host name of the backup TACACS+ server. 2 backup servers are allowed.

tacacs server IPaddress or hostname

Configuring Simple Network Management Protocol

Cisco ACNS software allows you to deploy one or more Simple Network Management Protocol (SNMP) agents for your CDN.

Note In ACNS 5.0 software you can only configure SNMP agents using CLI commands or a Content Engine GUI. You cannot use the Content Distribution Manager GUI to configure SNMP.

ACNS 5.0 software supports the following versions of SNMP:

•Version 1 (SNMPv1)—This is the initial implementation of SNMP. Refer to RFC 1157 for a full description of its functionality.

•Version 2 (SNMPv2c)—This is the second release of SNMP, described in RFC 1902. It provides additions to data types, counter size, and protocol operations.

•Version 3 (SNMPv3)—This is the most recent version of SNMP, defined in RFC 2271 through RFC 2275.

SNMPv1 and SNMPv2C do not have any security (that is, authentication or privacy) mechanisms to keep SNMP packet traffic on the wire confidential. As a result, packets on the wire can be detected and SNMP community strings compromised.

To solve the security shortcomings of SNMPv1 and SNMPv2c, SNMPv3 provides secure access to Content Engines by authenticating and encrypting packets over the network. In ACNS 5.0 software, SNMPv3 features are added to the SNMP agent in addition to SNMPv1 and SNMPv2c.

Note Registering a new SNMP agent with your CDN, as well as modifying or removing a registered SNMP agent, causes each of your CDN nodes to restart as they register the configuration change. Restarting your CDN devices results in a temporary interruption in service across your CDN for the time it takes for each of your devices to come back online—usually a few minutes.

Each Cisco device running ACNS 5.0 software contains the software necessary to communicate information about device configuration and activity using the SNMP protocol. Before you can begin logging SNMP data, you must acquire and deploy an SNMP manager application for use with the CDN.

Supported MIBs

The SNMP agent supports the following MIBs:

•CISCO-CDP-MIB

•ENTITY-MIB

•CISCO-ENTITY-ASSET-MIB

•MIB-II

•CISCO-CONFIG-MAN-MIB

•CISCO-CONTENT-ENGINE-MIB (supports streaming media-related MIB objects)

•HOST-RESOURCES-MIB

•EVENT-MIB

The EVENT-MIB can set the threshold on any MIB variables supported by ACNS 5.0 software and store the threshold permanently on disk. The HOST-RESOURCES-MIB provides statistics on system resources.

The CISCO-CONTENT-ENGINE-MIB is extended to incorporate streaming related MIB objects. The following three MIB groups are implemented to incorporate statistics about the WMT server/proxy, Cisco Streaming Engine, and Real Proxy. For each 64-bit counter MIB object, a 32-bit counter MIB object is implemented so that the SNMP clients using SNMPv1 protocol can retrieve data associated with 64-bit counter MIB objects. The MIB objects of each of these groups are read-only.

•The WMT MIB group provides statistics about WMT proxy and server performance. Twenty-eight MIB objects are implemented in this group. Six of these MIB objects are implemented as 64-bit counters.

•The Cisco Streaming Engine MIB group provides statistics about RTSP streaming engine performance. Seven MIB objects are implemented in this group. Two of these MIB objects are implemented as 64-bit counters.

•The Real Proxy MIB group provides statistics about RealProxy performance. Fourteen MIB objects are implemented in this group.

Use the following link to access these MIBs:

ftp://ftp.cisco.com/pub/mibs/v2/

Key SNMP CLI Commands

Use the snmp-server group global configuration command to select one of the three SNMP versions, SNMPv1, SNMPv2c, or SNMPv3. Use the no form of this command to remove the specified version. Refer to the Cisco ACNS Software Command Reference, Release 5.0 for more information on how to use this and other SNMP commands.

The snmp-server community string command provides view-based access control for SNMPv1, SNMPv2c, and SNMPv3 but also continues to provide backward compatibility between different versions. The previous version of this command did not have an option to create a community string that allows SNMP messages to execute a set operation on a MIB object. A rw option has been introduced for this purpose. Also, the previous version of the SNMP agent did not provide selective access control to MIB objects. Access to any MIB object was denied or granted based on authentication of the SNMP community string. With the introduction of view-based access control, it is now possible to configure a community string that grants access to only part of the MIB subtree. To provide backward compatibility with the previous version of this command, a default read group or default write group (if the rw option is specified on the command line) is associated with the community string if no group name is specified. Both of these default groups are hidden from users and not displayed in the configuration file or in the show snmp group command, but are created during initialization of the SNMP agent.

Note The SNMP agent is disabled by default, and a community string is not configured.

The following example enables the SNMP agent and assigns the community string comaccess to SNMP:
507-1(config)# snmp-server community comaccess
The preceding example defines a community string comaccess used as a password for authentication when you access the SNMP agent of the Content Engine. Any SNMP message sent to the Content Engine must have the "Community Name" field of the message match the community string defined here in order to be authenticated. Entering a community string enables the SNMP agent.

The following example disables the SNMP agent and removes the previously defined community string.
507-1(config)# no snmp-server community 
Configuring SNMP Traps

To enable the Content Engine to send SNMP traps, use the snmp-server enable traps global configuration command. If you do not enter the snmp-server enable traps command, no traps are sent. Use the no form of this command to disable all SNMP traps or only SNMP authentication traps.

The snmp-server enable traps command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which hosts or hosts receive SNMP traps. To send traps, you must configure at least one host.

For a host to receive a trap, both the snmp-server enable traps command and the snmp-server host command for that host must be enabled.

In addition, SNMP must be enabled with the snmp-server community command.

To disable the sending of the MIB-II SNMP authentication trap, you must enter the command no snmp-server enable traps snmp authentication.

The following example enables the Content Engine to send all traps to the host 172.31.2.160 using the community string public:
ContentEngine(config)# snmp-server enable traps
ContentEngine(config)# snmp-server host 172.31.2.160 public
The following example disables all traps:

Content Engine (config)# no snmp-server enable traps

Configuring Services on Content Routers

Configuring services on Content Routers differs from configuring services on Content Engines and device groups in that only platform configuration and authentication services need to be enabled on Content Routers.

The configuration windows for these features are the same windows as those used for Content Engines and device groups. See the following sections and pages for configuration information.

For platform configuration, see the following sections:

•Configuring System Logging

•Configuring NTP Settings

•Configuring CDP Settings

For authentication and authorization, see the following sections:

•About Authentication

•Configuring Content Authentication

For more information regarding the use of Content Routers in the CDN environment, see "Setting Up Content Request Routing in the CDN."