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-server
