Table Of Contents
Configuring Platform and System Settings
Configuring the Domain Name System Server
Configuring the Content Router for Interoperability with a Layer 4 Switch
Configuring NTP Settings
Configuring Device Clock and Time Zone Settings
Configuring CDP Settings
Configuring TCP Settings
About Explicit Congestion Notification
About Congestion Windows
About the Retransmit Time Multiplier
About TCP Slow Start
About TCP-Over-Satellite Extensions
Configuring Secure Shell Settings
About the Secure Shell Host Key
About Secure Shell Daemon Password Guesses
Enabling the Telnet Service on the Content Engine
Configuring Exec Timeout Settings
Enabling RCP Services on the Content Engine
Modifying System Default Properties
Configuring Faster Detection of Offline Content Engines
About Faster Detection of Offline Content Engines
Printing ACNS Network Data
Creating Proxy Error Message Configurations
Configuring Proxy Error Message Download Settings for the Content Engine
Configuring Proxy Error Message Upload Settings for the Content Engine
Configuring Platform and System Settings
This chapter explains how to configure platform and system settings. It contains the following sections:
•
Configuring the Domain Name System Server
•Configuring the Content Router for Interoperability with a Layer 4 Switch
•Configuring NTP Settings
•Configuring Device Clock and Time Zone Settings
•Configuring CDP Settings
•Configuring TCP Settings
•Configuring Secure Shell Settings
•Enabling the Telnet Service on the Content Engine
•Enabling RCP Services on the Content Engine
•Modifying System Default Properties
•Configuring Faster Detection of Offline Content Engines
•Printing ACNS Network Data
•Creating Proxy Error Message Configurations
Configuring the Domain Name System Server
DNS allows the network to translate domain names entered in requests into their associated IP addresses. To configure DNS caching on a Content Engine, you must complete the following tasks:
•Specify the list of DNS servers, which are used by the network to translate requested domain names into IP addresses that the Content Engine should use for domain name resolution.
•Specify the name of the local domain.
•Specify the maximum number of records that the DNS cache on the Content Engine should store. This will define the size of the DNS cache on the Content Engine.
•Enable DNS caching on the Content Engine.
By default, the DNS caching name service on the Content Engine uses a DNS server from its list of configured DNS servers instead of the original DNS server.
•Original DNS server—DNS server from the original request (referred to as the original DNS server)
•List of Configured DNS Servers—DNS servers that are used in the network and have been added to the list of DNS servers that the Content Engine should use for domain name resolution.
To configure DNS server settings for a Content Engine, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3 From the Contents pane, choose General Settings > Network > DNS. The HTTP DNS Cache Settings window appears. (See Figure 16-1.) Table 16-1 defines the fields in this window and provides the corresponding CLI global configuration commands.
Figure 16-1 HTTP DNS Cache Settings Window
Step 4 Check the Enable DNS Caching of DNS Entries for Http Proxy check box to enable DNS caching.
Step 5 In the Maximum Cached DNS Entries field, enter a value in megabytes to configure the size of the DNS cache hash table to be temporarily used for storing records. The range is from 5 to 512.
Step 6 Check the Enable Serial Lookup check box to allow each configured name server to be queried in turn if the request to the primary name server fails.
Step 7 In the Local Domain Name field, enter the name of the local domain that is to be DNS cached.
Step 8 In the List of DNS Servers field, enter a list of DNS servers used by the network to resolve host names to IP addresses. You can configure up to eight DNS servers. Separate items in the list with a space.
Step 9 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default and device group settings. To revert to the previously configured window settings, click Reset. The Reset button appears only when you have applied default or group settings to change the current device settings but the settings have not yet been submitted.
Table 16-1 HTTP Proxy DNS Cache Settings
GUI Parameter
|
Function
|
CLI Command
|
Enable DNS Caching of DNS Entries for HTTP Proxy
|
Enables DNS caching in the system.
|
dns enable
|
Maximum Cached DNS Entries
|
Defines the maximum size of the DNS cache hash table used for temporarily saving DNS records.
|
dns max-cache-memory
|
Enable Serial Lookup
|
Allows each configured name server to be queried in turn if the request to the primary name server fails.
|
dns serial-lookup
|
Local Domain Name
|
Name of the local domain to be DNS cached.
|
ip domain-name name1 name2 name3
|
List of DNS Servers
|
DNS servers that are used by the network to translate requested domains into IP addresses.
|
ip name-server
|
Configuring the Content Router for Interoperability with a Layer 4 Switch
When a request for content is made, the Layer 4 Cisco Content Services Switch uses owner and content rules to translate the virtual IP address of the owner to the IP address of the service where the content resides. Depending on the content rules configured, the Content Services Switch checks for services that match the content rules and determines the service that can best serve the content request.
Note A Cisco Content Services Switch enables you to configure owners and content rules to direct requests for content to a specific destination service (for example, a server or a port on a server). By configuring services, owners, and content rules, you optimize and control how the Content Services Switch handles each request for specific content.
•A service is a destination location where a piece of content physically resides (such as, a local or remote server and port).
•An owner is generally the person or company who contracts the web hosting service to host their web content and allocate bandwidth as required.
•A content rule is a hierarchical rule set containing individual rules that describe which content (for example, .html files) is accessible by visitors to the web site, how the content is mirrored, on which server the content resides, and how the Content Services Switch should process requests for the content. Each rule set must have an owner.
If you have a Content Services Switch deployed in your ACNS network for load balancing, this feature of redirection of requests with the origin server name allows you to access the content using Content Router redirection without advertising a separate Content Router Fully Qualified Domain Name (FQDN).
To configure and enable Layer 4 switch interoperability, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.
Step 2 Click the Edit icon next to the name of the Content Router that you want to view. The Modifying Content Router window appears.
Step 3 In the Contents pane, choose General Settings > Network > L4 Switch. The Layer 4 Switch Settings for Content Router window appears. (See Figure 16-2.)
Figure 16-2 Layer 4 Switch Settings for Content Router Window
Step 4 Check the Enable HTTP l4-switch check box to enable Layer 4 switch redirection interoperability using HTTP.
Step 5 Check the Enable RTSP l4-switch check box to enable Layer 4 switch redirection interoperability using RTSP.
Step 6 Click Submit to save the configured settings.
Configuring NTP Settings
Cisco ACNS 5.x software allows you to configure the Content Engine time and date settings using an NTP (Network Time Protocol) host on your network. NTP allows the synchronization of time and date settings for the different geographical locations of the Content Engines on your ACNS network.
To configure Content Engine or device group NTP settings, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3 From the Contents pane, choose General Settings > Network > NTP. (See Figure 16-3.)
Figure 16-3 NTP Settings Window
Step 4 Check the Enable check box to enable NTP settings.
Step 5 Enter a host name or IP address in the NTP Server field.
Step 6 Click Submit to save the settings.
Configuring Device Clock and Time Zone Settings
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 manually 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. Customized summer time settings configured from the Content Distribution Manager GUI correspond to the clock summertime global configuration command.
Note 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 clock set EXEC command sets the software clock.
To configure the time zone for proper system configuration and to set summer time (daylight savings time) on the Content Engine, follow these steps:
Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2 Click the Edit icon next to the Content Engine for which you want to configure the time zone. The Device Home for Content Engine window appears.
Step 3 In the Contents pane, choose General Settings > Time Zone. The Time Zone Settings for Content Engine window appears.
Step 4 To configure a standard time zone on the Content Engine, follow these steps:
a. Under the Time Zone Settings section, click the Standard Time Zone radio button. The default is UTC (offset = 0) with no summer time configured. When you configure a standard time zone, the system is automatically adjusted for the UTC offset and the UTC offset need not be specified.
The standard convention for time zones uses a Location/Area format in which Location is a continent or a geographic region of the world and Area is a time zone region within that location. For a list of standard time zones that can be configured and their UTC offsets, see Table 16-2.
b. Choose a location for the time zone from the drop-down list. The window refreshes, displaying all area time zones for the chosen location in the second drop-down list.
c. Choose an area for the time zone. The UTC offset (hours and minutes ahead or behind UTC) for the corresponding time zone is displayed next to the second drop-down list. During summer time savings, the offset may be different and will be displayed accordingly.
Note Some of the standard time zones (mostly time zones within the United States) have daylight savings time zones configured automatically.
Step 5 To configure a customized time zone on the Content Engine, follow these steps:
a. Under the Time Zone Settings section, click the Customized Time Zone radio button.
b. In the Customized Time Zone field, specify the name of the time zone. The time zone entry is case-sensitive and can contain up to 40 characters including spaces. If you specify any of the standard time zone names, an error message is displayed when you click Submit.
c. For UTC Offset, choose the + or - sign from the first drop-down list to specify whether the configured time zone is ahead or behind UTC. Also, choose the number of hours (0-23) and minutes (0-59) offset from UTC for the customized time zone. The range for the UTC offset is from -23:59 to 23:59, and the default is 0:0.
Step 6 To configure customized summer time, follow these steps under the Customized Summer Time Savings section.
Note Customized summer time can be specified for both standard and customized time zones.
a. To configure absolute summer time, click the Absolute Dates radio button.
The start date and end date for summer time can be configured in two ways: absolute dates or recurring dates. Absolute date settings apply only once and must be set every year. Recurring dates apply repeatedly for many years.
b. In the Start Date and End Date fields, specify the month (January through December), day (1-31), and year (1993-2032) on which summer time must start and end in mm/dd/yyyy format. Make sure that the end date is always later than the start date.
Alternatively, click the Calendar icon next to the Start Date and End Date fields to display the Date Time Picker popup window. By default the current date is highlighted in yellow. In the Date Time Picker popup window, use the left or right arrow icons to choose the previous or following years, if required. Choose a month from the drop-down list. Click a day of the month. The chosen date is highlighted in blue. Click Apply. Alternatively, click Set Today to revert to the current day. The chosen date will be displayed in the Start Date and End Date fields.
c. To configure recurring summer time, click the Recurring Dates radio button.
d. From the Start Day drop-down list, choose a day of the week (Monday-Sunday) to start.
e. From the Start Week drop-down list, choose an option (first, 2nd, 3rd, or last) to set the starting week. For example, choose first to configure summer time to recur beginning the first week of the month or last to configure summer time to recur beginning the last week of the month.
f. From the Start Month drop-down list, choose a month (January-December) to start.
g. From the End Day drop-down list, choose a day of the week (Monday-Sunday) to end.
h. From the End Week drop-down list, choose an option (first, 2nd, 3rd, or last) to set the ending week. For example, choose first to configure summer time to end beginning the first week of the month or last to configure summer time to stop beginning the last week of the month.
i. From the End Month drop-down list, choose a month (January-December) to end.
Step 7 From the Start Time drop-down lists, choose the hour (0-23) and minute (0-59) at which daylight saving time should start. From the End Time drop-down lists, choose the hour (0-23) and minute (0-59) at which daylight saving time should end.
Start Time and End Time fields for summer time are the times of the day when the clock is changed to reflect summer time. By default, both start and end times are set at 00:00.
Step 8 In the Offset field, specify the minutes offset from UTC (0-1439). See Table 16-2.
The summer time offset specifies that the number of minutes that the system clock moves forward at the specified start time and backward at the end time.
Step 9 To not specify a summer or daylight saving time for the corresponding time zone, click the No Customized Summer Time Configured radio button.
Step 10 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you attempt to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
Table 16-2 Timezone—Offset from UTC
Time Zone
|
Offset from UTC (in hours)
|
Africa/Algiers
|
+1
|
Africa/Cairo
|
+2
|
Africa/Casablanca
|
0
|
Africa/Harare
|
+2
|
Africa/Johannesburg
|
+2
|
Africa/Nairobi
|
+3
|
America/Buenos_Aires
|
-3
|
America/Caracas
|
-4
|
America/Mexico_City
|
-6
|
America/Lima
|
-5
|
America/Santiago
|
-4
|
Atlantic/Azores
|
-1
|
Atlantic/Cape_Verde
|
-1
|
Asia/Almaty
|
+6
|
Asia/Baghdad
|
+3
|
Asia/Baku
|
+4
|
Asia/Bangkok
|
+7
|
Asia/Colombo
|
+6
|
Asia/Dacca
|
+6
|
Asia/Hong_Kong
|
+8
|
Asia/Irkutsk
|
+8
|
Asia/Jerusalem
|
+2
|
Asia/Kabul
|
+4.30
|
Asia/Karachi
|
+5
|
Asia/Katmandu
|
+5.45
|
Asia/Krasnoyarsk
|
+7
|
Asia/Magadan
|
+11
|
Asia/Muscat
|
+4
|
Asia/New Delhi
|
+5.30
|
Asia/Rangoon
|
+6.30
|
Asia/Riyadh
|
+3
|
Asia/Seoul
|
+9
|
Asia/Singapore
|
+8
|
Asia/Taipei
|
+8
|
Asia/Tehran
|
+3.30
|
Asia/Vladivostok
|
+10
|
Asia/Yekaterinburg
|
+5
|
Asia/Yakutsk
|
+9
|
Australia/Adelaide
|
+9.30
|
Australia/Brisbane
|
+10
|
Australia/Darwin
|
+9.30
|
Australia/Hobart
|
+10
|
Australia/Perth
|
+8
|
Australia/Sydney
|
+10
|
Canada/Atlantic
|
-4
|
Canada/Newfoundland
|
-3.30
|
Canada/Saskatchewan
|
-6
|
Europe/Athens
|
+2
|
Europe/Berlin
|
+1
|
Europe/Bucharest
|
+2
|
Europe/Helsinki
|
+2
|
Europe/London
|
0
|
Europe/Moscow
|
+3
|
Europe/Paris
|
+1
|
Europe/Prague
|
+1
|
Europe/Warsaw
|
+1
|
Japan
|
+9
|
Pacific/Auckland
|
+12
|
Pacific/Fiji
|
+12
|
Pacific/Guam
|
+10
|
Pacific/Kwajalein
|
-12
|
Pacific/Samoa
|
-11
|
US/Alaska
|
-9
|
US/Central
|
-6
|
US/Eastern
|
-5
|
US/East-Indiana
|
-5
|
US/Hawaii
|
-10
|
US/Mountain
|
-7
|
US/Pacific
|
-8
|
UTC was formerly known as Greenwich mean time (GMT). The offset time (number of hours ahead or behind UTC) as displayed in the table is in effect during winter time. During summer time or daylight savings time, the offset may be different from the values in the table and is calculated and displayed accordingly by the system clock.
Configuring CDP Settings
CDP (Cisco Discovery Protocol) is a device discovery protocol that runs on all Cisco-manufactured devices. With CDP, each device in a network sends periodic messages to all devices in the network. All devices listen to periodic messages sent by others in order to learn about neighboring devices and determine the status of their interfaces.
With CDP, network management applications can learn the device type and the Simple Network Management Protocol (SNMP) agent address of neighboring devices. Applications are then able to send SNMP queries within the network. Also, CiscoWorks2000 discovers the Content Engine by means of the CDP packets that are sent by the Content Engine after booting.
Content Engine-related tasks require that the Content Engine platform support CDP in order to be able to notify the system manager of the existence, type, and version of the Content Engine platform.
To configure CDP settings using the Content Distribution Manager GUI, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.
Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3 From the Contents pane, choose General Settings > Network > CDP. The CDP Settings window appears. (See Figure 16-4.)
Figure 16-4 CDP Settings Window
Step 4 Check the Enable check box to enable CDP support.
Step 5 In the Hold Time field, enter the time (in seconds) to specify the length of time that a receiver is to keep the CDP packets. The range is 10 to 255 seconds. The default is 180 seconds.
Step 6 In the Packet Send Rate field, enter a value (in seconds) for the interval between CDP advertisements. The range is 5 to 254 seconds. The default is 60 seconds.
Step 7 Click Submit to save the settings.
To configure CDP in the CLI, use the following global configuration command:
cdp {enable | holdtime seconds | timer seconds}
To enable CDP on a particular interface, use the following global configuration command:
interface interface slot/port cdp enable
Configuring TCP Settings
Although Content Engines are typically used to increase the throughput of HTTP streams over TCP end to end, adjusting TCP parameters for better performance is often overlooked when configuring content caching. For data transactions and queries between client and servers, the size of windows and buffers is important, and fine-tuning the TCP stack parameters therefore becomes the key to maximizing cache performance. The relevant TCP parameters to maximize cache performance and throughput include the ability to tune timeout periods, client and server receive and send buffer sizes, and TCP window scaling behavior.
Note Because of the complexities involved in TCP parameters, care is advised in tuning these parameters. In nearly all environments, the default TCP settings are adequate. Fine tuning of TCP settings is for network administrators with adequate experience and full understanding of TCP operation details.
To configure TCP settings for the Content Engine, follow these steps:
Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2 Click the Edit icon next to the Content Engine for which you want to configure TCP settings. The Device Home for Content Engine window appears.
Step 3 In the Contents pane, choose General Settings > Network > TCP. The TCP Settings for Content Engine window appears.
To configure TCP parameters, you need to configure three sets of settings:
•TCP General Settings
•TCP Client Settings
•TCP Server Settings
See Figure 16-5 and Figure 16-6. Table 16-3 describes the fields in this window and provides the corresponding CLI global configuration commands.
Figure 16-5 TCP Settings Window—General Settings
Figure 16-6 TCP Settings Window—Server and Client Settings
Step 4 Under the TCP General Settings section, follow these steps:
a. Check the Enable Explicit Congestion Notification check box to enable reduction of delay and packet loss in data transmissions. It provides TCP support for RFC 2581. (See the "About Explicit Congestion Notification" section.)
b. Check the Enable Type Of Service check box to enable the TCP Type of Service. It is disabled by default.
c. In the Congestion Window Size field, specify the initial congestion window value in segments. The default is 2 segments. (See the "About Congestion Windows" section.)
d. In the ReTransmit Time Multiplier field, specify the factor used to modify the length of the retransmit timer by 1 to 3 times the base value determined by the TCP algorithm. The default is 1, which leaves the times unchanged. (See the "About the Retransmit Time Multiplier" section.)
Note Modify this factor with caution. It can improve throughput when TCP is used over slow reliable connections but should never be changed in an unreliable packet delivery environment.
e. In the Initial Slow Start Threshold field, specify the threshold for slow start in segments. The default is 2 segments. (See the "About TCP Slow Start" section.)
f. In the Keepalive Probe Count field, specify the number of times the Content Engine can retry a connection before the connection is declared unsuccessful. The default is 4 attempts.
g. In the Keepalive Probe Interval field, specify the length of time that the Content Engine keeps an idle connection open. The default is 300 seconds.
h. In the Keepalive Timeout field, specify the length of time that the Content Engine keeps a connection open before disconnecting. The default is 90 seconds.
Step 5 Under the TCP Client Settings section, follow these steps:
a. Check the Enable Client Satellite check box to set client TCP compliance to the RFC 1323 standard. (See the "About TCP-Over-Satellite Extensions" section.)
Note If you enable a client satellite, the server satellite is automatically enabled, and vice versa.
b. In the Client Max Segment Size field, specify the maximum packet size sent to clients. The default is 1432 bytes.
c. In the Client Receive Buffer Size field, specify the TCP receiving buffer size (in kilobytes) for incoming TCP packets. The default is 32 KB.
d. In the Client Read/Write Timeout field, specify the period after which the Content Engine times out trying to read or write to the network. The default is 120 seconds.
e. In the Client Send Buffer Size field, specify the TCP sending buffer size (in kilobytes) for outgoing TCP packets. The default is 32 KB.
Step 6 Under the TCP Server Settings section, follow these steps:
a. Check the Enable Server Satellite check box to set server TCP server compliance to the RFC 1323 standard. (See the "About TCP-Over-Satellite Extensions" section.)
Note If you enable a server satellite, the client satellite is automatically enabled, and vice versa.
b. In the Server Max Segment Size field, specify the maximum packet size sent to the server. The default is 1460 bytes.
c. In the Server Receive Buffer Size field, specify the TCP receiving buffer size (in kilobytes) for incoming TCP packets. The default is 32 KB.
d. In the Server Read/Write Timeout field, specify the period after which the Content Engine times out trying to read or write to the network. The default is 120 seconds.
e. In the Server Send Buffer Size field, specify the TCP sending buffers size (in kilobytes) for outgoing TCP packets. The default is 32 KB.
Step 7 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
Table 16-3 TCP Settings
GUI Parameter
|
Function
|
CLI Command
|
TCP General Settings
|
Enable Explicit Congestion Notification
|
Enables reduction of delay and packet loss.
|
tcp ecn enable
|
Enable Type Of Service
|
Enables Type of Service.
|
tcp type-of-service enable
|
Congestion Window Size
|
Congestion window size in segments.
|
tcp cwnd-base segments
|
ReTransmit Time Multiplier
|
Factor used to modify the length of the retransmit timer.
|
tcp increase-xmit-timer-value value
|
Initial Slow Start Threshold
|
Threshold for slow start in segments.
|
tcp init-ss-threshold value
|
Keepalive Probe Count
|
Number of times the Content Engine can retry a connection before it is considered unsuccessful.
|
tcp keepalive-probe-cnt count
|
Keepalive Probe Interval
|
Length of time that the Content Engine keeps an idle connection open.
|
tcp keepalive-probe-interval seconds
|
Keepalive Timeout
|
Length of time that the Content Engine keeps a connection open before disconnecting.
|
tcp keepalive-timeout seconds
|
TCP Client Settings
|
Enable Client Satellite
|
Sets client TCP compliance to the RFC 1323 standard.
|
tcp client-satellite
|
Client Max Segment Size
|
Maximum packet size sent to clients.
|
tcp client-mss max_seg_size
|
Client Receive Buffer Size
|
TCP receiving buffer size in kilobytes (1-512) for incoming TCP packets.
|
tcp client-receive-buffer kbytes
|
Client Read/Write Timeout
|
Period after which the Content Engine times out when attempting to read or write to the network.
|
tcp client-rw-timeout seconds
|
Client Send Buffer Size
|
TCP sending buffers size in kilobytes (1-512) for outgoing TCP packets.
|
tcp client-send-buffer kbytes
|
TCP Server Settings
|
Enable Server Satellite
|
Sets TCP server compliance to the RFC 1323 standard.
|
tcp server-satellite
|
Server Max Segment Size
|
Maximum packet size sent to the server.
|
tcp server-mss max_seg_size
|
Server Receive Buffer Size
|
TCP receiving buffer size in kilobytes (1-512) for incoming TCP packets.
|
tcp server-receive-buffer kbytes
|
Server Read/Write Timeout
|
Period after which the Content Engine times out when attempting to read or write to the network.
|
tcp server-rw-timeout seconds
|
Server Send Buffer
|
TCP sending buffer size in kilobytes (1-512) for outgoing TCP packets.
|
tcp server-send-buffer kbytes
|
About Explicit Congestion Notification
The TCP Explicit Congestion Notification (ECN) feature allows an intermediate router to notify the end hosts of impending network congestion. It also provides enhanced support for TCP sessions associated with applications that are sensitive to delay or packet loss, including Telnet, web browsing, and transfer of audio and video data. The major issue with ECN is the need to change the operation of both the routers and the TCP software stacks to accommodate the operation of ECN.
About Congestion Windows
The congestion window (cwnd) is a TCP state variable that limits the amount of data that a TCP sender can transmit onto the network before receiving an acknowledgment (ACK) from the receiving side of the TCP transmission. The TCP cwnd variable is implemented by the TCP congestion avoidance algorithm. The goal of the congestion avoidance algorithm is to continually modify the sending rate so that the sender automatically senses any increase or decrease in available network capacity during the entire data flow. When congestion occurs (manifested as packet loss), the sending rate is first lowered and then gradually increased as the sender continues to probe the network for additional capacity.
About the Retransmit Time Multiplier
The TCP sender uses a timer to measure the time that has elapsed between sending a data segment and receiving the corresponding ACK from the receiving side of the TCP transmission. When this retransmit timer expires, the sender (according to the RFC standards for TCP congestion control) must reduce its sending rate. However, because the sender is not reducing its sending rate in response to network congestion, the sender is not able to make any valid assumptions about the current state of the network. Therefore, in order to avoid congesting the network with an inappropriately large burst of data, the sender implements the slow start algorithm, which reduces the sending rate to one segment per transmission. (See the next section, "About TCP Slow Start.")
You can modify the sender's retransmit timer by using the Retransmit Time Multiplier field in the Content Distribution Manager GUI or the tcp increase-xmit-timer-value global configuration command in the CLI. The retransmit time multiplier modifies the length of the retransmit timer by one to three times the base value, as determined by the TCP algorithm that is being used for congestion control.
When making adjustments to the retransmit timer, be aware that they affect performance and efficiency. If the retransmit timer is triggered too early, the sender pushes duplicate data onto the network unnecessarily; if the timer is triggered too slowly, the sender remains idle for too long, unnecessarily slowing data flow.
About TCP Slow Start
Slow start is one of four congestion control algorithms used by TCP. The slow start algorithm controls the amount of data being inserted into the network at the beginning of a TCP session, when the capacity of the network is not known.
For example, if a TCP session began by inserting a large amount of data into the network, much of the initial burst of data would probably be lost. Instead, TCP initially transmits a modest amount of data that has a high probability of successful transmission. TCP then probes the network by sending increasing amounts of data as long as the network does not show signs of congestion.
The slow start algorithm begins by sending packets at a rate that is determined by the congestion window, or cwnd variable (see "About Congestion Windows"). The algorithm continues to increase the sending rate until it reaches the limit set by the slow start threshold (ssthresh) variable. (Initially, the value of the ssthresh variable is adjusted to the receiver's maximum window size [RMSS]. However, when congestion occurs, the ssthresh variable is set to half the current value of the cwnd variable, marking the point of the onset of network congestion for future reference.)
The starting value of the cwnd variable is set to that of the sender maximum segment size (SMSS), which is the size of the largest segment that the sender can transmit. The sender sends a single data segment, and because the congestion window is equal to the size of one segment, the congestion window is now full. The sender then waits for the corresponding ACK from the receiving side of the transmission. When the ACK is received, the sender increases its congestion window size by increasing the value of the cwnd variable by the value of one SMSS. Now the sender can transmit two segments before the congestion window is again full and the sender is once more required to wait for the corresponding ACKs for these segments. The slow start algorithm continues to increase the value of the cwnd variable and therefore increase the size of the congestion window by one SMSS for every ACK received. If the value of the cwnd variable increases beyond the value of the ssthresh variable, then the TCP flow control algorithm changes from the slow start algorithm to the congestion avoidance algorithm.
About TCP-Over-Satellite Extensions
The Content Engine has the ability to turn on TCP-over-satellite extensions (as documented in RFC 1323) to maximize performance and end-to-end throughput over satellite-type connections.
The large number of satellites available to network infrastructures has increased the amount of bandwidth available in the air. Taking advantage of these connections through satellite-type connections has created new challenges in the use of TCP transactions and acknowledgments:
•Latency—Round trip times to satellites orbiting 24,000 miles above the earth are 550 milliseconds for a single satellite hop. Buffer size must be set to prevent low-throughput connections.
•Bit errors—Packet loss can occur in a land-based device-to-satellite connection in addition to the losses caused by regular network congestion.
•Asymmetric bandwidth—Return bandwidth from satellites can be narrower than receiving bandwidth, thereby affecting performance.
Use the fields provided under the TCP Server Settings and TCP Client Settings sections to set the TCP connection so that it complies with RFC 1323.
Configuring Secure Shell Settings
Secure Shell (SSH) consists of a server and a client program. Like Telnet, you can use the client program to remotely log in to a machine that is running the SSH server, but unlike Telnet, messages transported between the client and the server are encrypted. The functionality of SSH includes user authentication, message encryption, and message authentication.
The SSH management window in the Content Distribution Manager GUI allows you to specify the key length, login grace time, and maximum number of password guesses allowed when logging in.
To enable the SSH daemon on the Content Engine, follow these steps:
Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2 Click the Edit icon next to the Content Engine for which you want to enable SSH. The Device Home for Content Engine window appears.
Step 3 In the Contents pane, choose General Settings > Network > SSH. The SSH Configuration window appears. (See Figure 16-7.) Table 16-4 describes the fields in this window and provides the corresponding CLI global configuration commands.
Figure 16-7 SSH Configuration Window
Step 4 Check the Enable check box to enable the SSH feature. SSH enables login access to the Content Engine through a secure and encrypted channel.
Step 5 In the Length of key field, specify the number of bits needed to create an SSH key. The default is 1024.
When you enable SSH, be sure to generate both a private and a public host key, which client programs use to verify the server's identity. (See the "About the Secure Shell Host Key" section.)
Step 6 In the Login grace time field, specify the number of seconds for which an SSH session will be active during the negotiation (authentication) phase between client and server before it times out.
Step 7 In the Maximum number of password guesses field, specify the maximum number of incorrect password guesses allowed per connection. The default is 3. (See "About Secure Shell Daemon Password Guesses" section.)
Step 8 To allow clients to connect using SSH protocol version 1, check the Enable SSHv1 check box.
Step 9 To allow clients to connect using SSH protocol version 2, check the Enable SSHv2 check box.
Note You can enable both SSHv1 and SSHv2, or you can enable one version and not the other. You cannot disable both versions of SSH unless you disable the SSH feature by unchecking the Enable check box. (See Step 4.)
Step 10 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
Table 16-4 SSH Settings
GUI Parameter
|
Function
|
CLI Command
|
Enable
|
Enables the SSH feature.
|
sshd enable
|
Length of key
|
Number of bits needed to create an SSH key.
|
ssh-key-generate key-length length
|
Login grace time
|
Number of seconds for which an SSH session will be active during the negotiation (authentication) phase between client and server before it times out.
|
sshd timeout seconds
|
Maximum number of password guesses
|
Maximum number of incorrect password guesses allowed per connection.
|
sshd password-guesses num
|
Enable SSHv1
|
Allows clients to connect using SSH protocol version 1.
|
sshd version 1
|
Enable SSHv2
|
Allows clients to connect using SSH protocol version 2.
|
sshd version 2
|
About the Secure Shell Host Key
When you run an SSH client and log in to the Content Engine, the public key for the SSH daemon running on the Content Engine is recorded in the client machine known_hosts file in your home directory. If the Content Engine administrator subsequently regenerates the host key by specifying the number of bits in the Length of key field, you must delete the old public key entry associated with the Content Engine in the known_hosts file before running the SSH client program to log in to the Content Engine. When you run the SSH client program after deleting the old entry, the known_hosts file is updated with the new SSH public key for the Content Engine.
About Secure Shell Daemon Password Guesses
Although the value in the Maximum number of password guesses field specifies the number of allowed password guesses from the SSH server side, the actual number of password guesses for an SSH login session is determined by the combined number of allowed password guesses of the SSH server and the SSH client. Some SSH clients limit the maximum number of allowed password guesses to three (or to one in some cases), even though the SSH server allows more than this number of guesses.
When you specify n allowed password guesses, certain SSH clients interpret this number as n + 1. For example, when configuring the number of guesses to two for a particular device, SSH sessions from some SSH clients will allow three password guesses.
Enabling the Telnet Service on the Content Engine
To enable the Telnet service on the Content Engine, follow these steps:
Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2 Click the Edit icon next to the Content Engine for which you want to enable Telnet. The Device Home for Content Engine window appears.
Step 3 In the Contents pane, choose General Settings > Network > Telnet. The Telnet Settings for Content Engine window appears.
Step 4 Check the Telnet Enable to enable the terminal emulation protocol for remote terminal connection.
Note You must use a console connection instead of a Telnet session to define device network settings on the Content Engine. However, after you have used a console connection to define the device network settings for this Content Engine, you can use a Telnet session to perform subsequent configuration tasks (for example, configure DNS caching).
Step 5 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
To enable the Telnet service on the Content Engine from the CLI, use the telnet enable global configuration command.
Configuring Exec Timeout Settings
To configure the length of time that an inactive Telnet session remains open on the Content Engine, follow these steps:
Step 1 From the Content Distribution Manger GUI, choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2 Click the Edit icon next to the Content Engine for which you want to configure the exec timeout. The Device Home for Content Engine window appears.
Step 3 In the Contents pane, choose General Settings > Network > Exec Timeout. The Exec Timeout Settings for Content Engine window appears.
Step 4 In the Exec Timeout field, specify the number of minutes after which an active session times out. The default is 15 minutes.
A Telnet session with the Content Engine can remain open and inactive for the period specified in this field. When the exec timeout period elapses, the Content Engine automatically closes the Telnet session.
Step 5 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
To configure the length of time that an inactive Telnet session remains open on the Content Engine from the CLI, use the exec-timeout minutes global configuration command.
Enabling RCP Services on the Content Engine
Remote Copy Protocol (RCP) lets you download, upload, and copy configuration files between remote hosts and a switch. Unlike TFTP, which uses User Datagram Protocol (UDP), a connectionless protocol, RCP uses TCP, which is connection oriented.
RCP is a subset of the UNIX rshell service, which allows UNIX users to execute shell commands on remote UNIX systems. It is therefore a UNIX built-in service. This service uses TCP as the transport protocol, and listens for requests on TCP port 514. RCP service can be enabled on Content Engines running ACNS software. Inetd (an Internet daemon pronounced eye net dee) is a program that listens for connection requests or messages for certain ports and starts server programs to perform the services associated with those ports. RCP copies files between devices.
To enable RCP services on the Content Engine, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.
Step 2 Click the Edit icon next to the Content Engine for which you want to enable RCP services. The Device Home for Content Engine window appears.
Step 3 In the Contents pane, choose General Settings > Network > Inetd RCP. The Inetd RCP Settings for Content Engine window appears.
Step 4 Check the Inetd Rcp Enable check box to enable the RCP service on the Content Engine.
Note The Inetd daemon listens for FTP, RCP, and TFTP services. For inetd to listen to RCP requests, it must be explicitly enabled for RCP service.
Step 5 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default or device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.
If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.
To enable RCP services on the Content Engine from the CLI, use the inetd enable rcp global configuration command.
Modifying System Default Properties
You can modify the following system properties:
•cdm.session.timeout—Length of a Content Distribution Manager session (in minutes).
•DeviceGroup.overlap—Content Engine feature overlapping (enable or disable).
•System.CmsUnsProgramSync.Interval—Interval by which CMS synchronizes program import UNS objects (in minutes). The default is 1440 minutes.
•System.datafeed.pollRate—Poll rate between the Content Engine or the Content Router and the Content Distribution Manager (in seconds).
•System.device.recovery.key—Device identity recovery key. This property enables a device to be replaced by another node in the ACNS network.
•System.guiServer.fqdn—Scheme to use (IP address or FQDN) to launch the Content Engine Cache GUI.
•System.lcm.enable—Local and central management feature (enable or disable). This property allows settings that are configured using the local device CLI or the central Content Distribution Manager GUI to be stored as part of the ACNS network configuration data.
•System.monitoring.collectRate—Rate at which the Content Engine collects and sends the monitoring report to the Content Distribution Manager (in seconds). The default is 300 seconds.
•System.monitoring.dailyConsolidationHour—Hour at which the Content Distribution Manager consolidates hourly and daily monitoring records.
•System.monitoring.enable—Content Engine statistics monitoring (enable or disable).
•System.monitoring.monthlyConsolidationFrequency—Frequency (in days) with which the Content Distribution Manager consolidates daily monitoring records into monthly records.
•System.monitoring.recordLimitDays—Maximum number of days of monitoring data to maintain in the system.
•System.repstatus.updateEnabled—Replication status periodic calculations on a Content Engine (enable or disable).
•System.repstatus.updateRate—Rate of replication status periodic updates calculated on a Content Engine (in minutes).
•System.repstatus.updateRateSec—Rate of replication status periodic updates calculated on a Content Engine (in seconds). The default is 600 seconds. Setting this rate will override the update rate set in minutes.
•System.repstatus.updateSyncEnabled—Sending summary replication status with requested detailed status (enable or disable).
The Config Properties window displays information about existing system configuration properties and their current values. To modify the value of a system property, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose System > Configuration. The Config Properties window appears. (See Figure 16-8.)
Figure 16-8 Config Properties Window—Page 1
Step 2 To see the second page of this window, click Page 2. (See Figure 16-9.)
Figure 16-9 Config Properties Window—Page 2
Step 3 Click the Edit icon next to the system property that you want to change. The Modifying Config Property window appears.
Step 4 Enter a new value or choose a new parameter from a drop-down list, depending on the system property that you want to change.
Step 5 Click Submit.
Configuring Faster Detection of Offline Content Engines
You can detect offline Content Engines more quickly if you enable the fast detection of offline Content Engines. A Content Engine is declared as offline when it has failed to contact the Content Distribution Manager for a getUpdate (get configuration poll) request for at least two polling periods. (See "About Faster Detection of Offline Content Engines" section for more information about this feature.)
To configure fast detection of offline Content Engines, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose System > Configuration. The Config Properties window appears.
Step 2 In the Contents pane, choose Fast CE Offline Detection. The Configure Fast CE Offline Detection window appears.
Note The fast detection offline Content Engines feature is in effect only when the Content Distribution Manager receives the first UDP heartbeat packet and a getUpdate request from a Content Engine.
Step 3 To enable the Content Distribution Manager detect the offline status of Content Engines quickly. check the Enable check box.
This check box is unchecked by default so that if UDP traffic between Content Engines and the Content Distribution Manager is blocked, then all Content Engines using ACNS 5.1 software or earlier are not declared offline when they are upgraded to ACNS 5.2 software.
Step 4 In the Heartbeat Rate (Seconds) field, specify how often Content Engines should transmit a UDP heartbeat packet to the Content Distribution Manager.
Step 5 In the Heartbeat Fail Count field, specify the number of UDP heartbeat packets that can be dropped during transmission from Content Engines to the Content Distribution Manager before a Content Engine is declared offline.
Step 6 In the Heartbeat UDP Port field, specify the port number using which Content Engines will send UDP heartbeat packets to the primary Content Distribution Manager.
The Maximum Offline Detection Time field displays the product of the failed heartbeat count and heartbeat rate.
Maximum Offline Detection Time = Failed heartbeat count * Heartbeat rate
If you have not enabled the fast detection of offline Content Engines feature, then the Content Distribution Manager waits for at least two polling periods to be contacted by the Content Engine for a getUpdate request before declaring the Content Engine to be offline. However, if you enable the fast detection of offline Content Engines feature, then the Content Distribution Manager waits until the value displayed in the Maximum Offline Detection Time field is exceeded.
If the Content Distribution Manager receives the Cisco Discovery Protocol (CDP) from a Content Engine, then the Content Distribution Manager displays the Content Engine as offline after a time period of 2* (heartbeat rate) * (failed heartbeat count).
Step 7 To save the settings, click Submit.
About Faster Detection of Offline Content Engines
Communication between the Content Engine and Content Distribution Manager using User Datagram Protocol (UDP) allows faster detection of Content Engines that have gone offline. UDP heartbeat packets are sent at a specified interval from each Content Engine to the primary Content Distribution Manager in an ACNS network. The primary Content Distribution Manager tracks the last time that it received a UDP heartbeat packet from each Content Engine. If the Content Distribution Manager has not received the specified number of UDP packets, it displays the status of the nonresponsive Content Engines as offline. Because UDP heartbeats require less processing than a getUpdate request, they can be transmitted more frequently, and the Content Distribution Manager can detect offline Content Engines much faster.
You can enable or disable this feature, specify the interval between two UDP packets, and configure the failed heartbeat count. Heartbeat packet rate is defined as the interval between two UDP packets. Using the specified heartbeat packet rate and failed heartbeat count values, the Content Distribution Manager GUI displays the resulting offline detection time as a product of heartbeat rate and failed heartbeat count. If the fast detection of offline Content Engines is enabled, the Content Distribution Manager detects Content Engines that are in network segments that do not support UDP and uses getUpdate (get configuration poll) request to detect offline Content Engines.
By default, the feature to detect offline Content Engines more quickly is not enabled. Content Engines using releases earlier than ACNS 5.2 software might not allow UDP traffic from Content Engines to the Content Distribution Manager, so when this feature is enabled, erroneous offline status reporting might occur because these Content Engines might be in network segments that do not support UDP, and UDP heartbeat packets might not be sent at the specified interval to the primary Content Distribution Manager. If you disable the fast detection of offline Content Engines, all Content Engines can be upgraded without any error in their status being displayed in the Content Distribution Manager GUI.
However, because the UDP packets are sent as clear text, they can be spoofed by a hacker, causing the Content Distribution Manager to incorrectly report the status of a Content Engine as online even when it is actually offline. This problem can be avoided by forcing the Content Distribution Manager to display a Content Engine as offline when the Content Distribution Manager does not receive the specified small number of secure getUpdate requests from the Content Engine.
In ACNS networks with heavy traffic, dropped UDP packets can cause the Content Distribution Manager to incorrectly report the status of Content Engines as offline. To avoid this problem, configure a higher value for dropped UDP heartbeat packets.
Printing ACNS Network Data
Using the features of the Content Distribution Manager, you can print any tabular data about your ACNS network. This includes lists of content providers, websites, and locations, or any of the resources of your ACNS network, such as Content Engines, channels, and so on.
To print data from the Content Distribution Manager, follow these steps:
Step 1 From the Content Distribution Manager GUI, locate the information that you wish to print.
For example, if you wanted to print data about the locations defined for your ACNS network, you would choose Network > Locations.
Step 2 To print your ACNS network data using the default printer on your operating system, click the Printer icon.
Creating Proxy Error Message Configurations
The configurable proxy error messages feature allows you to specify URLs for uploading or downloading templates and files of proxy error messages.
Configuring Proxy Error Message Download Settings for the Content Engine
You can select custom error message files from a list of filenames that have been previously configured. The list of configurable proxy error messages for which download settings can be specified is fixed. The protocols that can be used for downloading custom error files are FTP, HTTP, and HTTPS. You cannot configure two error messages with the same name and different URLs.
To download the custom error message file to the Content Engine, follow these steps:
Step 1 Choose Devices > Devices. The Devices listing window appears.
Step 2 Click the Edit icon next to the Content Engine to which you want to download the error message file. The Content Engine Device Home window appears with the Contents pane on the left.
Step 3 In the Contents pane, choose Streaming/Caching > Proxy Error Messages > Download. The Proxy Error Message Download for Content Engine window appears, listing the proxy error messages and their download URLs.
Step 4 In Aggregate Settings, the Yes radio button is chosen by default. This specifies that the proxy error message configurations for the Content Engine and the device groups with which the Content Engine is associated are displayed. They cannot be modified or deleted. You can only view the proxy error messages created for device groups. Alternatively, click the No radio button to apply the proxy error message configurations for only the Content Engine.
Step 5 Click the Create New Error Messages icon in the taskbar. The Creating New Proxy Error Message for Content Engine window appears.
Step 6 From the Proxy Error Message drop-down list, choose a proxy error message that you wish to download to the Content Engine. See Table 16-5 for a description of the proxy error messages that can be downloaded.
Step 7 In the Download URL field, enter the host name or IP address of the server from which the proxy error message is to be downloaded to the Content Engine.
Step 8 Click Submit to save the settings.
Table 16-5 Proxy Error Messages
Proxy Error Message Name
|
Description
|
blocked-dueto-filter-error
|
Error response when a request is blocked because of a filter
|
cache-read-error
|
Error response when a cache file system (cfs) read fails
|
cache-write-error
|
Error response when a cfs write fails
|
cdn-not-found-error
|
Error response when an ACNS network is not found
|
client-access-denied-msg
|
Error response when client access is denied
|
client-connection-broken-error
|
Error response when a client connection is lost
|
cr-domain-not-found-err
|
Error response when a Content Router could not be found
|
cr-general-error
|
Error response when a Content Router is not operational
|
cr-not-in-cz-error
|
Error response when a Content Router is not found in a coverage zone
|
cr-unavailable-error
|
Error response when a Content Router is not available
|
dns-not-available-error
|
Error response when DNS is unavailable for resolution
|
expect-failed-error
|
Error response when the Expect specifier in the HTTP request header cannot be met
|
ftp-bad-login-error
|
Error response when an FTP login fails
|
ftp-bad-url-error
|
Error response when an FTP request receives a bad URL
|
ftp-disabled-error
|
Error response when FTP is disabled
|
ftp-failure-error
|
Error response when an FTP failure occurs
|
ftp-internal-error
|
Error response when an FTP interval is exceeded
|
ftp-not-found-error
|
Error response when an FTP reports file not found
|
ftp-put-created-msg
|
Error response when an FTP PUT operation is successful
|
ftp-put-error
|
Error response when an FTP PUT operation fails
|
ftp-put-modified-msg
|
Response when an FTP update is successful
|
ftp-unavailable-msg
|
Error response when an FTP file is unavailable
|
http-blocked-port-msg
|
Error response when an HTTP request comes through a blocked port
|
https-blocked-port-msg
|
Error response when an HTTPS request comes through a blocked port
|
icap-processing-error
|
Error response when an error has occurred in ICAP processing
|
invalid-port-error
|
Error response when an invalid port is accessed
|
looped-req-error
|
Error response when a looped request is unsuccessful
|
not-enough-resources-error
|
Error response when not enough resources are available for the request process
|
not-in-cache
|
Error response when an object is not found in the cache
|
offline-miss-error
|
Error response when a Content Engine that is offline finds a cache miss
|
outgoing-proxy-fail-error
|
Error response when all outgoing proxies fail
|
proxy-unauthenticated-error
|
Error response when proxy authentication fails
|
radius-redirect-error
|
Response for a RADIUS redirect message
|
request-blocked-msg
|
Error response when a request is blocked
|
request-malformed-error
|
Error response when request headers are malformed
|
rev-dns-not-available-msg
|
Error response when DNS is not available
|
server-connection-broken-error
|
Error response when a server connection is lost
|
unsupported-cr-method-error
|
Error response when an unsupported Content Router method is used
|
www-unauthenticated-error
|
Error response when server authentication fails
|
To delete proxy error messages, follow these steps:
Step 1 Choose Devices > Devices. The Devices window appears.
Step 2 Click the Edit icon next to the Content Engine for which you want to delete download error messages. The Content Engine Device Home window appears with the Contents pane on the left.
Step 3 In the Contents pane, choose Streaming/Caching > Proxy Error Messages > Download. The Proxy Error Message Download for Content Engine window appears, listing the proxy error messages and their download URLs.
Step 4 Delete the proxy error message or messages:
•To delete all download proxy error messages configured for the Content Engine, click the Remove All Proxy Error Message Configurations in this CE/Device Group icon in the taskbar.
The system displays a dialog box asking you to confirm your decision. Click OK to confirm.
Note This action does not delete the error messages configured through device groups.
•To delete a single proxy error message, from the Proxy Error Message Download for Content Engine window, click the Edit icon of the proxy error message that you want to delete. The Modifying Proxy Error Message window appears. In the taskbar of this window, click the Delete Proxy Error Message icon to delete the download settings for the corresponding error message.
The system displays a dialog box, asking you to confirm whether you want to permanently delete the error message configuration. Click OK to confirm.
Configuring Proxy Error Message Upload Settings for the Content Engine
Customized proxy error messages can be uploaded from the Content Engine to a specified FTP server. You can configure upload settings only for those error files for which you have previously configured the download settings. All the fields in the window to configure upload settings will be disabled if no download settings have been configured.
The proxy error messages are uploaded as custom error message files. Each proxy error message corresponds to an error message file on the FTP server.
To upload the custom error file from the Content Engine to the specified FTP server, follow these steps:
Step 1 Choose Devices > Devices. The Devices window appears.
Step 2 Click the Edit icon next to the desired Content Engine. The Contents pane appears on the left.
Step 3 In the Contents pane, choose Streaming/Caching > Proxy Error Messages > Upload. The Proxy Error Message Upload Settings for Content Engine window appears.
Step 4 From the Proxy Error Message drop-down list, choose the proxy error message to be uploaded to the FTP server. All proxy error messages for which download settings have been configured are displayed here.
Step 5 Enter the host name or IP address of the FTP server in the FTP Server Address field.
Step 6 Enter the remote directory where the error message needs to be saved in the FTP Server Directory field.
Step 7 Enter the name of the custom error file in the FTP Server Filename field.
A custom error file with the name entered here is created for each proxy error message in the directory specified in the previous field. If you specify the same filename for more than one proxy error message, the previously uploaded error message to that file will be overwritten.
Step 8 Enter the name of the user who needs to access the FTP server in the FTP Server Username field.
Step 9 In the FTP Server Password field, enter the password to authenticate the user who logs in to the server.
Step 10 In the Confirmation Password field, reenter the password entered in the previous field.
Step 11 Click Submit to save the settings.
