Table Of Contents
show statistics access-lists 300
show statistics authentication
show statistics http-authcache
show statistics transaction-logs
Cisco ACNS Software Commands
This chapter contains an alphabetical listing of all commands of Cisco ACNS 4.2 software.
access-lists
To configure access control list entries, use the access-lists command in global configuration mode.
access-lists {300 {deny groupname {any [position number] | groupname [position number]}} | {permit groupname {any [position number] | groupname [position number]}} | enable}
no access-lists {300 {deny groupname {any [position number] | groupname [position number]}} | {permit groupname {any [position number] | groupname [position number]}} | enable}
Syntax Description
Defaults
No default behaviors or values
Command Modes
Global configuration
Usage Guidelines
In ACNS 4.2 software, you can configure group authorization using an access control list (ACL) after a user has been authenticated against an NTLM or LDAP server. The use of this list configures a group privilege when members of the group are accessing content provided by the Content Engine. Using the ACL allows or prevents users belonging to certain groups from viewing specific content. This authorization feature offers more granular access control by specifying that access is only allowed to specific groups.
Use the access-lists enable global configuration command to enable the use of the ACL.
Use the access-lists 300 command to permit or deny a group from accessing the Internet using the Content Engine. For instance, use the access-lists 300 deny groupname marketing to prevent any user from the marketing group from accessing content through the Content Engine.
Access List Design Considerations
Access lists are built using the following design considerations:
•
A user can belong to several groups.
•
•
•
•
•
In this example, four groups are defined under a groupname string called Groupname.
Groupname = "engineering1,engineering2,marketing,sales"Note that in this example, the number of characters for the groups under the groupname string Groupname cannot exceed 128 characters. The number of groups in the string equals 4. The number of characters in each group is fewer than 32 characters.
Examples
In this example, you can display the configuration of the ACL by using the show access-lists 300 command.
ContentEngine# show access-lists 300Access Control List Configuration---------------------------------Access Control List is enabledGroupname-based List (300)1. permit groupname techpubs2. permit groupname acme13. permit groupname engineering4. permit groupname sales5. permit groupname marketing6. deny groupname anyTo display statistical information for the ACL, use the show statistics access-lists 300 command.
ContentEngine# show statistics access-lists 300Access Control Lists Statistics-----------------------------------------Groupname and username-based List (300)Number of requests: 1Number of deny responses: 0Number of permit responses: 1To reset the statistical information for the ACL, use the clear statistics access-lists 300 command.
ContentEngine# clear statistics access-lists 300Console(config)# access-lists 300 permit groupname acme1 position 2aclVerifierUpdateEntry() 1#402#412#acme1#2#5#aclVerifierUpdateEntry() nNoCmd 1aclVerifierUpdateEntry() nPermissionMode 402aclVerifierUpdateEntry() nUserOrGroup 412aclVerifierUpdateEntry() sName acme1aclVerifierUpdateEntry() nPosition 2aclVerifierUpdateEntry() nDuplicatePosition 5ACL lockedacl_InsertNode() nPosition 2 nDuplicatePosition 6acl_DeleteNode() insideacl_DeleteNode() nPosition 6acl_DeleteNode() current->pAclEntryACL unlockedasset tag
To set the tag name for the CISCO-ENTITY-ASSETT-MIB, use the asset command in global configuration mode.
asset tag name
no asset tag name
Syntax Description
Defaults
No default behaviors or values
Command Modes
Global configuration
Usage Guidelines
Use this command to set the tag name.
Examples
Console(config)# asset tag entitymibauthentication
To configure user authentication options, use the authentication command in global configuration mode. Use the no form of the command to selectively disable options.
authentication {configuration {local | radius | tacacs} enable [primary | secondary | tertiary]} | login {local | radius | tacacs} enable [primary | secondary | tertiary]}
no authentication {configuration {local | radius | tacacs} enable [primary | secondary | tertiary]} | login {local | radius | tacacs} enable [primary | secondary | tertiary]}
Syntax Description
Defaults
Local authentication methods are enabled by default.
Command Modes
Global configuration
Usage Guidelines
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.
The authentication command configures both the authentication and authorization methods that govern login and configuration access to the Content Engine. Login and configuration privileges are maintained in three databases in ACNS 4.2 software: the local database, TACACS+ database, and Remote Authentication Dial-In User Service (RADIUS) database. If all databases are enabled, then all three databases are queried. If the user data cannot be found in the first database queried, then the second and third databases are queried.
The authentication login command determines whether the user has any level of permission to access the Content Engine. The authentication configuration command authorizes the user with privileged access (configuration access) to the Content Engine.
The authentication login local and the authentication configuration local commands use a local database for authentication and authorization.
The authentication login tacacs and authentication configuration tacacs commands use a remote TACACS+ server to determine the level of user access.
Note
The authentication login radius and authentication configuration radius commands use a remote RADIUS server to determine the level of user access.
Note
By default, the local method is enabled, with TACACS+ and RADIUS both disabled for login and configuration. Whenever TACACS+ and RADIUS are disabled, local is automatically enabled. TACACS+, RADIUS, and local methods can be enabled at the same time. The primary option specifies the first method to attempt for both login and configuration; the secondary option specifies the method to use if the primary method fails. The tertiary option specifies the method to use if both primary and secondary methods fail. If all methods of an authentication login or authentication configuration command are configured as primary, or all as secondary or tertiary, local is attempted first, then TACACS+, and then RADIUS.
The following example enables local, TACACS+, and RADIUS authentication and authorization, setting TACACS+ as the first method used, local as the secondary method if the TACACS+ method fails, and RADIUS as the tertiary method to use if both local and TACACS+ fail.
ContentEngine(config)# authentication login tacacs enable primaryContentEngine(config)# authentication login local enable secondaryContentEngine(config)# authentication login radius enable tertiaryContentEngine(config)# authentication configuration tacacs enable primaryContentEngine(config)# authentication configuration local enable secondaryContentEngine(config)# authentication configuration radius enable tertiaryThis is an example of the show authentication user command:
ContentEngine# show authentication userLogin Authentication: Console/Telnet Session----------------------------- -----------------------local enabled (secondary)radius enabled (tertiary)tacacs enabled (primary)Configuration Authentication: Console/Telnet Session----------------------------- -----------------------local enabled (secondary)radius enabled (tertiary)tacacs enabled (primary)HTTP Request Authentication
The ACNS 4.2 software Cache application supports TACACS+, Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server HTTP request authentication. NTLM authentication from an HTTP request 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.
TACACS+ Authentication
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 4.2 supports TACACS+ only and not TACACS or Extended TACACS.
TACACS+ provides both authentication and authorization options. To configure TACACS+, use the authentication and tacacs commands. To enable TACACS+, use the tacacs enable command.
Note
For more information on TACACS+ authentication, see tacacs.
NTLM Authentication
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 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. For more information on NTLM authentication, see ntlm.
RADIUS HTTP Request Authentication
RADIUS authentication clients reside on the Content Engine running ACNS 4.2 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 parameters, use the radius-server command in global configuration mode. To disable RADIUS authentication parameters, use the no form of this command. For more information on RADIUS authentication, see radius-server.
LDAP HTTP Request Authentication
System administrators can use the Content Engine to restrict user Internet access using an LDAP server for authentication purposes, which provides most of the services of the X.500 protocol with less complexity and overhead.
Use the ldap global configuration command to enable LDAP authentication. Use the no form of the command to disable LDAP functions. An LDAP-enabled Content Engine authenticates users with an LDAP server. 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.
ACNS 4.2 software supports LDAP version 2 and version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL). For more information on LDAP authentication, see ldap.
HTTP Request Considerations
When the Content Engine authenticates a user through a TACACS+, NTLM, RADIUS, or LDAP server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is retained, subsequent attempts to access restricted Internet content by that user do not require server lookups.
The http authentication cache timeout command specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires reauthentication.
An NTLM or LDAP authenticated user has to belong to an access control list to allow access to requested content.
Note
Note
Excluding Domains from HTTP Authentication Servers
To exclude domains from HTTP authentication servers, use the rule no-auth domain command. TACACS+, NTLM, RADIUS, or LDAP authentication takes place only if the site requested does not match the specified pattern.
Proxy Mode Server Authentication
The events listed below occur when the Content Engine is configured for HTTP request authentication and one of the following two scenarios is true:
•
•
1.
2.
3.
4.
5.
6.
7.
8.
Transparent Mode Authentication
The events listed below occur when the Content Engine is configured for H TTP request authentication and both of the following are true:
•
•
1.
2.
3.
4.
5.
6.
7.
8.
In transparent mode, the Content Engine uses the client IP address as a key for the authentication database.
If you are using user authentication in transparent mode, we recommend that the AuthTimeout interval configured with the http authentication cache timeout command be short. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (PC, workstation, and the like). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. When the Content Engine operates in proxy mode, it can authenticate the user with the user ID and password.
Server Redundancy
Authentication servers can be specified with the corresponding authentication server (NTLM, LDAP, or RADIUS) host command options, or (TACACS+) server hostname command option, to configure additional servers. These additional servers provide authentication redundancy and improved throughput, especially when Content Engine load-balancing schemes distribute the requests evenly between the servers. If the Content Engine cannot connect to any of the authentication servers, no authentication takes place and users who have not been previously authenticated are denied access.
Security Options
The Content Engine uses simple (nonencrypted) authentication to communicate with the authentication server. Future expansion may allow for more security options based on Secure Socket Layer (SSL), SASL, or certificate-based authentication.
Hierarchical Caching in Proxy Mode
In some cases, users are located at branch offices. A Content Engine (CE1) can reside with them in the branch office and be configured in proxy mode. Another Content Engine (CE2) in proxy mode or another HTTP-compatible proxy device can reside upstream, with a TACACS+, NTLM, RADIUS, or LDAP server available to both Content Engines or proxy devices for user authentication.
Note
If branch office user 1 accesses the Internet, and content is cached at CE1, then this content cannot be served to any other branch office user unless that user is authenticated. CE1 must authenticate the local users.
Assuming that both CE1 and CE2 are connected to the server and authenticate the users, when branch office user 2 firsts requests Internet content, CE1 responds to the request with an authentication failure response (either HTTP 407 if in proxy mode, or HTTP 401 if in transparent mode). User 2 enters the user ID and password, and the original request is repeated with the credentials included. CE1 contacts the HTTP request authentication server to authenticate user 2.
Assuming authentication success, and a cache miss, the request along with the credentials is forwarded to CE2. CE2 also contacts the authentication server to authenticate user 2. Assuming authentication success, CE2 either serves the request out of its cache or forwards the request to the origin server.
User 2 authentication information is now stored in the authentication cache in both CE1 and CE2. Neither CE1 nor CE2 needs to contact the authentication server for user 2's subsequent requests (unless user 2's entry expires and is removed from the authentication cache).
This scenario assumes that CE1 and CE2 use the same method for authenticating users. Specifically, both Content Engines must expect the user credentials (user ID and password) to be encoded in the same way.
Note
Hierarchical Caching in Transparent Mode
When the Content Engine operates in transparent mode, the user IP address is used as a key to the authentication cache. When user 2 sends a request transparently to CE1, after authentication, CE1 inserts its own IP address as the source for the request. Therefore, CE2 cannot use the source IP address as a key for the authentication cache.
When CE1 inserts its own IP address as the source, it must also insert an X-Forwarded-For header in the request (http append x-forwarded-for-header command). CE2 must first look for an X-Forwarded-For header. If one exists, that IP address must be used to search the authentication cache. Assuming the user is authenticated at CE2, then CE2 must not change the X-Forwarded-For header, just in case there is a transparent CE3 upstream.
In this scenario, if CE1 does not create an X-Forwarded-For header (for example, if it is not a Cisco Content Engine and does not support this header), then authentication on CE2 will not work.
Hierarchical Caching, Content Engine in Transparent Mode with an Upstream Proxy
In a topology with two Content Engines, assume that CE1 is operating in transparent mode and CE2 is operating in proxy mode, with the browsers of all users pointing to CE2 as a proxy.
Because the browsers are set up to send requests to a proxy, an HTTP 407 message is sent from CE1 back to each user to prompt for credentials. By using the 407 message, the problem of authenticating based on source IP address is avoided. The username and password can be used instead.
This mode provides better security than using the HTTP 401 message. The Content Engine examines the style of the address to determine whether there is an upstream proxy. If there is, the Content Engine uses an HTTP 407 message to prompt the user for credentials even when operating in transparent mode.
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. Its default timeout value is 480 minutes.
Use the http authentication cache timeout command to configure the authentication cache timeout parameters if necessary.
The maximum number of entries that is maintained in authentication cache is 32000. The minimum number is 500. The default value is 16000. Use the http authentication max-entries command to configure this parameter if necessary.
The http authentication command has a header option that can be set to display a message to the client when authorization has failed. In this scenario you can choose http authentication header 401 (Unauthorized) or http authentication header 407 (Proxy Authorization Required). By default, the Content Engine authenticates cache loads based on the URL syntax of the incoming request.
Use the show http authentication command to display the authentication cache parameters.
Transaction Logging
Once a user has been authenticated through TACACS+, LDAP, NTLM, or a RADIUS server, all transaction logs generated by the Content Engine for that user contain user information. If the Content Engine is acting in proxy mode, the user ID is included in the transaction logs. If the Content Engine is acting in transparent mode, the user IP address is included instead.
If the transaction-logs sanitize command is invoked, the user information is suppressed.
In this example, the host for the LDAP server daemon is configured:
Console(config)# ldap server host www.someDomain.com port 390To delete an LDAP server, use the no ldap server command.
Console(config)# no ldap server host 1.1.1.1In this example, the host for the RADIUS server is configured:
Console(config)# radius-server 172.16.90.121In this example, the length of time that entries are valid in the authentication cache is set:
Console(config)# http authentication cache timeout 1000The following example specifies that the Content Engine should use header 407 when asking the end user for authentication credentials (user ID and password).
Console(config)# http authentication header 407End-to-End Authentication
The ACNS 4.2 software Cache application supports both basic and NTLM end-to-end authentication. End-to-end NTLM authentication includes pass-through servicing and the caching of web objects that require NTLM authentication. HTTP request authentication authenticates a user's domain, username, and password with a preconfigured NTLM domain controller before allowing requests from the user to be served by the Content Engine. NTLM authentication works only in a Microsoft environment (for instance, Microsoft Internet Explorer clients accessing Microsoft Internet Information Servers).
Note
Basic End-to-End Authentication
The ACNS software Cache application can strip NTLM authentication headers to allow fallback to a basic-style authentication challenge against Microsoft Internet Information System (IIS) servers.
This feature is designed to allow browsers to authenticate against a Microsoft IIS web server that issues an NTLM-based challenge. NTLM is proprietary and undocumented. Removing the NTLM headers allows the browser to fall back on the basic authentication method. If IIS is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security. Use the http authenticate-strip-ntlm global configuration command to enable stripping of the NTLM headers.
NTLM End-to-End Authentication
The two levels of NTLM end-to-end support can be summarized as follows:
•
If NTLM pass-through service is set on the server, the Content Engine sets up a secure persistent connection between the client and the server through the Content Engine. NTLM authentication messages pass through this virtual persistent connection. The Content Engine does not cache any object transferred on the virtual connection. All the client requests are served by the origin server.
•
The ACNS 4.2 software Cache application can be configured to cache objects that require NTLM authentication. The server puts a "no-store" flag on a reply object to prevent the reply from being cached. If no such flag is present, the object is cacheable. When the Content Engine receives a request from a client already connected with the intended NTLM server, the ACNS software searches the cache. For a cache miss, the request is forwarded to the origin server. The reply object is then sent to the client and a copy is cached. On a cache hit, the Content Engine checks for a secured connection between this client and the server. If the object requires NTLM authentication and there is no virtual persistent connection set up between the client and the server, the
Content Engine establishes the secured connection between client and server and forwards the request to the server. If there is a virtual persistent connection between the client and the server, an If-Modified-Since (IMS) message is sent to the server to verify the validity of the object and the user's access rights to this object before the cached copy is served to the client.This example configures a Content Engine for end-to-end NTLM authentication. By default, basic and NTLM authenticated objects are not cached.
Console(config)# no http authenticate-strip-ntlmConsole(config)# http cache-authenticated ntlmConsole# show http cache-authenticated ntlmBasic authenticated objects are not cached.NTLM authenticated objects are cached.Examples
The following example enables local and TACACS+ authentication and authorization, setting TACACS+ as the first method used and local as the secondary method to use if TACACS+ fails.
Console(config)# authentication login tacacs enable primaryConsole(config)# authentication login local enable secondaryConsole(config)# authentication configuration local enable secondaryConsole(config)# authentication configuration tacacs enable primaryThis is an example of the show authentication command.
Console# show authenticationLogin Authentication: Console/Telnet Session----------------------------- -----------------------local enabledtacacs enabled (primary)Configuration Authentication: Console/Telnet Session----------------------------- -----------------------local enabledtacacs enabledThis is an example of the show statistics authentication command.
Console# show statistics authenticationAuthentication Statistics--------------------------------------Number of access requests: 37Number of access deny responses: 14Number of access allow responses: 23Related Commands
show authentication
show statistics authentication
tacacs
autosense
To enable autosense on an interface, use the autosense interface configuration command. To disable this function, use the no form of this command.
autosense
no autosense
Syntax Description
This command has no arguments or keywords.
Defaults
Autosense is enabled by default.
Command Modes
Interface configuration
Usage Guidelines
Cisco router Ethernet interfaces do not negotiate duplex settings. If the Content Engine is connected to a router directly with a crossover cable, the Content Engine interface must be manually set to match the router interface settings. Disable autosense before configuring an Ethernet interface. When autosense is on, manual configurations are overridden. You must reboot the Content Engine to start autosensing.
Examples
ContentEngine(config-if)# autosenseContentEngine(config-if)# no autosensebandwidth
To configure an interface bandwidth, use the bandwidth interface configuration command. To restore default values, use the no form of this command.
bandwidth mbits
no bandwidth
Syntax Description
Defaults
1000 Mbps on Gigabit Ethernet interfaces.
Command Modes
Interface configuration
Usage Guidelines
Use this command to set the bandwidth on Fast Ethernet interfaces. Gigabit Ethernet interfaces run at 1000 Mbps only.
Examples
ContentEngine(config-if)# bandwidth 10ContentEngine(config-if)# no bandwidthboomerang
To enable boomerang content routing on the Content Engine and enter domain configuration mode, use the boomerang domain configuration command.
boomerang {dns {domain domain-name [alias alias-name | content-server ip-address [file filename] | dns-ttl seconds | hops hops | key {0 keyword | 7 keyword | keyword} | origin-server ip-address] | enable} | log-races enable}
no boomerang {dns {domain domain-name [alias alias-name | content-server ip-address [file filename] | dns-ttl seconds | hops hops | key {0 keyword | 7 keyword | keyword} | origin-server ip-address] | enable} | log-races enable}
Syntax Description
Defaults
dns-ttl: 20 seconds
key: 0 (clear text)
log-races enable: disabled
Command Modes
Domain configuration
Usage Guidelines
Use the boomerang dns enable command to enable content routing software on a Content Engine that you want to configure as a content routing agent. Use the boomerang dns domain command to configure the Content Engine as a content routing agent for a specified domain and to enter the domain configuration mode to establish operating parameters for the specified domain name.
Boomerang agents support multiple domains, where each agent domain may be associated with a different boomerang server. Other than memory limits, there are no limits to the number of domains supported on the agent. For more information on the boomerang agent, refer to the Cisco Content Routing Software Configuration and Command Reference, Release 1.1.
Caution
Use the boomerang dns domain domain-name alias alias-name command to set alternate boomerang domain names that share the same operating parameters. If you are using the Content Engine as a content routing agent, use this command on both the Content Router and the Content Engine to establish an alternative name for a domain.
Note
If the Content Engine is not used to serve web pages, use the content-server ip-address file filename option to specify the address of the cache to be used. If it wins the race, the content server is the local web cache or mirror cache that serves content for the requesting web client that initiated the DNS race. The boomerang client probes the content server periodically to ensure that it is running and able to serve web pages. The probe consists of an HTTP GET request for the configured filename. A response of 200 OK indicates that the content server is running. If a filename is not given, attempts to connect are made only through port 80.
If you are using the Content Engine as a content routing agent, use the boomerang dns domain domain-name dns-ttl command to specify the DNS TTL value contained in the DNS response generated by the agent. In general, a lower DNS TTL value ensures more recent content, whereas a higher DNS TTL value reduces the Content Router load. The higher the DNS TTL value, the less the load on the Content Router. A lower value means an increased Content Router load, but also means that the addresses of Content Engines that won DNS races are used for a shorter length of time in the annealing process. For example, if the DNS TTL is set at 60 seconds, a DNS server returns to the Content Router to look up a domain name no more than once a minute. In other words, the name server uses the winning Content Engine address for 60 seconds before consulting the Content Router again. Use the no dns-ttl command to reset the delay to its default value.
Note
The number of hops to live value of the DNS response is generated by the client. The value specified by the hops option overrides the value specified by the boomerang server.
The key shared secret string specifies the secret that is matched against the secret contained in the packets sent by the server. The shared secret configured on the client domain needs to be the same as the secret configured on the server.
Use the origin-server ip-address subcommand if the Content Engine is used as a cache rather than as a mirror site. If the web cache does not have the requested content, or there is a cache miss, it must obtain the content from the origin server and cache it for future requests. Because the Content Engine web cache does not have the IP address of the origin server, this subcommand must be set to provide the IP address to obtain content from the origin server.
The boomerang log-races enable command enables logging of the DNS IP address resolution timing results between the boomerang server and the agent. To disable the command, enter the no boomerang log-races command.
To delete a domain, enter the no boomerang command. It is not necessary to enter arguments and variables before deleting the current domain name.
Examples
In the following example, assume that a domain is named www.foobar.com. It is given the domain name www.foobar.com on the Content Router.
Console(config)# boomerang dns enableConsole(config)# boomerang dns domain www.foobar.comIn the following example, assume that a domain is named www.foobar.com. It is given the alias www.foobar.net on the Content Router.
Console(config-domain)# alias www.foobar.netWhen configuring www.foobar.com on the agent, enter the alias on the Content Engine as follows.
Console(config-domain)# alias www.foobar.netRelated Commands
show boomerang
boomerang dump-log
To write boomerang memory data to a local disk file, use the boomerang dump-log EXEC command.
boomerang dump-log
no boomerang dump-log
Syntax Description
This command has no arguments or keywords.
Defaults
No default behaviors or values
Command Modes
EXEC
Usage Guidelines
Enable the boomerang logging function with the boomerang log-races enable command, and then dump the log to file using the boomerang dump-log EXEC command. The command writes data in memory to a disk file, for example:
/local/local1/logs/boomerang/boomlog.txtExamples
Console(config)# boomerang dump-logwriting Boomerang events to /local1/logs/boomerang/boomlog.txt file ......finishedRelated Commands
boomerang send-packet
boomerang send-packet
To send test packets to determine whether or not a destination accepts boomerang-altered source IP addresses, use the boomerang send-packet EXEC command.
boomerang send-packet {tcp | udp} dest-port source-port {dest-ip-address | dest-hostname} {source-ip-address | source-hostname}
no boomerang send-packet {tcp | udp} dest-port source-port {dest-ip-address | dest-hostname} {source-ip-address | source-hostname}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Some networks may have filters that prevent the transmission of packets with source addresses outside the address space of the network. If you are using the Content Engine as a content routing agent, such filters could inhibit the content routing process. To determine whether such filters exist, use a sniffer and the boomerang send-packet command to send a packet with a source address outside the subnet on which the Content Engine resides. The sniffer should be set up to monitor traffic on the network of the destination site to which the packet is sent. If the sniffer detects this packet, you know that the destination can accept boomerang-altered source IP addresses.
Examples
Console# boomerang send-packet tcp 53 53 10.1.1.1 10.1.1.2Related Commands
boomerang dump-log
bypass
To enable transparent error handling and dynamic authentication bypass, and to configure static bypass lists, use the bypass global configuration command. To disable the bypass feature, use the no form of the command.
bypass auth-traffic enable
bypass load {enable | in-interval seconds | out-interval seconds | time-interval minutes}
bypass static clientipaddress {serveripaddress | any-server}
bypass static any-client serveripaddress
bypass timer minutes
no bypass {auth-traffic enable | load {enable | in-interval seconds | out-interval seconds | time-interval minutes} | static {clientipaddress {serveripaddress | any-server} | any-client serveripaddress} | timer minutes}
Syntax Description
Defaults
bypass timer: 20 minutes
in-interval: 60 seconds
out-interval: 4 seconds
time-interval: 10 minutes
Command Modes
Global configuration
Usage Guidelines
Bypass features are available only with WCCP Version 2. The Content Engine can only set up a bypass for WCCP-redirected traffic, not proxy-style requests.
Authentication Traffic Bypass
Some websites, because of IP authentication, do not allow the Content Engine to connect directly on behalf of the client. To preserve transparency and to avoid a disruption of service, the Content Engine can use authentication traffic bypass to automatically generate a dynamic access list for these client/server pairs. Authentication bypass triggers are also propagated upstream and downstream in the case of hierarchical caching. When a client/server pair goes into authentication bypass, it is bypassed for an amount of time set by the bypass timer command (20 minutes by default).
Dynamic Traffic Bypass
The following two scenarios describe typical dynamic traffic bypass situations:
Scenario 1—Dynamic Bypass Upon Receiving a Web Server Error
A user issues an HTTP request from a web browser. The request is transparently intercepted and redirected to the Content Engine. The Content Engine accepts the incoming TCP connection from the web browser, determines that the request is for an object not in storage (cache miss), and issues a request for the object from the origin web server, but receives some kind of error (for instance, a protocol or authentication error) from the web server.
The Content Engine has already accepted the TCP connection from the web browser and the three-way TCP handshake has taken place. The Content Engine detects that the transaction with the web server is failed, but does not know the cause (the origin web server is performing authentication based on user source IP address, incompatibility between the TCP stacks, and so forth).
If error-handling transparent (the default) is configured and if the Content Engine receives an error from the origin server, the Content Engine sends a 200 OK response back to the browser with instructions to refresh the URL as follows.
HTTP/1.0 200 OKCache-Control; no-cacheConnection: CloseThis refresh instruction causes the client to send the request again. On the connection retry, the Content Engine does not accept the connection. It passes the request back to the WCCP-enabled router or switch unintercepted. The router then sends the flow toward the origin web server directly from the web browser, thereby bypassing the Content Engine.
Scenario 2—Dynamic Bypass Upon Receiving an Unsupported Protocol
When the Content Engine receives non-HTTP requests over TCP port 80, the Content Engine issues a "retry" response, closes the connection, and does not accept subsequent connections in the same manner as in scenario 1.
Note
These two scenarios implement the WCCP return-path functionality in WCCP, which is a mechanism whereby a Content Engine can return traffic to the WCCP-enabled router or switch, telling the router or switch to forward the packets as if the Content Engine was not present.
It is typical for about 3 percent of all HTTP traffic flows to have some kind of failure condition. These failed flows are automatically retried using authentication bypass or dynamic client bypass, demonstrating that the failure conditions were preexisting and not due to the deployment of transparent caching.
Overload Bypass
If a Content Engine becomes overwhelmed with traffic, it can use the bypass load feature to reroute the overload traffic.
When the Content Engine is overloaded and the bypass load command is enabled, the Content Engine bypasses a bucket. If the load remains too high, another bucket is bypassed, 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.
When the first bucket bypass occurs, a time 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.
Bypass Static
The bypass static command permits traffic from specified sources to bypass the Content Engine. The types of traffic sources are as follows:
•
•
•
Wildcards in either the source or the destination field are not supported.
To clear all static configuration lists, use the no form of the command.
Examples
This example forces HTTP traffic from a specified client to a specified server to bypass the Content Engine.
ContentEngine(config)# bypass static 10.1.17.1 172.16.7.52This example forces all HTTP traffic destined to a specified server to bypass the Content Engine.
ContentEngine(config)# bypass static any-client 172.16.7.52This example forces all HTTP traffic from a specified client to any web server to bypass the Content Engine.
ContentEngine(config)# bypass static 10.1.17.1 any-serverThis example forces all authenticated HTTP traffic to bypass the Content Engine for 24 hours.
ContentEngine(config)# bypass auth-traffic enableContentEngine(config)# bypass timer 1440A static list of source and destination addresses helps to isolate instances of problem-causing clients and servers.
•
ContentEngine# show bypass listClient Server Entry type------ ------ ----------10.1.17.1:0 172.16.7.52:0 static-configany-client:0 172.16.7.52:0 static-config10.1.17.2:0 any-server:0 static-config•
Total number of HTTP connections bypassed = 0Connections bypassed due to system overload = 0Connections bypassed due to authentication issues = 0Connections bypassed due to facilitate error transparency = 0Connections bypassed due to static configuration = 0Total number of entries in the bypass list = 3Number of Authentication bypass entries = 0Number of Error bypass entries = 0Number of Static Configuration entries = 3Related Commands
rule
show bypass
show statistics bypass
clear bypass
cache
To perform cache-related actions, use the cache EXEC command.
cache {clear [force] | reset | synchronize}
To clear the disk of all cached content, use the cache clear EXEC command.
Syntax Description
clear
Clears the cache.
force
(Optional) Forces deletion of all cached objects.
reset
Resets the cache (unmounts, formats, and mounts cache file system volumes).
synchronize
Synchronizes the cache.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The cache clear command removes all cached contents from the currently mounted cfs volumes. Objects being read or written are removed when they cease being "busy." The equivalent to this command is the clear cache or cfs clear command.
Caution
The cache clear force deletes all cfs objects, whether busy or not, and may generate broken GIF or HTML messages for objects that were being read from the disk when the command was executed. If an object is being written to the Content Engine disk when a cache clear force command is executed, the application stops caching that object but still delivers the object from the web server to the client.
The cache synchronize command synchronizes the cache file system and the media file system contents from memory to disk. Although synchronization is performed at regular intervals while the Content Engine is operating, this command can be used to ensure that all data is written to disk before you reset or turn off the Content Engine. Synchronization can also be done using the cfs sync and mediafs sync commands.
Examples
ContentEngine# cache clear forceRelated Commands
clear cache
cfs
cd
To change from on directory to another directory, use the cd EXEC command.
cd directoryname
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to maneuver between directories and for file management. The directory name becomes the default prefix for all relative paths. Relative paths do not begin with a slash (/). Absolute paths begin with a slash (/).
Examples
Relative path:
ContentEngine(config)# cd local1Absolute path:
ContentEngine(config)# cd /local1Related Commands
dir
lls
ls
mkdir
pwd
deltree
cdp
To enable Cisco Discovery Protocol (CDP) on an interface, use the cdp command in interface configuration mode.
cdp enable
Syntax Description
Defaults
No default behavior or values
Command Modes
Interface configuration
Usage Guidelines
Use this command to enable CDP on an interface.
Examples
ContentEngine(config-if)# cdp enablecdp
To configure Cisco Discovery Protocol (CDP) options, use the cdp command in global configuration mode.
cdp {enable | holdtime seconds | timer seconds}
no cdp {enable | holdtime seconds | timer seconds}
Syntax Description
Defaults
holdtime: 180 seconds
timer: 60 seconds
Command Modes
Global configuration
Usage Guidelines
When enabled using the cdp enable command, Cisco Discovery Protocol (CDP) obtains protocol addresses of neighboring devices and discovers the platform of those devices. It also shows information about the interfaces used by your router. CDP is media- and protocol-independent, and runs on Cisco-manufactured equipment.
Use of SNMP with the CDP Management Information Base (MIB) allows network management applications to learn the device type and the SNMP agent address of neighboring devices, and to send SNMP queries to those devices. Cisco Discovery Protocol uses the CISCO-CDP-MIB.
Each device configured for CDP sends periodic messages, known as advertisements, to a multicast address. The cdp timer seconds command specifies the rate at which CDP packets are sent. Each device advertises at least one address at which it can receive SNMP messages. The advertisements also contain Time To Live or hold time information. To set the hold time, use the cdp holdtime seconds command to specify the period of time in seconds that a receiver is to keep CDP packets. Each device also listens to the periodic CDP messages sent by others to learn about neighboring devices.
Examples
In the following example, three command lines are entered in sequence. CDP is first enabled, the hold time is set to 10 seconds for keeping CDP packets, and then the rate at which CDP packets are sent (15 seconds) is set.
ContentEngine(config)# cdp enableContentEngine(config)# cdp holdtime 10ContentEngine(config)# cdp timer 15Related Commands
clear cdp counters
clear cdp table
show cdp
cfs
To manipulate the cache object file system of the Content Engine, use the cfs EXEC command.
cfs clear partition [force]
cfs format partition
cfs mount partition
cfs reset partition
cfs sync partition
cfs unmount partition
no cfs {clear partition [force] | format partition | mount partition | reset partition | sync partition | unmount partition}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Cache objects retrieved from the web are saved and manipulated with the cache file system (cfs) on a cfs partition of the hard disk. This does not affect the sysfs, swfs, or mediafs partitions. The cfs commands are used to manage the cache object file system.
The cfs clear command deletes nonbusy objects from the specified cfs volume. A nonbusy object is an object that is not being accessed (read or written). The cfs clear command (without force) deletes all possible objects without generating a broken GIF or HTML message to the client.
The cfs clear force command deletes all objects, busy or nonbusy, and may generate broken GIF or HTML messages for objects that were being read from the disk when the command was executed. If an object is being written to the Content Engine disk when a cfs clear force command is executed, the application stops caching that object but still delivers the object from the web server to the client.
The cfs reset command unmounts, formats, and mounts a specified volume. Unmounting a volume can result in broken GIF or HTML messages for objects that are being read from the disk (cache hits) when the command is executed. When a cfs volume is reset, all cfs data on that volume is lost.
Note
The cfs format command creates the cache file system internal "dbs" for the cfs partition of the disk if the volume is unmounted. It formats the cfs partition to prepare it for a cfs mount. The cfs mount command creates and maps data structures in memory to the cfs partition.
Caution
The cfs unmount command frees the in-memory data structures that map to the physical (disk) cfs partition.
The cfs sync command synchronizes the cache file system contents from memory to disk. Although synchronization is performed at regular intervals while the Content Engine is running, this command can be used to ensure that all data is written to disk before you reset or turn off the Content Engine. Synchronization can also be done with the cache synchronize command.
Examples
ContentEngine# cfs sync disk05Related Commands
show cfs
cache clear
clear cache
clear
To clear the HTTP object cache, the hardware interface, statistics, archive working transaction logs, and other settings, use the clear EXEC command.
clear bypass {counters | list}
clear cache [dns [domain domainname | hostname hostname] | http [url url] | http-authentication | real-proxy | wmt]
clear cdp {counters | table}
clear logging
clear statistics {access-lists 300 | all | authentication | boomerang | dns-cache | ftp | history | http {all | cluster | ims | object | outgoing | proxy outgoing | requests | response | savings} | http-authcache | https | icp {all | client | server} | ip | ldap | mediacache real | ntlm | pre-load | radius | rule {action action-type {all | pattern pattern-type} | all} | running | tacacs | tcp | transaction-logs | url-filter {N2H2 | websense} | wmt}
clear transaction-log
Syntax Description
bypass
Clears bypass commands.
counters
Clears all bypass counters.
list
Clears all bypass lists.
cache
Clears the HTTP object from the cfs cache.
dns
(Optional) Clears cached DNS entries in the HTTP proxy.
domain
(Optional) Specifies the DNS cache domain name.
domainname
DNS cache domain name.
hostname
(Optional) Specifies the DNS cache host name.
hostname
DNS cache host name.
http
(Optional) Clears the HTTP objects cache.
url
(Optional) Clears the URL from cfs HTTP cache.
url
HTTP URL.
http-authentication
(Optional) Clears the authentication cache.
real-proxy
(Optional) Clears RealProxy cache content.
wmt
(Optional) Clears the WMT cache.
cdp
Resets CDP statistical data.
counters
Clears CDP counters.
table
Clears CDP tables.
logging
Clears syslog messages saved in disk file.
statistics
Clears statistics as specified.
access-lists
Clears access control list statistics.
300
Clears group name-based access control list.
all
Clears all statistics.
authentication
Clears authentication statistics.
boomerang
Clears boomerang statistics.
dns-cache
Clears DNS cache statistics.
ftp
Clears FTP caching statistics.
history
Clears the statistics history.
http
Clears HTTP statistics.
all
Clears all HTTP statistics.
cluster
Clears healing mode statistics.
ims
Clears HTTP if-modified-since (IMS) statistics.
object
Clears HTTP object statistics.
outgoing
Clears HTTP outgoing proxy statistics.
proxy outgoing
Clears outgoing proxy monitor statistics.
requests
Clears HTTP requests statistics.
response
Clears HTTP response statistics.
savings
Clears HTTP savings statistics.
http-authcache
Clears authentication cache statistics.
https
Clears HTTPS statistics.
icp
Clears ICP statistics.
all
Clears all ICP statistics.
client
Clears ICP client statistics.
server
Clears ICP server statistics.
ip
Clears IP statistics.
ldap
Clears LDAP statistics.
mediacache
Clears media cache statistics.
real
Clears RealProxy media cache statistics.
ntlm
Clears NTLM statistics.
pre-load
Clears preload statistics.
radius
Clears RADIUS statistics.
rule
Clears rule statistics.
action
Clears statistics of all the rules with same action.
action-type
Specifies one of the following actions:
block
cache
dscp client cache-hit
dscp clent cache-miss
dscp server
freshness-factor
insert-no-cache
no-auth
no-cache
no-proxy
redirect
refresh
reset
rewrite
selective-cache
use-dns-server
use-proxy
use-proxy-failover
use-serverSee the "rule" section for explanations of actions and patterns.
all
Clears statistics of all the patterns for this action.
pattern
Clears statistics of rules with the specified pattern.
pattern-type
Specifies one of the following patterns:
domain
dst-ip
dst-port
mime-type1
src-ip
url-regex
header-field
url-regsubSee the "rule" section for explanations of patterns and actions.
all
Clears statistics of all the rules.
running
Clears the running statistics.
tacacs
Clears TACACS+ statistics.
tcp
Clears TCP statistics.
transaction-logs
Clears transaction log export statistics.
url-filter
Clears URL filter statistics.
N2H2
Clears N2H2 URL filter statistics.
websense
Clears Websense URL filter statistics.
wmt
Clears all Windows Media Technologies (WMT) statistics.
transaction-log
Archives working transaction log files.
1 mime-type is an option for the freshness-factor, no-cache, and selective-cache actions only.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The clear cache command removes all cached contents from the currently mounted cfs volumes. Objects being read or written are removed when they cease being "busy." The equivalent to this command is the cache clear or cfs clear command.
Caution
The clear cache force command deletes all objects, whether busy or not, and may generate broken GIF or HTML messages for objects that were being read from the disk when the command was executed. If an object is being written to the Content Engine disk when a clear cache force command is executed, the application stops caching that object but still delivers the object from the web server to the client.
The clear logging command removes all current entries from the syslog.txt file, but does not make an archive of the file. It does put a syslog in syslog.txt to indicate that the syslog has been cleared as shown in the following example:
Feb 14 12:17:18 ContentEngine# exec_clear_logging:Syslog clearedThe clear statistics command clears all statistical counters from the parameters given. Use this command to monitor fresh statistical data for some or all features without losing cached objects or configurations.
The clear transaction-log command causes the transaction log to be archived immediately to the Content Engine hard disk. This command has the same effect as the transaction-log force archive command.
Examples
To purge all the entries in the bypass list, use the clear bypass list option.
ContentEngine# clear bypass listTo force the working transaction log file to be archived, use the clear transaction-log option.
ContentEngine# clear transaction-logIn the following example, the clear statistics http cluster command resets the healing mode statistics.Console(config)# clear statistics http clusterRelated Commands
cache clear
cfs clear
show statistics
show interface
show wccp
clock
To set, clear, or save the battery-backed clock functions, use the clock EXEC command.
clock {read-calendar | set time day month year | update-calendar}
no clock {read-calendar | set time day month year | update-calendar}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
If you have an outside source on your network that provides time services (such as a Network Time Protocol [NTP] server), you do not need to set the system clock manually. When setting the clock, enter the local time. The Content Engine calculates Coordinated Universal Time (UTC) based on the time zone set by the clock timezone global configuration command.
Two clocks exist in the system: the software clock and the hardware clock. The software uses the software clock. The hardware clock is used only at bootup to initialize the software clock.
The set keyword sets the software clock.
When the E-CDN application is enabled, all commands that can change the local time are disabled: clock read-calendar, clock set, ntpdate, and ntp.
Examples
ContentEngine# clock set 13:32:00 01 February 2000Related Commands
clock timezone
show clock detail
clock
To set the summer daylight saving time and time zone for display purposes, use the clock global configuration command. To disable this function, use the no form of this command.
clock {summertime timezone {date startday startmonth startyear starthour endday endmonth endyear offset | recurring {1-4 startweekday startmonth starthour endweekday endmonth endhour offset | first startweekday startmonth starthour endweekday endmonh endhour offset | last startweekday startmonth starthour endweekday endmonh endhour offset}} | timezone {timezone hoursoffset minutesoffset}}
no clock {summertime timezone {date startday startmonth startyear starthour endday endmonth endyear offset | recurring {1-4 startweekday startmonth starthour endweekday endmonh endhour offset | first startweekday startmonth starthour endweekday endmonh endhour offset | last startweekday startmonth starthour endweekday endmonh endhour offset}} | timezone {timezone hoursoffset minutesoffset}}
Syntax Description
summertime
Configures summer or daylight saving time.
timezone
Name of summer time zone.
date
Configures absolute summer time.
startday
Date (1-31) to start.
startmonth
Month (January through December) to start.
startyear
Year (1993-2032) to start.
starthour
Hour (0-23) to start in (hh:mm) format.
endday
Date (1-31) to end.
endmonth
Month (January through December) to end.
endyear
Year (1993-2032) to end.
endhour
Hour (0-23) to end in (hh:mm) format.
offset
Minutes offset (see Table 2-1) from UTC (0-59).
recurring
Configures recurring summer time.
1-4
Configures starting week number 1-4.
first
Configures summer time to recur beginning the first week of the month.
last
Configures summer time to recur beginning the last week of the month.
startweekday
Weekday (Monday-Friday) to start.
startmonth
Month (January-December) to start.
starthour
Hour (0-23) to start in (hh:mm) format.
endweekday
Weekday (Monday-Friday) to end.
endmonth
Month (January-December) to end.
endhour
Hour (0-23) to end in hour:minute (hh:mm) format.
offset
Minutes offset (see Table 2-1) from UTC (0-59).
timezone
Configures standard time zone.
timezone
Name of time zone.
hoursoffset
Hours offset (see Table 2-1) from Coordinated Universal Time (-23, +23).
minutesoffset
Minutes offset (see Table 2-1) from UTC (0-59).
Defaults
No default behavior or values
Command Modes
Global configuration
Usage Guidelines
To set and display the local and UTC current time of day without an NTP server, use the clock timezone command with the clock set command. The clock timezone parameter specifies the difference between UTC and local time, which is set with the clock set EXEC command. The UTC and local time are displayed with the show clock detail EXEC command.
Use the clock timezone offset command to specify a time zone, where timezone is the desired time zone entry from Table 2-1 and 0 0 is the offset (ahead or behind) Coordinated Universal Time (UTC) in hours and minutes. UTC was formerly known as Greenwich mean time (GMT).
ce(config)# clock timezone timezone 0 0
Note
Examples
The following example specifies the local time zone as Pacific Standard Time and offsets 8 hours behind UTC.
ContentEngine(config)# clock timezone PST -8ContentEngine(config)# no clock timezoneContentEngine(config)# clock summertime PDT date 10 October 2001 23:59 29 April 2002 23:59 60Related Commands
clock
show clock detail
configure
To enter global configuration mode, use the configure EXEC command. You must be in global configuration mode to enter global configuration commands.
configure
To exit global configuration mode, use the end, Ctrl-Z, or exit commands.
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to enter global configuration mode.
Examples
ContentEngine# configureEnter configuration commands, one per line. End with CNTL/Z.ContentEngine(config)#Related Commands
show running-config
show startup-config
end
exit
Ctrl-Z
copy
To copy configuration or image data from a source to a destination, use the copy EXEC command.
copy compactflash install filename
copy disk ftp {hostname | ip-address} remotefiledir remotefilename localfilename
copy disk startup-config filename
copy ftp disk {hostname | ip-address} remotefiledir remotefilename localfilename
copy ftp install {hostname | ip-address} remotefiledir remotefilename
copy http install {hostname | ip-address} remotefiledir remotefilename [port port_num]
copy running-config disk filename
copy running-config startup-config
copy running-config tftp {hostname | ip-address} remotefilename
copy startup-config disk filename
copy startup-config running-config
copy startup-config tftp {hostname | ip-address} remotefilename
copy system-status disk filename
copy tech-support disk filename
copy tech-support tftp {hostname | ip-address} remotefilename
copy tftp disk {hostname | ip-address} remotefilename localfilename
copy tftp running-config {hostname | ip-address} remotefilename
copy tftp startup-config {hostname | ip-address} remotefilename
no copy {compactflash install filename | disk ftp {hostname | ip-address} remotefiledir remotefilename localfilename | disk startup-config filename | ftp {disk {hostname | ip-address} remotefiledir remotefilename localfilename | install {hostname | ip-address} remotefiledir remotefilename} | http install {hostname | ip-address} remotefiledir remotefilename [port port_num] | running-config {disk filename | startup-config | tftp {hostname | ip-address} remotefilename} | startup-config {disk filename | running-config | tftp {hostname | ip-address} remotefilename} | system-status disk filename | tech-support {disk filename | tftp {hostname | ip-address} remotefilename} | tftp disk {hostname | ip-address} remotefilename localfilename | tftp running-config {hostname | ip-address} remotefilename} | tftp startup-config {hostname | ip-address} remotefilename
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The copy disk ftp command copies files from a sysfs partition to an FTP server. The copy disk startup-config command copies a startup configuration file to Flash memory.
The copy ftp disk command copies a file from an FTP server to a sysfs partition.
Use the copy ftp install command to install an image file from an FTP server. Part of the image goes to disk and part goes to Flash memory.
Use the copy http install command to install an image from an HTTP server. It transfers the image from an HTTP server to the Content Engine using HTTP as transport protocol and installs the software on the device. Part of the image goes to disk and part goes to Flash memory.
Use the copy running-config command to copy the running system configuration to a sysfs partition, Flash memory, or to a TFTP server. The copy running-config startup-config command is equivalent to the write memory command.
The copy startup-config command copies the startup configuration file to a TFTP server or to a sysfs partition.
The copy system-status command creates a file on a sysfs partition containing hardware and software status information.
The copy tech-support tftp command can copy technical support information to a TFTP server or to a a sysfs partition.
The copy tftp disk command copies a file from a TFTP server to disk.
Examples
The following example copies an image file from an FTP server and installs the file to the local device.
ce-590# copy ftp install 10.1.1.1 //users2/ACNS400BR/boot ce590-ACNS-400.binEnter username for remote ftp server:biffEnter password for remote ftp server:Initiating FTP download...printing one # per 1MB downloadedSending:USER biff10.1.1.1 FTP server (Version) Mon Feb 28 10:30:36 EST2000) ready.Password required for biff.Sending:PASS *****User biff logged in.Sending:TYPE IType set to I.Sending:PASVEntering Passive Mode (128,107,193,244,55,156)Sending:CWD //users2/ACNS400BR/bootCWD command successful.Sending PASVEntering Passive Mode (128,107,193,244,55,156)Sending:RETR ce590-ACNS-400.binOpening BINARY mode data connection for ruby.bin (87376881 bytes).###################################################################################writing flash component:.................................................................The new software will run after you reload.ce-590#Related Commands
install
reload
show running-config
show startup-config
write
cpfile
To make a copy of a file, use the cpfile EXEC command.
cpfile sourcefile destinationfile
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to create a copy of a file. Only sysfs files can be copied.
Examples
ContentEngine# cpfile ce500-194616.bin cd500-194618.binRelated Commands
copy
dir
lls
ls
mkfile
rmdir
rename
debug
Note
To monitor and record cache software functions, use the debug EXEC command. Use the no form of the command to disable debug.
debug option
no debug option
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
We recommend that the debug command be used only at the direction of Cisco Systems technical support personnel. Cache performance is affected when you run debug. Use the show debugging command to display enabled debug options.
Related Commands
show debugging
undebug
delfile
To delete a file, use the delfile EXEC command.
delfile filename
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to remove a file from a sysfs partition.
Examples
ContentEngine# delfile /local1/tempfileRelated Commands
cpfile
deltree
mkdir
mkfile
rmdir
deltree
To remove a directory with its subdirectories and files, use the deltree EXEC command.
deltree directory
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to remove a directory and all files within the directory from the Content Engine sysfs file system. Do not remove files or directories required for proper Content Engine functioning.
Examples
ContentEngine# deltree /local1/testdirRelated Commands
delfile
mkdir
mkfile
rmdir
dir
To view a long list of files in a directory, use the dir EXEC command.
dir [directory]
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to view a detailed list of files contained within the working directory, including names, sizes, and time created. The equivalent command is lls.
Examples
ContentEngine# dirsize time of last change name-------------- ------------------------- -----------3931934 Tue Sep 19 10:41:32 2000 errlog-cache-20000918-164015431 Mon Sep 18 16:57:40 2000 ii.cfg431 Mon Sep 18 17:27:46 2000 ii4.cfg431 Mon Sep 18 16:54:50 2000 iii.cfg1453 Tue Sep 19 10:34:03 2000 syslog.txt1024 Tue Sep 19 10:41:31 2000 <DIR> testdirRelated Commands
ls
lls
disable
To turn off privileged EXEC commands, use the disable EXEC command.
disable
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The disable command places you in the user-level EXEC shell. To turn privileged EXEC mode back on, use the enable command.
Examples
ContentEngine# disableRelated Commands
enable
disk
To configure the disks for devices that are using ACNS software, use the disk EXEC command.
disk add diskname {cfs {remaining | partitionsize} | ecdnfs {remaining | partitionsize} | mediafs {remaining | partitionsize} | sysfs {remaining | partitionsize}}
disk cancel-config
disk config sysfs {remaining | partitionsize} {cfs {remaining | partitionsize} | ecdnfs {remaining | partitionsize} | mediafs {remaining | partitionsize}}
disk raid-array add-array
disk raid-array repair diskname
disk recover
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use the disk config command to configure disk allocations.
Note
For example, adjust the disk storage allocations as follows:
ContentEngine# disk config sysfs 2GB cfs 6GB mediafs 2GB ecdnfs remainingUse the disk cancel-config command to cancel the configuration.
Use the disk add command to add a single disk with specified partitions.
Use the disk raid-array add-array command to create a logical disk for the Storage Array that is recognized by the CDM-4650 RAID controller.
Use the disk raid-array repair command to rebuild a RAID disk array after a single disk in the array fails.
Note
Examples
In the following example of the disk config sysfs command, 10 percent of the total storage is allocated to the sysfs and 30 percent to every other file system.
ContentEngine# disk config sysfs 10% mediafs 30% ecdnfs 30% cfs 30%Disk configured successfully.New configuration will take effect after reload.Please remove this device from the ECDN CDM (if any) before reboot this device, as this device's configuration will be stale due to disk repartition.Related Commands
show disks
show cfs
show ecdnfs
show mediafs
show statistics
dns-cache
To configure the maximum DNS cache size, use the dns-cache global configuration command. To disable the DNS cache, use the no form of this command.
dns-cache size maxnumber
no dns-cache size
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Usage Guidelines
Cache size refers to the maximum number of DNS cache entries. Domain name resolution requires that at least one DNS name server be configured with the ip name-server command. The DNS cache goes online when the ip name-server command is configured, and goes offline when the last IP name server configuration is deleted with the no ip name-server ip-address command.
Examples
In the following example, the DNS cache size is set to 20,000 records.
ContentEngine(config)# dns-cache size 20000In the following example, the DNS cache is disabled with the no form of the dns-cache command.
ContentEngine(config)# no dns-cache sizeRelated Commands
ip name-server
clear dns-cache
dnslookup
show statistics dns-cache
dnslookup
To resolve a host or domain name to an IP address, use the dnslookup EXEC command.
dnslookup {hostname | domainname}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Examples
In the following three examples, the dnslookup command is used to resolve the host name myhost to IP address 172.31.69.11, cisco.com to IP address 192.168.219.25, and the host name IP address.
ContentEngine# dnslookup myhostofficial hostname: myhost.cisco.comaddress: 172.31.69.11ContentEngine#dnslookup cisco.comofficial hostname: cisco.comaddress: 192.168.219.25ContentEngine#dnslookup 10.0.11.0official hostname: 10.0.11.0address: 10.0.11.0ecdn
To force the Enterprise CDN (E-CDN) software downgrade or to reset the administrator's Content Distribution Manager (CDM) GUI password, use the ecdn EXEC command.
ecdn {force-downgrade [disable] | reset-cdm-gui-password}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
When using the ecdn reset-cdm-gui-password command, the default password takes effect after the device is rebooted. After the CDM has rebooted, the administrator password can be changed from the default value to a new password using the CDM GUI.
Examples
In the following two examples, the first demonstrates a forced downgrade of the Enterprise CDN software without preserving content, and the second demonstrates the optional disable downgrade command.
Console# ecdn force-downgradeConsole# ecdn force-downgrade disableThe following two examples demonstrate how this command is used to reset of the administrator's CDM GUI password to its default value. The first example aborts the command after answering no to the confirmation question three times.
ecdn-cdm# ecdn reset-cdm-gui-passwordThis command will reset CDM GUI password for user admin to the default value.The default password is the word 'default'.Are you sure you want to go ahead?[yes/no]Please enter yes or no:Please enter yes or no:Please enter yes or no:noCommand aborted.The second example resets the password to its default value after answering yes to the confirmation question.
ecdn-cdm# ecdn reset-cdm-gui-passwordThis command will reset CDM GUI password for user admin to the default value.The default password is the word 'default'.Are you sure you want to go ahead?[yes/no] yesecdn
To associate the Content Engine or Content Router with the IP address and (optionally) the port number of the Content Distribution Manager and enable the Enterprise CDN (E-CDN) application, use the ecdn command in global configuration mode. To clear these parameters, use the no form of this command.
ecdn {cdm ip ip_address [port port_num] | enable}
no ecdn {cdm ip ip_address [port port_num] | enable}
Syntax Description
Defaults
If you do not specify a port number, the default is port 80. The E-CDN application is not enabled by default.
Command Modes
Global configuration
Examples
This example associates the Content Engine with the Content Distribution Manager IP address 172.17.76.76 and port number 443.
ContentEngine(config)# ecdn cdm ip 172.17.76.76 port 443This example cancels the association of the Content Engine with a Content Distribution Manager.
ContentEngine(config)# no ecdn cdm ipThis example enables the E-CDN application.
ContentEngine(config)# ecdn enableAdmin's passwd will be changed to what you have set on the CDM.Please make sure that from now on until ecdn is turned off,you make all "admin" passwd changes from the cdm GUI console.This example disables the E-CDN application.
ContentEngine(config)# no ecdn enableRelated Commands
show ecdn
enable
To access privileged EXEC commands, use the enable EXEC command.
enable
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
To access privileged EXEC mode from user EXEC mode, use the enable command. The disable command takes you from privileged EXEC mode to user EXEC mode.
Examples
ContentEngine> enableContentEngine#Related Commands
disable
exit
end
To exit global configuration mode, use the end global configuration command.
end
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Global configuration
Usage Guidelines
Use the end command to exit global configuration mode after completing any changes to the running configuration. To save new configurations to NVRAM, use the write command.
The Ctrl-Z command also exits global configuration mode.
Examples
ContentEngine(config)# endContentEngine#Related Commands
exit
Ctrl-Z
error-handling
To set error-handling options on the Content Engine, use the error-handling command in global configuration mode.
error-handling {reset-connection | send-cache-error | transparent}
no error-handling
Syntax Description
reset-connection
Resets the TCP connection without specifying any error.
send-cache-error
Sends cache error.
transparent
Makes the cache transparent to the client.
Defaults
The default is the error-handling transparent option.
Command Modes
Global configuration
Usage Guidelines
The error-handling transparent option is set by default, so that the Content Engine will not send errors to the client but will bypass the client connections to the server. Setting the error-handling send-cache-error command will send a Content Engine-generated error page to the client. Using the reset-connection option resets the TCP client connection.
If error handling is set to transparent, the Content Engine adds the client/server pair to the WCCP bypass list. The Content Engine will send a retry message to the client. The retried connection from the client is then bypassed by the Content Engine.
A transparent error bypass is triggered only if the following conditions exist:
•
•
•
For a client request, bypass occurs under the following conditions:
•
•
•
For a server response, bypass occurs under the following conditions:
•
•
•
With the transparent option enabled, end users can receive browser-generated messages rather than a Content Engine-generated HTML page for errors that the Content Engine encounters while processing a client request or response. Thus, the Content Engine remains transparent (invisible) to the end user.
Transparent error reporting is implemented as follows:
•
To make the source of the error messages transparent to the user, the client/server pair is added to the bypass list and an HTTP redirect message is sent to the client, requesting the client to redirect the request to the same URL as before. The client, on receiving the redirect message, sends back the request once again. This time, the request is bypassed by the Content Engine because the client/server pair is on the bypass list. The request now goes to the server directly. Because the connection was not accepted by the Content Engine, any timeout error, failure to connect to the server, or mangled response from the server is handled by the browser. Currently all entries on the bypass list are kept for a configurable period of time (the default is 20 minutes).
With the reset-connection option, a reset is sent back to the client and the connection is closed if it encounters an error from the server. When a browser receives a connection reset, it displays a "Connection Reset By Peer" alert box.
•
For all error conditions, the Content Engine sends back a reset and closes the connection. It does not send back any error pages. All errors seen by the clients are in the familiar browser error format.
•
The Content Engine sends back HTML error pages. When clients are using the Content Engine as an incoming proxy server, they receive the HTML error pages generated by the Content Engine.
Examples
ContentEngine(config)# error-handling transparentexception
Note
To enable error handling or debug mode, use the exception debug global configuration command. To revert to the default value, use the no form of this command.
exception {coredump | debug}
no exception {coredump | debug}
Syntax Description
coredump
Causes proxy processes to do a core dump if the system crashes.
debug
Causes proxy processes to hang if the system crashes, until they are explicitly killed.
Defaults
The default is disabled.
Command Modes
Global configuration
Examples
ContentEngine(config)# exception ?debug if enabled, proxy processes will hang there until someone kills itContentEngine(config)# exception disableContentEngine(config)# no exception disableRelated Commands
debug
exec-timeout
To configure the length of time that an inactive Telnet session remains open, use the exec-timeout global configuration command. To revert to the default value, use the no form of this command.
exec-timeout timeout
no exec-timeout
Syntax Description
Defaults
The default is 15 minutes.
Command Modes
Global configuration
Usage Guidelines
A Telnet session with the Content Engine can remain open and inactive for the interval of time specified by the exec-timeout command. When the exec-timeout interval elapses, the Content Engine automatically closes the Telnet session.
Examples
ContentEngine(config)# exec-timeout 100ContentEngine(config)# no exec-timeoutexit
To access the EXEC command shell from the global, interface, and debug configuration command shells, use the exit command.
exit
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC, global configuration, and interface configuration
Usage Guidelines
Use the exit command in any configuration mode to return to EXEC mode. This is equivalent to the Ctrl-Z or the end command.
The exit command issued in the user level EXEC shell terminates the console or Telnet session.
Examples
ContentEngine(config)# exitContentEngine# exitContentEngine>Related Commands
end
external-ip
To configure up to eight external Network Address Translation (NAT) IP addresses, use the external-ip command in global configuration mode.
external-ip ip-address
no external-ip ip-address
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Usage Guidelines
Use this command to configure up to eight Network Address Translation IP addresses to allow the router to translate up to eight internal addresses to registered unique addresses and translate external registered addresses to addresses that are unique to the private network.
Examples
ContentEngine(config)# external-ip 192.168.43.1 192.168.43.2 192.168.43.3 192.168.43.4find-pattern
To search for a particular pattern in a file, use the find-pattern command in EXEC mode.
find-pattern {binary reg-express filename | case {binary reg-express filename | count reg-express filename | lineno reg-express filename | match reg-express filename | nomatch reg-express filename | recursive reg-express filename} | count reg-express filename | lineno reg-express filename | match reg-express filename | nomatch reg-express filename | recursive reg-express filename}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
Use this command to search for a particular regular expression pattern in a file.
Examples
ContentEngine# find-pattern binaryftp
To configure FTP caching services on the Content Engine, use the ftp global configuration command. Use the no form of this command to selectively disable options.
ftp age-multiplier directory-listing dl_time file fo_time
ftp max-ttl days directory-listing dlmax_days file fmax_days
ftp max-ttl hours directory-listing dlmax_hours file fmax_hours
ftp max-ttl minutes directory-listing dlmax_min file fmax_min
ftp max-ttl seconds directory-listing dlmax_sec file fmax_sec
ftp min-ttl min_minutes
ftp object max-size size
ftp proxy active-mode enable
ftp proxy anonymous-pswd passwd
ftp proxy incoming port
ftp proxy outgoing host {hostname | ip-address} port
ftp reval-each-request {all | directory-listing | none}
no ftp {age-multiplier directory-listing dl_time file fo_time | max-ttl {days directory-listing dlmax_days file fmax_days | hours directory-listing dlmax_hours file fmax_hours | minutes directory-listing dlmax_min file fmax_min | seconds directory-listing dlmax_sec file fmax_sec} | min-ttl min_minutes | object max-size size | proxy {active-mode enable | anonymous-pswd passwd | incoming port | outgoing host {hostname | ip-address} port | reval-each-request {all | directory-listing | none}}
Syntax Description
Defaults
dl_time: 30 percent
fo_time: 60 percent
dlmax_days: 7 days
fmax_days: 3 days
dlmax_hours: 72 hours
fmax_hours: 168 hours
dlmax_min: 4320 minutes
fmax_min: 10080 minutes
dlmax_sec: 259200 seconds
fmax_sec: 604800 seconds
min_minutes: 86400 minutes
Maximum size of cacheable object: unlimited
Command Modes
Global configuration
Usage Guidelines
The Content Engine accepts FTP requests when URLs specify the FTP protocol (for example, GET ftp://ftp.cs.wisc.edu/pub/cao/READM). For these requests, the client uses HTTP as the transport protocol with the Content Engine, whereas the Content Engine uses FTP with the FTP server.
The FTP proxy supports passive and active mode for fetching files and directories. Passive mode is the default. The Content Engine automatically changes to active mode if passive mode is not supported by the FTP server. If active-mode enable is configured, FTP first attempts to fetch the file in active mode. If active mode fails, FTP attempts to fetch it again in passive mode.
The Content Engine caches both the FTP file objects and directory listings in the cfs. The Content Engine transforms the regular directory listings from the FTP server into HTML, with links that the client users can point to and click to download files.
When the Content Engine receives an FTP request from the web client, it first looks in its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server (if one is configured), or directly from the origin FTP server.
The FTP proxy supports anonymous as well as authenticated FTP requests. Only base64 encoding is supported for authentication. The FTP proxy accepts all FTP URL schemes defined in RFC 1738. In the case of a URL in the form ftp://user@site/dir/file, the proxy sends back an authentication failure reply and the browser supplies a popup window for the user to enter login information.
The FTP proxy supports commonly used MIME types, attaches the corresponding header to the client, chooses the appropriate transfer type (binary or ASCII), and enables the browser to open the FTP file with the configured application. For unknown file types, the proxy uses binary transfer as the default and instructs the browser to save the download file instead of opening it. The FTP proxy returns a formatted directory listing to the client if the FTP server replies with a known format directory listing. The formatted directory listing has full information about the file or directory and provides the ability for users to choose the download transfer type.
The Content Engine caches FTP traffic only when the client uses the Content Engine as a proxy server for FTP requests. All FTP traffic that was sent directly from the web client to an FTP server, if transparently intercepted by the Content Engine, is treated as non-HTTP traffic.
The FTP proxy supports up to eight incoming ports. It can share the ports with transparent-mode services and also with the other proxy-mode protocols supported by the Content Engine, such as HTTP and HTTPS. In proxy mode, the Content Engine accepts and services the FTP requests only on the ports configured for FTP proxy. All the FTP requests on other proxy mode ports are rejected in accordance with the error-handling settings on the Content Engine.
The Content Engine can apply the Rules Template to FTP requests based on server name, domain name, server IP address and port, client IP address, and URL.
The Content Engine logs FTP transactions in the transaction log, in accordance with the Squid syntax. When URL tracking is enabled, the Content Engine logs FTP transaction information to the syslog. The syslog entries are prefixed with <ftp>.
Examples
This example configures an incoming FTP proxy on ports 8080, 8081, and 9090. Up to eight incoming proxy ports can be configured on the same command line.
ContentEngine(config)# ftp proxy incoming 8080 8081 9090This example removes one FTP proxy port from the list entered in the previous example. Ports 8080 and 9090 remain FTP proxy ports.
ContentEngine(config)# no ftp proxy incoming 8081This example disables all the FTP proxy ports.
ContentEngine(config)# no ftp proxy incomingThis example configures an upstream FTP proxy with the IP address 172.16.76.76 on port 8888.
ContentEngine(config)# ftp proxy outgoing host 172.16.76.76 8888This example specifies an anonymous password string for the Content Engine to use when contacting FTP servers. The default password string is anonymous@hostname.
ContentEngine(config)# ftp proxy anonymous-pswd newstring@hostnameThis example configures the maximum size in kilobytes of an FTP object that the Content Engine will cache. By default, the maximum size of a cacheable object is not limited.
ContentEngine(config)# ftp object max-size 15000This example forces the Content Engine to revalidate all objects for every FTP request.
ContentEngine(config)# ftp reval-each-request allThis example configures a maximum Time To Live of 3 days in cache for directory listing objects and file objects.
ContentEngine(config)# ftp max-ttl days directory-listing 3 file 3Related Commands
show ftp
fullduplex
To configure an interface for full-duplex operation, use the fullduplex interface configuration command. To disable this function, use the no form of this command.
fullduplex
no fullduplex
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Interface configuration
Usage Guidelines
Use this command to configure an interface for full-duplex operation. Full duplex allows data to travel in both directions at the same time through an interface or a cable. A half-duplex setting ensures that data only travels in one direction at any given time. Although full duplex is faster, the interfaces sometimes cannot operate effectively in this mode. If you encounter excessive collisions or network errors, configure the interface for half duplex rather than full duplex.
Examples
ContentEngine(config-if)# fullduplexContentEngine(config-if)# no fullduplexRelated Commands
halfduplex
gui-server
To disable or specify the number of the Content Engine management graphical user interface (GUI) server port, use the gui-server global configuration command.
gui-server {enable | port port}
no gui-server {enable | port port}
Syntax Description
enable
Enables the graphical user interface.
port
Configures the graphical user interface server port.
port
Port number (1-65535). The default is 8001.
Defaults
The default port is 8001.
Command Modes
Global configuration
Examples
The following example enables the Content Engine management GUI on port 8002.
ContentEngine(config)# gui-server enableContentEngine(config)# gui-server port 8002Related Commands
show gui-server
halfduplex
To configure an interface for half-duplex operation, use the halfduplex interface configuration command. To disable this function, use the no form of this command.
halfduplex
no halfduplex
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Interface configuration
Usage Guidelines
Use this command to configure an interface for half-duplex operation. Full duplex allows data to travel in both directions at the same time through an interface or a cable. A half-duplex setting ensures that data only travels in one direction at any given time. Although full duplex is faster, the interfaces sometimes cannot operate effectively in this mode. If you encounter excessive collisions or network errors, configure the interface for half duplex rather than full duplex.
Examples
ContentEngine(config-if)# halfduplexContentEngine(config-if)# no halfduplexRelated Commands
fullduplex
help
To obtain online help for the command-line interface, use the help EXEC or global configuration command.
help
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
EXEC and global configuration
Usage Guidelines
You can get help at any point in a command by entering a question mark (?). If nothing matches, the help list will be empty, and you must back up until entering a ? shows the available options.
Two styles of help are provided:
•
•
Examples
ContentEngine# helpHelp may be requested at any point in a command by entering a question mark '?'.Two styles of help are provided:1. Full help is available when you are ready to enter a command argument.2. Partial help is provided when an abbreviated argument is entered.hostname
To configure the Content Engine's network name, use the hostname global configuration command. To reset the host name to the default setting, use the no form of this command.
hostname name
no hostname name
Syntax Description
name
New host name for the Content Engine; the name is case sensitive. The name may be from 1 to 22 alphanumeric characters.
Defaults
The default host name is the Content Engine model number (for example CE590 or CE7320).
Command Modes
Global configuration
Usage Guidelines
Use this command to configure the host name for the Content Engine. The host name is used for the command prompts and default configuration filenames.
Examples
The following example changes the host name to sandbox.
ContentEngine(config)# hostname sandboxsandbox(config)#The following example removes the host name.
ContentEngine(config)# no hostname(config)#http
To configure HTTP-related parameters, use the http global configuration command. To disable HTTP related-parameters, use the no form of this command.
http age-multiplier text num binary num
http anonymizer enable
http append {proxy-auth-header {hostname | ip-address} | via-header | www-auth-header {hostname | ip-address} | x-forwarded-for-header}
http authenticate-strip-ntlm
http authentication {cache {max-entries entries | timeout minutes} | header {401 | 407}}
http cache-authenticated {all | basic | ntlm}
http cache-cookies
http cache-on-abort {enable | max-threshold maxthresh | min-threshold minthresh | percent percenthresh}
http client-no-cache-request {ignore | revalidate}
http cluster {heal-port number | http-port number | max-delay seconds | misses number}
http destination-port {allow {all | range} | deny {all | range}}
http fast-response enable
http include-ecdn-stats
http l4-switch enable
http max-ttl {days text textdays binary bindays | hours text texthours binary binhours | minutes text textminutes binary binminutes | seconds text textseconds binary binseconds}
http min-ttl minutes
http object {max-size maxsize | url-validation enable}
http persistent-connections [all | client-only | server-only | timeout seconds]
http proxy {incoming ports | outgoing {connection-timeout microsecs | host {hostname | ip-address} port [primary] monitor seconds | origin-server | preserve-407}}
http reval-each-request {all | none | text}
http serve-ims text percentage binary percentage
http smart-range {enable | max-start offset max-interval interval}
http strict-request-content-length-checking enable
no http {age-multiplier text num binary num | anonymizer enable | append {proxy-auth-header {hostname | ip-address} | via-header | www-auth-header {hostname | ip-address} | x-forwarded-for-header} | authenticate-strip-ntlm | authentication {cache {max-entries entries | timeout minutes} | header {401 | 407}} | cache-authenticated {all | basic | ntlm} | cache-cookies | cache-on-abort {enable | max-threshold maxthresh | min-threshold minthresh | percent percenthresh} | client-no-cache-request {ignore | revalidate} | cluster {heal-port number | http-port number | max-delay seconds | misses number} | http destination-port {allow {all | range} | deny {all | range}} | fast-response enable | include-ecdn- stats | l4-switch enable | max-ttl {days text textdays binary bindays | hours text texthours binary binhours | minutes text textminutes binary binminutes | seconds text textseconds binary binseconds} | min-ttl minutes | object {max-size maxsize | url- validation enable} | persistent-connections [all | client-only | server-only | timeout seconds] | proxy {incoming ports | outgoing {connection-timeout microsecs | host {hostname | ip-address} port [primary] monitor seconds | origin-server | preserve-407}} | reval-each- request {all | none | text} | serve-ims text percentage binary percentage | smart-range {enable | max-start offset max-interval interval} | strict-request-content- length-checking enable}
Syntax Description
Defaults
age-multiplier: 30 percent for text objects and 60 percent for binary objects
timeout minutes: 480
header: HTTP 401
maxthresh: 256 KB
minthresh: 32 KB
ports: no incoming proxy
percenthresh: 80 percent
heal-port number: 14333
http-port number: 80
textdays: 3 days
bindays: 7 days
texthours: 72 hours
binhours: 168 hours
textminutes: 4320 minutes
binminutes: 10080 minutes
textseconds: 259200 seconds
binseconds: 604800 seconds
misses number: 0 misses
include-ecdn-stats: E-CDN user requests are not logged
object max-size: no maximum size
outgoing connection-timeout: 300 milliseconds
http strict-request-content-length-checking: disabled
The Content Engine strips the hop-to-hop 407 response sent by the Internet proxy by default.
http cache-on-abort: disabled
http destination-port: allows ports 80-87 and 1025-65535; denies ports 1-79 and 88-1024.
max-start offset: 16384
max-interval interval: 16384
The default is no incoming proxy.
Command Modes
Global configuration
Usage Guidelines
Use these commands to configure specific parameters for caching HTTP objects.
The http anonymizer command zeros out client IP addresses in the log files.
Note
If a cached object's HTTP header does not specify an expiration time, the age-multiplier and max-ttl options provide a means for the Content Engine to age cached objects. The Content Engine's algorithm to calculate an object's cache expiration date is as follows:
Expiration date = (Today's date - Object's last modified date) * Freshness factor
The freshness factor is computed from the text and binary percentage parameters of the age-multiplier command. Valid age-multiplier values are 0 to 100 percent of the object's age. Default values are 30 percent for text and 60 percent for binary objects. After the expiration date, the object is considered stale and subsequent requests result in a fresh retrieval by the Content Engine.
When the Content Engine authenticates a user through a 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 max-entries option sets the maximum number of authentication cache entries retained.
The timeout option specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires a server lookup for reauthentication.
The max-ttl option sets the upper limit on estimated expiration dates. An explicit expiration date in the HTTP header (set by the web server) takes precedence over the max-ttl value.
HTTP Request Considerations
The ACNS 4.2 software Cache application supports Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server HTTP request authentication. The http authentication command 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.
When the Content Engine authenticates a user through an NTLM, RADIUS, or 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 server lookups.
The http authentication cache timeout command specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires reauthentication.
LDAP authentication can be used with Websense URL filtering, but not with RADIUS authentication. Both LDAP and RADIUS rely on different servers, which may require different user IDs and passwords, making LDAP and RADIUS authentication schemes mutually exclusive. Should both RADIUS and LDAP be configured on the Content Engine at the same time, LDAP authentication is executed, not RADIUS authentication.
Excluding Domains from HTTP Authentication Servers
To exclude domains from HTTP authentication servers, use the rule no-auth domain command. LDAP, NTLM, or RADIUS authentication takes place only if the site requested does not match the specified pattern.
Proxy Mode Server Authentication
The events listed below occur when the Content Engine is configured for HTTP request authentication and one of the following two scenarios is true:
•
•
1.
2.
3.
4.
5.
6.
7.
8.
Transparent Mode Authentication
The events listed below occur when the Content Engine is configured for authentication and both of the following are true:
•
•
1.
2.
3.
4.
5.
6.
7.
8.
In transparent mode, the Content Engine uses the client IP address as a key for the authentication database.
If you are using user authentication in transparent mode, we recommend that the AuthTimeout interval configured with the http authentication cache timeout command be short. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (PC, workstation, and the like). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. When the Content Engine operates in proxy mode, it can authenticate the user with the user ID and password.
Server Redundancy
Two authentication servers can be specified with the host option for NTLM, RADIUS, and LDAP servers, or server hostname option for TACACS+ servers. These additional servers provide authentication redundancy and improved throughput, especially when Content Engine load-balancing schemes distribute the requests evenly between the servers. If the Content Engine cannot connect to any of the authentication servers, no authentication takes place and users who have not been previously authenticated are denied access.
Security Options
The Content Engine uses simple (nonencrypted) authentication to communicate with the LDAP server. Future expansion may allow for more security options based on Secure Socket Layer (SSL), SASL, or certificate-based authentication.
To prevent unwanted access to any destination HTTP port when a request is going through the Content Engine, enter the following command:
ContentEngine(config)# http destination-port deny 1025-65535This command denies access to any port except for ports 80-87.
To allow HTTP access to a port number below 1025, enter the following command:
ContentEngine(config)# http destination-port allow 88Hierarchical Caching in Proxy Mode
In some cases, users are located at branch offices. A Content Engine (CE1) can reside with them in the branch office. Another Content Engine (CE2) can reside upstream, with an NTLM, RADIUS, or LDAP server available to both Content Engines for user authentication.
Note
If branch office user 1 accesses the Internet, and content is cached at CE1, then this content cannot be served to any other branch office user unless that user is authenticated. CE1 must authenticate the local users.
Assuming that both CE1 and CE2 are connected to the server and authenticate the users, when branch office user 2 firsts requests Internet content, CE1 responds to the request with an authentication failure response (either HTTP 407 if in proxy mode, or HTTP 401 if in transparent mode). User 2 enters the user ID and password, and the original request is repeated with the credentials included. CE1 contacts the HTTP request authentication server to authenticate user 2.
Assuming authentication success, and a cache miss, the request along with the credentials is forwarded to CE2. CE2 also contacts the authentication server to authenticate user 2. Assuming success, CE2 either serves the request out of its cache or forwards the request to the origin server.
User 2 authentication information is now stored in the authentication cache in both CE1 and CE2. Neither CE1 nor CE2 needs to contact the authentication server for user 2's subsequent requests (unless user 2's entry expires and is removed from the authentication cache).
This scenario assumes that CE1 and CE2 use the same method for authenticating users. Specifically, both Content Engines must expect the user credentials (user ID and password) to be encoded in the same way.
Hierarchical Caching in Transparent Mode
When the Content Engine operates in transparent mode, the user IP address is used as a key to the authentication cache. When user 2 sends a request transparently to CE1, after authentication, CE1 inserts its own IP address as the source for the request. Therefore, CE2 cannot use the source IP address as a key for the authentication cache.
When CE1 inserts its own IP address as the source, it must also insert an X-Forwarded-For header in the request (http append x-forwarded-for-header command). CE2 must first look for an X-Forwarded-For header. If one exists, that IP address must be used to search the authentication cache. Assuming the user is authenticated at CE2, then CE2 must not change the X-Forwarded-For header, just in case there is a transparent CE3 upstream.
In this scenario, if CE1 does not create an X-Forwarded-For header (for example, if it is not a Cisco Content Engine and does not support this header), then authentication on CE2 will not work.
Hierarchical Caching, Content Engine in Transparent Mode with an Upstream Proxy
In a topology with two Content Engines, assume that CE1 is operating in transparent mode and CE2 is operating in proxy mode, with the browsers of all users pointing to CE2 as a proxy.
Because the browsers are set up to send requests to a proxy, an HTTP 407 message is sent from CE1 back to each user to prompt for credentials. By using the 407 message, the problem of authenticating based on source IP address is avoided. The username and password can be used instead.
This mode provides better security than using the HTTP 401 message. The Content Engine examines the style of the address to determine whether there is an upstream proxy. If there is, the Content Engine uses an HTTP 407 message to prompt the user for credentials even when operating in transparent mode.
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.
Transaction Logging
Once a user has been authenticated through LDAP, NTLM, or a RADIUS server, all transaction logs generated by the Content Engine for that user contain user information. If the Content Engine is acting in proxy mode, the user ID is included in the transaction logs. If the Content Engine is acting in transparent mode, the user IP address is included instead.
If the transaction-logs sanitize command is invoked, the user information is suppressed.
In this example, the host for the LDAP server daemon is configured:
Console(config)# ldap server host www.someDomain.com port 390To delete an LDAP server, use the no ldap server command.
Console(config)# no ldap server host 1.1.1.1In this example, the host for the RADIUS server is configured:
Console(config)# radius-server 172.16.90.121In this example, the length of time that entries are valid in the authentication cache is set:
Console(config)# http authentication cache timeout 1000The following example specifies that the Content Engine should use header 407 when asking the end user for authentication credentials (user ID and password).
Console(config)# http authentication header 407The cache-cookies option enables the Content Engine to cache binary content served with HTTP Set-cookie headers and no explicit expiration information.
The reval-each-request option enables the Content Engine to revalidate all objects requested from the cache, text objects only, or none at all.
Use the object max-size option to specify the maximum size in kilobytes of a cacheable object. The default is no maximum size for a cacheable object. The no form of the command resets the default value.
The http proxy options enable the Content Engine to operate in environments where WCCP is not enabled, or where client browsers have previously been configured to use a legacy proxy server. The Content Engine accepts proxy-style requests when the incoming proxy ports are configured with the http proxy incoming ports option. Up to eight incoming proxy ports can be specified on a single command line or on multiple command lines.
To configure the Content Engine to direct all HTTP miss traffic to a parent cache (without using ICP or WCCP), use the http proxy outgoing host port option, where host is the system name or IP address of the outgoing proxy server, and port is the port number designated by the outgoing (upstream) server to accept proxy requests.
The cache-on-abort option provides user-defined thresholds to determine whether or not the Content Engine will complete the download of an object when the client has aborted the request. When the download of an object aborts before it is completed, the object is not stored on the Content Engine or counted in the hit-rate statistics. Client abort processing occurs when a client of the Content Engine aborts the download of a cacheable object before the download is complete. Typically, a client aborts a download by clicking the Stop icon on the browser, or by closing the browser during a download.
If the cache-on-abort option is enabled and all cache-on-abort thresholds are disabled, then the Content Engine always aborts downloading an object to the cache. If the Content Engine determines that there is another client currently requesting the same object, downloading is not aborted. The Content Engine only applies those thresholds that have been enabled.
To specify the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster, use the http cluster http-port option.
Note
To return to the default port number, use the no http cluster http-port command.
The client-no-cache-request option allows a choice between ignoring the no-cache client request or revalidating the object with the origin server before serving the no-cache client request. These choices are mutually exclusive, and the last selection takes effect.
The fast-response enable command disables Nagle's algorithm for all HTTP connections. It should be used only if there are current applications running that require an immediate, timely response to frequent small bursts of information from clients. Disabling Nagle's algorithm can result in a performance degradation because it disables the buffering of data. This algorithm should only be disabled when a particular server application needs the client's information immediately after it is sent. The decision to use this command depends upon the requirements of the client-server applications that are currently running.
The include-ecdn-stats command logs and updates the statistics for E-CDN user requests, such as redirected GET requests, when set. The default is that E-CDN user requests are not logged. If this command is set, E-CDN user requests are logged as part of the transaction.
The l4-switch enable option permits the Content Engine to transparently receive Layer 4 redirected traffic from Layer 4-enabled switches such as the Cisco CSS 11000 series switches. Refer to the switch documentation for specific configuration information.
Configuring Healing Mode
When a Content Engine is added to an existing WCCP Version 2 cache group (cluster), it can receive requests for content that was formerly served by another cache in the cluster. This event is termed a "near-miss," because if the request had been sent to the former Content Engine, it would have been a cache hit. A near-miss lowers the overall cache hit rate of the Content Engine cluster.
Healing mode allows the newly added Content Engine to query and obtain cache objects from all other caches in the cluster on a cache miss event. If the object is not found in the cluster, the Content Engine processes the request through the outgoing proxy or origin server. The Content Engine in healing mode is called a healing client. The caches in the cluster that respond to healing client requests are called healing servers.
Note
The http cluster command modifies the healing mode parameters. The http cluster http-port command specifies the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster.
Note
The http cluster heal-port command specifies the port number over which the healing client sends healing queries and the healing server sends healing responses. The default port number is 14333. If a port other than the default is configured, make sure that all Content Engines in the cluster use the same port.
The http cluster misses command specifies the maximum number of misses that the healing Content Engine can receive from the cluster from the last healing mode hit response until the healing process is disabled. The default is 0 misses. The http cluster max-delay command specifies the maximum time in seconds that a healing Content Engine waits for a healing response from the cluster before considering the healing request a miss.
To enable the healing client, you should, at the least, configure the max-delay and misses options. The default port number for http-port is 80. If you use the default port, you do not have to configure http-port. The default port number for heal-port is 14333.
To disable the healing client, you should, at the least, configure either misses or max-delay to 0, or you can use the no form of the command as follows:
http cluster misses 0
no http cluster misses
http max-delay 0
no http cluster max-delay
Note
HTTP Proxy Failover
The http proxy outgoing option can configure up to eight backup proxy servers for the HTTP proxy failover feature. One proxy server functions as the primary proxy server and all requests are redirected to it. If the primary proxy server fails to respond to the HTTP CONNECTION request, the server is noted as failed and the requests are redirected to the next outgoing proxy server until one of the proxies services the request. The no http proxy outgoing connection-timeout option causes the timeout to be set to the default value of 300 milliseconds.
To explicitly designate the primary proxy, use the primary keyword. If several proxies are configured with the primary keyword, the last one configured overrides the others. Failover to a proxy server occurs in the order that the proxy servers were configured. If all the configured proxy servers fail, the Content Engine can optionally redirect requests to the origin server if the user enters the http proxy outgoing origin-server option. If the user has configured the origin-server option, the Content Engine directs HTTP requests to the original server specified in the HTTP header. If the option is not enabled, the client receives an error response. Response errors and read errors are returned to the client, because it is not possible to detect whether these errors are generated at the origin server or at the proxy.
The state of the proxy servers is maintained by active monitoring, which occurs in the background. The state of the proxy servers can be seen in the CLI and syslog NOTICE messages. This interval is configured with the http proxy outgoing monitor option. This outgoing monitor interval is the interval of time over which the proxy servers are polled. If one of the proxy servers is unavailable, the polling mechanism waits for the connect timeout (300 milliseconds) before polling the next server.
Requests with a destination specified in the proxy-protocols outgoing-proxy exclude command bypass the Content Engine proxy as well as the failover proxies.
By default, the Content Engine strips the hop-to-hop 407 (Proxy Authentication Required) error code sent by an Internet proxy. If the http proxy outgoing preserve-407 command is invoked, the Content Engine sends the 407 error code to the client, and the Internet proxy authenticates the client.
Note
When an HTTP request intended for another proxy server is intercepted by the Content Engine in transparent mode, the Content Engine forwards the request to the intended proxy server if the proxy-protocols transparent original-proxy command was entered.
The proxy failover feature currently supports only HTTP, not HTTPS or FTP.
The persistent-connections option enables persistent connections on the Content Engine. To configure the number of seconds that the Content Engine should wait for a connection response before it times out, use the timeout option.
The http object url-validation enable option has a dependency with the ip name-server CLI command. When the ip name-server option is not configured (for example, during transparent proxy), http object url-validation enable is dynamically turned off. When the ip name-server option is configured, http object url-validation enable is turned on automatically if and only if it was enabled.
Caution
Use the proxy-protocols outgoing-proxy exclude global configuration command to specify a domain for which the Content Engine should not use an upstream proxy. In the following example, the domain cisco.com is outgoing proxy-excluded.
ContentEngine(config)# proxy-protocols outgoing-proxy exclude cisco.comThe Content Engine will not use the upstream proxy for any domain that ends with the listed domain name. For example, if you specify cisco.com, the configured outgoing proxy server will be bypassed each time the Content Engine tries to retrieve a web page from videos.cisco.com, or personals.cisco.com.
For IP addresses, enter the full IP address or use the asterisk "*" as a wildcard for IP address fields as follows:
172.16.1.*
172.16.*.*
172.*.*.*
The syntax 172.16.*.* indicates that all requests to the domain host of 172.16.xxx.xxx will be excluded. Wildcard syntax does not support "0" or "?".
The following forms of wildcard specification are not supported:
172.*.10.2
172.31.1*.8
If the client receives only a portion of the object but not the entire object because a download was prematurely halted, the client can use a Range request header to download only those missing portions of the object. The Range header specifies the byte range of the object requested. The command http smart-range enable enables the proxy to cache an HTTP response even if the client issues a Range request and the object is not in the cache. Use the no version of this command, no http smart-range enable, to disable this caching.
The http smart-range max-start offset max-interval interval byte values control these Range request conditions when this feature is enabled. The offset value is the maximum offset value of the first range in the client's Range request. The interval value is the maximum interval between any consecutive ranges in the client's request. Only if a Range request satisfies both conditions and a cache miss occurs does the proxy issue a normal request to the origin server, cache the response (if cacheable), and send a Range response to the client. If the response is not cacheable, then a full response is sent to the client.
Examples
This http authentication example sets the length of time that entries are valid in the authentication cache.
Console(config)# http authentication cache timeout 1000The following http authentication example specifies that the Content Engine should use header 407 when asking the end user for authentication credentials (user ID and password).
Console(config)# http authentication header 407In this http proxy outgoing example, the host 10.1.1.1 on port 8088 is designated the primary proxy server, and host 10.1.1.2 is a backup proxy server.
ContentEngine(config)# http proxy outgoing host 10.1.1.1 8088 primaryContentEngine(config)# http proxy outgoing host 10.1.1.2 220In this example, the Content Engine is configured to redirect requests directly to the origin server if all of the proxy servers fail.
ContentEngine(config)# http proxy outgoing origin-serverIn this example, the Content Engine is configured to monitor the proxy servers every 120 seconds.
ContentEngine(config)# http proxy outgoing monitor 120To disable any of the preceding commands, use the no version of the command.
Proxy Failover show Commands
ContentEngine# show http proxyIncoming Proxy-Mode:Servicing Proxy mode HTTP connections on ports: 8080Outgoing Proxy-Mode:Primary proxy server: 172.16.63.150 port 1 FailedBackup proxy servers: 172.16.236.151 port 8005172.16.236.152 port 123172.16.236.153 port 65535 Failed172.16.236.154 port 10Monitor Interval for Outgoing Proxy Servers is 60 secondsUse of Origin Server upon Proxy Failures is disabled.Statistics
ContentEngine# show statistics http requestsStatistics - RequestsTotal % of Requests---------------------------------------------------Total Received Requests: 49103 -Forced Reloads: 109 0.2Client Errors: 23 0.0Server Errors: 348 0.7URL Blocked: 0 0.0Sent to Outgoing Proxy: 0 0.0Failures from Outgoing Proxy: 0 0.0Excluded from Outgoing Proxy: 0 0.0ICP Client Hits: 0 0.0ICP Server Hits: 0 0.0HTTP 0.9 Requests: 2 0.0HTTP 1.0 Requests: 49101 100.0HTTP 1.1 Requests: 0 0.0HTTP Unknown Requests: 0 0.0Non HTTP Requests: 0 0.0Non HTTP Responses: 46 0.1Chunked HTTP Responses: 0 0.0Http Miss Due To DNS: 0 0.0Http Deletes Due To DNS: 0 0.0Objects cached for min ttl: 2674 5.ContentEngine# show statistics http proxy outgoingHTTP Outgoing Proxy StatisticsIP PORT ATTEMPTS FAILURES---------------------------------------------------172.16.23.150 8000 0 0172.16.23.151 8080 0 0172.16.23.152 9000 0 0172.16.23.153 9001 0 0172.16.23.154 9005 0 0Requests when all proxies were failed: 0In this example, with the default configuration (all cache-on-abort thresholds disabled), client abort processing is configured to always abort downloading an object to the cache:
ContentEngine(config)# http cache-on-abort enableIn this example, the Content Engine is configured to always continue downloading an object to the cache (this is the default configuration):
ContentEngine(config)# no http cache-on-abortIn this example, the Content Engine is configured to use the default minimum threshold when the cache-on-abort option has been enabled, and the threshold is set to 16 kilobytes:
ContentEngine(config)# http cache-on-abort min 16In this example, the Content Engine is configured to not consider the minimum threshold:
ContentEngine(config)# no http cache-on-abort minThe cache-on-abort max-threshold and percent thresholds are configured like the minimum threshold shown in the examples.
This example enables the healing mode feature by setting the HTTP port 8080 for forwarding HTTP requests to a specific port (3144) on a healing server, setting the maximum delay to wait for a response from the cluster in seconds before considering the healing request a miss, and setting the maximum number of misses that the healing Content Engine can receive from the cluster before healing mode is disabled at the healing client.
Console(config)# http cluster http-port 8080Console(config)# http cluster heal-port 3144Console(config)# http cluster max-delay 5Console(config)# http cluster misses 5In this example, the show statistics http cluster command displays the statistics of the healing client and the healing server. The clear statistics http cluster command resets the healing mode statistics:
Console(config)# show statistics http clusterYimin-507#show stat http clusterHealing mode max attempts = 0Healing mode max latency = 10Healing mode current cumulative misses = 0Healing mode client statistics------------------------------Client Requests Sent = 0Client Responses Received = 0Client Responses Hit = 0Client Responses Miss = 0Client Responses Error = 0Client Responses Timeout = 0Healing mode server statistics------------------------------Server Requests Received = 0Server Responses Sent = 0Server Responses Hit = 0Server Responses Miss = 0Server Responses Error = 0Yimin-507#Console(config)# clear statistics http clusterThe show http cluster command displays max-delay, misses, http-port, and heal-port values. In the first example, the values are set to 0 and the healing client is disabled.
Console# show http clusterHealing client is disabledTimeout for responses = 10 secondsMax number of misses allowed before stop healing mode = 0Port number for healing request/response = 14333Http-port to forward http request to healing server = 80In this example the healing client is enabled.
Console# show http clusterHealing client is enabledTimeout for responses = 10 secondsMax number of misses allowed before stop healing mode = 999Port number for healing request/response = 14333Http-port to forward http request to healing server = 80Related Commands
proxy-protocols
rule no-proxy
rule use-proxy
rule use-proxy-failover
show http
show http proxy
show statistics http requests
show statistics http proxy outgoing
https
To configure the Content Engine for HTTPS proxy services, use the https global configuration command.
https destination-port allow {ports | all}
https destination-port deny {ports | all}
https proxy incoming ports
https proxy outgoing host {hostname | ip-address} port
no https {destination-port allow {ports | all} | deny {ports | all} | proxy {incoming ports | outgoing host {hostname | ip-address} port}}
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Usage Guidelines
Cisco ACNS 4.2 software supports HTTPS in the following two scenarios:
•
•
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 an SSL tunnel through the Content Engine.
Table 2-2 shows CLI commands associated with HTTPS proxy features. The order in which the CLI commands are entered is not important.
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.
The Content Engine as an HTTPS proxy server supports up to eight ports. It can share the ports with transparent-mode services and with HTTP. In proxy mode, the Content Engine accepts and services the HTTPS requests on the ports specified with the https proxy incoming command. All HTTPS requests on other proxy-mode ports are rejected in accordance with the error-handling settings on the Content Engine. In transparent mode, all HTTPS proxy-style requests intended for another HTTPS proxy server are accepted. The Content Engine acts on these transparently received requests in accordance with the proxy-protocols transparent command.
When the Content Engine is configured to use an HTTPS outgoing proxy with the https proxy outgoing host command, all incoming HTTPS requests are directed to this outgoing proxy. The proxy-protocols outgoing-proxy exclude command specifies a global proxy exclude domain effective for all proxy server protocols, including HTTPS. The Content Engine applies the following logic when an outgoing proxy server is configured:
•
•
•
When a Content Engine intercepts a proxy request intended for another proxy server and there is no outgoing proxy configured for HTTPS, and the proxy-protocols transparent default-server command is invoked, the Content Engine addresses the request to the destination server directly and not to the client's intended proxy server. However, if the proxy-protocols transparent reset command is configured on the Content Engine and a cache miss occurs, all transparently intercepted requests sent by clients are returned to the client and requested objects are not delivered.
Content Engine Security
To prevent unwanted access to any destination HTTPS port when a request is going through the Content Engine, use the following command sequence:
no https destination-port allow 443 563
https destination-port deny all
This command sequence denies access to any port above and below 1024. Ports 443 and 563 (the standard HTTPS ports) must be explicitly denied access using the no https destination-port allow 443 563 command.
Note
For example, when these commands are configured on the Content Engine and the request to access port xxx at banking.wellsfargo.com is redirected to this Content Engine, the connection to port xxx is denied. This configuration is valid either in the transparent deployment scenario, in which requests are redirected to the Content Engine, or in HTTPS proxy server mode, when the user makes the requests directly to the Content Engine.
Statistics Reporting
Only connection statistics are reported. Because requests and responses are sent through the secure tunnel, the Content Engine is not able to identify the number of requests sent, or the number of bytes per request. Thus, the request and transaction per second (TPS) statistics are not available for HTTPS.
Transaction Logging
The Content Engine logs HTTPS transactions in the transaction log in accordance with Squid syntax. One log entry is made for each HTTPS connection, though many transactions are performed per connection. The Content Engine is not aware of objects conveyed through the SSL tunnel, only the HTTPS server name.
Examples
In this example, the Content Engine is configured as an HTTPS proxy server, and accepts HTTPS requests on port 8081. Only a single port is supported in the HTTPS protocol.
ContentEngine(config)# https proxy incoming 8081In this example, the Content Engine is configured to forward HTTPS requests to an outgoing proxy server (10.1.1.1) on port 8880.
ContentEngine(config)# https proxy outgoing host 10.1.1.1 8880In this example, a domain name is excluded from being forwarded to an outgoing proxy server.
ContentEngine(config)# proxy-protocols outgoing-proxy exclude cruzio.comContentEngine(config)# proxy-protocols transparent default-serverRelated Commands
proxy-protocols
http proxy
show proxy-protocols
show http proxy
icp
To configure the Internet Cache Protocol (ICP) client and server, use the icp global configuration command. To disable the ICP client and server, use the no form of this command.
icp client add-remote-server {hostname | ip-address} {parent | sibling} icp-port icpport http-port httpport [restrict domainnames]
icp client enable
icp client exclude domainnames
icp client max-fail retries
icp client max-wait timeout
icp client modify-remote-server {hostname | ip-address} {http-port port | icp-port port | parent | restrict domainnames | sibling}
icp server enable
icp server http-port port
icp server port icpport
icp server remote-client {hostname | ip-address} {fetch | no-fetch}
no icp {client {{add-remote-server {hostname | ip-address} {parent | sibling} icp-port icpport http-port httpport [restrict domainnames]} | enable | exclude domainnames | max-fail retries | max-wait timeout | modify-remote-server {hostname | ip-address} {http-port port | icp-port port | parent | restrict domainnames | sibling}} | server {enable | http-port port | port icpport | remote-client {hostname | ip-address} {fetch | no-fetch}}}
Syntax Description
