Guest

Cisco Videoscape Distribution Suite for Internet Streaming

Release Notes for Cisco TV CDS 2.5.6

  • Viewing Options

  • PDF (211.0 KB)
  • Feedback
Release Notes for Cisco TV CDS 2.5.6

Table Of Contents

Release Notes for Cisco TV CDS 2.5.6

Contents

New Features

Enhancements

Supported Environments

System Requirements

Limitations and Restrictions

Open Caveats

CServer

Configuration

FSI

Monitoring

Statsd

Resolved Caveats

CServer

Database

Interoperability

ISA

Reporting

RTSP

SNMP

Upgrading to Release 2.5.6

Upgrading from Release 2.5.2, 2.5.3, 2.5.4, or 2.5.5 to Release 2.5.6

Downgrading from Release 2.5.6

Related Documentation

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco TV CDS 2.5.6


These release notes cover Cisco TV CDS Release 2.5.6.

Revised: May 2012 OL-27171-01

Contents

The following information is in the release notes:

New Features

Enhancements

Supported Environments

System Requirements

Open Caveats

Resolved Caveats

Upgrading to Release 2.5.6

Related Documentation

Obtaining Documentation and Submitting a Service Request

New Features

Release 2.5.6 introduces the Remote Setup and Control Server Support feature, which allows the Setup and Control servers of the Streamers to be placed in a different location than the Play servers of the Streamers. All control traffic (setup and control) goes to one server acting as the Setup and Control servers, and all video data traffic is served from the Streamers designated as the Play servers.

As part of this feature, there is never just one stream transmitted on a single Ethernet interface. There is always at least two active streams transmitted on an interface.


Note The Remote Setup and Control Server Support feature is supported on a Virtual Video Infrastructure (VVI) with split-domain management in an ISA environment and Content Storage configured as either Shared or Distributed. The VOD Error Repair feature is not supported with the Remote Setup and Control Server Support feature.


Remote Setup and Control

The setup and control traffic between the set-top boxes (STBs) and CDS is sent to a location that is separate from the location where the video data streams originate. The Session Traversal Utilities for NAT (STUN) traffic is structured so that it is sent to the Setup server instead of the Play server. The packets used to discover the data path through the end-user's NAT device comply with RFC-5389.

Stream to Interface Relationship

The Remote Setup and Control Server Support feature requires at least two stream requests before sending the first data stream, and makes sure there are at least two data streams on an active Streamer interface at all times. The Control server makes sure there are at least two streams on an active Streamer, and the active Streamer makes sure there are at least two streams on an active stream interface.

The very first session setup request waits for the second session setup request. If the second setup request does not show up with in the configured time interval then the first request times out and fails the session setup, otherwise both of the setup requests are processed in concurrently. If the first play request on a Control server reaches the session timeout period before a second play request is received, the first session fails without allocating the play server.

If there are only two sessions created on the CDS and one session is destroyed or completes, the remaining session is destroyed by setup server.

Global Source Address

The Remote Setup and Control Server Support feature introduces the Global Source Address, which is the IP address (and optional associated port number) that is used by all Play servers for transmitting stream data. The Global Source Address is defined on all Streamers acting as the Play server and the remote server acting as the Setup and Control server.

The Global Source Address is defined in the setupfile on Streamers acting as the Play server and the remote server acting as the Setup and Control server. This address is hosted on the primary Setup server and is managed in a fault-tolerant manner; that is, it moves from interface to interface as needed if an interface fails, and it transitions to a new primary Setup server if the original primary Setup server becomes unreachable.

Each stream interface on the Streamers continues to have a unique IP address so that diagnostic packets (and cache- fill traffic if configured as a stream/cache interface) can be sent and received on those interfaces. However, all stream data packets are sent using the Global Source Address as the source.

The Global Source Address has the following benefits:

Mid-session STUN handshakes are not needed, which eliminates the overhead and associated temporary black-screens that occur on STBs when STUN handshakes happen mid-session.

Streams can be moved more easily for load-balancing purposes. A Streamer can move a stream from one interface to another without involving the Control server, Setup server, or STB. A Control server can move a stream from one Play server to another without involving the Setup server or STB.

Address management on the Setup server and on the network is simplified. There is only one stream source address that needs to be hosted on the Setup server, and there is only one routing setup in the network configuration.

Global Source Address allows the coexistence of Release 2.5.4 with Release 2.3.3.

Any Streamer using the Global Source Address for STUN handshakes has those STUN packets routed to the Release 2.5.4 Setup server; while Streamers running Release 2.3.3 continue to use their local interface addresses for associated STUN packets routing.

After all Streamers have been upgraded to Release 2.5.4, the Global Source Address is used for STUN handshakes and for all stream transmissions.

The following additional information should be considered when configuring the Remote Setup and Control Server Support feature:

To trace the source of a stream, use the stream session ID along with the associated log files on the Streamers acting as the Play server, as well as the server acting as the primary Setup server and primary Control server. Other diagnostics such as the ping command can still use the unique IP address of each stream interface.

Additional router configuration may be necessary to ensure that the Global Source Address s hosted on the Setup server is used for inbound traffic and that packets sent to that address are never sent to the Play servers.

CDSM

To configure the Remote Setup and Control Server Support feature, do the following:


Step 1 Log in to the VVI Stream Manager as a user with Engineering access. The CDSM Setup page is displayed.

Step 2 In the Remote Setup and Control Service Support section of the CDSM Setup page, set Remote Setup and Control Service to Enabled.

Step 3 Enter the settings as appropriate. See Table 1 for a description of the fields.

Table 1 Remote Setup and Control Service Support Fields

Field
Description

Global Source IP

IP address used by the Streamers acting as the Play servers for transmitting streams. The Global Source Address is defined on the Streamers acting as the Play server and the remote server acting as the Setup and Control server., is hosted on the primary Setup server, and is managed in a fault-tolerant manner

Global Source Port

Port number used in conjunction with the Global Source IP address for transmitting stream data. The default is 4000.

Minimum Streams Per Port

Minimum number of streams allowed on each stream interface on the Streamer Play Servers. The default is 4. The range is from 4 to 10.

Single Session Timeout

Amount of time, in seconds, the first play request can be held on a Play server waiting for a second play request. If the timeout is reached, the first play session fails and the stream request is sent back to the Control server for relocation.

The default is 10. The range is from 2 to 20.

Sessions Per Control

Number of sessions allowed per Control server. The default is 1000. The range is from 10 to 2000.


Step 4 Click Submit.


When the Remote Setup and Control Service Support feature is enabled, the Configure > Array Level > Stream Group Setup page displays the Stream Group Role field. Each Stream Group must be configured as one of the following Stream Group Role options:

Stream Delivery—Stream Group consisting of Streamers acting as Play servers

Setup/Control—Stream Group consisting of a remote server acting as the Setup server and Control server

The Configure > Array Level > Control/Setup page only displays Stream Groups that are configured as Setup/Control.

The VHO ISA Setup page and the System Health page display the Stream Group Role next to each Stream Group name.

Enhancements

The following enhancements have been added in Release 2.5.6:

In the Remote Setup and Control Server Support feature, the Control server uses the Global Source Address as the stream source address in the reply to the NAT Setup request from the STB (CSCtz44634). This occurs whenever the Streamer Play server indicates that a remote STUN handshake is needed.

Ability to configure thin pipes among servers in the same site has been added (CSCtt97249). The CDSM/VVIM GUI now allows the Local Site and the Remote Site to be the same site. This configuration provides a way to restrict bandwidth usage among servers at the same site, thus honoring the physical capacity of the link.

The XML output of the trick-mode monitoring APIs for ISA environments now have a type of 160 for the first content when streams are rewound or restarted from EOS (CSCty78949).

Supported Environments

Release 2.5.6 of the Cisco TV CDS supports both the ISA and RTSP environments. Some RTSP environment features are only applicable to certain RTSP Deployment Types.

System Requirements

The Cisco TV CDS Release 2.5.6 runs on the CDE110, CDE220, CDE250, and CDE420. See the Cisco Content Delivery Engine110 Hardware Installation Guide, and the Cisco Content Delivery Engine 205/220/250/420 Hardware Installation Guide.

The Cisco TV CDS Release 2.5.6 also runs on the CDE100, CDE200, CDE300, and CDE400 hardware models that use the Lindenhurst chipset. See the Cisco Content Delivery Engine CDE100/200/300/400 Hardware Installation Guide for set up and installation procedures.

Release 2.5.6 does not support the CDEs with the ServerWorks chipset. All CDEs with the ServerWorks chipset need to be replaced with the CDEs with the Lindenhurst chipset or the Next Generation Appliances (CDE110, CDE220, CDE250, andCDE420) before upgrading to Release 2.5.6.


Note If you are using Internet Explorer 8 to access the CDSM GUI, for the online help to display correctly, you need to turn on Compatibility View. To turn on Compatibility View in Internet Explorer 8, choose Tools > Compatibility View.


Limitations and Restrictions

This release contains the following limitations and restrictions:

RTSP Redirect Server Limitations—The TV CDS Redirect Server provides a central entry-point for stream requests, which are then redirected based on internal load balancing policies to other Setup servers in the CDS deployment for session processing. The load balancing policies require that the CDS server running the Redirect Server have access to the database of each potential Setup server. The policies use key pieces of information from the database, such as the RTSP server status, the server load, and the Setup IP address to management IP address mappings. If the Redirect Server does not have access to this data, it cannot properly redirect the setup request to the "best" Setup server.

In the case of multiple Stream Groups, with the Redirect Server configured to run on Streamers within one of the Stream Groups, it is required that the database replication partners for the Streamers contain all of the Streamers from all Stream Groups, which basically constitutes a full-mesh database replication approach among all of the Streamers

If a full-mesh database replication for the Streamers is not desired, the Redirect Server can operate on the Vaults, which already have the necessary database replication partners defined to support required data.

Open Caveats

This release contains the following open caveats:

CServer

CSCtt22964

Symptom:

Transmit unit hang detected on e1000 interfaces during a server bring-up soon after upgrading from Release 2.3.3.

Conditions:

Happens only after upgrading the software from Release 2.3.3 during server bring-up on servers with e1000 adapters in quad formation and specific adapters on that quad configuration.

Workaround:

Rebooting a second time fixes the issue. This is a know issue with Intel drivers. Following is the excerpt from the driver README:

Detected Tx Unit Hang in Quad Port Adapters
-------------------------------------------
In some cases ports 3 and 4 don't pass traffic and report 'Detected Tx Unit
Hang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports 
1 and 2 don't show any errors and will pass traffic.
 
   
This issue MAY be resolved by updating to the latest kernel and BIOS. The 
user is encouraged to run an OS that fully supports MSI interrupts.
 
   

CSCtr15443

Symptom:

Evaluators shown as continuously active; they never seem to complete.

Conditions:

A disk drive that is bad or failing, yet not sufficiently bad to be declared "sick" by the disk driver continues to go in and out of "repair" mode, causing the evaluators to constantly restart and inhibiting the evaluators from completing.

In addition, the evaluators need to have a significant amount of local work that needs to be done (such as defragging or smoothing). If the amount of work is small, this symptom may not be exhibited because the evaluators are able to complete the task during the small windows of time that the disk drive is not in repair mode.

Workaround:

Remove and replace the bad disk drive.

CSCtu19076

Symptom:

System KDB may occur.

Conditions:

Removing a front-mounted device before the logical preparations for removal are complete.

Workaround:

Before removing a functioning storage device from the front of the server, ensure that it has first been logically removed by echoing the device name to /proc/cds/cdd/remove_device. For example,

echo csd3 > /proc/cds/cdd/remove_device prepares the device csd3 for removal from the server.

Ensure that the message "csdX can now be safely removed" (where X is the device number) appears on the console before pulling the device. Also, the red LED on the device will be flashing after it has been prepared to be removed.

Following these recommendations will avoid a possible system KDB event.

CSCts35941

Symptom:

During a failure of the Streamer hosting the primary Control server, occasionally part of the playing streams could be lost. This loss happens because of communication problems between the Streamers, causing confusion over which Streamer was the primary Control server, and also in some cases preventing the backup server from receiving the current state for all playing streams.

Conditions:

Loss of streams during a primary Control server failure are most likely to occur when a new Streamer has been brought online shortly before the primary Control server failed. Code that should have been sending switch forwarding probes on the ports for the new server to determine if the router forwarding table was sending and receiving traffic on the ports, before using the ports for live video and control traffic, was incorrectly making the ports available for use before the switch forwarding table was properly setup for sending and receiving traffic on these ports. This caused a very high percentage packet loss for communication traffic to the new server. The new server could then mistakenly believe there were no other primary Control server and could temporarily take over the role of primary Control server with no stream state. While in this mode, the new Streamer would issue commands to tear down all the streams that were playing on Streamer that it could communicate with.

A second problem could occur when the new Streamer did see the current primary server and the new server was the second Streamer to come up. There is a time window, during which the new Streamer has not finished bringing all of its ports online and had only one or two active ports, where the primary server could decide to use this new Streamer as the backup server. The primary would then send the new Streamer stream state information in parallel from multiple ports on the primary server exceeding the capacity to deliver the information being sent from many ports to the one or two active ports on the receiving Streamer. This would result in a high level of packet loss, and retransmitting the packets would continue to fail until the Streamers declared each other unreachable. The backup server would then see the primary as unreachable, but would only have state for part of the playing streams. If the primary server really failed so that the primary control IP address was no longer reachable over the management network, the backup server could become primary without having state for many of the stream.

These problems are much more likely to occur when the switch being used has a significant delay when a new port comes online, before the switch forwarding table is setup to forward traffic to and from the new port. The problem is also dependent on the timing between when a new Streamer comes online and when the existing primary server fails.

Workaround:

When possible, avoid shutting down the primary server if another Streamer has just come online. Wait for a couple of minutes after bringing the new Streamer online to make sure that it has had time for the switch to enable communication on all of the ports.

Some switches have configuration settings that can be modified to reduce the time delay between when a new port first detects link state and when the switch sets up the forwarding table information to send and receive traffic on the port. Reducing this time delay will help minimize the window in which this problem can occur.

CSCtt22591

Symptom:

Usually the first symptom is the presence of "WARNING: Stream transmit..." errors in the protocol timing log. This indicates that the LAN ports are getting behind.

Next some streams are dropped to reduce the load on the server, and some streams may end up getting changed to a NULL state-see the "Nulls:" part of the "Active streams:" lines in the protocol timing log to track this.

Conditions:

This appears to happen when the LAN channel has a total combined bandwidth (transmit and receive) of 41 to 46 Gbps.

Workaround:

There currently is no workaround other than to avoid having the server support both a maximum fill-bandwidth load and a maximum transmit-bandwidth load at the same time. It takes a well balanced load to do this; usually a server reaches a maximum on one or the other instead of both at the same time; so it is not likely you will actually encounter this problem.

Release 2.5.5 has the following LAN transmit and receive maximum limits:

Maximum transmit-bandwidth for a server with 4 10-gigabit Ethernet adapters is around 37.5 Gbps.

Maximum fill receive-bandwidth for a server with 4 10-gigabit Ethernet adapters is around 9.45 Gbps.

CSCtn28329

Symptom:

In the CDSM (or VVIM) GUI, on the Server Setup page (Configure > Server > Server Setup), when specifying an interface for the FTP Out Interface field under the FTP Out Setting section, the configuration setting does not take affect and the specified interface is not used for FTP out operations.

Conditions:

Using the CDSM (or VVIM) GUI, specify an FTP out interface and submit the Server Setup page. The setupfile on the server will be updated to reflect this configuration, as in following example:

ftpout if eth0 max utilization mbps 0 max sessions 0
 
   

Workaround:

The IP address of the interface to be used in FTP out operations can be specified on the ftp command line.

Configuration

CSCti78219

Symptom:

Not all packages are found in the drop-down list on the Monitor > System Level > Package Monitor page.

Conditions:

When the number of packages in the system reaches a level greater than 70,000.

Workaround:

If the number of packages in the system grows much beyond 70,000, then the drop-down list may not be able to display them all. The solution is to delete packages that are no longer needed. The maximum number of packages that will display in the drop-down list is variable, and is dependent on the system that is accessing the web page.

FSI

CSCtt46144

Symptom:

For a duplicated live future request, the state field in response XML body is empty instead of having the correct state of the scheduled live recording.

Conditions:

The client sends a request to schedule a live content with the same assetID, providerID, captureStart and captureEnd as an already scheduled future recording on the same channel.

Workaround:

None.

Monitoring

CSCtu23071

Symptom:

The following symptoms have been observed:

1. Monitor > Server Level > Disk Monitor shows a different failed disk than the Disk Activity graph.

2. When using some web browsers, the Disk Activity graph may reload repeatedly.

3. The Disk Activity Graph may show zero read/write activity if the disk activity is greater than100 Mbps.

Conditions:

Any CDE250.

Workaround:

For item one, there is no workaround. For item 2, using an older browser (IE6) should allow the user to see the Disk Activity graph. For item 3, when viewing the graph, the user can click on the icon to switch between the graph and a table display of the values to see if any disks are working at greater than 100 Mbps.

Statsd

CSCto43335

Symptom:

Caching Node remote servers file contains all servers from old group.

Conditions:

Moving Caching Node from group A to group B.

Workaround:

Restart statsd on the Caching Node that was moved and log in to the CDSM GUI and submit the Server Setup page for that Caching Node.

Resolved Caveats

This section contains he resolved caveats in Cisco TV CDS Release 2.5.6. Not all resolved issues are mentioned here. The following list highlights resolved caveats associated with customer deployment scenarios.

CServer

CSCty93882

Symptom:

Video macroblocking is observed during playback.

Conditions:

This can happen when there is a transition from one content to another and the second piece of content does not start at a GOP boundary.

CSCtz26392

Symptom:

Server will Page Fault.

Conditions:

This is a very rare race condition where all of the following must occur:

1. A query reply is received from a server that becomes unreachable.

2. That query reply is processed (very small window) after the server is marked unreachable.

3. The mirroring code executes the cleanup path (only happens on the server that has this object with the lowest server ID).

4. The mirroring code determines that there are excess copies (or partial copies) of the object that was queried.

5. The mirroring code decides to delete the copy (or partial copy) from the server that has just become unreachable.

When all of these conditions are met, then the attempt to send the delete to the server fails and executes the errant code.

CSCtx72438

Symptom:

Ixgbe driver does not allow packets to be received unless CServer is loaded. If an ixgbe interface is configured to be used by the Linux kernel, the interface statistics show that no packets are being received.

Conditions:

Always happens.

CSCty47111

Symptom:

The Streamer designated as the primary Control Setup server crashes in CM::ReadRate::startUsingSlot when transitioning from the active read-rate to the pending play request read-rate. The pending read-rate, along with the pending stream play object, has been previously deleted.

Conditions:

Streams are playing on the Streamer designated as the primary Control Setup server. One of the streams needs to be in the state where it is transitioning to new play request and has a pending play in the loading state and an active play that is in the process of being deactivated. This Streamer designated as the primary Control Setup server is off-lined, which then starts moving locally playing streams to other Streamers at the site.

CSCty58360

Symptom:

Streamer runs out of mapped memory and crashes after being up for a long time, possibly many months. A typical assert message seen would be the following:

CALYPSO ASSERT: "mappedblockmgr.getavailblocks() >= blockcnt"" or "CALYPSO ASSERT: 
"memBlockDesc != &DescriptorLoop"
 
   

The problem is more likely to be seen on a 32-bit kernel system than a 64-bit system with much more memory available.

Conditions:

The problem would be seen on Streamers that have to send streams directly to the IP addresses of the set-top boxes, and would therefore have a much larger pool of destination addresses for which the Streamer would need to create ARP entries. For each ARP entry that is released after a stream ends, 64 bytes of memory would be lost. The available mapped memory pool displayed at the top of the CServer protocol timing log would show a slow decrease in available memory each day.

CSCtx54504

Symptom:

Server may errantly (and very temporarily) report system pressure.

Conditions:

When the system is running at full capacity and resources are very low.

CSCtr46736

Symptom:

Primary-backup status conflict in some servers.

Conditions:

Network partition.

CSCtt02130

Symptom:

Server goes into kernel debugger (KDB) mode after a "service network restart" is issued or an individual adapter is restarted.

Conditions:

It only happens when the adapters are shared with the Linux operating system.

Database

CSCtx62492

Symptom:

AVSDB content metadata at the Streamer and Caching Node layer continues to accumulate, and is not being cleaned up. There are over 260,000 entries on some severs, as opposed to only 60,000 content entries in the Vault's database. If CServer clears it from the data drives, it needs to be cleaned up in AVSDB as well. This could potentially result in AVSDB queries to run slower and slower over time. There needs to be a process that automatically cleans the older content entries from the database.

Conditions:

There are over 260,000 entries on some servers as opposed to only 60,000 content entries in the Vault's database. If CServer clears it from the data drives, it needs to be cleaned up in AVSDB as well. This could potentially result in AVSDB queries to run slower and slower over time.

Interoperability

CSCty02366

Symptom:

Set TME field to MystroMDN, the Stream Extension events are sent to standard ISA Stream Channel.

Conditions:

Enable Stream Extension, the events are still delivered to standard ISA stream channel.

CSCty02408

Symptom:

Stream reaches the end and it should set the scale to 0.

Conditions:

The stream reaches the end and scale is non-zero.

CSCty02422

Symptom:

Stream reaches the end, CDS delivered VE_PAUSE. It should not.

Conditions:

Stream reaches the end.

ISA

CSCtz38547

Symptom:

PSE_START_SEG event missing when stream is rewound, it hits EOS.

Conditions:

Problem occurs only with some of STBs running ODN clients. Some how some of ODN clients are not sending LSCP_PAUSE(NOW) immediately after stream hits EOS.

CSCty50084

Symptom:

LSCP jump requests for playlist sessions should deliver PSE_END_SEGMENT and PSE_START_SEGMENT COBRA events if Stream Extension is enabled (TME/SCE field set to Enable for MystroMDN).

Conditions:

Playlist sessions with client is capable of LSCP jump requests.

CSCty50101

Symptom:

If Stream Extension is enabled, then PSE_END_SEGMENT event is expected if session is torn down in the middle.

Conditions:

The session is torn down in the middle.

CSCty45873

Symptom:

The number of null streams are increasing and content storage is not freeing on deletion of contents.

Conditions:

ResourceManager thread that invokes the API "ession.destroyWithReason()" gets stuck forever.

Reporting

CSCtz44288

Symptom:

Session trick-modes reported by the trick-mode APIs may include extra or incomplete 160 and 161 events.

Conditions:

These extra or incomplete values typically are included when a session was ended before a play request was sent, or if the session was ended before the EOS command was sent.

RTSP

CSCtz05726

Symptom:

Transport Profile of H2221 is not supported in Release 2.5.5.

Conditions:

When a setup request is sent from the client with a Transport Profile of H2221, the following exception is thrown:

Transport Profile is not supported
 
   

CSCty87286

Symptom:

Error is throwing when playing live content after two advertisements

Conditions:

Occurs when playing a live playlist. The live content is after two advertisements. When the backoffice sends request to play a specific NPT of the live program, the following error occurs:

457:Invalid Play range
 
   

SNMP

CSCty83893

Symptom:

After upgrading to Release 2.5.x from Release 2.3.x, and using CISCO-CDSTV-CS-STATS-MIB, the value returned by cdstvActiveStreamBW is inaccurate.

Conditions:

After upgrade to Release 2.5.2.

Upgrading to Release 2.5.6

The supported upgrade paths are the following:

Release 2.5.2 to Release 2.5.6

Release 2.5.3 to Release 2.5.6

Release 2.5.4 to Release 2.5.6

Release 2.5.5 to Release 2.5.6

If the CDS is running an earlier software release, you must first upgrade to one of the supported releases before upgrading to Release 2.5.6.

For software upgrade procedures, see the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.


Note To upgrade from Release 2.5.1 to Release 2.5.2, see EDCS-1141294.

To upgrade from Release 2.5.1-ES1 to Release 2.5.5, see EDCS- 1138748. The following are described in EDCS-1138748:

CDSM and Vaults upgrade from Release 2.5.1-ES1 to Release 2.5.5

CDE220 and CDE300 servers upgrade from Release 2.3.3-ES1 to Release 2.5.5

CDE250 servers upgrade from Release 2.4.1 to Release 2.5.5


Upgrading from Release 2.5.2, 2.5.3, 2.5.4, or 2.5.5 to Release 2.5.6

For the upgrade sequence of the CDS devices in your system (CDSM/VVIM and CDS servers [Vault, Streamer, Caching Node, ISV]), see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

To upgrade a CDS device, do the following:


Step 1 Download the ISO image file (CDS-TV-2.5.6.iso) and the cdsinstall-2.5.6 script from the Cisco Software Download website. For more information on downloading the software files, see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

Step 2 For the CDS servers, offload the device before upgrading the software.

a. From the CDSM GUI, choose Maintain > Servers > Server Offload. The Server Offload page is displayed.

b. From the Server IP drop-down list, select the IP address or nickname of the sever and click Display.

c. Select Enable and click Submit.

d. Ensure the CDS server has been offloaded by checking the protocoltiming log.

Step 3 Log in to the CDS device as user root.

Step 4 For CDS servers, before installing the image file, stop the database with the following command:

# db_shutdown
 
   

Wait until the following command returns no output:

# netstat -an | grep 9999 and #pgrep avsdb
 
   

Step 5 Copy the ISO image file and the cdsinstall-2.5.6 script to the CDS server.

# scp -p <user>@<remote_ip_address>:CDS-TV-2.5.6.iso /
# scp -p <user>@<remote_ip_address>:cdsinstall-2.5.6 /
 
   

Step 6 Run the cdsinstall script to upgrade the ISO image to Release 2.5.6.

# cd /root
# ./cdsinstall-2.5.6 /CDS-TV-2.5.6.iso
 
   

Step 7 For the CDSM or VVIM, when the script has completed, reboot the server.

Step 8 For CDS servers, make sure that the database is not running and reboot the server.

# pgrep avsdb
# reboot
 
   

Step 9 For CDS servers, after the CDS server has been verified as reachable, disable the Server offload.

a. Choose Maintain > Servers > Server Offload. The Server Offload page is displayed.

b. From the Server IP dropdown list, select the IP address or nickname of the server and click Display.

c. Choose Disable and click Submit.

d. Verify the CDS server is online by viewing the status on the Monitor > System Level > System Health page.


Downgrading from Release 2.5.6

For the downgrade sequence of the CDS devices in your system (CDSM/VVIM and CDS servers [Vault, Streamer, Caching Node, ISV]), see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

To downgrade a CDS device, do the following:


Step 1 Download the ISO image file (for example, CDS-TV-2.5.2.iso) and the cdsinstall script (for example, cdsinstall-2.5.2) for Release 2.5.2, 2.5.3, or 2.5.5 from the Cisco software download website. For more information on downloading the software files, see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

Step 2 For CDS servers, offload the server (see Step 2 in "Upgrading from Release 2.5.2, 2.5.3, 2.5.4, or 2.5.5 to Release 2.5.6").

Step 3 Log in to the CDS device as user root.

Step 4 For CDS servers, before installing the image file, stop the database with the following command:

# db_shutdown
 
   

Wait until the following command returns no output:

# netstat -an | grep 9999 and #pgrep avsdb
 
   

Step 5 Copy the ISO image file and the cdsinstall script to the /root directory and run the cdsinstall script to download the software. For example, the following commands are for downgrading to Release 2.5.2:

# scp -p <user>@<remote_ip_address>:CDS-TV-2.5.2.iso /
# scp -p <user>@<remote_ip_address>:cdsinstall-2.5.2 /
# cd /root
# ./cdsinstall-2.5.2  /CDS-TV-2.5.2.iso
 
   

Step 6 For the CDSM or VVIM, when the script has completed, reboot the server.

Step 7 For CDS servers, make sure that the database is not running and reboot the server.

# pgrep avsdb
# reboot
 
   

Step 8 For CDS servers, after the CDS server has been verified as reachable, disable the Server offload.

a. Choose Maintain > Servers > Server Offload. The Server Offload page is displayed.

b. From the Server IP dropdown list, select the IP address or nickname of the server and click Display.

c. Choose Disable and click Submit.

d. Verify the CDS server is online by viewing the status on the Monitor > System Level > System Health page. (see Step 7 in "Upgrading from Release 2.5.2, 2.5.3, 2.5.4, or 2.5.5 to Release 2.5.6" procedure).


Related Documentation

Refer to the following documents for additional information about the Cisco TV CDS 2.5:

Cisco TV CDS 2.5 ISA Software Configuration Guide

http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/configuration/isa_guide/tv_cds_2_5_isa_config.html

Cisco TV CDS 2.5 RTSP Software Configuration Guide

http://wwww.cisco.com/en/US/docs/video/cds/cda/tv/2_5/configuration/rtsp_guide/tv_cds_2_5_rtsp_config.html

Cisco TV CDS 2.5 API Guide

http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/developer_guide/tv_cds_2_5_apiguide.html

Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide

http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/installation_guide/tv_cds_2.5_maint_guide.html

Cisco Content Delivery System 2.x Documentation Roadmap

http://www.cisco.com/en/US/docs/video/cds/overview/CDS_Roadmap.html

Cisco Content Delivery Engine 205/220/250/420 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/cde205_220_420/installation/guide/cde205_220_420_hig.html

Cisco Content Delivery Engine 110 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/cde110/installation/guide/cde110_install.html

Cisco Content Delivery Engine 100/200/300/400 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/installation/guide/CDE_Install_Book.html

Regulatory Compliance and Safety Information for Cisco Content Delivery Engines

http://www.cisco.com/en/US/docs/video/cds/cde/regulatory/compliance/CDE_RCSI.html

Open Source Used in TV CDS 2.5

http://www.cisco.com/en/US/products/ps7127/products_licensing_information_listing.html

The entire CDS software documentation suite is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps7127/tsd_products_support_series_home.html

The entire CDS hardware documentation suite is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps7126/tsd_products_support_series_home.html

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.