Table Of Contents

Monitoring and Troubleshooting

Monitoring with SNMP

Understanding the Different Versions of SNMP

SNMP Security Models and Security Levels

Supported MIBs

Enabling the SNMP Agent on a Content Engine

Defining SNMP Users

Defining SNMPv3 Users Using the Content Engine GUI

Defining SNMPv3 Users Using CLI Commands

Configuring the Content Engine to Send SNMP Traps

Configuring SNMP Traps Using the Content Engine GUI

Configuring SNMP Traps Using CLI Commands

Using Cisco Discovery Protocol

Transaction Logging

Understanding the Transaction Log Formats

Squid-Style Transaction Logging

Extended Squid-Style Transaction Logging

Apache-Style Transaction Logging

Custom Format Transaction Logging

Transaction Logging and NTLM Authentication

Usage Guidelines for Log Files

Understanding Working Logs

Archive Working Log

Sanitizing Transaction Logs

Exporting Transaction Log Files

Exporting Transaction Logs to External FTP or STFP Servers

Enabling and Configuring Transaction Logging Using the Content Engine GUI

Exporting Transaction Logs to an FTP or SFTP Server Using the Content Engine GUI

Enabling and Configuring Transaction Logging Using CLI Commands

Exporting Transaction Logs to External FTP Servers Using CLI Commands

Restarting Export After Receiving a Permanent Error from the External FTP Server

Exporting Transaction Logs to External SFTP Servers Using CLI Commands

Configuring System Logging

Using CiscoWorks2000

Configuring System Logging Using the Content Engine GUI

Configuring System Logging Using CLI Commands

Mapping Syslog Priority Levels to RealProxy Error Codes

Creating HTTP Custom Error Pages

Usage Guidelines

Configuring HTTP Custom Error Pages Using the Content Engine GUI

Configuring HTTP Custom Error Pages Using CLI Commands

HTTP Custom Error Message Configuration Examples

Traceroute Support

Monitoring and Troubleshooting

---

This chapter describes how to monitor a Content Engine using the Simple Network Management Protocol (SNMP). It also explains how to use the transaction logging and system logging features supported by the Content Engine. The chapter also describes how to use traceroute. This chapter contains the following sections:

•Monitoring with SNMP

•Transaction Logging

•Configuring System Logging

•Creating HTTP Custom Error Pages

•Traceroute Support

---

Note For complete syntax and usage information for the CLI commands used in this chapter, refer to the Cisco ACNS Software Command Reference, Release 5.1.

---

Monitoring with SNMP

SNMP is an interoperable standards-based protocol that allows for external monitoring of the Content Engine through an SNMP agent.

An SNMP-managed network consists of three primary components: managed devices, agents, and management systems.

•A managed device is a network node that contains an SNMP agent and resides on a managed network.

•Managed devices collect and store management information and use SNMP to make this information available to management systems that use SNMP. Managed devices include routers, access servers, switches, bridges, hubs, computer hosts, and printers.

•An SNMP agent is a software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. The SNMP agent gathers data from the Management Information Base (MIB), which is the repository for information about device parameters and network data. The agent can also send traps, or notification of certain events, to the manager.

Each Content Engine that is running ACNS 5.x software has an SNMP agent that is responsible for gathering information about the Content Engine's device configuration and activity. Before you can access this SNMP information, you must have deployed an SNMP management application on a management station. This SNMP management station is referred to as the SNMP host because it uses SNMP to send the device agent an SNMP Get request to obtain information from the Content Engine.

The SNMP management station and the device agent (the SNMP agent on the Content Engine) use SNMP to communicate, as follows:

1. The SNMP management station (the SNMP host) uses SNMP to request information from the Content Engine.

2. After receiving these SNMP requests, the device agent on the Content Engine accesses a table that contains information about the individual device (the Content Engine). This table, or database, is called a Management Information Base (MIB).

---

Note The SNMP agent on the Content Engine only initiates communication with the SNMP host under unusual conditions; it will initiate communication when it has a trap it needs to send to the host. For more information on this topic, see the "Configuring the Content Engine to Send SNMP Traps" section.

---

3. After locating the specified information in the MIB, the device agent uses SNMP to send the information to the SNMP management station.

Figure 17-1 illustrates these SNMP operations when the Content Engine has been locally deployed.

Figure 17-1 SNMP Components with a Locally Deployed ACNS Content Engine

Understanding the Different Versions of SNMP

ACNS 5.x 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.

SNMP Security Models and Security Levels

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. The SNMP agent in the ACNS 5.x software supports SNMPv3 as well as SNMPv1 and SNMPv2c.

The following security features are provided in SNMPv3:

•Message integrity—Ensures that nothing has interfered with a packet during transmission.

•Authentication—Determines that the message is from a valid source.

•Encryption—Scrambles the contents of a packet to prevent it from being seen by an unauthorized source.

SNMPv3 provides security models as well as security levels. A security model is an authentication process that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security process is used when an SNMP packet is handled. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3.

Table 17-1 describes the combinations of security models and security levels.

Table 17-1 SNMP Security Models and Security Levels 

Model	Level	Authentication	Encryption	Process
v1	noAuthNoPriv	Community string	No	Uses a community string match for user authentication.
v2c	noAuthNoPriv	Community string	No	Uses a community string match for user authentication.
v3	noAuthNoPriv	Username	No	Uses a username match for user authentication.
v3	AuthNoPriv	Message Digest 5 (MD5) or Secure Hash Algorithm (SHA)	No	Provides authentication based on the Hash-Based Message Authentication Code (HMAC)-MD5 or HMAC-SHA algorithms.
v3	AuthPriv	MD5 or SHA	Yes	Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encryption Standard (DES) 56-bit encryption (packet authentication) based on the cipher block chaining (CBC)-DES (DES-56) standard.

The SNMPv3 agent can be used in the following modes:

•noAuthNoPriv mode (that is, no security mechanisms turned on for packets)

•AuthNoPriv mode (for packets that do not need to be encrypted using the privacy algorithm [DES 56])

•AuthPriv mode (for packets that must be encrypted; privacy requires that authentication be performed on the packet)

Using SNMPv3, users can securely collect management information from their SNMP agents without fear that the data has been tampered with. Also, confidential information, such as SNMP set packets that change a Content Engine's configuration, can be encrypted to prevent their contents from being exposed on the wire. Also, the group-based administrative model allows different users to access the same SNMP agent with varying access privileges.

Supported MIBs

The ACNS 5.x software implementation of SNMP supports the following MIBs:

•MIB-II

•ENTITY-MIB

•HOST-RESOURCES-MIB

•CISCO-CONTENT-ENGINE-MIB

•CISCO-ENTITY-ASSET-MIB

•CISCO-CONFIG-MAN-MIB

•CISCO-CDP-MIB

---

Note The CISCO-CONTENT-ENGINE-MIB now supports streaming WMT, RealProxy, and Cisco Streaming Engine statistics.

---

In the ACNS 5.1 software release, you can use IP access control lists (ACLs) to control SNMP access on a Content Engine. For more information about defining IP ACLs, see "Creating and Managing IP Access Control Lists."

Enabling the SNMP Agent on a Content Engine

By default, the SNMP agent on the Content Engine is disabled and an SNMP community string is not defined. The SNMP community string is used as a password for authentication when accessing the SNMP agent on the Content Engine. In order to be authenticated, the Community Name field of any SNMP message sent to the Content Engine must match the SNMP community string defined on the Content Engine.

The SNMP agent on the Content Engine is enabled when an SNMP community string is defined on the Content Engine. You can use the CLI or the Content Engine GUI to define an SNMP community string and enable the SNMP agent, as follows:

•From the CLI, use the snmp-server community command. For example,

ContentEngine(config)# snmp-server community comaccess

•From the Content Engine GUI, choose System > SNMP. In the displayed SNMP window, scroll down to the Community field and enter an SNMP community string (as shown in Figure 17-2). Click Update.

Figure 17-2 SNMP Window for SNMPv1 and SNMPv2

If the SNMPv3 protocol is going to be used for SNMP requests, the next step is to define an SNMP user account that can be used to access the Content Engine through SNMP

For more information on how to create an SNMPv 3 user account on the Content Engine, see the next section "Defining SNMP Users".

Defining SNMP Users

When defining SNMP users for a locally deployed Content Engine, note the following:

•If the SNMPv3 protocol is going to be used for SNMP requests, you must define at least one SNMPv3 user account on the Content Engine in order for the Content Engine to be accessed through SNMP.

•A group defined with the SNMPv1 or SNMPv2c security model should not be associated with SNMP users; they should only be associated with the community strings.

•You can use either the Content Engine GUI or the CLI to define SNMPv3 user accounts.

Defining SNMPv3 Users Using the Content Engine GUI

To configure an SNMPv3 user account on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose System > SNMP. The SNMP window for configuring SNMPv1 or SNMPv2 appears. (See Figure 17-3.)

Figure 17-3 SNMP Window for SNMPv1 and SNMPv2

Step 2 Scroll down to the bottom of the SNMP window.

Step 3 At the bottom of the window, click the SNMPv3 Configuration Click here link. The SNMP window for configuring SNMPv3 settings (including SNMPv3 user accounts) appears. (See Figure 17-4.)

Figure 17-4 SNMPv3 Window

Step 4 Scroll down to the SNMPV3 User configuration section of the SNMP v3 window (as shown in Figure 17-5).

Figure 17-5 Defining SNMPv3 User Accounts

Step 5 Use the SNMPV3 user configuration fields and drop-down lists to define new SNMPv3 user accounts on this Content Engine.

a. In the Name field, enter the name of the SNMP user. Use letters, numbers, dashes, and underscores, but no blanks. This is the name of the user on the SNMP host who wants to communicate with the SNMP agent on the Content Engine.

b. In the Group field, enter the name of the group to which the SNMP user belongs.

c. In the Remote SnmpID field, enter the globally unique identifier for a remote SNMP entity (for example, the SNMP network management station) for at least one of the SNMP users.

---

Tip In order to send an SNMPv3 inform message, at least one SNMPv3 user with a remote SNMP ID option must be configured on the Content Engine. The SNMP ID is entered in octet string form. For example, if the IP address of a remote SNMP entity is 192.147.142.129, then the octet string would be 00:00:63:00:00:00:a1:c0:93:8e:81.

---

d. From the Auth-Algorithm drop-down list, choose the algorithm used to authenticate the SNMP user (md5, sha, or no_auth). By default, no_auth for no authentication is chosen.

–Choose md5 for the HMAC-MD5-96 authentication level.

–Choose sha for the HMAC-SHA-96 authentication level.

e. In the optional Auth-Password field, enter the HMAC MD5 user authentication password. This field is only applicable if you chose md5 as the authentication type.

f. In the optional Priv-Password field, enter the HMAC MD5 user private password. This field is only applicable if you chose md5 as the authentication type. This is a string that enables the SNMP agent to receive packets from the host.

Step 6 Click Update to add the new SNMPv3 user account. The new user account that you just created is listed in the SNMPv3 window.

Step 7 Continue to add more SNMPv3 user accounts. To remove an existing SNMPv3 user account, click the Delete check box next to the account that you wish to remove.

Step 8 Click Update again to save your changes to the SNMPv3 user accounts.

---

Defining SNMPv3 Users Using CLI Commands

To define an SNMPv3 user account on a Content Engine (the SNMP server), use the snmp-server user global configuration command. Use the no form of this command to remove SNMP access.

snmp-server user name group [auth {md5 password [priv password] | sha password [priv password]} | remote octetstring [auth {md5 password [priv password] | sha password [priv password]}]]

Table 17-2 describes the parameters for the snmp-server user command.

Table 17-2 Parameters for the snmp-server user CLI Command 

Parameter	Description
name	Name of the SNMP user.
group	Group to which the SNMP user belongs.
auth	(Optional) Configures user authentication parameters.
md5	Configures the HMAC MD5 authentication algorithm.
password	HMAC MD5 user authentication password.
priv	(Optional) Configures the authentication parameters for the packet.
password	HMAC MD5 user private password.
sha	Configures the HMAC SHA authentication algorithm.
password	HMAC SHA authentication password.
remote	(Optional) Specifies engine identity of remote SNMP entity to which the user belongs.
octetstring	Engine identity octet string.

In the following example, an SNMPv3 user account is created on the Content Engine. The SNMPv3 user is named acme and belongs to the group named admin. Because this SNMP user account has been set up with no authentication password, the SNMP agent on the Content Engine will not perform authentication on SNMP requests from this user.

ContentEngine(config)# snmp-server user acme admin

Configuring the Content Engine to Send SNMP Traps

You can use either the Content Engine GUI or the CLI to configure SNMP traps on a locally deployed Content Engine.

Configuring SNMP Traps Using the Content Engine GUI

To configure SNMP traps on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose System > SNMP. The SNMP window appears. (See Figure 17-6.)

Figure 17-6 SNMP Window for SNMPv1 and SNMPv2

Step 2 From the SNMP window, do one of the following:

•To configure the Content Engine SNMPv1 or SNMPv2 agent to send SNMP traps to a specific SNMP host, enter information in the appropriate fields of this window, and click UPDATE.

For example, you must define the SNMP trap host by specifying the host name or IP address of the SNMP trap host that will be sent in the SNMP trap messages from the Content Engine.

•To configure the Content Engine's SNMP v3 agent to send SNMP traps to a specific SNMP host, scroll down to the bottom of the SNMP window. Click the SNMPv3 Configuration Click here link. The SNMP window for configuring an SNMPv3 agent on the Content Engine appears. (See Figure 17-4.) Use the SNMPv3 window to configure SNMP traps and SNMP v3 user accounts for this Content Engine.

For more information about configuring SNMPv3 user accounts, see the "Defining SNMPv3 Users Using the Content Engine GUI" section. For information about the fields in the SNMP windows, click the HELP button in the SNMP window to obtain context-sensitive help.

---

Configuring SNMP Traps Using CLI Commands

You can also use the Content Engine CLI to configure SNMP traps on a locally deployed Content Engine. Use the following guidelines when using the CLI to configure SNMP traps on a locally deployed Content Engine:

•Use the snmp-server enable traps global configuration command to enable traps. 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.

•You must use the snmp-server enable traps command in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP traps from the Content Engine. To send traps, you must configure at least one SNMP trap host.

•For an SNMP host to receive a trap, both the snmp-server enable traps command and the snmp-server host command for that host must be configured. 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.

•Use the snmp-server group global configuration command to choose one of the three SNMP versions, SNMPv1, SNMPv2c, or SNMPv3. Use the no form of this command to deselect the currently selected version.

•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 the snmp-server community string 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.

---

Table 17-3 shows how to use the CLI to configure SNMP traps on a locally deployed Content Engine. Refer to the Cisco ACNS Software Command Reference, Release 5.1 for more information on how to use this and other SNMP commands.

Table 17-3 CLI Examples of Configuring SNMP Traps on a Local Content Engine 

Purpose	Command
Enables all SNMP traps on the Content Engine.	ContentEngine(config)# snmp-server enable traps
Configures the Content Engine to send all SNMP 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
Enables the SNMP agent and assigns the community string comaccess 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.	ContentEngine(config)# snmp-server community comaccess
Disables the SNMP agent and removes the previously defined community string.	ContentEngine(config)# no snmp-server community
Disables all SNMP traps on the Content Engine.	ContentEngine(config)# no snmp-server enable traps

Using Cisco Discovery Protocol

Cisco Discovery Protocol (CDP) is a device discovery protocol that runs on all Cisco-manufactured devices. With CDP, each device within a network sends periodic messages to all other devices within the network. 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 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 enables CDP implementation with a single CLI command:

ContentEngine(config)# interface FastEthernet 0/0 cdp enable

Transaction Logging

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 address.

High-performance caching presents additional challenges other than how to quickly retrieve objects from storage, memory, or the web. Administrators of caches are often interested in what requests have been made of the cache and what the results of these requests were. This information is then used for such applications as:

•Problem identification and solving

•Load monitoring

•Billing

•Statistical analysis

•Security problems

•Cost analysis and provisioning

By default, transaction logging is disabled on the Content Engine that is running ACNS software. You can use either the Content Engine GUI or the CLI to enable transaction logging on the Content Engine. When transaction logging is enabled through the Content Engine GUI, the Squid log format is used.

Understanding the Transaction Log Formats

In ACNS 5.x software, you can choose the Squid, Extended Squid, or Apache transaction log formats, or you can use a custom log format that allows you to log additional fields. Only one format type can be active at a time. When transaction logging is enabled through the Content Engine GUI, the Squid log format is used.

Squid-Style Transaction Logging

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.

Squid Log File Format

The Squid log file format is as follows:

time elapsed remote host code/status bytes method URL rfc931 peer status/peer host 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 -

Squid transaction logs are a valuable source of information about cache workloads and performance. The logs record not only access information but also system configuration errors and resource consumption, such as memory and disk space.

Use the transaction-logs format squid command to enable transaction logging in Squid-style format.

ContentEngine(config)# transaction-logs format squid 

Table 17-4 lists the fields associated with the Squid-style format.

Table 17-4 Squid-Style Format Description 

Field	Description
Time	UNIX time stamp as Coordinated Universal Time (UTC) seconds with a millisecond resolution.
Elapsed	Length of time in milliseconds that the cache was busy with the transaction. Note Entries are logged after the reply has been sent, not during the lifetime of the transaction.
Remote host	IP address of the requesting instance.
Code/status	Two entries separated by a slash. The first entry contains information on the result of the transaction: the kind of request, how it was satisfied, or in what way it failed. The second entry contains the HTTP result codes.
Bytes	Amount of data delivered to the client. This does not constitute the net object size, because headers are also counted. Also, failed requests may deliver an error page, the size of which is also logged here.
Method	Request method to obtain an object for example, GET.
URL	URL requested.
Rfc931	Contains the authentication server's identification or lookup names of the requesting client. This field will always be a "-" (dash).
Peer status/Peer host	Two entries separated by a slash. The first entry represents a code that explains how the request was handled, for example, by forwarding it to a peer, or returning the request to the source. The second entry contains the name of the host from which the object was requested. This host may be the origin site, a parent, or any other peer. Also note that the host name may be numerical.
Type	Content type of the object as seen in the HTTP reply header. In ACNS 5.x software, this field will always contain a "-" (dash).

---

Note Many public tools are available that can convert a Squid-style transaction log into reports. Visit the following website, http://www.squid-cache.org/Scripts, for listings of such tools.

---

Extended Squid-Style Transaction Logging

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 (Table 17-4) is used to log the authorized user. This field always contains a "-" (dash) if no user information is available.

Extended Squid-Style Log File Format

An Extended Squid-style log file 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 -

Use the transaction-logs format extended-squid global configuration command to enable transaction logging in Extended Squid format.

ContentEngine(config)# transaction-logs format extended-squid 

ContentEngine(config)#

Apache-Style Transaction Logging

This 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, refer to the W3C Common Log Format website at http://www.w3.org/Daemon/User/Config/Logging.html.

Use the transaction-logs format apache global configuration command to enable transaction logging in Apache style format.

ContentEngine(config)# transaction-logs format apache

ContentEngine(config)#

Apache-Style Log File Format

The Apache-style log file format is as follows:

remotehost rfc931 authuser date request status bytes

An Apache-style log file forma 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

Table 17-5 lists the fields associated with the Apache Common Log file format.

Table 17-5 Apache Common Log File Format Descriptions 

Field	Description
Remotehost	Remote host name or IP address.
Rfc931	Contains the authentication server's identification or lookup names of the requesting client. This field will always contain a "-" (dash).
Authuser	Username that the user entered for authentication purposes. This will be a "-" (dash) if no user information is available.
Date	Date and time of the request.
Request	First line of the request.
Status	HTTP status code, for example, 200.
Bytes	Content length of the document transferred.

Custom Format Transaction Logging

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 Common Log file (CLF) format. The log format string is a string which can contain the tokens listed in Table 17-6 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.

•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 17-6 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 17-6 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 dash (-).

•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 dash (-) 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 Common Log file 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 Common Log file 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 17-6 Custom Log File Format String Values 

Format Token	Value
%...a	IP address of the requesting client.
%...A	IP address of the server from which the object was served (for example, the origin server or the outgoing proxy in the case of a cache miss or 0.0.0.0 in the case of a cache hit).
%...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 dash (-) is logged.
%...m	Request method.
%...p	Canonical port of the server servicing the request. Not applicable on the Content Engine, so a dash (-) 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 17-7.
%...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 17-7 specifies the format token for the date and time of the format token %...{format}t listed in Table 17-6.

Table 17-7 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 (01—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 (00—23).
%I	Hour as a decimal number using a 12-hour clock (01—12).
%j	Day of the year as a decimal number (001—366).
%k	Hour (24-hour clock) as a decimal number (0—23); single digits are preceded by a blank. (See also %H.)
%l	Hour (12-hour clock) as a decimal number (1—12); single digits are preceded by a blank. (See also %I.)
%m	Month as a decimal number (01—12).
%M	Minute as a decimal number (00—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 (for example, 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 (00—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 as well as Extended Squid-style format, the transaction-logs log-windows-domain command records 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.

Use the no transaction-logs log-windows-domain command to negate logging NTLM parameters in Apache-style and Extended-style formats.

Usage Guidelines for Log Files

This section provides some guidelines when working with log files.

Understanding Working Logs

Depending upon where the sysfs is mounted, transactions are logged to a working log on the local disk in one of these files:

•/local1/logs/working.log

•/local2/logs/working.log

Depending upon where the sysfs is mounted, the following log files are logged to a working log on the local disk as follows:

•WMT logs are logged to a working log on the local disk in one of these files:

–/local1/logs/export/working.log

–/local2/logs/export/working.log

•RealSubscriber logs are logged to a working log on the local disk in one of these files:

–/local1/logs/real-subscriber-logs/working.log

–/local2/logs/real-subscriber-logs/working.log

•Cisco Streaming Engine logs are logged to a working log on the local disk in one of these files:

–/local1/logs/cisco-streaming-engine/working.log

–/local2/logs/cisco-streaming-engine/working.log

•RealProxy logs are logged to a working log on the local disk in one of these files:

–/local1/logs/real-proxy/working.log

–/local2/logs/real-proxy/working.log

Archive Working Log

You can specify the interval at which the working log should be cleared by moving the data to an archive log. The archive log files are located on the local disk in the /local1/logs/ or /local2/logs/ directory depending upon where the sysfs is mounted.

Because multiple archive files are saved, the filename includes the time stamp when the file was archived. Because the files can be exported to an FTP/SFTP server, the filename also contains the IP address of this Content Engine.

The archive filename format is:

celog_IPADDRESS_YYYYMMDD_HHMMSS.txt

Sanitizing 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.

You can enable the sanitize feature in transaction logging, through the following interfaces:

•Content Engine GUI—From the Content Engine GUI, choose Cache > Transaction Logs. Check the Transaction Log Enable check box to activate transaction logging on the Content Engine, and then click the Sanitize transaction logs radio button to enable the sanitize feature. Click Update to apply the settings.

•CLI command—Use the transaction-logs sanitized global configuration command, as shown in the following example:

ContentEngine(config)# transaction-logs sanitize 

ContentEngine(config)#

The no form of this command disables the sanitize feature.

Exporting Transaction 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 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 the 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 or STFP Servers

You can use either of the following methods to export transaction logs to external FTP or secure FTP (SFTP) servers:

•CLI commands, as described in the "Exporting Transaction Logs to External FTP Servers Using CLI Commands" section and the "Exporting Transaction Logs to External SFTP Servers Using CLI Commands" section

•Content Engine GUI, as described in the "Exporting Transaction Logs to an FTP or SFTP Server Using the Content Engine GUI" section

Enabling and Configuring Transaction Logging Using the Content Engine GUI

To enable and configure transaction logging on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Transaction Logs. The Transaction Logs window appears. (See Figure 17-7.)

Figure 17-7 Transaction Logs Window

Step 2 Click the Enable transaction logging radio button to activate transaction logging on this Content Engine.

Step 3 Specify the maximum size of the archive file in kilobytes in the Maximum size of Archive file field.

Step 4 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.

Step 5 If you want to sanitize the transaction logs, click the Sanitize transaction logs On radio button.

---

Note For more information about the sanitize feature, see the "Sanitizing Transaction Logs" section.

---

Step 6 Click Update to save the settings.

Step 7 Close the Transaction Logs window, or proceed to use this window to enable exporting to an FTP server.

For more information about exporting transaction logs to an FTP server, see the next section.

---

Exporting Transaction Logs to an FTP or SFTP Server Using the Content Engine GUI

If you want to enable exporting of transaction logs to an external FTP or secure FTP (SFTP) server, 
follow these steps:

---

Step 1 From the Transaction Logs window (Figure 17-7), check the Transaction Log FTP Export radio button.

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 the necessary information about the FTP server.

---

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.

---

a. In the FTP Export Server field, enter an IP address or host name for the FTP server.

b. In the Name field, enter a user ID for the user.

c. In the Password field, enter a password for this user.

d. In the Directory field, enter the name of a working directory that will contain the transaction logs.

---

Note The user specified in the Name field must have write permission to the specified directory.

---

Step 4 Check the SFTP check box if the FTP server chosen is a secure FTP server.

Step 5 Click Update to save the settings.

---

Enabling and Configuring Transaction Logging Using CLI Commands

This section describes how to use CLIcommands to enable transaction logging in Squid, Extended Squid, Apache, or customized log format.

Table 17-8 summarizes the different transaction logging formats and the CLI commands you can use to enable and configure transaction logging on a Content Engine. For complete syntax and usage information for theses CLI commands, refer to the Cisco ACNS Software Command Reference, Release 5.1.

Table 17-8 List of Transaction Logging Formats 

Format	Description
Squid-style	Use the transaction-logs format squid command to enable a transaction log in Squid-style format: ContentEngine(config)# transaction-logs format squid For more information about the Squid-style format, see the "Configuring System Logging" section.
Extended Squid-style	Use the transaction-logs format extended-squid command to enable transaction logging in Extended Squid format. ContentEngine(config)# transaction-logs format extended-squid For more information about the Extended Squid-style format, see the "Extended Squid-Style Transaction Logging" section.
Apache	Use the transaction-logs format apache command to enable transaction logging in Apache-style format. ContentEngine(config)# transaction-logs format apache For more information about the Apache-style format, see the "Apache-Style Transaction Logging" section.
Custom	Use the transaction-log format custom command 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 Common Log format. For more information about the custom style formats, see the "Custom Format Transaction Logging" section.

Exporting Transaction Logs to External FTP Servers Using CLI Commands

To use the CLI to export transaction logs to an external FTP server, you must first enable exporting of transaction logs and then configure the FTP server parameters. Use the transaction-logs export enable global configuration command to enable exporting of transaction logs to external FTP servers. You can then use the transaction-logs export ftp-server option to enter 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.

Use the transaction-logs export compress global configuration ommand to 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 feature uses less disk space for the archived files on both the Content Engine and the FTP export server and also requires less bandwidth during export.

In this example, two FTP servers are configured.

ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mylogin mypasswd 
/ftpdirectory 

ContentEngine(config)# transaction-logs export ftp-server myhostname mylogin mypasswd 
/ftpdirectory

To delete an FTP server, use the no form of the command.

ContentEngine(config)# no transaction-logs export ftp-server 10.1.1.1 

ContentEngine(config)# no transaction-logs export ftp-server myhostname 

Use the no form of the transaction-logs export enable command to disable the entire transaction log export feature while retaining the rest of the configuration.

ContentEngine(config)# no transaction-logs export enable 

To change a username, password, or directory, reenter the entire line.

ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mynewname mynewpass 
/newftpdirectory

The show transaction-logging command displays information on the configuration of transaction logging in the Content Engine. Note that transaction log file information is displayed for HTTP and WMT MMS caching proxy transactions.

ContentEngine# show transaction-logging 

Transaction log configuration:

---------------------------------------

Logging is enabled.

Logging of ecdn internal communication is disabled.

End user identity is hidden. (sanitized)

File markers are disabled.

Archive interval: every-day every hour.

Maximum size of archive file: 2000000 KB

Log File format is extended-squid.

Exporting files to ftp servers is enabled.

File compression is disabled.

Export interval: every-day at 11:45  local time

ftp-server           username        directory

10.1.1.1	mylogin		 /ftpdirectory

10.2.2.2	mylogin		 /ftpdirectory

HTTP Caching Proxy Transaction Log File Info

  Working Log file - size : 83

                     age: 502845

  Archive Log file - celog_10.1.1.21_20020107_150300.txt        size: 1075

  Archive Log file - celog_10.1.1.21_20020117_150300.txt        size: 1199746

  Archive Log file - celog_10.1.1.21_20020118_000000.txt        size: 137583

  Archive Log file - celog_10.1.1.21_20020118_150300.txt        size: 12667

  Archive Log file - celog_10.1.1.21_20020123_150300.txt        size: 298

WMT MMS Caching Proxy/Server Transaction Log File Info

  Working Log file - size : 541

                     age: 54117

  Archive Log file - mms_export_10.1.1.21_20020107_225942       size: 541

  Archive Log file - mms_export_10.1.1.21_20020107_232156       size: 938

  Archive Log file - mms_export_10.1.1.21_20020117_193239       size: 541

  Archive Log file - mms_export_10.1.1.21_20020122_224556       size: 1993

  Archive Log file - mms_export_10.1.1.21_20020124_150334       size: 541

  Archive Log file - mms_export_10.1.1.21_20020131_025505       size: 541

ContentEngine#

---

Note For security reasons, passwords are never displayed.

---

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. The show statistics transaction-logs command displays the current state of readiness for transaction log export.

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.

In the following example, an invalid user login parameter was included in the transaction-logs export ftp-server command. The show statistics transaction-logs command shows that the Content Engine failed to export archive files.

ContentEngine# show statistics transaction-logs

Transaction Log Export Statistics:

Server:172.16.10.5

      Initial Attempts:1

      Initial Successes:0

      Initial Open Failures:0

      Initial Put Failures:0

      Retry Attempts:0

      Retry Successes:0

      Retry Open Failures:0

      Retry Put Failures:0

      Authentication Failures:1

      Invalid Server Directory Failures:0

To restart the export of archive transaction logs, you must reenter the transaction-logs export ftp-server parameters.

ContentEngine(config)# transaction-logs export ftp-server 172.16.10.5 goodlogin pass /ftpdirectory

Exporting Transaction Logs to External SFTP Servers Using CLI Commands

Use the transaction-logs export sftp-server option to export transaction logs to an external SFTP server. You must first issue the transaction-logs export enable command and then 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.

Use the no form of the transaction-logs export enable command to disable the export of transaction logs to an SFTP server.

Configuring System Logging

Use the ACNS system logging feature to set specific parameters for the system log file (syslog). This file contains authentication entries, 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.

You can use either of the following methods to configure the Content Engine to send varying levels of event messages to disk, console, or host.

•Content Engine GUI, as described in the "Configuring System Logging Using the Content Engine GUI" section

•Content Engine CLI, as described in the "Configuring System Logging Using CLI Commands" section

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 Content Engine GUI or the CLI.

Use the logging host command to forward syslog messages to a CW2K syslog server. Use the logging host priority command to send only syslog messages that have a certain severity level to the CW2K syslog server.

Configuring System Logging Using the Content Engine GUI

To configure system logging on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose System > Syslog. The Syslog window appears. (See Figure 17-8.)

Figure 17-8 Syslog Window

Step 2 In the Syslog Server field, enter the IP address or host name of the syslog server. This is the host that is to receive syslog messages from this Content Engine.

---

Note To prevent this Content Engine from sending syslog messages to an external host, delete the IP address in the Syslog Server field, or disable the Logging Host option (uncheck the Enable check box) in the Syslog window.

---

Step 3 In the Syslog File field, enter the path of the syslog file in the disk.

Step 4 Choose an option from the Facility drop-down list to specify a notification method.

Step 5 Check the Enable check box to enable sending syslog messages to the console, disk, or host.

Step 6 Choose an option from the Priority drop-down list to specify the priority level of the corresponding event. (See Table 17-9.)

Step 7 Click Update to save the settings.

---

Configuring System Logging Using CLI Commands

Use the logging command to set specific parameters for syslog.

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

Table 17-9 System Logging Priority Levels and Descriptions 

Priority Code	Condition	Syslog Priority Level
0	Emergency	Priority 0—LOG_EMERG Emergency. System is unusable.
1	Alert	Priority 1—LOG_ALERT Alert. Immediate action needed.
2	Critical	Priority 2—LOG_CRI Critical. Critical conditions.
3	Error	Priority 3—LOG_ERR Error. Error conditions.
4	Warning	Priority 4—LOG_WARNING Warning. Warning conditions.
5	Notice	5—LOG_NOTICE Notice. Normal but significant conditions.
6	Informational	6—LOG_INFO Information. Informational messages.
7	Debug	7—LOG_DEBUG Debug. Debugging messages.

---

Note Syslog messages from the Content Engine to a remote host are sourced from port 10000 rather than from 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 `0'

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 generates error messages and writes them to the RealProxy log file. (See the "Understanding RTSP" section.) These error messages are captured by the ACNS software and passed to the system log file. The correspondence between the RealProxy error codes and the syslog priority levels, as shown in Table 17-10.

Table 17-10 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. RealProxy 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 you are debugging a program.	7—LOG_DEBUG Debug. Debugging messages.

Creating HTTP Custom Error Pages

ACNS 5.1 software allows you to create HTTP customized error pages. If you create these customized pages, then the Content Engine displays the appropriate customized error page instead of the default error message when proxy errors occur.

Usage Guidelines

•You can use the Content Engine GUI or the CLI to create HTTP customized error pages for any of the error messages listed in Table 17-11.

•To change the text for a specific message, use the http custom-error-page download command, identify the message you want to change, and specify the URL that is the source for the custom message file. The custom message file can be up to 16 KB in size and is used instead of the standard message page for the specified message.

•To reset a specific message to the default message text, use the http custom-error-page reset command and identify the message that you want to return to the default page.

•To copy the current contents of a specified message page, use the http custom-error-page upload command and identify the host name or IP address, the directory, and the filename where you want to copy the specified message. The host should be reachable and allow copying a file to the specified directory.

Table 17-11 describes the custom error messages and their usage.

Table 17-11 Custom Error Page Messages 

Message Identifier	Usage
blocked-dueto-filter-error	Error response when a request is blocked because of a filter.
cache-read-error	Error response when a cache files system (cfs) read fails.
cache-write-error	Error response when a cfs write fails.
cdn-not-found-error	Error response when the ACNS network is not found.
client-access-denied-msg	Error response when a client access is denied.
client-connection-broken-error	Error response when a client connection is lost.
cr-domain-not-found-err	Error response when the Content Router could not be found.
cr-general-error	Error response when the Content Router is not operational.
cr-not-in-cz-error	Error response when the Content Router is not found in the coverage zone.
cr-unavailable-error	Error response when the Content Router is not available.
dns-not-available-error	Error response when DNS is unavailable for resolution.
expect-failed-error	Error response when Expect specifier in the HTTP request header cannot be met.
ftp-bad-login-error	Error response when the FTP login fails.
ftp-bad-url-error	Error response when the FTP request receives a bad URL.
ftp-disabled-error	Error response when the FTP is disabled.
ftp-failure-error	Error response when FTP fails.
ftp-internal-error	Error response when the FTP interval is exceeded.
ftp-not-found-error	Error response when the FTP file not found.
ftp-put-created-msg	Error response when the FTP PUT is successful.
ftp-put-error	Error response when the FTP PUT fails.
ftp-put-modified-msg	Response when the FTP update is successful.
ftp-unavailable-msg	Error response when the FTP file is unavailable.
http-blocked-port-msg	Error response when an HTTP request comes through a blocked port.
https-blocked-port-msg	Error response when an HTTPS request comes through a blocked port.
icap-processing-error	Error response when an error occurred in ICAP processing.
invalid-port-error	Error response when an invalid port is accessed.
looped-req-error	Error response when a looped request is unsuccessful.
not-enough-resources-error	Error response when enough resources are not available for the request process.
not-in-cache	Error response when the object is not found in the cache.
offline-miss-error	Error response when an off-line Content Engine finds a cache miss.
outgoing-proxy-fail-error	Error response when all outgoing proxy fails.
proxy-unauthenticated-error	Error response when the proxy authentication fails.
radius-redirect-error	Error response for a RADIUS redirect message.
request-blocked-msg	Error response when the request is blocked.
request-malformed-error	Error response when the request headers are malformed.
rev-dns-not-available-msg	Error response when DNS is not available.
server-connection-broken-error	Error response when the server connection is lost.
unsupported-cr-method-error	Error response when an unsupported Content Router method is used
www-unauthenticated-error	Error response when the server authentication fails

Configuring HTTP Custom Error Pages Using the Content Engine GUI

To configure HTTP custom error pages on a locally deployed Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose Caching > Customized Error Page. The Custom Error Page Configuration window appears. (See Figure 17-9.)

Figure 17-9 Customized Error Page Window

---

Tip Display the Proxy Error Messages drop-down list to view a list of all the proxy error messages for which you can create customized error pages. For more information on this list of custom error messages, see Table 17-11.

---

Step 2 Choose the error message that needs to be configured from the Proxy Error Messages drop-down list.

Step 3 Click the Download radio button and enter the URL in the Download URL field. The URL specifies the location from which the customized error page should be downloaded to the Content Engine.

If the customized error page is downloaded for the specified proxy error message, the Content Engine displays this error page instead of the default error message.

Step 4 In the Server IP field, enter the IP address or host name of the syslog server. This is the host that is to receive syslog messages from this Content Engine.

Step 5 Click the Upload radio button.

Step 6 Enter the appropriate information in the Upload Server IP, Remote Directory, Remote File Name, Username, and Password fields to specify the upload parameters.

---

Tip For more information about any of the fields in the Custom Error Page Configuration window, click the HELP button to access the context-sensitive help.

---

Step 7 Click Update.

---

Configuring HTTP Custom Error Pages Using CLI Commands

To use the CLI to configure HTTP custom error pages, use the http custom-error-page EXEC command.

http custom-error-page download message url | reset {all | message} | upload {ip-address | hostname} dirname filename message

Table 17-12 describes the parameters for the http custom-error-page command.

Table 17-12 Parameters for the http custom-error-page CLI Command 

Parameter	Description
download	Copies the custom error message file to the Content Engine from the specified URL.
url	Specifies the source of the custom error file. The file size cannot exceed 16 KB.
message	Specifies the type of custom error message (for example, ftp-put-error). See Table 17-11 for a list of these custom error messages
reset	Reverts to the default error page.
upload	Uploads the custom error message file to the specified host, directory, and file.
ip-address	Specifies the IP address of the host to which to copy the error page.
hostname	Specifies the host name to which to copy the error page.
dirname	Specifies the directory name to which to copy the error page.
filename	Specifies the filename to which to copy the error page.

HTTP Custom Error Message Configuration Examples

The following command copies a custom error message page to the Content Engine for the cache-read-error message:

ContentEngine# http custom-error-page download 
http://www.myserver.com/errors/cache-read-error.txt cache-read-error 

ContentEngine#

The following command copies the current contents of the cache-read-error message to a file in the errors directory on the host with the IP address 192.168.1.1:

ContentEngine# http custom-error-page upload 192.168.1.1 /errors cache-read-error.txt 
cache-read-error 

ContentEngine#

The following command resets the cache-read-error message to the default text:

ContentEngine# http custom-error-page reset cache-read-error 

ContentEngine#

Traceroute Support

Traceroute is a widely available utility on most operating systems. Much like ping, it is a valuable tool for determining connectivity in a network. Ping allows the user to find out if there is a connection between two end systems. Traceroute does this as well, but additionally lists the intermediate routers between the two systems. Users can therefore see the routes that packets can take from one system to another.

Use the traceroute EXEC command to find the route to a remote host, when either the host name or IP address is known.

ContentEngine# traceroute yahoo.com 

traceroute to 66.218.71.113 (66.218.71.113), 30 hops max, 38 byte packets

***

***

***

***

10  p3-3.paloalto-cr2.bbnplanet.net (4.0.26.13)  3.219 ms  2.001 ms  2.097 ms

11  p7-1.paloalto-nbr2.bbnplanet.net (4.0.6.77)  3.133 ms  1.949 ms  2.076 ms

12  p4-0.paloalto-nbr1.bbnplanet.net (4.0.5.65)  2.755 ms  2.204 ms  2.037 ms

13  p1-0.paix-bi2.bbnplanet.net (4.0.6.98)  2.928 ms  2.146 ms  2.334 ms

14  p1-0.xpaix17-level3.bbnplanet.net (4.0.1.70)  3.397 ms  3.631 ms  3.081 ms

15  gige10-0.ipcolo4.SanJose1.Level3.net (64.159.2.42)  3.334 ms  2.999 ms  2.388 ms

16  cust-int.level3.net (64.152.69.18)  3.871 ms  3.031 ms *

17  ge-3-3-0.msr1.pao.yahoo.com (216.115.101.42)  3.695 ms ge-2-3-0.msr2.pao.yahoo.com 
(216.115.101.46)  6.998 ms *

18  vl16.bas1.scd.yahoo.com (66.218.64.146)  6.282 ms  5.091 ms  5.162 ms

19  w2.rc.scd.yahoo.com (66.218.71.113)  6.028 ms  5.782 ms  5.544 ms

ContentEngine#