Cisco ACNS Software Upgrade and Maintenance Guide, Release 5.x
Chapter1: Introduction to Upgrading Your ACNS Software
Downloads: This chapterpdf (PDF - 329.0KB) The complete bookPDF (PDF - 2.88MB) | Feedback

Introduction to Upgrading Your ACNS Software

Table Of Contents

Introduction to Upgrading Your ACNS Software

Before Upgrading Your Software

Upgrade, Downgrade, and Interoperability Considerations

Upgrade Options

Downgrade Options

Interoperability Requirements

ACNS 5.5 Software Feature Interoperability Issues

Protocol Support for Windows Media Streaming Has Changed

MMS Configurations are Removed on Upgrade

Multicast Station NSC Reference URL Configurations in a Mixed Network

Using Mixed Versions of Windows Media Server

Windows Media Managed Live Programs

Windows Media Services Streaming Media Acquisition

WCCP Transparent Redirection for MMS

Using Windows Media Encoder or Mixed Versions of Windows Media Player

Migrating from MMS-Based Streaming to HTTP- or RTSP-Based Streaming with ACNS 5.5 Software

Windows Media Services License Key Interoperability Issues

Content Distribution Manager Interoperability Issues

ACNS 5.4 Software Feature Interoperability Issues

Content Distribution Managers

Cookie Support for Content Acquisition

Websense Issues When Upgrading to ACNS 5.4.x Software

Websense Issues When Downgrading From ACNS 5.4.x Software

ACNS 5.3 Software Feature Interoperability Issues

Invalid Custom Log Format Strings

SmartFilter Plug-In Versions

Eliminated Upgrade and Downgrade Paths

ACNS 5.2 Software Feature Interoperability Issues

Incompatible Configuration File Formats

Multicast File Transfers

SMB File Acquisition

Software Driver Support and the TV Output Feature

ACNS 5.1 Software Feature Interoperability Issues

Content Distribution

Multicast Clouds

ACNS 5.0 Software Feature Interoperability Issues

Media File System Issues When Downgrading to ACNS 5.0 Software

Websense Issues When Downgrading to ACNS 5.0 Software or ACNS 5.1 Software

ACNS 4.x Software and ACNS 5.x Software Feature Interoperability Issues

ACNS 5.x Software to ACNS 4.2.x Software Downgrade Issues


Introduction to Upgrading Your ACNS Software


This chapter describes general network behavior during a software upgrade and describes specific issues regarding the interoperability of different software releases. This chapter contains the following sections:

Before Upgrading Your Software

Upgrade, Downgrade, and Interoperability Considerations

ACNS 5.5 Software Feature Interoperability Issues

ACNS 5.4 Software Feature Interoperability Issues

ACNS 5.3 Software Feature Interoperability Issues

ACNS 5.2 Software Feature Interoperability Issues

ACNS 5.1 Software Feature Interoperability Issues

ACNS 5.0 Software Feature Interoperability Issues

ACNS 4.x Software and ACNS 5.x Software Feature Interoperability Issues

Before Upgrading Your Software

Before you upgrade your software, read this chapter for information about any important upgrade or downgrade issues that you might encounter. Next, locate the chapter for the software release that you are currently using. For example, if you are using ACNS 5.2 software and you want to upgrade to ACNS 5.3 software, see ""Upgrading Software from the ACNS 5.2 Software Release."

For standalone devices, you must perform the software upgrade using the CLI, and the devices are upgraded one at a time. Follow the upgrade or downgrade instructions for standalone devices in "Upgrading Software for Standalone Content Engines."

For centrally managed ACNS networks, you can upgrade software for single devices or for multiple devices that belong to device groups. You can use the Content Distribution Manager GUI or the device CLI to perform the software upgrade. If you are using the Content Distribution Manager GUI, locate the chapter for the software release that is currently running on your Content Distribution Manager. The procedures in each chapter match the GUI interface for that software release. The GUI periodically changes from one release to the next, which is why you want to use the procedures that correspond to the ACNS release running on your Content Distribution Manager.

Upgrade, Downgrade, and Interoperability Considerations

In general, an ACNS network will be upgraded gradually, so that your network might consist of nodes with different software versions for some time. You can expect the following behavior during an upgrade or downgrade of your network:

The ACNS network continues to operate with mixed versions up to one major or minor version difference in a deployed solution.

New features that depend on device cooperation might not be fully functional until the ACNS network upgrade is complete, but no existing features will be affected.

While being upgraded, a node will be unavailable for a short time.

All nodes, other than the node being upgraded, continue to operate at full capacity. The availability of other nodes is not affected during an upgrade.

Content is preserved during an upgrade or downgrade unless you remove channels or you use the disk and acquisition-distribution database cleanup EXEC commands.

All logs are preserved during an upgrade or downgrade, unless you change the disk configuration. Any time disk space is reconfigured, the logs are automatically removed.


Note The CE-511 and CE-566 Content Engines only support ACNS 5.2 software or later; they do not support ACNS 5.1 or earlier releases of ACNS software.


We strongly recommend that you upgrade your ACNS network devices in the following order:

1. Multicast sender Content Engines

2. Multicast receiver Content Engines

3. Non-root Content Engines

4. Root Content Engines

5. Content Routers

6. Standby Content Distribution Managers (Upgrade before primary when using the GUI only.)

7. Primary Content Distribution Manager


Note When you upgrade Content Distribution Managers using the CLI, we recommend that you upgrade your primary Content Distribution Manager first, and then upgrade your standby Content Distribution Manager. (See the "Upgrading the ACNS 5.1 Content Distribution Manager" section.)

Primary and standby Content Distribution Managers must be operating with exactly the same software release as each other for failover to be successful.


Upgrade Options

The following ACNS software release upgrades can be performed:

Any ACNS 5.1.x, ACNS 5.2.x, ACNS 5.3.x release to any ACNS 5.4.x release.

Any ACNS 4.2.x release (except ACNS 4.2.1) to any ACNS 5.x.x release (except ACNS 5.4.x).

Any ACNS 5.x.x release to any ACNS 5.x.x release, with the following exception:

Direct upgrade from ACNS 5.0.x to ACNS 5.4.x is not allowed.

From ACNS 5.0.x software, first upgrade to ACNS 5.1.x, ACNS 5.2.x, or ACNS 5.3.x before you upgrade to ACNS 5.4.x.


Note When you upgrade a Content Engine from any ACNS release to ACNS 5.1.9 or a later release of ACNS 5.1 software or 5.2.1 or a later release of ACNS 5.2 software, all cached RealMedia content is deleted from the Content Engine mediafs cache. This situation occurs because the meta file formats have been changed in these releases, affecting the way that the cached RealMedia streaming file is interpreted.


Downgrade Options

The following ACNS software release downgrades can be performed:

ACNS 5.x.x release (except ACNS 5.4.x) to ACNS 4.2.x release.

After the downgrade, ACNS 5.x.x features will not work.

Any content acquired by the ACNS 5.x.x Content Engine will be lost after the downgrade.

ACNS 5.1 release to ACNS 5.0.3 release.

After the downgrade, ACNS 5.1-specific features will not work (for example, NTLM authentication).

MMS content acquired by the ACNS 5.1 Content Engine remains and can be served by the Content Engine after the downgrade; however, the ACNS 5.0.3 Content Engine cannot reacquire MMS content.

The mediafs disk space will need to be reconfigured after the downgrade.

ACNS 5.1 release to ACNS 5.0.1 release (not recommended).

This downgrade requires that the management database tables be manually re-created using the CLI.

The mediafs disk space will need to be reconfigured after the downgrade.

ACNS 5.2 release to any ACNS 5.1 or ACNS 5.0 release.

Any ACNS 5.x.x release to any ACNS 5.x.x release, with the following exception:

Direct downgrade from ACNS 5.4.x to ACNS 5.0.x is not allowed.

From ACNS 5.4 software, first downgrade to ACNS 5.1.x, ACNS 5.2.x, or ACNS 5.3.x before you downgrade to ACNS 5.0.x or earlier.

Interoperability Requirements

Devices must follow these upgrade requirements for proper interoperability:

Devices in an ACNS network cannot differ by more than one major or minor software release.

The Content Distribution Manager must be operating with the same or lower software release as its managed devices.

Primary and standby Content Distribution Managers must be operating with exactly the same software release as each other.

ACNS 4.x devices do not interoperate with ACNS 5.x devices.

ACNS 5.5 Software Feature Interoperability Issues

This section describes ACNS 5.5 software feature interoperability issues.

Protocol Support for Windows Media Streaming Has Changed

ACNS 5.5 software no longer supports the MMS protocol for acquiring or distributing Windows Media content between servers. If you are using MMS-based streaming, you must migrate to RTSP-based streaming or HTTP-based streaming before you upgrade to the ACNS 5.5 software release. (See the "Migrating from MMS-Based Streaming to HTTP- or RTSP-Based Streaming with ACNS 5.5 Software" section.)

MMS Configurations are Removed on Upgrade

Because the MMS protocol is no longer supported in ACNS 5.5.1 or later releases, command options in the Content Engine CLI and Content Distribution Manager GUI that configure the MMS protocol have been removed. If you have these command options configured in an earlier ACNS release, and then you upgrade to ACNS 5.5.1 or later, the MMS configurations are removed. If you downgrade to an earlier release, the MMS configurations are not restored.

You must plan to save your configurations before you upgrade your software to ACNS 5.5.x, if you want to restore MMS configurations after a downgrade.

The Content Distribution Manager automatically creates a database backup file, which you can find in the CLI root directory with a filename similar to the following:

cms-db-03-13-2006-08-30.dump

The filename contains the date and time that the backup was made. In the example, 03-13-2006 is the date and 8:30 is the time that this data was saved. We recommend that you export a copy of the database backup file before you upgrade your Content Distribution Manager or Content Engines to ACNS 5.5 software.


Note For a complete list of commands that have been changed or removed in the ACNS 5.5.1 software release, see the Release Notes for Cisco ACNS Software, Release 5.5.1 document.


Multicast Station NSC Reference URL Configurations in a Mixed Network

If you are using a Content Distribution Manager that is running a release prior to ACNS 5.5 (such as ACNS 5.3.x or ACNS 5.4.x) and you are using it to manage Content Engines that are running ACNS 5.5 software, the Content Distribution Manager does not recognize the nsc-reference option of the wmt multicast station-configuration global configuration command. This option is new to the ACNS 5.5.1 release.

If you configure an ACNS 5.5 Content Engine using the wmt multicast station-configuration command without configuring the nsc-reference option, the configuration can be successfully managed by the Content Distribution Manager.

If you configure an ACNS 5.5 Content Engine using the wmt multicast station-configuration command and the nsc-reference option, the configuration is not recognized by the Content Distribution Manager.

If you configured an ACNS 5.5 Content Engine using the wmt multicast station-configuration command without configuring the nsc-reference option, and later you attempt to modify the configuration by adding an NSC reference URL for this station from the Content Engine CLI, the lower version Content Distribution Manager removes the multicast station during the next management system update.

Using Mixed Versions of Windows Media Server

Windows Media Server prior to Version 9.x does not support RTSP, so you cannot use an RTSP source URL with older versions of Windows Media Server. If you have Windows Media Servers in your ACNS network that do not support RTSP, you must use HTTP as the source URL for Windows Media streaming.

Windows Media Managed Live Programs

In ACNS releases prior to ACNS 5.5, MMST was the protocol used for communications between Content Engines for managed live programs. In the ACNS 5.5 release, the protocol for communication between Content Engines has changed to RTSPT. If you are using ACNS 5.5 software on some Content Engines and are using earlier versions of software on other Content Engines in your network, Windows Media managed live programs will fail because the ACNS 5.5 Content Engine will not be able to communicate with ACNS 5.4 or 5.3 Content Engines. If you are migrating to ACNS 5.5 software, you must upgrade all the Content Engines in the Windows Media live channel to ACNS 5.5 software for successful delivery of managed live programs.

HTTP unicast delivery (Unicast in-Unicast out) to the client is not supported for managed live streaming; only RTSP URLs are supported. In the Live Source URL field in the Content Distribution Manager GUI (Services > Video > Programs > Live Streaming), you can have an HTTP or RTSP URL, but in the Unicast URL Reference field and in the Customized URL field only RTSP URLs are allowed.

If MMS is configured in the Live Streaming window (Services > Video > Programs > Live Streaming) before the upgrade, the configuration remains the same after the upgrade to ACNS 5.5 software; however, you cannot modify the source URLs in this window without changing the protocol from MMS to one of the supported protocols in ACNS 5.5 software.

The Content Distribution Manager GUI returns an error message if you try to modify the settings in this window when the MMS protocol is included from a previous release.

Windows Media Services Streaming Media Acquisition

In prior releases, ACNS software supported Content Engine acquisition of Windows Media streaming content. In ACNS 5.5 software, the Content Engine cannot acquire and pre-position Windows Media streaming content.

If an MMS URL is specified as the source URL for a content item in the Channel Content window (Services > Web > Channels > Channel Content) before the upgrade, the configuration remains the same after the upgrade to ACNS 5.5 software; however, you cannot modify the content items in this window until you change the protocol of the URL from MMS to one of the supported protocols in ACNS 5.5 software.

The Content Distribution Manager GUI returns an error message if you try to modify the settings in this window when the MMS protocol is included from a previous release.

WCCP Transparent Redirection for MMS

In the ACNS 5.5 release, WCCP Service 81 and Service 82 for MMS redirection are still valid. If your network is set up for WCCP redirection for MMS, and an MMS request is redirected to the Content Engine, the Content Engine accepts the request and immediately closes the connection. This operation forces the Windows Media client to rollover to HTTP for the request. We recommend that you explicitly reconfigure your MMS settings to RTSP.

Using Windows Media Encoder or Mixed Versions of Windows Media Player

HTTP is supported for communications between Windows Media Player and the Windows Media Encoder or between a Content Engine and the Windows Media Player; however, it is not supported for communications between Content Engines.

HTTP is the only mode of data delivery supported by Windows Media Encoders. RTSP is not supported by Windows Media Encoders. ACNS software supports live streams that have Windows Media Encoders as their source. Support for HTTP allows Content Engines to communicate with the Windows Media Encoder.

If Windows Media Player Version 9, or a later version, issues an explicit mmst:// or mmsu:// URL request, the ACNS 5.5 software sends an error message and will not play the stream. If a request contains an mms:// URL, the player uses RTSP or HTTP instead.

When connecting to a publishing point using the MMS protocol, a rollover method is used to obtain the best connection. When a URL in Windows Media Player Version 9, or a later release, specifies an MMS URL (mms://), the Windows Media Player attempts to use the following protocols for media delivery, in the order shown:

1. RTSPU (RTSP using UDP)

2. RTSPT (RTSP using TCP)

3. HTTP

4. MMSU (MMS using UDP)

5. MMST (MMS using TCP)


Note If you have different versions of Windows Media Player in your network, you should configure HTTP proxy in all versions of Windows Media Player to allow Windows Media streaming over HTTP, which is supported across all versions of software.


Migrating from MMS-Based Streaming to HTTP- or RTSP-Based Streaming with ACNS 5.5 Software

Before you upgrade your software to the ACNS 5.5 release, follow these steps:


Step 1 If MMS outgoing proxy is enabled in your Content Engine, change the configuration to RTSP outgoing proxy or HTTP outgoing proxy by using one of the following commands:

wmt proxy outgoing http host {hostname | ipaddress} port

wmt proxy outgoing rtsp host {hostname | ipaddress} port

Also change the Windows Media default port from 1755 to either 554 (RTSP) or to some other port.

Step 2 If you are using Windows Media Player Version 9, or a later version, you must change your publishing point URLs to use either RTSP or HTTP instead of MMS.

For example, if you have configured an on-demand publishing point for the file sample.asf using a URL similar to the following:

mms://Server/sample.asf

Change your URL to this:

rtsp://Server/sample.asf

or this:

http://Server/sample.asf

Step 3 Change all Windows Media broadcast alias URLs from MMS to RTSP or HTTP.

Step 4 Change all Windows Media multicast station URLs from MMS to RTSP or HTTP.

Step 5 If your Windows Media Player is configured for MMS proxy, change the configuration from MMS to RTSP for Windows Media Version 9 and newer players or HTTP for older versions of Windows Media Player.

Step 6 If you have WCCP enabled, you might need to configure RTSP transparent interception.

Step 7 The URLs in your playlists are converted from MMS to HTTP during the upgrade. If you have been using a port other than port 80 to stream the content referenced in the playlist, you must update each playlist reference to include the actual port number.

For example, if you streamed the file welcome2.asf over port 8008 in ACNS 5.4 or an earlier release, and your URL looked like this:

mms://server/welcome2.asf

When streaming over the same port in Windows Media version 9, your URL must look like this:

http://server:8008/welcome2.asf



Caution After you upgrade to ACNS 5.5 software, all MMS settings are erased.

Windows Media Services License Key Interoperability Issues

Licenses purchased for Windows Media Services (WMS) in the ACNS 5.5 software and later releases are not supported in ACNS 5.4.x software or earlier releases. However, a Content Distribution Manager running ACNS 5.4 software can configure licenses for both ACNS 5.4 and ACNS 5.5 devices.

One caveat is that an ACNS 5.4 Content Distribution Manager cannot correctly validate ACNS 5.5 license keys. Because the license keys in ACNS 5.5 software are new, they are not recognized by earlier software versions. When you attempt to run a validation check on an ACNS 5.5 WMS license key from the ACNS 5.4 Content Distribution Manager GUI, you will receive an error message stating that you have entered the key incorrectly. (License key validation is optional in the Content Distribution Manager GUI.) (See Table 1-1.)

Table 1-1 Content Distribution Manager Interoperability Matrix

Content Distribution Manager Software
ACNS 5.4 WMS Licenses
ACNS 5.5 WMS Licenses
Later ACNS 5.5.x Licenses
ACNS 5.4

Configure

Yes

Yes

Yes

 

Validate

Yes

No

No

ACNS 5.5

Configure

Yes

Yes

Yes

 

Validate

No

Yes

Yes


You should not attempt to validate ACNS 5.5 license keys with an ACNS 5.4 Content Distribution Manager. You, however, can submit the license key and successfully configure the WMS license for the ACNS 5.5 release from an ACNS 5.4 Content Distribution Manager. To verify that WMT is enabled on a Content Engine in this situation, use the show wmt EXEC command.

If you attempt to configure an ACNS 5.5 (or later release) WMS license key on an appliance that is running ACNS 5.4 software or an earlier release, the license key will fail, and Windows Media Services will not be enabled on that appliance. This failure is logged and can be viewed from Devices > Device Monitoring > Logs in the Content Distribution Manager GUI.

If you have a mixture of ACNS 5.4 and ACNS 5.5 devices in your network and you want to configure licenses by device groups, we recommend that you group devices in the Content Distribution Manager separately by software release in order to avoid an issue with license incompatibility.


Note When you upgrade from ACNS 5.4 to ACNS 5.5 software, any WMS license keys that you configured in ACNS 5.4 will continue to be valid after the upgrade.


Content Distribution Manager Interoperability Issues

A Content Distribution Manager running ACNS 5.4 software can provide a centralized interface for configuring and managing ACNS networks in which some or all of the Content Engines are running ACNS 5.5 software.

A Content Distribution Manager running ACNS 5.5 software can provide a centralized interface for configuring and managing ACNS networks in which all of the Content Engines are running ACNS 5.5 software only. (See Table 1-2.)

Table 1-2 Content Distribution Manager Interoperability Matrix

Content Distribution Manager Software
ACNS 5.4.x Appliances
ACNS 5.5.1 Appliances
Later ACNS 5.5.x Appliances

ACNS 5.4

Yes

Yes

Yes

ACNS 5.5

No

Yes

Yes


If you are migrating your network to the ACNS 5.5 release, observe the following requirements:

Ensure that your Content Distribution Manager is running a version of ACNS 5.4 software.

Always upgrade your Content Engines and Content Routers to ACNS 5.5 before you upgrade the Content Distribution Manager to ACNS 5.5.

Always upgrade your Content Distribution Manager to ACNS 5.5 last, after all other applicances in your network are using ACNS 5.5 software.

Follow the migration procedure outlined in the "Migrating from MMS-Based Streaming to HTTP- or RTSP-Based Streaming with ACNS 5.5 Software" section.

ACNS 5.4 Software Feature Interoperability Issues

This section describes ACNS 5.4 software interoperability issues.

Content Distribution Managers

A Content Distribution Manager operating with ACNS 5.4 software can manage Content Engines and Content Routers that are using ACNS 5.4 software and later versions only. Content Distribution Managers operating with ACNS 5.1, ACNS 5.2, or ACNS 5.3 software can manage Content Engines and Content Routers that are using ACNS 5.4 software. We recommend that you do not upgrade your Content Distribution Manager to ACNS 5.4 software until all of your managed ACNS devices have been upgraded to the ACNS 5.4 release.

Cookie Support for Content Acquisition

Cookie support for content acquisition is a new feature in ACNS 5.4 software. This feature affects the root Content Engine only. If you configure the manifest file for cookie support, when you downgrade from ACNS 5.4 to an earlier software release, a parse error will be generated for the manifest file enableCookies and authCookie attributes after the downgrade.

Websense Issues When Upgrading to ACNS 5.4.x Software

Cisco ACNS 5.4 software supports Websense Enterprise software Version 5.5 on all Cisco Content Engine platforms.


Note The integrated Websense Enterprise software Version 5.5 in ACNS 5.4 software requires a minimum of 512 MB of RAM. We recommend that you upgrade the RAM on your device to 512 MB or greater, or move your integrated Websense server to another device that has at least 512 MB of RAM.


If you upgrade from the ACNS 5.3.x software to the ACNS 5.4.x software, support for the RADIUS and eDirectory configurations will no longer be provided by the Websense binaries. Consequently, the global configuration commands that were used to configure the RADIUS and eDirectory agents are deprecated in the ACNS 5.4.1 software release.

If you used the CLI to configure the RADIUS and eDirectory agents on a Content Engine that is running ACNS 5.3.x software, and you upgrade from ACNS 5.3.x software to ACNS 5.4.x software, the configuration for the RADIUS and eDirectory agents that were stored in the wsradius.ini and wsedire.init files will be saved. However, any configuration changes that are made to the RADIUS and eDirectory agents through the Websense GUI Manager will not be reflected in these two .ini files.


Note The CLI commands that are used to activate the RADIUS and eDirectory agents (the websense-server service radius-agent activate and websense-server service edirectory-agent activate global configuration commands) and to specify the eDirectory administrative password (the websense-server service edirectory-agent edir-server administrative-passwd password global configuration command) have been retained in the ACNS 5.4.x software.


If you are upgrading from the ACNS 5.2.x software to the ACNS 5.4.x software, you do not have to make any changes to the previous Websense configuration because the RADIUS and eDirectory Agents were not supported in the ACNS 5.2.x software release.

Websense Issues When Downgrading From ACNS 5.4.x Software

If you downgrade from ACNS 5.4.x software to ACNS 5.3. software, the local WebsenseEnterprise directory and other related Websense files are removed. All previously existing internal configuration files used by Websense are deleted, and all changes that were made before the downgrade are lost.

The following error message is displayed to notify you about this Websense downgrade issue:

WARNING:
Websense does not support downgrade
Hence removing /local/local1/WebsenseEnterprise
Websense will stop working after copy ftp install


Note In previous releases, the software did not generate an error message indicating that the WebsenseEnterprise directory had been removed. For more information, see the "Websense Issues When Downgrading to ACNS 5.0 Software or ACNS 5.1 Software" section.


When the Content Engine reloads after the downgrade, Websense is reinstalled, and the internal configuration files are created afresh. If Content Engine Websense server configurations (such as websense-server service policy local activate, websense-server service eim activate, and so forth) are stored in the startup-config file before the downgrade, they will be reinitiated.

ACNS 5.3 Software Feature Interoperability Issues

This section describes ACNS 5.3 software interoperability issues.

Invalid Custom Log Format Strings

In ACNS 5.3 software and later releases, invalid custom log format strings cannot be configured. However, releases of ACNS software prior to Release 5.3 allow you to configure invalid custom log format strings. When you upgrade ACNS devices from ACNS 5.2 software to ACNS 5.3 software, any invalid custom log formats that were configured are deleted.

SmartFilter Plug-In Versions

When you upgrade or downgrade your Content Engine to a different release of ACNS software, if there is a difference in the SmartFilter plug-in version, the SmartFilter database and configuration files are deleted and default configurations are loaded. This change occurs because the configuration details might be changed with each new version of SmartFilter software. After each upgrade or downgrade of the SmartFilter plug-in, a new database must be downloaded from the SmartFilter Administration Console to the Content Engine.

Eliminated Upgrade and Downgrade Paths

In the ACNS 5.3.1 software release, the following upgrade and downgrade paths were eliminated:

Upgrading from the ACNS 4.2 software to the ACNS 5.3 software

Downgrading from the ACNS 5.3 software to the ACNS 4.2 software

ACNS 5.2 Software Feature Interoperability Issues

This section describes ACNS 5.2 software interoperability issues.

Incompatible Configuration File Formats

ACNS software contains default TIBCOSmartPGM FX configuration files for multicast sender and receiver Content Engines. The multicast sender and receiver Content Engines determine which medium (terrestrial or satellite) is being used for the multicast by checking the configuration of the multicast cloud. The Content Engines then read the configuration parameter values from the PGM configuration file that corresponds to the medium being used for the multicast.

ACNS 5.2 software uses the following default TIBCOSmartPGM FX configuration files:

fxd.conf.src

fxd.conf.rcv

In ACNS 5.1 and ACNS 5.0 software, default PGM and FX multicast configuration parameters are saved in two sets of files: FX parameters are saved in one set, and PGM parameters are saved in another. The default filenames are as follows:

fxd.conf.src

fxd.conf.rcv

pgmfx.conf.src

pgmfx.conf.rcv


Note Configuration file formats are not compatible between ACNS 5.2 software (and later releases) and ACNS 5.1 or 5.0 software. When you upgrade from ACNS 5.1 or 5.0 software to ACNS 5.2 software, your customized ACNS 5.1 and 5.0 configuration files in the /local1/multicast-expert-config/ directory are renamed with "_3" appended. When you downgrade from ACNS 5.3 software or a later release to ACNS 5.1 or 5.0 software, the ACNS 5.2 configuration files are renamed with "_4" appended. You must manually recreate your customized configuration files after upgrading or downgrading from ACNS 5.2 software or later releases.


The Content Engine stores sample copies of the default TIBCOSmartPGM FX configuration files in the /local1/multicast-expert-config/ directory for reference. You can modify one of these sample configuration files, rename it, and save it back to the multicast sender or receiver Content Engine. When you create customized configuration files and copy them to the /local1/multicast-expert-config/ directory using the default configuration filenames, the Content Engine uses the customized configuration file instead of the default configuration file. The customized configuration file becomes effective after the Content Engine is restarted.

Content Engines running ACNS 5.2 software contain the following sample configuration files:

fxdSatellite.conf.src.sample—Use for a sender Content Engine in a satellite network.

fxdSatellite.conf.rcv.sample—Use for a receiver Content Engine in a satellite network.

fxdTerra.conf.src.sample—Use for a sender Content Engine in a terrestrial network.

fxdTerra.conf.rcv.sample—Use for a receiver Content Engine in a terrestrial network.

Content Engines running ACNS 5.1 and ACNS 5.0 software contain the following sample configuration files:

pgmfxSatellite.conf.src.sample

pgmfxSatellite.conf.rcv.sample

pgmfxTerra.conf.src.sample

pgmfxTerra.conf.rcv.sample

Multicast File Transfers

ACNS 5.2 software supports new multicast file transfer features that enhance the reliability and performance of multicast file distribution in the ACNS 5.2 network. These enhancements impact the interoperability of Content Engines in a mixed network.

In earlier ACNS releases (Release 5.0 and Release 5.1), the file transfer session depended on a period of time to resend the missing packets. The sender had to transmit the packets within this period of time for each retransmission request (NACK) from receiver Content Engines. If a multicast receiver joined the session too late and missed blocks of data that were outside the transmission window, the sender would not resend the missing blocks. The receiver could not receive the entire file, and the transmission failed. The receiver had to wait until a subsequent transmission session (carousel pass) to recover the missed files. The receiver could only receive the entire file or nothing. A slow receiver often failed to receive a large file if the receiving rate lagged behind the sending rate.

The multicast file transfer enhancements in ACNS 5.2 software resolve these issues by eliminating the period of time for file transmissions. This feature is called checkpoint. Checkpoint allows the sender to divide the transferring file into blocks and to retransmit any and all blocks until the transfer session ends. At any time during the transfer session, a receiver can request retransmission of any block that it has missed. Receiver Content Engines also can receive the blocks of a transfer in any order. Data transmission can occur over a longer period, and receivers can recover missed data blocks to successfully complete the transfer in most situations. File transfers are much more resistant to loss of data.

This feature also solves the problem of a multicast receiver joining a transfer session late. In an unlikely situation, even if a receiver joins so late that the sender has multicast nearly all of a very large file, the receiver can still receive the data. The receiver also can request retransmission for all the blocks it has missed. Even if a receiver goes offline and restarts during a transfer, it can recover missing data without requesting retransmission of the blocks it has already received.

Because of these enhancements, receivers using ACNS 5.2 software cannot interact with senders using ACNS 5.0 or 5.1 software. The ACNS 5.2 multicast receiver will ignore files sent from an ACNS 5.0 or 5.1 multicast sender. However, an ACNS 5.2 multicast sender can interoperate with ACNS 5.0 or 5.1 multicast receivers because the software detects the lower software version and disables the checkpoint feature. We recommend that you upgrade your multicast sender to ACNS 5.2 software first, and then upgrade your receivers to ACNS 5.2 software.

SMB File Acquisition

When a root Content Engine is downgraded from ACNS 5.2 software to ACNS 5.1 software, some channels are disabled and some content fails to be acquired. This problem occurs when the manifest file URL is a Server Message Blocks (SMB) URL with a Universal Naming Convention (UNC) path format (for example, \\host\share\file), or when an item or crawl task that is specified in either the src or start-url attribute has a UNC path format.

Because ACNS 5.1 software does not support SMB file acquisition, the root Content Engine running ACNS 5.1 software is not able to fetch the manifest file or acquire content from the SMB shares.

To work around this problem, do the following either before or after you downgrade the root Content Engine from ACNS 5.2 to ACNS 5.1 software:

Remove the SMB URL from the Manifest URL field in the Channel configuration window of Content Distribution Manager GUI and use a URL with supported protocols (HTTP, FTP, or HTTPS).


Note From an ACNS 5.1 Content Distribution Manager GUI, choose Channels > Channels > Edit Channel.
From an ACNS 5.2 Content Distribution Manager GUI, choose Content > Channels > Edit Channel > Channel Content.


Edit the manifest file by removing content items and crawl tasks that have UNC formatted paths.

Initiate channel acquisition and verify that the workaround is successful by using the acquirer start-channel EXEC command.

Software Driver Support and the TV Output Feature

The TV output service supports the local playback of pre-positioned MPEG content through a hardware decoder. The hardware decoder converts the digital information into an analog TV signal. The TV out service is only functional if the Content Engine is equipped with a supported MPEG hardware decoder. To enable the TV output service on a Content Engine that is registered with a Content Distribution Manager, use the tvout enable global configuration command.


Note Pre-positioned content is only supported on registered Content Engines; it is not supported on standalone Content Engines (that is, Content Engines that are not registered with a Content Distribution Manager and are being managed and monitored with the Content Engine GUI or CLI.). Consequently, the TV out service, which involves pre-positioned content, is not supported on standalone Content Engines.


The changes that are related to the TV output service are as follows:

In ACNS 5.2.3 software, the ACNS TV-out functionality now works for the CE-510 and CE-565 models equipped with newer Vela II Revision D and Revision E MPEG hardware decoder cards. (In ACNS 5.2.1 software, this functionality did not work for these cards.)

New driver software was incorporated into ACNS 5.2.3 software. This new driver software supports both the existing Vela II Revision A cards as well as the newer Vela II Revision D and Revision E cards.

In ACNS 5.2.3 software or later, the output of the show hardware EXEC command displays the version of the TV-out hardware that the Content Engine is equipped with. In this sample output from the show hardware command, this particular information is highlighted in bold. The "rev 3" in the command output indicates that the TV-out hardware uses the newer Revision 3 MPEG decoder PCI part. The Vela II Revision D and Revision E cards use the Revision 3 part.

Content Engine # show hardware
.
.
.
Total 1 CPU.
1024 Mbytes of Physical memory.
1 CD ROM drive (CD-224E)
1 AV card (Vela II)
2 GigabitEthernet interfaces
1 Console interface
2 USB interfaces [Not supported in this version of software]

The following PCI cards were found:
PCI-Slot-1 MPEG-Decoder-AV [1105:8476 (Sigma Designs, Inc.) (rev 3)]
PCI-Slot-2 SCSI
Manufactured As: Pre-FCS 565  [867383Z]
.
.
.


Note In order to support the TV out service with a Revision D or Revision E card, the Content Engine must be running the newer driver software, which is included in the ACNS 5.2.3 software, instead of an earlier version of the driver.


In ACNS 5.0.17 software, ACNS 5.1.11 software, or ACNS 5.2.1 software or later, the output of the show hardware EXEC command notifies you if the Content Engine is running a version of the ACNS software that does not support the TV-out hardware contained in the Content Engine. In the following example, you are notified that the Content Engine has a Vela II audio-video (AV) card that is not supported by the version of ACNS software, which is running on the Content Engine. In the following sample output from the show hardware command, this particular information is highlighted in bold:

Content Engine # show hardware
.
CPU 0 is GenuineIntel Intel(R) Celeron(R) CPU 1.70GHz (rev 1) running at 1699MHz
.
Total 1 CPU.
1024 Mbytes of Physical memory.
1 CD ROM drive (CD-224E)
1 AV card (Vela II) [***Revision not supported in this version of software***]
2 GigabitEthernet interfaces
1 Console interface
2 USB interfaces [Not supported in this version of software]

The following PCI cards were found:
.
.
.

In ACNS 5.0.17 software, ACNS 5.1.11 software, or ACNS 5.2.1 software or later, the output of the show tvout EXEC command also notifies you if the Content Engine is running a version of the ACNS software that does not support the TV-out hardware contained in the Content Engine. In the following sample output from the show tvout command, this particular information is highlighted in bold:

Content Engine # show tvout
.
.
.
TV-out model: ce565-002 (sigma)
 [***Hardware revision level not supported in this version of software***]

TV-out service is not enabled
TV-out signal: ntsc

TV-out service is not running
.
.
.

ACNS 5.1 Software Feature Interoperability Issues

This section describes ACNS 5.1 software interoperability issues.

Content Distribution

Content Engines running ACNS 5.0.1, 5.0.3, and 5.1 software acting in various roles, such as root Content Engine, forwarder, receiver, and multicast sender, may interoperate with each other in any combination of basic functionalities that are common to all releases. If a chain of forwarders passes content from a Content Engine running ACNS 5.1 software to a Content Engine running ACNS 5.0 software, and then to another Content Engine running ACNS 5.1 software, the ACNS 5.1 software features are preserved across the chain to the third Content Engine.

For example, if a higher-version forwarder is sending content to a lower-version receiver, the extra database columns are converted to a name-value pair in the metadata field and are transmitted. The lower-version receiver ignores the metadata, but still writes it to the database and passes it on to receivers farther down the chain. If a receiver farther down the chain is running the higher-version software, it picks up the metadata and the functionality along with it.

However, features available to a newer release do not work with other Content Engines that are running older releases. For example, a multicast backup sender (an ACNS Release 5.1 feature) does not work with multicast receivers running ACNS 5.0 software.

The multicast backup sender functions only when the receivers detect that the primary sender is down and send NACKs to trigger a retransmission of the multicast file to the backup sender. If a network has no ACNS 5.1 multicast receivers, even if it does have a multicast backup sender, the backup sender cannot become active.

Similarly, the intelligent carousel feature relies on the multicast receiver to send file requests to the multicast sender. Only receivers that are using ACNS 5.1 software are capable of making such requests. In a mixed network, however, a receiver Content Engine using ACNS 5.0 software can receive the file transmission that was requested by the receiver running ACNS 5.1 software.


Note See also the "Websense Issues When Downgrading to ACNS 5.0 Software or ACNS 5.1 Software" section for another ACNS 5.1 interoperability issue.


Multicast Clouds

ACNS software releases prior to ACNS 5.1.x do not support some of the multicast cloud features introduced in ACNS 5.1.x software and supported in later releases. If you are running mixed versions of ACNS software in your network, you should consider the following additional information regarding multicast sender interoperability:

Condition 1: The ACNS network is set up for multicast distribution with Content Engines subscribed to multicast-enabled channels. Multicast sender and receiver Content Engines are running mixed versions of ACNS software. All Content Engines have been successfully enabled for multicasting. The Content Distribution Manager is running ACNS 5.1.x or a later release of ACNS 5.x software.

Symptom:

Only senders running ACNS 5.1.x or a later release of ACNS 5.x software support failover to a backup sender. Only receivers running ACNS 5.1.x or a later release of ACNS 5.x software can send negative acknowledgements (NACKs).

If both the primary sender and the backup sender are actively sending the same file, the receiver Content Engine locks out one of the two senders and receives one copy of the file from the first sender.


Note Cases 1 through 6 assume that you are using a Content Distribution Manager that is running ACNS 5.1.x or a later release of ACNS 5.x software.


Case 1.1: The primary sender is using an ACNS software release earlier than ACNS 5.1.x. The backup sender is using ACNS 5.1.x or a later release of ACNS 5.x software, as is the receiver.

The backup sender considers the primary sender inactive and becomes active after the configured failover period.

The primary sender periodically sends multicast files as configured in the carousel pass and multicast-out bandwidth settings.

The receiver tries to send a NACK to the primary sender, but receives NACK failures and begins sending NACKs to the backup sender. The backup sender responds to the NACK.

Case 1.2: Both the primary sender and the backup sender are using ACNS 5.1.x or a later release of ACNS 5.x software. The receiver is using an ACNS software release earlier than ACNS 5.1.x.

Failover works between the primary and backup senders, but neither the primary sender nor the backup sender ever receives a NACK response from the receiver.

The primary sender sends out the first carousel pass for content without the need for a NACK, so the receiver might be able to obtain content if it joins the group promptly. If it does not, the receiver is not able to obtain content.

Case 1.3: Both the primary sender and the receiver are using an ACNS software release earlier than ACNS 5.1.x. The backup sender is using ACNS 5.1.x or a later release of ACNS 5.x software.

The backup sender considers the primary sender inactive and becomes active after the configured failover grace period. The backup sender continues to wait for a NACK response from the receiver before sending the multicast, but the receiver is unable to send a NACK.

The primary sender periodically sends multicast files as configured in the carousel pass and multicast-out bandwidth settings.

The receiver should be able to obtain content from the primary sender.

Condition 2: Although you may have received a warning message from the Content Distribution Manager, you can still configure a Content Engine as a backup sender if the Content Engine is registered with a Content Distribution Manager running ACNS 5.1.x or a later release of ACNS 5.x software and the Content Engine is running ACNS software earlier than ACNS 5.1.x. Cases 4 through 6 discuss the backup sender operating under these conditions.

Symptom: The Content Distribution Manager does not send related configuration information and configuration changes to the Content Engine running the earlier software version. This situation results in the Content Engine not being able to identify itself as the multicast backup sender. This scenario might also occur if a backup sender using ACNS 5.1.x or a later release of ACNS 5.x software is downgraded to an earlier software version through the Content Engine CLI.

Case 2.1: Both the primary sender and the backup sender are using an ACNS software release earlier than ACNS 5.1.x. The receiver is running ACNS 5.1.x or a later release of ACNS 5.x software.

The receiver alternately attempts to send NACKs between the primary sender and the backup sender but is unsuccessful.

The primary sender periodically sends multicast files as configured in the carousel and multicast-out bandwidth settings.

Case 2.2: The primary sender and the receiver are using ACNS 5.1.x or a later release of ACNS 5.x software. The backup sender is using an ACNS software release earlier than ACNS 5.1.x.

The primary sender does not recognize the backup sender as being active after the configured failover grace period.

The receiver can successfully send NACKs only to the primary sender. If the primary sender fails, the receiver sends the NACKs to the backup sender, and when it receives a NACK failure as expected, the receiver retries the primary sender. The receiver alternates sending NACKs between the senders until the primary sender becomes active again.

Case 2.3: The primary sender is using ACNS 5.1.x or a later release of ACNS 5.x software. Both the backup sender and the receiver are using an ACNS software release earlier than ACNS 5.1.x.

The primary sender does not recognize the backup sender as being active, and the primary sender becomes active after the configured failover grace period. The primary sender sends the first carousel pass of content without needing to receive a NACK. The primary sender then waits for the receiver's NACK to trigger further carousel passes if more than one carousel pass is configured.

The receiver never sends a NACK to the primary sender or the backup sender.

Condition 3: The Content Distribution Manager is using an ACNS software release earlier than ACNS 5.1.x. In software releases earlier than ACNS 5.1.x, only one sender is configurable for each multicast cloud.

Case 3.1: The sender is using ACNS 5.1.x or a later release of ACNS 5.x software. The receiver is using a software release earlier than ACNS 5.1.x.

The sender operates like a primary sender running ACNS 5.1.x software. That is, it sends the first round of content without requiring a NACK to trigger the carousel pass. However, the sender is unable to continue making carousel passes because the receiver is unable to send NACKs.

Case 3.2: Both the sender and the receiver are using ACNS 5.1.x or a later release of ACNS 5.x software.

The sender can perform carousel passes and the receiver can send NACKs for missing content, however, there is no support for a backup sender or for configuring the NACK interval multiplier.

Case 3.3: The sender is using an ACNS software release earlier than ACNS 5.1.x. The receiver is using ACNS 5.1.x or a later release of ACNS 5.x software.

The sender periodically sends multicast files as configured in the carousel pass and multicast-out bandwidth settings so that the receiver can obtain content.

The receiver tries to send NACKs to the sender but continually fails and retries.

Workaround for Cases 1.1 through 3.3: Upgrade both senders and receivers to ACNS 5.1.x or a later release of ACNS 5.x software. Upgrade the sender first, and then upgrade the receivers.

Workarounds for Case 3.1 only:

Use the distribution multicast resend EXEC command on the sender Content Engine to trigger a multicast carousel pass manually.

Upgrade both senders and receivers to ACNS 5.1.x or a later release of ACNS 5.x software. Upgrade the sender first, and then upgrade the receivers.

ACNS 5.0 Software Feature Interoperability Issues

This section describes ACNS 5.0 software interoperability issues.

Media File System Issues When Downgrading to ACNS 5.0 Software

If you have configured the media file system (mediafs) with ACNS 5.1 software or later, and then downgrade to ACNS 5.0 software, the mediafs disk space assignment is lost and it reverts to ACNS network file system (cdnfs) disk space. (The mediafs is used for on-demand content that is fetched through the two streaming protocols [RTSP and WMT]. The cdnfs is used for pre-positioned content in the ACNS network.)

This situation occurs because of a design change that was implemented in ACNS 5.1 software. Because ACNS 5.0 software is not compatible with this change, the disk space becomes assigned to cdnfs instead of mediafs.

To work around this problem, follow these steps:


Step 1 After you downgrade to ACNS 5.0 software, use the CLI (disk config EXEC command) or the GUI to assign the mediafs disk space.

Use the Content Distribution Manager GUI for Content Engines that are registered with a Content Distribution Manager. Use the Content Engine GUI for standalone Content Engines (that is, Content Engines that are not registered with a Content Distribution Manager and are being managed through the Content Engine GUI or CLI).

Step 2 Reboot the Content Engine for the disk configuration changes to take effect.


Websense Issues When Downgrading to ACNS 5.0 Software or ACNS 5.1 Software

If the local (internal) Websense server is enabled on the Content Engine and you downgrade from the ACNS 5.2.x software to ACNS 5.0 software or ACNS 5.1 software, the Websense Enterprise directory is removed from the Content Engine and the local Websense server stops working. Note that the ACNS 5.2.x software does not generate an error message indicating that the Websense Enterprise directory has been removed.

To avoid this problem when downgrading from ACNS 5.2.x software to ACNS software 5.1 or ACNS 5.0 software, follow these steps:


Step 1 Disable the local (internal) Websense server on the Content Engine.

Step 2 Deactivate the Websense services on the Content Engine.

Step 3 Install the ACNS 5.1 software or ACNS 5.0 software downgrade image on the Content Engine.


ACNS 4.x Software and ACNS 5.x Software Feature Interoperability Issues

Cisco ACNS 5.x software introduces significant changes from the functionality of ACNS 4.2 software. The following changes have been implemented in ACNS 5.x software compared to ACNS 4.2 software:

The Content Distribution Manager no longer stores any content.

Content acquisition and distribution have changed.

The form of the URL used to request content is significantly different.

Routing and redirection are handled differently.

To upgrade from a previous release of ACNS software to ACNS 5.x software, you must be running ACNS 4.2 software or a later version of ACNS 4.x software. If you are running ACNS 4.1.3 or an earlier version of ACNS software, you must first upgrade your software to ACNS 4.2 before you can upgrade to ACNS 5.x software. This ensures that the pre-positioned content is preserved. (See "Migrating from ACNS 4.x Software to ACNS 5.x Software.")

If you are running Cache software or E-CDN software, first upgrade to ACNS 4.2 software and then upgrade to ACNS 5.x software. For these upgrade instructions, refer to the Cisco ACNS Software Maintenance and Troubleshooting Guide that is available online at the following URL:

http://www.cisco.com/en/US/products/sw/conntsw/ps491/prod_maintenance_guides_list.html


Note Upgrading from Internet CDN (ICDN) software to ACNS software is not supported.



Note When upgrading from ACNS 4.2 software to ACNS 5.x software, any ecdnfs file systems are automatically changed to cdnfs file systems. Files are not deleted unless the administrator specifically deletes them.


ACNS 5.x Software to ACNS 4.2.x Software Downgrade Issues

Cisco ACNS 5.x software and ACNS 4.2 software have significant functional differences. When you downgrade from an ACNS 5.x release to an ACNS 4.x release, note the following:

After the downgrade, ACNS 5.x.x features will not work.

Any content acquired by the ACNS 5.x.x Content Engine will be lost after the downgrade.

Use the following files for the downgrade:

ACNS-5.x.x.x.x-TO-4.2.x-K9.bin software file, where x corresponds to the current version.

acns4_cdm_ip.meta

This downgrade meta file registers the device with the ACNS 4.2 Content Distribution Manager and to points to the software (.bin) file for the downgrade.