Downloads |
 Feedback
|
Table Of Contents
Release Notes for Cisco TV CDS 2.1.4
2.1.3 CDSM Bulk Configuration Import Support for Stream Destinations
Configuring QoS Settings on the CDS Servers
Changing the Date and Time with NTP
Installing and Configuring the TV CDS 2.1 Software
Preparing the CDEs for the TV CDS Software
Connecting to the Serial Port on the CDE
VVI with Split-Domain Management Installation Procedure
Installing and Configuring the VVIM
Installing and Configuring the Stream Manager
Installing and Configuring the Vaults, Caching Nodes, or Streamers
Upgrading from Release 1.5.1.x
Upgrade the Software on the CDSM
Upgrade the Software on Each Streamer and Vault
Upgrading from Release 2.0 to Release 2.1.4
Getting a Software File from Cisco.com
Upgrade the Software on the CDSM
Upgrade the Software on Each Streamer and Vault
Upgrading from Release 2.1.3 to Release 2.1.4
Upgrading a VVI from Release 2.1.3 to Release 2.1.4
Getting a Software File from Cisco.com
Upgrade the Software on the CDSM
Upgrade the Software on Each Streamer and Vault
Updating the Device Drivers for new SSDs
Rolling Back the SSD Driver Update
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco TV CDS 2.1.4
These release notes cover Cisco TV CDS Release 2.1.4.
Revised: October 2011 OL-22676-02Contents
The following information is in the release notes:
•
Installing and Configuring the TV CDS 2.1 Software
•
Enhancements
Release 2.1.4 is a maintenance release and consists of resolved caveats and the Bulk Configuration feature. See the "Resolved Caveats" section for more information.
2.1.3 CDSM Bulk Configuration Import Support for Stream Destinations
In 2.1.3, CDSM GUI will support importing Stream Destination (Configure -> System Level -> Stream Destination) configurations using an XML file. This feature will enable the user to import a set of Stream Destination configurations using an XML file in one step.
Enabling Bulk Import Feature:
In 2.1.3, this feature will be always enabled for Stream Destination Page.
Supported Environments
Release 2.1.4 of the Cisco TV CDS supports the following environments and associated backoffice integrations:
•
–
–
•
–
–
–
–
–
–
–
System Requirements
The Cisco TV CDS Release 2.1.4 runs on the CDE110, CDE220, and CDE420. See the Cisco Content Delivery Engine110 Hardware Installation Guide, and the Cisco Content Delivery Engine 205/220/420 Hardware Installation Guide.
The Cisco TV CDS Release 2.1.4 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.1.4 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, andCDE420) before upgrading to Release 2.1.4.
See the "Related Documentation" section for links to the documentation online.
Limitations and Restrictions
There are no limitations nor restrictions in Release 2.1.4.
Important Notes
The section covers the following important notes that apply to this release;
•
New SSD Driver
There is a new driver for the new solid-state drives (SSDs) that also addresses an issue with the old SSDs.
Old SSD Issue
When an abrupt power loss occurs on an older SSD while the SSD is under load, which can also happen when the SSD is being written to and a power-off shutdown occurs, the result is that the SSD may become corrupted and unusable. If an SSD becomes corrupted in this way it must be replaced.
This driver update provides a fix to prevent the corruption of the SSD when the system is being shutdown. When the system is being shutdown the driver sends a command to the SSD to stop all activity and therefore is protected from corruption.
Note
New SSDs
New solid-state drives (SSDs) used in the following CDE models require a device driver update for the TV CDS software to recognize the drives:
•
•
•
•
A new Generation 2 SSD drive could occur in one of the above newly manufactured CDEs or as a returned merchandise authorization (RMA) SSD drive replacement.
The new SSDs replace the end-of-life (EOL) external 160 GB SSDs. A new SSD drive is a Generation 2 front-mounted SSD. The new SSD model is identified by the title "Intel SSD 320 Series" on the label and has the model number: SSDSA2BW160G3. For more information, see Field Notice 63438 at: http://www.cisco.com/en/US/products/ps7126/prod_field_notices_list.html.
The new driver prevents the corruption of the existing SSDs in the field when a system is shutdown. In the case of receiving any new model of SSDs, the driver must be installed.
Note
For more information, see the "Updating the Device Drivers for new SSDs" section.
Thin Pipe Mapping
The CDSM GUI's Thin Pipe Map page allows you to configure low-bandwidth connections between local and remote groups. A local group consists of CDS servers in the same local area network (LAN). A remote group consists of all the CDS servers that are reachable by way of a wide area network (WAN).
There can be multiple thin pipes configured for each local group. As an example, a site with Caching Nodes organized into a Cache Group could have one 500-Mbps thin pipe going to a site with a Vault Group, and a second 500-Mbps thin pipe going to a location with a Stream Group. The thin pipes are completely independent of each other.
The Thin Pipe Map page also allows for the configuration of thin pipes in a hierarchy, where a remote group must be reached through several pipes. For example, a Cache Group could have a 500 Mbps thin pipe over which it streams to three Stream Groups. Each Stream Group could have separate 100 Mbps thin pipes. In this case, the Cache Group traffic on egress to all Stream Groups is limited to 500 Mbps, while ingress traffic to each Stream Group from this Cache Group is limited to 100 Mbps. In this example, the Cache Group would have four thin pipes configured: one 500 Mbps pipe to all three Stream Groups, and a total of three 100 Mbps pipes, one to each individual Stream Group.
Note
As an example, Figure 1 shows the maximum bandwidth available for the various groups in a Virtual Video Infrastructure (VVI) system with two super headends (SHEs), three caching sites, and one streaming site.
Figure 1 Thin Pipe Example
Note
Table 1 lists the thin pipe mappings that would be configured for the Vault Group 1 illustrated in Figure 1.
The thin pipes configured in Table 1 ensures that the bandwidth for Vault Group 1 never exceeds the maximum bandwidth available for Vault Group 1, which is 5 Gbps. This means that even if all remote groups were requesting cache-fills from Vault Group 1, which would be a maximum throughput of 9 Gbps, the actual maximum bandwidth of cache-fill traffic coming from Vault Group 1 would never exceed 5 Gbps.
Configuring QoS Settings on the CDS Servers
There needs to be a dedicated Differentiated Services (DiffServ) Assured Forwarding (AF) class for the CCP traffic. The Assured Forwarding PHB guarantees a certain amount of bandwidth to an AF class and allows access to extra bandwidth, if available. There are four AF classes, AF1x through AF4x. Within each class, there are three drop probabilities (low, medium, and high).
Note
Table 1 lists the DSCP parameters that are configured in the setupfile, the data types that use each parameter, and the required DSCP value for each. The DSCP value can be any number from 0 to 63, but in order for CCP traffic to work properly, the DSCP value must be one of the values listed in Table 2.
Currently, the values for the DSCP parameters must be set manually in the setupfile. Log in to each CDS server as root and edit the setupfile by adding the parameters described in Table 2. The setupfile file is located in the /arroyo/test directory.
Caution
Following are the fields that have to be added to the setupfile on each CDS server grouped by AF class. For convenience, you can copy the text of the appropriate settings for the AF class you want to use and paste it into the setupfile.
To configure for class AF1 add the following lines to the setupfile:
cache_priority0_dscp 14cache_priority1_dscp 14cache_priority2_dscp 14cache_priority3_dscp 14cache_priority4_dscp 12cache_priority5_dscp 10cache_priority6_dscp 10cache_priority7_dscp 14control_dscp 10To configure for class AF2 add the following lines to the setupfile:
cache_priority0_dscp 22cache_priority1_dscp 22cache_priority2_dscp 22cache_priority3_dscp 22cache_priority4_dscp 20cache_priority5_dscp 18cache_priority6_dscp 18cache_priority7_dscp 22control_dscp 18To configure for class AF3 add the following lines to the setupfile:
cache_priority0_dscp 30cache_priority1_dscp 30cache_priority2_dscp 30cache_priority3_dscp 30cache_priority4_dscp 28cache_priority5_dscp 26cache_priority6_dscp 26cache_priority7_dscp 30control_dscp 26To configure for class AF4 add the following lines to the setupfile:
cache_priority0_dscp 38cache_priority2_dscp 38cache_priority3_dscp 38cache_priority4_dscp 36cache_priority5_dscp 34cache_priority6_dscp 34cache_priority7_dscp 38control_dscp 34Changing the Date and Time with NTP
This section provides the details on setting the time and date. Specific NTP configuration details should be obtained from your system administrator.
The clocks on all CDS nodes (vault, streamer, cache and CDSM) in a network must be synchronized in order to retrieve the statistics on the CDSM. Synchronizing the clocks is the final step in the installation process before rebooting the system for each CDS node.
Perform the following steps to change the date and time with NTP:
Step 1
Step 2
[root@system]# chkconfig --level 2345 ntpd on[root@system]# chkconfig --list ntpdYou will see the following:
ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:offStep 3
[root@system]# service ntpd stopStep 4
[root@system]# /usr/bin/tzselectStep 5
[root@system]# date -s "16:55:30 Nov 7, 2009"Step 6
[root@system]# ntpd -q
Note
Step 7
[root@system]# service ntpd startStep 8
[root@system]# /sbin/hwclock --systohcStep 9
[root@system]# ntpq -pStep 10
[root@system]# init 6Open Caveats
This release contains the following open caveats:
Configuration:
•
Symptom:
Submitting System-> Headend Setup page removes the leading zeros in the Service Group Name.
Condition:
CDSM Setup:
–
–
–
–
Workaround:
None,
Database
•
Symptom:
The error indicates that a PAID to GOID lookup is occurring during a database checkpoint. The lookup times out due to the database being busy with a checkpoint and the error is thrown in c2k log and the messages log. The lookup is retried and the fill is successful.
Condition:
CCDN-PS-WCDC-01 kernel: IsaDbCommand error -1 attempting GET PAID_TO_GOID.
Workaround:
cServer and Database should communicate with each other to avoid these types of errors.
Ingest
•
Symptom:
CDSM System Snapshot page: Prov. (push) Ingests field is always 0.
Condition:
Database content records for Provisioned FTP Push Ingests were not replicated from vaults to CDSM properly. Some fields are zeroed.
Workaround:
Check database on vaults directly. Provisioned but not active FTP Push Ingests will have OpState = 3, and AdminState = 2.
ISA
•
Symptom:
If more than a handful (> 10) of barkers streams are created then this issue occurs, but the root cause is not known yet.
Condition:
The error is triggered by some unknown issues. It is under investigation and and is trying to be reproduce in the lab.
Workaround:
Manually figure out the duplicate barker streams and use the procedure to clean them. The following procedure must be run on both primary and backup setup streamers:
1.
2.
3.
4.
After steps 1-4 are done on both the primary and backup setup streamers , perform the following steps only on the primary setup streamer:
5.
6.
7.
8.
After steps 5-8 are done then perform the following steps on both streamers:
9.
10.
11.
Finally, perform the following step only on the primary streamer:
12.
Streamer
•
Symptom:
1.5 vault could not fill content to 2.1.4 streamers.
Condition:
During upgrade, cserver version is co-existing on vaults and streamers. It did not happen always.
Workaround:
Reboot 2.1.4 streamers.
•
Symptom:
On the simulation test bed, if a stream failed to be transmit-filled from vaults or cache servers to streamers, ResourceManager could not identify it when it is LSCP Timeout.
Condition:
This only happens on the simulation test bed, and only happens when the stream failed to be filled. If stream plays to end and transition to Open state, it will be detected by ResourceManager and torn down by Stream Service if it is LSCP Timeout. On the end-to-end system, STB will send Tear Down command to control server if the null stream becomes timeout.
Workaround:
Hardly see it on the end-to-end system.
•
Symptom:
Small number of packet loss is observed with a packet analyzer.
Condition:
When streaming 3000+ streams from 80 live ingest streams the packet analyzer reports a few packets that are lost. With the small number of packets lost there is no visual effect observed or degradation of quality.
Workaround:
Stream a lower number of streams per streamer or ingest lower number of live streams per vault.
Upgrade
•
Symptom:
While running preupgrade script in 1.5.x, at the end it displays the following message "Please reboot the server and run the script 'upgrade' when the server comes back up". This message should be changed to indicate that the upgrade script should be run after the OS upgrade.
Conditions:
Run preupgrade script on a 1.5.x server
Workaround:
None.
Vault
•
Symptom:
1.5 vault ingested content failed to remote-mirror to 2.1.4 vault
Condition:
During upgrade, the cserver version is co-existing on vaults. Newly ingested content to 1.5 vault cannot be remote mirrored to 2.1.4 vault. It is not a 2.1.4 bug, it is related to 1.5 code.
Workaround:
Once 1.5 vault is upgraded to 2.1.4, objects will be mirrored to 2.1.4 vault automatically. Or they do not ingest new content during upgrade.
•
Symptom:
When HD ingest count is over 40 on a Lindenhurst with 8G memory, c2k log shows "ERROR: Out of memory", video has artifacts for live streaming.
Condition:
160 SD ingest count is enforced on a Lindenhurst vault. But equivalent HD ingest has no limitation enforced. It is possible HD ingests are over vault's capacity.
Workaround:
Limit HD ingest number at backoffice.
•
Symptom:
A bad drive caused receiving mirroring stuck on a vault.
Condition:
A bad drive on the vault and vault is doing disk writes.
Workaround:
Pull the bad drive. Or wait for 5-10 minutes, the bad drive will be kicked off by the cserver.
Video Quality
•
Symptom:
Packet loss is observed when 300 live streams for 30 MPEG2 HD live contents.
Condition:
–
–
Workarounds:
–
–
•
Symptom:
Packet loss is observed with 3000 streams for 50/80 MPEG2 SD live contents. There are about 50 packets lost testing on the CDE420.
Conditions:
This issue is observed on both the CDE420 with 32G memory and CDE400 with 8G memory.
Workarounds:
–
–
•
Symptom:
Macroblocking for up to a second after a transition from FF or REW to 1x Play.
Conditions:
–
–
–
Workarounds:
–
–
–
Resolved Caveats
The following caveats have been resolved since Cisco TV CDS Release 2.1.4. Not all resolved issues are mentioned here. The following list highlights associated with customer deployment scenarios.
CacheGateway
•
Symptom:
The Streamer is unable to get content from the Cache Gateways when the Provide ID is 20 characters in length.
Cache Management
•
Symptom:
When sending a name-to-GOID lookup request to the library node from the cache node, there was no library node online. In this case, the requesting server synthesizes a response, but the response contains no response data, only a response status. The fix is to ensure that we do not de-reference the response data pointer unless the response status indicates success.
CDSM
•
Symptom:
The CDSM file system can become full and all logging stops.
Configuration
•
Symptom:
You cannot configure an SOP in the CDSM GUI with a name longer than 20 characters, and the GUI also does not allow any special characters in the SOP name.
•
Symptom:
Service Group values greater than 32bit signed into (2147483647) get changed to 2147483647 prior to being set in the database.
File Systems
•
Symptom:
Objects do not stream properly after upgrading from 1.5.x to 2.x. Fragmented objects on the 1.5 server (Streamer or Vault) may become unusable after an upgrade to 2.x as they are marked as "data downloads" after the upgrade is completed.
Ingest
•
Symptom:
A Gen II vault KDB during live ingest.
•
Symptom:
The active ingest content gets stuck after the ingest port is down for a long time. This problem occurs only if the link that has the current ingest going on (management or ingest interface) goes down. The thread in the application waiting for the response from the FTP server never comes out and remains hung until service is restarted.
ISA
•
Symptom:
Connections on the Sectamus server are timing out when there is no response from the master vault received within 3 seconds. A portion of the RTA titles that are ingested at the top of the hour will fail and will not be available to be viewed.
•
Symptom:
When adding 60 feed live ingestion (FTP push ingest; the vault acts as an FTP server), after ingesting for some time we found the content store factory in the master vault is restarted.
•
Symptom:
The defragmentation or local smoothing of large objects can lead to a stuck polling loop, which excessively consumes the CPU.
Network
•
Symptom:
There is a time comparison that is intended to make sure that the receiving server does not send out the cancel message on a stream it does not want at a rate faster than 5ms between packets (200 packets per second maximum).
Scalability
•
Symptom:
Streamer runs out of capacity when starting more than 300 unique fill streams.
statsd
•
Symptom:
The statsd fails to generate a setup file for ISA non-scs deployments.
Streamer
•
Symptom:
After a network outage, when control primary and control backup stream servers resync, the backup primary may KDB if it is required to process rapid commands given from a remote control. This happens when the user pushes the buttons several times a second.
•
Symptom:
If the Igate read fails with a read failure, when retrying reading the igate the read always fails because the flag in the read rate that indicates that a read failure has occurred is never reset.
•
Symptom:
When IGate mem on streamer reaches 720M, streams cannot be set up and "IGate memory limit exceeded 0 1 0 0 0 0 0 0 0 0" is kept printing in the Streamer protocoltiming.log.
•
Symptom:
A new tunable is required to adjust the delay before a failing stream.
•
Symptom:
2.1 NGOD cannot play live-ingested content.
•
Symptom:
There are several paths in the cost request code where the CostingAgent may reference a stream after it has already been destroyed. One of these paths was previously fixed as part of CSCta12859 but was subsequently broken again by CSCtb95669.
Utilities
•
Symptom:
The avs_clist tool is printing out the wrong GOID length creating a clone list. When running the avs_clist on 1.5.1.5.4, the clone list has problems with the GOID length. Also the cloned vault can delete a remote GOID.
Vault
•
Symptom:
When removing a copy, the loop exceeds the bound of a global array.
•
Symptom:
Asset fails to ingest. Asset being ingested has to be coded with more than one setting for the aspect ratio, and in violation of both our VOD encoding specs and the MPEG-2 specification Part 1.
•
Symptom:
If any of the remote vaults are rebooted, the FTP control connections from the master vault to the remote vault are left in the EST state on the master side. The master content store considers them as a good connection and sends the PASV command through it, but the send fails and causes the ingest to fail.
•
Symptom:
If an error occurs during the RTA ingest (ftp-push) request (PASV failed or STOR failed), the connection between the master and the remote vault are closed by the remote vault and there are chances that the file desc goes into an error and causes the poll thread to spin on it until the file desc is reused by the system for other ingests.
The window for the thread spinning over CPU is small if the file desc number is small (such as 10, 11) but it could be bigger if the file desc number is big enough that system takes time to reuse it.
•
Symptom:
A softlockup is caused by an infinite loop when more than ten servers exist in one array.
•
Symptom:
A malformed vaultcloner file can cause the cloner to delete content on the cloner.
Installing and Configuring the TV CDS 2.1 Software
This section includes the following topics:
•
•
For a CDS for an ISA environment or RTSP environment, see the software installation procedures included in the Cisco Content Delivery Engine 110 Hardware Installation Guide and the Cisco Content Delivery Engine 205/220/420 Hardware Installation Guide. See the "Related Documentation" section for information on accessing these documents.
It is a good idea to read through this entire section before performing the install or upgrade procedure.
Note
uname -r
If the response to this command has "cdstv.2.1.4.b30" in the output, the system has the TV CDS 2.1.4 software. If 2.1.4 is not on the system, see the "Getting a Software File from Cisco.com" section to obtain the TV CDS software needed for your deployment.
Release 2.1 introduces two features that require additional information when configuring the CDS servers and the CDSM:
•
•
Virtual Video Infrastructure
Release 2.1 introduces the Virtual Video Infrastructure with Caching Nodes. With the VVI, there is the option to centrally manage all the servers or to use the split-domain management. Split-domain management has two managers:
•
•
You can have multiple Stream Domains that are each managed by a separate Stream Manager. Centrally managed VVIs are only supported in an RTSP environment. A VVI in an ISA environment must use split-domain management, as well as Shared Content Store and CCP Streamers. For more information about Shared Content Store and CCP Streamers, see the Cisco TV CDS ISA 2.1 Software Configuration Guide. Each of the VVI configurations has a different installation process.
Note
CDSM Redundancy
Release 2.1 also introduces CDSM redundancy. All CDS servers keep track of both CDSM IP addresses. Each CDSM keeps track of the other CDSM IP address, as well as the virtual IP address that is used to access the CDSM. When running the cdsconfig script on each CDS server, you need to add each CDSM as a replication member. The CDSM that is chosen as the primary is accessed by using the virtual IP address. When running the cdsconfig script on each CDSM, you are prompted for the virtual IP address and subnet mask. When running the cdsconfig script on a Stream Manager, you are asked if this is the first CDSM that is getting added to the domain. For more information on the CDSM Redundancy feature, see the Cisco TV CDS ISA 2.1 Software Configuration Guide or the Cisco TV CDS RTSP 2.1 Software Configuration Guide.
Following is an overview of the procedure to add a second CDSM:
1.
2.
3.
Note
Preparing the CDEs for the TV CDS Software
Before performing the software installation and initial configuration, you must correctly install the CDEs and connect the cables as described in the Cisco Content Delivery Engine 110 Hardware Installation Guide and the Cisco Content Delivery Engine 205/220/420 Hardware Installation Guide. See the "Related Documentation" section for information on accessing these documents.
Note
Before you run the initial configuration script, you should gather the following information:
•
•
•
•
•
Note
However, RTSP VVI does not generate a range for the server ID.•
Note
–
–
In both the CDS and VVI, all Vaults and Streamers are identified by an array ID, a group ID, and a server ID. In the CDSM GUI, the array ID identifies servers that are part of the same system, the group ID identifies servers that are part of the same group (Vault Group or Stream Group), and the server ID is a unique number that identifies the server. Table 1-3 lists the CDSM GUI ID names and maps them to the CServer names in the setupfile and .arroyorc files.
Connecting to the Serial Port on the CDE
The RJ-45 serial ports on the Cisco CDEs front and back panels can be used for administrative access to the CDE through a terminal server. Terminal emulation software must be configured as follows:
•
•
•
•
•
VVI with Split-Domain Management Installation Procedure
Note
The order in which you install and configure the CDEs for VVI is very important. The VVIM (Vault/Cache CDSM) and all the Vaults and Caching Nodes in the VVIM domain must be installed and configured first and brought online before the Streamer domain is configured. A high-level view of the installation order follows:
Step 1
a.
b.
Step 2
a.
b.
Note
Step 3
a.
b.
Step 4
a.
b.
Step 5
Step 6
Note
Installing and Configuring the VVIM
To install the TV CDS software and initially configure the VVIM, do the following:
Step 1
The operating system boots.
Step 2
Step 3
Step 4
[root]# ./cdsinstallThe following prompt is displayed:
Continuing first-time installation after kickstart using image //CDS-TV.iso Select Deployment Type (ctrl-c to quit):1) CDSM1CDSM Selected... Output omitted ...Unmounting /mnt/cdrominst.sh completed, removing .iso image==================================================Configure the system for initial installation ==================================================Step 5
•
•
[root]# cdsconfigPlease ensure an IP address and netmask are configured formanagement interface eth0:Select an option or an interface to re-configure/disable:1. eth0 ip:172.22.97.162 mask:255.255.255.128 bcast:172.22.97.2552. Configure another interface3. DoneChoice [3]: 3Backing up old scripts in /etc/sysconfig/network-scriptsWriting new ifcfg-ethX scriptsEnter a hostname [cdsm162]: EnterEnter the number of the eth interface that connects to the gateway [0]: EnterEnter the default gateway IP address [172.22.97.129]: EnterBacking up /etc/sysconfig/networkWriting new /etc/sysconfig/networkBacking up /etc/hostsWriting new /etc/hostsRestarting network services, this may take a minute:Shutting down interface eth0: [ OK ]Shutting down loopback interface: [ OK ]Bringing up loopback interface: [ OK ]Bringing up interface eth0: [ OK ]Network services restarted; may take a few seconds to establish connectivityReboot for hostname changes to take effectNetwork configuration completePlease choose your platform from the following list of valid platforms:1. 2U-SCSI-12. 3U-SCSI-13. 3U-SCSI-104. 3U-SCSI-115. 2U-SATA-16. 2U-SATA-27. 2U-SATA-108. 2U-SATA-119. 4U-SATA-110. 4U-SATA-211. 4U-SATA-312. 4U-SATA-1013. 4U-SATA-1114. 4U-SATA-1215. CDE100-2C-116. CDE110-2C-1Choice: 16Please select a role for this CDSM:1. CDS Manager (single domain)2. VVI Manager (split domain for Vault and Caching node)3. CDS Manager (split domain for Streamers)Choice: 2Please enter a group ID: 12345Please enter a server ID [62]: 162Writing new configuration to /home/isa/.arroyorcNo existing replication group information foundDo you want to configure replication group members now? (yes/no) [y]: yThere are currently no replication group members.Do you want to add another replication group member? (yes/no) [y]: y
Note
In the following example, the configuration of the CDS devices shows generalized input values. Option 5, cdsmgw, is the Stream Manager. Add the Stream Manager as a replication group member. This is for ISA only; this is not required for RTSP.
Select a role for the new replication group member:1. ssv2. Vault3. cache4. Streamer5. cdsmgwChoice: device_role (1, 2, 3, 4, 5 or 6)Enter an IP address for new CDS_device: IP_AddressCurrent replication group members:device_role IP_AddressDo you want to add another replication group member? (yes/no) [n]: nConfiguring CDSMDatabase is running.Do you want to enable CDSM Redundancy ? (yes/no) [y]:CDSM Virtual IP [172.22.99.106]:Subnet Mask [255.255.254.0]:Writing rc.localCDSM configuration finishedcdsconfig finished, please use CDSM to complete configuration[root]#Step 6
dbdomsock /tmp/isadb
If the preceding line is not in the file, use a text editor to add the line. Close and save the .arroyorc file.
Step 7
[root]# su - isa //==== start avsdb[isa]$ pgrep avsdb28794 //==== verify avsdb process is running[isa]$ exitlogout[root]# /arroyo/www/bin/apachectl start //==== start apache serverhttpd: Could not reliably determine the server's fully qualified domain name, using 172.22.97.162 for ServerName[root]#Step 8
http://VVIM_ip_addressThe VVIM Login page is displayed.
Step 9
If you are unable to log in with the username admin and the password admin, do the following:
a.
[root]#/home/stats/runonceb.
The VVIM Setup page is displayed.
Step 10
•
•
Once the VVIM has been installed and initially configured, install and initially configure the Vaults and Caching Nodes that are part of this VVIM domain. See the "Installing and Configuring the Vaults, Caching Nodes, or Streamers" section for more information. When all the servers in the VVIM domain have been configured and are listed on the VVIM's System Health Monitor page, install and configure the Stream Manager. See the "Installing and Configuring the Stream Manager" section for more information.
Installing and Configuring the Stream Manager
To install the TV CDS software and initially configure the Stream Manager, do the following:
Step 1
The operating system boots.
Step 2
Step 3
Step 4
[root]# ./cdsinstallThe following prompt is displayed:
Continuing first-time installation after kickstart using image //CDS-TV.iso Select Deployment Type (ctrl-c to quit):1) CDSM1CDSM Selected... Output omitted ...Unmounting /mnt/cdrominst.sh completed, removing .iso image==================================================Configure the system for initial installation ==================================================Step 5
•
•
[root]# cdsconfigPlease ensure an IP address and netmask are configured formanagement interface eth0:Select an option or an interface to re-configure/disable:1. eth0 ip:172.22.97.162 mask:255.255.255.128 bcast:172.22.97.2552. Configure another interface3. DoneChoice [3]: 3Backing up old scripts in /etc/sysconfig/network-scriptsWriting new ifcfg-ethX scriptsEnter a hostname [cdsm162]: EnterEnter the number of the eth interface that connects to the gateway [0]: EnterEnter the default gateway IP address [172.22.97.129]: EnterBacking up /etc/sysconfig/networkWriting new /etc/sysconfig/networkBacking up /etc/hostsWriting new /etc/hostsRestarting network services, this may take a minute:Shutting down interface eth0: [ OK ]Shutting down loopback interface: [ OK ]Bringing up loopback interface: [ OK ]Bringing up interface eth0: [ OK ]Network services restarted; may take a few seconds to establish connectivityReboot for hostname changes to take effectNetwork configuration completePlease choose your platform from the following list of valid platforms:1. 2U-SCSI-12. 3U-SCSI-13. 3U-SCSI-104. 3U-SCSI-115. 2U-SATA-16. 2U-SATA-27. 2U-SATA-108. 2U-SATA-119. 4U-SATA-110. 4U-SATA-211. 4U-SATA-312. 4U-SATA-1013. 4U-SATA-1114. 4U-SATA-1215. CDE100-2C-116. CDE110-2C-1Choice: 16Please select a role for this CDSM:1. CDS Manager (single domain)2. VVI Manager (split domain for Vault and Caching node)3. CDS Manager (split domain for Streamers)Choice: 3Is this Streaming Domain going to use CCP as Cache Fill Protocol? (yes/no) [y]: YIs this the first CDS Manager getting added to this domain? (yes/no) [y]:Enter the name of this Stream Domain: StreamDomain1Enter the IP address of the VVIM: 172.22.99.109Retrieved Server ID '1001' from '172.22.99.109'Please enter a group ID: 12345
Note
Writing new configuration to /home/isa/.arroyorcNo existing replication group information foundDo you want to configure replication group members now? (yes/no) [y]: yThere are currently no replication group members.Do you want to add another replication group member? (yes/no) [y]: y
Note
In the following example, the configuration of the CDS devices shows generalized input values. Option 5, vvimgw, is the VVIM. Add the VVIM as a replication group member.
Note
1. ssv2. Vault3. cache4. Streamer5. vvimgwChoice: device_role (1, 2, 3, 4, 5 or 6)Enter an IP address for new CDS_device: IP_AddressCurrent replication group members:device_role IP_AddressDo you want to add another replication group member? (yes/no) [n]: nConfiguring CDSMDatabase is running.Do you want to enable CDSM Redundancy ? (yes/no) [y]:CDSM Virtual IP [172.22.99.106]:Subnet Mask [255.255.254.0]:Writing rc.localCDSM configuration finishedcdsconfig finished, please use CDSM to complete configuration[root]#Step 6
dbdomsock /tmp/isadb
If the preceding line is not in the file, use a text editor to add the line. Close and save the .arroyorc file.
Step 7
[root]# su - isa //==== start avsdb[isa]$ pgrep avsdb28794 //==== verify avsdb process is running[isa]$ exitlogout[root]# /arroyo/www/bin/apachectl start //==== start apache serverhttpd: Could not reliably determine the server's fully qualified domain name, using 172.22.97.162 for ServerName[root]#Step 8
http://Stream_Manager_ip_addressThe Stream Manager Login page is displayed.
Step 9
If you are unable to log in with the username admin and the password admin, do the following:
a.
[root]#/home/stats/runonceb.
The CDSM Setup page is displayed.
Step 10
•
•
Installing and Configuring the Vaults, Caching Nodes, or Streamers
To install the TV CDS software and initially configure each Vault, Caching Node, or Streamer, do the following:
Step 1
Step 2
So that your password for root is not the default password, use the passwd command to change the password used.
Step 3
[root]# ./cdsinstallYou should see something similar to this:
Continuing first-time installation after kickstart using image //CDS-TV.isoSelect Deployment Type (ctrl-c to quit):1) ISA2) RTSP/FSI1ISA SelectedMounting //CDS-TV.iso at /mnt/cdromCalling inst.sh for isaKilling running processes: statsdUn-taring isa-base.tgzCalling forprod.shRemoving RTSP-specific filesInstalling ISA-specific files (existing files backed up to .file)ISA installation completeStarting fixperms.shLoading File ListProcessing File ListEnding fixperms.shUnmounting /mnt/cdrominst.sh completed, removing .iso imageStep 4
[root]# ./cdsinstall CDS-TV-2.1.4.isoYou must reboot the system after running the install script. When the system has rebooted, login as root and continue with Step 5.
Step 5
[root]# cdsconfigYou should see something similar to this:
Please ensure an IP address and netmask are configured formanagement interface eth0:Select an option or an interface to re-configure/disable:1. eth0 ip:172.22.99.237 mask:255.255.254.0 bcast:172.22.99.2552. Configure another interface3. DoneChoice [3]:Step 6
Step 7
Step 8
Step 9
Step 10
Select an option or an interface to re-configure/disable:1. eth0 ip:172.22.99.238 mask:255.255.254.0 bcast:172.22.99.2552. Configure another interface3. DoneChoice [3]:Step 11
Backing up old scripts in /etc/sysconfig/network-scriptsWriting new ifcfg-ethX scriptsStep 12
Step 13
Step 14
Backing up /etc/sysconfig/networkWriting new /etc/sysconfig/networkBacking up /etc/hostsWriting new /etc/hostsShutting down interface eth0: [ OK ]Shutting down loopback interface: [ OK ]PCI: Enabling device 0000:0e:00.0 (0000 -> 0003)PCI: Enabling device 0000:0e:00.1 (0000 -> 0003)Restarting network services, this may take a minute:Shutting down loopback interface: [ OK ]Bringing up loopback interface: [ OK ]Bringing up interface eth0: [ OK ]Network services restarted; may take a few seconds to establish connectivityReboot for hostname changes to take effectNetwork configuration completeUse detected platform: CDE420-4A-C ? (yes/no) [y]: yUse detected platform: CDE420-4A-C ? (yes/no) [y]: yStep 15
Please select a device role:1. ssv2. Vault3. cache4. StreamerStep 16
Step 17
Step 18
Enter Stream Control interface (Hit 'Enter' to skip): eth1Writing new configuration to /home/isa/.arroyorcNo existing replication group information foundDo you want to configure replication group members now? (yes/no) [y]: yesThere are currently no replication group members.Do you want to add another replication group member? (yes/no) [y]: y
Note
In the following example, the configuration of the CDS devices shows generalized input values. The option for the VVIM and Stream Manager is called "Controller." Add the VVIM and Stream Manager as a replication group members, as well as the Vaults, Caching Nodes, and Streamers.
Select a role for the new replication group member:1. ssv2. Vault3. cache4. Streamer5. ControllerStep 19
Step 20
Current replication group members:Vault 172.22.99.239Do you want to add another replication group member? (yes/no) [n]:Step 21
Configuring ISA ecosystem/home/isa/Berkeley/status_db:dbstatus: Subscript out of range.Starting statsdRun svrinit to seed database? (yes/no) [n]: yStep 22
Note
a.
b.
c.
Writing rc.localISA ecosystem configuration finishedcdsconfig finished, please use CDSM to complete configuration[root@v238 ~]#If you receive an error message saying the database is unavailable and cannot set things up, enter the following command to initialize the database tables:
[root]# su - isa (For ISA deployments only.)[isa]# exit[root]# /home/stats/svrinit_15 -h <hostname> -i <ip address> -s <mask-ip address>
Note
Note
Step 23
a.
http://XXX.XXX.XXX.XXXThe VVIM or CDSM Login page is displayed.
b.
The System Health Monitor page is displayed showing the devices and their IP address.
The TV CDS software installation is complete.
Upgrading to Release 2.1
This section includes the following topics:
•
•
•
•
Note
Release 2.1 introduces the ability to route interfaces to different subnets. After upgrading the TV CDS software to Release 2.1, any servers with incompatible routes are listed in red on the Route Tables page. You can review the Route Table configuration for each of these servers, modify or delete the routes, and click Submit to apply the changes. The routes are converted to the Release 2.1 format and the server is listed in black. When all servers with incompatible routes are fixed, the warning message is removed and the entry in the system alarm drop-down list in the GUI banner is removed.
Release 2.1 also introduces the ability to configure up to 16 DNS servers on each of the System Level, Array Level, and Server Level DNS pages. After upgrading the TV CDS software to Release 2.1, any DNS entries need to be resubmitted. When all DNS entries are resubmitted, the warning message is removed and the entry in the system alarm drop-down list in the GUI banner is removed.
Note
Note
A high-level view of the CDS software upgrade procedure is as follows:
1.
2.
Repeat for every Streamer on the site starting with the "Available" Streamers, followed by the "Backup" Streamer, and ending with the "Primary" Streamer.
3.
Caution
Note
Upgrading from Release 1.5.1.x
Note
The Cisco technician will have the following items to upgrade your software to Release 2.1:
•
•
•
•
•
•
•
Note
Upgrade the Software on the CDSM
Upgrading the software on the CDSM has the following main tasks:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Upgrade the Software on Each Streamer and Vault
Note
In a multi-site CDS, upgrade all the Vaults using the same procedural order as the Streamers (offload, upgrade, reboot, and online). Start the Vault upgrade at the Control sites, then finish with the Setup/Control site.
Upgrading the software on a Streamer or a Vault has the following main tasks:
1.
2.
3.
4.
5.
6.
7.
8.
Note
# killall -HUP inetd
If this is not done, you will receive the error "setpriority: Permission denied" in the ns_log when ISA services are starting up. The ISA services will still be up but the default priority will be (0).
Upgrading from Release 2.0 to Release 2.1.4
Upgrading the CDSM and CDS servers from Release 2.0 to Release 2.1.4 involves the following steps:
1.
2.
3.
4.
5.
Note
After upgrading the TV CDS software to Release 2.1, any servers with incompatible routes are listed in red on the Route Tables page. You can review the Route Table configuration for each of these servers, modify or delete the routes using the information you recorded, and click Submit to apply the changes. For more information, see either the Cisco TV CDS 2.1 ISA Software Configuration Guide or the Cisco TV CDS 2.1 RTSP Software Configuration Guide.
The following procedures are covered in this section:
•
•
•
Getting a Software File from Cisco.com
To get a software file from Cisco.com, do the following:
Step 1
http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=268438145
The Log In page is displayed.
Step 2
Step 3
Step 4
Step 5
Step 6
•
•
The Download page is displayed with the information about the software image file and a Download link.
Step 7
Step 8
Step 9
Step 10
Upgrade the Software on the CDSM
Note
To upgrade the software on the CDSM, do the following:
Step 1
Step 2
# scp 172.22.98.111:/images/2.1/CDS-TV-2.1.4.iso /rootStep 3
# scp 172.22.98.111:/images/2.1/cdsinstall /rootStep 4
# ./cdsinstall CDS-TV-2.1.4.isoSelect Deployment Type (ctrl-c to quit):1) ISA2) RTSP/FSI3) CDSM4) CDSM with ISA--- Output omitted ---Step 5
# rebootStep 6
ps -ef | grep avsdb
Upgrade the Software on Each Streamer and Vault
Perform this procedure for each Vault and Streamer in the CDS.
Note
In a multi-site CDS, upgrade all the Vaults using the same procedural order as the Streamers (offload, upgrade, reboot, and online). Start the Vault upgrade at the Control sites, then finish with the Setup/Control site.
Note
For Vaults:
•
For Streamers:
•
•
To upgrade the software on a Vault or Streamer, do the following:
Step 1
a.
b.
c.
Step 2
a.
b.
c.
Step 3
Step 4
# scp 172.22.98.111:/images/2.1/CDS-TV-2.1.4.iso /rootStep 5
# scp 172.22.98.111:/images/2.1/cdsinstall /rootStep 6
# ./cdsinstall CDS-TV-2.1.4.isoSelect Deployment Type (ctrl-c to quit):1) ISA2) RTSP/FSI3) CDSM4) CDSM with ISA--- Output omitted ---Step 7
a.
b.
c.
Step 8
a.
b.
Step 9
a.
b.
c.
Step 10
Upgrading from Release 2.1.3 to Release 2.1.4
Note
Upgrading the CDSM and CDS servers from Release 2.1.3 to Release 2.1.4 involves the following steps:
1.
2.
3.
4.
5.
The following procedures are covered in this section:
•
•
•
Upgrading a VVI from Release 2.1.3 to Release 2.1.4
A high-level view of the VVI software upgrade procedure is as follows:
1.
2.
[isa@vault220 ~/IntegrationTest]$ ./show_calypso_services********************************************************************** ContentStore (SLAVE) Services Status ************************************************************************ContentStoreSlave ======> Running************************************************************************************************************************************************************************************Follow the "Upgrade the Software on Each Streamer and Vault" procedure. When all SHEs are upgraded, there will be Vaults running Release 2.1.4 coexisting with Caching Nodes and Streamers running Release 2.1.3.
3.
a.
b.
c.
d.
[root@s65 root]# cat /proc/calypso/status/streamer/resiliencyinfoStreamer Resiliency Info:Service Address: 172.22.98.50Control Service: Primary
Note
Getting a Software File from Cisco.com
To get a software file from Cisco.com, do the following:
Step 1
http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=268438145
The Log In page is displayed.
Step 2
Step 3
Step 4
Step 5
Step 6
•
•
The Download page is displayed with the information about the software image file and a Download link.
Step 7
Step 8
Step 9
Step 10
Upgrade the Software on the CDSM
Note
To upgrade the software on the CDSM, do the following:
Step 1
Step 2
# scp 172.22.98.111:/images/2.1/CDS-TV-2.1.4.iso /rootStep 3
# scp 172.22.98.111:/images/2.1/cdsinstall /rootStep 4
# ./cdsinstall CDS-TV-2.1.4.isoSelect Deployment Type (ctrl-c to quit):1) ISA2) RTSP/FSI3) CDSM4) CDSM with ISA--- Output omitted ---Step 5
# rebootStep 6
ps -ef | grep avsdb
Upgrade the Software on Each Streamer and Vault
Perform this procedure for each Vault and Streamer in the CDS.
Note
In a multi-site CDS, upgrade all the Vaults using the same procedural order as the Streamers (offload, upgrade, reboot, and online). Start the Vault upgrade at the Control sites, then finish with the Setup/Control site.
To upgrade the software on a Vault or Streamer, do the following:
Step 1
a.
b.
c.
Step 2
a.
b.
c.
Step 3
Step 4
# scp 172.22.98.111:/images/2.1/CDS-TV-2.1.4.iso /rootStep 5
# scp 172.22.98.111:/images/2.1/cdsinstall /rootStep 6
# ./cdsinstall CDS-TV-2.1.4.isoSelect Deployment Type (ctrl-c to quit):1) ISA2) RTSP/FSI3) CDSM4) CDSM with ISA--- Output omitted ---Step 7
a.
b.
c.
Step 8
a.
b.
Step 9
a.
b.
c.
Step 10
Adding a Second CDSM
To implement the CDSM Redundancy feature available in Release 2.1, do the following after upgrading all existing servers to Release 2.1:
Step 1
The operating system boots.
Step 2
Note
Step 3
[root]# ./cdsinstallThe following prompt is displayed:
Continuing first-time installation after kickstart using image //CDS-TV.iso Select Deployment Type (ctrl-c to quit):1) ISA2) RTSP3) CDSM4) CDSM with ISA3CDSM Selected... Output omitted ...Unmounting /mnt/cdrominst.sh completed, removing .iso image==================================================Configure the system for initial installation ==================================================Step 4
# scp -r 172.22.98.109:/arroyo/db/DATADIR /arroyo/dbStep 5
For more detail about the cdsconfig script, see the "Installing and Configuring the Stream Manager" section.
Step 6
# vi /etc/rc.local#!/bin/sh## This script will be executed *after* all the other init scripts.# You can put your own initialization stuff in here if you don't# want to do the full Sys V style init stuff.touch /var/lock/subsys/local# Lines below this one modified by cdsflavconfig (ISA):su - isa -c "cd /home/isa/IntegrationTest"sleep 30/arroyo/www/bin/apachectl startsleep 30su - isa -c "cd /home/isa/RTScheduler/Exporter; ./ExporterServer >& /home/isa/RTScheduler/Exporter/ExporterServer.log&"/home/stats/statsd -i 172.11.99.100 -s 255.255.255.0 -d eth0sleep 30Step 7
# rebootStep 8
a.
b.
$ vi /home/isa/.arroyorc# Local settingsself 2groupid 400serverid 141partno 3U-SCSI-10mirroring 0mgmtif 0ingestif 1# Database Paramsdbdomsock /tmp/isadbdbnetport 9999# Replication Group MembersVault 111.0.110.40controller 111.0.110.42c.
[root]# su - isa (For ISA deployments only.)[isa]# exit[root]# /home/stats/svrinit_15 -h <hostname> -i <ip address> -s <mask-ip address>
Note
Updating the Device Drivers for new SSDs
The SSD driver update is for new SSDs and to address an issue with older SSDs. For more information, see the "Important Notes" section.
If a CDE requires an SSD replacement, the device driver must be updated. The device driver must be updated before replacing the SSD. If a new CDE is being added to the CDS, after upgrading the TV CDS software, the device driver must be updated. New SSDs are not recognized with the proper attributes until the device driver is updated.
Note
To view a list of TV CDS software releases this device driver applies to see the defect, CSCtr29064, in the Bug Tool Kit ((http://tools.cisco.com/Support/BugToolKit/).
Note
To install the device driver update package, do the following:
Step 1
Note
Following is the md5 checksum for the cdstv_x.y.z_CSCtr29064.bin driver update package:
89684e2094d841b236ba1d83e958df9b cdstv_x.y.z_CSCtr29064.binThe driver update package is a self-extracting, self-installing package.
Step 2
# chmod 755 /root/cdstv_x.y.z_CSCtr29064.binStep 3
# cd /root# ./cdstv_x.y.z_CSCtr29064.binThe package installs the device driver.
Step 4
Step 5
cd /lib/module/`uname -r`/sbin/modinfo -F version csd.ko cdd_sys.koThe updated driver files report the same version for both driver files in the format of x.y.z.1, where x.y.z is the version of the TV CDS software (for example, 2.3.3.1).
Step 6
# reboot
Note
A new SSD drive is a Generation 2 front-mounted SSD. The new SSD model is identified by the title "Intel SSD 320 Series" on the label and has the model number: SSDSA2BW160G3. For more information, see Field Notice 63438 at: http://www.cisco.com/en/US/products/ps7126/prod_field_notices_list.html.
The following command provides information on the external SSDs that are the new drive model:
# find /sys/devices -name "model" | xargs grep SSDSA2BW16/sys/devices/pci0000:80/0000:80:05.0/0000:87:00.0/host3/port-3:7/end_device-3:7/target3:0:7/3:0:7:0/model:INTEL SSDSA2BW16/sys/devices/pci0000:80/0000:80:05.0/0000:87:00.0/host3/port-3:6/end_device-3:6/target3:0:6/3:0:6:0/model:INTEL SSDSA2BW16/sys/devices/pci0000:80/0000:80:05.0/0000:87:00.0/host3/port-3:5/end_device-3:5/target3:0:5/3:0:5:0/model:INTEL SSDSA2BW16/sys/devices/pci0000:80/0000:80:05.0/0000:87:00.0/host3/port-3:4/end_device-3:4/target3:0:4/3:0:4:0/model:INTEL SSDSA2BW16/sys/devices/pci0000:80/0000:80:05.0/0000:87:00.0/host3/port-3:3/end_device-3:3/target3:0:3/3:0:3:0/model:INTEL SSDSA2BW16To view all SSD models currently supported by the Cisco TV CDS software, enter the following command:
# find /sys/devices -name "model" | xargs grep SSDSAThe older SSD model is INTEL SSDSA2M160.
Rolling Back the SSD Driver Update
If for any reason you need to revert to the older SSD driver, with the TV CDS software running on the CDS server, do the following:
Step 1
cd /lib/module/`uname -r`Step 2
cp csd.ko csd.ko.updatecp cdd_sys.ko cdd_sys.ko.updateStep 3
cp csd.ko_bkup_<previous_version> csd.kocp cdd_sys.ko_bkup_<previous_version> cdd_sys.koStep 4
/sbin/modinfo -F version csd.ko cdd_sys.koThe drivers before the driver update have a version in the format of a.b.c and the two drivers do not necessarily have the same version number.
Step 5
Related Documentation
Refer to the following documents for additional information about the Cisco TV CDS 2.1:
•
•
•
http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_1/developer_guide/tv_cds_2_1_apiguide.html
•
http://www.cisco.com/en/US/docs/video/cds/overview/CDS_Roadmap.html
•
•
http://www.cisco.com/en/US/docs/video/cds/cde/cde110/installation/guide/cde110_install.html
•
http://www.cisco.com/en/US/docs/video/cds/cde/installation/guide/CDE_Install_Book.html
•
http://www.cisco.com/en/US/docs/video/cds/cde/regulatory/compliance/CDE_RCSI.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.
CCDE, CCENT, CCSI, Cisco Eos, Cisco Explorer, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2011 Cisco Systems, Inc. All rights reserved.
