Table Of Contents
show statistics access-lists 300
show statistics authentication
show statistics content-routing
show statistics http-authcache
show statistics transaction-logs
Cisco ACNS Software Commands
This chapter contains an alphabetical listing of all commands of Cisco ACNS 5.0 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 5.0 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 command to prevent any user from the marketing group from accessing content through the Content Engine.
At least one authentication method, local, TACACS+, or RADIUS, must be enabled.
Note
It is recommended that the local method be configured.
In ACNS 5.0 software, the access control list contains the following feature enhancements and limitations:
•
•
•
•
Note
•
•
Examples
In this example, you can display the configuration of the access control list 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 access control list, 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 access control list, use the clear statistics access-lists 300 command.
ContentEngine# clear statistics access-lists 300Console(config)# access-lists 300 permit groupname acme1 position 2Related Commands
show access-lists 300
show statistics access-list 300
acquirer
To start or stop content acquisition on a specified acquirer channel, use the acquirer EXEC command.
acquirer {start-channel {channel-id channel_num | channel-name channel-name} | stop-channel {channel-id channel_num | channel-name channel-name}}
Syntax Description
Defaults
No default behaviors or values
Command Modes
EXEC
Usage Guidelines
In ACNS 5.0 software, the acquirer runs as a daemon and processes its acquisition tasks until it is notified of a change in its channel table. After the acquirer is notified of a change in its channel table, it updates its task list.
The acquirer start-channel command starts a content acquisition task for the specified channel ID or name. The acquirer checks the manifest file and, if an update is required, reprocesses it. The acquirer stop-channel command stops the current acquisition task for the specified channel ID or name, even if the Time To Live of the particular task has not expired.
Examples
In this example, the acquirer starts acquiring content on channel 86.
CDM# acquirer start-channel channel-id 86CDM# acquirer start-channel channel-name corporateIn this example, the acquirer stops acquiring content on channel 86.
CDM# acquirer stop-channel channel-id 86CDM# acquirer stop-channel channel-name corporateRelated Commands
show acquirer
show statistics acquirer
acquisition-distribution
To start or stop the content acquisition and distribution process, use the acquisition-distribution EXEC command.
acquisition-distribution {database-cleanup {start | stop} | start | stop}
Syntax Description
Defaults
No default behaviors or values
Command Modes
EXEC
Examples
The following example starts the acquisition and distribution database cleanup process .
CDM# acquisition-distribution startThe following example starts the acquisition and distribution process.
CDM# acquisition-distribution startThe following example stops the acquisition and distribution process.
CDM# acquisition-distribution stopRelated Commands
show acquirer
show distribution
asset tag
To set the tag name for the asset tag string, 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
Examples
Console(config)# asset tag entitymibauthentication
To configure user authentication options, use the authentication command in global configuration mode. Use the no form of this 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
The local authentication method is 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 5.0 software: the local database, TACACS+ database, and 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 5.0 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 5.0 software 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 the "tacacs" section.
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 the "ntlm" section.
RADIUS HTTP Request Authentication
RADIUS authentication clients reside on the Content Engine running ACNS 5.0 software. When enabled, these clients send authentication requests to a central RADIUS server, which contains user authentication and network service access information.
To configure RADIUS 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 the "radius-server" section.
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 this 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 on an LDAP server.
ACNS 5.0 software supports LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL). For more information on LDAP authentication, see the "ldap" section.
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.
When the access control list is configured and enabled, an NTLM or LDAP authenticated user has to belong to an access control list to allow access to requested content. However, even with the access control list enabled, the default policy is to allow access to the requested content, which means that if the user does not appear in any access control lists, access is allowed.
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 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 HTTP 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 in the case of TACACS+ servers, with the 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 authentication (clear text) to communicate with LDAP, RADIUS, and TACACS+ authentication servers. The Content Engine uses encryption to communicate with NTLM authentication servers.
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 5.0 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 5.0 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
auto-register
To enable discovery of a Fast Ethernet or Gigabit Ethernet Content Engine or Content Router and its automatic registration with the Content Distribution Manager through DHCP, use the auto-register global configuration command. To disable this function, use the no form of this command.
auto-register enable [FastEthernet slot/port | GigabitEthernet slot/port]
no auto-register enable [FastEthernet slot/port | GigabitEthernet slot/port]
Syntax Description
Defaults
Automatic registration using DHCP is enabled by default.
Command Modes
Interface configuration
Usage Guidelines
The auto-register enable command allows a Fast Ethernet or Gigabit Ethernet Content Engine or Content Router to discover the host name of the Content Distribution Manager through DHCP and to automatically register the device with the Content Distribution Manager. Discovery and registration occur at bootup.
To assign a static IP address using the interface GigabitEthernet slot/port command, the automatic registration of devices through DHCP must be disabled by using the no auto-register enable command, because automatic registration through DHCP is enabled by default.
Examples
ContentEngine(config)# auto-register enable GigabitEthernet 2/0ContentEngine(config)# auto-register enable FastEthernet 0/1ContentEngine(config)# no auto-register enableRelated Commands
show auto-registration
show running-config
show startup-config
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 autosenseRelated Commands
interface
show interface
show running-config
show startup-config
bandwidth
To configure an interface bandwidth, use the bandwidth interface configuration command. To restore default values, use the no form of this command.
bandwidth {10 | 100 | 1000}
no bandwidth {10 | 100 | 1000}
Syntax Description
Defaults
No default behaviors or values
Command Modes
Interface configuration
Usage Guidelines
Gigabit Ethernet interfaces run at 1000 Mbps only.
Examples
ContentEngine(config-if)# bandwidth 10ContentEngine(config-if)# no bandwidthRelated Commands
interface
bandwidth
To set an allowable bandwidth usage limit and its duration for Cisco Streaming Engine, RealProxy, RealServer, and WMT streaming media, use the bandwidth global configuration command.
bandwidth allow kbits {cisco-streaming-engine {start-time weekday hour end-time weekday hour} | real-proxy {start-time weekday hour end-time weekday hour} | real-server {start-time weekday hour end-time weekday hour} | wmt {start-time weekday hour end-time weekday hour}}
Syntax Description
Defaults
No default behaviors or values
Command Modes
Global configuration
Usage Guidelines
With the various types of traffic originating from a device, every type of traffic, such as streaming media, HTTP, and metadata, consumes network resources. Use the bandwidth command to limit the amount of network bandwidth used by the Cisco Streaming Engine, RealNetworks, and WMT streaming media.
Examples
The following example limits the RealProxy bandwidth to 1000 kbps from Monday at 8:00 a.m. to Friday at 6:00 p.m.
ContentEngine(config)# bandwidth allow 1000 real-proxy start-time monday 8:00 end-time friday 18:00Related Commands
bandwidth (interface configuration)
show bandwidth
interface
show interface
show running-config
show startup-config
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 this 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.
Static Bypass
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-
