Table Of Contents
show statistics access-lists 300
show statistics authentication
show statistics content-routing
show statistics http-authcache
show statistics pac-file-server
show statistics transaction-logs
Cisco ACNS Software Commands
This chapter contains an alphabetical listing of all the commands in Cisco ACNS 5.1 software. The ACNS software CLI is organized into the following command modes:
•
EXEC mode—For setting, viewing, and testing system operations. It is divided into two access levels, user and privileged. To use the privileged access level, enter the enable command at the user access level prompt and then enter the privileged EXEC password when you see the password prompt.
•
•
•
See "Command-Line Interface Command Summary," for a complete discussion of using CLI command modes.
Table 2-1 summarizes the ACNS commands and indicates the command mode for each command. The commands used to access configuration modes are marked with an asterisk (*) in Table 2-1. EXEC both indicates that the command is available from either user EXEC or privileged EXEC mode. The same command may have different effects when entered in a different command mode, and for this reason they are listed and documented separately. In Table 2-1, when the first occurrence is entered in EXEC mode, the second occurrence is entered in global configuration mode. When the first occurrence is entered in global configuration mode, the second occurrence is entered in interface configuration mode.
The ACNS software device mode determines whether the ACNS device is functioning as a Content Engine, Content Distribution Manager, Content Router, or IP/TV Program Manager. The commands available from a specific CLI mode are determined by the ACNS device mode in effect. Table 2-1 also indicates the device mode for each command. All indicates that the command is available for every device mode.
When viewing this guide online, click the name of the command in the left column of the table to jump to the command page, which provides the command syntax, examples, and usage guidelines.
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.x software, you can configure group authorization using an access control list (ACL) only after a user has been authenticated against an NTLM or LDAP HTTP-request authentication 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 login authentication method, such as local, TACACS+, or RADIUS, must be enabled.
Note
In ACNS 5.x 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 300ContentEngine(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. You can also use this command to verify and correct the Last-Modified-Time attribute in content acquired using ACNS software before Release 5.1.
acquirer {check-time-for-old-content [channel-id channel-num | channel-name channel-name] [correct [channel-id channel-num | channel-name channel-name]] | start-channel {channel-id channel-num | channel-name channel-name} | stop-channel {channel-id channel-num | channel-name channel-name} | test-url url}
Syntax Description
Defaults
If you do not specify the channel, this command applies to all channels assigned to the root Content Engine.
Command Modes
EXEC
Usage Guidelines
The acquirer is a software agent that gathers channel content before it is distributed to the receiver Content Engines in an ACNS network. The acquirer maintains a task list, which it updates after receiving a notification of changes in its channel configuration.
In ACNS software Release 5.0.1 and earlier, the acquirer stored the Last-Modified-Time attribute in local time format. As a result, content acquired using Release 5.0.1 or earlier software has a Last-Modified-Time attribute that is incorrect if used with later versions of the ACNS software, which use GMT format. Content downloaded after you upgrade to Release 5.0.3 and later releases has a Last-Modified-Time attribute in the correct GMT format.
When using Release 5.0.3 and later releases, you must correct the Last-Modified-Time attributes for content acquired with earlier releases by entering the following command from the privileged EXEC prompt:
acquirer check-time-for-old-content correct [channel-id channel-num channel-name channel-name]
This command changes the Last-Modified-Time attributes for content in all channels assigned to the root Content Engine unless you specify the channel ID or name.
Content Engines running ACNS software, Release 5.1 identify changes in the Last-Modified-Time attribute and download content only when changes have occurred.
Use the acquirer start-channel command to immediately start acquisition tasks for the selected channel. Use the acquirer stop-channel command to immediately stop all acquisition tasks for the selected channel.
Use the acquirer test-url url EXEC command to test whether a URL is accessible or not. The actual content is dumped into the path /dev/null. For testing MMS over HTTP, use mms-http:// in the URL.
Examples
In this example, the acquirer starts acquiring content on channel 86.
ContentEngine# acquirer start-channel channel-id 86ContentEngine# acquirer start-channel channel-name corporateIn this example, the acquirer stops acquiring content on channel 86.
ContentEngine# acquirer stop-channel channel-id 86ContentEngine# acquirer stop-channel channel-name corporateIn this example, the acquirer test-url command is used to test a URL.
ContentEngine# acquirer test-url http://172.16.150.26--05:16:41-- http://10.107.150.26=> `/dev/null'Connecting to 10.107.150.26:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1,722 [text/html]100%[====================================>] 1,722 1.64M/s ETA 00:0002:45:40 (1.64 MB/s) - `/dev/null' saved [1722/1722]In the following example, the protocol used to test a URL is MMS over HTTP:
ContentEngine# acquirer test-url mms-http://192.168.150.76/DCARoot/ColorBars1_100k.wmvAcquiring stream: http://192.168.150.76/DCARoot/ColorBars1_100k.wmvThis can take as long as the duration of the stream. Please wait......Stream acquired successfully.Related Commands
show acquirer
show statistics acquirer
acquirer
To provide authentication when the acquirer obtains content through a proxy server, use the acquirer global configuration command.
acquirer proxy authentication {outgoing ip-address port-num | transparent} username [[password password] [ntlm domain [basic-auth-disable]]
Syntax Description
Defaults
No default behaviors or values
Command Modes
Global configuration
Usage Guidelines
Use the acquirer proxy authentication outgoing global configuration command to configure authentication when you enable content acquisition through a proxy server. You must first configure the proxy host and the port using the http proxy outgoing host global configuration command. The maximum number of outgoing proxies allowed is eight. When you remove an outgoing proxy using the no http outgoing proxy command, the authentication information associated with that proxy is automatically removed.
Use the acquirer proxy authentication transparent command for transparent caches in the ACNS network that require authentication.
The acquirer supports proxy with basic or NTLM authentication.Content acquisition through a proxy server is supported only for HTTP and not for HTTPS or FTP. Also, authentication is only supported for a single proxy server in a chain, so if multiple proxy servers in a chain require authentication, the request will fail.
Examples
The following example shows the authentication configuration for a nontransparent proxy server with NTLM authentication:
ContentEngine# acquirer proxy authentication outgoing 192.168.1.1 8080 myname password password ntlm mydomain basic-auth-disableThe following example shows the authentication configuration for a transparent proxy server with basic authentication:
ContentEngine# acquirer proxy authentication transparent 192.168.1.1 8080 mynameRelated Commands
show acquirer
http proxy outgoing
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.
ContentEngine# acquisition-distribution database-cleanup startThe following example starts the acquisition and distribution process.
ContentEngine# acquisition-distribution startThe following example stops the acquisition and distribution process.
ContentEngine# acquisition-distribution stopRelated Commands
show acquirer
show distribution
asset
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
ContentEngine(config)# asset tag entitymibauthentication
To specify authentication and authorization methods, 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] | fail-over server-unreachable}
no authentication {configuration {local | radius | tacacs} enable [primary | secondary | tertiary] | login {local | radius | tacacs} enable [primary | secondary | tertiary] | fail-over server-unreachable}
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 can be maintained in three different databases in ACNS 5.x 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.
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.1 software supports TACACS+ only and not TACACS or Extended TACACS.
To configure TACACS+, use the authentication and tacacs commands. To enable TACACS+, use the tacacs enable command.
For more information on TACACS+ authentication, see the "tacacs" section.
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 disabledtacacs enabled (primary)Configuration Authentication: Console/Telnet Session----------------------------- -----------------------local enabled (secondary)radius disabledtacacs enabled (primary)Configuration Authentication: Console/Telnet Session----------------------------- -----------------------local enabled (secondary)radius enabled (tertiary)tacacs enabled (primary)Enforcing Authentication with the Primary Method
The fail-over server-unreachable option enforces authentication using the primary authentication method unless that is not available, in which case the local database is used. This prevents users from accessing content with credentials from the local database unless the primary authentication method is unavailable.
HTTP Request Authentication
The ACNS 5.1 software caching services support 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+ Request Authentication
The TACACS+ database also validates users during an HTTP request authentication. TACACS+ provides both authentication and authorization options. To configure TACACS+, use the authentication and tacacs commands. To enable TACACS+, use the tacacs enable command.
For more information on TACACS+ authentication, see the "tacacs" section.
NTLM HTTP Request 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.
Note
RADIUS HTTP Request Authentication
RADIUS authentication clients reside on the Content Engine running ACNS 5.x 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.x 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 action no-auth pattern-list number command. TACACS+, NTLM, RADIUS, or LDAP authentication takes place only if the site requested does not match the specified domain from the pattern list chosen. For more information on excluding domains using rule commands see the "rule" section.
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:
ContentEngine(config)# ldap server host www.someDomain.com port 390To delete an LDAP server, use the no ldap server command.
ContentEngine(config)# no ldap server host 1.1.1.1In this example, the host for the RADIUS server is configured:
ContentEngine(config)# radius-server 172.16.90.121In this example, the length of time that entries are valid in the authentication cache is set:
ContentEngine(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).
ContentEngine(config)# http authentication header 407End-to-End Authentication
The ACNS 5.x software caching services support 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
Note
Basic End-to-End Authentication
The ACNS software caching services 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.x software caching services 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.
ContentEngine(config)# no http authenticate-strip-ntlmContentEngine(config)# http cache-authenticated ntlmContentEngine# 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.
ContentEngine(config)# authentication login tacacs enable primaryContentEngine(config)# authentication login local enable secondaryContentEngine(config)# authentication configuration local enable secondaryContentEngine(config)# authentication configuration tacacs enable primaryThis is an example of the show authentication command.
ContentEngine# 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.
ContentEngine# 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 Dynamic Host Configuration Protocol (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
Global 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 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 {cisco-streaming-engine kbits {default | max-bandwidth | start-time weekday time end-time weekday time} | http | real-proxy {incoming | outgoing} kbits | real-server kbits | wmt {incoming | outgoing} kbits}
Syntax Description
Defaults
No default behavior 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
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
10
Sets bandwidth to 10 megabits per second (Mbps).
100
Sets bandwidth to 100 Mbps.
1000
Sets bandwidth to 1000 Mbps. This option is not available on all ports and is the same as autosense.
Defaults
No default behaviors or values
Command Modes
Interface configuration
Examples
ContentEngine(config-if)# bandwidth 10ContentEngine(config-if)# no bandwidthRelated Commands
interface
bitrate
To configure the maximum pacing bit rate for large files sent using the HTTP protocol, and to separately configure WMT bit rate settings, use the bitrate global configuration command.
bitrate {http default bitrate | wmt {incoming bitrate | outgoing bitrate}}
no bitrate {http default bitrate | wmt {incoming bitrate | outgoing bitrate}}
Syntax Description
Defaults
http bitrate: 1500 kbps
wmt incoming bitrate: 0 (no limit)
wmt outgoing bitrate: 0 (no limit)
Command Modes
Global configuration
Usage Guidelines
ACNS 5.x software includes the Windows Media Technologies (WMT) proxy, which has the ability to cache on-demand media files when the user requests these files for the first time. All subsequent requests for the same file are served by the WMT proxy using the Microsoft Media Server (MMS) protocol. The WMT proxy can also live-split a broadcast, which causes only a single unicast stream to be requested from the origin server in response to multiple client requests for the stream.
The bit rate between the proxy and the origin server is called the incoming bit rate. Use the bitrate command to limit the maximum bit rate per session for large files delivered using either the HTTP or the MMS protocol.
Examples
The following example shows how to configure an incoming bit rate for a file sent over HTTP.
ContentEngine(config)# bitrate http default 100The following example shows how to configure an incoming bit rate for a file sent using MMS. Use the show wmt command to verify that the incoming bit rate has been modified.
ContentEngine(config)# bitrate wmt incoming 300000ContentEngine(config)# exitContentEngine# show wmtWMT version: ce507-001.000WMT enabledWMT disallowed client protocols: noneWMT end user license agreement acceptedWMT license key not installedWMT evaluation enabled. Estimated 48 days 4 hours left for evaluation.WMT max outgoing bandwidth limit enforced during evaluation: 56000 Kbits/secWMT outgoing bandwidth configured is 56000 Kbits/secWMT incoming bandwidth configured is 56000 Kbits/secWMT incoming port: 1755WMT max sessions configured: 155WMT max sessions platform limit: 155WMT max sessions enforced: 155 sessionsWMT max outgoing bit rate allowed per stream has no limitWMT max incoming bit rate allowed per stream: 300000 Kbits/secWMT cache enabledWMT cache max-obj-size: 1024WMT cache unique-stream-key enabledWMT debug level: 0WMT L4 switch not enabledWMT debug client ip not setWMT debug server ip not setWMT/REAL cache space partition: wmt 70%, real 30%WMT Stripping ? from Live URL is not enabledWMT Live-split using streaming engine is enabledWMT Proxy cache using streaming engine is enabledContentEngine#Related Commands
show http all
show wmt
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 | gateway ipaddress | load {enable | in-interval seconds | out-interval seconds | time-interval minutes} | static {clientip | any-client} {serverip | any-server} | timer minutes}
no bypass {auth-traffic enable | gateway ipaddress | load {enable | in-interval seconds | out-interval seconds | time-interval minutes} | static {clientip | any-client} {serverip | any-server} | 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 refers to a method that the Content Engine can use to handle various error responses (including authentication failure) from an origin server. When the Content Engine receives an error response from an origin server, it adds an entry for the server to its bypass list. When it receives subsequent requests for content residing on the bypassed server, it redirects packets to the bypass gateway. If no bypass gateway is configured, then the packets are returned to the redirecting Layer 4 switch.
If both WCCP Version 2 and a Layer 4 switch are configured, then requests redirected to the Content Engine by WCCP are bypassed to the redirecting WCCP Version 2-enabled router. Requests redirected to the Content Engine by the Layer 4 switch are redirected to the bypass gateway. Thus, the Content Engine can differentiate between requests arriving as a result of WCCP and as a result of the Layer 4 switch.
Bypass features can be used with a WCCP Version 2-enabled router or with a Layer 4 switch, such as the Cisco Content Switching Module or Cisco Content Services switch. The Content Engine cannot set up a bypass for proxy-style requests.
Using a Bypass Gateway
To enable bypass with a Layer 4 switch, use the http l4 switch enable command. To identify the router to which the Content Engine will direct responses when errors are received from the origin server, use the bypass gateway command. Replace ipaddress with the IP address of a router that is a Layer 2 neighbor of the Content Engine.
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).
By default, 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, the Content Engine 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.
Note
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
http l4-switch
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
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 one 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
cdm
To configure the Content Distribution Manager IP address to be used for Content Engines or Content Routers, or to configure the role and GUI parameters on a Content Distribution Manager device, use the cdm global configuration command.
cdm {ip ip-address | role {primary | standby} | ui port port-num}
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Usage Guidelines
In ACNS 5.1 software, you can use the cdm ui port global configuration command to change the Content Distribution Manager GUI port from the standard number 8443.
ContentDistributionManager(config)# cdm ui port 35535
Note
Examples
The following example configures an IP address and a primary role for a Content Distribution Manager.
ContentDstributionManager(config)# cdm ip 10.1.1.1ContentDstributionManager(config)# cdm role primaryThe following example configures a new GUI port to access the Content Distribution Manager GUI.
ContentDstributionManager(config)# cdm ui port 8550cdnfs
To manage the ACNS network file system (cdnfs), use the cdnfs EXEC command.
cdnfs {browse | cleanup {info | start | stop} | delete-unused-ecdnfs-files | lookup url}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The ACNS network file systems (cdnfs) stores pre-positioned ACNS network content to be delivered by all supported protocols, including HTTP, WMT, MMS, and RTSP. You can configure the cdnfs size of each Content Engine using the disk configure command.
The cdnfs cleanup command, which was used to clean up unwanted entries in the cdnfs and synchronize the acquisition and distribution database with the content stored on the cdnfs, has been modified in ACNS software, Release 5.1. This command now cleans up the content of deleted channels from the acquisition and distribution database. In certain cases, the acquirer is not notified by the Centralized Management System (CMS) about deleted channels, and it therefore fails to clear all unified name space (UNS) content. In such cases, the cdnfs cleanup EXEC command can be used to clean up all UNS content associated with deleted channels.
Note
The cdnfs browse command is an interactive command and has the following subcommands used to view ACNS network files and directories:
ContentEngine# cdnfs browse/>ls/>helpdir, ls: list directory contentscd,chdir: change current working directoryinfo: display attributes of a filemore: page through a filecat: display a fileexit,quit: quit CDNFS browse shell/>Since the cdnfs is empty in this example, the ls command does not show any results. Normally, if the cdnfs contained information, it would list the websites as directories, and file attributes and content could be viewed using these subcommands.
The cdnfs cleanup command synchronizes the state of the acquisition and distribution database with the content stored on the cdnfs. You should use this command after replacing a failed disk drive.
Use the cdnfs delete-unused-ecdnfs-files command to delete leftover legacy data files from previously released ACNS software ecdnfs files.
Note
Use the cdnfs lookup command to look up and, if present, obtain information on a specified URL in the cdnfs.
Examples
The following example deletes existing E-CDN application legacy files.
ContentEngine(config)# delete-unused-ecdnfs-filesThe following example shows the result of a lookup on a live streaming file. Typically, the "File Size" field is larger than zero. The "Live Stream Route..." information appears only for live streaming entries.
ContentEngine(config)# cdnfs lookup mms://10.107.192.3/SoccerCDNFS File Attributes:Status 3 (Ready)File Size 0 BytesStart Time nullEnd Time nullAllowed Playback via HTTP WMTcdn_uns_id d2CkEFiNwwaVNx+qI9KLeQ..channelId 131no_redirect_to_origin 1wmt-live 1Live Stream Route for WMT Media stream is :-->Next Hop = 10.1.21.6-->Next Hop = 10.107.150.203-->Last Hop = 10.107.192.3The following example shows the output of the cdnfs cleanup info command:
ContentEngine# cdnfs cleanup infoGathering cleanup information. This may take some time....(Use Ctrl+C or 'cdnfs cleanup stop' to interrupt)..............................Summary of garbage resource entries found-------------------------------------------Number of entries : 605Size of entries (KB) : 60820911Related Commands
show cdnfs
show statistics cdnfs
cdp
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 with 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
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
Examples
ContentEngine(config-if)# cdp enableRelated Commands
show cdp
interface
show interface
show running-config
show startup-config
cfs
To configure the cache object file system (cfs) of the Content Engine, use the cfs EXEC command.
cfs {clear partition [force] | format partition | mount partition | reset partition | sync partition | 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
channel
To assign, create, delete, add, modify, or otherwise configure a channel, use the channel EXEC command.
channel assign site-name channel-name {channel-root root-ce-name | content-engine {all | ce-name} | device-group {all | dev-name}}
channel create site-name channel-name [description channel-desc] [multicast-enabled] [priority {high | low | normal}] [skip-encryption] [weak-certificate]
channel delete site-name {all | channel-name}
channel manifest-add site-name channel-name url disk-quota ttl [password password username username]
channel manifest-fetch site-name channel-name
channel manifest-modify site-name channel-name [disk-quota disk-quota] [manifest-url url] [password password] [time-to-live ttl] [username username]
channel modify site-name channel-name [description channel-desc] [multicast {disable | enable}] [new-channel-name channel-name] [priority {high | low | normal}] [skip-encryption {disable | enable}] [weak-certificate {disable | enable}]
channel un-assign site-name channel-name {content-engine {all | ce-name} | device-group {all | dev-name}}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Examples
ContentDistributionManager# channel assign southeast se1 channel-root salesContentDistributionManager# channel create southeast se1 description salesoffice multicast-enabled weak-certificatechannel-group
To add the current interface to an EtherChannel group, use the channel-group interface configuration command.
channel-group {1 | 2}
no channel-group {1 | 2}
Syntax Description
Defaults
No default behavior or values
Command Modes
Interface configuration
Usage Guidelines
EtherChannel provides incremental trunk speeds between Fast Ethernet and Gigabit Ethernet, or even at speeds greater than Gigabit Ethernet. EtherChannel combines multiple Fast Ethernet interfaces up to 400 Mbps or Gigabit Ethernet interfaces up to 2 Gbps. EtherChannel provides fault-tolerant, high-speed links between switches, routers, and servers.
EtherChannel for ACNS 5.x software supports grouping of up to four same-speed network interfaces into one virtual interface. This allows the addition or removal of a virtual interface that consists of two, three, four Fast Ethernet or two Gigabit Ethernet interfaces; interoperability with Cisco routers, switches, and other networking devices or hosts supporting EtherChannel; and automatic failure detection and recovery based on each interface's current link status.
Use the channel-group command to add and remove the port channel group ID number. The ID number is either 1 or 2. The channel-group and ip address commands add a physical Fast Ethernet port to a previously created Fast EtherChannel. The channel number is the same as the channel number specified when the port-channel interface command is used to create either a Fast Ethernet or a Gigabit Ethernet channel.
Note
Examples
The following example adds an interface to a channel group.
ContentEngine# configContentEngine(config)# interface fastEthernet 0/3ContentEngine(config-if)# no ip addressContentEngine(config-if)# channel-group 1ContentEngine(config-if)# exitThe following example removes the group ID number from a channel group.
ContentEngine(config)# interface fastEthernet 0/3ContentEngine(config-if)# no channel-group 1ContentEngine(config-if)# exitRelated Commands
port-channel
interface
show interface
show running-config
show startup-config
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] | media-real | wmt]
clear cdp {counters | table}
clear ip access-list counters {acl-num | acl-name}
clear logging
clear statistics {access-lists 300 | all | authentication | dns-cache | |distribution {all | metadata-receiver | metadata-sender | multicast-data-receiver | multicast-data-sender | unicast-data-receiver | unicast-data-sender} | dns-cache | ftp | history | http {all | cluster | ims | object | outgoing | proxy outgoing | requests | response | savings} | http-authcache | https | icap | icmp | icp {all | client | server} | ip | ldap | ntlm | pac-file-server | pre-load | radius | rtsp {proxy media-real | server cisco-streaming-engine} | rule {action action-type | all} | running | tacacs | tcp | transaction-logs | tvout | udp | url-filter {http {local-list | N2H2 | websense} | wmt local-list} | wmt}
clear transaction-log
clear users {administrative | request-authenticated}
clear wmt {incoming | outgoing | stream-id 1-999999}
Syntax Description
bypass
Clears bypass commands.
counters
Clears all bypass counters.
list
Clears all bypass lists.
cache
Clears HTTP objects 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 the cfs cache.
url
HTTP or FTP URL.
media-real
(Optional) Clears RealProxy cache content.
wmt
(Optional) Clears the WMT cache.
cdp
Resets CDP statistical data.
counters
Clears CDP counters.
table
Clears CDP tables.
ip access-list counters
Clears IP access list counters.
acl-name
Clear counters for the specified access list, identified using an alphanumeric identifier up to 30 characters, beginning with a letter.
acl-num
Clear counters for the specified access list, identified using a numeric identifier (standard access list: 1-99; extended access list: 100-199).
logging
Clears syslog messages saved in the 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.
content-routing
Clears all content routing statistics.
distribution
Clears distribution statistics.
all
Clears distribution statistics for every component.
metadata-receiver
Clears distribution statistics for the metadata receiver.
metadata-sender
Clears distribution statistics for the metadata sender.
multicast-data-receiver
Clears distribution statistics for the multicast data receiver.
multicast-data-sender
Clears distribution statistics for the multicast data sender.
unicast-data-receiver
Clears distribution statistics for the unicast data receiver.
unicast-data-sender
Clears distribution statistics for the unicast data sender.
dns-cache
Clears DNS cache statistics.
ftp
Clears FTP caching statistics.
history
Clears the statistics history.
http
Clears the cfs cache containing HTTP and FTP objects.
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 request statistics.
response
Clears HTTP response statistics.
savings
Clears HTTP savings statistics.
http-authcache
Clears authentication cache statistics.
https
Clears HTTPS statistics.
icap
Clears ICAP statistics.
icmp
Clears ICMP 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.
ntlm
Clears NTLM statistics.
pac-file-server
Clears PAC file server statistics.
pre-load
Clears preload statistics.
radius
Clears RADIUS statistics.
rtsp
Clears RTSP statistics.
proxy media-real
Clears RTSP-based RealMedia proxy statistics.
server cisco-streaming-engine
Clears RTSP-based Cisco Streaming Engine server statistics.
rule
Clears rules statistics.
action
Clears statistics of all the rules with the same action.
action-type
Specifies one of the following actions:
block
cache
dscp client cache-hit
dscp client 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 "Actions" section for explanations of actions and patterns.
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.
tvout
Clears TV out statistics.
udp
Clears UDP statistics.
url-filter
Clears URL filter statistics.
http
Clears URL filter for HTTP statistics.
local-list
Clears local-list URL filter statistics.
N2H2
Clears N2H2 URL filter statistics.
websense
Clears Websense URL filter statistics.
rtsp
Clears URL filter for Real-Time Streaming Protocol (RTSP) statistics.
local-list
Clears local list URL filter for RTSP statistics.
wmt
Clears URL filter Windows Media Technologies (WMT) statistics.
local-list
Clears local list URL filter for WMT statistics.
wmt
Clears all WMT statistics.
transaction-log
Archives working transaction log files.
users
Clears the connections (login) of authenticated users.
administrative
Clears the connections of administrative users authenticated through a remote login service.
request-authenticated
Clears users authenticated by request.
wmt
Clears WMT streams.
incoming
Clears all incoming WMT streams.
outgoing
Clears all outgoing WMT streams.
stream-id
Clears specified WMT stream.
1-999999
WMT stream ID to clear.
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 puts a "Syslog cleared" message in the syslog.txt file 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.
The clear users administrative command clears the connections for all administrative users who are authenticated through a remote login service, such as TACACS. This command does not affect an administrative user who is authenticated through the local database.
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.ContentEngine(config)# clear statistics http clusterRelated Commands
cache clear
cfs clear
show statistics
show interface
show wccp
clock
To set or clear clock functions or update the calendar, 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.
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 endmonth endhour
offset | last startweekday startmonth starthour endweekday endmonth 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 endmonth endhour offset | first startweekday startmonth starthour endweekday endmonth endhour
offset | last startweekday startmonth starthour endweekday endmonth 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-2) from Coordinated Universal Time (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
Day of the week (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-2) from UTC (0-59).
timezone
Configures standard time zone.
timezone
Name of time zone.
hoursoffset
Hours offset (see Table 2-2) from UTC (-23 to +23).
minutesoffset
Minutes offset (see Table 2-2) 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-2 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 with an offset of 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
cms
To configure the Centralized Management System (CMS) embedded database parameters, use the cms EXEC command.
cms {database {backup | create | delete | downgrade [script filename | maintenance {full | regular} | restore filename | validate} | deregister [force] | recover {identity word}}
Syntax Description
Defaults
No default behavior or values
Command Modes
EXEC
Usage Guidelines
The ACNS network is a collection of Content Router, Content Engine, and Content Distribution Manager nodes. One primary Content Distribution Manager retains the ACNS network settings and provides other ACNS network nodes with updates. Communication between nodes occurs over secure channels using Secure Shell Layer (SSL) protocol, where each node on the ACNS network uses a Rivest, Shamir, Adelman (RSA) certificate-key pair to communicate with other nodes.
Use the cms database create command to initialize the CMS database. Before a node can join an ACNS network, it must first be registered and then activated. The cms enable global configuration command automatically registers the node in the database management tables and enables the CMS. The node sends its attribute information to the Content Distribution Manager over the SSL protocol and then stores the new node information. The Content Distribution Manager accepts these node registration requests without admission control and replies with registration confirmation and other pertinent security information required for getting updates. Activate the node using the Content Distribution Manager GUI.
Once the node is activated, it automatically receives configuration updates and the necessary security RSA certificate-key pair from the Content Distribution Manager. This security key gives the node the ability to communicate with any other node in the ACNS network. The cms deregister command removes the node from the ACNS network by deleting registration information and database tables.
To back up the existing management database for the Content Distribution Manager, use the cms database backup command. For database backups, specify the following items:
•
•
The naming convention for backup files includes the time stamp.
Examples
ContentDistributionManager# cms database backupcreating backup file with label `backup'backup file local1/acns-db-9-22-2002-17-36.dump is ready. use `copy' commands to move the backup file to a remote host.ContentDistributionManager# cms database validateManagement tables are validIn this example the CMS deregistration process has problems deregistering the Content Engine, but it proceeds to deregister it from the CMS database when the force option is used.
ContentEngine# cms deregister forceDeregistration requires management service to be stopped.You will have to manually start it. Stopping management service on this node...This operation needs to restart http proxy and streaming proxies/servers (if running) for memory reconfiguration. Proceed? [no]yesmanagement services stoppedThu Jun 26 13:17:34 UTC 2003 [I] main: creating 24 messagesThu Jun 26 13:17:34 UTC 2003 [I] main: creating 12 dispatchersThu Jun 26 13:17:34 UTC 2003 [I] main: sending eDeRegistration message to CDM 10.107.192.168...ContentEngine#ContentEngine# cms recover identity defaultRegistering this node as Content Engine...Sending identity recovery request with key defaultThu Jun 26 12:54:42 UTC 2003 [I] main: creating 24 messagesThu Jun 26 12:54:42 UTC 2003 [I] main: creating 12 dispatchersThu Jun 26 12:54:42 UTC 2003 [I] main: Sending registration message to CDM 10.107.192.168Thu Jun 26 12:54:44 UTC 2003 [W] main: Unable to load device info file in TestServerThu Jun 26 12:54:44 UTC 2003 [I] main: Connecting storeSetup for CE.Thu Jun 26 12:54:44 UTC 2003 [I] main: Instantiating AStore 'com.cisco.unicorn.schema.PSqlStore'...Thu Jun 26 12:54:45 UTC 2003 [I] main: Successfully connected to databaseThu Jun 26 12:54:45 UTC 2003 [I] main: Registering object factories for persistent store...Thu Jun 26 12:54:51 UTC 2003 [I] main: Dropped Sequence IDSET.Thu Jun 26 12:54:51 UTC 2003 [I] main: Successfully removed old management tablesThu Jun 26 12:54:51 UTC 2003 [I] main: Registering object factories for persistent store...Thu Jun 26 12:54:51 UTC 2003 [I] main: Creating PSql Table BYPASS_INFO...Thu Jun 26 12:54:54 UTC 2003 [I] main: Created Table FILE_CDM.Thu Jun 26 12:54:55 UTC 2003 [I] main: Created SYS_MESS_TIME_IDX index.Thu Jun 26 12:54:55 UTC 2003 [I] main: Created SYS_MESS_NODE_IDX index.Thu Jun 26 12:54:55 UTC 2003 [I] main: No Consistency check for store.Thu Jun 26 12:54:55 UTC 2003 [I] main: Successfully created management tablesThu Jun 26 12:54:55 UTC 2003 [I] main: Registering object factories for persistent store...Thu Jun 26 12:54:55 UTC 2003 [I] main: AStore Loading store data...Thu Jun 26 12:54:56 UTC 2003 [I] main: ExtExpiresRecord Loaded 0 Expires records.Thu Jun 26 12:54:56 UTC 2003 [I] main: Skipping Construction RdToClusterMappings on non-CDM node.Thu Jun 26 12:54:56 UTC 2003 [I] main: AStore Done Loading. 327Thu Jun 26 12:54:56 UTC 2003 [I] main: Created SYS_MESS_TIME_IDX index.Thu Jun 26 12:54:56 UTC 2003 [I] main: Created SYS_MESS_NODE_IDX index.Thu Jun 26 12:54:56 UTC 2003 [I] main: No Consistency check for store.Thu Jun 26 12:54:56 UTC 2003 [I] main: Successfully initialized management tablesNode successfully registered with id 103Registration complete.ContentEngine#The following example shows the use of the cms recover identity command when the host name of the Content Engine does not match the host name configured in the Content Distribution Manager graphical user interface.
ContentEngine# cms recover identity defaultRegistering this node as Content Engine...Sending identity recovery request with key defaultThu Jun 26 13:16:09 UTC 2003 [I] main: creating 24 messagesThu Jun 26 13:16:09 UTC 2003 [I] main: creating 12 dispatchersThu Jun 26 13:16:09 UTC 2003 [I] main: Sending registration message to CDM 10.107.192.168There're no CE devices in CDNregister: Registration failed.ContentEngine#Related Commands
cms enable
show cms
cms
To schedule maintenance and enable the Centralized Management System (CMS) on a given node, use the cms global configuration command.
cms {database maintenance {full {enable | schedule weekday at time} | regular {enable | schedule weekday at time}} | enable | rpc timeout {connection 5-1800 | incoming-wait 10-600 | transfer 10-7200}}
no cms {database maintenance {full {enable | schedule weekday at time} | regular {enable | schedule weekday at time}} | enable | rpc timeout {connection 5-1800 | incoming-wait 10-600 | transfer 10-7200}}
Syntax Description
Defaults
database maintenance regular: enabled
database maintenance full: enabled
connection: 30 seconds for Content Distribution Manager; 180 seconds for the Content Engine and the Content Router
incoming wait: 30 seconds
transfer: 300 seconds
Command Modes
Global configuration
Usage Guidelines
Use the cms database maintenance command to schedule routine full maintenance cleaning ("vacuuming") or a regular maintenance reindexing of the embedded database. The full maintenance routine runs only when the disk is more than 90 percent full and only runs once a week. Cleaning the tables returns reusable space to the database system.
The cms enable command automatically registers the node in the database management tables and enables the CMS. The no cms enable command only stops the management services on the device and does not disable a primary sender. You can use the cms deregister command to remove a primary or backup sender Content Engine from the ACNS network and to disable communication between the two multicast senders.
Examples
The following example schedules a regular (reindexing) maintenance routine to start every Friday at 11:00 at night.
ContentEngine(config)# cms database maintenance regular schedule Fri at 23:00The following example shows how to enable the CMS process on a Content Engine.
ContentEngine(config)# cms enableThis operation needs to restart http proxy and streaming proxies/servers (if running) for memory reconfiguration. Proceed? [no]yesRegistering this node as Content Engine...Thu Jun 26 13:18:24 UTC 2003 [I] main: creating 24 messagesThu Jun 26 13:18:25 UTC 2003 [I] main: creating 12 dispatchersThu Jun 26 13:18:25 UTC 2003 [I] main: Sending registration message to CDM 10.107.192.168Thu Jun 26 13:18:27 UTC 2003 [I] main: Connecting storeSetup for CE.Thu Jun 26 13:18:27 UTC 2003 [I] main: Instantiating AStore 'com.cisco.unicorn.schema.PSqlStore'...Thu Jun 26 13:18:28 UTC 2003 [I] main: Successfully connected to databaseThu Jun 26 13:18:28 UTC 2003 [I] main: Registering object factories for persistent store...Thu Jun 26 13:18:35 UTC 2003 [I] main: Dropped Sequence IDSET.Thu Jun 26 13:18:35 UTC 2003 [I] main: Dropped Sequence GENSET.Thu Jun 26 13:18:35 UTC 2003 [I] main: Dropped Table USER_TO_DOMAIN....Thu Jun 26 13:18:39 UTC 2003 [I] main: Created Table FILE_CDM.Thu Jun 26 13:18:40 UTC 2003 [I] main: Created SYS_MESS_TIME_IDX index.Thu Jun 26 13:18:40 UTC 2003 [I] main: Created SYS_MESS_NODE_IDX index.Thu Jun 26 13:18:40 UTC 2003 [I] main: No Consistency check for store.Thu Jun 26 13:18:40 UTC 2003 [I] main: Successfully created management tablesThu Jun 26 13:18:40 UTC 2003 [I] main: Registering object factories for persistent store...Thu Jun 26 13:18:40 UTC 2003 [I] main: AStore Loading store data...Thu Jun 26 13:18:41 UTC 2003 [I] main: ExtExpiresRecord Loaded 0 Expires records.Thu Jun 26 13:18:41 UTC 2003 [I] main: Skipping Construction RdToClusterMappings on non-CDM node.Thu Jun 26 13:18:41 UTC 2003 [I] main: AStore Done Loading. 336Thu Jun 26 13:18:41 UTC 2003 [I] main: Created SYS_MESS_TIME_IDX index.Thu Jun 26 13:18:41 UTC 2003 [I] main: Created SYS_MESS_NODE_IDX index.Thu Jun 26 13:18:41 UTC 2003 [I] main: No Consistency check for store.Thu Jun 26 13:18:41 UTC 2003 [I] main: Successfully initialized management tablesNode successfully registered with id 28940Registration complete.Warning: The device will now be managed by the CDM. Any configuration changesmade via CLI on this device will be overwritten if they conflict with settings on the CDM.Please preserve running configuration using 'copy running-config startup-config'.Otherwise management service will not be started on reload and node will be shown'offline' in CDM UI.management services enabledContentEngine(config)#Related Commands
cms database
cms deregister
show cms
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 cdnfs disk url sysfs-filename
copy cdrom install filedir filename
copy compactflash install filename
copy disk {ftp {hostname | ip-address} remotefiledir remotefilename localfilename | startup-config filename}
copy ftp {disk {hostname | ip-address} remotefiledir remotefilename localfilename | install {hostname | ip-address} remotefiledir remotefilename}
copy http install {{hostname | ip-address} remotefiledir remotefilename | port port-num | proxy {hostname | ip-address} | username username password password}
copy running-config {disk filename | startup-config | tftp {hostname | ip-address} remotefilename}
copy startup-config {disk filename | running-config | tftp {hostname | ip-address} remotefilename}
copy system-status disk filename
copy tech-support {disk filename | tftp {hostname | ip-address} remotefilename}
copy tftp {disk {hostname | ip-address} remotefilename localfilename | running-config
{hostname | ip-address} remotefilename | startup-config {hostname | ip-address} remotefilename}no copy {cdnfs disk url sysfs-filename | cdrom install filedir filename | 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 | proxy {hostname | ip-address} port-num | username username password password} | 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
HTTP server port: 80
Command Modes
EXEC
Usage Guidelines
The copy cdnfs EXEC command copies data files out of the cdnfs to the sysfs for further processing, for example, to provide the copied files to the install imagefilename EXEC command for copying the cdnfs files to install the ACNS software.
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 NVRAM.
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 file from an HTTP server and install it on a local device. It transfers the image from an HTTP server to the Content Engine using HTTP as the transport protocol and installs the software on the device. Part of the image goes to disk and part goes to flash memory. You can also use this command to redirect your transfer to a different location or HTTP proxy server, by specifying the proxy hostname | ip-address option. A username and a password will have to be authenticated with a primary domain controller (PDC) before the transfer of the software release file to the Content Engine is allowed.
Use the copy running-config command to copy the running system configuration to a sysfs partition, flash memory, or 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 on 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 oldfilename newfilename
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 caching application functions, use the debug EXEC command. Use the no form of the command to disable debug.
debug option
no debug option
Syntax Description
