Cisco Internet CDN Software User Guide
Chapter 4: Maintaining Cisco Internet CDN Software

Table of Contents

Maintaining Cisco Internet CDN Software

Adding and Removing SNMP Managers
Changing System Passwords
Managing Symmetric Keys
Modifying Playserver Configuration
Modifying Routing Properties
Setting Up Remote Logging
Updating Cisco Internet CDN Software
Modifying System Properties
Troubleshooting

Maintaining Cisco Internet CDN Software

This chapter contains information on maintaining and troubleshooting your Cisco Internet CDN Software. Additional configuration and troubleshooting information can be found in the hardware documentation that shipped with your CDN devices.

This chapter contains the following sections:

Adding and Removing SNMP Managers

The Cisco Internet CDN Software allows you to deploy one or more Simple Network Management Protocol (SNMP) managers for your CDN.


Note   Registering a new SNMP manager with your CDN, as well as modifying or removing a registered SNMP manager, causes all your CDN nodes to restart as they register the configuration change. Restarting your CDN devices results in a temporary interruption in service across your CDN for the time it takes your devices to come back online—usually a few minutes.

See Appendix "Deploying SNMP on Content Delivery Networks," for more information on using SNMP with your CDN.

Creating an SNMP Manager

Each Cisco Internet CDN Software Version 2.1 device comes with the software necessary to communicate information about device configuration and activity using the SNMP protocol. However, before you can begin logging SNMP data, your organization needs to acquire and deploy an SNMP manager application for use with the CDN.

You can create your SNMP manager using the published CISCO-CONTENT-NETWORK-MIB, which is available from Cisco.com or through FTP from:

ftp://ftpeng.cisco.com/pub/mibs
 

Cisco Internet CDN devices also support the Internet standard HOST-RESOURCES-MIB (RFC 1514). Once you have configured an SNMP manager on your network, use the SNMP Configuration feature on the Content Distribution Manager to point to that device.

Registering an SNMP Manager with the CDN

To add an SNMP manager to your CDN:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose SNMP Configuration. The SNMP Configuration Tool page appears. (See Figure 4-1.)


Figure 4-1: SNMP Configuration Tool


Step 3   In the IP Address field, enter the address of your SNMP manager.

Step 4   Click Add. The manager is added to the list of registered SNMP Managers. Your CDN will temporarily go offline as each CDN node registers the new SNMP manager. This interruption should only last a few minutes.


Removing an SNMP Manager

To remove an SNMP manager from your CDN:


Step 1   From the Content Distribution Manager user interface, click tools.

Step 2   From the drop-down list, choose SNMP Configuration. The SNMP Configuration Tool page appears. (See Figure 4-1.)

Step 3   In the list of registered SNMP managers, check the check box adjacent to the IP address of your SNMP manager.


Tips To choose all SNMP Managers, check the box at the top of the column in the header area.

Step 4   Click Remove. You are prompted to confirm your decision to remove the manager.

Step 5   Click OK. The manager is removed from the list of registered SNMP managers.


Changing System Passwords

All CDN devices maintain two separate passwords for each login account:

All CDN devices are shipped to customers with both the HTTP and root passwords set to a default value, called the "system password." This default value can be initially used to log in to either the device's web interface or its command-line interface.


Note   Default passwords for each device should be changed at the earliest possible opportunity, with the root and HTTP passwords set to different alphanumeric values.

For information about changing the root or HTTP password for individual Content Engines or Content Routers, see the "Modifying Content Engine Passwords" section and the "Modifying Content Router Passwords" section.

Once the HTTP and root passwords have been changed, the system password can no longer be used to log in to devices from either the web interface or the command-line interface. Instead, the system password you define acts as an "override" password for your Content Distribution Manager and other CDN devices.

The system passwords feature is used to manage your system passwords only after the default password values have been changed. System passwords ensure that administrators can access their devices either through the web interface (HTTP password) or through the command-line interface (CLI password), even when an individual device password has been lost or forgotten.

For example, if you have a different password for each device on your CDN and the password for one of your Content Engines has been forgotten or lost, you can substitute the system password for the forgotten password on the Modify a Content Engine page of the Content Distribution Manager graphical user interface and reset either the HTTP or root passwords currently assigned to that device.

Use the sections that follow to change the system password for either the Content Distribution Manager or your Content Engines and Content Routers.

Changing the Content Distribution Manager System CLI Password

To change the Content Distribution Manager CLI password, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the System Tools drop-down list, choose System Passwords.

The System Passwords page appears. (See Figure 4-2.)


Figure 4-2: System Passwords


Step 3   Under the CDM CLI Password heading, enter the old and the new passwords in the Old Password and New Password fields, and then reenter the new password in the Re-type New Password field. This updates the password used to access the command-line interface on the device that serves as your primary Content Distribution Manager.


Note   All passwords should contain exactly eight characters.

Step 4   Click Save. You may be prompted to enter the new password value into the CDM login dialog. If prompted, enter the new password into the Password field and click OK.

The System Passwords page refreshes. If the password was successfully changed, a green circle with a check mark is displayed next to the affected password field. See the "Content Distribution Manager Icons" section for details.


Changing the CLI System Password for Content Engines and Content Routers

You change the CLI password for all your Content Engines and Content Routers by entering new password values into the field provided in the System CLI Password area of the System Passwords page.

When you click Save, the system password on each Content Engine and Content Router on your CDN is overwritten with the new password value you specified.

Once you have a usable system password value, use it to modify a Content Engine or Content Router password, as outlined in the "Modifying Content Engine Passwords" section and the "Modifying Content Router Passwords" section if the original password has been forgotten.

To change the system CLI password for your Content Engines and Content Routers, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the System Tools drop-down list, choose System Passwords.

The System Passwords page appears. (See Figure 4-2.)

Step 3   Under the System CLI Password heading, enter the old and the new passwords in the Old Password and New Password fields, and then reenter the new password in the Re-type New Password field. This updates the system password used to access the command-line interface on all Content Engines and Content Routers.


Note   All passwords should contain exactly eight characters.

Step 4   Click Save. The system CLI password change is circulated to all Content Engines and Content Routers on your CDN. This may take a few minutes.


Changing the HTTP System Password for CDN Devices

The HTTP system password is used to gain access to the web interface for any CDN device. In the case of the Content Distribution Manager, the system HTTP password can give an administrator access to the Content Distribution Manager graphical user interface if the normal account password is lost or forgotten. In the case of Content Routers and Content Engines, the system HTTP password gives administrators access to high-level device configuration options that are accessible only from the device's web interface.

To change the system HTTP password for your CDN devices, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the System Tools drop-down list, choose System Passwords.

The System Passwords page appears. (See Figure 4-2.)

Step 3   Under the System HTTP Password heading, enter the old and the new passwords in the Old Password and New Password fields, and then reenter the new password in the Re-type New Password field. This updates the system password used to access the web interface on any CDN device.


Note   All passwords should contain exactly eight characters.

Step 4   Click Save. The system HTTP password change will be circulated to all devices on your CDN. This may take a few minutes.


Resetting the CLI and HTTP Passwords for CDN Devices

If you lose access to your CDN devices, either by losing or forgetting the CLI or HTTP passwords, you can reset the device passwords for a given device to their default value.


Note   Once you have access to the device using the default password, you must promptly use the password features available through the Content Distribution Manager graphic user interface to create a new password for the device.

See the "Modifying Content Engine Passwords" section or the "Modifying Content Router Passwords" section for information on changing device passwords from the Content Distribution Manager.

You need access to the device console for the devices in question in order to reset the CLI and HTTP passwords. Refer to the hardware documentation that came with your device for instructions on connecting a monitor and keyboard or serial connection to the device for console access.

To reset CDN device passwords to their default values:


Step 1   If the device in question is up and running, reboot it.

Step 2   At the LILO boot prompt, enter the following command:

LILO boot: linux single

 

The device loads Linux and the prompt changes to indicate that bash has been invoked.

Step 3   At the bash prompt, enter the following command:

bash# /cisco/merlot/etc/reset-passwd

 

You are notified that the system default passwords have been restored.

Step 4   Reboot the device a second time as follows:

bash# reboot

 

When the device comes back online, you can log in to the CLI using the default CLI password value, or access the device web interface using the default HTTP password.


Managing Symmetric Keys

Symmetric keys are used to provide content-based security on a per-hosted domain basis within the CDN. Using symmetric keys, end user requests are "signed" by the content provider using a symmetric key—essentially an algorithm used to encrypt the request.

Content Engines within the hosted domain maintain a copy of each symmetric key for the hosted domain. When Content Engines receive an encrypted request, they determine which key was used to sign it, and then use the appropriate key from their own set to reproduce the unique signature (or message authentication code, MAC) of the request. If the Content Engine's generated MAC value matches that of the request, the Content Engine knows that the request is authentic and attempts to serve it.

See the "Configuring Content Security for Hosted Domains" section for information on creating symmetric keys for a hosted domain.

Viewing Symmetric Keys

Using the Symmetric Key Content Authorization (SKCA) feature, you can view the symmetric keys assigned to a hosted domain.


Note   Before viewing symmetric keys for a hosted domain you must have the hosted domain address and secure access password.

To view the symmetric keys for a hosted domain:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the System Tools drop-down list, choose Symmetric Key Access. The Symmetric Key Access page appears. (See Figure 4-3.)


Figure 4-3: Symmetric Key Access


Step 3   In the Hosted Domain field, enter the name of the hosted domain, exactly as it appears on the View Hosted Domains page. (See Figure 2-16.)

Step 4   In the Access Password field, enter the symmetric key access password. This password was created when you created your symmetric keys.

Step 5   Click the View Keys button. The Symmetric Key Access page appears, displaying the symmetric key ID value as well as start and expiration date.

Step 6   Use the Next Key and Previous Key buttons to view each of the symmetric keys for this hosted domain.


Changing the Symmetric Key Password

Symmetric key passwords allow content providers to view the authentication keys for their hosted domains. Passwords are created and maintained on the Modify a Hosted Domain page and should be changed periodically to protect symmetric keys from unauthorized access.

See the "Viewing Symmetric Keys" section for information on viewing the symmetric keys for a hosted domain.

To change the symmetric key password for a hosted domain:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   Choose Hosted Domains from the drop-down list.

The View Hosted Domains page appears. (See Figure 2-16.)

Step 3   Click the icon adjacent to the name of the hosted domain that you want to change. The Modify a Hosted Domain page appears. (See Figure 3-7.)

Step 4   Under the Content Security heading, enter the existing symmetric key password in the Old Key Access Password field.


Note   You may have to scroll through the Modify a Hosted Domain screen to see the content security configuration fields.

Step 5   In the New Key Access Password field, enter the new symmetric key access password.

Step 6   In the Confirm New Key Access Password field, reenter the new symmetric key access password value.

Step 7   Click Save to confirm your change to the symmetric key access password. The old password value and both of the new password values have to be entered correctly before the CDN will allow you to modify the symmetric key access password.


Modifying Playserver Configuration

Cisco Internet CDN devices support a wide variety of media types, including RealNetworks RealMedia, Microsoft Windows Media Server, and Apple QuickTime.

In order for your CDN devices (the Content Distribution Manager and Content Engines) to be able to serve these media types, you must tell the CDN that a particular playserver type is present.

If there is a particular media type that you do not want to serve through your CDN, you need to disable the corresponding playserver so that your CDN devices do not attempt to serve that media type.

Using the playserver mappings in the manifest file, you can customize your content type mappings from MIME content types or file extensions to configured playservers. See the "Manifest File Structure and Syntax" section for more information on customizing content type mappings.


Note   Modifying the configuration of any playserver causes any CDN nodes running that playserver software to restart and register the configuration change. Depending on the number and location of devices that restart following a playserver configuration change, you may experience a temporary interruption in service for the time it takes your devices to come back online—usually a few minutes.

Use the following information to enable, disable, or modify the configuration of your CDN playservers.

Modifying Windows Media Services Configuration

Cisco Internet CDN Software supports Windows Media Technologies for delivering static, pre-positioned, video-on-demand, and live streamed content to users over the Internet. Microsoft Windows Media Technologies consists of a suite of components that make possible the distribution of live streams and broadband content over the Internet.


Note   In order to use Windows Media Technologies with your CDN, you must first obtain valid licenses from Cisco.com for each Content Engine that will be running Windows Media Services. See the "World Wide Web" section or the "Obtaining Technical Assistance" section for information on obtaining Windows Media Technologies licenses for your Content Engines.

Using the Windows Media Server Configuration page on the Content Distribution Manager, you must first register your acceptance of the Windows Media Technologies license agreement, after which you can make changes to a number of Windows Media Services settings remotely, or deactivate Windows Media Services altogether.

After you have accepted the Windows Media Technologies license agreement and enable the use of Windows Media Services on your CDN, you can then activate Windows Media Services on your hosted domains.

Enabling Windows Media Services on Your CDN

To enable the use of Windows Media Services on your CDN:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Windows Media Server Configuration. The Windows Media Server Configuration page appears. (See Figure 4-4.)


Figure 4-4: Windows Media Server Configuration


Step 3   Click the Read and Approve Windows Media Server option.

Step 4   Click OK. The Windows Media Technologies license agreement appears. You are required to scroll through and read the entire license agreement before continuing.

Step 5   At the bottom of the license agreement, click Agree. You are returned to the Windows Media Server Configuration page. Options appear for configuring your Windows Media Server. (See Figure 4-4.)

See the "Activating Windows Media Services for a Hosted Domain" section for instructions on enabling Windows Media Services on your hosted domains.

See the next section, "Configuring Windows Media Technologies Streaming," for instructions on modifying your Windows Media Server settings.


Configuring Windows Media Technologies Streaming

Cisco Internet CDN Software supports streaming data for up to 2500 concurrent clientconnections per CDN device (Content Distribution Manager or Content Engines).

Using the Windows Media Services configuration feature, you can specify the maximum number of simultaneous client connections and the maximum amount of bandwidth that will be allowed for each CDN device that is serving client requests.

Limiting the number of concurrent sessions and the amount of total bandwidth devoted to serving client requests may potentially deny immediate access to CDN data to some clients. However, doing so also preserves system resources, resulting in optimal performance for clients who are being served. Consider the likely volume of requests you will receive, as well as the bandwidth requirements of the content you are serving and the needs of your customers, before making changes to the Windows Media Technologies streaming configuration.

To modify the Windows Media Technologies streaming configuration:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Windows Media Server Configuration.

The Windows Media Services Configuration page appears. (See Figure 4-4.)

Step 3   In the Maximum number of concurrent streams field, enter a number corresponding to the maximum number of client connections each Content Engine and the Content Distribution Manager will allow. The maximum number of streams allowed by Cisco Internet CDN Software is 2500.

Step 4   In the Maximum amount of bandwidth (bits/second) to serve concurrently field, enter a value representing the amount of available network bandwidth, in bits per second, that each device can use to serve client requests.

For example, if you wanted to allocate 10 megabits per second for each Content Engine, you would enter:

10000000

 

Or, to allocate unlimited bandwidth, you would enter:

0 


Step 5   Click Save. The settings used by Windows Media Services to stream content will be updated on all affected CDN devices. Content Engines in hosted domains on which Windows Media Services have been activated will restart following the change.


Viewing Content Engines Running Windows Media Services

Cisco Internet CDN Software automatically tracks the number and identity of Content Engines on which Windows Media Services have been activated.


Note   Activating or deactivating Windows Media Services on a hosted domain affects all Content Engines on that domain. In addition, adding a Content Engine that has not had Windows Media Services activated to a hosted domain on which Windows Media Services have been activated will result in Windows Media Services automatically being activated on the newly added Content Engine.

To view the Content Engines on which Windows Media Services have been activated:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Windows Media Server Configuration.

The Windows Media Services Configuration page appears. (See Figure 4-4.)

Step 3   Do one of the following:

  • To view the number of Content Engines on your CDN on which Windows Media Services have been activated, refer to the Number of Content Engines with WMT activated field. This is a read-only field that is updated periodically by Cisco Internet CDN Software.

  • To view which Content Engines on your CDN have had Windows Media Services activated, click the notepad icon labeled View Content Engines with WMT activated. A separate window opens, listing the names of Content Engines running Windows Media Services.


Modifying RealServer Configuration

Cisco Internet CDN Software supports RealServer for delivering static and live streamed content to users.


Note   Although the Activate RealServer option is enabled by default on the Content Distribution Manager, in order to use RealServer with your CDN, you must first obtain a valid license from RealNetworks.

Using the Content Distribution Manager RealServer Configuration page, you can make changes to a number of RealServer settings remotely, or disable RealServer altogether.


Note   For detailed instructions on managing your RealServer, refer to the RealNetworks documentation that came with your RealServer software, or visit the RealNetworks web page at http://www.realnetworks.com to access the RealServer documentation online.

Activating and Deactivating RealServer

To modify your RealServer configuration:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Real Server Configuration.

The Real Server Configuration page appears. (See Figure 4-5.)


Figure 4-5: RealServer Configuration


Step 3   Check or uncheck the Activate Real Server box. When checked, this option instructs the CDN to serve RealMedia content using the RealServer installed on the serving Content Engine, as well as any other content types mapped to RealServer in the manifest file for each hosted domain.


Note   Clicking Reset at any time before saving restores RealServer to its last configuration.

Step 4   Click Save to save your configuration changes. Any CDN devices with RealServer installed will restart in order to integrate the new configuration change.


Configuring RealServer Multicasting

When enabled, this option enables the RealServer multicasting feature on your network, enabling Cisco Internet CDN installations to conserve bandwidth by sending a single media stream to multiple clients, rather than streaming media to each requesting client individually.

When enabled, multicasting streams content between the RealServer and clients while maintaining a simultaneous accounting control channel between each client and the RealServer. This extra control channel is used to transmit authentication information as well as client commands like "start" and "stop." RealServer multicasting allows you to track client behavior and display statistics during viewing, including real-time data on the number of clients receiving a presentation. Data collected can be reviewed and analyzed using the Java Monitor or RealSystem Administrator. See the "Modifying the RealServer Java Monitor Configuration" section for more information on the Java Monitor.

Once enabled, multicasting is applied to all streams broadcast from your RealServer. Clients that have been preconfigured to use multicasting do so, maximizing the bandwidth available to multicasting and unicasting clients alike.

Although you typically use the built-in administrative features of RealServer to configure multicasting, it is possible to enable multicasting remotely from your Content Distribution Manager user interface using the Real Server configuration tool.

To modify your RealServer multicasting settings:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Real Server Configuration.

The Real Server Configuration Tool page appears. (See Figure 4-5.)

Step 3   To enable multicasting, check the Enable Multicast check box. Additional configuration options appear.

Step 4   Enter the base address of the address range to which you will be sending multicast streams in the Address Base field.

RealServer uses the first available address in the range you specify. Refer to the "Calculating Addresses for Back-Channel Multicasts" section in the RealServer Version 8 Administration Guide for more information on determining the number of required addresses for multicasting.

Step 5   Enter the value by which multicast addresses will be incremented in the Address Step field.

For example, if the base address is 240.3.0.0 and the address step is 32, then the first multicast address used is 240.3.0.0, and the second address used is 240.3.0.32.

Step 6   Set the maximum distance that streamed packets can travel over a network, as measured in hops from one multicast-enabled router to another, by entering a Time To Live value in the TTL field provided.

Each time a multicast data packet passes through a multicast-enabled router, its Time To Live value is decreased by 1. Once the value reaches 0, the RealServer discards the packet.

For typical networks, a Time To Live value of 16 is adequate to keep packets within the network.


Note   Clicking Reset at any time before saving restores RealServer to its last configuration.

Step 7   Click Save to save your RealServer configuration changes. Any CDN devices with RealServer installed restart to integrate the new multicasting configuration change.


Configuring RealServer Live Splitting

Cisco Internet CDN Software supports splitting of live streams, enabling live broadcasts to be forwarded from an origin RealServer (referred to as a transmitter) to one or more receiver RealServers.

Splitting makes it possible to replicate streams to locations close to requesting clients, improving the response time for client requests and the quality of the streamed broadcast, while also making it possible to serve a larger number of clients.

Before taking advantage of the live splitting feature, you must configure your transmitting RealServer properly.

The following changes must be made to your RealServer transmitting server configuration:

For example, a manifest file would read:

    <server name="transmitting-server">
    
    <host name= "10.89.1.1:2040"/>
    
    </server>
    
     
    
If no port is defined after the host name, the default port is used as the listen port.

  • The Security Type parameter must be set to None.

Refer to "Chapter 12: Splitting Live Presentations" in the RealServer Administration Guide for instructions on setting live stream security as well as configuring your transmitting server for pull splitting. The RealServer Administration Guide is available online at the following URL:

http://service.real.com/help/library/guides/server8/realsrvr.htm

See the "<host />" section for instructions on modifying your manifest file to include the nondefault listen port on the transmitting RealServer.

Configuring RealServer Distributed Licensing

The RealServer distributed licensing feature enables you to purchase a single license to be used by multiple RealServers on your network that share a pool of streams.

The RealServers that share a license are called a license group. Each license group consists of a coordinating RealServer, referred to as the publisher RealServer, on which the license file is placed, and cooperating RealServers, referred to as subscriber RealServers, that are configured to look for the publisher RealServer and determine whether there are streams available for use under the license.

It is also possible to configure a secondary publisher RealServer if no connections are available for your primary publisher.

For more information on distributed licensing, refer to the "Distributed Licensing" section in the RealServer Version 8 Administration Guide

To modify your Real Server configuration and enable distributed licensing:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Real Server Configuration.

The Real Server Configuration Tool page appears. (See Figure 4-5.)

Step 3   Check the Enable Distributed Licensing check box. Options for configuring distributed licensing appear.

Step 4   Under the Distributed Licensing URL heading, enter the URL that points to the license file on the publisher RealServer.

Step 5   Under the Primary Publisher heading, enter the IP address of the publisher RealServer in the IP field and the admin port number for the subscriber RealServer in the Port field.

Step 6   If you are deploying a backup publisher RealServer that can be contacted if connections to the primary publisher server are not available, repeat Step 5 for the fields under the Secondary Publisher heading; otherwise, proceed to Step 7.

Step 7   Under the Authorization heading, in the appropriate fields, enter the username and password required to access the publisher RealServer.


Note   Clicking Reset at any time before saving restores RealServer to its last configuration.

Step 8   Click Save to save your configuration changes. Any CDN devices with RealServer installed will restart to integrate the new license distribution change.


Modifying the RealServer Java Monitor Configuration

RealServer comes supplied with a real-time monitor that displays activity on your RealServer. You can use the Java Monitor to:

You can also create other external Java Monitors if you need to track more than one RealServer or monitor multiple RealServers side by side.

To configure the RealServer Java Monitor:


Step 1   From the Content Distribution Manager user interface, click tools.

Step 2   From the drop-down list, choose Real Server Configuration.

The Real Server Configuration Tool page appears. (See Figure 4-5.)

Step 3   To enable the Java Monitor, check the Enable Java Monitor check box.

Before using the RealServer Java Monitor, you must specify the port number that the monitor will use when connecting to your RealServer and, optionally, a password that can be used to access the monitor. The default value for the port is 9090.

Step 4   If necessary, in the Port field, change the default port number to the port your RealServer is using.

Step 5   If necessary, in the Password field, enter a new password for accessing the Java Monitor. Although it is not encrypted, this field does not display the password value once it has been saved, reading invalid instead.


Note   Clicking Reset at any time before saving restores RealServer and the Java Monitor to their last configuration.

Step 6   Click Save to change your settings to the Java Monitor configuration. Any CDN devices with RealServer installed restart to integrate the new configuration change.


Modifying QuickTime Server Configuration

Your Cisco Internet CDN Content Distribution Manager and Content Engines come with the Apple Computer Darwin Streaming Server already installed. This server is used to stream QuickTime-format media to users.

By default, your Content Distribution Manager has the Darwin Streaming Server enabled. If you do not wish the Darwin Streaming Server to be enabled on your CDN, use the QuickTime Configuration page to disable this playserver.

To configure your QuickTime server:


Step 1   From the Content Distribution Manager user interface, click tools.

Step 2   From the drop-down list, choose QuickTime Configuration. The QuickTime Configuration page appears.

Step 3   To disable your QuickTime server, uncheck the Activate QuickTime check box. QuickTime content will not be served from your CDN, or will be served by the playserver specified in the manifest of each of your hosted domains.

Step 4   Click Save to change your QuickTime configuration. Any CDN devices with the QuickTime Darwin Streaming Server installed will restart to integrate the new configuration change.


Modifying Routing Properties

Cisco Internet CDN Software allows you to modify a number of configuration settings that affect content routing on the CDN, including the deployment of coverage zones used in static content routing.

For a detailed discussion of CDN content routing, see the "Routing End User Requests to Content Engines" section.


Note   Configure your Domain Name System (DNS) server before making any changes to the routing properties. Refer to the "Configuring DNS" section in Chapter 2 of the Cisco Internet CDN Software Configuration Guide.

Modifying Dynamic Routing Properties

Most requests for CDN content are handled using dynamic routing, as described in the "Routing a Request" section. Using the routing properties feature, available from the Tools area of the Content Distribution Manager, you can adjust a number of configuration properties that affect the routing behavior of your Content Routers and Content Engines.

To modify dynamic routing properties on your CDN:


Step 1   From the Content Distribution Manager user interface, click tools.

Step 2   From the drop-down list, choose Routing Properties. The Routing Properties page appears.

Step 3   Modify any of the Time to Live (TTL) or name server (NS) configuration settings to match your organization's needs. See Table 4-1 for explanations of the various dynamic routing configuration settings.

Step 4   Click Save. A message appears, indicating that the dynamic routing settings have been modified.

Step 5   Click OK. You are returned to the Routing Properties page.



Table 4-1: Dynamic Routing Properties
Routing Property Description

Time To Live (TTL) of a glue A record associated with NS records naming supernodes

Read only. This field shows the duration, in seconds, of the Content Engine address records contained in the name server records returned to the DNS proxy from the Content Router.

Time To Live (TTL) of NS records naming supernodes, if all supernodes are in preferred locations

This field affects the TTL of the name server records for supernodes returned to the DNS proxy by the Content Router when all supernodes are in preferred locations.

Time To Live (TTL) of NS records naming supernodes, if some supernodes are not in preferred locations

This field affects the TTL of the name server records for supernodes returned to the DNS proxy by the Content Router when some supernodes named are not in preferred locations.

Time To Live (TTL) of A records identifying Content Engines

This field affects the life span, in seconds, of the A(ddress) record returned by a Content Engine identifying the Content Engine content IP address or the virtual IP address of a Content Engine cluster.

Minimum number of NS records

This field affects the minimum number of NS records that the Content Router returns for any request, unless there are fewer supernodes and standalone Content Engines on the CDN than the minimum number.

Target number of NS records if any are in preferred locations

This field affects the number of name server records that the Content Router returns for any request in which some devices are in preferred locations.

The Content Router will not select additional name server records to meet the target if that would require returning records from nonpreferred locations.

Target number of NS records if none are in preferred locations

This field affects the number of name server records that the Content Router returns for any request in which no devices are in preferred locations.

Force NS records to identify two different locations

This field, when enabled, forces the Content Router to select supernodes or standalone Content Engines from two locations in any response to the DNS proxy.



Configuring Static Routing

Coverage zones allow Cisco Internet CDN Software to select the most appropriate device for serving each user request, even in unusual network configurations in which requesting DNS proxies are not located near the clients they are serving. Using a separate coverage zone file maintained by the content provider, DNS proxies requiring static routing are named, and preferred locations are specified for handling requests from known client addresses or address ranges.

For more information on the role coverage zones in CDN routing, see the "Static Routing" section.


Note   Static routing works only if all Content Routers on the CDN and all Content Engines that might be called on to serve content using static routing are running Cisco Internet CDN Software Version 2.1 or later.

Using the routing properties feature of the Content Distribution Manager, you identify the location of your coverage zone file, which is fetched by each Content Engine and Content Router on your CDN. In addition, you can set a number of configuration parameters governing routing, such as Time to Live (TTL) values for the address (A) and name server (NS) records, and the number of NS records returned from the Content Router to the DNS proxy for requests handled using both standard and hybrid routing.

To modify static routing properties on your CDN:


Step 1   From the Content Distribution Manager user interface, click tools.

Step 2   From the drop-down list, choose Routing Properties. The Routing Properties page appears.

Step 3   If you have not already done so, enter the full URL of the coverage zone file in the field provided. The coverage zone file must be placed in a location that is accessible to all Content Engines and Content Routers on the CDN.

Step 4   Modify any of the Time to Live (TTL) or name server (NS) configuration settings to match your organization's needs. See Table 4-2 for explanations of the various static routing configuration settings.

Step 5   Click Save. A message appears, indicating that the static routing settings have been modified.

Step 6   Click OK. You are returned to the Routing Properties page.



Table 4-2: Static Routing Properties
Routing Property Description

Time To Live (TTL) of a glue A record associated with NS records naming supernodes

Read only. This field shows the life span, in seconds, of the Content Engine address records contained in the name server records returned to the DNS proxy from the Content Router.

Time To Live (TTL) of NS records naming supernodes, if some supernodes are not in preferred locations

This field affects the life span, in seconds, of the name server records for supernodes returned to the DNS proxy by the Content Router when the client address uses static routing.

Time To Live (TTL) of A records identifying Content Engines

This field affects the life span, in seconds, of the A(ddress) record returned by a Content Engine identifying the Content Engine content IP address or the virtual IP address of the Content Engine cluster.

Number of NS records to return when DNS client is in coverage zone

This field affects the number of name server records that the Content Router returns if the requesting client's IP address is in the range defined for a coverage zone.

URL of the coverage zone file

This is the full web address of the file specifying coverage zone information for the CDN. This file typically resides on a server maintained by the content provider, but must be accessible to all Content Engines and Content Routers on the CDN.



Sample Coverage Zone File

Coverage zone files can be created using any ASCII text editing tool. A single coverage zone text-format file defines all the coverage zones for a CDN.

Coverage zones are defined in the file by lists of DNS proxies from which requests are to be handled using static routing, and lists matching client addresses (or address ranges) with recommended locations on the CDN for handling requests from those clients.

When creating a coverage zone file, make sure that the following are true:

For example, the following could be a coverage zone file:

CZ1
#One or more DNS Proxies 
DNS 10.89.11.1
#Addresses or address ranges mapped to CDN best locations
network 10.89.0.0/12	Waltham
 
#One or more DNS Proxies 
DNS 10.89.11.1 10.89.50.113 
#Addresses or address ranges mapped to CDN best locations
network 10.89.13.20/32	Plymouth; Boxborough "North Adams"
 

Setting Up Remote Logging

Each Content Engine logs the following information locally:

  • HTTP requests that the device processes
  • RealServer activity

  • QuickTime server activity

You can specify that these log files be periodically deposited (in compressed form) on an FTP site. You can then use this information for billing content providers.


Note   Make sure that the FTP server is set to accept only ACTIVE-mode sessions from clients before configuring remote logging on the Content Distribution Manager. Only ACTIVE-mode transfers of the CDN logs will work.

If you choose not to enable remote logging, log files are stored locally for a time on the Content Engine but are eventually removed from the device to make room for more recent log files. Each Content Engine stores approximately 100 to 150 MB of archived log files. Log files are removed from the Content Engine based upon their age, with the oldest log files being deleted first.

To specify that Content Engines deposit log information about HTTP requests, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Remote Logging.

The Remote Logging page appears. (See Figure 4-6.) The status of the Remote Logging feature appears at the top of the page. Verify that the status is disabled before proceeding.


Figure 4-6: Remote Logging


Step 3   In the Host Name field, enter the DNS name or the IP address of the remote FTP site where you want the Content Engine usage information logs to be deposited. For example, enter:

ftp.mydomain.com

 

Step 4   In the Log Files Storage Path field, enter the path on the remote FTP server where you want the log files deposited. For example, enter:

/cenglog/path

 

Step 5   In the Update Interval field, enter the frequency (in hours) that the system checks for log files on the selected device to be transferred to the remote FTP server. If log files are not available for transfer, no action is taken.

Step 6   In the Size Limit field, enter the maximum allowed size for log files transferred to the remote server. Log files that are larger than the maximum allowed size are not transported to the remote FTP server, so be sure to use a conservative estimate when supplying this ceiling.

Step 7   In the Username and Password fields, enter a username and a password to access the remote FTP server.

Step 8   Click Start to begin remote logging on the selected device. Once you have started remote logging, clicking Stop cancels it.


Secure Transfer of Internet CDN Software Log Files

Cisco Internet CDN Software supports the secure transfer of log files from CDN devices to a remote logging server. This feature prevents outsiders from "sniffing," intercepting, and gaining access to the information in CDN log files as they are being transferred between Content Engines on your CDN and your designated remote logging server.

Encrypted log files have a GPG extension on your remote logging server, for example:

192.168.3.24~access.log.1~20010628082504.cdn.gpg
 

You need to have the Gnu Privacy Guard (GPG) software installed on your remote logging server in order to decrypt the CDN log files once they are received. GPG is freely available as shareware on the Internet. Refer to the Gnu Privacy Guard web page at:

http://www.gnupg.org

To specify that Content Engines deposit log information about HTTP requests in a secure, encrypted format, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose System Configuration.

The System Configuration page appears.

Step 3   Locate the enableLogFileEncryption option in the left-hand column.

Step 4   In the middle column, enter true in the field provided. This enables the secure log file transfer feature.

Step 5   Locate the LogFileEncryptionKey option in the left-hand column.

Step 6   In the middle column, enter an alphanumeric encryption password in the field provided.

This password is used to encrypt outgoing log files and then decrypt the same files once they have been received on the remote logging FTP server. You must enter a value in this field in order for the encryption to take place.

Step 7   Click Save. The Secure log file transfer option is enabled on all Content Engines on your CDN.

See "Setting Up Remote Logging" section for more information on configuring your Content Engines to transfer CDN log files to a remote server.


Understanding Remote Logging Output

Once it is enabled, remote logging occurs from the selected device to the designated remote FTP server at the intervals you specified in the preceding section. Remote logging generates a compressed access log file with a filename in the following format:

IP address~access.logfiletype.lognumber.timestampMilliseconds.cdn.gz
 

where:

Log files are migrated a minimum of once per calendar day. In addition, log files are migrated to the remote logging server automatically when the log file size reaches 10 MB, or when the Content Engine is restarted for any reason.

In addition to the main compressed file containing access data, a second and corresponding log file is also placed on the remote host server. This file, which has an *.ok extension and the same filename as the compressed file to which it belongs, verifies that the compressed log file was transferred successfully from CDN device to the remote host server. For example:

IP address~access.logfiletype.log number.timestampMilliseconds.cdn.gz.ok
 

If no *.ok file was created for the compressed log file archive you transferred to the remote server, the log file archive may not have been properly uploaded to the server. Repeat the instructions in the "Setting Up Remote Logging" section.

SQuID Cache Log File Format

The SQuID cache log tracks the origin of HTTP requests to a given Content Engine, as well as the time of arrival of the request and how the Content Engine disposed of the request.

In response to any request for content, the Content Engine either:

  • Serves content directly from its own cache, if that content is present

  • Forwards the request on to the origin server to fulfill, if the requested content is not present in the Content Engine cache

SQuID cache log files use the following naming convention:

IP address~access.log.log number.timestampMilliseconds.cdn.gz

Each log is compressed with the UNIX gzip archiver, and must be decompressed before it can be read. SQuID cache log files contain an entry for each content item requested in the following format:

[TIME in sec].[TIME microsec] [milliseconds] [client ip] [REQUEST 
status] / [HTTP_CODE] [SIZE] [HTTP_METHOD] [HTTP_URL] [CACHE_IDENT]/ 
[HIER_HOST] / [CONTENT_TYPE] 
 

For example:

985794537.211    499 10.89.0.203 TCP_MISS/200 5538 GET 
http://good.niagara.sightpath.com/images/homepage/smb-jobs-npm.gif - 
DIRECT/www.cisco.com image/gif
 
985796546.734      1 10.89.1.190 TCP_MEM_HIT/200 4553 GET 
http://good.niagara.sightpath.com/images/guest_navbar.gif - NONE/- 
image/gif
 

Descriptions of the log record components follow.

SQuID Cache Log Record Component Description

TIME in sec.TIME in microseconds

Time of day at which the logged event occurred, recorded in seconds and microseconds.

Milliseconds

Length of time, in milliseconds, that the SQuID cache spent processing the request.

Client IP

IP address of the requesting client.

Request Status

Label indicating whether or not the TCP request found its target content. Possible values when requests do find content are:

When requests do not find content, the value is TCP_MISS.

HTTP Code

HTTP status code for the requested item. Possible values are:

Size

Size of the requested content item, in bytes.

HTTP Method

Action requested for the requested content item. The value is GET.

HTTP URL

URL followed to request the content item. This identifies a valid CDN hosted domain and can be used for billing purposes to differentiate among different Content Provider services.

CACHE_IDENT

Filename of the requested content item.

HIER_HOST

Indicates whether or not the request was moved up the CDN hierarchy to the origin server. Possible values are:

  • DIRECT—Indicates that there was a TCP miss and that the content was fetched from the origin server rather than served from the Content Engine cache.

  • NONE—Indicates that there was a TCP hit, and that the content was served directly from the Content Engine cache.

CONTENT_TYPE

Content MIME type specified in the HTTP response Content-type header, for example:

text/html
 

When no content type is specified, this field is left blank.



QuickTime Server Log File Format

In addition to the SQuID cache log, Content Engines running the Apple Computer Darwin Streaming Server for QuickTime generate and migrate separate log files detailing Darwin Server activity on the device.

As with all other log files, Darwin Server logs are migrated a minimum of once per calendar day and are automatically migrated to the remote logging server when the log file size reaches 10 MB, or when the Content Engine is restarted.

Darwin Streaming Server access log files use the following naming convention:

IP address~access.StreamingServerlog.log number.timestampMilliseconds.cdn.gz
 

Darwin Server log files generated on the Content Engine follow the access log format, documented in the supporting materials for Darwin Streaming Server 2.

This document is available online at:

http://www.publicsource.apple.com/projects/streaming/StreamingServerHelp/

Descriptions of the purpose of these and other logging configuration elements can also be found in the online help for the Darwin Streaming Server, available on the Internet at:

http://www.publicsource.apple.com/projects/streaming/StreamingServerHelp/

RealServer Log File Format

In addition to the SQuID cache log, Content Engines running RealServer will generate and migrate separate log files detailing RealServer activity. As with all other log files, RealServer logs will be migrated a minimum of one time per calendar day, and will automatically be migrated to the remote logging server when the log file size reaches 10 MB, or when the Content Engine is restarted.

RealServer access log files use the following naming convention:

IP address~access.rmlog.log number.timestampMilliseconds.cdn.gz

RealServer log files generated on the Content Engine follow the RealServer Access Log format, documented in the chapter "Reporting RealServer Activity" in the RealServer Administration Guide for RealServer Version 8.0. This document is available online at:

http://service.real.com/help/library/guides/server8/realsrvr.htm

When generating RealServer log files, Internet CDN Content Engines use the following logging configuration settings:

Logging Configuration Element Description
LoggingStyle

This setting determines how much data about media clips is gathered in the RealServer access log. The default setting used by Content Engines is 5.

StatsMask

This setting determines how much data about requesting clients is gathered in the access log. The default setting used by Content Engines is 3.



Descriptions of the purpose of these and other logging configuration elements can also be found in the RealServer Administration Guide.

Windows Media Technologies Log File Format

As with all other log files, Windows Media Server logs are migrated a minimum of once per calendar day and are automatically migrated to the remote logging server when the log file size reaches 10 MB, or when the Content Engine running Windows Media Server is restarted.

Windows Media Technologies log files use the following naming convention:

mms_export.YYMMDD.###

 

where ### represents a sequential number for that day.

The following is a list of fields that appear in the Windows Media Technologies log file used with Cisco Internet CDN Software. Descriptions are provided for each field.

Field Description

audiocodec

Audio codec used in stream.

avgbandwidth

Average bandwidth (in bits per second) at which the client was connected to the server.

c-buffercount

Number of times the client buffered data while playing the stream.

c-bytes

Number of bytes received by the client from the server. For a unicast, c-bytes and sc-bytes must be identical. If not, packet loss has occurred.

c-cpu

Client computer CPU type.

c-dns

Client computer Domain Name Server name.

c-hostexe

Host application, for example, a web page in a browser (Iexplore.exe) or a Microsoft Visual Basic applet (Vb.exe) or standalone Microsoft Windows Media Player (Mplayer2.exe).

c-hostexever

Host application version number.

c-ip

Client computer IP address. A client that is not connected properly provides a client proxy server IP address, not the client IP address.

c-os

Client computer operating system.

c-osversion

Client computer operating system version number.

c-pkts-lost-client

Number of packets lost during transmission from server to client and not recovered at the client layer through error correction or at the network layer through User Datagram Protocol (UDP) resends.

c-pkts-lost-cont-net

Maximum number of continuously lost packets on the network layer during transmission from server to client.

c-pkts-lost-net

Number of packets lost on the network layer. Packets lost at the network layer can be recovered if the client re-creates them through forward error correction. The difference between c-pkts-lost-net and c-pkts-lost-client is c-pkts-recovered-ECC.

c-pkts-received

Number of packets from the server (s-pkts-sent) that are received correctly by the client on the first try.

c-pkts-recovered-ECC

Number of packets repaired and recovered on the client layer. Packets repaired and recovered at the client layer are equal to the difference between c-pkts-lost-net and c-pkts-lost-client.

c-pkts-recovered-resent

Number of packets recovered because they were resent through UDP.

c-playerid

Globally unique identifier (GUID) of the player.

c-playerlanguage

Client language-country code.

c-playerversion

Version number of the player.

c-quality

Percentage of packets that were received by the client, indicating the quality of the stream. If cPacketsRendered is all packets received by the client including packets recovered by error correction and UDP resend (c-pkts-received + c-pkts-recovered-ECC + c-pkts-recovered-resent) then c-quality can be calculated as:

[cPacketsRendered / (cPacketsRendered + c-pkts-lost-client)] * 100

c-rate

Mode of Windows Media Player when the last command event was sent.

c-resendreqs

Number of client requests to receive new packets. This field contains a value only if the client is using UDP resend.

c-starttime

Time stamp (in seconds) of the stream when an entry is generated in the log file.

c-status

Codes that describe client status, mapped to HTTP/1.1 and RTSP client status codes described in Request for Comments (RFC) 2068 and RFC 2326.

Windows Media Services includes the extensible client status codes 480 (simultaneous client connections exceeded the maximum client limit of the server) and 483 (stream exceeded maximum file bit rate limit of the server).

c-totalbuffertime

Time (in seconds) that the client used to buffer the stream. If the client buffers the stream more than once before a log entry is generated, c-totalbuffertime is the total amount of time that the client spent buffering the stream.

channelURL

URL to the .nsc file. A unicast client information log file records a "-" (hyphen) for this field.

cs(Referer)

URL to the web page in which Windows Media Player was embedded (if it was embedded).

cs-uri-stem

Name of the file that is playing: an .asf file for a unicast or an .asx file for a multicast.

cs(User-Agent)

Browser type used if Windows Media Player was embedded in a browser, Mozilla/4.0_(compatible;_MSIE_4.01;_
Windows_98) date, date (in Greenwich Mean Time) when an entry is generated in the log file.

filelength

Length of the file (in seconds). This value is 0 for a live stream.

filesize

Size of the file (in bytes). This value is 0 for a live stream.

protocol

Protocol used to access the stream: MMS, HTTP, or ASFM (multicast protocol).

s-cpu-util

Average load on the server processor (0%-100%). If multiple processors exist, this value is the average for all processors.

s-dns

Server DNS.

s-ip

Server IP address.

s-pkts-sent

Packets sent by the server.



Updating Cisco Internet CDN Software

From the Software Update page, you can:

  • Determine the current version of Cisco Internet CDN Software
  • Import software updates from remote locations, such as Cisco.com

  • Update Cisco Internet CDN Software on the devices you specify

  • Delete obsolete software updates


    Note   Contact your Cisco sales representative for information about obtaining the latest software upgrades.

Determining the Current Software Version

The Software Update page shows the current version of Cisco Internet CDN Software that you are using.

To determine the current Cisco Internet CDN Software version:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Software Update. The Software Update page appears. (See Figure 4-7.)


Figure 4-7: Software Update Page


Step 3   Click the tab corresponding to the type of device for which you wish to check the software version. The screen refreshes, listing the selected type of devices on your CDN.

Step 4   Locate the device and refer to the Version column for the device, where the number of the software version being used by the device is displayed.


Note   The Version column is not updated until a software update has been successfully completed. If a software update is in progress, the Version column displays the base version, not the update version number.


Adding a New Update File

Before you can update your Cisco Internet CDN Software, you must first acquire the appropriate software update file from Cisco.

In order to acquire the software update from Cisco, you must first:

  • Access the Cisco.com website and locate the software update files.

  • Download the software update files to a web server within your own organization or copy the location (URL) for the files (see the "Adding a New Update File Directly from Cisco.com" section).

  • Add the update to the CDN by copying the URL for the update files (pointing either to your web server or Cisco.com) to the Content Distribution Manager.

  • Use the software update feature to import the update file pointed to by the link.

You must have a Cisco.com username and password before attempting to download a software update from Cisco.com. In order to acquire a Cisco.com login, go to http://www.cisco.com and click the Register link.


Note   You need a service contract number, Cisco.com registration number and verification key, Partner Initiated Customer Access (PICA) registration number and verification key, or packaged service registration number in order to obtain a Cisco.com username and password.

To add an update file for the Cisco Internet CDN Software:


Step 1   Launch your preferred web browser and point it to:

http://www.cisco.com/pcgi-bin/tablebuild.pl/cdn-sp  

 

Step 2   If prompted, log in to Cisco.com using your designated username and password.

The Cisco Internet CDN Software download page appears, listing the available software updates for the Cisco Internet CDN Software product.


Note   Each software update consists of two files: a binary-format update file (*.upg) and a smaller meta file (*.meta). Both files must be downloaded in order to successfully complete a Cisco Internet CDN Software update.

Step 3   Locate the files you wish to download by referring to the Release column for the proper release version of the software.

Step 4   Click the link for the software update file you wish to download. The order in which you download the update files does not matter. The Software License Agreement page appears.

Step 5   After you have read the license agreement, click the Yes link at the bottom of the agreement to go to the software download page.

Step 6   Click the Site 1 (San Jose, CA) link. You are prompted to open the file or save it to your local hard drive.

Step 7   Click Save to file and then choose a location on your workstation to temporarily store the update file.

Step 8   Post the file you downloaded (*.meta or *.upg) to a designated area on your organization's web server and make note of the URL required to access this file. You will need it later.


Note   It is imperative that the upgrade (*.upg) file be placed in the same directory as its corresponding meta file, or in a location that is relative to the location of the meta file.

Step 9   Repeat Step 3 through Step 8 for the other software update file.

Step 10   Launch the Cisco Internet CDN Software Content Distribution Manager and log in using an administrative username and password.

Step 11   Click tools.

Step 12   From the drop-down list, choose Software Update.

The Software Update page appears listing available software updates. (See Figure 4-7.) If there is currently no update available, a message appears.

Step 13   Click Add New Update File.

A page appears with a field for entering the URL of your software update.

Step 14   Paste the URL for the update meta file on your web server into the field provided. For example, a valid URL might look like this:

http://internal.mysite.com/cdn/internet-CDN-version.meta
 

where internet-CDN-version is the version number of the software update.


Note   Do not attempt to link directly to the UPG file. The relative location of the update file is provided by the meta file.

Step 15   Click OK.

The version and URL for the update file appear, for example:

1.0.3 http://internal.mysite.com/cdnsw.upg
 

Adding a New Update File Directly from Cisco.com

It is also possible to add a software update to the CDN directly from Cisco.com, rather than posting it on a web server within your organization first.

To add the software update directly from Cisco.com:


Step 1   Launch your preferred web browser and point it to:

http://www.cisco.com/pcgi-bin/tablebuild.pl/cdn-sp  

 

Step 2   If prompted, log in to Cisco.com using your designated username and password.

The Cisco Internet CDN Software (Cisco CDN Service Provider Software) download page appears, listing the available software updates for the Cisco Internet CDN Software product. Note that each software update consists of two files: a binary-format upgrade file (*.upg) and a smaller meta file (*.meta).

Locate the software update you wish to install by consulting the Release column for the proper release version of the software.

Step 3   Click the link for the meta (*.meta) file. The Software License Agreement page appears.

Step 4   After you have read the license agreement, click the Yes link at the bottom of the agreement to go to the software download page.

Step 5   Right-click Site 1 (San Jose, CA) and copy the URL by selecting the Copy Shortcut (Internet Explorer) or Copy Link Location (Netscape) option from the shortcut menu that appears.

Step 6   Point your browser to the address of your Cisco Internet CDN Software Content Distribution Manager and log in using an administrative username and password.

Step 7   Click tools.

Step 8   From the drop-down list, choose Software Update.

Step 9   The Software Update page appears (see Figure 4-7), listing available software updates. If there is currently no update available, a message appears.

Step 10   Click Add New Update File.

A page appears for specifying the URL for the update location.

Step 11   Paste the URL for the update meta file on your web server into the field provided. The URL should begin with:

http://www.cisco.com/pcgi-bin/Software/Tablebuild/download.cgi/  
 

If the URL does not begin with http://www.cisco.com, return to Step 5 and verify that you copied the link from Site 1 (San Jose, CA).

Step 12   Click OK.

The version and URL for the update file appear, for example:

1.0.3 http://internal.mysite.com/cdnsw.upg
 

Updating the Software on a Content Engine or Content Router

You can update software on your devices as needed using the software update feature. When upgrading, begin with Content Engines and Content Routers before upgrading the Content Distribution Manager.

The Content Distribution Manager reboots at the conclusion of the upgrade procedure, causing you to temporarily lose contact with the device and the graphical user interface.

Once the Content Distribution Manager has updated its software and rebooted, it may be unable to communicate with devices running different versions of the Cisco Internet CDN Software.


Note   Although Version 2.1 of Cisco Internet CDN Software supports CDNs in which some nodes are running earlier (2.0.x) CDN software releases, if you have deployed a failover Content Distribution Manager and supernodes on the same CDN, it is necessary to update the software on all Content Engines in your supernodes so that those supernodes will continue to communicate with the failover Content Distribution Manager.

To update the Cisco Internet CDN Software on your devices, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Software Update.

The Software Update page appears. (See Figure 4-7.)

Step 3   If there are multiple updates listed, click the radio button next to the available update file you want to use. Otherwise, proceed to the next step.

Step 4   Click the tab corresponding to the type of device that you want to upgrade, for example, Content Routers. The window refreshes, listing the devices of the selected type on your CDN.


Note   Always update Content Engines and Content Routers before the associated Content Distribution Manager.

Step 5   Refer to the column labeled Version to verify that the devices you are choosing are not already running the version you wish to upgrade to, or that the current version has an upgrade path to the version that you will upgrade to.


Note   If you have questions regarding upgrade paths, contact Cisco Technical Support.

Step 6   Check the check boxes next to the name of the device you will be upgrading, or check the box in the column header to choose all devices.

Step 7   Click OK. The selected devices begin the update process and go offline temporarily.

Step 8   Repeat Step 4 through Step 7 for each device that you wish to upgrade.

Step 9   Click the Refresh button to see the status of your upgrade. When devices come back online, they will be recognized by the Content Distribution Manager.

Step 10   For information on the status of software updates on devices across your CDN, see the "Viewing System Event Logs" section.


Your CDN is now restored, and you are ready to begin serving user requests using the updated Cisco Internet CDN Software.

Updating the Software on a Warm Standby Content Distribution Manager

Unlike other CDN devices, a warm standby Content Distribution Manager must be upgraded manually using the command-line interface. Before upgrading the warm standby Content Distribution Manager, you must have first acquired the Cisco Internet CDN Software upgrade file from Cisco.com. See the "Adding a New Update File" section for information on downloading a software update.

To update the Cisco Internet CDN Software on a warm standby Content Distribution Manager:


Step 1   Log in to the warm standby device using the admin account and password.

Step 2   At the prompt, enter enable to enable the administrative mode.

> enable

 

The prompt changes to a pound sign (#) to indicate that you are in administrative mode.

Step 3   Enter ftp to launch the file transfer application.

The prompt changes to indicate that you are in FTP mode.

Step 4   Enter the open command followed by the DNS name or IP address of the host machine containing the software upgrade package, for example:

ftp> open 10.89.11.1

 

You may need to log in separately to the host machine.

Step 5   Enter bin to switch to binary transfer mode.

Step 6   Enter the cd command followed by the remote path of the upgrade file, for example:

ftp> cd /upgrade

 

The directory changes to the location that you specified.

Step 7   Enter the get command followed by the name of the upgrade file, MERLOT.upg:

ftp> get MERLOT.upg

 

Step 8   Enter the quit command to close the file transfer application.

Step 9   Enter upgrade swupgrade to initiate the software update on the warm standby Content Distribution Manager:

# upgrade swupgrade

 

The warm standby Content Distribution Manager automatically restarts following the software update.


Updating the Software on a Content Services Switch

Each software update file contains an updated Content Services Switch (CSS) configuration script that provides your Content Services Switch with network configuration information such as IP address, gateway address, uplink address, and VLAN information if you are deploying VLANs.

Periodically this script is updated along with Cisco Internet CDN Software, providing new configuration options for your Content Services Switches.

Using the Content Distribution Manager user interface, you can upload the CSS configuration script from the Content Distribution Manager to any Content Services Switch on your CDN. This saves you the trouble of having to manually upload the CSS script to the Content Services Switch, a process that is detailed in the "Preparing the Content Services Switch and Uploading the Script" section in Chapter 3 of the Cisco Internet CDN Software Configuration Guide.

Once you have uploaded the configuration script to a Content Services Switch, refer to the "Configuring the Content Services Switch" section in Chapter 3 of the Cisco Internet CDN Software Configuration Guide.

To upload an updated configuration script to a Content Services Switch:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Content Services Switch. The Content Services Switch page appears. (See Figure 4-8.)


Figure 4-8: Content Services Switch


Step 3   In the IP Address field, enter the network address of the Content Services Switch to which you wish to upload the updated configuration script.

Step 4   In the Password field, enter the admin account password.

Step 5   In the Re-type Password field, reenter the admin account password.

Step 6   Click the Save button to initiate transfer of the configuration script to the Content Services Switch you specified.

Step 7   Repeat Step 2 through Step 6 for each Content Services Switch to which you wish to upload the updated script.


Canceling a Software Update

You can cancel a software update before it has begun using the software update feature.

Canceling a software update removes the update software request from the Content Distribution Manager.

If a device has already received the update request and started the software update, that update process will continue regardless of the cancellation request. Once the device has completed the software update, it will report its status to the Content Distribution Manager as if no cancellation request had been issued.

Contact Cisco Technical Support for instructions on restoring an earlier version of the Cisco Internet CDN Software on a CDN device.

To cancel a software update:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose Software Update. The Software Update page appears. (See Figure 4-7.)

Step 3   Click the tab corresponding to the type of device for which you wish to cancel the software update. The screen refreshes, listing the selected type of devices on your CDN.

Step 4   Locate the device or devices for which the software update is scheduled. These have an update status of pending.

Step 5   Check the check box next to the device or devices on which you wish to cancel the software update.

Step 6   Click the Clear button. You are prompted to confirm your decision to cancel the software update.

Step 7   Click OK to proceed or Cancel to terminate the clear software update request and resume the software update on the selected devices.

Step 8   Repeat Step 3 through Step 7 for each type of device (Content Router, Content Engines, or Content Distribution Manager) on which you wish to cancel a software update.


Deleting an Update File

To delete a Cisco Internet CDN Software update file, follow these steps:


Step 1   On the Software Update page (see Figure 4-7), if there are multiple updates to choose from, click the button next to the update file that you want to delete. Otherwise, proceed to the next step.

Step 2   Click Delete Update File. You are prompted to confirm your decision to delete the software update file.

Step 3   Click OK. You are returned to the Software Update page with the selected software update removed from the CDN.


Modifying System Properties

You may need to modify one or more of the configuration settings used by a device, or even by your entire CDN—disabling a playserver, for example, or changing one of the runtime settings used by a particular server or device.

Using the System Configuration page (see Figure 4-9), available from the Tools area of the Content Distribution Manager user interface, you can modify a wide variety of system properties.


Figure 4-9: System Configuration


Changes made using the System Configuration page cause any CDN devices affected by those changes to restart once the change has been saved. Depending on the number and location of affected devices that restart, you may experience a temporary interruption in your CDN after using the System Configuration page, as affected devices restart to integrate configuration changes.


Note   Modifying system properties using the System Configuration page can adversely affect your network. Use the System Configuration page only under the direct supervision of a Cisco Technical Assistance Center representative.

Modifying the System Timeout Value

Access to the Content Distribution Manager web interface is secured, in part, using an automatic timeout feature that terminates open connections to the Content Distribution Manager after a set period of inactivity.

The Content Distribution Manager resets its timeout counter each time the Content Distribution Manager web interface is refreshed—following a save or cancel operation or the transition to a new screen.

Using the system configuration feature, available from the Tools area of the Content Distribution Manager, you can modify the length of time that the Content Distribution Manager will wait before terminating idle sessions.

To modify the Content Distribution Manager session timeout:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the System Tools drop-down list, choose System Configuration.

The System Configuration page appears. (See Figure 4-9.)

Step 3   Locate the cdm.session.timeout option.

Step 4   In the field provided, set the timeout value in milliseconds. For example, if you want the Content Distribution Manager to terminate sessions that are idle for more than 10 minutes, you would enter the following value in the CDN Session Timeout field:

600000000

 

Step 5   Click Save. The screen refreshes, displaying the new timeout value in the box beneath the cdm.session.timeout option.


Enabling and Disabling Telnet

The Cisco Internet CDN includes both SSH and Telnet software, which allow administrators to connect and issue commands to CDN devices remotely. The ability to remotely connect to your CDN devices is an integral part of maintenance and troubleshooting activities.

Because the information sent back and forth to CDN devices using SSH is encrypted, we recommend using SSH for all remote interaction with CDN devices.

If your organization does not use SSH or an SSH client is unavailable, you can use Telnet to communicate with your CDN devices. By default, all Cisco Internet CDN Version 2.1 devices have Telnet disabled.

To enable or disable Telnet on a CDN device:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the System Tools drop-down list, choose Simple Peek.

Step 3   Click the tab corresponding to the type of device for which you wish to enable Telnet.

Step 4   From the list of devices that appears, click the icon next to the name of the device you wish to edit.

Step 5   If you are prompted, click Yes to proceed and then enter your administrative login information a second time. A second browser window opens with the System Tools dialog box displayed.

Step 6   From the Features drop-down list, choose Enable Telnet or Disable Telnet, and then click Go. A message is displayed, indicating that the Telnet feature has been enabled or disabled.

Step 7   Close the System Tools dialog box and return to the Simple Peek page.

Step 8   Repeat Step 3 through Step 7 for each device on which you wish to enable or disable Telnet.


Setting the Maximum Cachable Object Size

Using the system configuration feature, you can adjust the maximum size of content items that can be cached by SQuID, the UNIX-based program that Cisco Internet CDN Software uses to store content on a proxy server close to requesting clients on the CDN.

By default, Cisco Internet CDN Software sets the maximum size of objects to 512000 kilobytes. However, it is possible to set the maximum cache size lower than this.

To modify the maximum cachable object size:


Step 1   From the Cisco Internet CDN Software user interface, click tools.

Step 2   From the drop-down list, choose System Configuration.

The System Configuration page appears, listing the system configuration properties that have been added for your CDN.

Step 3   Click the Add Property button. The Modify Properties page appears.

Step 4   Click the Catalogs tab. A list of CDN properties appears.

Step 5   Click the button next to the ServerConfig.squid.maxCacheableObjSize property. You can only add one system configuration property at a time.

Step 6   Click the Add button. The Modify Properties page refreshes, listing the name of the property in the Name field.

Step 7   In the Value field, enter a maximum object size, in kilobytes. The acceptable size range is between 4096 and 512000 kilobytes.

Step 8   Click the CE check box, indicating that this configuration option should be applied only to the Content Engines (CEs) on your CDN.


Note   Applying a configuration option to a device that does not use that option does not affect the performance of the affected device—unu