Cisco Cache Application Product Overview

Cache Application Overview

The Cache application portion of Cisco ACNS software deployed on Cisco Content Engines is one of the content delivery elements of the Content Delivery Network (CDN) solution from Cisco Systems. The CDN solution allows the proactive distribution of rich media files to Content Engines at the network edge for local access to e-business applications such as e-learning, e-commerce, knowledge sharing, and corporate communications. Designed for affordability and ease of installation, the CDN solution enables you to quickly deploy high-impact, high-bandwidth rich media, such as high-quality streaming video, with minimal administration.

Cisco Content Engines with Cache application software installed accelerate content delivery by caching frequently accessed content (transparently or proxy-style) and then locally fulfilling content requests rather than traversing the Internet or intranet to a distant server. This solution helps to protect your network from uncontrollable bottlenecks and accelerates the delivery of content, enabling service providers to offer higher service quality and enabling enterprise employees to be more productive. By caching content such as Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP) traffic, Cisco Content Engines minimize redundant network traffic that traverses WAN links. As a result, WAN bandwidth costs either decrease or grow less quickly. This bandwidth optimization increases network capacity for additional users or traffic and for new services, such as voice.

Advanced Transparent Caching Service

Cisco Content Engines offer advanced transparent caching technologies that include:

Overload bypass—Prevents a Content Engine from becoming a bottleneck when traffic loads exceed the capacity of a Content Engine.
Dynamic client bypass—Prevents source IP authentication problems by selectively allowing clients to directly connect to origin servers.
Flow protection—Prevents existing flows from being broken when the Web Cache Communication Protocol (WCCP) cluster load distribution changes because of the addition or subtraction of a Content Engine into or from a cluster.
WCCP slow start—Prevents cluster destabilization when a new Content Engine is added to a heavily loaded cluster.
Rules Template—Enables flexible establishment of caching policies or rules, for example, "no-cache" policies, refresh policies, upstream proxy selection rules, and URL rewrite rules.

To integrate with existing proxy infrastructures, the Cisco ACNS software supports a number of proxied protocols, including FTP, Hypertext Transfer Protocol Secure (HTTPS), HTTP 1.0, and HTTP 1.1. With the Rules Template feature, administrators can establish proxy policies, providing control over how traffic is proxied.

The Cisco Content Engines can be deployed in front of a website (reverse proxy) to transparently cache inbound requests for content, significantly reducing the traffic and TCP connection maintenance performed by origin servers.

By supporting WCCP Version 2 or by interoperating with the Cisco CSS 11000 Series switches, a Content Engine can achieve a basic level of transparency that includes:

Transparently receiving content traffic
Fault tolerance
Scalable clustering

Configuring Caching Management Features

You can configure the Cache application with the command-line interface (CLI) or with the Cache application graphical user interface (GUI). This guide contains mostly CLI configuration examples. However, GUI examples are shown whenever a feature requires them or to illustrate a feature through a screen capture.

For information on CLI commands, refer to the Cisco Application and Content Networking Software Command Reference.

Logging On to the Graphical User Interface

The graphical user interface has separate online help for those Cache application features supported with the graphical management interface.

To connect to the graphical user interface, perform the following steps.

Step 1 Start a web browser on a machine that has access to the network on which the Content Engine resides.

Note Be sure to enable Java, JavaScript, and Cascading Style Sheets on your Internet Explorer browser, or use Netscape 4.0 or later browser.

Step 2 Open the URL with the cache IP address specified in the initial Cache application configuration. Append the default port number 8001. For example:

http://172.16.13.8:8001

You are prompted for a username and password. (See Figure 1-1.)

Figure 1-1: Cache Application GUI—Authentication Challenge

Step 3 Enter a correct username and password. The Content Engine returns the graphical user interface home page, as shown in Figure 1-2.

If you forget your password, you must have another administrator reset your password. The password for the user admin is specified in the initial system configuration dialog.

Figure 1-2: Cache Application Graphical User Interface—Home Page

Administering Caching from the Cache Application Graphical User Interface

Graphical user interface (GUI) configuration pages exist for the following features:

Authenticated cache
Authentication
Basic networking
Bypass
Cache on abort
Content preload
Disk configuration
DNS
FTP freshness
FTP proxy
HTTP freshness
HTTP proxy
HTTPS proxy
Internet Cache Protocol (ICP) client
ICP server
Lightweight Directory Access Protocol (LDAP)
NT LAN Manager (NTLM)
Network Time Protocol (NTP)
Persistent connection
Proxy protocols
RADIUS
RealProxy
Remote Authentication Dial-In User Service (RADIUS)
Routing
Rules Template
SNMP
Syslog
TACACS+
TCP
Transaction logs
URL filtering
Users
WCCP clustering
WCCP custom web cache
WCCP media caching
WCCP reverse proxy
WCCP services
WCCP web caching
WCCP WMT streaming
WMT streaming

Access to the Cache application GUI can be controlled with multiple levels of username and password access, and access can be restricted to a subset of IP addresses (hosts). These access controls are configured with the user command and the trusted-host command, which are the same commands that you use to configure access to the CLI.

Note Be sure to enable Java, JavaScript, and Cascading Style Sheets on your Internet Explorer browser, or use Netscape 4.0 or later browser.

Secure Shell Version 1 Support for Login

Secure Shell (SSH) enables login access to the Content Engine through a secure and encrypted channel. SSH consists of a server and a client program. Like Telnet, you can use the client program to remotely log on to a machine that is running the SSH server, but unlike Telnet, messages transported between the client and the server are encrypted. The functionality of SSH includes user authentication, message encryption, and message authentication.

Before you enable the sshd command, use the ssh-key-generate command to generate a private and a public host key, which the client programs use to verify server's identity.

When a user runs an SSH client and logs in to the Content Engine, the public key for the SSH daemon running on the Content Engine is recorded in the client machine known_hosts file in the user's home directory. If the Content Engine administrator subsequently regenerates the host key by issuing the ssh-key-generate command, the user must delete the old public key entry associated with the Content Engine in the known_hosts file before running the SSH client program to log in to the Content Engine. When the user runs the SSH client program after deleting the old entry, the known_hosts file is updated with the new SSH public key for the Content Engine.

Note The Telnet daemon can still be used with the Content Engine. SSH does not replace Telnet.

This example generates an SSH public key and then enables the SSH service.

Console(config)# ssh-key-generate

Ssh host key generated successfully
Saving the host key to box ...
Host key saved successfully
 
Console(config)# sshd enable

Starting ssh daemon ...
Ssh daemon started successfully

System Logging

Use the logging command 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.

To configure the Content Engine to send varying levels of event messages to an external syslog host, use the logging host command. Logging can be configured to send various levels of messages to the console using the logging console priority option. (See Table 1-1.)

Table 1-1: Mapping of RealProxy Error Level to Syslog Priority Level

RealProxy Error Code	RealProxy Condition	RealProxy Usage	syslog Priority Level
0	Panic	Error potentially causing a system failure. RealSystem takes actions necessary to correct the problem.	Priority 0—LOG_EMERG, Emergency. System is unusable.
1	Severe	Error requiring immediate user intervention to prevent a problem.	Priority 1—LOG_ALERT, Alert. Immediate action needed.
2	Critical	Error that may require user intervention to correct.	Priority 2—LOG_CRI, Critical. Critical conditions.
3	General	Error that does not cause a significant problem with normal system operation.	Priority 3—LOG_ERR, Error. Error conditions.
4	Warning	Warning about a condition that does not cause system problems but may require attention.	Priority 4—LOG_WARNING Warning. Warning conditions.
5	Notice	Notice about a condition that does not cause system problems but should be noted.	5—LOG_NOTICE Notice. Normal but significant conditions.
6	Informational	Informational message only.	6—LOG_INFO Information. Informational messages.
7	Debug	Information of use only when debugging a program.	7—LOG_DEBUG Debug. Debugging messages.

Note In ACNS 4.1 software, syslog messages from the Content Engine to a remote host are sourced from port 10000 rather than port 514.

This example shows the last few lines of the syslog.txt file using the type-tail command, which only lists the last few lines of text in a file.

ContentEngine# type-tail syslog.txt

Jan 18 17:50:03 ContentEngine Host[3766]: authentication failure; (uid=0) -> aaHH for 
content_engine_config service
Jan 18 17:50:05 ContentEngine login[3766]: Failed login session from 172.16.1.1 for user 
aaHH:  Authentication service cannot retrieve authentication info.
Jan 18 18:39:05 ContentEngine Host[6787]: set privilege level to \Q0'
Jan 18 18:39:05 ContentEngine login: user login on 1 from 172.16.66.148
ContentEngine#

Mapping Syslog Priority Levels to RealProxy Error Codes

The RealProxy (See the "Configuring RealProxy 8.01" section) generates error messages and writes them to the RealProxy log file. These error messages are captured by the Cache software and passed to the system log file. There is a one-to-one mapping correspondence between the RealProxy error codes and the syslog priority levels, as shown in Table 1-1.

Network Time Protocol Time Synchronization

To configure the Network Time Protocol (NTP) and to allow the system clock to be synchronized by a time server, use the ntp server global configuration command. The Content Engine can remain within a particular time zone while it synchronizes to Coordinated Universal Time (UTC).

To disable this function, use the no form of this command.

ntp server {hostname | ip-address}

no ntp server {hostname | ip-address}

In this example the time of the Content Engine is synchronized to a time server with an IP address of 172.16.22.44.

ContentEngine(config)# ntp server 172.16.22.44

In this example the time-synchronization configuration to the time server at 172.16.22.44 is disabled.

ContentEngine(config)# no ntp server 172.16.22.44