Document ID: 12563
Updated: Jan 31, 2006
Contents
Introduction
This document explains the codes that you see after issuing the show transaction-log entries 255 command on the Cisco Content Engine. These log codes are written in Squid Log Format, and each log can be parsed with any log file parsing tool used on Squid caching logs.
Before You Begin
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
Prerequisites
Readers of this document should be knowledgeable of Squid Log Format.
Unlike the common log format, Squid's native log format was designed with
Content Engine statistics in mind. This format can be generated not only by
Squid, but also by commercial Content Engines, such as ContentFlow, InfoLibria,
and NetContent. For more information, refer to
Squid Web Proxy
Content
.
Components Used
The information in this document is based on the software and hardware versions below.
-
all releases of Cisco Content Engine Software (formerly Cache Engine Software)
-
all versions of Cisco Content Engine (formerly Cache Engine Software)
Standard Log Codes
This section explains the standard log codes.
TCP_HIT
A valid copy of the requested object was in the Content Engine.
TCP_MISS
The requested object was not in the Content Engine.
TCP_REFRESH_HIT
The object was in the Content Engine, but it was stale (old). An If-Modified-Since request was made, and a 304 Not Modified reply was received.
TCP_REF_FAIL_HIT
The object was in the Content Engine, but it was stale. The request to validate the object failed, so the stale object was returned.
TCP_REFRESH_MISS
The object was in the Content Engine, but it was stale. An If-Modified-Since request was made, and the reply contained new content.
TCP_CLIENT_REFRESH
The client issued a request with the no-cache pragma.
TCP_IMS_HIT
The client issued an If-Modified-Since request, and the object was in the Content Engine and still fresh.
TCP_IMS_MISS
The client issued an If-Modified-Since request for a stale object.
TCP_SWAPFAIL
The object was believed to be in the Content Engine, but it could not be accessed.
TCP_DENIED
Access was denied for this request.
UDP_
This code refers to requests on the Internet Control Protocol (ICP) port (3130).
UDP_HIT
A valid copy of the requested object was in the Content Engine.
UDP_HIT_OBJ
A valid copy of the requested object was in the Content Engine, but the object data was small enough to be sent in the User Datagram Protocol (UDP) reply packet. It saves the Transmission Control Protocol (TCP) request.
UDP_MISS
The requested object was not in the Content Engine.
UDP_DENIED
Access was denied for this request.
UDP_INVALID
An invalid request was received.
UDP_RELOADING
The ICP request was refused because the Content Engine is busy reloading its metadata.
ERR_
This code refers to various types of errors for HTTP requests.
Hierarchy Data Codes
This section explains the hierarchy data codes.
DIRECT
The object has been requested from the origin server.
FIREWALL_IP_DIRECT
The object has been requested from the origin server because the origin host IP address is inside your firewall.
FIRST_PARENT_MISS
The object has been requested from the parent Content Engine with the fastest weighted round-trip time.
FIRST_UP_PARENT
The object has been requested from the first available parent in your list.
LOCAL_IP_DIRECT
The object has been requested from the origin server because the origin host IP address matched your local_ip list.
SIBLING_HIT
The object was requested from a sibling Content Engine, which replied with a UDP_HIT.
NO_DIRECT_FAIL
The object could not be requested because of firewall restrictions, and no parent Content Engines were available.
NO_PARENT_DIRECT
The object was requested from the origin server because no parent Content Engines exist for the URL.
PARENT_HIT
The object was requested from a parent Content Engine, which replied with a UDP_HIT.
SINGLE_PARENT
The object was requested from the only parent Content Engine appropriate for this URL.
SOURCE_FASTEST
The object was requested from the origin server because the source_ping reply arrived first.
PARENT_UDP_HIT_OBJ
The object was received in a UDP_HIT_OBJ reply from a parent Content Engine.
SIBLING_UDP_HIT_OBJ
The object was received in a UDP_HIT_OBJ reply from a sibling Content Engine.
PASSTHROUGH_PARENT
The neighbor or proxy defined in the passthrough_proxy config option was used.
SSL_PARENT_MISS
The neighbor or proxy defined in the ssl_proxy config option was used.
DEFAULT_PARENT
No ICP queries were sent to any parent Content Engines. This parent was chosen because it was marked as default in the config file.
ROUNDROBIN_PARENT
No ICP queries were received from any parent Content Engines. This parent was chosen because it was marked as default in the config file, and it had the lowest Round Robin use count.
CLOSEST_PARENT_MISS
This parent was selected because it included the lowest Round-Trip Time (RTT) measurement to the origin server. This only appears with a query_icmp on option set in the config file.
CLOSEST_DIRECT
The object was fetched directly from the origin server because this Content Engine measured a lower RTT than any of the parent Content Engines.
Related Information
Open a Support Case
(Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.
