Cisco Service Router Application Configuration Guide

Preface
This preface describes the audience, use, and organization of the Cisco Internet Streamer CDS 3.2
Software Configuration Guide. The preface also outlines the document conventions and support
information.
This preface contains the following sections:
•
Document Revision History, page xvii
•
Audience, page xvii
•
Objective, page xviii
•
Document Organization, page xviii
•
Document Conventions, page xix
•
Related Publications, page xx
•
Obtaining Documentation and Submitting a Service Request, page xx
Document Revision History
The Document Revision History table below records technical changes to this document.
Document Version
Date
Notes
OL-29021-01
March 2013
Added Generic Session Tracking and Logging and Origin
Server Failover enhancement
OL-27552-02
September 2012
Added Multicast Cloud feature and External System Alarms
Reporting enhancement.
OL-27552-01
August 2012
Initial release.
Audience
This guide is for the networking professional managing the Cisco Internet Streamer Content Delivery
System, hereafter referred to as the CDS. Before using this guide, you should have experience working
with the Cisco IOS software and be familiar with the concepts and terminology of Ethernet, local area
networking, and Internet streaming.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
xvii
Preface
Objective
This guide provides the information you need to configure and monitor the Cisco Internet Streamer CDS.
This guide provides procedures for using the commands that have been created or changed for use with
the Cisco Internet Streamer CDS. It does not provide detailed information about these commands.
This guide does not describe system messages you might encounter or how to install your CDS. See the
“Related Publications” section on page xx for links to documentation online.
For documentation updates, see the release notes for this release.
Document Organization
This document contains the following chapters and appendices:
Chapter or Appendix
Description
Chapter 1, “Product Overview”
Provides a brief introduction to the Internet Streamer
CDS.
Chapter 2, “Network Design”
Describes the CDS topology, elements of a delivery
service, and the delivery service workflow.
Chapter 3, “Getting Started”
Provides information about initially configuring the
devices to communicate with the CDSM, configuring a
standby CDSM, navigating the CDSM, and a typical
configuration workflow.
Chapter 4, “Configuring Devices”
Provides information on configuring the devices in the
Internet Streamer CDS.
Chapter 5, “Configuring Services”
Provides information about configuring delivery
services.
Chapter 6, “Configuring the System”
Provides information on system configuration for the
Internet Streamer CDS.
Chapter 7, “Monitoring the Internet
Streamer CDS”
Provides information on monitoring the Internet
Streamer CDS.
Chapter 8, “Maintaining the Internet
Streamer CDS”
Provides information on upgrading the Internet Streamer
CDS software, deleting devices from the system,
performing disk maintenance, and removing content from
the system.
Appendix A, “Troubleshooting”
Discusses troubleshooting Service Routers, and the
acquisition and distribution of content.
Appendix B, “Creating Manifest Files”
Provides information on creating and validating a
Manifest file.
Appendix C, “Creating Coverage Zone
Files”
Provides information on creating and validating a
Coverage Zone file.
Appendix D, “Creating Geo/IP Files”
Provides information on creating Authorization Service
files.
Appendix E, “Creating CDN Selector
Files”
Provides information on creating CDN Selector XML
files.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
xviii
Preface
Chapter or Appendix
Description
Appendix F, “Creating Service Rule Files” Provides information on creating Service Rule XML
files.
Appendix G, “ABR Session-Based
Encryption and Session Tracking”
Provides information on Session-Based Encryption and
Session Tracking.
Appendix H, “Creating NAS Files”
Provides information on creating NAS XML files.
Appendix J, “CLI Commands”
Provides information on configuring port channels, last
resort routing domains, and other CLI commands.
Appendix I, “URL Signing and Validation” Describes the URL signing script for URL signature
creation at the portal.
Appendix K, “Verifying the Internet
Streamer CDS”
Describes procedures for verifying the Internet Streamer
CDS using the different media players.
Appendix L, “Software Licensing
Information”
Provides information about the software licenses for the
Internet Streamer CDS.
Document Conventions
This guide uses the following conventions for command syntax descriptions and textual emphasis:
Convention
Description
boldface font
Commands and keywords are in boldface.
italic font
Arguments for which you supply values are in italics.
[ ]
Elements in square brackets are optional.
{x | y | z}
Alternative, mutually exclusive, keywords are grouped in braces and
separated by vertical bars.
[x | y | z]
Optional alternative keywords are grouped in brackets and separated by
vertical bars.
string
A nonquoted set of characters. Do not use quotation marks around the string
or the string will include the quotation marks.
screen
font
Terminal sessions and information the system displays are in screen font.
boldface screen
italic screen
Caution
font
font
Information you must enter is in boldface screen font.
Arguments for which you supply values are in italic screen font.
^
The symbol ^ represents the key labeled Control—for example, the key
combination ^D in a screen display means hold down the Control key while
you press the D key.
< >
Nonprinting characters, such as passwords, are in angle brackets in contexts
where italics are not available.
!, #
An exclamation point ( ! ) or a pound sign ( # ) at the beginning of a line of
code indicates a comment line.
Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
xix
Preface
Note
Means reader take note. Notes contain helpful suggestions or references to materials not contained in
this publication.
Tip
Means the following information might help you solve a problem.
Related Publications
These documents provide complete information about the CDS and are available from the Cisco.com
site:
•
Cisco Internet Streamer CDS 3.2 API Guide
•
Cisco Internet Streamer CDS 3.0–3.1 Quick Start Guide
•
Cisco Internet Streamer CDS 3.2 Command Reference
•
Cisco Internet Streamer CDS 3.2 Alarms and Error Messages Guide
•
Release Notes for Cisco Internet Streamer CDS 3.2
•
Cisco Internet Streamer CDS 3.0–-3.1–-3.2 Software Installation Guide for non-CDEs
•
Cisco Content Delivery Engine 205/220/250/420 Hardware Installation Guide
•
Cisco Content Delivery System 3.x Documentation Roadmap
•
Regulatory Compliance and Safety Information for Cisco Content Delivery Engines
•
Open Sources Used in CDS IS Release 3.1
You can access the software documents at the following URL:
http://www.cisco.com/en/US/products/ps7127/tsd_products_support_series_home.html
You can access the hardware documents for the CDEs at the following URL:
http://www.cisco.com/en/US/products/ps7126/tsd_products_support_series_home.html
You can access the hardware documents for non-CDEs at the following URLs:
•
Cisco UCS C200 Installation and Service Guide
http://www.cisco.com/en/US/docs/unified_computing/ucs/c/hw/C200M1/install/c200M1.html
•
Cisco UCS C210 Installation and Service Guide
http://www.cisco.com/en/US/docs/unified_computing/ucs/c/hw/C210M1/install/C210M1.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 the following URL:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
xx
Preface
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.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
xxi
Preface
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
xxii
CH A P T E R
1
Product Overview
This chapter provides an introduction to the Cisco Internet Streamer Content Delivery System (CDS).
This chapter has the following major topics:
•
Overview, page 1-1
•
Content Delivery System Architecture, page 1-5
Overview
The Cisco Content Delivery System (CDS) is a distributed network of Content Delivery Engines (CDEs)
running Content Delivery Applications (CDAs) that collaborate with each other to deliver multi-format
content to a variety of client devices. The client devices supported are personal computers and
Wi-Fi-enabled mobile devices, such as personal digital assistants (PDAs).
The CDS supports a variety of mechanisms to accelerate the distribution of content within the content
delivery network. The CDS offers an end-to-end solution for service providers to ingest and stream
entertainment-grade content to subscribers.
The CDS functionality can be separated into four areas:
•
Ingest
•
Distribution
•
Delivery
•
Management
Each CDE in the CDS contributes to one or more of these functions as determined by the CDAs running
on it. Table 1-1 describes the relationship between the CDA names and the Internet Streaming Content
Delivery System Manager (CDSM) device names.
Table 1-1
CDA Mapping to Functionality and CDSM
CDA Name
Functionality
Internet Streamer (+ Content Acquirer) Ingest, distribution, and delivery
CDSM Device Name
Service Engine (SE)
Service Router
Redirect client requests for delivery Service Router (SR)
Internet Streaming Content Delivery
System Manager
Management
CDSM
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-1
Chapter 1
Product Overview
Overview
The Service Engine can function as a Content Acquirer and Internet Streamer, or just as an Internet
Streamer.
Figure 1-1 shows the major elements of a CDS network. How content flows, from ingest to distribution
within the CDS, to delivery to client devices, is dictated by the content delivery services defined for each
Content Origin. A delivery service is a configuration defined by using the CDSM and consists of
configuration parameters that dictate how content is ingested and distributed, and what content is
delivered to the client devices. Some of the primary delivery service definition parameters are:
•
Origin server
•
Service routing domain name
•
Service Engines participating in the delivery service
•
Service Engine designated as the Content Acquirer
The Content Acquirer is only active on one Service Engine in each delivery service.
Figure 1-1
High-Level View of the Cisco CDS
metadata
ten
t
gE
Gi
Service Engine
Internet Streamer
Gi
gE
Access point
t
ten
con
Origin
servers
Service Engine
Internet Streamer
metadata
Content
provider
con
Asset
Management
System
GigE
Switched
network
management
Gi
gE
Service Engine
Content Acquirer
Service Router
Proximity Engine
GigE
Service Engine
Internet Streamer
Switched
network
E
Gi
management
CDSM
CMTS
CMTS
CMTS
Geo-Location
servers
Access point
ig
G
gE
GigE
RF
RF
HFC
RF
GigE
Service Router
Request Routing Engine
DNS
servers
Modem
209787
Access point
The following sections briefly describe the elements of the CDS. For more detailed information, see the
“Content Delivery System Architecture” section on page 1-5.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-2
Chapter 1
Product Overview
Overview
Ingest and Distribution
The Service Engine designated as the Content Acquirer for a delivery service is the ingest device. Cisco
Internet Streamer CDS supports the following methods of content ingest:
•
Prefetch ingest
•
Dynamic ingest
•
Hybrid ingest
•
Live stream ingest and split
The distribution of content within the CDS is determined by the method of ingest used.
Note
The recommended maximum number of prefetched content items is 200,000.
Prefetch Ingest
The Content Acquirer receives metadata from the backoffice in the form of an XML-formatted Manifest
file and, using the information in the file, pulls the content into storage on the Content Acquirer. The
content can be ingested by using different protocols. The supported protocols are FTP, HTTP, HTTPS,
and CIFS, which are files copied to the Service Engine. The ingested content is then distributed to all
Service Engines in the content delivery service. The content is stored on each Service Engine’s hard disk
for a configurable amount of time or until the content entry gets deleted from the Manifest file. This is
called content pinning.
The Manifest file can be used to specify different policies for content ingest and also for streaming the
prefetched content. For example, the policy could include specifying the expiry of the content, setting
time windows in which the content is made available to users, and so on.
Note
The maximum number of content files that can be prefetched on each SE is 200,000. The content type
(MIME) value cannot exceed 32 characters.
Dynamic Ingest
Content can be dynamically ingested into the CDS. Dynamic ingest is triggered when a Service Engine’s
Internet Streamer application does not find a client’s requested content in its local hard disk storage. All
Service Engines participating in the content delivery service coordinate to form a content distribution
tunnel starting at the origin server and ending at the Service Engine responding to the client request. As
the content flows through this tunnel, the participating Service Engines cache a copy of the content.
Subsequent requests for the same content are served off the CDS network. Content ingested and
distributed by this method is deleted if clients do not request it frequently.
The Internet Streaming CDSM manages this ingest method internally, not by instructions embedded in
a Manifest file, and manages the storage automatically. The Internet Streaming CDSM also provides the
ability to purge any dynamically ingested content out of the Service Engines. Content is identified by a
URL, which is also used to delete the content.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-3
Chapter 1
Product Overview
Overview
Hybrid Ingest
The hybrid ingest method provides a very powerful solution by combining the features of the prefetch
ingest and the dynamic ingest methods. The metadata and control information about the content, defined
in the Manifest file, is propagated and pinned to all Service Engines participating in the content delivery
service. However, the content is not prefetched. Ingest occurs upon user request for the content. Content
that is cached on the Service Engines by using this method is subject to the same deletion rules as the
dynamic ingest method. The metadata that is propagated can be used to specify explicit controls and
policies for streaming the content.
Live Stream Ingest and Split
The live stream ingest method distributes a live content feed to all the Service Engines participating in
the content delivery service and helps to scale the content delivery to a very large audience. This method
leverages the live stream splitting capabilities of the Internet Streamer application and optimizes the
access by doing a one-to-many split to all Service Engines in the content delivery service. The Internet
Streaming CDSM provides the necessary interface to schedule the streaming of live programs. Advanced
techniques are used to enhance the performance of live streaming.
Delivery
The Service Router handles client requests for content and determines the best Service Engine to deliver
it based on proximity, load and health states.
Once the best Service Engine has been determined, the content is delivered to the client device by means
of one of the following mechanisms:
•
Static Content Download using HTTP—Content is downloaded by the client device before it can
be rendered to the user.
•
Progressive Content Download using HTTP—Content is rendered in segments to the user before
it has been fully downloaded.
•
Content Streaming using HTTP, RTMP, RTSP, or RTP—Content is streamed to the client device,
Service Engines collect feedback and can fine-tune streaming. Advanced error recovery can also be
performed. This is a very common method of streaming video content to client devices.
Table 1-2 lists the content types and formats, content transport protocols, and client types supported by
the CDS.
Table 1-2
Supported Content Types
Content Types and
Formats
Transport
Protocols
Typical Client Types
Access
Network Type
Windows Media
RTP,
(WMA, WMV, ASF, RTSP,
and others) VC-1
HTTP
Windows Media Player 9, 10, 11 on PC
Windows Media Player 9 for Mac
Windows Media Technology (WMT) Silverlight
Wired
Wi-Fi
Cellular
QuickTime (MOV),
hinted (3GP) files
On PC: QuickTime Player, QuickTime Pro 6 or 7, Wired
Wi-Fi
RealPlayer 10 or 11 (3GP only), VLC player
On Mac: QuickTime Player, QuickTime Pro 6 or Cellular
7, RealPlayer 10 for Mac OS X (3GP only)
RTP,
RTSP,
HTTP
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-4
Chapter 1
Product Overview
Content Delivery System Architecture
Table 1-2
Supported Content Types (continued)
Content Types and
Formats
Note
Transport
Protocols
Typical Client Types
Access
Network Type
Other Hypertext and HTTP
image files (HTML,
JPEG, and so on)
Web browsers and other HTTP clients
Wired
Wi-Fi
Cellular
MPEG (MP1, MP2,
MP4)
RTP,
RTSP
MPEG clients
Wired
Adobe Flash (SWF,
FLV, MP3)
RTMP,
HTTP
Adobe Flash Player 9 for Windows, Mac OS, and Wired
Linux
Wi-Fi
Cellular
H.264
RTMP,
HTTP
H.264 clients
Note
Note
For Flash Media Streaming, the Adobe
Flash Media Player 9 update 3, Adobe
Media Player, and Adobe Air, are the only
players that support MPEG-4.
Wired
For Flash Media Streaming, the Adobe
Flash Media Player 9 update 3 is the only
supported player.
RTMP is part of the Flash Media Streaming feature.
Management
The Internet Streaming CDSM, a secure Web browser-based user interface, is a centralized system
management device that allows an administrator to manage and monitor the entire CDS network. All
devices, Service Engines and Service Routers, in the CDS are registered to the Internet Streaming
CDSM.
Service Engines can be organized into user-defined device groups to allow administrators to apply
configuration changes and perform other group operations on multiple devices simultaneously. One
device may belong to multiple device groups.
The Internet Streaming CDSM also provides an automated workflow to apply a software image upgrade
to a device group.
Content Delivery System Architecture
The CDS consists of an Internet Streaming CDSM, one or more Service Engines, and one Service
Router. For full redundancy, a CDS would include an additional CDSM and Service Router. The Service
Engine handles content ingest, content distribution within the CDS, and content delivery to client
devices. The Service Router handles client requests and redirects the client to the most appropriate
Service Engine. The Internet Streaming CDSM manages and monitors the CDS, the delivery services,
and all the devices in the CDS.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-5
Chapter 1
Product Overview
Content Delivery System Architecture
This section covers the following topics:
•
Service Engine
– Storage and Distribution
– Stream and Cache-Fill Performance
– NAS
– Content Acquirer
– Internet Streamer
•
Service Router
•
Content Delivery System Manager
•
Resiliency and Redundancy
Service Engine
Each Service Engine can function as a Content Acquirer and Internet Streamer, or just as an Internet
Streamer. Based on the Service Engines’ assignments to different delivery services, the right set of
applications supporting the functions is enabled. For example, only one Service Engine is assigned the
role of Content Acquirer in each delivery service. In addition, the Service Engine assigned as the Content
Acquirer in a delivery service also includes the functions of an Internet Streamer.
Storage and Distribution
Both the Content Acquirer and the Internet Streamer applications have storage and distribution functions
within the CDS, which include the following:
•
Management of the physical storage of content and metadata. Content URLs are translated into their
physical file paths for content retrieval, deletion, and update.
•
Management of dynamically ingested content and periodic replacement of content not accessed
frequently. Content replacement is performed by sophisticated content-replacement algorithms. The
algorithms add “weight” to the content according to size, frequency of access, and other attributes
to produce the list of content that needs to be purged.
•
Ingest of prefetched content and retrieval of such content for distribution to other Service Engines
in the same delivery service.
•
Maintenance of information about the entire CDS topology and all the delivery services. This
includes upkeep of a list of Service Engines in the same delivery service that is used for distributing
prefetched, dynamic, and live stream content.
•
Maintenance of the database that stores and distributes metadata about the content, and the topology
and delivery service information.
•
Distribution of content on a per-delivery service basis, where the flow path of content could differ
from one delivery service to another.
FastCAL
The Content Abstraction Layer (CAL) library provides an interface to the Content Delivery Network File
System (CDNFS). The CAL library monitors the content in the CDNFS and communicates with the
Content Manager process to evict less popular content.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-6
Chapter 1
Product Overview
Content Delivery System Architecture
The Fast Content Abstraction Layer (FastCAL) library provides quick response time for
high-performance Web Engine create, update, lookup, and delete operations. All other protocol engines
and modules, including live streaming for Flash Media Streaming and RTSP gateway, continue to use
the CAL library and Unified Namespace (UNS) process. Flash Media Streaming VOD (prefetched,
hybrid and dynamically cached content) use FCAL by way of the Web Engine. FastCAL communicates
with the Content Manager for popularity tracking. Lookup notifications are also sent from FastCAL to
the Content Manager.
Disk Path
FastCAL creates the disk path for cache content. An example of a disk path with an HTTP content URL
of http://171.71.50.9/vod/foo.flv is the following:
/disk11-01/c/171.71.50.9/1d/a1/1da1394af838bbcb45af78fd5681abeb/foo.flv.http
The disk path for the prefetched HTTP content URL, http://171.71.50.9/vod/c5.flv, translates to the
following:
/disk03-01/p/171.71.50.9/1d/a1/1da1394af838bbcb45af78fd5681abeb/c5.flv
Disk Allocation
Disk usage for all disks is maintained in shared memory, which is updated by Content Manager with
actual disk usage and by FastCAL when new content is created. FastCAL creates predefined buckets,
which are groups of disks. The number of disks per bucket varies, and the number of buckets varies; it
is determined by the CDE model.
The CDNFS disk mount point always displays as diskXX-YY, where XX is the disk number and YY is
the partition. Every content URL is always associated with the same bucket, so lookup, create, and delete
always happen within the same bucket. This method avoids searching all disks on the CDE. If a bucket
has no disks (because of disk failure, unmounting of the disks, and so on), content is served from the
network. The incoming traffic to the SE is distributed evenly to the buckets, which means if the number
of available disks in a bucket is less than the other buckets, the other disks in the impaired bucket are
used more, which may impact performance.
Bucket Allocation
A hashing algorithm is used to generate a hash of the content URL, on which a calculation is performed
to determine the bucket for the content. This ensures content is distributed evenly among all the buckets.
Content Manager
The Content Manager module keeps track of all the files in CDNFS, and maintains all content popularity
information and stores it in a snapshot file. Content Manager includes the following enhancements:
•
Improve cache content storage from 10 million to 20 million content objects
•
Increase maximum length of URL to 2048 characters
Note
In calculating the maximum length of the URL (2048 characters), an MD5 hash must be
considered as part of the overall URL length, and therefore the maximum length of the URL
should not exceed 2028 characters.
•
Continue to manage cache content objects for all protocol engines
•
Maintains share memory containing disk related information
•
Monitors disk usage periodically and starts eviction when usage exceeds threshold
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-7
Chapter 1
Product Overview
Content Delivery System Architecture
Note
•
Receives updates on disk information based on CMGRSlowScan process, which scans the entire
system over a 12-hour period
•
Receives updates on each disk during start-up from CMgrSnapshotReader
We recommend that any CDE model that has hard-disk drives (HDDs) (instead of solid-state drives
[SSDs]), and is used to stream ABR content, be configured with a maximum of 5 million objects instead
of the default of 20 million. This is because HDD-based hardware requires more seek time to access
content. The software can handle 20 million objects, but the hard-drive access time impacts the ABR
streaming performance. ABR content consists of a large number of small files, which results in a lot of
overhead.
For long-tail content (Windows Media Streaming, Flash Media Streaming, Movie Streamer, and
progressive download), the maximum number of content objects can be configured with the default of
20 million on the HDD-based hardware models.
Two of the HDD-based hardware models are the CDE220-2G2 and CDE250-2M0.
Content Types
Content Manager manages content object types in the following ways:
•
Cache content—Maintains file information such as disk path, file size, and priority
•
Prefetched content—Maintains prefetched file disk path in memory to manage the number of
prefetched assets in the system
•
Hybrid content—Handles the same as cache content, maintains file information
•
Related content—Maintains information on parent content disk location, aggregated size and hit
count
Create
When a file is created (added), FastCAL library updates Content Manager with the file location, URL,
file size, and hit counts.
If the cache-fill rate (creation rate) is much faster than the deletion rate, Content Manager sets the
unwritable flag for that disk. If a protocol engine wants to create content in the system, FastCAL avoids
using that disk for the file creation. If all disks are unavailable, the protocol engine performs a bypass or
cut-through operation.
Content Manager sets the disk unwritable flag for the following reasons:
•
Disk usage reaches the DiskStopCreate high watermark (98 percent)
•
Total cache content objects reaches the ObjCntStopCreate high water mark (105 percent)
•
Deletions exceeds 5000 entries
Content Manager removes the disk unwritable flag when the following occurs:
•
Disk usage is below the DiskStartCreate low watermark (95 percent)
•
Content object count is below the ObjCntStartCreate low watermark (100 percent)
•
Deletion entries drop below 5000
The status of whether the cache content can be stored is displayed in the show cdnfs command.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-8
Chapter 1
Product Overview
Content Delivery System Architecture
Update
Content Manager monitors the cached and prefetched content, but not live content. FastCAL updates the
content creation time (if created), hit count, file size, and disk path information in Content Manager
when there is a popularity update call from the protocol engine. Whenever there is a cache content
popularity update, Content Manager stores the popularity information and the file path of the content,
and computes the popularity (priority) of the content. If the update is a prefetched content popularity
update, Content Manager ignores the message, but continues to monitor the prefetched URL for
statistics.
Because of the Web Engine capability to do request bundling, multiple requests can be severed by a
single datasource. The datasource keeps track of the requests that get served off from it and calls the
popularity update at the end of its lifecycle (before eviction of datasource).
Delete and Eviction
Deletion operating is when a file is deleted through the CLI or by the protocol engine. FastCAL library
deletes the content object from disk first, then sends a message to Content Manager to remove the entry
for the deleted content object. If the message is lost, Content Manager deletes the entry by way of the
sanity check which runs after Slow Scan (CMGRSlowScan) is finished or through the eviction process.
The Content Manager is involved in evicting content. If the disk usage high-watermark is reached,
Content Manager starts the eviction process by deleting cached content with the lowest priority first. If
the protocol engine uses FastCAL to delete the content, FastCAL deletes the content and updates the
Content Manager.
Note
The disk path is maintained in a hierarchical manner by breaking down disk path with directory node
(Dir Node) and file node (File Node). If the number of Dir Nodes exceeds the limit (one million), the
Content Manager starts evicting files in a similar process to object count eviction.
Priority Calculation
The priority calculation is based on the current hit count, the size of the content object, and the decay of
the content object. The popularity of the content decays over a period of time if the content is not
accessed.
By default, Content Manager prefers to keep small content objects over large content objects, because
the overhead of fetching a small object is higher than larger objects. However, this preference is
configurable in the following ways:
•
CDSM GUI: Devices > Devices > General Settings > Content Management page, Cache content
eviction preferred size drop-down list
•
CLI: cache content eviction-preferred-size {large | small}
Deletion Scenarios
There are five scenarios in which Content Manager removes content:
1.
Disk usage exceeds threshold.
2.
Content objects exceed the cache content max_cached_entries command value.
3.
Delivery service or SE is removed from the CDSM GUI.
4.
Disk is removed or marked as “bad.”
5.
The clear cache all command is entered.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-9
Chapter 1
Product Overview
Content Delivery System Architecture
The first two can be categorized as priority-based content eviction, the following two can be categorized
as top-down tree-structure deletions, and the last one can be categorized as a forking deletion. In all
scenarios Content Manager removes all entries for the associated content, and deletes all content from
storage (with the exception of disk removal).
Disk Usage Exceeds Threshold
Content Manager keeps track of disk usage. If disk usage reaches the disk usage high watermark
(93 percent), Content Manager starts the eviction process. When the disk usage reaches the disk usage
low watermark (90 percent), the eviction process stops. The eviction process is based on the following
criteria:
•
Priority of the content on each disk
•
Available space on each disk
Content Count Exceeds Maximum Allowed
The default maximum number of cache content objects is 20 million. If the maximum limit is exceeded,
Content Manager starts the eviction process.
Delivery Service or SE Removal
If a delivery service is removed from the CDSM or an SE is deregistered from a delivery service, Content
Manager creates a deletion task and starts deleting all associated cache content. For prefetched content,
Content Manager removes all references, and Acquisition and Distribution handles the content object
deletion.
Disk Removal or Disk Marked as Bad
If a disk has gone “bad” and is removed from the system, UNS is notified. UNS internally calls FastCAL,
which notifies Content Manager. The content object information is removed from Content Manager.
Content Manager also monitors the disk status every three seconds, and if a disk is removed, Content
Manager removes all associated entries for it.
clear cache all Command
If the clear cache all command is entered, the Content Manager creates a child process to delete the
cache content. The progress of the clear cache all operation is shown in the show cache command output.
Addition and Deletion Processes
Content addition stops at 105 percent of the maximum object count or 95 percent of the CDNFS capacity
(disk usage). For example, if the maximum number of objects has been configured as 20 million (which
is the default value), the CDS starts deleting content if the object count reaches 20 million, but adding
content is still allowed. Adding content stops when the maximum number of content objects reaches
21 million(105 percent of 20 million), which allows time for the content deletion process to reduce the
number of objects in the CDS to the configured limit. Adding content resumes only after the number of
objects is 20 million or less. The same logic applies to disk usage. The deletion process starts when disk
usage reaches 93 percent, adding content stops when disk usage reaches 98 percent, and adding content
resumes only after the disk usage percentage reaches 95 percent or less.
If adding content has been stopped because either the content count reached 105 percent of the limit or
the disk usage reached 98 percent of capacity, the unwritable flag is set in the share memory and when
the protocol engine calls create, FastCAL library looks into the share memory and denies the creation
request. The protocol engine performs a bypass or cut-through operation.
The show cdnfs usage command shows the current status of whether the content is able to be cached or
not. Following is an example of the output:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-10
Chapter 1
Product Overview
Content Delivery System Architecture
# show cdnfs usage
Total number of CDNFS entries :
2522634
Total space
:
4656.3 GB
Total bytes available
:
4626.0 GB
Total cache size
:
2.4 GB
Total cached entries
:
2522634
Cache-content mgr status
: Cachable
Units: 1KB = 1024B; 1MB = 1024KB; 1GB = 1024MB
If the maximum object count is reached, the following is displayed:
Cache-content mgr status: Not cacheable on the following disk(s): [/disk00-06]
[/disk01-06] [/disk02-01]
105% of max obj count reached :
[/disk00-06] [/disk01-06] [/disk02-01]
If the disk usage reaches more than 98 percent, the following is displayed:
Cache-content mgr status: Not cacheable on the following disk(s): [/disk01-06]
[/disk02-01]
98% of disk usage reached:
[/disk01-06] [/disk02-01]
Eviction Protection
Content Manager provides configurable eviction protection for some content. The Content Manager
eviction algorithm is triggered when the disk usage reaches 93 percent or when the cached object count
reaches the configured maximum object count. The eviction algorithm assigns a priority number to each
content object based on an algorithm similar to the greedy-dual-size-frequency (GDSF) algorithm. The
priority number is based on the size and usage of the object. Small objects are given preference over large
objects; that is, they are less likely to be deleted.
To protect incoming large objects from getting a low priority and being deleted, use the cache content
eviction-protection global configure command. The cache content eviction-protection command
allows you to set the minimum content size (100 MB, 500 MB, 1 GB, and 4 GB) and the minimum age
(1–4 hours for 100 MB size, 1, 4, 8, or 24 hours for all other sizes) of the content object to be protected
from deletion. For example, to set the eviction protection for content objects larger than 100 MB that
were ingested in the last two hours, you would enter the following command:
#(config) cache content eviction-protection min-size-100MB min-duration-2hrs
If the content object being cached is larger than the configured size, it is inserted into a protection table
along with the current time stamp. If the difference between the object’s time stamp and the current time
is greater than the configured time duration, the object is removed from the protection table. If the
eviction algorithm is triggered, before it selects an object for deletion, it first looks at the protection
table, and if the object is found, it is skipped for that iteration. The clear-cache-content command also
check the protection table before deleting an object. The clear-cache-all command does not check the
eviction protection table; cache content is just deleted. As for relative cache content, content in the
protection table might still be deleted if the relative content that is not protected is deleted. The eviction
protection is disabled by default.
If the Content Manager eviction algorithm is not able to find any content to delete, a syslog message is
sent to notify the administrator to revisit the configuration. Changing the settings of the cache content
eviction-protection command only affect the content that are currently in the protection table and any
new content that is added. Any object that is removed from the protection table prior to the configuration
change is not brought back into the protection table.
Reloading the SE or entering the no cache content eviction-protection min-size-xx duration-xx
command removes all entries in the eviction protection table.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-11
Chapter 1
Product Overview
Content Delivery System Architecture
Note
Changing the time on the SE affects the Content Manager eviction process. If the time is set forward,
content is deleted sooner than expected. If the time is set back, content is protected longer.
The show cache content command displays the eviction protection status and the number of elements
in the eviction protection table.
Web Engine Integration with FastCAL
Web Engine calls FastCAL directly for content creation, lookup, update, and deletion.
CAL Queue Limits
The CAL queue is limited to 3000 tasks on the CDE250 and 1500 tasks on all other CDEs. When the
CAL queue threshold is exceeded, Web Engine does not add anymore disk operation tasks (creates,
updates, or popularity updates) and a trace message is logged with the following string:
Reason: CalQThreshold Exceeded!
A new output field, "Outstanding Content Popularity Update Requests," has been added to the show
statistics web-engine detail command. At any point, the sum of the "Outstanding Content Create
Requests," "Outstanding Content Update Requests," and "Outstanding Content Popularity Update
Requests" output fields is always less than the threshold. If the sum of these three output fields exceeds
the CAL queue threshold, no more create, update, and popularity update tasks are performed, the
"Reason: CalQThreshold Exceeded!" trace message is logged, and content is served as follows:
•
Large content files are served by way of bypass
•
Small content files are served from tmpfs and the files are evicted from tmpfs without moving them
to disk
UNS Integration with FastCAL
UNS is the process that is called by other modules like CMS, Acquisition and Distribution, and
Streamscheduler to access the CDNFS content by way of the CAL–UNS client library. UNS still handles
Movie Streamer and Windows Media Streaming content (both prefetched and cached), and live
streaming content for Flash Media Streaming.
UNS uses FastCAL for any disk-based operation. Content Manager and FastCAL handle accounting of
disk usage and new content allocation to the disks for all modules.
Stream and Cache-Fill Performance
The Stream and Cache-Fill feature improves performance in the following ways:
•
QoS support. Using QoS together ensures that sessions receive either best effort or a guaranteed rate
while not exceeding overall system capacity.
•
File-level hole management is supported, allowing partially-filled files to be streamed, and
multiple-parallel fills and streams to be attached to the same file at various offsets.
•
Higher performance data transmission engine provides better throughput
Hole management is not used for small files, because the sessions are over quickly, and the entire file is
always downloaded from the Origin server. Encrypted HLS traffic and HTTPS traffic do not use the
Stream and Cache-Fill components, because HTTPS traffic is encrypted in the user space, and encrypted
HLS traffic is similar to small ABR files.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-12
Chapter 1
Product Overview
Content Delivery System Architecture
With ABR large files, files are either stitched from fragments or they are natively large files. Clients are
more likely to stop streaming from an ABR large file when they shift bit rates, so files may have holes.
Hole management and QoS optimize the serving of large ABR files. There is a large improvement in
performance with ABR large files and the Stream and Cache-Fill feature.
Large file progressive download traffic is similar to large ABR files, but the client is likely to stay on a
bit rate longer because it does not automatically adjust its rate. This traffic type also sees a large
performance improvement, for the same reasons as large ABR files.
Stream and Cache-Fill Feature Components
Stream and Cache-Fill feature consists of the following components:
•
QoS Types
•
Hole Management
QoS Types
The Stream and Cache-Fill feature adds support for the following QoS classes:
•
Note
Hard Guaranteed (HG)—Flows assigned a bit rate that is maintained under any circumstances. The
bandwidth allocated for these sessions is never reused by other sessions. HG is not directly
selectable.
HG is not supported in Release 3.1.
•
Soft Guaranteed (SG)—Flows assigned a fixed bit-rate, unlike HG, any unused bandwidth assigned
can be reused by other sessions. SG and best effort (BE) flows can continue to be admitted even if
the total requested SG rate exceeds system capacity, as long as the total measured rate does not
exceed the total system capacity. This is a statistical guarantee in the sense that it is expected to be
guaranteed in most circumstances.
•
Best Effort (BE)—Depending on whether the traffic is VOD or live, the bandwidth allocation
behaves differently.
– In the VOD case, all BE streams are given an equal share of any disk bandwidth left over after
guaranteed sessions are satisfied.
– In the live case, each BE client is allowed to stream at a rate limited only by CPU and network
interface bandwidth.
The system has an administratively-defined minimum best-effort rate for VOD BE sessions. New
sessions are only admitted if the global best-effort rate does not fall below the minimum. This way
the SE does not stream countless sessions at very low bit-rates.
•
On any given SE, live BE traffic cannot be mixed with any other type of QoS, but VOD BE can be
mixed with guaranteed QoS types.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-13
Chapter 1
Product Overview
Content Delivery System Architecture
Table 1-3 summarizes the different QoS types in the CDS. The types listed in bold are introduced with
this feature.
Table 1-3
Supported QoS Types
QoS Type
Minimum Guaranteed
Rate
Hard Guaranteed
(HG)
Protocol Engine
requested rate
Maximum Rate
Other Compatible
QoS Types
Protocol Engine requested rate
SG, BE
(not supported in
Release 3.1)
Soft Guaranteed (SG) Delivery service bitrate Delivery service bitrate
HG, BE
Best Effort VOD
(BE-VOD)
Globally configured
minimum
(Total disk rate - Total (SG +
SG
HG) rate) / number BE sessions
Best Effort Live
(BE-live)
None
Determined by CPU and
network cards
None
Fixed Bit Rate
None
Delivery service bitrate
None
Best Effort
None
Determined by CPU, network
cards and disk
None
There is no performance penalty for using any QoS type. The QoS types are defined indirectly through
the delivery services.
QoS statistics can be viewed by using the show statistics admission command.
Note
Only admission statistics can be cleared. QoS statistics are dynamically measured quantities rather than
counters; and therefore, cannot be cleared.
Hole Management
Although hole management is not directly visible as a feature to the user, it has a great impact on system
behavior. The basic ideas of hole management are as follows:
•
Multiple fills can run on a single file at different offsets
•
Play request is considered a hit either if the entire request range is filled, or a currently active fill
will eventually fill that range
•
Maximum number of holes per file is limited for file system robustness reasons
Holes in a file are created in two cases:
1.
If the last client aborts the session and fills are still going to the file.
2.
When fills are aborted for some other reason like the Origin server drops the connection.
In either case, hole management is equipped to handle these holes by starting fills as needed to bridge
holes and limit the total number of holes in a file if required.
When a client aborts a session, any associated fill task normally continues to completion, until either the
entire hole is filled or until the end of file. The exception to this is when no more clients are playing the
file. In this case, all fills are aborted.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-14
Chapter 1
Product Overview
Content Delivery System Architecture
NAS
Network-attached Storage (NAS) is supported as a read-only storage respository at the root location
(Content Acquirer) in the CDS. Content is written to NAS by an external agent, such as the Origin
Server, a publishing subsystem, or a data storage application. NAS offers a new content category, similar
in characteristics to dynamically-cached content, which does not require metadata attachment.
Note
NAS is only supported in lab integrations as proof of concept.
The following rules apply to NAS support:
•
NAS cannot be used as a source for prefetched or hybrid content.
•
Only content serviced by the Web Engine is supported (HTTP content and Flash Media Streaming).
Note
Note
NAS for Windows Media Streaming and Movie Streamer is not supported.
•
Only Network File System (NFS) mounts are supported for acquiring content from NAS.
•
Content acquired from NAS is not written to local storage on the SEs at the root location; when
reading content, NAS is considered an extension of the local file system.
•
If there is more than one SE at a root location for a delivery service, then the SE that acquires the
content from NAS is based on a hash of the content URL (similar to dynamically-cached content).
•
NFS share can be mounted from multiple IP addresses simultaneously.
•
Multiple mounts for the same volume on a NAS is supported.
•
NAS should be colocated with the SEs at the root location; if WAN link is used, then WAN link
failover scenario should be provided.
•
IP address failover by NAS should be implemented to avoid service disruption.
•
NAS is not applicable to live streaming.
•
NAS lookup is tried before pulling content from the Origin Server.
•
When Web Engine performs FastCAL lookup, NAS file lookup is performed first; followed by
cached content, then prefetched content.
•
In a cache-miss scenario, the Origin Server is queried last.
Ingress traffic from NAS mounts is not distributed evenly over port channels. Separate interfaces can be
used for NAS outside of the port-channel configuration to achieve better load balancing. Ingress traffic
to the CDS is determined by the switch, this applies to all application traffic over port channels.
Content Acquirer
Every delivery service requires a Content Acquirer, which is a CDA that resides on every Service
Engine. The Content Acquirer CDA becomes active when the Service Engine is designated as the
Content Acquirer in a delivery service. The Content Acquirer has the following functions and
capabilities:
•
Fetches content from origin servers using HTTP, HTTPS, FTP, or CIFS (Dynamic ingest supports
HTTP only).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-15
Chapter 1
Product Overview
Content Delivery System Architecture
•
Creates and distributes the metadata for each of the prefetched contents according to the Manifest
file and the information returned by the origin server.
Once the Content Acquirer has ingested the content and distributed the metadata, it creates a database
record for the metadata and marks the content ready for distribution. All other types of ingest (dynamic,
hybrid, and live stream) are handled by the Content Acquirer as well.
Internet Streamer
All Internet Streamers participating in a delivery service pull the metadata from a peer Internet Streamer
called a forwarder, which is selected by the internal routing module. Each Internet Streamer
participating in a delivery service has a forwarder Internet Streamer. The Content Acquirer is the
top-most forwarder in the distribution hierarchy. In the case of prefetched ingest, each Internet Streamer
in the delivery service looks up the metadata record and fetches the content from its forwarder. For live
or cached content metadata, only the metadata is distributed.
The content associated with the metadata for live and cached content is fetched by the specified protocol
engine, which uses the dynamic ingest mechanism. When a request for a non-prefetched content arrives
at an Internet Streamer, the protocol engine application gets the information about the set of upstream
Internet Streamers through which the content can be acquired. In the case of dynamic ingest, the Internet
Streamer uses the cache routing function to organize itself as a hierarchy of caching proxies and
performs a native protocol cache fill. Live stream splitting is used to organize the Internet Streamers into
a live streaming hierarchy to split a single incoming live stream to multiple clients. The live stream can
originate from external servers or from ingested content. Windows Media Engine, Movie Streamer
Engine, and Flash Media Streaming engine support live stream splitting.
The Internet Streamers use service control to filter and control incoming requests for content. The
service rules and Authorization Server with IP address and geographic-location blocking are some of the
functions that are encapsulated under the Service Control option in the Internet Streaming CDSM.
The Internet Streamers send keep-alive and load information to the Service Router that is participating
in the same delivery service. This information is used by the Service Router to choose the most
appropriate Internet Streamer to handle the request.
The Internet Streamer function is implemented as a set of protocol engine applications. The protocol
engine applications are:
•
Web Engine
•
Windows Media Streaming Engine
•
Movie Streamer Engine
•
Flash Media Streaming Engine
Web Engine
All HTTP client requests that are redirected to a Service Engine by the Service Router are handled by
the Web Engine. On receiving the request, the Web Engine uses its best judgment and either handles the
request or forwards it to another component within the Service Engine. The Web Engine, using HTTP,
can serve the request from locally stored content in the CDS or from any upstream proxy or origin server.
An HTTP client request that reaches the Service Engine can either be from a Service Router redirect or
from a direct proxy request.
On receiving an HTTP request for content, the Web Engine decides whether the content needs to be
streamed by the Windows Media Engine, and if so, hands the request over to the Windows Media Engine,
otherwise the request is handled by the Web Engine. Message size between Web Engine and Windows
Media Streaming is 12 KB.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-16
Chapter 1
Product Overview
Content Delivery System Architecture
Note
The Web Engine supports the following:
•
Optimization for small content objects
•
Optimization of Adaptive Bitrate Streaming for Move, Apple Iphone, and Smooth HD
•
Move video on-demand (VOD) streaming
•
Move live streaming
•
MP3 live streaming
•
Interoperation with Apple’s media stream segmenter, as well as Microsoft’s Internet Information
Services 7.0 (IIS7.0) Smooth Streaming.
– Apple’s media stream segmenter segments encoded media into separate files for streaming to
iPhones.
– Microsoft’s IIS Smooth Streaming offers adaptive streaming of high-definition (HD) content.
•
HTTP GET and HEAD request methods.
Bursts of traffic (such as 800 connections per second) may cause the Web Engine to become disabled
before it can transmit notification to the SR that the threshold has been reached.
When the content file is smaller than the chunk size, UKSE sends the entire file immediately. In this case,
UKSE does not check pacing; therefore, the bit rate for files smaller than the chunk size is not honored.
Cache-Fill Operations
The Web Engine interfaces with the storage function in the Service Engine to determine whether the
content is present locally or whether the content needs to be fetched from either an upstream Service
Engine or the origin server.
The Web Engine communicates to the upstream Service Engine for cache-fill operations. This
interaction is based on HTTP. This cache-fill operation is on demand and hence only occurs when the
content is not stored locally. The upstream Service Engine can be selected dynamically by means of the
Hierarchical Cache Routing Module, or can be configured statically through the Internet Streaming
CDSM. The Hierarchical Cache Router generates a list of upstream Service Engines that are alive, ready
to serve the request, and part of the delivery service. If the Web Engine is unsuccessful in locating the
content on one of these Service Engines, the content is retrieved from the origin server.
Note
When cache-control:no-store is sent in a 200 response from the Origin server, the Web Engine respects
the no-store header and does not cache the content. However, if no-store is appended to the cache-control
header in a 304 response, the no-store header does not trigger deletion of the content from the disk. The
304 response only triggers updating the cache with the recent header attributes sent in the 304 response
header.
The Web Engine supports request headers and entity headers as described in the HTTP 1.1 specification
(RFC-2616). The Web Engine allows CDS domain and HCACHE custom headers only when sent from
an SE
Web Engine respects the following date formats:
•
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
•
Sun Nov 6 08:49:37 1994
; ANSI C's asctime() format
The following format is obsolete and is not supported:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-17
Chapter 1
Product Overview
Content Delivery System Architecture
•
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
If the headers (for example, the expiry header) comes in with a non-supported date format, Web Engine
continues to cache the content, but subsequent requests for the same URL are revalidated as the content
is considered expired.
Whether the content is found locally or retrieved and stored through the cache-fill operation, the Web
Engine serves the content based on the following:
•
Freshness of content—The freshness of prefetched content is governed by a time-to-live (TTL)
value set for the content in the delivery service configuration. The TTL specifies the rate at which
content freshness is checked. This setting is configured for each delivery service either by using the
CDSM or by specifying this setting in the Manifest file for the delivery service.
For cached content, which is content ingested by means of the dynamic ingest or the hybrid ingest
method, the freshness check is performed by the Web Engine in compliance with RFC 2616. If the
origin server does not provide an expiry time, the Web Engine uses the age multiplier setting, the
minimum TTL setting, and the maximum TTL setting to determine the freshness of the content. If
the Web Engine performs the calculation and determines the content should be checked for freshness
with the origin server, and the origin server is unreachable, the client receives a 504 error.
Note
This algorithm is used to determine freshness for cached content based on the expire time. It is
not used to determine the popularity of the content.
This expiry header validation is just one case to decide whether content revalidation is needed
or not. Revalidation is also decided based on cache control headers that are part of request
headers, and the min-fresh, max-stale, max-age parameters that can come in both request and
response headers.
Revalidation is enabled by default for the Web Engine.
If the origin server provides the expire time, it is used to determine the freshness of the content. If
the expire time is not available, the expire time of the content is calculated as follows:
Expire_time = (Create_time – Last_modified_time_from_origin_server) * age multiplier
The create time is the time on the CDS when the content was cached. The last modified time is the
time the content was last modified on the origin server. The age multiplier value (as a percentage)
is used to shorten the time it takes to have the content revalidated.
For example, if the create time was May 5, 2009 12:00 and the origin server last modified the content
on May 1, 2009 12:00, then the expire time would be 4 days. If the age multiplier was set to 50
percent, the expire time would be 2 days.
The calculated expire time is compared with the minimum TTL and maximum TTL settings. If the
expire time is greater than the maximum TTL, the maximum TTL is used as the expire time. If the
expire time is less than the minimum TTL, the minimum TTL is used as the expire time.
Using the example above, if the minimum TTL was 3 days and the calculated expire time was 2 days,
then the minimum TTL is used as the expire time. If the maximum TTL is 10 days, then the
calculated expire time still uses the minimum TTL of 3 days as the expire time. The min/max TTL
algorithm follows:
Expire_time = if (MINTTL < Expire_time < MAXTTL), then Expire_time
else if Expire_time < MINTTL, then MINTTL
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-18
Chapter 1
Product Overview
Content Delivery System Architecture
else MAXTTL
The expire time is compared with the cache age in order to determine whether the content needs to
be revalidated by the origin server. If the cache age is less than or equal to the expire time, then the
content is considered fresh. The following calculation is used to determine the cache age:
Cache_age = Current_time – Create_time
In our example, if the current time is May 25, 2009 12:00 and the create time is May 5, 2009 12:00,
then the cache age is 20 days. The cache age of 20 days is compared to the expire time, which in our
example is 2 days, and because the cache age is greater than the expire time the content is revalidated
with the origin server. When the content is revalidated it gets a new create time. To compute a more
accurate cache age, the response delay is considered. The response delay is calculated as follows:
Response_delay = Create_time – Time_request_sent_to_origin_server
In our example, the create time is May 5, 2009 12:00, and if the origin server takes 2 minutes to
respond to the request for content (because of network-imposed delays), the response delay is May
5, 2009 11:58. This allows the cache age to be calculated based on the time the request was initiated,
not the time the response was received.
•
Rate of data transfer—The rate at which the content is sent can be configured on a per-delivery
basis. By default, LAN bandwidth is used.
•
Content completeness—Prefetched content is stored locally in the CDS in its entirety. For cached
content, there are two cases when the content is not complete:
– The Web Engine process halts or the Service Engine experiences a failure in the process of
caching the content. In this case, the subsequent request starts the cache fill anew.
– The content is in the process of being cached by another request. In this case, the subsequent
request is served from the cached content.
Per-Request HTTP Headers from Redirected URLs
When the CDS is integrated with products such as the Content Adaptation Engine (CAE), Service
Engines are used to serve over-the-top content. In such scenarios, the CDS provides HTTP headers
similar to that of the Origin server. The information in the HTTP header can be unique to a user session.
The CAE retrieves this information from the Origin server response and provides it as a query parameter
within the URL. This information is intact when received by the Service Engine following redirections
from the CAE and Service Router. The Web Engine retrieves the “_resp_hdrs_” value from the received
URL. The retrieved value is % unescaped, and parsed for use when serving the content.
As indicated in RFC-2396, a query parameter cannot contain the reserved characters ;/?:@&=+,$ and
thus are escaped using % encoding. The query string must have the “_resp_hdrs_” tag. A URL with the
“_resp_hdrs_” tag has the following format:
http://<URL to serve>?_resp_hdrs_=<strings to include in the http headers>
Following is an example of a URL with the “_resp_hdrs_” tag and value:
http://nas_url_to_serve?_resp_hdrs_=Set-Cookie%3A%20ff%3DrlsBo4v%3B%20path%3D/%3B%20
domain%3D.site.com
HTTP Error Response Caching
Caching HTTP error responses from the Origin Server provides the Web Engine with the ability to
validate incoming requests faster and reduce unnecessary access to the Origin Server.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-19
Chapter 1
Product Overview
Content Delivery System Architecture
As an example, the Origin Server sends back a response with the status “503 Service Unavailable” and
includes the maximum age in the response. The Web Engine caches the response locally, and for any
subsequent client requests for the same content, the Web Engine compares the cached response age with
the maximum age returned in the response. If the cached response is expired, the Web Engine rechecks
the Origin Server; otherwise, the Web Engine sends the cached response to the client.
The HTTP response headers must include the max-age, expiry, etag, and other fields that are required to
determine whether the responses can be cached.The HTTP response headers that can be cached are those
that indicate some error has occurred with respect to the client request (4xx or 5xx status codes).
Note
Error response 416 is not cached when the Origin server responds with Transfer-Encoding:Chunked
header. Whenever the Origin server sends chunked encoding, whatever status is returned, the response
is not cached.
Service Rules
Service rules can be configured that dictate how the Web Engine responds when client requests match
specific patterns. The patterns can be a domain or host name, certain header information, the request
source IP address, or a Uniform Resource Identifier (URI). Some of the possible responding actions are
to allow or block the request, generate or validate the URL signature, or rewrite or redirect the URL.
Note
The following service rule actions are supported for the Web Engine: allow, block, rewrite the URL, no
cache, redirect the URL, resolve the URL, revalidate cache, and validate the URL signature.
Windows Media Streaming Engine
The Windows Media Streaming engine uses Windows Media Technology (WMT), a set of streaming
solutions for creating, distributing, and playing back digital media files across the Internet. WMT
includes the following applications:
•
Windows Media Player—End-user application
•
Windows Media Server—Server and distribution application
•
Windows Media Encoder—Encodes media files for distribution
•
Windows Media Codec—Compression algorithm applied to live and on-demand content
•
Windows Media Rights Manager (WMRM)—Encrypts content and manages user privileges
The Windows Media Streaming engine streams Windows Media content, with the capability of acting
both as a server and as a proxy. It streams prefetched content to the Windows Media Player, acts as a
proxy for client requests, splits a live stream into multiple live streams, and caches content requested
from remote servers.
Windows Media Streaming engine acts as Windows Media Server for prefetched or cached content
stored locally. The request is served by RTSP and HTTP. Windows Media Streaming engine checks with
the storage function on the Service Engine to see whether the content is stored locally; if the content is
not found, Windows Media Streaming engages the Windows Media Proxy.
The WMT Proxy works like the cache-fill operation in the Web Engine. See the “Cache-Fill Operations”
section on page 1-17. There are two options:
•
Hierarchical Caching Proxy—If content is not found locally, Windows Media Streaming checks the
upstream Service Engines first before pulling the content from the origin server.
•
Static Caching Proxy—The administrator statically configures Service Engines as upstream proxies.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-20
Chapter 1
Product Overview
Content Delivery System Architecture
The WMT Proxy accepts and serves streaming requests over RTSP and HTTP.
For information on cache management for Windows Media Streaming, see the “Content Manager”
section on page 1-7.
Fast Start
Fast Start provides data directly to the Windows Media Player buffer at speeds higher than the bit rate
of the requested content. After the buffer is filled, prefetched, cached, or live content stream at the bit
rate defined by the content stream format. Fast Start does not apply to content that is dynamically
ingested. Only Windows Media 9 Players that connect to unicast streams using MMS-over-HTTP or
RTSP can use Fast Start. The Fast Start feature is used only by clients that connect to a unicast stream.
With live content, Windows Media Streaming needs to hold the content in its buffer for a few seconds.
This buffer is used to serve Fast Start packets to subsequent clients that request the same stream as the
initiating first client request. The first client triggers the process, with the subsequent clients benefitting
from Fast Start.
Fast Cache
Fast Cache allows clients to buffer a much larger portion of the content before rendering it. Fast Cache
is supported only for TCP. Windows Media Streaming streams content at a much higher data rate than
specified by the stream format. For example, using Fast Cache, Windows Media Streaming can transmit
a 128-kilobit per second (Kbps) stream at 700 Kbps. This allows the client to handle variable network
conditions without perceptible impact on playback quality. Only MMS-over-HTTP and RTSP requests
for prefetched or cached content support Fast Cache. The speed is determined by the client’s maximum
rate and the configured Fast Cache rate—whichever is smaller.
Fast Stream Start
The first client requesting a live stream often experiences the longest wait time for the content to begin
playing. Users can experience long wait times because of the full RTSP or HTTP negotiation that is
required to pull the live stream from the source. Delays can also occur if the edge Service Engine has
not buffered enough stream data to fill the player’s buffer at the time the content is requested. When the
buffer is not filled, some data to the client might be sent at the linear stream rate, rather than at the Fast
Start rate. With Fast Stream Start, when a live stream is primed, or scheduled and pulled, a live
unicast-out stream is pulled from the origin server to a Service Engine before a client ever requests the
stream. When the first request for the stream goes out, the stream is already in the delivery service.
Caching SDP Files for RTSP Broadcast Live
Live streaming is content that is streamed while it is still being encoded by an encoder. There are two
kinds of Windows Media live streaming
•
Playlist live—One or more content items are streamed sequentially.
•
Broadcast live—Live and prerecorded content can be streamed to more than one client
simultaneously. The SE streams the content to all clients, which does not allow the clients to perform
seeks on the stream.
Streaming is accomplished by using HTTP live or RTSP live. HTTP live uses Windows Media Streaming
Protocol (MS-WMSP) where the wms-hdr in the WMS-Describe-Response describes the content. RTSP
live uses RTSP where the Session Description Protocol (SDP) file in the DESCRIBE response describes
the content.
The RTSP playlist live SDP file cannot be cached because the SDP file keeps changing to reflect the
different content playlists.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-21
Chapter 1
Product Overview
Content Delivery System Architecture
The SDP file for RTSP broadcast live does not change unless the program is stopped, so it can be cached
on the streaming SE. Once the SDP file is cached, it can be used to compose the DESCRIBE response.
No further requests for the SDP file from the upstream server (SE, Content Acquirer, or Origin server)
are necessary.
Note
The SDP file cannot be cached if content requires authorization by either the Origin server or the SE.
Live Stream Splitting
Live stream splitting is a process whereby a single live stream from the origin server is split and shared
across multiple streams, each serving a client that requested the stream. When the first client that
requested the stream disconnects, Windows Media Streaming continues to serve the subsequent
requesting clients until all requesting clients have disconnected. Live stream splitting using content that
is already stored locally is generally better than using content from the origin server; this is because the
Service Engine is typically closer to the requesting clients, and therefore network bandwidth to the origin
server is freed up.
To avoid doing a CAL lookup resolve for each incoming Windows Media Streaming live request, the live
hierarchical splitting URL is cached and is then used by all subsequent Windows Media Streaming live
requests for the same live program.
Note
When using Windows Media Server 2008 as the origin server, the source content type must be a playlist
or encoder type.
Live stream splitting can either be unicast or multicast, depending on the configuration, capabilities and
limitations of the network. Windows Media Streaming can receive and deliver Windows Media content
over IP multicast or unicast transmission in the following combinations:
Note
•
Unicast-In Multicast-Out
•
Multicast-In Multicast-Out
•
Unicast-In Unicast-Out
•
Multicast-In Unicast-Out
For multicast-in (to the SE) to work, the network needs to be multicast-enabled.
Multicast-Out
Windows Media Streaming can be used in a live or rebroadcast program to deliver multicast streams to
client devices. The source of the stream can be multicast, unicast, or a local file. The program can be
scheduled, continuous, or play once. The content can be either live or rebroadcast. Windows Media
Streaming creates a Windows Media file (.nsc) that contains session information including the multicast
IP address, port, time-to-live (TTL), and so on. The client requests the .nsc file using HTTP. Once the
file is downloaded, the client parses it and sends an Internet Group Management Protocol (IGMP) join
to receive the multicast stream. A client can start and stop the stream, but cannot pause, fast-forward, or
rewind it.
Unicast-Out
Windows Media Streaming can act as a broadcast publishing point to deliver live streams,
prefetched/cached content, or content from dynamic ingest, to a requesting client. The source of the
stream can be multicast, unicast, or a local file. Windows Media Streaming can also perform live stream
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-22
Chapter 1
Product Overview
Content Delivery System Architecture
splitting if more than one client requests the same content. The delivery service can be used to simulate
an experience similar to viewing a TV program even if the source of the stream is a Video On Demand
(VOD) file. A client can start and stop the stream but cannot pause, fast-forward, or rewind it. When a
delivery service is configured, a client makes a request to the Windows Media Engine, which is acting
as the Windows Media Server, and Windows Media Streaming checks to see whether the incoming
stream is present. If it is, Windows Media Streaming joins the stream and splits it to the new client. If
the request is the first client request for this stream, Windows Media Streaming sends the request to the
origin server and then serves it to the new client.
ASX Request Handling
Web Engine generates meta-responses for the following Windows Media Streaming ASX requests:
•
Requested Windows Media Streaming asset is prefetched
•
Unicast (.asx) request for Windows Media Streaming live program is scheduled
•
Multicast (.nsc.asx) request for live program is scheduled
When the wmt disallowed-client-protocols command is configured, Web Engine generates the
meta-response based on the protocols enabled. When both RTSPU and RTSPT are disabled, only the
HTTP URL is generated in the meta-response. However, when HTTP is disabled, the generated ASX file
still contains the HTTP URL, so that the content can be served by the Web Engine as a progressive
download (as opposed to live streaming by Windows Media Streaming). For .nsc.asx files, only the
HTTP URL is generated.
VOD ASX Request
Web Engine does lookups for incoming ASX requests in the following manner:
•
If the ASX asset is cached or prefetched, the asset is served.
•
If the ASX asset is not found, Web Engine strips the .asx extension from the URL and performs the
lookup again.
– If the asset is found (after stripping the .asx from the URL), Web Engine generates the
meta-response for the requested Windows Media Streaming ASX request.
– If the asset is not found (after stripping the .asx from the URL), no meta-response is generated
and the request is treated as a cache miss.
Live ASX Request
In the case of a unicast live request or a multicast live request, Web Engine generates the meta-response
for found assets. If the asset is not found, Web Engine generates a “403 Forbidden” error message and
sends it to the client.
NSC Request Handling
An NSC request is a managed live streaming request. When the live program schedule is started, the NSC
content is created by Windows Media Streaming.
For Web Engine lookups of NSC files, CAL returns the NSC file location where the content can be
served from, or returns “Not in Schedule.”
Authentication
Windows Media Streaming supports pass-through authentication. The following authentication
mechanisms are supported in pass-through mode:
•
Anonymous
•
NTLM
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-23
Chapter 1
Product Overview
Content Delivery System Architecture
•
Negotiate (Kerberos)
•
Digest access authentication
With pass-through authentication, Windows Media Streaming establishes a tunnel between the client and
the origin server so that the origin server can authenticate the client.
Bandwidth Management
Bandwidth management of Windows Media content can be controlled by setting limits for incoming and
outgoing bandwidth and session bit rate and Fast Start maximum bandwidth. In addition, in the case of
live streaming, contributing origin servers can by identified to allow incoming content to exceed the
bandwidth check to support high demand scenarios. The Windows Media bandwidth management
capabilities are described in Table 1-4.
Table 1-4
Bandwidth Management Capabilities
Bandwidth
Management
Description
Incoming
Bandwidth
The bandwidth for Windows Media content coming into the Service Engine, from
either an upstream Service Engine or from the origin server.
Outgoing
Bandwidth
The bandwidth for streaming Windows Media content to the end user from the
Service Engine.
Incoming Session The maximum bit rate per session that can be delivered to the Service Engine from
Bit Rate
the origin server or upstream Service Engine.
Outgoing Session The maximum bit rate per session that can be delivered to a client.
Bit Rate
Incoming
Bandwidth
Bypass List
The list of identified hosts allowed to bypass the incoming bandwidth check for
broadcast or multicast live content.
Fast Start
Maximum
Bandwidth
Maximum bandwidth allowed per player when Fast Start is used to serve packets to
each player. Increased bandwidth initially used by the Fast Start feature can
overburden a network if many players connect to the stream at the same time. To
reduce the risk of network congestion caused by the Fast Start feature, limit the
amount of bandwidth the Fast Start feature uses to stream to each player.
Movie Streamer Engine
The Movie Streamer Engine is an open-source, standards-based, streaming server that delivers hinted
MPEG-4, hinted 3GP, and hinted MOV files to clients over the Internet and mobile networks using the
industry-standard RTP and RTSP. Hinted files contain hint tracks, which store packetization information
that tell the streaming server how to package content for streaming.
The Movie Streamer Engine is an RTSP streaming engine that supports Third Generation Partnership
Project (3GPP) streaming files (.3gp). Support of 3GPP provides for the rich multimedia content over
broadband mobile networks to multimedia-enabled cellular phones.
Note
The streaming capability of Movie Streamer Engine only depends on the movie file format or stream
transport type. It is independent of codec types. Movie Streamer supports any client player that can fetch
media streams by way of RTSP or RTP. However, the client player must have the correct codec in order
to render the stream correctly.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-24
Chapter 1
Product Overview
Content Delivery System Architecture
The Movie Streamer Engine can act as both a server and a proxy. It streams prefetched or RTSP-cached
content to RTSP clients, acts as a proxy for client requests, splits a live stream into multiple live streams,
and caches content requested from remote servers.
After the RTSP request comes into the Movie Streamer, the URI in the RTSP request is modified to
reflect the result of the mobile capability exchange. The Movie Streamer checks with the storage
function on the Service Engine to see whether the content is stored locally. If the content is not found or
if an RTSP-cached content version needs freshness validation, the Movie Streamer engages the Movie
Streamer proxy.
In the case of an RTSP-cached content version verification, the Movie Streamer proxy forwards the
DESCRIBE request to the origin server for a response containing the Last-Modified-Time header in the
response. If the Last-Modified-Time matches the cached version, the Movie Streamer streams the cached
content; otherwise, the Movie Streamer proxy forwards the request to the origin server for RTSP
negotiation. Then, a client session and a server session are created.
•
Server session is responsible for connecting to the origin server to fetch the content and cache it
locally. The server session generates the media cache file and the linear hint files.
•
Client session is responsible for streaming the locally cached file to the client.
•
Client and server sessions are separated so that multiple server sessions can be spawned for the same
URL to cache content from different starting points or at faster speeds, or both. This increases the
speed of fetching the content. The client session starts to stream from the cached content that the
server session is writing.
The Movie Streamer proxy works like the cache-fill operation in the Web Engine and the Windows
Media Engine, except for the minimum TTL value. The Movie Streamer’s minimum TTL value is always
zero. See the “Cache-Fill Operations” section on page 1-17. There are two options:
•
Hierarchical Caching Proxy—If content is not found locally, the Movie Streamer checks the
upstream Service Engines first before pulling the content from origin server.
•
Static Caching Proxy—The administrator statically configures Service Engines as upstream proxies.
For information on cache management for the Movie Streamer, see the “Content Manager” section on
page 1-7.
The Movie Streamer supports basic pass-through proxy mode for certain conditions where caching
cannot be performed. Such conditions include, but are not limited to, the Service Engine running out of
disk space.
Transport Types
Prefetched content can be delivered by the non-accelerated method or the accelerated method.
Non-prefetched content (proxied or cached content) is always delivered by the accelerated method. The
content is delivered to the client device by one of the following mechanisms:
•
Non-Accelerated—This method has limited concurrent streams and total throughput, but supports
many transport formats. The non-accelerated method supports the following transport formats:
– RTP over UDP
– Reliable UDP
•
Accelerated—This method supports only RTP over UDP. Content must be reprocessed by the
Movie Streamer Linear Hinter. The linear hinter process can be initiated manually by the
administrator or dynamically triggered by the first request for the content.
The Movie Streamer Linear Hinter process may take a while, so the first request that triggers this process
is served by the non-accelerated method. All subsequent requests are served by the accelerated method.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-25
Chapter 1
Product Overview
Content Delivery System Architecture
The first client request for content that requires proxying or caching experiences a delay, because all
proxying and caching requires the accelerated method.
Live Stream
The Movie Streamer Engine supports multicast reference URLs (Announce URLs) for programs that are
created through the Internet Streaming CDSM. The multicast reference URL, which is in the form of
http://Service Engine IP address/Program ID.sdp, is resolved by the Movie Streamers that are serving
the live program.
QuickTime live typically has a UDP socket pair (for RTP and RTCP) per track, and each client session
typically has two tracks (audio and video).
Note
The following rules apply to live splitting:
1.
For unicast streaming, the client request must be sent by RTSP.
2.
For multicast streaming, the client request must be sent by HTTP.
Authentication
The Movie Streamer Engine supports the Basic authentication mode.
URL Signing
For more information see the “URL Signing” subsection, under the “Flash Media Streaming Engine”
section on page 1-29.
Flash Media Streaming Engine
The Flash Media Streaming engine incorporates the Adobe Flash Media Server technology into the CDS
platform. The Flash Media Streaming engine is capable of hosting Flash Media Server applications that
are developed using ActionScripts, such as VOD (prefetched content, or dynamic or hybrid ingested
content), live streaming, and interactive applications.
Note
The Cisco CDS Flash Media Streaming engine supports the Adobe Flash Media Rights Management
Server (FMRMS) for VOD content; it is not supported for live streaming. Adobe FMRMS protects media
content delivered to Adobe Media Player and Adobe AIR applications. FMRMS is also available for
proxied content, if Adobe supports the content type. For more information about the Adobe Flash Media
Rights Management Server, see www.adobe.com.
Note
CDS supports the Adobe Flash Media Server Administration APIs and the Administration Console that
was built using the Administration APIs. These APIs can be used to monitor and manage the Adobe
Flash Media Server running on a Cisco CDS Service Engine. See the “Configuring Flash Media
Streaming—General Settings” section on page 4-45 for more information.
Upon receiving a client request for VOD content, the edge Service Engine does the following:
•
If the content is present, the edge Service Engine streams it using RTMP.
•
If the content is not present, the edge Service Engine uses HTTP to fetch the content from the origin
server and serves it using RTMP.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-26
Chapter 1
Product Overview
Content Delivery System Architecture
No client information is sent to the origin server. No per-client control connection is present between the
edge Service Engine and the origin server for VOD streaming.
HTTP Requests
Flash Media Streaming encompasses all flash applications, from simple Flash Video (FLV) files to more
complex Small Web Format (SWF) files. All HTTP client requests for SWF files, that are redirected to
a Service Engine by the Service Router, are handled by the Web Engine. The Web Engine, using HTTP,
serves the request from locally stored content in the CDS or from any upstream Service Engine or origin
server. See the “Web Engine” section on page 1-16 for more information.
RTMP Requests
The SWF file is a compiled application that runs on the Adobe Flash Player, and may contain Real Time
Media Protocol (RTMP) calls to FLV, MPEG-4 (H.264), or MP3 files. RTMP calls, in the form of URL
requests, are routed to a Service Engine by the Service Router.
Flash Media Streaming supports RTMP and RTMPE on port 1935 only. RTMPE is the secure flash
streaming technology from Adobe. Encrypted RTMP (RTMPE) is enabled on Flash Media Streaming by
default, and allows you to send streams over an encrypted connection without requiring certificate
management.
Flash Media Streaming also supports RTMPT and RTMPTE on port 80. RTMP Tunneled (RTMPT)
encapsulates the RTMP data within HTTP requests in order to traverse firewalls. RTMP Tunneled
Encrypted (RTMPTE) encrypts the communication channel, tunneling over HTTP.
Note
The Service Router uses RTMP redirection to direct the client’s Flash Player to the best Service Engine
based on load balancing and resiliency. RTMP redirections are supported only by Adobe Flash Player 9.
All older Flash Players do not support RTMP redirection.
Note
For VOD streams, all RTMP calls in the SWF file must be in the following format:
rtmp://rfqdn/vod/path/foo.flv
In this format, rfqdn is the routing domain name of the Service Router, vod is the required directory, and
path is the directory path to the content file that conforms to the standard URL specification.
If you are unable to store the VOD content in the required “vod” directory on your origin server, you can
create a VOD virtual path for all RTMP requests. All client requests for RTMP calls still use the
rtmp://rfqdn/vod/path/foo.flv format for VOD streams, but the SE replaces the “vod” directory with the
string specified in the flash-media-streaming application-virtual-path vod map command.
Use the flash-media-streaming application-virtual-path vod map <mapping string> command on
each SE participating in a Flash Media Streaming delivery service. The mapping string variable accepts
all alphanumeric characters and the slash (/) character, and can be from 1 to 128 characters. For example,
to map the “vod” directory to “media” for the go-tv-stream.com origin server, use the
flash-media-streaming application-virtual-path vod map media command.
If comedy.flv is the content being requested, the RTMP call in the SWF file would be
rtmp://go-tv-stream.com/vod/comedy.flv. The SE would replace the “vod” directory and request
http://go-tv-stream.com/media/comedy.flv from the upstream SE or origin server.
If just the slash (/) character is used to replace the “vod” directory, the SE request would be
http://go-tv-stream.com/comedy.flv.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-27
Chapter 1
Product Overview
Content Delivery System Architecture
For prefetched and cached content, the Flash Media Streaming engine uses RTMP or RTMPE over port
1935. The Flash Media Streaming engine also supports RTMPT and RTMPTE over port 80. For content
that is not found locally, the Flash Media Streaming engine communicates with the Web Engine, that in
turn communicates with the upstream Service Engine for cache-fill operations. See the “Cache-Fill
Operations” section on page 1-17. This interaction uses HTTP. Once the content is in the process of
being retrieved by the Web Engine, the Flash Media Streaming engine uses RTMP to begin streaming
the content.
The following describes the characteristics of caching content using HTTP for RTMP client requests;
1.
Origin server-based cache validation is still honored for the cached content.
2.
Client-side Web Engine rules are bypassed for the RTMP client request.
3.
If HTTP headers from the origin server have the “no-cache” attribute set, content is not cached, and
transparent proxy is performed to stream RTMP.
4.
Transparent proxy from HTTP to RTMP is supported. Flash Media Streaming engine begins RTMP
streaming while content is still being fetched using HTTP proxy mode.
Any HTTP configuration that prevents content from being cached still applies for RTMP requests. The
Flash Media Streaming engine uses multiple HTTP-based range requests in such cases.
Multi-Bit Rate Streaming
Flash Media Streaming supports multi-bit rate streaming, also known as dynamic streaming. Dynamic
streaming offers the ability to adjust the bit rate used to stream video to clients in order to adapt to
changes in network conditions.
Multi-bit rate streaming has the following requirements:
•
Origin server must be running Flash Media Server 3.5
•
Client must be using Flash Media Player 10 or higher
•
Encoder for VOD must be running Flash Media Encoder CS4
•
Encoder for live streaming must be running Flash Media Live Encoder 3
For VOD, the encoder creates different bit rates for the content. For live streaming, the encoder publishes
three streams with different bit rates to the origin server.
With Flash Media Player 10, there are new QoS properties that provide information about the stream and
video performance and network capabilities; for example, when the NetStreamInfoBytesPerSecond field
changes, the client can request a different bit rate for the stream.
The client player sends the command to switch or swap the stream. When network changes occur, the
client sends a switch command to request the content be streamed with a higher or lower bit rate. Swap
is used when swapping streams in a playlist (for example, advertisements). The bit rate change request
works for both VOD and live streaming. The supported formats are H.264 and FLV. The client-side
ActionScripts should use play2() instead of play() for smooth stream transitions.
Flash Media Streaming Proxy
The Flash Media Streaming engine can deliver content acting as an origin server or as a proxy server.
The Flash Media Streaming engine acts as a proxy server when content cannot be cached due to the
origin server’s configuration or due to the Service Engine’s Web Engine configuration. Content is
ingested and distributed using HTTP, whether the client request for the content used HTTP or RTMP.
Note
Any content that does not contain “live” or “vod” in the path is automatically proxied.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-28
Chapter 1
Product Overview
Content Delivery System Architecture
Unicast Streaming
The Flash Media Streaming engine supports unicast flash streaming.
URL Signing
Flash Media Streaming supports signed URLs, which adds additional security. The URL signature
generation is based on a key that is a shared secret between the component generating the URL signature
and the component validating the URL signature. The URL signature can be generated by the Service
Engine, another component external to the Service Engine, or the web portal.
For more information about the URL signatures, see the “Configuring URL Signing Key” section on
page 4-28.
Codecs
Flash Media Streaming supports the On2 VP6 codec, as well as those listed in Table 1-5.
Table 1-5
Codecs Supported in Flash Media Streaming
Standard
Details
ISO/IEC 14496-3
MPEG-4 Part 3, also known as AAC+, HE-AAC. A set of compression codecs
for perpetual coding of audio signals, including some variations of Advanced
Audio Coding (AAC), as well as AAC Main, AAC LC, and SBR.
ISO/IEC 14496-10
Advanced Video Coding (AVC), also known as H.264/AVC.
All levels of applications are supported, Base (BP), Main (MP), High (HiP),
High 10 (Hi10P), and High 4:2:2 Profile (Hi422P).
This standard is technically identical to the ITU-T H.264 standard.
ISO/IEC 14496-12
ISO Base Media File Format. A file format for storing media content
containing one audio track (either ISO/IEC 14496-3 [AACPlus] or MP3), and
one video track (either ISO/IEC 14496-10 [H.264 or AVC] or VP6).
3GPP TS 26.245
Time text format.
Live Streaming
Flash Media Streaming uses RTMP to stream live content by dynamic proxy. Configuration of live or
rebroadcast programs is not required. When the first client requests live streaming content, the stream is
created. There are no limits to the number of live streams other than the system load. Live streaming uses
distributed content routing to distribute streams across multiple Service Engines.
Upon receiving a client request for live content, the edge Service Engine does the following:
•
If the live stream is already present, the edge Service Engine attaches the new client to the existing
stream. No message is sent to the origin server and no connection is set up.
•
If the live stream is not present, CDS creates a connection to the origin server to get the stream. No
client information is sent to the origin server.
No per-client control connection is present between the edge Service Engine and the origin server for
live streaming.
For Flash Media Streaming, a delivery service can be used for prefetched content, cached content,
dynamically cached content, and live content. Because Flash Media Streaming uses dynamic proxy to
stream live content, no disk space is used to store content. A Service Engine can act as the origin server
for streaming live content, provided the SE designated as the origin server is not assigned to the delivery
service that is streaming the live content.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-29
Chapter 1
Product Overview
Content Delivery System Architecture
The Flash Media Streaming engine automatically retries a connection to an upstream Service Engine or
the origin server if the upstream live-splitting connection fails. This switchover does not require any
additional retries from the client side. Clients see a subsecond buffering, after which video continues to
play. This feature does not address switchover when the Service Engine that is streaming to the client
fails. The primary advantage is increased resiliency in the CDS infrastructure. In other words, if a
Service Engine fails, the downstream Service Engine automatically tries to connect to an upstream
Service Engine in the path, and if it fails to connect, then a connection to the origin server is
automatically made.
The Adobe Flash Media Encoder can publish the streams to any Adobe Flash Media Server acting as the
origin server. Clients use the RFQDN to get the live content. The request from the client for
“streamname” is mapped to origin_appinst_streamname internally in the CDS to differentiate between
two streams with the same name in two different delivery services.
Note
All RTMP calls for live content in the SWF file must be in the following format:
rtmp://rfqdn/live/path/foo.flv
In this format, rfqdn is the routing domain name of the Service Router, live is the required directory, and
path is the directory path to the content file that conforms to the standard URL specification.
Flash Media Streaming supports live stream splitting. For more information about live stream splitting,
see the “Live Stream Splitting” section on page 1-22.
Flash Media Streaming Query String
Previously, if an RTMP request had a query string in the URL for VOD, the Web Engine could decide
whether or not to cache the content based on the Web Engine configuration. However, if the query string
in the RTMP URL included the end-user specific parameters and not the stream name, every request
would have a different URL because every user has a different query string. This leads to the same
content getting cached multiple times.
The flash-media-streaming ignore-query-string enable command tells Flash Media Streaming to
remove the query string before forwarding the request to the Web Engine in the case of VOD, or before
forwarding the request to the forwarder SE in the case of live streaming.
If URL signature verification is required, the sign verification is performed before the query string check
is invoked. The URL signing and validation, which adds its own query string to the URL, continues to
work independently of this enhancement.
When the flash-media-streaming ignore-query-string enable command is entered, for every request
in which the query string has been ignored, a message is written to the FMS error log, and the Query
String Bypassed counter is incremented in the output of the show statistics flash-media-streaming
command. The FMS access log on the edge SE contains the original URL before the query string was
removed.
The flash-media-streaming ignore-query-string enable command affects every VOD and live
streaming request and is not applicable to proxy-style requests.
Interactive Applications
Flash Media Streaming supports pass-through (proxy) functionality for interactive applications
(non-VOD and non-live). The interactive applications are hosted on a Flash Media Interactive Server that
is external to the CDS.
Note
For the edge server proxy to function correctly, the origin server must be running Adobe Flash Media
Server 3.5.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-30
Chapter 1
Product Overview
Content Delivery System Architecture
Direct routing from the Service Engine, acting as the Flash Media Streaming edge server proxy, to the
origin server (the Flash Media Interactive Server) is supported by way of the hierarchical path of Service
Engines to the origin server. Every Service Engine that receives the request proxies it to the next SE
along the path, where it reaches the origin server. Using the delivery service framework, the origin server
is abstracted from the client request by using the Service Router Domain Name (SRDN), which resolves
to the Service Engine that accepts the user connection and forwards the request to the origin server. Flash
Media Streaming includes the edge server (proxy) mode, and by default, all non-live and non-VOD
applications are proxied by using the edge server. Flash Media Streaming selectively picks connections
for processing in edge server mode and aggregates connections to the origin servers.
Note
The video and audio content used in an interactive application is cached on the SE acting as the Flash
Media Streaming edge server proxy and is not removed when Flash Media Streaming is disabled. The
maximum storage allowed for cached content associated with interactive applications is 2 GB. The only
way to delete this cached content is to use the clear cache flash-media-streaming command or to reload
the CDS software on the SE.
CDS supports implicit URI as the method that allows the client to connect with the edge server without
exposing the origin server. The URI would look like this: rtmp://edge1.fms.com/ondemand.
Request routing based on SWF files or using RTMP redirection is supported. However, RTMP
redirection requires more changes in the client code. SWF file-based redirection is recommended. SWF
redirection works as follows:
1.
SWF files and associated HTML pages are either prefetched or hosted in the origin server.
2.
Client uses a web browser to access the HTML page, which also loads the SWF file.
3.
SWF file is accessed using the SRDN.
4.
Service Router redirects the request to a Service Engine.
5.
SWF file is downloaded to the web browser.
6.
ActionScript in the SWF file attempts to connect to the same host from where the SWF file was
downloaded. This is an RTMP connection that reaches the Service Engine.
7.
Service Engine checks for the application type in the URI and, if it is not VOD or live, the processing
is moved to the edge server mode and the connection is forwarded to the origin server.
8.
Service Engine tunnels the data between the client and the origin server.
Note
Changes to a delivery service do not affect existing connections to the Flash Media Interactive Server
(origin server). Only new connections are affected by changes to a delivery service.
Note
URL signing for interactive applications is supported. For more information, see the “URL Signing and
Flash Media Streaming” section on page I-13.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-31
Chapter 1
Product Overview
Content Delivery System Architecture
Service Router
The Service Router has three parts:
•
Request Routing Engine
•
Proximity Engine
•
CDN Selector
The Service Router can be configured as both the Request Routing Engine and the Proximity Engine, or
the Service Router can be configured only as the Request Routing Engine. Additionally, the Service
Router can act as a standalone Proximity Engine by not configuring the Request Routing Engine as the
authoritative DNS server.
The Proximity Engine contains the functionality of the Proximity Servers used for proximity-based
routing. See the “Proximity-Based Routing” section on page 1-40 for more information on this routing
method. The Proximity Engine peers with network routers and listens in on route updates to get topology
and routing path information. This information is used to locate the closest resource in the network.
Real-time measurements of reachability and delay are also considered. See the “Proximity Engine”
section on page 1-46 for more information on the Proximity Engine.
CDN Selector
The CDN Selector provides a method of performing third-party streaming service selection. The
third-party streaming service is selected based on the content type of the client request, the geographic
location of the client request, or both. When CDN Selector is enabled, the Service Router uses the
information in the CDN Selector file to determine which third-party streaming service is selected for
servicing the client request.
Note
The CDN Selector is an early field trial (EFT) feature.
A CDN Selector file is an XML file containing the URL, including the directory path, of each third-party
streaming service, and the content types and geographic locations criteria for redirecting client requests.
If the geographic location is used as the selection criteria, the CDN Selector uses the Geo-Location
server to map the client’s IP address to the client’s country.
The Geo-Location server identifies the country of a client by the IP address of the client. The CDN
Selector compares the client’s country with the countries defined in the CDN Selector file. If the client’s
country matches a country specified in the CDSN Selector file, then the translated URL associated with
that CDN is used. If a match is not found, the default CDN is used.
The Service Router then sends a 302 redirect to the client with the translated URL for the selected
third-party streaming service. If the Internet Streamer CDS is chosen, the request is handed over to the
Request Routing Engine for further processing. If the client request does not meet any of the selection
polices criteria and a default CDN is specified in the CDN Selector file, the client request is redirected
to the default CDN.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-32
Chapter 1
Product Overview
Content Delivery System Architecture
Request Routing Engine
The Request Routing Engine mediates requests from the client devices and redirects the requests to the
most appropriate Service Engine. It monitors the load of the devices and does automatic load balancing.
The Request Routing Engine is the authoritative Domain Name System (DNS) server for the routed
request for the fully qualified domain name (FQDN) of the origin server. In other words, the Request
Routing Engine responds to any DNS queries for that domain.
Routing Redirection
There are three ways for client requests to get routed to the Request Routing Engine and on to the Service
Engine:
•
Router fully qualified domain name (RFQDN) redirection
•
DNS-based redirection
•
IP-based redirection
RFQDN Redirection
RFQDN redirection is the default configuration. With RFQDN redirection, client requests are resolved
to the Request Routing Engine by the DNS server and the Request Routing Engine redirects the request
to the Service Engine based on route tables created from the Coverage Zone file and the current load of
the Service Engines. The redirected URL is http://SENAME.SE.RFQDN/relative_path_of_content,
where SENAME is the hostname of the Service Engine.
Note
The redirected URL for Flash Media Streaming requests is:
rtmp://SENAME.SE.RFQDN/application_name/encoded (relative_path_of_streamname), where
SENAME is the hostname of the Service Engine.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-33
Chapter 1
Product Overview
Content Delivery System Architecture
Figure 1-2 describes the Request Routing Engine workflow for RFQDN redirection.
Figure 1-2
Request Routing Engine Workflow for RFQDN Redirection
In Figure 1-2, the client sends a request for a video file (for example, sample.wmv) to
http://video.cds.com. The browser in turn sends a recursive DNS request to resolve video.cds.com
through the DNS proxy.
The Service Router is configured to be the authoritative DNS for video.cds.com. The DNS proxy
resolves video.cds.com to the Service Router’s Request Routing Engine and sends the Service Router IP
address back to the client. The client then sends a request for sample.wmv to the Service Router.
The Request Routing Engine chooses the Service Engine to redirect the request to based on load,
location, and other factors. A 302 redirect message is sent to the client with the redirected URL
http://se1.se.cds.com/sample.wmv.
A DNS request is sent to the Request Routing Engine again through the DNS proxy to resolve
se1.se.cds.com. The Request Routing Engine returns the IP address of se1 to the DNS proxy which is
forwarded to the client. The client then contacts the Service Engine (se1) directly and requests the
sample.wmv. The Service Engine streams the requested content to the client.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-34
Chapter 1
Product Overview
Content Delivery System Architecture
DNS-Based Redirection
DNS-based redirection enables requests to get directly routed to the Service Engine without any 302
redirects. It also allows content to be streamed without transforming the request URL.
Note
When DNS-based redirection is used, for application-level requests, last-resort redirection is supported.
However, on the DNS plane, an A record with the last-resort domain name or IP address is not returned.
Figure 1-3 describes the Service Router’s Request Routing Engine workflow using DNS-based
redirection.
Figure 1-3
Request Routing Engine Workflow with DNS-Based Redirection
When DNS-based redirection is enabled, the DNS proxy contacts the Request Routing Engine to resolve
video.cds.com (step 8 in Figure 1-3), the Request Routing Engine determines which Service Engine to
redirect the request to based on load, location, and other heuristics, and directly returns the appropriate
Service Engine’s IP address instead of the Service Router’s IP address. The client then directly requests
the content from the Service Engine instead of the Service Router.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-35
Chapter 1
Product Overview
Content Delivery System Architecture
Note
The TTL for the DNS proxy requests is one second. A one-second TTL ensures that the DNS proxy keeps
sending requests to the Request Routing Engine, which in turn causes the Request Routing Engine to
determine the best Service Engine at that point in time, and not to redirect the request to the same SE.
Note
There are certain side effects in adopting this approach. They are as follows:
•
When creating the Coverage Zone file, the IP address of the DNS proxy needs to be used for the
client IP address range.
•
If proximity-based routing is enabled, it uses the IP address of the DNS proxy in computing the
proximity.
•
If location-based routing is enabled, the location of the DNS proxy is taken into consideration in the
selection of the SE.
•
Service-aware routing cannot be used because the protocol and content type are not considered at
the DNS level.
•
Content-based routing cannot be used because the protocol and content type are not considered at
the DNS level.
To configure DNS-based redirection, use the service-router redirect-mode dns-redirect command.
service-router redirect-mode dns-redirect {all | domain domain}
The following example enables DNS-based redirection with the cdsfms.com domain as the domain used
to redirect all client requests to:
SR(config)# service-router redirect-mode dns-redirect domain cdsfms.com
To display information about the redirect mode, use the show service-router redirect-mode command.
To display the statistics, use the show statistics service-router summary command and the show
statistics se command. The output for the DNS-Based Redirection feature is listed as DNS Requests. In
addition to these two show commands, there is also the show statistics service-router dns command.
IP-Based Redirection
When IP-based redirection is enabled, the Request Routing Engine uses the IP address of the Service
Engine in the URL instead of the hostname. The redirected URL is http://<se ip
addr>/ipfwd/<rfqdn>/<path>. The IP-based redirection method avoids the extra DNS lookup that was
required in the RFQDN redirection.
Note
The Web Engine does not support IP-based redirection.
Off-Net and On-Net Clients
The Request Routing Engine chooses the Service Engine based on two scenarios:
•
Client is directly connected to the service provider’s network (on-net).
•
Client is roaming outside the home network (off-net).
When clients are connected to the service provider’s network, the Service Engine is chosen based on the
requested FQDN, the client’s IP address, and the responsiveness of the Service Engine. The Request
Routing Engine compares the client’s IP address against a table of address ranges representing the client
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-36
Chapter 1
Product Overview
Content Delivery System Architecture
subnets assigned to each Service Engine. This table is known as the Coverage Zone file. The Coverage
Zone file provides information on the proximity of the client to the Service Engine based on each client’s
IP address.
If the client is not connected to the service provider network and location-based routing is enabled, the
Request Routing Engine compares the latitude and longitude of each Service Engine, which is defined
in the Coverage Zone file, with the latitude and longitude of the client, which is obtained from the
Geo-Location servers, to assign a Service Engine that is geographically closest to the client. For more
information, see the “Location-Based Routing” section on page 1-40.
Coverage Zone File
When a Service Engine is registered to the CDSM, it is assigned a default Coverage Zone file that is
created by the CDSM using the interface IP address of the Service Engine. The default Coverage Zone
file can be unassigned, and a custom coverage zone can be created using the Coverage Zone file.
A Coverage Zone file is an XML file containing coverage zone entries for each client IP address range,
the Service Engine serving that range, the latitude and longitude of the Service Engine, and a metric
value. The Coverage Zone file can be referenced by a URL and imported into the CDSM, or uploaded
from a local machine. The Coverage Zone file can be set as the default for a specific Service Router or
for all Service Routers in the CDS network.
When content is requested by a client, the Request Routing Engine checks the client’s IP address to find
the coverage zone that contains that IP address. The Request Routing Engine then selects the Service
Engine that serves this coverage zone.
Note
When DNS-based redirection is enabled, the Coverage Zone file needs to have entries with respect to the
IP address of the DNS proxies instead of the client IP address.
If a specific IP address is in multiple coverage zones, the one with the more specific range is selected.
If no match is found in the coverage zone data and if location-based routing or proximity-based routing
is enabled on the Request Routing Engine, the Request Routing Engine looks up the best Service Engine
closest to the client. If the Request Routing Engine is unable to redirect the request, the Request Routing
Engine sends an error response to the client.
A coverage zone can be associated with one or more Service Engines. Each Service Engine can have its
own unique coverage zone, or the Service Engines can be associated with more than one coverage zone
and have over lapping coverage zones.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-37
Chapter 1
Product Overview
Content Delivery System Architecture
In Figure 1-4, all Service Engines serve Coverage Zone 1, and Service Engine 1 is specifically associated
with Coverage Zone 2, a subset of Coverage Zone 1.
Figure 1-4
Coverage Zone Example
Service Engine 1
Coverage Zone 2
Coverage Zone 1
Service Engine 3
211781
Service Engine 2
If a coverage zone is served by multiple Service Engines, all Service Engines are put in the routing table.
The metric value, entered in the Coverage Zone file, indicates the proximity of the Service Engine to the
client. When multiple Service Engines serving a coverage zone are on the same subnet and have the same
metric value, and load-based routing is not enabled, the Request Routing Engine uses round-robin
routing to redirect the client. If load-based routing is enabled, the load of the Service Engines are used
to determine the best Service Engine to redirect the client.
Routing Methods
The Request Routing Engine chooses the best Service Engine based on whether the Service Engine is
participating in the delivery service for which the origin server matches that of the requested domain,
and whether the Service Engine is assigned to serve the client’s network region, as defined in the
Coverage Zone file.
If the client’s subnet is not defined in the Coverage Zone file, the Request Routing Engine checks the
following routing methods to see if they are configured:
Note
•
Load-Based Routing
•
Proximity-Based Routing
•
Location-Based Routing
•
Zero-IP Based Configuration
•
Last-Resort Routing
•
Service Aware Routing
•
Content-Based Routing
The keepalive messages between the Service Router and Service Engine are transmitted and received on
port 2323. However, the software interoperates with older software releases that do not use port 2323 for
keepalive messages. If a firewall is configured between the Service Engine and the Service Router, port
2323 (UDP) must be opened for the keepalive message to go through.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-38
Chapter 1
Product Overview
Content Delivery System Architecture
Figure 1-5 describes the order in which the different routing methods are addressed in the Request
Routing Engine.
Figure 1-5
Request Routing Engine Workflow of Routing Methods
Load-Based Routing
Load-based routing is enabled by default and cannot be disabled. In load-based routing, the routing
decision is made according to the capacity and load of the Service Engines.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-39
Chapter 1
Product Overview
Content Delivery System Architecture
The load of the Service Engine is determined by different parameters, such as processor usage, memory
usage, disk usage, the number of current Windows Media streams being served, and so on. The current
load is compared with the thresholds configured for the Service Engine. If a threshold has been exceeded
for a Service Engine it is excluded from the routing table.
Note
Bursts of traffic (such as 800 connections per second) may cause the Web Engine to become disabled
before it can transmit notification to the SR that the threshold has been reached.
Proximity-Based Routing
Proximity-based routing offers more intelligence to service routing by using network proximity for
Service Engine selection. In proximity-based routing, the Request Routing Engine uses the colocated
Proximity Engine, or an external Proximity Server that runs routing protocols to get route updates from
network routers. A Proximity Server listens for OSPF, BGP, and IS-IS updates and provides proximity
information between clients requesting content and Service Engines that have the requested content. It
provides a list of Service Engines to the Request Routing Engine ranked in order of optimal routes for
content and messages in a network.
Proximity-based routing is used to select the closest Service Engine for a specified client IP address. The
Proximity Engine and Proximity Server communicate with network routers and listen in on route updates
and gets topology and routing path information. This information is used to locate the closest resource
in the network. Real-time measurements of reachability and delay are also considered.
For information on the collocated Proximity Engine, see the “Proximity Engine” section on page 1-46.
Location-Based Routing
Location-based routing is used for off-net clients. Off-net clients are clients that are not directly
connected to the service provider network. Location-based routing is designed to work with load-based
routing. When both are enabled, the Request Routing Engine first looks up the client IP address in the
Coverage Zone file. If there is no subnet match, the client’s geographical location is compared to the
geographical location of the Service Engines listed in the Coverage Zone file, and the closest and
least-loaded Service Engine is selected. Geographically locating a client is used when users roam outside
of their home network.
To provide routing to off-net clients, the Request Routing Engine communicates with a Geo-Location
server, which maps IP addresses to a geographic location. For redundancy, the CDSM can be configured
with a primary and secondary Geo-Location server.
The Geo-Location server identifies the geographical location of an off-net client by the latitude and
longitude of the client. The Request Routing Engine compares the client’s location with the location of
the Service Engines participating in that delivery service and chooses the best Service Engine to serve
the content.
Zero-IP Based Configuration
The zero-ip based configuration is a catch-all condition for routing. It can be used in combination with
proximity-based routing and location-based routing. If an SE cannot be found through location-based
routing or proximity-based routing, the zero-ip based configuration is taken into account for selecting
an SE.
The zero-ip based configuration is a network entry in the Coverage Zone file defined as 0.0.0.0/0. It
matches all client subnets. If the client subnet does not match any of the other network entries in the
Coverage Zone file and a 0.0.0.0/0 network entry exists, then the SEs listed for that entry are considered
for serving the client request.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-40
Chapter 1
Product Overview
Content Delivery System Architecture
Last-Resort Routing
Last-resort routing is useful when all Service Engines have exceeded their thresholds or all Service
Engines in the domain are offline, or the client is unknown. If last-resort routing is configured, the
Request Routing Engine redirects requests to a configurable alternate domain or translator response
domain when all Service Engines serving a client network region are unavailable, or the client is
unknown. A client is considered unknown if the client’s IP address is not part of a subnet range listed in
the Coverage Zone file, or part of a defined geographical area (for location-based routing) listed in the
Coverage Zone file.
Note
When DNS-based redirection is used, for application-level requests, last-resort redirection is supported.
However, on the DNS plane, an A record with the last-resort domain name or IP address is not returned.
Last-resort routing works dynamically. When the load of one or more Service Engines in the original
host domain is reduced below threshold limits or the Service Engines are reactivated, new requests are
routed to the original host domain automatically.
Last-resort routing allows redirecting a request to an alternate domain or Origin server (if Enable Origin
Server Redirect is enabled) for one of the following conditions:
•
All SEs in the delivery service have exceeded their thresholds
•
All SEs in the delivery service are unavailable or no SEs are assigned to the delivery service
•
Client is unknown
Redirecting to the Origin server is allowed if the Enable Origin Server Redirect field is enabled for the
Content Origin. The default setting is enabled. For more information on this configuration parameter,
see the “Content Origins” section on page 5-1.
Note
Unknown clients are only redirected to the alternate domain (last-resort domain) or translator response
domain when the Allow Redirect All Client Request check box is checked or the equivalent
service-router last-resort domain <RFQDN> allow all command is entered.
If the last-resort domain or the translator response domain are not configured and the Service Engine
thresholds are exceeded, known client requests are redirected to the Origin server (if Enable Origin
Server Redirect is enabled) and unknown clients either receive an error URL (if the Error Domain and
Error Filename fields are configured), or a 404 “not found” message.
Last-resort routing could also be configured to redirect a client to an error domain and filename.
The URL translator provides a way to dynamically translate the client request URL in order to redirect
the client to a different CDN. With the URL translator option, the following occurs if the SR uses
last-resort routing for a client request:
1.
The SR contacts the third-party URL translator through the Web Service API. The Web Service API
is described in the Cisco Internet Streamer CDS 3.2 API Guide.
2.
The third-party URL translator sends the translated URL in the response to the SR.
3.
The SR sends a 302 redirect message to the client with the translated URL it received from the
third-party URL translator.
The timeout for connecting to the URL translator server is 500 milliseconds. There are no retries if the
URL translator cannot be reached.
If there is no configuration on the URL translator for the requested domain or the connection timeout
threshold has been reached, the SR last-resort routing falls back to the alternate domain configuration.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-41
Chapter 1
Product Overview
Content Delivery System Architecture
Alternate domain last-resort routing supports requests from RTSP, HTTP (including MMS-over-HTTP),
and RTMP clients.
URL translator last-resort routing supports RTSP and HTTP client requests. For Flash Media Streaming
clients (RTMP), the client must be able to handle redirects to a different application name. Most Flash
clients cannot support a stream name change; so the filename returned by the translator is ignored.
Service Aware Routing
Service-aware routing is enabled by default and cannot be disabled. In service aware routing, the Request
Routing Engine redirects the request to the Service Engine that has the required protocol engine enabled,
the required protocol engine is functioning properly and has not exceeded its threshold, and the SE has
not exceeded its thresholds as configured. See the “Setting Service Monitor Thresholds” section on
page 4-85 for more information.
The following user agents are served by the Windows Media Engine:
•
Natural Selection (NS) player and server
•
Windows Media player and server
The following user agents are served by the Movie Streamer Engine:
Note
•
Quicktime player and server
•
RealOne player
•
RealMedia player
In addition to redirecting requests based on the user agents listed in this section, requests for content
with the following file extensions are served by Windows Media Engine (both HTTP and RTSP
requests):
•
wma
•
wmv
•
asf
•
asx
Requests for content with the following file extensions are served by the Movie Streamer Engine:
•
3gp
•
3gp2
•
mov
•
mp4
When a request reaches the Service Router, the Request Routing Engine generates a hash from the URI.
The Request Routing Engine first generates a list of Service Engines to best serve the request based on
service aware routing. The Request Routing Engine then reorders the list based on the hash and selects
the best Service Engine. Because the hash generated for the same URI is equal, typically the same
Service Engine is selected. If the Service Engine is overloaded, the next Service Engine in the list is
selected.
For service aware routing, some of the services running on a Service Engine are protocol based. When
protocol-based services associated with a protocol engine are stopped on a Service Engine, the Request
Routing Engine excludes this Service Engine from the list of possible Service Engines that can serve
requests for this type of content. The Request Routing Engine identifies the protocol engine that serves
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-42
Chapter 1
Product Overview
Content Delivery System Architecture
the request based on the user-agent in the request. For example, if some Windows Media Engine-related
services are stopped, the Service Engine can still serve Web Engine requests. However, if the request for
Web Engine content is sent from a Windows Media Player, the Request Routing Engine excludes the
Service Engine from the list of possible Service Engines that can serve the request.
Note
If the Web Engine is disabled on the Service Engine, the Service Engine does not get selected for serving
any requests, including Windows Media Streaming, Flash Media Streaming, and Movie Streamer.
Note
For service aware routing, if a threshold is exceeded for all Service Engines, the Request Routing Engine
redirects the client request to the origin server if a last-resort alternate domain is not configured. If a
last-resort alternate domain is configured, the alternate domain takes precedence over the origin server.
For a managed-live URL, if the origin server does not match the source of the live program, the above
case fails. For the above case to work, the origin server host must be configured to match the live
program source. In addition, the origin server stream name must be the same as the live program name.
Content-Based Routing
In content-based routing, the Request Routing Engine redirects the request based on the URI. Requests
for the same URI are redirected to the same Service Engine, provided the Service Engine’s thresholds
are not exceeded. If the same SE is not available, requests are routed to the next best SE. If the original
SE is available again, requests are routed back to it irrespective of the number of interim redirects to the
second best SE.
The same content can be stored in more than one Service Engine if the number of redundant copies is
set to more than one. Redundancy is used to maximize the cache-hit ratio. If redundancy is configured
with more than one copy, multiple Service Engines are picked for a request with the same URI hash.
Content-based routing is best suited for cache, prefetched, and live program requests to maximize the
cache-hit ratio.
Note
A client RTMP URL request for Flash Media Streaming does not contain the stream name; therefore, a
client’s URL requests for different RTMP streams could seem the same. For this reason, content-based
routing may not be efficient for Flash Media Streaming because a different directory needs to be created
for each stream to differentiate the content.
Note
Content-based routing does not work with clients sending signed URL requests. The hashing algorithm
for content-based routing considers the whole signed URl, so a signed URL request for the same content
may be redirected to a different SE.
Request Routing Engine Workflow of Coverage Zone, Proximity-Based Routing, and Location-Based Routing
The Request Routing Engine workflow for clients connected to the service provider’s network is as
follows:
1.
The client sends the DNS query for the routed FQDN to the local DNS server.
2.
The DNS server replies with the Service Router IP address.
3.
The client issues an HTTP, RTMP, or RTSP request to the Service Router.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-43
Chapter 1
Product Overview
Content Delivery System Architecture
4.
If the Request Routing Engine finds the client’s subnet in the Coverage Zone file, the following
occurs:
a. The Request Routing Engine chooses the appropriate Service Engine and performs a
protocol-specific redirection.
b. The client issues an HTTP, RTMP, or RTSP request to the Service Engine.
c. The Service Engine serves the content.
If the Request Routing Engine does not find the client’s subnet in the Coverage Zone file and
proximity-based routing has been enabled, the following occurs:
a. The Request Routing Engine communicates with the Proximity Engine and gets the SE
proximity list with the SEs that have the least network cost listed first.
b. The Request Routing Engine selects the closest Service Engine for the specified client IP
address.
c. The Request Routing Engine performs a protocol-specific redirection with the closest Service
Engine.
d. The client issues an HTTP, RTMP, or RTSP request to the Service Engine.
e. The Service Engine serves the content.
If the Request Routing Engine does not find the client’s subnet in the Coverage Zone file and
location-based routing has been enabled, the following occurs:
a. The Request Routing Engine communicates with a Geo-Location server and gets the
geographical coordinates of the client’s IP address.
b. The distance is calculated between the client and the Service Engines, and the Service Engine
closest to the client is selected.
c. The Request Routing Engine performs a protocol-specific redirection with the closest Service
Engine.
d. The client issues an HTTP, RTMP, or RTSP request to the Service Engine.
e. The Service Engine serves the content.
When a Service Router is registered with the CDSM, the CDSM propagates the Service Router’s IP
address to all the registered devices. The Service Engine sends a keep-alive message to the Service
Router on a periodic interval, which consists of information about the SE resources (such as disk, CPU,
memory, and network interface usage). The Request Routing Engine uses the Service Engine’s load and
liveness information for generating the routes.
The Internet Streamer CDS can have more than one Service Router to support Service Router failover.
In line with failover, the DNS server should be configured with multiple Service Routers for the same
routed FQDN.
Note
DNS entries for all FQDNs must be delegated to the Service Router. In the DNS server’s database file,
a name server record must be entered for each FQDN that routes to the Service Router.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-44
Chapter 1
Product Overview
Content Delivery System Architecture
Request Redirection
The Request Routing Engine supports the following redirections:
•
HTTP ASX Redirection Used if the requested file has an.asx extension. This redirection method
is used for Windows Media Technology. To use the HTTP 302
redirection instead, see the “Configuring Application Control” section
on page 4-122.
•
HTTP 302 Redirection
Used if the protocol is HTTP and the file extension is not .asx. This is
the native HTTP redirection.
•
RTSP 302 Redirection
Used if the protocol is RTSP and the client is QuickTime or Windows
Media. This is the native RTSP redirection.
•
RTMP 302 Redirection
Used if the protocol is RTMP and the client is Adobe Flash Player,
Adobe Media Player, or Adobe Flash Lite Player.
Normal requests for files with an .asx extension returns a status 200, unless HTTP 302 redirection is
enabled.
Cross-Domain Policy
For Flash Media Streaming, when a client requests content from a portal. and the content contains a
request to a different remote domain (the origin server in the case of the CDS), the request cannot be
served unless the remote domain (origin server) has a crossdomain.xml that grants access to the original
portal.
For example, if a client request is for abc.com/streaming.html, and the content in streaming.html has a
request to cds-origin.com/vod/sample.flv, the client requests a crossdomain.xml. The crossdomain.xml
allows access to abc.com, which allows the streaming of sample.flv.
If the cds-origin.com does not have crossdomain.xml, then the request is denied.
Note
For Flash Media Streaming, the remote domain request is looked up in the crossdomain.xml file. For
Microsoft Silverlight, the remote domain request is looked up in the clientaccesspolicy.xml file.
In the CDS, instead of directly going to cds-origin.com, the request first comes to the Service Router.
When the request for crossdomain.xml comes to the Service Router, the Request Routing Engine sends
it to the client. This XML file grants access to the portal for the file requested. The client then sends the
request for the file, which is then served.
Note
For Windows Media Streaming Silverlight the clientaccesspolicy.xml file is requested only when web
service calls are made. Depending on the client player, for both Windows Media Streaming Silverlight
and Flash Media Streaming applications, the clientaccesspolicy.xml and crossdomain.xml need to be
provisioned on the origin server.
Note
Flash Media client players that use FLVPlaybackComponent do not currently request the crossdomain
XML file for video files. The crossdomain request is issued only when a query string is present. In such
cases, the video gets downloaded but does not play.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-45
Chapter 1
Product Overview
Content Delivery System Architecture
Configuring and Monitoring the Cross-Domain Policy Feature
The Cross-Domain Policy feature can be enabled through the CDSM. See the “Configuring
Cross-Domain Policy” section on page 4-110 for more information.
Logging information can be found in the /local/local1/errorlog/service_router_errorlog.current file.
When the Request Routing Engine sends the crossdomain.xml to a client, the “crossdomain.xml served
to client” message is logged. When the Request Routing Engine sends the clientaccesspolicy.xml file to
a client, the “clientaccesspolicy.xml served to client” message is logged.
The show statistics service-router summary command displays an increase in the number of the HTTP
Requests (normal) in Request Received section of the output.
Note
The crossdomain.xml or clientaccesspolicy.xml file served by the SR is logged as 200 OK, and the
request redirect is logged as a 302.
Unified Routing Table
The unified routing table uses one global route context for all domains, with all SEs from the Coverage
Zone file added to one set of route tables. This is a good option if the CDS serves a number of different
domains (configured as delivery services), but uses the same set of SEs for the different delivery services
(domains). By enabling the unified routing table in this scenario, the memory usage on the SR is reduced.
If the CDS is configured with fewer domains or the SEs are not all serving the same domains, then the
memory usage is not impacted as much, and not enabling unified routing may be a better option.
The unified routing table option is disabled by default. To enable unified routing on the SR, enter the
service-router unified-routing -table enable command.
Note
Not enabling the unified routing table increases the memory usage on the SR. Make sure the memory
usage does not exceed the recommended limit, which is 1.5 GB when the SR is running with a load and
no configuration changes are occurring.
Proximity Engine
The Proximity Engine leverages routing information databases (IGP and BGP) by interconnecting and
peering with routers. This information is used to compute the network distance between a source
address, referred to as the proximity source address (PSA) and a target address, referred to as the
proximity target address (PTA). This distance is known as the proximity rating of the PTA.
The Proximity Engine is configured as one of the Proximity Servers for the proximity-based routing
method. See the “Proximity-Based Routing” section on page 1-40 for more information.
Note
The Proximity Engine only participates in the Open Shortest Path First (OSPF), Intermediate
System-to-Intermediate System (IS-IS), and Border Gateway Protocol (BGP) to gather information to
make proximity decisions. The Proximity Engine is not a router and does not ever use the information
to route traffic.
Note
The Proximity Engine is only supported on the CDE205 and the CDE220-2G2 platforms.
The standby interface is not supported for Proximity Engine. Use port channel configuration instead.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-46
Chapter 1
Product Overview
Content Delivery System Architecture
The Proximity Engine operates in an IP routing domain where the Interior Gateway Protocol (IGP) or
BGP is used to distribute routing information across the domain. For the proximity function to work, at
least one of the following is required:
Note
•
Enabled link-state protocol, such as OSPF or IS-IS for IGP proximity, which is required if the
Proximity Engine is going to peer with IGP routers.
•
Enabled policy routing protocol, such as BGP for best-path proximity and location-community
proximity, which is required if the Proximity Engine is going to peer with BGP routers.
All BGP routes must resolve to IGP next hops or directly connected routes.
Routers running OSPF or IS-IS establish adjacencies with their directly connected neighbors and
exchange their connectivity view (that is, each router advertises its visibility about its adjacencies).
Advertisements are flooded throughout the whole routing area and each router stores each received
advertisement in a link-state database (LSDB).
The LSDB contains the topology of the whole network and each router uses it to compute the Shortest
Path Tree and the Routing Information Base (RIB) that contains each known IP prefix in the network
and its corresponding next-hop.
OSPF and IS-IS are the two IP link-state protocols. They operate quite similarly:
•
Establish adjacencies with directly connected neighbors
•
Create a routing update packet (OSPF LSA and ISIS LSP) containing the router connectivity
•
Flood routing updates (LSA or LSP) throughout the routing area
•
Collect all received routing updates in a LSDB
•
Compute shortest first path (SPF) algorithm
•
Populate the RIB with the result of SPF
The difference between OSPF and IS-IS is in the way packets are formatted and exchanged
(encapsulation) and in the way adjacencies and flooding are handled over broadcast media. From a
routing computation perspective, both protocols behave the same and therefore the Proximity Engine
operates the same in networks deploying OSPF or ISIS.
The Proximity Engine makes proximity decisions using information from the same link-state database
that is passed between routers using OSPF or IS-IS. For these reasons, the Proximity Engine must be
configured to make either OSPF or IS-IS adjacencies to gather link-state database information for routers
in the same autonomous system, and BGP adjacencies to gather the BGP routing information for routers
in the different autonomous systems.
Proximity Engine Request Flow
Following is the Proximity Engine request flow:
1.
The Request Routing Engine sends the proximity request to the Proximity Servers, the first of which
could be the colocated Proximity Engine.
The proximity request specifies a PSA (the client’s IP address) and a set of one or more PTAs ( IP
addresses of the SEs).
2.
The Proximity Engine receives the proximity request and performs a route look-up on the PSA.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-47
Chapter 1
Product Overview
Content Delivery System Architecture
3.
The Proximity Engine determines whether the request should be handled by IGP, BGP, or locally.
Local routing is used when both the PSA and PTA are both local to the network. If the proximity
algorithm for BGP location community is enabled, and the PSA has community attribute
information, then both BGP and IGP routing information is considered.
The Proximity function takes into account:
4.
•
Routing topology
•
Inter-autonomous system reachability
•
Optimal path taken by the requested data
The Proximity Engine sends the response back to the Request Routing Engine.
In the proximity response, the Proximity Engine returns a list of proximity target addresses and the
cost associated with each address. This list includes all the IP addresses of all the SEs registered to
the CDSM. Using the proximity response data, the Request Routing Engine can select the closest
(best) target.
Note
If multi-port support is configured on the CDE220-2S3i with multiple IP addresses, only one
valid IP address of that SE is included in the list. If this CDE220-2S3i is selected, it can load
balance the requests among the streaming interfaces.
Proximity Ranking
The proximity ranking could include the following proximity algorithms:
1.
BGP community-based proximity
2.
BGP best-path proximity
3.
IGP proximity
The first two algorithms are only used if they are enabled. The last one, IGP proximity, is enabled when
an IGP is configured.
The proximity ranking always contains the proximity target list (PTL) addresses in the same order as
above. For example, if there is a PSA and two PTAs (PTA1 and PTA2), and all proximity algorithms are
enabled, the following rules are applied:
1.
If PSA and PTA1 have at least one community in common and PTA2 does not have a common
community, PTA1 is preferred over PTA2.
2.
If both PTA1 and PTA2 have at least one community in common as the PSA, the next weight is
considered.
The larger the number, the more weight the community has. If PTA1 has a weight of 5 and PTA2 has
a weight of 2, PTA1 is preferred over PTA2.
3.
If both PTA1 and PTA2 have the same weight, the next algorithm is considered, which is BGP
best-path.
4.
For BGP best-path, the PTA with the smallest AS-hop count is preferred. If both PTAs have the same
AS-hop count, the next and final algorithm is considered, which is IGP proximity.
5.
For IGP proximity, the PTA with the lowest IGP metric is preferred.
BGP Proximity Algorithms
Community-Based Proximity
Two distinct proximity algorithms are used:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-48
Chapter 1
Product Overview
Content Delivery System Architecture
•
IGP-proximity algorithm gives ordered list of SE IP addresses known in the IGP database (OSPF or
IS-IS).
•
BGP-proximity algorithm gives ordered list of SE IP addresses known in the BGP table.
While the combination of the IGP and BGP basic proximity is sufficient for the proximity calculation
for most network deployments, they may not be appropriate for some network deployments, such as a
Multiprotocol Label Switching (MPLS) network. Most of the time it is sufficient to rank the prefixes and
make the recommendation for the prefixes based on whether the PSA and the PTA are in the same rack
(the most preferred ranking), the same point of presence (POP), the same city, or the same autonomous
system (AS) (the least preferred).
When the BGP community-based proximity option is enabled, additional location information is
included in the proximity calculation to influence application-level traffic optimization in the network.
When the community-based proximity option is not used, the proximity request is handled by IGP
proximity.
The BGP community-based proximity requires that the PSA has a BGP community string. PTAs that
have the same BGP community string as the PSA are ranked as more preferred than PTAs that do not
have the same BGP community string as the PSA. The association of PSA and PTA community attributes
is configurable by specifying the target (PTA) community values to association with the location (PSA)
community, and optionally assigning a preference level. For more information, see the “Configuring the
BGP Community-based Proximity Settings” section on page 4-118. For the remaining PTAs that have
different community strings, they are ranked by IGP proximity.
Best-Path Proximity
Note
Best-Path proximity algorithm requires the configuration of the BGP proximity settings.
When the BGP best-path proximity option is enabled, the BGP best-path algorithm ranks each route
included in the PTA based on the attribute values associated with each route.
Redirect Proximity
Note
Redirect proximity algorithm requires the configuration of the SRP and the BGP proximity settings.
If the PSA is learned from another AS, the current Proximity Engine does not have the best knowledge
to handle the request. In this case, if the BGP redirect proximity option is enabled, the Proximity Engine
sends back a Redirect response to the Service Router. The Redirect response contains the list of
Proximity Engines that reside in the same AS as the PSA. The Service Router then sends the proximity
request to one of these Proximity Engines.
Service Routing Protocol
The Service Routing Protocol (SRP) uses distributed hash table (DHT) technology to form a distributed
network of Proximity Engines. SRP is highly scalable and resilient. SRP is implemented as an overlay
network on top of IPv4 or IPv6 transport. Currently, only IPv4 is supported.
Note
SRP is required if the Redirect proximity algorithm is enabled. SRP is used to gather and store
information about all the Proximity Engines that are available for redirection.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-49
Chapter 1
Product Overview
Content Delivery System Architecture
A DHT network is a logical network composed of Proximity Engines that have the same DHT domain.
Although DHT does not play any direct role in responding to the proximity service, it is the integral part
of the Proximity Engine system that gathers and stores information about other Proximity Engines in the
network to form a cohesive, resilient proximity service network.
Content Delivery System Manager
The Internet Streaming Content Delivery System Manager (CDSM) is a web browser-based user
interface. The Internet Streaming CDSM allows the administrator to configure, manage, and monitor
delivery services and devices in the Cisco Content Delivery System (CDS). Application programming
interfaces (APIs) are provided for backoffice integration with the Internet Streaming CDSM.
Authentication, Authorization, and Accounting
The Internet Streaming CDSM uses HTTPS to secure the administrator’s session. Multiple users can
perform administrative operations by using the Internet Streaming CDSM. The administrator can
configure certain users to have either view-only rights for monitoring the CDS, or full rights that allow
configuration changes as well as monitoring capabilities.
User accounts and groups can be added to the Internet Streaming CDSM and given roles and rights for
accessing configuration information. It is also possible to segregate and group objects and give access
to a limited group of users.
User authentication can be configured to use RADIUS and TACACS+ servers when available, otherwise
the Internet Streaming CDSM provides its own authentication server.
The CDS-wide policy and status information is maintained in a relational database on the Internet
Streaming CDSM. This information is propagated and synchronized with all devices in the CDS
network.
As part of the network management process, the administrator can perform basic administration
operations on the Internet Streaming CDSM database, including backup and restore.
Device Management
The Internet Streaming CDSM sends device configuration changes to the selected device or group of
devices once the change has been submitted. The device sends any configuration changes that were made
locally to the CDSM, and also provides periodic status information.
Devices can be organized into user-defined device groups, which allow administrators to apply
configuration changes and perform other group operations on multiple devices simultaneously. Because
a device can belong to multiple device groups, this reduces the management overhead of the
administrator. Device groups allow for a single instance of management thus eliminating the need to
repeat the same step for each device.
The Internet Streaming CDSM also provides an automated workflow to apply software upgrades to the
devices in a device group.
Higher Storage Utilization of CDS
Storage across multiple Service Engines is virtually divided into buckets where each Service Engine
serves only a subset of the total content. Both the local storage and RAM of the Service Engines can
function as an aggregated distributed service, providing unlimited scalability. Linear scaling of the CDS
storage is accomplished by adding more Service Engines to one location. This addresses the demands of
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-50
Chapter 1
Product Overview
Content Delivery System Architecture
the “Long Tail” use case relevant to the Service Engines. The Long Tail is the realization that the sum
of many small markets is worth as much, if not more, than a few large markets. Long-tail distribution is
the possibility that extremely infrequent occurrences in traffic are more likely than anticipated.
This higher storage utilization provides the following:
•
Overall better system performance
•
Higher in-memory cache hit ratio
•
Deterministic resiliency in case of failures or overload due to very popular content (This is useful
when customers have live, prefetched, and cached assets more than 4.5 terabytes of content on one
Service Engine.)
The content distribution is resilient and stateless. If the load of all content mapped to one Service Engine
increases, the load is automatically spread to other Service Engines without requiring any administrator
intervention.
Delivery Services Management
The Internet Streaming CDSM provides the configuration and monitoring of delivery services, which
defines how content is ingested, stored, cached, and published. The Internet Streaming CDSM provides
the Service Engines with information about the delivery services and which Service Engines are
participating in the delivery service.
In addition to using the Internet Streaming CDSM to define delivery services, an XML file called a
Manifest file can be used to define a delivery service. The Manifest file and APIs serve as the basis for
backoffice integration. For more information about the Manifest file, see the “Manifest File” section on
page 2-10.
Resiliency and Redundancy
A CDS that is designed with full redundancy and no single point of failure includes redundant Internet
Streaming CDSMs and Service Routers. The redundancy mechanisms for the Content Acquirer and
Internet Streamer applications running on the Service Engines operate differently.
Content Acquirer Redundancy
In the event of a primary failure on the Content Acquirer, the failover mechanism supports the election
of a backup Content Acquirer. A failover requires that both the primary and backup Content Acquirer
be located in the root location of the delivery service.
Live Programs
If the Content Acquirer receives a live program as a multicast stream from the origin server, upon failure
of the primary, the backup Content Acquirer assumes control of that program’s streaming and the
program continues without interruption. This process is transparent to the end user. When the primary
Content Acquirer comes back online, it receives the live stream from the active secondary Content
Acquirer and does not fall back (regain its primary status) until the live program has finished or has been
restarted.
If the Content Acquirer receives the program as a unicast stream from the origin server, the failover
mechanism is not supported. If the primary Content Acquirer fails while a program is playing, the person
viewing the program must re-request the program.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-51
Chapter 1
Product Overview
Content Delivery System Architecture
Internet Streamer Redundancy
If a Service Engine running the Internet Streamer application fails, the Service Router stops receiving
keep-alive messages from that Service Engine. When a new request comes in, the Service Router does
not redirect the request to that Service Engine; instead, it redirects the request to other Service Engines
within the same delivery service. All the existing sessions on the failed Service Engine terminate and the
affected end users must re-request the content.
Service Router Redundancy
If the CDS network is designed with multiple Service Routers, all Service Routers are aware of all
Service Engines in the CDS. The DNS servers must be configured with multiple Service Routers and the
failover is handled by the DNS servers.
Internet Streaming CDSM Redundancy
The Internet Streaming CDSM can operate in two different roles: primary and standby. The primary role
is the default. There can only be one primary active in the CDS network; however, you can have any
number of Internet Streaming CDSMs operating in standby to provide redundancy and failover
capability.
Primary and standby CDSMs must be running the same version of software. We recommend that the
standby CDSM be upgraded first, followed by the primary CDSM.
The Internet Streaming CDSM design principle is that the management device is never in the service
delivery path. When the CDSM fails, the rest of the CDS continues to operate. A CDSM failure does not
affect any services delivered to end users, and all content ingest continues. The only negative effect is
that the administrator cannot change configurations or monitor the CDS. As soon as a failure to connect
to the CDSM is noticed, the administrator can activate the standby CDSM. For information on making
the standby CDSM the primary CDSM, see the “Changing a Standby to a Primary CDSM” section on
page 3-12.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
1-52
CH A P T E R
2
Network Design
Provisioning the Cisco CDS consists of two stages:
•
Register the devices to the Internet Streaming CDSM and define the network topology and device
groups.
•
Configure the delivery services that deliver content to the clients.
This chapter describes the details of the two stages of provisioning a Cisco CDS network, how metadata
and content flow through the Cisco CDS, and features that determine your network design. This chapter
has the following major topics:
Note
•
Cisco CDS Topology, page 2-1
•
Delivery Service, page 2-3
•
Content Replication Using a Multicast Cloud, page 2-12
•
Service Workflow, page 2-18
•
Programs, page 2-20
•
IPv6 Support for Client Interfaces, page 2-21
•
HTTPS Streaming, page 2-25
•
Wholesale CDN, page 2-30
To achieve the best throughput, we recommend you configure port channels for the gigabit Ethernet
interfaces. For more information, see the “Configuring Port Channel” section on page J-6.
Cisco CDS Topology
In the Cisco CDS, the Service Engines are grouped together into locations, such that a Location Tree is
a set of locations organized in the form of a tree. The Location Tree represents the network topology
configuration that is based on parent-child relationships. Locations are well connected and have similar
connectivity properties to the outside world. A location generally implies topological proximity. Each
location can have a parent relationship and multiple child relationships, such that each location can have
zero to one parent locations and zero to many child locations. These relationships guide how content
flows among locations but does not restrict content flow in any direction.
Locations are also classified into tiers. Each tier consists of locations belonging to the same tier. All
locations with no parents belong to Tier 1. All locations that are children of Tier 1 locations belong to
Tier 2.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-1
Chapter 2
Network Design
Cisco CDS Topology
The Cisco CDS can consist of one or more topological Location Trees. A Cisco CDS network is limited
by the maximum depth of four tiers.
Figure 2-1 illustrates two location trees, with the parent-child relationship of each location indicated by
a solid line and each tier indicated by a dotted line.
Figure 2-1
Location Trees Example
San Francisco - Financial
Concord
Tier 1
South San Francisco
San Francisco - Mission
Pleasant Hill
Walnut Creek
Tier 2
Daly City
San Mateo
San Francisco Bay View District
San Ramon
211812
Tier 3
Half Moon Bay
Tier 4
The Location Trees define preferred distribution routes. The Tier 1 locations are located closest to the
Internet or backbone. Tier 1 locations can communicate with all other Tier 1 locations.
Note
The CDS does not support network address translation (NAT) configuration, where one or more CDEs
are behind the NAT device or firewall. The workaround for this, if your CDS network is behind a firewall,
is to configure each internal and external IP address pair with the same IP address.
The CDS does support clients that are behind a NAT device or firewall that have shared external IP
addresses. In other words, there could be a firewall between the CDS network and the client device.
However, the NAT device or firewall must support RTP/RTSP.
Device Groups
Device groups offer a way to group similar devices and configure all the devices in a group at one time.
Service Engines can be assigned to multiple device groups when the Device Group Overlap feature is
enabled.
A device in a device group can have individual settings different from other devices in the group, and its
settings can revert back to the group settings. The last configuration submitted for the device, whether
group or individual, is the configuration the device uses.
In addition to group configuration and assignment, the CDSM allows the following:
•
Hiding configuration pages of a device group
•
Adding all newly activated devices to a device group
•
Forcing device group settings onto all devices assigned to a group
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-2
Chapter 2
Network Design
Delivery Service
A device can be assigned to a device group in one of two ways:
•
From the Device Assignment page
•
From the Device Group Assignment page
Baseline Groups
A baseline group is a special type of device group that denotes a group of devices for a particular service.
There are three baseline groups:
•
Web Baseline Group—Used for web-based content
•
Video Baseline Group—Used for video content
•
Platform Baseline Group—Used for platform-specific configurations
A device group can be configured as a baseline group. A device can be assigned to a baseline group in
the following three ways:
•
From the Devices home page.
•
From the Device Assignment page.
•
From the Device Group Assignment page.
Delivery Service
A delivery service is a configuration that defines how content is acquired, distributed, and stored in
advance of a client request (prefetch), and after a client request (cached). Content from a single origin
server is mapped to a set of Service Engines by a delivery service. Content objects associated with a
specific delivery service have a common domain name; in other words, the content in a specified delivery
service resides in a single location on an origin server. Each delivery service maps service routing
domain names to origin servers one-to-one for Service Router DNS interception.
The CDSM is used to create the topology and configure the delivery services. All Service Engines and
Service Routers that register with the CDSM are populated with the topology and the information about
the configured delivery services.
The designated Content Acquirer is the only role which is administratively defined in the CDSM, all
other roles, based on the topology and delivery service subscription, are assumed by the Service Engines
automatically.
Both prefetched content and on-demand (dynamic and hybrid) content caching is supported. Different
algorithms are used to elect the Service Engines for the various roles based on the type of content being
distributed.
Content Acquirer
For each delivery service, there is only one Content Acquirer but multiple Service Engines. The location
that has the Content Acquirer for a delivery service is called the root location. Other Service Engines in
the root location that are assigned to the same delivery service can act as backup Content Acquirers if
the configured Content Acquirer fails.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-3
Chapter 2
Network Design
Delivery Service
Note
The locations can be virtual. For example, a location can consist of the enterprise data center and the
backup data center. The SEs in both the data center and the backup data center can be backup Content
Acquirers for each other.
For Content Acquirer redundancy, a delivery service must have at least two SEs located in the root
location. If the primary Content Acquirer fails or becomes overloaded, the SEs in the delivery service
use the selected backup Content Acquirer (there could be several SEs assigned to the delivery service
that are colocated at the root location).
Content Acquirer Selection for Prefetched Content
For prefetched content, the designated Content Acquirer always performs the content acquisition. Only
in an event of a failure does another Service Engine in the same location assume the Content Acquirer
role.
The selection algorithm runs in every Service Engine in the root location (also known as the Content
Acquirer location). The algorithm always runs in context of a delivery service; that is, only the Service
Engines subscribed to the same delivery service are considered in the selection.
Each Service Engine creates an ordered list of Service Engines belonging to the same location and
subscribed to the same delivery service. In the root location, the designated Content Acquirer is always
added as the first entry in the list.
At steady state when there are no failures, the designated Content Acquirer performs the content
acquisition. Each Service Engine in the delivery service gets the content and metadata from the Content
Acquirer by way of forwarder Service Engines and receiver Service Engines. Every Service Engine polls
its forwarder Service Engine periodically for content and metadata. For more information, see the
“Forwarder and Receiver Service Engines” section on page 2-5.
In the event that the Content Acquirer fails, the periodic polls for metadata fail causing the Service
Engines to run the Content Acquirer election algorithm .
Each Service Engine creates the ordered list again. The list looks the same as the previous list, except
that the Content Acquire which just failed is not considered in the election process. The Service Engine
that appears second in the ordered list now assumes the role of the Content Acquirer.
Content Acquirer Selection for Dynamic or Hybrid Ingest
For on-demand content, which is dynamic or hybrid ingest, the designated Content Acquirer is only used
to determine the location of where to acquire the content from the origin server directly. All of the
Service Engines in the root location are eligible to acquire the content. The Service Engine selected to
acquire the content is based on a URL hash. Content acquisition and storage is spread across multiple
Service Engines.
The selection algorithm runs on every Service Engine in the root location ( also known as the Content
Acquirer location). The algorithm always runs in context of a delivery service; that is, only Service
Engines subscribed to the same delivery service are considered in the selection.
Each Service Engine creates an ordered list of Service Engines belonging to the same location and
subscribed to the same delivery service. This ordering is based on a index created by a URL hashing
function. At steady state when there are no failures, the Service Engine that appears first in the list
performs the content acquisition.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-4
Chapter 2
Network Design
Delivery Service
In addition to the URL-based list ordering, the health and the load of the Service Engines are also
considered in the selection. Service Engines that do not have the applicable protocol engine enabled,
failed Service Engines, and Service Engines with load thresholds exceeded are eliminated from the
selection process. If a Service Engine is eliminated from the list, the next Service Engine in the ordered
list is used to acquire the content.
Location Leader
All other locations (that is, non-root locations) in the delivery service have an SE designated as the
location leader. The location leader is determined automatically by the CDSM. The other SEs act as
backup location leaders in case the location leader fails. In the same location, different delivery services
may have different SEs as their location leaders. The location leader gets the delivery service content
from outside the location, while the other SEs in the location get the content from the location leader.
This reduces the distribution traffic on low-bandwidth links, because the SEs in the same location are
likely to be on the same LAN.
Use the show distribution forwarder-list and show distribution location location-leader-preference
commands to see the location leader for a delivery service.
Location Leader Selection for Prefetched Content
The location leader selection for prefetched content is based on the same algorithm that is used for the
Content Acquirer backup selection for prefetched content, except that the Service Engines are ordered
based on an internal ID assigned at the time of registering to the CDSM. The first Service Engine in the
list is selected. In the root location, the designated Content Acquirer is always the location leader.
Location Leader Selection for Live Streaming
For live streaming, the location leader selection is based on the program URL hash and the service
availability. Each program within a delivery service could have different location leaders. Depending on
the URL hash and the number of SEs in the location, some SEs could be acting as the location leader for
more than one program.
Location Leader Selection for Dynamic or Hybrid Content
For on-demand content, which is dynamic ingest or hybrid ingest, the location leader selection is based
on the same algorithm that is used for the Content Acquirer selection for on-demand content, with the
algorithm repeated for each location. This mechanism helps distribute the load, improve cache hits, and
reduces redundant content (which contributes to storage scalability). The location leader selection is
very similar to how a location leader is selected for live streaming content.
Forwarder and Receiver Service Engines
Content distribution flows from the Content Acquirer to the receiver Service Engine (SE) by way of store
and forward. A receiver SE does not just go directly to the Content Acquirer for content. Rather, it finds
out who its upstream SE (the forwarder SE) is and pulls the content from that forwarder. The forwarder
SE in turn pulls the content from its own forwarder, which may be the Content Acquirer. All receiver
SEs store the content on disk after they get the content. Each receiver SE selects a forwarder SE.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-5
Chapter 2
Network Design
Delivery Service
The store-and-forward process causes content to flow through a distribution tree constructed specifically
for this delivery service and with all receiver SEs in the delivery service as nodes on the tree. If an SE
does not belong to the delivery service, it does not appear on the tree.
Both the metadata about the content and content itself flow through the distribution tree. This tree is
constructed by using the dynamic routing of the delivery service and is often a subtree of the overall CDS
topology.
Although the tree is global, the delivery service routing process is actually a per-SE local function that
answers the question "who is my forwarder for this delivery service?”
The following criteria is used to select a forwarder:
•
An SE is a forwarder for other SEs in its own location if it subscribes to the delivery service and it
is the location leader for the delivery service.
•
An SE in location A can be a forwarder for SEs from location B if the following occurs:
– It subscribes to the delivery service, location A is "closer" to the root location of the delivery
service than location B
– There is no other location between location A and location B that has a receiver SE of the
delivery service.
When selecting a forwarder from other locations, a receiver SE uses a hash algorithm seeded with
its own unique SE ID (assigned by the CDSM), to spread the load of multiple receivers equally to
all eligible forwarders.
Note
A "location leader" is always a per-delivery service and per-location concept, while a "forwarder" is
always a per-delivery service and per-SE concept.
A receiver SE finds its forwarder by examining the series of locations on the topology “toward” the root
location, following the parent-child relationship as described in the “Cisco CDS Topology” section on
page 2-1.
Note
1.
First, find a forwarder within the SE's own location. The location leader should be the forwarder. If
the location leader is down, use the backup location leader as the forwarder.
2.
If none is found or if the SE thinks it is the location leader, look for a forwarder in the next location
“toward” the root location. If still none are found (for example., there is no SE at that location
assigned to the delivery service or the potential ones are unreachable), then look further “toward”
the root location, and so on. The recursion ends if a forwarder is found or the Content Acquirer's
location is reached.
3.
Multicast Forwarder: If the delivery service is marked “multicast enabled,” the delivery service
searches for a multicast forwarder. If it fails to find any reachable multicast forwarder, it searches
again, this time, looking for unicast forwarders.
4.
Content Acquirer failover: If the SE is unable to find a live forwarder (for example, there is a
network or machine outage), the SE has to retry later, unless it is in the root location for the delivery
service and is allowed to failover to the origin server directly and act as a backup Content Acquirer.
This process follows the search path provided by the overall topology that was configured for the CDS.
Using the combination of the overall topology configuration and the assignment of SEs to delivery
services, the CDS gives the administrator a lot of control over the form of the distribution tree, and yet
still automates most of the selection and failover process.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-6
Chapter 2
Network Design
Delivery Service
Persistent HTTP Connections
HTTP connections are maintained among the SEs in a delivery service and the origin server as long as
the connection idle period does not exceed the keepalive timeout period of 15 seconds or the idle period
does not exceed the timeout period set on the origin server, whichever is the shorter period.
Persistent HTTP connections in a delivery service work in the following way:
1.
Open new HTTP connection. The first time a request for cache-miss content is sent to an upstream
device (SE or origin server), which is identified by the IP address of the device, a new HTTP
connection is formed.
The Web Engine has 8 working threads, which are computing units. Each thread can have as many
connections to as many upstream devices as required.
There are a maximum of 200 connections per upstream device (SE or origin server) that are persisted
in the idle queue for reuse for each of the 8 working threads, which gives a total of 1600 persistent
connections.
2.
Connection moved to idle queue. Once the content download is complete, the connection is moved
to the idle queue.
3.
Closing connections in idle queue. A 15-second keepalive timeout period is applied to each
connection moved to the idle queue and if the idle time of a connection reaches the keepalive timeout
period, it is closed. If a new request needs to be sent and there is a connection for the same server
(IP address) in the idle queue, the connection is moved to the main connection list and used for that
request.
A working thread uses an existing connection if the connection is idle; otherwise, a new connection
is opened.
4.
Open and close non-persistent connection. If a request for cache-miss content needs to be sent and
there are no idle connections for that upstream device, a new connection is created. If, after the
request is served, there already exists 200 connections for the upstream device in the idle queue, the
connection is terminated.
5.
Close 50 percent of connections in idle queue. If the origin server has a timeout period for HTTP
connections, that is taken into consideration. The 15-second keepalive timeout is used for closing
old HTTP connections. If the upstream SE or origin server has a shorter keepalive timeout period,
that takes precedence over the downstream SEs 15-second keepalive timeout.
Network Partition
In the case of network partitions, there can be multiple Content Acquirers for a single delivery service,
or multiple location leaders. There can be as many Content Acquirers as there are network partitions
(that have backup Content Acquirers) in the root location. Once the partition incident is over in the root
location, the system recovers and there is only one Content Acquirer again. There can be as many
location leaders as there are partitions (that have subscriber SEs) in any location. Once the partition
incident is over, the system recovers from it and there is one location leader again.
Delivery Service Distribution Tree
Delivery services form logical routes for content to travel from an origin server through the Content
Acquirer to all the Service Engines in the delivery service. Logical routes for content distribution are
based on the device location hierarchy or Location Tree.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-7
Chapter 2
Network Design
Delivery Service
The content distribution route follows the general tree structure of the Location Tree, where content is
distributed from the root of the tree (Content Acquirer) to the branches (Service Engines associated with
the delivery service). A delivery service distribution tree is constructed for each delivery service.
By excluding it from the Coverage Zone file, a Service Engine in a delivery service can be configured
only to forward content and metadata, and not deliver the content to client devices.
Figure 2-2 shows an example of a delivery service distribution tree. The Service Engines participating
in the delivery service are marked in red. Possible content and metadata routes are indicated by red lines.
The actual route may differ among the participating Service Engines as determined by the Service Router
routing method.
Figure 2-2
Delivery Service Distribution Tree Example
Origin
server
Concord
San Francisco - Financial
Tier 1
Content Aquirer
South San Francisco
San Francisco - Mission
Pleasant Hill
Walnut Creek
Tier 2
Daly City
San Mateo
San Francisco Bay View District
San Ramon
211782
Tier 3
Half Moon Bay
Tier 4
Types of Delivery Services
The Cisco CDS supports two types of delivery services:
•
Prefetch/caching delivery services
For prefetch delivery services, called content delivery services in the CDSM, content is forwarded
from Service Engine to Service Engine through the delivery service distribution tree until all Service
Engines in the delivery service have received it. The delivery service distribution architecture
provides unicast content replication using a hop-by-hop, store-and-forward methodology with the
forwarder Service Engines systematically selected on the basis of the manually configured location
hierarchy. For caching delivery services, the content need not be fully stored before forwarding.
•
Live delivery service
The live delivery services are only used for managed live stream splitting. The prefetch/caching
delivery services are used for prefetch ingest, dynamic ingest, and hybrid ingest.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-8
Chapter 2
Network Design
Delivery Service
Methods for Ingesting Content
There are two methods that can be used to configure a delivery service:
•
Specifying the content by using an externally hosted Manifest file.
•
Specifying the content by using the Internet Streaming CDSM.
The Internet Streaming CDSM provides a user-friendly interface for adding content and configuring
crawl tasks. All entries are validated and a Manifest file is generated. The Internet Streaming CDSM
offers the most frequently used parameters, a subset of the Manifest parameters. For a complete set
of parameters, use a Manifest file.
The following sections describe the main building blocks of a delivery service:
•
Origin Servers
•
Manifest File
•
Content Acquirer
•
Internet Streamer
Origin Servers
Content is stored on origin servers. Each delivery service is configured with one content origin. The
same origin server can be used by multiple live delivery services. However, only one prefetch/caching
delivery service is allowed per content origin. Each Content Origin is defined in the Internet Streaming
CDSM by the following:
•
Origin server
•
Service routing domain name
The origin server is defined by the domain name that points to the actual origin server. The origin server
domain name is used to fetch content that resides outside the delivery service, and to request redirection
in case of a failure. The origin server must support at least one of the following protocols in order for
the CDS to be able to ingest content:
•
HTTP
•
HTTPS
•
FTP
•
CIFS
•
SMB
Content can also originate from a local file on the CDS.
The service routing domain name is an FQDN and is used for content redirection. Each content that is
ingested by the Manifest file is published using the service routing domain name. The service routing
domain name configured for the Content Origin must also be configured in the DNS servers, so client
requests can be redirected to a Service Router for request mediation and redirection.
Proxy Server
When the Content Acquirer cannot directly access the origin server because the origin server is set up to
allow access only by a specified proxy server, a proxy server can be configured. The proxy server is
configured through the Internet Streaming CDSM for fetching the Manifest file, and through the
Manifest file for fetching the content. Proxy configurations made in the Manifest file take precedence
over proxy configurations in the CLI.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-9
Chapter 2
Network Design
Delivery Service
Origin Server Failover
The Content Acquirer can failover to an alternate Origin server if the primary Origin server fails. The
alternate Origin server is configured on the Services > Service Definition > Content Origins > Failover
Settings page in the CDSM GUI. The Content Acquirer detects Origin Server failure using timeout or
other mechanisms. When an Origin Server failure is detected, an alarm is generated to CDSM. The alarm
is cleared automatically after a configurable period of time. Meanwhile, the Content Acquirer switches
to the secondary Origin Server seamlessly. When all of the Origin Server fails, a 504 response will be
generated and sent to client. The operator then manually switches working server among primary OS and
any alternate OS. Transaction logs are generated to log these events.
Manifest File
The Manifest file contains XML tags, subtags, and attributes used to define how content is ingested and
delivered. Each delivery service has one Manifest file. The Manifest file can specify attributes for
content playback and control. Attributes for specifying metadata only, without fetching the content, are
supported. If special attributes are set, only the metadata and control information are propagated to the
Service Engines. The control data is used to control the playback of the content when it gets cached by
dynamic ingest. The Manifest file format and details are described in Appendix B, “Creating Manifest
Files.”
Crawling
For HTTP, HTTPS, FTP, SMB, or CIFS, a single item can be fetched by specifying a single URL in the
CDSM or Manifest file, or content can be fetched by using the crawler feature. The crawler feature
methodically and automatically searches acceptable websites and makes a copy of the visited pages for
later processing. The crawler starts with a list of URLs to visit, identifies every web link in the page, and
adds every link to the list of URLs to visit. The process ends after one or more of the following conditions
are met:
•
Links have been followed to a specified depth.
•
Maximum number of objects has been acquired.
•
Maximum content size has been acquired.
The crawler works as follows:
1.
The Content Acquirer requests the starting URL that was configured for the delivery service.
2.
The crawler parses the HTML at that URL for links to other files.
3.
If links to other files are found, the files are requested.
4.
If those files are HTML files, they are also parsed for links to additional files.
In this manner, the Content Acquirer “crawls” through the origin server.
Note
The crawler cannot parse JavaScript or VBScript to get the links, nor does it work with HTTP cookies.
A website that has indexing enabled and the default document feature disabled generates HTML that
contains a directory listing whenever a directory URL is given. That HTML contains links to the files in
that directory. This indexing feature makes it very easy for the crawler to get a full listing of all the
content in that directory. The crawler searches the folders rather than parsing the HTML file; therefore,
directory indexing must be enabled and the directory cannot contain index.html, default.html, or
home.html files.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-10
Chapter 2
Network Design
Delivery Service
In FTP acquisition, the crawler crawls the folder hierarchy rather than parsing the HTML file. Content
ingest from an SMB server for crawl jobs is similar to FTP ingest; that is, the crawler crawls the folder
hierarchy rather than parsing the HTML file.
Content Acquirer
The Content Acquirer parses the Manifest file configured for the delivery service and generates the
metadata. If the hybrid ingest attributes are not specified, the Content Acquirer ingests the content after
generating the metadata. The Content Acquirer can be shared among many delivery services; in other
words, the same Service Engine can perform the Content Acquirer role for another delivery service.
SMB Servers
The CDS supports file acquisition from Windows file servers with shared folders and UNIX servers
running the SMB protocol. The Content Acquirer first mounts the share folder. This mount point then
acts as the origin server from which the content is fetched. The Content Acquirer fetches the content and
stores it locally.
Note
With SMB, files greater than two gigabytes cannot be ingested.
HTTP Servers
The no-cache directive in an HTTP server response header tells the client that the content requested is
not cacheable. When an HTTP server responds with a no-cache directive, the Content Acquirer behaves
as follows:
•
If the content to be ingested is specified in an <item> tag in the Manifest file, the Content Acquirer
ignores the no-cache directive and fetches the content anyway.
•
If the content to be acquired is specified in a <crawler> tag in the Manifest file, the Content Acquirer
honors the directive and does not fetch the content.
Internet Streamer
The Internet Streamer application on the Service Engine participates in the delivery service by
distributing content within the CDS and delivering content to the clients. The Service Engines can be
shared among other delivery services.
HTTP Download—Disabling
In some instances, for example when there are contractual obligations to prevent clients from
downloading content, it may be necessary to disable HTTP downloads on a delivery service. When
HTTP download is disabled, the Web Engine returns a 403 forbidden message. For configuration
information, see the “Creating Delivery Service” section on page 5-15.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-11
Chapter 2
Network Design
Content Replication Using a Multicast Cloud
Content Replication Using a Multicast Cloud
The Multicast Cloud feature is a group of multicast-enabled SEs configured to communicate multicast
session information with one another. The Multicast Cloud feature is described in the following sections:
Note
•
Introduction to Multicast Cloud
•
Distributing Content Through Replication
•
Configuring Multicast Distribution
•
Multicast Forward Error Correction and Proactive Forward Error Correction
•
APIs for Multicast Cloud
The Multicast Cloud feature is supported in all releases starting from Release 3.1.1.
Introduction to Multicast Cloud
Content is forwarded (or replicated) either by unicast pull (transmission initiated by a client request for
the content) or, if it is enabled, by multicast push (transmission initiated in accordance with a
preconfigured program or schedule). Unicast content forwarding involves communication between a
single sender and single receiver, whereas multicast replication involves communication between a
single sender and a selected group of receivers.
Multicasting allows efficient distribution of content to multiple SEs and is useful when many end users
are interested in the same content. CDS software supports Pragmatic General Multicast (PGM)-based
multicast replication, using either satellite or multicast-enabled terrestrial infrastructures. (PGM is a
reliable multicast protocol that enables PGM receivers to report loss of data and request retransmission
by the PGM sender.)
In CDS software, the administrator configures the CDS network for multicasting by configuring a
multicast cloud in the CDSM GUI. The multicast cloud consists of one sender SE, an optional backup
sender for multicast-to-multicast failover, and at least one receiver SE. All the SEs in one cloud share a
unique advertising address, allowing them to communicate multicast session information. SEs that are
assigned to the multicast cloud must be enabled for multicasting. The multicast cloud is then associated
with one or more multicast-enabled delivery services. The multicast-enabled SEs assigned to the
multicast cloud are also assigned to the multicast-enabled delivery service.
The SEs that are receivers get their content from the multicast addresses associated with the cloud. The
multicast cloud is an overlay topology on the location-based distribution tree structure. The clouds can
be chained by making a receiver of one cloud the sender of another cloud. For best performance, the SEs
in a multicast cloud should all be able to receive data at about the same rate. The slowest receiver
determines the rate at which the sender pushes the files.
When configuring the multicast cloud, the administrator specifies a range of addresses by entering a start
IP address and an end IP address. Once a multicast cloud is configured, the multicast address range is
used to provide each delivery service associated with it a unique data delivery service multicast address.
When a multicast cloud is assigned to a delivery service, an unused IP address is automatically selected
from this range to ensure that the address is used by only one delivery service and by only one multicast
cloud. Because different multicast clouds may be associated with the same delivery service, the multicast
address used for each delivery service needs to be different in each multicast cloud.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-12
Chapter 2
Network Design
Content Replication Using a Multicast Cloud
Distributing Content Through Replication
After content is acquired from the Origin server by the Content Acquirer of a delivery service, it can be
replicated through the delivery service either by unicast or multicast transmission.
The delivery service configuration offers content replication options:
•
Multicast and unicast (multicast with failover to unicast)
•
Multicast-only
•
Unicast-only
Unicast Replication
The basic delivery service distribution architecture provides for unicast content replication using a
hop-by-hop, store-and-forward methodology with the forwarder SEs systematically selected on the basis
of the manually configured location hierarchy.
To distribute content through unicast, the CDS network automatically creates a unidirectional
distribution tree for each delivery service. The root node of the tree is the Content Acquirer of the
delivery service, and each SE subscribed to the delivery service is a node on the tree.
For each node, its parent node is also called its forwarder SE. The algorithm for automatically
designating the forwarder SE is called the channel routing algorithm.
Three general rules in the current channel routing algorithm are as follows:
1.
In each location for each delivery service, only one SE fetches content from another location for that
delivery service. We call this SE the location leader of the delivery service. All other SEs in this
location use the location leader as the forwarder for this delivery service. There can be only one
location leader per delivery service per location. Note that within one location, different delivery
services may have different location leaders.
The location leader is computed automatically by the channel routing algorithm.
Use the show distribution delivery-service command to see which SE is the current forwarder for
a delivery service. The reason/status field in the command output shows why an SE is unable to find
a forwarder. Use the show distribution forwarder-list command to see the forwarder selection
order of an SE for a delivery service.
2.
The location leader finds a subscribed SE from the closest location on the path toward the Content
Acquirer as its forwarder. If all the potential forwarders in a parent location are down (or
unreachable) the location leader skips to the next location level in the hierarchy (towards the Content
Acquirer location) to find a forwarder.
3.
If the location leader SE fails for some time, another SE in the location takes over as the location
leader. If the Content Acquirer fails, another SE in the location takes over as the temporary Content
Acquirer.
Multicast Replication
In multicast content distribution, the sender SE in a multicast cloud proactively pushes content into the
cloud according to a preconfigured schedule.
The receiver SEs listen on the advertisement IP address for information on content to be replicated from
the sender, and then the receiver SEs decide whether or not to accept an advertisement and receive the
corresponding content.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-13
Chapter 2
Network Design
Content Replication Using a Multicast Cloud
Content metadata must be distributed to a receiver first before the content itself can be replicated.
Content metadata helps to define what content to retrieve, how content will be retrieved, how recently
content has been updated, how content is to be pre-positioned (for example, expiration time), and so
forth. Metadata is always distributed using unicast. Content, however, can be replicated using either
multicast or unicast. A multicast receiver rejects the multicast sender’s advertisement of a file if the
proper content metadata has not yet arrived.
Multicast and Unicast
When a delivery service is configured for multicast and unicast, the receiver SE uses unicast to download
content only after all carousel passes have been exhausted and after the preconfigured multicast
transmission fails. In a multicast cloud configuration that uses a backup sender, when the delivery
service is enabled for multicast and unicast, the failover to unicast occurs when the current active
multicast sender has exhausted all the carousel passes for the file.
If the administrator wants the SEs to fall back to unicast (for example, with a multi-tier unicast
deployment using a terrestrial multicast medium), the multicast cloud should be configured for a low
number of carousel passes (such as 1, 2, or 3).
Multicast Only
If only multicast replication is desired (for example, with a hub and spoke or star topology deployment
using a satellite multicast medium), the delivery services should be configured as multicast-only, with a
high number of carousel passes configured in the multicast cloud (such as 10 or more).
When a delivery service is configured to be multicast only (that is, when the delivery services are
associated with a multicast cloud and the subscribing receiver SE has multicast service enabled), content
replication takes place only through multicasting. No retransmission takes place in unicast at all. This
prevents background unicast polls from happening and taking up bandwidth. However, if an SE in the
multicast-only delivery service is not enabled for multicasting, it can continue to request all the content
from a multicast-only delivery service through unicasting.
Configuring Multicast Distribution
To configure the CDS for multicast replication of content, the following tasks need to be performed:
1.
Enabling SEs for Multicasting, page 4-21
2.
Creating Multicast Clouds, page 5-8
3.
Assigning SEs to a Multicast Cloud, page 5-11
4.
Assigning Multicast Clouds to Delivery Services, page 5-13
5.
Assigning SE members of the multicast cloud to the delivery service (Services > Service Definition
> Delivery Services > Assign Service Engines)
Multicast Logging Enhancements
The CDS includes enhanced multicast logging to identify the receiver SE that is sending the
retransmission requests (NACKs) and to identify why a file is scheduled for multicasting. These logging
enhancements provide the following details:
•
Any NACKs that are received by the multicast sender SE are logged at the trace level in the
dist-meta-sender error log on the multicast sender SE.
•
Any NACKs that are related to preparing a file for scheduling are logged in the transaction log.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-14
Chapter 2
Network Design
Content Replication Using a Multicast Cloud
•
Any file that is scheduled for multicasting has the details about why it was scheduled for
multicasting. You can obtain the details from the time-based queue or the priority-based queue.
Multicast Forward Error Correction and Proactive Forward Error Correction
Forward error correction (FEC) is a type of data encoding that protects transmissions against errors,
without requiring retransmission. The FEC number denotes the number of packets that is encoded into
one FEC transmission group. When the FEC number goes up, the transmission group becomes larger, so
the multicast may be more error-resistant. However, there is more computational and bandwidth
overhead on the multicast sender and receivers.
The FEC default value is 16. If the multicast sender device is a high-end SE model such as a CDE250,
you can set this number higher in order to improve multicast reliability, especially when your network
connectivity has a high uniform loss rate. However, we do not recommend that you set this number
beyond 64 because it may place too much of a load on all the receiver SEs.
Separately, you can also set proactive FEC using the PGM configuration file, which is a text file
accessible from the SE in the /local1/multicast-expert-config/ directory. See the “Configuring PGM and
File Transmission Parameters Using Multicast Expert Mode” section on page 2-15 for more information.
Proactive FEC is the number of extra packets that the multicast sender proactively sends out for every
FEC number of data packets. The proactive FEC default value is 0. You can set it higher for better
multicast reliability; for example, 2 proactive packets for every 16 FEC packets, at the expense of 12.5
percent traffic overhead (2 divided by 16).
Proactive FEC is an additional reliability measure above and beyond that of normal FEC. Although
normal FEC does not incur bandwidth overhead, proactive FEC does. Proactive FEC primarily protects
the multicast from uniform losses. For example, if the network has a uniform loss rate of 15 percent, then
a proactive FEC of 2 extra packets for every 16 FEC packets (a 12.5 percent bandwidth overhead) cuts
the effective loss rate down to 2.5 percent. Most network losses are not completely uniform. Still, during
bursts, proactive FEC similarly undercuts the effective burst loss rate. For example, if the burst loss rate
is 20 percent while the average loss rate is 2 percent, with proactive FEC at 12.5 percent, the receiver
SEs experience a burst loss rate of 7.5 percent and an average loss rate near 0 percent.
Configuring PGM and File Transmission Parameters Using Multicast Expert Mode
PGM is a reliable multicast protocol defined in IETF RFC 3208. It is designed for applications that
require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple
receivers. Support for reliable multicasting and file transmission is provided by the
TIBCOSmartPGM FX tool set, which is integrated with Cisco CDS software. You can configure some
PGM and file transmission (FX) parameters through the CDSM GUI, such as the advertisement IP
address, multicast-out bandwidth, TTL, FEC transmission group, and so forth.
In some cases, expert users might want to change other PGM and FX parameters to make the multicast
file transfer more robust and efficient for their multicast environment. The CDS allows you to change
the configuration parameters of the TIBCOSmartPGM FX configuration file manually by using
multicast expert mode on the SE.
Caution
We do not recommend that you change the TIBCOSmartPGM FX configuration file unless you are an
expert in PGM multicasting and know how to adjust the configuration parameters.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-15
Chapter 2
Network Design
Content Replication Using a Multicast Cloud
The CDS software contains default TIBCOSmartPGM FX configuration files for multicast sender and
receiver SEs. The multicast sender and receiver SEs determine the medium (terrestrial or satellite) being
used for the multicast by checking the configuration of the multicast cloud, then they read the
configuration parameter values from the PGM configuration file that corresponds to the medium.
The CDS software uses the following default TIBCOSmartPGM FX configuration files:
•
fxd.conf.src
•
fxd.conf.rcv
The SE stores sample versions 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, and save it with the default filename. The modified configuration file becomes
effective after the SE is restarted.
SEs contain the following sample configuration files:
•
fxdSatellite.conf.src.sample—Use for a sender SE in a satellite network
•
fxdSatellite.conf.rcv.sample—Use for a receiver SE in a satellite network
•
fxdTerra.conf.src.sample—Use for a sender SE in a terrestrial network
•
fxdTerra.conf.rcv.sample—Use for a receiver SE in a terrestrial network
To change the configuration parameters of a default TIBCOSmartPGM FX configuration file, do the
following:
Step 1
Step 2
Log in to the multicast sender SE using FTP.
a.
From a PC running Windows, choose Start > Run.
b.
In the Open field, enter ftp ipaddress, using the IP address of the multicast sender or receiver SE.
c.
At the User prompt, enter your administrator-level username.
d.
At the password prompt, enter your password. The FTP prompt (ftp>) appears.
At the FTP prompt, open the multicast-expert-config directory.
ftp> cd multicast-expert-config
250 CWD command is successful.
ftp>
Step 3
List the sample configuration files in the directory.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
fxdSatellite.conf.rcv.sample
fxdSatellite.conf.src.sample
fxdTerra.conf.rcv.sample
fxdTerra.conf.src.sample
226 Transfer complete.
ftp: 297 bytes received in 0.01Seconds 29.70Kbytes/sec.
Determine which sample file you want to retrieve, based on whether you are configuring the multicast
sender or the receiver and whether your network is using terrestrial or satellite media transmission.
Step 4
Return to binary mode from ASCII mode.
ftp> bin
200 Type set to I.
Step 5
Copy the configuration file to your desktop.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-16
Chapter 2
Network Design
Content Replication Using a Multicast Cloud
ftp> get fxdSatellite.conf.rcv.sample
200 PORT command successful.
Opening BINARY mode data connection for fxdSatellite.conf.rcv.sample (5607 bytes).
226 Transfer complete.
ftp: 5607 bytes received in 0.00Seconds 5607000.00Kbytes/sec.
ftp>
Step 6
End the FTP session.
ftp> quit
Step 7
Locate the configuration file on your PC and open it using any text editor.
Step 8
Edit the sample configuration file.
Step 9
Save the file using Save As, and give it the same name as the default configuration file that you want to
replace. For example, save the file named fxdSatellite.conf.rcv.sample as fxd.conf.rcv.
Step 10
Transfer the file back to the multicast sender or receiver SE multicast-expert-config directory.
a.
Log in to the SE using FTP.
b.
Open the multicast-expert-config directory.
c.
Enter binary mode.
d.
Transfer the file into the directory. For example:
C:\>ftp 128.19.220.79
Connected to 128.19.220.79.
220 SERVICEENGING FTP server (Version wu-2.7.0(2) Tue Sep 7 17:20:20 P
DT 2004) ready.
User (128.19.220.79:(none)):admin
331 Password required for admin.
Password:
230 User admin logged in. Access restrictions apply.
ftp> cd multicast-expert-config
250 CWD command successful.
ftp> bin
200 Type set to I.
ftp> put fxd.conf.rcv
200 PORT command successful.
150 Opening BINARY mode data connection for fxd.conf.src.
226 Transfer complete.
ftp:5607 bytes sent in 0.01Seconds 560.70Kbytes/sec.
ftp> quit
Step 11
Restart the multicast sender or receiver SE for the new configuration to take effect.
APIs for Multicast Cloud
The following APIs have been modified or added to support the configuration and monitoring of the
Multicast Cloud feature:
•
Multicast Cloud—MCastApiServlet API has been added with create, modify, and delete actions, as
well as assign and unassign receiver SEs, and assign and unassign the multicast cloud to a delivery
service
•
Delivery Service—ChannelApiServlet API createDeliveryService and modifyDeliveryService
actions have been modified with the ability to enable multicast for the delivery service
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-17
Chapter 2
Network Design
Service Workflow
•
Service Engine— CeApiServlet API seMulticast action has been added to enable an SE as a
multicast sender and multicast receiver.
For more information, see the Cisco Internet Streamer CDS 3.2 API Guide.
Service Workflow
What follows is a description of the workflow of a delivery service. Table 2-1 shows sample values for
for the delivery service workflow described in Figure 2-3. The delivery service workflow is described in
detail following Figure 2-3.
Table 2-1
Delivery Service Parameters Example
Parameter
Value
Type
Caching/Prefetch
Origin Server
www.ivs-internal.com
Service Routing Domain Name
cr-ivs.videonet.com
Delivery Service Contents
http://www.ivs-internal.com/video/wmv-152
http://www.ivs-internal.com/video/wmv-92
http://www.ivs-internal.com/video/wmv-212
http://ww.ivs-internal.com/video/wmv-59 type=“cache”
http://www.ivs.internal.com/video/wmv-6 type=”cache”
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-18
Chapter 2
Network Design
Service Workflow
Figure 2-3
Delivery Service Workflow Diagram
1.
The topology is propagated to all the devices registered and activated in the Internet Streaming
CDSM. The delivery service configuration is propagated to all the Service Engines subscribed to the
delivery service. The Manifest file information is sent to the Content Acquirer for the delivery
service.
2.
The Content Acquirer parses the Manifest file and generates the metadata. All content listed in the
Manifest file, except for non-cache content types, is fetched.
3.
The Content Acquirer propagates the metadata to all other Service Engines.
4.
The Service Engines receive the metadata and associated prefetched content. The Service Engines
do not prefetch content that is “wmt-live” or “cache” types. The “wmt-live” type corresponds to the
Windows Media live streaming and the “cache” type corresponds to the hybrid ingest content.
5.
The client request for a URL first performs a DNS resolution. The Service Router is configured as
the authoritative DNS server for the hosted, or service routing, domain. The URLs that are published
to the users have the service routing domain names as the prefix.
6.
The Service Router resolves the service routing domain name to its own IP address.
7.
The client sends the request to the Service Router and the Service Router uses its routing method to
determine the best Service Engine to stream the requested content.
8.
The Service Router redirects the client to the best Service Engine.
9.
The client sends the request to the Service Engine.
The following are the possible scenarios after the request reaches the Service Engine:
•
Prefetched/Pinned Content
Flow 10, “Pre-ingested response.”
The content is prefetched using the URL: http://www.ivs-internal.com/video/wmv-152
The actual user request is: http://cr-video.videonet.com/video/wmv-152
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-19
Chapter 2
Network Design
Programs
The Service Engine processes the user request, and based on the metadata, determines the content
was prefetched and pinned in its local storage. The Service Engine looks up the policies for the
content and streams the content to the user.
•
Dynamic Ingest/Cached Content
Flows 10, 11, 12, “Non-ingested contents—Hierarchical cache resolution,” “Native Protocol
Response,” and “Dynamic ingest response.”
If the request for content is not specified in the Manifest file, dynamic ingest is used.
The user request is: http://cr-video.videonet.com/video/wmv-cached.wmv
The Service Engines in the delivery service form a hierarchy, pull the content into the CDS, and
cache it. The Service Engine streams the content to the user.
•
Hybrid Ingest/Metadata Only Content
(no content flow)
The request for content is specified in the Manifest file as “cache.”
The user request is: http://cr-video.videonet.com/video/wmv-59
The Service Engine fetches the content, similar to the dynamic ingest method, but the metadata
attributes (for example, serveStartTime, serveStopTime) are honored by the Service Engines and the
content is served only if the request falls within the defined time interval.
Programs
A program in the CDS is defined as a scheduled live or rebroadcast event that streams content to client
devices. The CDS streams live or rebroadcast content by using the Movie Streamer, Windows Media
Streaming, or Flash Media Streaming engine.
Movie Streamer live and rebroadcast programs can have multiple tracks (1–3 tracks).
Live Programs
Live events are streamed from third-party encoders (such as Windows Media Encoder Version 9 or the
QuickTime encoder) or from streaming servers (such as Windows Media Server). The live stream is
ingested by the Content Acquirer and transmitted to all Service Engines using either unicast or multicast.
The live stream is transmitted to end users by using either multicast or multicast/unicast live splitting.
The live stream is only available to end users during its scheduled times.
With live stream splitting, administrators do not have to create scheduled multicast events, because the
Service Engines automatically split the stream.
Unicast to multicast streaming is a solution similar to live stream splitting, except that in the final
delivery segment the stream is converted to multicast to minimize the bandwidth demand on the CDS
network and to minimize the load on the Service Engines.
Each live program can have up to ten different playtimes scheduled. The program is broadcast from all
Service Engines simultaneously.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-20
Chapter 2
Network Design
IPv6 Support for Client Interfaces
Rebroadcasts
In a scheduled rebroadcast, prefetched content is scheduled to be streamed from the Service Engines
using multicast. Content can only be selected from one delivery service. The Service Engines and device
groups assigned to the delivery service are automatically selected when the content files are chosen for
the program.
API Program File
Programs can be defined through the Internet Streaming CDSM or through an API. Programs created
through APIs are based on a program file. A program file is an XML file that resides on an external server
and contains the elements that define the schedule, content, and presentation parameters. The Internet
Streaming CDSM gets the program file, parses it, and saves the program file to the database. The
program is automatically updated at intervals by refetching the program file and reparsing it. RTSP is
the only protocol supported in the program file.
Programs created using an API can be viewed in the Internet Streaming CDSM as read-only, and
modifications to the API programs can be accomplished through the API. The API program can also be
edited using the Internet Streaming CDSM; however, the information about the API program file is
deleted and the program can no longer be modified through the API. A third option is to copy the API
program using the Copy Program feature.
For more information, see Appendix A, “Program Files in the CDS Software,” in the Cisco Internet
Streamer CDS 3.2 API Guide.
IPv6 Support for Client Interfaces
IPv6 is implemented on the client interfaces for the Web Engine, the Windows Media Streaming Engine,
the Flash Media Streaming engine, the Authorization Server, and the Service Router. Movie Streamer
does not support IPv6.
Communication among the Internet Streamer CDS devices, between the CDS and the Origin server, and
with the CDSM GUI still uses IPv4; these communications includes CMS, Service Router keep-alive,
live routing, cache routing, and acquisition and distribution of content.
Because the Internet Streamer CDS supports dual stack (IPv4 and IPv6) for client interfaces, both IPv4
clients, IPv6 clients, and dual-stack clients can interact with the Internet Streamer CDS.
The following rules apply to configuring IP addresses:
•
For Internet Streamer CDS IPv6 support, manually configured IPv6 addresses are only used to
communicate with the clients. Unique local IPv6 address and global IPv6 address can be configured
for each interface.
•
Unique local IPv6 address and global IPv6 address can be configured for each interface.
•
Multiple IPv6 and IPv4 addresses can be assigned to each network interface.
An interface on a CDS device (SE or SR) can learn auto-configured IPv6 addresses by way of stateless
address autoconfiguration (SLAAC) from the default gateway interface.
Note
When the default gateway interface IPv6 address is changed or removed, the associated interface on the
CDS device must be manually shut down and then brought back up, which is done by the shutdown
command followed by the no shutdown command. This process removes the stale auto-configured IPv6
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-21
Chapter 2
Network Design
IPv6 Support for Client Interfaces
address and is required when the IPv6 addresses are changed or removed on the default gateway
interfaces that connect to CDS devices.
We recommend restarting the device if IPv6 is enabled or disabled as the safest method. Restarting
(reloading) the device ensures all the processes are restarted and the kernel is functioning appropriately.
Note
If the streaming interface configuration is changed (addition, deletion, modification), the Web Engine is
restarted; therefore, we recommend offloading the SE before changing the streaming interface
configuration.
Note
The following are not supported for IPv6 addresses:
•
IP Security (IPSec) implementation
•
DHCP configuration
•
Flash Media Streaming Administration
•
Movie Streamer
•
Geo-Location servers
•
Proximity-based routing
•
Last-resort redirection
•
External servers (such as, FTP servers, syslog servers, and NTP servers)
Logical Interfaces
For the Service Engine, the logical interface configured as a primary interface must have an IPv4
address, because the intra-CDS device communication is only through IPv4. If the logical interface is
configured as both a primary and a streaming interface, it must have both IPv4 and IPv6 addresses
assigned, to serve IPv4 and IPv6, or dual stack clients.
Note
Whenever the IP address of the primary interface is changed, the DNS server needs to be restarted.
For the Service Router, the primary interface must be configured with IPv4 and IPv6 address to server
IPv4 and IPv6 dual-stack clients.
ICMP6, MLD, and Neighbor Discovery Messages
The following Internet Control Message Protocol version 6 (ICMPv6) messages are supported:
•
ICMPv6 error messages
•
Destination unreachable message
•
Packet too big message
•
Time exceeded message
•
Parameter problem message
•
Echo request message
•
Echo reply message
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-22
Chapter 2
Network Design
IPv6 Support for Client Interfaces
The following Neighbor Discovery for IPv6 are supported:
•
Router solicitation
•
Router advertisement
•
Neighbor solicitation
•
Neighbor advertisement
•
Redirect message
DNS Configuration
The IPv6 address name server must be configured by using the ipv6 name-server ip-address command.
Note
The Service Router acts as the authoritative DNS server, and supports IPv6 DNS extensions.
If an IPv6 address is configured on the Service Router for DNS, the communication between the Service
Router and the DNS server is over the IPv6 transport. The IPv4 address of the Service Router must be
configured in the DNS server, so that the Service Router can respond to both A and AAAA queries. In
this case, the communication between the DNS Server and the Service Router is over IPv4 transport.
QoS
CDS supports DSCP marking for QoS of outbound IPv4 or IPv6 traffic. The IPv4 header field is the Type
of Service (ToS) or differentiated services code point (DCSP) value. The IPv6 header field is the Traffic
Class (TCLASS).
ACL Setting
Access control lists (ACLs) for IPv6 are separate from IPv4, and use the Devices > Devices > General
Settings > Network > IPv6 ACL page. An ACL permit or deny policy for IPv6 traffic is based on source
and destination IPv6 address, plus other IPv6 protocol factors, such as TCP, UDP, ICMPv6, and GRE,
or a specific port number. There are two groups for IPv6 ACLs: Standard ACL and Extended ACL.
Service Router
Communication between the Service Engine and Service Router is through the IPv4 stack, including the
keep-alive message. If IPv6 is enabled, then the keep-alive message includes the IPv6 address of the SE
in the keep-alive message payload. This enables the Service Router to resolve the SE’s IPv6 address
correctly.
The Service Router operates as a DNS Server for the requests that belong to the delivery service to which
the SR is associated. The Service Router is provisioned to respond to A or AAAA queries for the
configured Service Routing Domain Name (RFQDN). The query can be on either an IPv4 or IPv6
transport.
The Service Router accepts the HTTP, RTSP, and RTMP requests and sends back the response by way
of the IPv6 transport. The Service Router also supports the IP-based redirection, and includes the IPv6
address of the SE in the redirect URL. If the redirect URL has the SE host name, the client sends a DNS
query to the Service Router, and the Service Router responds with the SE’s IPv4 address for the A query
and the SE’s IPv6 address for the AAAA query.
The Coverage Zone file supports IPv6 and IPv4 addresses. The network and subnetwork addresses in the
Coverage Zone file support CIDR format (IP address with a prefix).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-23
Chapter 2
Network Design
IPv6 Support for Client Interfaces
Note
The Geo-Location servers do no support IPv6 client configuration; therefore, location-based routing
only supports IPv4 addresses.
Authorization Server
The Authorization Server supports the following policies:
•
IP address-based
•
Geographic location-based
•
Service rules-based
The Geo/IP file contains information on the allowed client IP addresses and geographic locations, and
denied client IP addresses and geographic locations. The Authorization Server blocks client requests
based on the Geo/Ip file uploaded for the delivery service. For IP address-based authorization, the Geo/Ip
file supports both IPv4 and IPv6 addresses.
For geographic location-based authorization, the SE communicates with the Geo-Location server, which
maps IP addresses to geographic locations. The Geo-Location server, which is the same Geo-Location
sever used for location-based routing on the Service Router, identifies the geographic location of a client
request by the country, state, and city of the client.
Note
The Geo-Location servers do no support IPv6 client configuration; therefore, geographic location
authorization of client requests are only supported for IPv4 addresses.
Service Rules
For the Web Engine and Flash Media Streaming, service rules are configured by creating a Service Rule
XML file and uploading it for the delivery service. The SrcIp pattern type supports both IPv4 and IPv6
addresses.
For Windows Media Streaming and Movie Streamer, service rules are configured on a per-device basis,
either through the CDSM GUI or through the CLI. The src-ipv6 pattern-list is used to configure IPv6
source patterns for Windows Media Streaming, and src-ip pattern-list is used to configure IPv4 source
patterns for Windows Media Streaming and Movie Streamer.
Note
Movie Streamer does not support IPv6 addresses.
Windows Media Streaming Multicast
Windows Media Streaming multicast support provides a multicast service to distribute media efficiently
to multiple clients using IP multicast. Before a client can tune into a channel and listen to or watch a
stream, a multicast station has to be set up first. For IPv6 clients, the Windows Media Streaming
multicast station should also multicast on an IPv6 multicast IP address. This requires that an IPv6
multicast IP address be configured for the live or rebroadcast program in the Services > Live Video >
Live Programs > Live Streaming page for live programs and the Services > Live Video > Live
Programs > Streaming page for rebroadcast programs.
The client fetches an NSC file to get the multicast IP address and port information. For IPv4 and IPv6
clients, Windows Media Streaming must generate two different NSC files. When Windows Media
Streaming receives the request, the client type (IPv4 or IPv6) is detected and the corresponding NSC file
is sent in the response.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-24
Chapter 2
Network Design
HTTPS Streaming
HTTPS Streaming
The HTTPS Streaming feature provides delivery service-based HTTPS support for incoming requests to
the SE and outgoing requests to the Origin server. The CDSM GUI offers the ability to enable HTTPS
or HTTP for streaming to clients as well as ingesting from the Origin server for each delivery service.
When the HTTPS feature is enabled, the inter-SE communication continues to use HTTP.
Note
HTTPS support for user equipment (UE) sessions is not supported by the Service Router, so the Service
Router cannot be used to load-balance HTTPS sessions. DNS-based redirection must be used to redirect
client requests.
DNS-based redirection means that service-aware routing and content-based routing cannot be used. For
more information about DNS-based redirection, see the “DNS-Based Redirection” section on page 1-35.
The HTTPS feature supports SSL 3.0 and TLS 1.0 protocols to tunnel HTTP.
Certificates
SEs associated with the delivery service that has HTTPS streaming enabled have a certificate installed.
The SEs do not validate certificates of downstream clients. SEs, as a client of the Origin server, do not
send their certificates to the Origin server.
Certificate Authority’s (CA’s) root certificates are expected to be available to all clients initiating HTTPS
communication; most browsers are installed with well-known CA root certificates. Trusted CA
certificates are expected to be provided for the purpose of Origin server certification validation.
CDS does not support certificate enrollment (SCEP) nor certificate status verification (OCSP). The
Internet service provider or third-party service provides enrolled certificates and installs them through
the CDSM.
Note
A single subject alternative name (SAN) certificate is installed for all delivery services in the CDS.
RSA Key Pair
An RSA key pair (public, private) is generated and used for certificate signing requests (CSRs). The
private key cannot be encrypted.
Certificate and Key Pair Uploads to CDSM
The System > Configuration > HTTPS Streaming pages are used for uploading certificate files and
key files.
Updating Certificates
When a new HTTPS delivery service is added or the Service Router domain name is changed on an
existing HTTPS delivery service, the client certificate and key file must be updated. This requires that
new certificate and key files are uploaded to the CDSM and a schedule is created to notify the Web
Engines associated with the affected HTTPS delivery service.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-25
Chapter 2
Network Design
HTTPS Streaming
Traffic Separation for HTTPS
Prior to Release 3.0, port 443 was used for Acquisition and Distribution (A&D), all intra-CDS control,
and management. With the introduction of the HTTPS feature, port 443 also needs to be used for
streaming. It therefore becomes mandatory to have separate interfaces, one for the primary and one for
streaming. The management interface, if configured separately, must not share the same interface with
the streaming interface either.
Note
The HTTPS feature supports the Multiple Logical IP Addresses feature for multiple IP addresses for the
streaming interface and one IP address for the primary interface. However, combining the streaming
interface and the primary interface on one physical interface is not supported in the HTTPS feature.
Primary Interface
The primary interface is mandatory on all CDS devices and consists of one or more physical interfaces
out of which one is always designated as primary interface. The primary interface on the CDS devices
(SE, SR, and CDSM) is used for the following communication over port 443:
•
Communication among SEs
•
All intra-CDS control and data traffic
•
All prefetched traffic from the Origin server to the SEs by way of the location tree
•
All dynamic ingest and all cache miss traffic to the SEs by way of the location tree
•
Finding routes to an Origin server for the cache router module and live stream module
•
Keep-alive information from the SEs to the SR
•
All management communication between the SEs and the CDSM, by default
Alternatively, a management IP address and port can be configured manually on the SEs and SRs
that is used for all management communication to the CDSM. For redundancy, a port channel can
be configured. Streaming traffic uses the primary interface, and management traffic between the SE
or SR and CDSM use the manually configured IP address and port, and if configured, the port
channel and static route created for it.
Note
Note
The Management Communication Port on the Device Activation page for an SE is
hard-coded to port 443. The SR is not affected because the HTTPS feature does not support
the SR. DNS-based redirection is the only routing redirection supported.
To make sure the SE or SR is binding to the primary interface (or management IP address if configured)
as the source IP address when sending management traffic to the CDSM, create a static route from the
SE or SR to the CDSM. To configure a static IPv4 route from the SE or SR, see the “Configuring Static
IPv4 Routes” section on page 4-76 section. To configure a static IPv6 route from the SE or SR, see the
“Configuring Static IPv6 Routes” section on page 4-77 section. Alternatively, you can use the ip route
command and ipv6 route command on the CDS device.
On more higher-end CDEs, the primary interface can be configured as one-gigabit Ethernet interfaces
bonded as a port channel. Primary interface configuration is read-only from the CDSM but it can
modified via CLI to other interfaces.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-26
Chapter 2
Network Design
HTTPS Streaming
Note
Whenever the IP address of the primary interface is changed, the DNS server needs to be restarted.
Management IP and Port
After a primary interface has been selected, all CDSM-SE communication is via that inteface. Optionally
a management IP address and port can also be specified for CDSM-SE communication and the primary
interface would then be no longer be used. This interface can be disabled any time in which case primary
interface is enabled for communication.
Streaming Interface
After a primary interface has been configured and the device is online, the SE is ready to serve streaming
traffic. By default, the traffic is served by the primary interface. Optionally, one or more streaming
interfaces can be configured on an SE, which designate that all client-facing traffic goes through the
streaming interface. Effective client throughput can be measured as a sum of traffic on all streaming
interfaces.
The SE streaming interfaces have the following properties:
•
If the HTTPS feature is not enabled, the streaming interface is optional, and can have the same IP
address as the primary interface
•
Number of physical interfaces configured as streaming interfaces is not limited
•
They can be configured as a port channel
•
Multiple IP addresses in the same subnet can be configured for a streaming interface
•
Same IP address can be used for both a primary interface and a streaming interface.
•
No intra CDN traffic goes through the streaming interface.
•
Streaming interfaces can also be a single interface or a port channel.
The CDSM, SR, and other SEs do not know the IP addresses of the streaming interfaces on the SE; they
only know the primary interface IP address. When the SE sends the SR keep-alive messages, it sends the
streaming interface IP addresses as well, which the SR uses to redirect requests to.
HTTPS Enabled
To enable the HTTPS feature for a delivery service, the following configuration must exist:
•
All SEs must have at least one streaming interface configured
•
Streaming interface must be a different IP address than the primary interface (or management
interface if configured)
•
If a configured streaming interface needs to be reconfigured as a primary interface, the following
command sequence must be followed to avoid a port 443 conflict and a failure to start the rpc_httpd
process:
SE(config)# no streaming-interface GigabitEthernet 1/0
This box is configured to support HTTPS traffic delivery.
Deleting the only streaming interface configured will disable this functionality.
Do you want to continue? (Yes/No): yes
SE(config)# primary-interface GigabitEthernet 1/0
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-27
Chapter 2
Network Design
HTTPS Streaming
Note
Before making configuration changes to the primary interface or management IP address on an SE, make
sure the CDSM is not performing updates to the SE, and there are no prefetching activities going on for
the SE.
Note
When the HTTPS feature is enabled, and configuration changes (addition, deletion, modification) are
made to the streaming interfaces, the Web Engine is restarted; therefore, we recommend offloading the
SE before changing the streaming interface configuration.
Web Engine
By default, the Web Engine uses port 80 of the primary interface on the SE for serving HTTP clients and
communicating with the Origin server.
If a streaming interface is configured on the SE, the Web Engine uses port 80 of the streaming interface
for serving HTTP clients and communicating with the Origin server.
If HTTPS is enabled on an SE, the Web Engine uses port 443 of the streaming interface for serving
HTTPS clients.
Internally, the Web Engine on the SEs continue to use HTTP to communicate with each other.
Note
If the HTTPS feature is disabled for a delivery service, the Web Engine on the SEs associated with that
delivery service continue to use port 443.
Configuring HTTPS
Configuring the HTTPS feature consists of the following procedures:
•
Uploading the Certificate and Key Files
•
Separating the HTTPS Traffic
•
Enabling HTTPS for a Delivery Service
Uploading the Certificate and Key Files
Uploading certificate and key files consists of the following pages:
•
Root CA File Registration—Upload or import the certificates for the Origin servers participating
in HTTPS
•
HTTPS Certification Files Registration—Upload client certificate and key file for all SEs
•
HTTPS Certification File Scheduling—Schedule client certificate and key file notification to the
Web Engine on each SE that is participating in an HTTPS delivery service
The procedures involved in uploading certificate and key files consist of the following:
•
Uploading or Importing a Root CA File
•
Uploading Client Certificate and Key Files
•
Scheduling Web Engine Notification of Client Certificate and Key Files
For more information, see the “HTTPS Streaming” section on page 6-17.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-28
Chapter 2
Network Design
HTTPS Streaming
Separating the HTTPS Traffic
To enable the HTTPS feature for a delivery service, all participating SEs must have at least one streaming
interface configured and the streaming interface must be a different IP address than the primary interface
(or management interface if configured).
Note
Before making configuration changes to the primary interface or management IP address on an SE, make
sure the CDSM is not performing updates to the SE, and there are no prefetching activities going on for
the SE.
When using the CLI to make configuration changes to the SE, it takes up to one datafeed poll, which has
a default of five minutes, for the CLI change to synchronize with the CDSM. Do not make any changes
to the HTTPS setting, or SE assignment or device group assignment to the delivery service until the
CDSM has been synchronized with the configuration change.
Note
When the HTTPS feature is enabled, and configuration changes (addition, deletion, modification) are
made to the streaming interfaces, the Web Engine is restarted automatically; therefore, we recommend
offloading the SE before changing the streaming interface configuration.
To add a streaming interface to an SE, use the streaming-interface command. For more information,
see the Cisco Internet Streamer CDS 3.2 Command Reference. For more information about separating
traffic, see the “Traffic Separation for HTTPS” section on page 2-26.
Enabling HTTPS for a Delivery Service
To enable the HTTPS feature for a delivery service, all participating SEs must be configured with at least
one streaming interface that has a different IP address than the primary interface (or management notifies
if configured). For more information, see Separating the HTTPS Traffic.
To enable HTTPS for a delivery service, see the “Creating Delivery Service” section on page 5-15.
API Support for HTTPS
API support is provided for the HTTPS feature through the following APIs:
Note
•
ChannelApiServlet—Add the OsProtocol and StreamingProtocol parameters
•
FileMgmtApiServlet—Add fileType setting of 26 for root certificate files
•
CertKeyFileMgmtApiServlet—New Certificate Key File Management API
All parameters, except actions, are case sensitive.
If the action parameter is missing or cannot be recognized, an error code and the API usage syntax is
returned.
For more information, see the Cisco Internet Streamer CDS 3.2 API Guide.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-29
Chapter 2
Network Design
Wholesale CDN
Wholesale CDN
The Wholesale CDN feature offers the ability to configure delivery services with quotas and send
real-time information to the Content Delivery Network Manager (CDNM) for managing wholesale
(business-to-business) accounts.
The Wholesale CDN feature provides the following functions:
•
Session and Bandwidth Quotas per Delivery Service
•
Cache Storage Priority per Delivery Service
•
Snapshot Counters
•
Real-Time Exporting of Transaction Logs for Billing and Analytic Reports
•
APIs for Wholesale CDN
Session and Bandwidth Quotas per Delivery Service
Setting session and bandwidth quotas per delivery service in the CDS, and associating a delivery service
with a content provider (tenant) in the CDNM, provides the ability to manage multiple tenants with
different session and bandwidth requirements in the CDNM.
The per-delivery service session quota limits the maximum number of concurrent sessions for that
delivery service. The per-delivery service bandwidth quota limits the maximum bandwidth used to
deliver content to clients.
The Service Router (SR) enforces the maximum limits (session quota and bandwidth quota) and tracks
usage on each Service Engine (SE). The usage data is aggregated across the delivery service. The SR
makes session enforcement decisions upon receiving requests to load balance. If the request for content
does not exceed the maximum limit (quota threshold), it is routed to the best SE in the delivery service.
If the request for content exceeds the maximum limit, the client receives an appropriate error response.
Note
The session and bandwidth quotas do not reserve resources, nor do they guarantee service. The quotas
only limit the maximum usage of a delivery service.
Release 3.1.0 only supports session and bandwidth quotas for Web Engine progressive download, Web
Engine adaptive bit rate (ABR), and Windows Media Streaming. Session and bandwidth quotas are not
supported for Flash Media Streaming and Movie Streamer. The session and bandwidth quotas from Web
Engine and Windows Media Streaming are aggregated in SR that makes the enforcement decision and
the decision enforces all the requests including Flash Media Streaming and Movie Streamer.
Monitoring Session and Bandwidth Quotas
Information on quota allocation, usage, and denied sessions for each delivery service is sent to the
CDNM. The CDN operator can monitor changes to the used quotas based on threshold crossing and
session management metrics.
The SR transaction log has new status codes for session and bandwidth quotas being exceeded. The show
statistics service-router summary command has new counters under “Requests Not Redirected” for
“Session limit exceeded” and “Bandwidth limit exceeded.”
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-30
Chapter 2
Network Design
Wholesale CDN
Alarms and SNMP Traps
Each SE in the delivery service maintains a session counter and a bandwidth counter. The counters are
sent to the SR over the keep-alive messages.
The SR aggregates per-delivery service session and bandwidth counters and generates alarms and SNMP
traps when session or bandwidth quotas are reached, and when augmented session or bandwidth quotas
are reached. Clear alarms and corresponding SNMP traps are also sent when the quotas and augmented
quotas return to normal. New incoming requests are still accepted if the quota threshold has been
reached. New incoming requests are rejected if the augmented threshold has been reached. Both the
quota thresholds and augmented quota thresholds are configurable per delivery service.
For both ABR and non-ABR sessions, the concurrent sessions counter is incremented when an end user
request is received and a session is created on the SE, and decremented when the session is torn down.
For ABR sessions, the concurrent sessions counter increments on receiving a manifest file request or a
segment (fragment) request and decrements on finishing serving a manifest response or fragment
response.
The following major alarms are generated by the SR if the quota thresholds are exceeded:
•
DsSession—Session quota exceeded
•
DsAugmentedSession—Augmented session quota exceeded
•
DsBandwidth—Bandwidth quota exceeded
•
DsAugmentedBandwidth—Augmented bandwidth quota exceeded
The quota threshold alarms include the delivery service ID that triggered the alarm. Whenever one of
these alarms is raised or cleared the associated SNMP trap is sent (cdsAlarmMajorRaised and
cdsAlarmMajorCleared respectively).
The following new OIDs have been added to the CISCO_CDS_SERVICE-ROUTING-MIB:
•
cdssrRequestsSessionExceeded—Counter of the number of 499 events (not enough sessions)
•
cdssrRequestsBandwidthExceeded—Counter of the number of 453 events (not enough bandwidth)
Quota Reporting
Quota usage reporting is automatically sent whenever a session quota or a bandwidth quota is configured
for a delivery service with a setting other than zero (zero means no limits are configured).
To monitor the session counter and bandwidth counter when session quota and bandwidth quota are not
configured, check the Force Quota Usage Reporting check box on the General Settings page for the
delivery service.
Configuring Session and Bandwidth Quotas
Configure session and bandwidth quotas on the Definition page for the delivery service.
Cache Storage Priority per Delivery Service
Assigning a cache storage priority to a delivery service enables the CDN operator with multiple tenants
to provide preference settings for keeping cached content for a delivery service. By default, the Content
Manager deletes cached content based on popularity (an algorithm involving the number of cache hits,
the size of the content object, and the decay of the content object). The cache storage priority setting
assigned to a delivery service influences the content popularity and thereby the content that is evicted.
To create cache storage prioirties and assign them to delivery services, see the “Creating Storage Priority
Classes” section on page 5-14.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-31
Chapter 2
Network Design
Wholesale CDN
Snapshot Counters
The Snapshot Counter transaction logs for the SR and the SE record usage information per delivery
service and can be sent to the CDNM for analytic reporting and billing purposes. For more information,
see the “Snapshot Counter Transaction Logs” section on page 7-93.
Real-Time Exporting of Transaction Logs for Billing and Analytic Reports
Transaction logs can be sent real-time from the SE and SR to the CDNM or other export server for use
in analytic reports, summary billing records, and detailed transaction records on a per-delivery service
basis. The SE and SR use the Splunk Universal Forwarder (UF) to push the transaction logs to the Splunk
Lightweight Forwarder (LWF) on the CDNM.
For more information, see the “Real-Time Exporting of Transaction Logs for Billing and Analytic
Reports” section on page 7-95.
APIs for Wholesale CDN
The following APIs have been modified or added to support the configuration and monitoring of the
Wholesale feature:
•
Storage Priority Class—StoragePrioClassApiServlet API has been added with create, modify, and
delete actions, and getStoragePrioClass action has been added to the ListApiServlet
•
Quota Usage Reporting—New parameters have been added to the following actions of the
ChannelApiServlet:
– createDeliveryService
– modifyDeliveryService
– createDeliveryServiceGenSettings
– modifyDeliveryServiceGenSettings
For more information, see the Cisco Internet Streamer CDS 3.2 API Guide.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
2-32
CH A P T E R
3
Getting Started
This chapter discusses initial device configuration, logging into and navigating the Internet Streaming
Content Delivery System Manager (CDSM), and a typical Content Delivery System (CDS) configuration
workflow. This chapter presents the following major topics:
•
Initially Configuring the Devices, page 3-1
•
Logging In to the Internet Streaming CDSM, page 3-1
•
Activating and Synchronizing the Devices, page 3-3
•
Navigating the Internet Streaming CDSM, page 3-7
•
Configuring Primary and Standby CDSMs, page 3-11
•
Typical Configuration Workflow, page 3-13
Initially Configuring the Devices
You must initially configure the Content Delivery Engines (CDEs) before they can participate in the CDS
network. The CDE that runs the Internet Streaming CDSM must be initialized first so that the CDEs
running the Service Engine (SE) and Service Router (SR) can register with it. For more information
about initially configuring the CDEs, see Cisco Content Delivery Engine 205/220/250/420 Hardware
Installation Guide. See the “Related Publications” section on page xx.
After you have initially configured your CDEs, you must activate the SEs and SRs and configure the
internal clocks by using the Internet Streaming CDSM. See the “Activating and Synchronizing the
Devices” section on page 3-3 for more information.
Logging In to the Internet Streaming CDSM
To log in to the Internet Streaming CDSM, do the following:
Step 1
Using your web browser, enter the IP address of your CDSM and port 8443.
Note
CDS supports Internet Explorer version 6 or higher, and Mozilla Firefox version 3.6 or higher.
For example, if the IP address of your CDSM is 192.168.0.236, enter:
https://192.168.0.236:8443
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-1
Chapter 3
Getting Started
Logging In to the Internet Streaming CDSM
The Security Alert message is displayed.
Step 2
Note
If you are using Mozilla Firefox version 3.6 or higher as your web browser, you need to add the
CDSM IP address to the exception list. After entering the CDSM IP address with port 8443,
Firefox displays a Secure Connection Failed message with a link stating “Or you can add an
exception.” Click this link, then click Add Exception. The Add Security Exception dialog box
is displayed. Click Get Certificate. and then click Confirm Security Exception. The CDSM IP
address has been added to the exception list and you no longer get the Secure Connection Failed
message.
Note
Sometimes the CDSM is not initially accessible from a web browser. If this occurs you must
disable and re-enable the Centralized Management System (CMS). log in to the CLI for the
CDSM, and enter the global configuration command no cms enable followed by cms enable.
Click Yes to accept the security certificate. The Login page is displayed (Figure 3-1).
Figure 3-1
Step 3
Internet Streaming CDSM Login Page
Enter the username and password and click Login. The Internet Streaming CDSM home page is
displayed.
The built-in username is admin and the initial password is default.
Note
We strongly recommend that you change the built-in admin password as soon as possible. To do so, log
in to the CLI of the CDSM device, and use the username admin password <password> global
configuration command.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-2
Chapter 3
Getting Started
Activating and Synchronizing the Devices
Note
If the default username and password have been changed by another CDSM administrator, you need to
get the new username and password.
Activating and Synchronizing the Devices
The CDS administrator approves a device by making it active. This security feature prevents
unauthorized devices from joining the CDS.
Caution
All devices must be synchronized with each other for the CDS to function properly.
Synchronization ensures accurate timestamps in all the logs and accuracy in caching decisions
determined by If Modified Since (IMS) lookups. Using Network Time Protocol (NTP) to synchronize
the devices in the CDS is the best practice.
Note
If the network is not configured with NTP, then every device in the CDS must be configured with exactly
the same time and time zone. We recommend that you use an NTP server for network synchronization.
Activating and Setting NTP for Each Device
Tip
To navigate within the Internet Streaming CDSM, click one of the tabs (for example, Devices) and then
one of the tab options (for example Locations). Navigational directions in procedures are written in the
following way:
Devices > Devices > Assignments > Device Groups
Note
From the Devices Table, you can activate all inactive devices by clicking the Activate All Inactive SEs
icon. See the “Activating All Inactive Service Engines” section on page 3-5.
To activate and synchronize a Service Engine (SE) or Service Router (SR), do the following:
Step 1
From the Internet Streaming CDSM home page, choose Devices > Devices. The Devices Table is
displayed (Figure 3-2) listing all the registered SEs and SRs.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-3
Chapter 3
Getting Started
Activating and Synchronizing the Devices
Figure 3-2
Step 2
Click the Edit icon next to the device name. The Devices home page is displayed.
Note
Step 3
If the device you want to activate is not listed in the Devices Table, restart the CMS for that
device by telneting to it and entering no cms enable followed by cms enable in global
configuration mode.
Click Activate in the Devices home page. The Location dialog box is displayed (Figure 3-3).
Figure 3-3
Step 4
Devices Table Page–Edit Device
Devices Home Page—Location Dialog Box
Create or choose a location. To activate an SE, you need to assign it to a location.
Because the standby CDSM is global to the CDS network, it does not need to be assigned to a location.
You have the following options in creating or choosing a location:
a.
If you have already created locations, you can choose a location from the Location drop-down list.
b.
To create a default location, which can be edited later, check the Create a New location check box.
A default location is created with the following name: <SE-name>-location. From the Parent of the
New Location drop-down list, choose a parent for this location.
For information about creating locations, see the “Configuring Locations” section on page 4-1.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-4
Chapter 3
Getting Started
Activating and Synchronizing the Devices
Step 5
Click Apply and Activate.
The Status of the device shows “pending” until the device is fully activated. This may take a few minutes.
Step 6
To display the top-level Table of Contents, click the Show All button above the Contents pane.
Step 7
From the left-panel menu, select General Settings > Network > NTP. The NTP Settings page is
displayed.
Step 8
Check the Enable check box and enter the IP address or hostname of each NTP server. Use a space to
separate each server.
Step 9
Click Submit to save your settings.
The activation and NTP server settings must be completed for each SE, SR, and standby CDSM.
Tip
For a quick way to get to other SEs, click the Display All Devices icon located to the left of the Expand
All button. This icon toggles between the Display All Devices and Menu icons.
For more detailed information about configuring locations, activating devices, and configuring NTP
servers, see the following sections:
•
Configuring Locations, page 4-1
•
Activating a Service Engine, page 4-10
•
Configuring NTP, page 4-67
Activating All Inactive Service Engines
To activate all inactive SEs, do the following:
Step 1
From the CDSM home page, choose Device > Devices and click the Activate All Inactive SEs icon. See
Figure 3-4.
Figure 3-4
Devices Table Page—Activate All Inactive Service Engines
The Location Choice page is displayed (Figure 3-5).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-5
Chapter 3
Getting Started
Activating and Synchronizing the Devices
Figure 3-5
Step 2
Location Choice Page
In the Location Choice page, click either Select an Existing Location for All Inactive SEs or Create
a New Location for Each Inactive SE.
If you are creating a new location, you can select a parent location, or leave the default of “none.”
Step 3
Click Submit to save the settings.
The Status in the Devices Table for all the inactive SEs shows “pending” until the devices have been fully
activated.
Note
All devices activated in this way need to have the NTP settings configured. See Step 6 through
Step 9 in the “Activating and Setting NTP for Each Device” section on page 3-3.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-6
Chapter 3
Getting Started
Navigating the Internet Streaming CDSM
Navigating the Internet Streaming CDSM
Figure 3-6 shows the different elements of the Internet Streaming CDSM.
Figure 3-6
Internet Streaming CDSM User Interface
1
Left panel menu
5
System Status bar
2
Tab options
6
Page
3
Tabs
7
Submit and Cancel buttons
4
Task bar
8
Tools (Home, Help, and Logout)
The System Status bar, tabs, tab options, and tools are accessible from any page in the CDSM. The left
panel menu changes depending on which tab and tab option you choose.
Devices, Services, and Other Tables
The Devices Table page shows all the devices registered in the CDSM. Figure 3-7 shows an example of
the Devices Table page. A table is displayed for each of the following tab options:
•
Devices (from Devices tab)
•
Device Groups (from Devices tab)
•
Locations (from Devices tab)
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-7
Chapter 3
Getting Started
Navigating the Internet Streaming CDSM
•
Delivery Services (from Services tab)
•
Live Video (from Services tab)
Figure 3-7
Devices Table Page
You can sort the information in the table by clicking on any column title. The table can be sorted in
ascending or descending order for each column. The task bar options provide other table manipulations,
including filtering, refreshing the table, viewing all items, and printing.
The bottom of the table lists the page number and the total number of pages, as well as how many items
are showing out of the total number of items.
The table defaults to listing ten rows. You can change the number of rows shown by clicking the Rows
drop-down list.
To get more information on an item or to configure an item, click the Edit icon to the left of the item
name. To create a new item, click the Create New icon in the task bar.
Devices Home Page
The Devices home page provides information about the device, as well as the ability to perform the
following tasks:
•
Activate the device
•
Update the device software
•
Assign the device to baseline groups
From the Devices home page you can access the delivery services and device groups the device is
assigned to, by clicking the appropriate link. All delivery services, or device groups (depending on which
link you clicked), configured in your CDS are displayed. Through this page, you can assign the device
to additional delivery services or device groups by clicking the icon next to the applicable delivery
services or device groups and submitting your selection.
The Devices home page offers detailed bandwidth and bytes-served graphs with detailed reports for
each.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-8
Chapter 3
Getting Started
Navigating the Internet Streaming CDSM
The left panel menu has two toggle buttons: Show Basic/Show All and Expand All/Collapse All.
•
Show All
Shows all the menu items in the menu.
•
Show Basic
Shows only the Device home menu item.
•
Expand All
Shows every menu and submenu.
•
Collapse All
Shows only the top-level menu items.
Task Bar
The task bar displays information about the page you are on and provides associated tasks. All task bar
icons, as well as other icons, have labels that are displayed when you roll over the icon with your mouse
pointer.
Any icon used in a procedure is referenced by the rollover label; for example, Create New is the rollover
label for the following icon:
Table 3-1 describes the icons available in the CDSM.
Table 3-1
Icon
CDSM Icons
Function
Activates all inactive Service Engines.
Displays devices.
Displays left-panel menu.
Deactivates the device.
Updates application statistics.
Forces refresh of replication information or process content
changes.
Goes back to Replication Status page.
Forces full database update.
Forces settings on SEs in group.
Forces the group settings.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-9
Chapter 3
Navigating the Internet Streaming CDSM
Table 3-1
Icon
CDSM Icons (continued)
Function
Views read-only items.
Creates a new item.
Edits an item.
Deletes an item.
Adds a content item for acquisition.
Deletes a selected item.
Manages between host and proxy servers for content acquisition.
Saves to disk.
Views complete URL (+) or view (-) partial URL that is used to
acquire content.
Exports a table to a comma-separated value (CSV) file.
Creates a filtered table. Filter the table based on the field values.
Displays a graph.
Applies the default settings to the device.
Overrides the group settings on the device.
Views all table entries. Click this icon to view all entries after you
have created a filtered table.
Refreshes the table.
Reboots the device.
Prints the current window.
Copies a program.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-10
Getting Started
Chapter 3
Getting Started
Configuring Primary and Standby CDSMs
Table 3-1
Icon
CDSM Icons (continued)
Function
Previews a program.
Assigns all items to the entity.
Removes all items from the entity.
Indicates that the current transaction was successfully completed.
Indicates that user input is invalid and that the transaction did not
finish.
Configuring Primary and Standby CDSMs
The Internet Streaming CDSM can operate in two different roles: primary and standby. The primary role
is the default. You can have only one primary CDSM active in your network; however, you can have any
number of CDSMs operating in a standby role to provide redundancy and failover capacity. You must
configure the primary CDSM first. See Cisco Content Delivery Engine 205/220/250/420 Hardware
Installation Guide for information on configuring the primary CDSM.
Note
The primary and standby CDSMs must be running the same version of software. You must upgrade your
standby CDSM first, and then upgrade your primary CDSM.
If the primary CDSM is down, the devices (SE and SR) cannot send regular reports and events to it, so
the data is sent to the standby CDSM. After the primary CDSM is online, the database on the standby
CDSM is synchronized with the database on the primary CDSM.
To configure a standby CDSM, do the following using the CLI:
Step 1
Follow the instructions for configuring a CDSM using the setup utility, except do not enter the IP address
of the CDSM. The instructions can be found in the Cisco Content Delivery Engine 205/220/250/420
Hardware Installation Guide.
Step 2
Configure the standby CDSM.
CDE(config)# cdsm role standby
Step 3
Identify the IP address of the primary CDSM.
CDE(config)# cdsm ip 10.1.1.90
Step 4
Start the Centralized Management System (CMS).
CDE(config)# cms enable
Step 5
Save the configuration.
CDE# copy running-config startup-config
Step 6
Activate the standby CDSM by using the web interface of the primary CDSM.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-11
Chapter 3
Getting Started
Configuring Primary and Standby CDSMs
The primary CDSM notifies all registered devices that a standby CDSM exists and sends each device the
information it needs to contact the standby should the primary fail or become inactive.
Note
You cannot log in to the web interface of the standby CDSM. Its function is to maintain an up-to-date
copy of the primary’s database.
Changing a Standby to a Primary CDSM
Note
If your primary CDSM is still operating, you must change its role to standby by executing the cdsm role
standby command before following these steps. You can only have one primary CDSM operating at any
given time.
Note
To change the standby CDSM to become the primary, do the following:
Step 1
If your primary CDSM has failed, enter the following command:
CDE(config)# cdsm role primary
Step 2
Save the configuration.
CDE# copy running-config startup-config
Step 3
Restore the old primary CDSM, if possible.
Step 4
When the old primary CDSM is restored, change its role to standby.
cdsm role standby
Step 5
Reconnect the old primary CDSM (now standby CDSM) into the CDS network.
Step 6
Wait at least one polling interval to allow the data from the primary CDSM to be copied to the standby
CDSM.
Note
Step 7
During this period, do not make any configuration changes.
When the new primary CDSM and the new standby CDSM have synchronized, you can change the roles
of the CDSMs back to their original roles.
Note
There can only be one primary CDSM in a CDS at one time. If there are two primary CDSMs,
both CDSMs are halted.
To do this, do the following:
a.
Change the role of the primary CDSM to standby.
cdsm role standby
b.
Change the role of the standby CDSM to primary.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-12
Chapter 3
Getting Started
Typical Configuration Workflow
cdsm role primary
Note
If you have recently made configuration changes to the primary CDSM, wait at least the
polling interval before changing roles to ensure that the standby has a record of the most
recent configuration changes.
Recovering from Two Primary CDSMs
If you did not change the primary CDSM to standby before you changed the standby CDSM to primary,
you will have two primary CDSMs in your CDS and both will be halted. To restore both CDSMs, do the
following:
Step 1
Make sure the CDSM that is to be designated as the standby is in fact the standby by entering the cdsm
role standby command.
Step 2
Initiate the CMS on the standby CDSM by entering the cms enable command.
Step 3
Make sure the CDSM that is to be designated as the primary is in fact the primary by entering the cdsm
role primary command.
Step 4
Initiate the CMS on the primary CDSM by entering the cms enable command.
Step 5
Make sure the standby CDSM is activated by using the web interface of the primary CDSM.
Typical Configuration Workflow
Once you have completed activating and configuring the NTP servers for all the devices in the CDSM,
you are ready to configure the CDS for content delivery. For information about activating and
configuring the NTP servers for a device, see the “Activating and Setting NTP for Each Device” section
on page 3-3.
Table 3-2 lists the basic tasks for configuring the CDS for content delivery, with references to the
associated sections in each chapter.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-13
Chapter 3
Getting Started
Typical Configuration Workflow
Table 3-2
Configuration Workflow
Task
Description
Where to Find More Information
Change admin
password
Change the administrator password
on each device, including the CDSM,
and change the administrator
password for the system
Log in to the CLI for the device and use
the username admin password
<password> global configuration
command.
The password strength must be a
combination of alphabetic characters, at
least one number, at least one special
character, and at least one uppercase
character.
To change the password for the CDSM
GUI and CLI, go to “Creating, Editing,
and Deleting Users,” page 6-2
Configure
Dedicated
Management with
Redundant Port
Separate management traffic from
application traffic, and configure a
redundant port for management
“Configuring Port Channel,” page J-6
Create Device
Groups
Group like devices to speed up
configuration
“Configuring Device Groups,” page 4-4
Configure RCP
Configure Remote Copy Protocol
(RCP) to listen for requests on TCP
port 514
“Enabling RCP,” page 4-67
Configure FTP
Enable FTP services to listen for
connection requests
“Enabling FTP Services,” page 4-66
Configure Web
Engine
For all SEs participating in delivering “Configuring Web Engine HTTP Cache
content
Freshness,” page 4-47
Configure
Windows Media
Engine
For all SEs participating in delivering Begins with “Configuring Windows
Windows Media content
Media Streaming—General Settings,”
page 4-39
Configure Movie
Streamer
For all SEs participating in delivering “Configuring Movie Streamer—General
MPEG or MOV content
Settings,” page 4-43
Configure Flash
Media Streaming
For all SEs participating in delivering “Configuring Flash Media
Flash Media Streaming content
Streaming—General Settings,” page 4-45
Create Coverage
Zone File
Map SEs to client service areas by IP Appendix C, “Creating Coverage Zone
address or geographic location
Files”
Import or Upload
Coverage Zone
File
Apply Coverage Zone mappings to
CDS
“Coverage Zone File Registration,”
page 6-12
Configure Global
Routing Method
Set the Coverage Zone file
“Configuring Global Routing,” page 6-13
Configure Routing Configure the routing method used by “Configuring the Service Router,”
Method
SRs
page 4-101
Configure Content Define all origin servers that are used “Content Origins,” page 5-1
Origins
in delivery services
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-14
Chapter 3
Getting Started
Typical Configuration Workflow
Table 3-2
Configuration Workflow (continued)
Task
Description
Where to Find More Information
Create Delivery
Service
Definitions
Create delivery services for both
“Creating Delivery Service,” page 5-15
prefetched or cached content and live
programs
Create Live
Programs
Create live programs, or rebroadcasts “Configuring Programs,” page 5-42
and schedules
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-15
Chapter 3
Typical Configuration Workflow
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
3-16
Getting Started
CH A P T E R
4
Configuring Devices
This chapter section discusses configuring locations and device groups for devices, and detailed
instructions on configuring the different types of devices–CDSMs, SEs, and, SRs. This chaptersection
presents the following major topics:
•
Configuring Locations, page 4-1
•
Configuring Device Groups, page 4-4
•
Configuring the Service Engine, page 4-10
•
Configuring the Service Router, page 4-101
•
Configuring the CDSM, page 4-132
Configuring Locations
Locations are set up in the Internet Streaming CDSM to organize and group SEs into virtual networks
for distribution of content through delivery services. For more information about locations, see the
“Cisco CDS Topology” section on page 2-1.
Locations need to be configured before you can activate SEs and SRs and bring them online in the CDS
network. Table 4-1 describes the icons for the Locations Table page.
Table 4-1
Icon
Location Icons
Function
Create a new location.
Create a filtered table.
View all locations.
Refresh the table.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-1
Chapter 4
Configuring Devices
Configuring Locations
Table 4-1
Icon
Location Icons (continued)
Function
Print the current window.
Edit a location.
To create a new location or edit an existing one, do the following:
Step 1
Choose Devices > Locations. The Locations Table page is displayed (Figure 4-1).
The table is sortable by clicking the column headings.
Figure 4-1
Step 2
Locations Table Page
In the task bar, click the Create New Location icon. The Creating New Location page is displayed
(Figure 4-2).
To edit a location, click the Edit icon next to the location name.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-2
Chapter 4
Configuring Devices
Configuring Locations
Figure 4-2
Step 3
Enter the settings as appropriate. See Table 4-2 for a description of the fields.
Table 4-2
Step 4
Creating New Location Page
Location Fields
Field
Description
Name
Name of the location.
Parent Location
Choose a location from the drop-down list. A location with no parent, None, is
level 1. The location level is displayed after you choose a parent location.
Comments
Enter any information about the location.
Click Submit to save the settings.
To delete a location, from the Locations Table page, click the Edit icon next to the location you want to
delete, and click the Delete icon in the task bar.
To view the location tree, click the Location Trees icon in the task bar. The location tree represents the
network topology you configured when you assigned a parent to each location.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-3
Chapter 4
Configuring Devices
Configuring Device Groups
Configuring Device Groups
The Internet Streaming CDSM allows you to configure SEs into device groups so that the entire group
of SEs is configured at one time. Device groups and SEs share the same configuration features and
options.
Table 4-3 describes the icons for the Device Groups Table page.
Table 4-3
Icon
Device Group Table Icons
Function
Creates a new device group.
Creates a filtered table.
Views all device groups.
Refreshes the table.
Prints the current window.
Edits a device group.
This section covers creating, editing, and deleting device groups. All other configuration pages for a
device group are covered in the “Configuring the Service Engine” section on page 4-10.
To create or edit a device group, do the following:
Step 1
Choose Devices > Device Groups. The Device Groups Table page is displayed (Figure 4-3).
The table is sortable by clicking the column headings.
Figure 4-3
Step 2
Device Groups Table Page
In the task bar, click the Create New Device Group icon. The Creating New Device Group page is
displayed (Figure 4-4).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-4
Chapter 4
Configuring Devices
Configuring Device Groups
To edit a device group, click the Edit icon next to the device group name.
Figure 4-4
Creating New Device Group Page
Step 3
In the Name field, enter the name of the device group. The name must be unique and should be a name
that is useful in distinguishing the device group from the others in the CDS.
Step 4
Check the Automatically assign all newly activated devices to this group check box if applicable.
Step 5
Choose Regular Group to indicate this group is not used as a baseline for all SEs or choose Baseline
Group and select the baseline type to define this group as a baseline for all SEs.
For information about baseline groups, see the “Baseline Groups” section on page 2-3“Baseline Groups”
section on page 2-3.
Step 6
To customize the left panel menu for this device group, click the Select pages to hide from the menu
for this device group arrow, and check the pages you want to hide. To collapse these settings, click the
arrow again.
Use this feature to remove from view any configuration pages that you do not need for the device group.
Step 7
In the Comments field, enter any information about the device group.
Step 8
Click Submit to save the settings.
If you are editing this device group, you can view a list of all settings configured for this device group
by clicking the Pages configured for this device group arrow. To collapse this information list, click
the arrow again.
To delete a device group, click the Delete icon in the task bar.
Step 9
Note
To assign SEs to the device group, choose Assignments > Devices. The Assignment table is displayed
listing all SEs in the CDS.
From this point forward, the steps to get to a configuration page are combined into one step using
notation similar to the following: Device Group > Assignments > Devices.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-5
Chapter 4
Configuring Devices
Configuring Device Groups
Step 10
Click the Assign icon (blue cross mark) next to each SE name you want to assign to this group.
To assign all SEs, click Assign all Service Engines in the task bar.
Step 11
Click Submit to add the selected SEs to the device group.
To remove an SE from the device group, click the Unassign icon (green check mark) next to the name
of the SE, and click Submit.
To remove all SEs from the device group, click the Unassign all Service Engines icon in the task bar,
and click Submit.
Working with Device Groups
Working with Device Groups
When you first create a device group, all settings you configure for the device group are automatically
propagated to all the SEs assigned to that group.
Note
All SE settings in the “Configuring the Service Engine” section on page 4-10, except those listed below,
can also be configured for a device group. The following pages are not available for device group
configuration:
•
Devices > Application Control > Windows Media Streaming > Bypass List. See the “Configuring
Windows Media Streaming—Bypass List” section on page 4-42“Configuring Windows Media
Streaming—Bypass List” section on page 4-42 for more information.
•
Devices > General Settings > Network > Network Interfaces. See the “Viewing Network
Interfaces” section on page 4-71 for more information.
•
Devices > General Settings > Network > External IP. See the “Configuring External IP
Addresses” section on page 4-71 for more information.
•
Devices > General Settings > Network > IP ACL. See the “Configuring IP ACL for IPv4 and IPv6”
section on page 4-73 for more information.
After configuring the device group settings, the task bar for the corresponding configuration page for an
individual SE that is part of that device group displays the Override Group Settings icon and the Device
Group drop-down list with the device group name displayed.
When an SE is associated with one or many device groups, the name of the device group whose settings
were applied last are displayed.
To configure individual settings for an SE in a device group, click the Override Group Settings icon in
the task bar. You can then edit the fields on the page and click Submit. The Device Group drop-down
list displays “Select a Device Group.”
To reapply the settings for the device group, select the device group from the Device Group drop-down
list and click Submit. Alternatively, you can go to the corresponding device group configuration page
and click the Force Settings on SEs in Group. The Force Settings on SEs in Group only displays for
a device group configuration page when an SE’s individual settings override the group settings.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-6
Chapter 4
Configuring Devices
Configuring Device Groups
Note
The individual SE configuration page does not display the Override Group Settings icon and Device
Group drop-down list in the task bar if the settings have not been configured for the corresponding device
group configuration page.
Note
When adding an SE to an existing device group, the new SE does not automatically inherit the device
group settings. Use the Force Group Settings option for the device group to force the group settings to
all SEs in the group.
Alternatively, you can go to each device group configuration page and click the Force Settings on SEs
in Group. A dialog box lists all the SEs that have different configuration settings than the device group
settings. The Force Settings on SEs in Group only displays for a device group configuration page when
an SE’s individual settings override the group settings.
To force all device group settings to all assigned SEs, go to the Device Group Home page and click the
Force Group Settings icon in the task bar.
Note
The last configuration submitted for the device, whether it is the device group configuration or the
individual device configuration, is the configuration the device uses.
Table 4-4 describes the icons for the Device Groups configuration pages.
Table 4-4
Icon
Device Group Configuration Icons
Function
Deletes a device group.
Updates application statistics.
Forces full database update.
Reboots all devices in device group.
Forces the group settings. Forces the complete set of configurations
made for a device group to all devices associated with that group.
Forces settings on SEs in a device group. Forces the configuration of
the displayed page to all SEs in the device group.
Overrides the group settings on the device.
Prints the current window.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-7
Chapter 4
Configuring Devices
Configuring Device Groups
Aggregate Settings
Aggregate Settings
The following device and device group configuration pages have aggregate settings:
•
Replication > Scheduled Bandwidth. See the “Scheduled Bandwidth” section on
page 4-18“Scheduled Bandwidth” section on page 4-18 for more information.
•
Service Control > Service Rules. See the “Configuring Service Rules” section on
page 4-22“Configuring Service Rules” section on page 4-22 for more information.
•
Service Control > URL Signing. See the “Configuring URL Signing Key” section on
page 4-28“Configuring URL Signing Key” section on page 4-28 for more information.
•
Application Control > Bandwidth Schedules. See the “Configuring Bandwidth Schedules” section
on page 4-37“Configuring Bandwidth Schedules” section on page 4-37 for more information.
•
General Settings > Login Access Control > Users > Usernames. See the “Creating, Editing, and
Deleting Users—Usernames” section on page 4-57“Creating, Editing, and Deleting
Users—Usernames” section on page 4-57 for more information.
To access these pages, first choose Devices > Devices or Devices > Device Groups, followed by the Edit
icon next to the device or device group you want to configure.
Aggregate Settings is set to Yes by default. When Aggregate Settings is set to Yes, the settings for the
device group are aggregated with the settings for the SE. This means you can configure settings for all
SEs in a device group, then configure individual settings for each SE, and the combined settings for the
device group and individual SE are apply to the SE. Any settings for the device group are listed with the
View icon and any settings for the individual SE are listed with the Edit icon on the individual SE
configuration page.
If Aggregate Settings is set to No, only the individual SE settings are applied to the SE and the device
group settings do not apply to the SE.
To edit the device group settings, or configure new settings for the device group, you must go to the
device group corresponding configuration page.
If you remove all device group settings, all device settings displayed with Aggregate Settings enabled
are removed as well.
Note
The last configuration submitted for the device, whether it is the device group configuration or
the individual device configuration, is the configuration the device uses.
Table 4-5 describes the icons for the configuration pages that have aggregate settings.
Table 4-5
Icon
Aggregate Settings Icons
Function
Creates a new entry.
Edits an entry.
Deletes an entry.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-8
Chapter 4
Configuring Devices
Configuring Device Groups
Table 4-5
Icon
Aggregate Settings Icons (continued)
Function
Views read-only entry.
Creates a filtered table. Filter the table based on the field values.
Views all table entries. Click this icon to view all entries after you
have created a filtered table.
Refreshes the table.
Prints the current window.
Device Group Overlap
Device Group Overlap
If you want the ability to assign a device to more than one device group, you must enable device group
overlap. Device group overlap is enabled by default.
To enable or disable device group overlap, do the following:
Step 1
Choose System > Configuration. The Config Properties page is displayed.
Step 2
Click the Edit icon next to the DeviceGroup.overlap property. The Modifying Config Property page is
displayed.
Step 3
To enable device group overlap, choose true from the Value drop-down list.
To disable device group overlap, choose false from the Value drop-down list.
Step 4
Click Submit to save the settings.
You cannot disable device group overlap after you have assigned devices to multiple device groups.
Tip
To force the complete configuration set of a device group to all devices in that group, click the Force
Group Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-9
Chapter 4
Configuring Devices
Configuring the Service Engine
Configuring the Service Engine
This section walks you through the different configuration pages available for a Service Engine. The
main configuration groups are described as follows:
•
Replication—Settings for bandwidth usage for replication and scheduling bandwidth usage.
Additionally, distribution settings for negative acknowledgement NACK) interval and multicast
settings for designating an SE as a multicast receiver and sender.
•
Service Control—Settings for access control by way of client request filtering, URL signing, and
Authorization Server settings; additionally, transaction logs are configured to monitor traffic
•
Application Control—Settings for bandwidth management of delivery services and protocol engines
(Web, Windows Media, Movie Streamer, Flash Media Streaming, and RTSP advanced settings)
•
General Settings—Settings for access control of the device, maintenance, network connectivity, and
monitoring
The first two pages, Device Activation and Assignment, cover activating an SE in the Internet Streaming
CDSM and assigning it to a location, and assigning device groups to the SE.
Activating a Service Engine
Activating a Service Engine
Activating a device (Service Engine, Service Router, or stamdby CDSM) can be done through the
Devices home page initially, or through the Device Activation page.
To activate a device from the Device Activation page, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed (Figure 4-5).
Figure 4-5
Step 2
Devices Table Page
Click the Edit icon next to the device you want to configure. The Devices home page is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-10
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 3
Click Show All to display the top-level menu options, and click Device Activation. The Device
Activation page is displayed (Figure 4-6).
Figure 4-6
Step 4
Device Activation Page
Enter the settings as appropriate. See Table 4-6 for a description of the fields.
Table 4-6
Device Activation Fields
Field
Description
Name
Name of the device.
Activate
To activate or deactivate the device, check or uncheck the Activate check box.
Alternatively, you can click the Deactivate Device icon in the task bar.
When you uncheck the Activate check box and click Submit, the Replaceable
check box is displayed. Check the Replaceable check box when you need to
replace the device or recover lost registration information. For more information,
see the “Recovering CDS Network Device Registration Information” section on
page 8-25“Recovering CDS Network Device Registration Information” section on
page 8-28.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-11
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-6
Device Activation Fields (continued)
Field
Description
Server Offload
To offload this device for maintenance or a software upgrade, check the Server
Offload check box. When checked, the Service Router stops sending requests to
this device.
Note
If a client paused a program at that moment Server Offload is enabled,
most likely resuming the program will fail.
To monitor the current streams on an SE during the Server Offload state, use the
show interface command. If the packets received or packets sent is increasing then
the SE is streaming. The number of packets received is high if there is an incoming
stream.
Note
We recommend separating the management traffic from the streaming
traffic by using the port channel configuration, see the “Configuring Port
Channel” section on page J-6“Configuring Port Channel” section on
page J-6 for more information.
•
If management and streaming traffic are separated, the show interface
command for the streaming port channel displays information on active
sessions.
•
If management and streaming traffic are not separated, the show interface
command shows very low traffic; the packets received and packets sent are
lower than a client streaming session.
Once the SE has finished streaming, you can perform maintenance or upgrade the
software on the device. For information about upgrading the software, see the
“Upgrading the Software” section on page 8-6“Upgrading the Software” section
on page 8-6.
The Status field on the Device Activation page and the Devices Table page displays
“offloading” when Server Offload is checked.
Once the software upgrade or maintenance is complete, you need to uncheck the
Server Offload check box so that the device can again participate in the system.
Note
Content Cache
If the Server Offload option is set on an SE that is acting as the Content
Acquirer for a delivery service for dynamic ingest or live stream splitting,
a new SE is chosen as the Location Leader for the delivery service.
However, if the Content Acquirer is up and communicating with the
CDSM, it continues to perform content ingest and content distribution.
Informational only. The content cache size is the total disk space on the CDS
network file system (CDNFS) on the SE that is designated for cache. The Content
Cache represents the unused cache space. The used cache space is the disk space
allotted for all the delivery services to which the SE is assigned. To view the used
cache space, choose Services > Service Definition > Delivery Services > Assign
Service Engines.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-12
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-6
Device Activation Fields (continued)
Field
Description
Set Default
Coverage Zone
File
When checked, which is the default setting, a default Coverage Zone file is
generated with the SE serving the local subnet it resides on. The coverage zone is
a CDS network-wide mapping of client IP addresses to SE IP addresses that should
respond to client requests. For more information, see the “Coverage Zone File
Registration” section on page 6-12“Coverage Zone File Registration” section on
page 6-12.
The default coverage zone can be disabled and you can create and assign custom
coverage zones using the Coverage Zone file import or upload.
Uncheck the Set Default Coverage Zone File check box to use a user-defined
Coverage Zone file that was imported or uploaded.
Location
Lists all the locations configured for the CDS.
Use SE’s primary
IP address
Enables the CDSM to use the IP address on the primary interface of the SE for
management communications.
Management
Communication
Address
Note
If the Use SE’s primary IP Address for Management Communication
check box is checked and the Management Communication Address and
Port are configured, the CDSM uses the SE’s primary IP address for
communication.
Note
Do not check the Use SE’s primary IP Address for Management
Communication check box if you want to separate management and
streaming traffic. Instead, use the Management Communication Address
and Port fields to specify where management traffic should be sent.
Manually configures a management IP address for the CDSM to communicate with
the SE.
Manual configuration of the management IP address and port are used when using
port channel configuration to separate management and streaming traffic. For more
information about port channel configuration see the “Configuring Port Channel
and Load Balancing Settings” section on page 4-71“Configuring Port Channel and
Load Balancing Settings” section on page 4-71 and the “Configuring Port
Channel” section on page J-6“Configuring Port Channel” section on page J-6.
Management
Communication
Port
Port number to enable communication between the CDSM and the SE.
Comments
Information about the settings.
Note
To make sure the SE is binding to the primary interface (or management IP address if
configured) as the source IP address when sending management traffic to the CDSM, create a
static route from the SE to the CDSM. To configure a static IPv4 route from the SE, see the
“Configuring Static IPv4 Routes” section on page 4-81 section. To configure a static IPv6 route
from the SE, see the “Configuring Static IPv6 Routes” section on page 4-82 section.
Alternatively, you can use the ip route command and ipv6 route command on the CDS device.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-13
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 5
Click Submit to save the settings.
Assigning Devices to Device Groups
Assigning Devices to Device Groups
You can assign devices to device groups in three ways:
•
Through the Device Group Assignment page
•
Through the device Assignment page
•
Through the Devices home page, if the device group is a baseline group
To assign devices to device groups through the Assignment page, do the following:
Step 1
Choose Devices > Devices, and click the Edit icon next to the device you want to assign.
Step 2
Click Show All, and then choose Assignments > Device Groups. The Device Group Table page is
displayed with all of the configured device groups listed (Figure 4-7).
Note
From this point forward, the beginning steps in the procedures are combined into one step using
notation similar to the following: Devices > Devices Assignments > Device Groups.
Figure 4-7
Step 3
Assignment Page
Click the Assign icon (blue cross mark) next to the device group you want to assign to this SE.
Alternatively, click the Assign All Device Groups icon in the task bar.
A green arrow wrapped around the blue X indicates an SE assignment is ready to be submitted. To
unassign an SE, click this icon. The SE assignment states are described in Figure 4-8.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-14
Chapter 4
Configuring Devices
Configuring the Service Engine
Figure 4-8
Step 4
SE Assignment State
Click Submit to save the settings.
A green circle with a check mark indicates a device group is assigned to this SE. To unassign the device
group, click this icon, or click the Remove All Device Groups icon in the task bar. Click Submit to save
the changes.
Additionally, the Filter Table icon and View All Device Groups icon allow you to first filter a table and
then view all device groups again.
Replication
The bandwidth used for replication and ingest is determined by the settings in the Default Bandwidth
and the Scheduled Bandwidth pages. The replication configuration pages consist of the following:
•
Default Bandwidth
•
Scheduled Bandwidth
•
Configuring the NACK Interval Multiplier
•
Enabling SEs for Multicasting
Table 4-7 describes the icons on the replication bandwidth configuration pages.
Table 4-7
Icon
Replication Bandwidth Configuration Icons
Function
Refreshes the table or page.
Displays a graph.
Applies the default settings to the device.
Creates a new item.
Creates a filtered table. Filter the scheduled bandwidth by start time,
end time, days of the week, and bandwidth type.
Views all scheduled bandwidth. Click this icon to view all schedule
bandwidths after you have created a filtered table.
Prints the current window.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-15
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-7
Replication Bandwidth Configuration Icons
Icon
Function
Edits a scheduled bandwidth. Click this icon next to one of the
scheduled bandwidths to edit the settings.
Deletes a scheduled bandwidth. To delete a scheduled bandwidth,
click the Edit icon and then click this icon.
Default Bandwidth
Default Bandwidth
The default bandwidth settings can be configured for acquisition (ingest) and distribution (replication)
of content. The default settings are used unless a scheduled bandwidth is configured for a specified time
period.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To set the default bandwidth for replication, do the following:
Step 1
Choose Devices > Devices > Replication > Default Bandwidth. The Replication Default Bandwidth
page is displayed (Figure 4-9).
Figure 4-9
Step 2
Replication Default Bandwidth Page
Enter the settings as appropriate. See Table 4-8 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-16
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-8
Replication Default Bandwidth Fields
Field
Description
Acquisition-in
Bandwidth
Bandwidth used for ingesting content when this SE is acting as the Content
Acquirer.
The default is 1,000,000 kbps (kilobits per second).
Distribution-in
Bandwidth
Bandwidth used for incoming content that is sent by a forwarding SE as part of the
distribution process.
The default is 500,000 kbps.
Distribution-out
Bandwidth
Bandwidth used for outgoing content that is sent to a downstream SE as part of the
distribution process.
The default is 100,000 kbps.
Step 3
Click Submit to save the settings.
For information on the task bar icons, see Table 4-7.
Bandwidth Graph
Bandwidth Graph
To view a graphical representation of the bandwidth settings, click the Display Graph icon in the task
bar. The Acquisition and Distribution Bandwidth graph is displayed in a new window.
The vertical axis of the graph represents the amount of bandwidth in Kbps (kilobits per second) and the
horizontal axis represents the days of the week. The scale shown on the vertical axis is determined
dynamically based on the bandwidth rate for a particular type of bandwidth and is incremented
appropriately. The scale shown on the horizontal axis for each day is incremented for each hour. Each
type of bandwidth is represented by a unique color. A legend at the bottom of the graph maps the colors
to the corresponding bandwidths.
You can change the graph view by choosing the different options, as described in Table 4-9.
Table 4-9
Acquisition and Distribution Bandwidth Graph—Viewing Options
Option
Description
Distribution In
Bandwidth settings for incoming content distribution traffic. The default is
1,000,000.
Distribution Out
Bandwidth settings for outgoing content distribution traffic. The default is
500,000.
Acquisition In
Bandwidth settings for incoming content acquisition traffic. The default is
1,000,000.
All Servers
A consolidated view of all configured bandwidth types. This is the default.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-17
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-9
Acquisition and Distribution Bandwidth Graph—Viewing Options (continued)
Option
Description
Show Detailed
Bandwidth/Show
Effective Bandwidth
Toggles between the two options:
Show Detailed Bandwidth—Displays detailed bandwidth settings for the
SE and its associated device groups. The bandwidth settings of the
device and device groups are shown in different colors for easy
identification.
Show Effective Bandwidth—Displays the composite (aggregate)
bandwidth settings for the SE and its associated device groups.
Show Aggregate
Toggles between the two options:
View/Show
Show Aggregate View—Displays the bandwidth settings configured for
Non-Aggregate View
the corresponding device groups.
Show Non-Aggregate View—Displays the bandwidth settings
configured for the SE.
Sun, Mon, Tues,
Wed, Thurs, Fri, Sat
Displays the bandwidth settings for the corresponding day of the week.
Full Week
Displays the bandwidth settings for the entire week This is the default view
and is combined with the All Servers view.
Scheduled Bandwidth
Scheduled Bandwidth
Scheduled Bandwidth settings take precedence over Default Bandwidth settings.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure a bandwidth schedule, do the following:
Step 1
Choose Devices > Devices > Replication > Scheduled Bandwidth. The Replication Scheduled
Bandwidth Table page is displayed (Figure 4-10).
The table is sortable by clicking the column headings.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-18
Chapter 4
Configuring Devices
Configuring the Service Engine
Figure 4-10
Replication Scheduled Bandwidth Table Page
For information about Aggregate Settings, see the “Aggregate Settings” section on page 4-8“Aggregate
Settings” section on page 4-8.
Note
Step 2
Configuring Replication Bandwidth Scheduling is only supported on a per SE-basis; Device
Group configuration of Replication Bandwidth Scheduling is not supported.
Click the Create New icon in the task bar. The Replication Scheduled Bandwidth page is displayed
(Figure 4-11).
To edit a scheduled bandwidth, click the Edit icon next to the scheduled bandwidth you want to edit.
Figure 4-11
Step 3
Replication Scheduled Bandwidth Page
Enter the settings as appropriate. See Table 4-10 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-19
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-10
Replication Scheduled Bandwidth Fields
Field
Description
Bandwidth Type
Distribution-in—For incoming content distribution traffic from SEs.
Distribution-out—For outgoing content distribution traffic to SEs.
Acquisition-in—For incoming content acquisition traffic from origin servers.
Multicast-out—For outgoing multicast content traffic to SEs.
Note
Step 4
The Multicast Cloud feature is for early field trials (EFTs) and is not
supported in Release 3.1.0.
Bandwidth Rate
Maximum amount of bandwidth that you want to allow (in kbps).
Start Time
Time of day for the bandwidth setting to begin, using a 24-hour clock in local time
(hh:mm).
End Time
Time of day for the bandwidth setting to end (hh:mm).
Day Selection
Days on which bandwidth settings apply.
•
Full Week—Specifies that the allowable bandwidth settings are applied for an
entire week.
•
Sun, Mon, Tue, Wed, Thu, Fri, and Sat—Specifies individual days of the week
on which the allowable bandwidth settings take effect.
Click Submit to save the settings.
For information on the task bar icons, see Table 4-7.
Configuring the NACK Interval Multiplier
Configuring the NACK Interval Multiplier
To identify missing content and trigger a resend of a file, receiver SEs send a negative acknowledgement
(NACK) message to the sender SE. NACK messages generated by many receiver SEs could generate
more traffic than the sender can handle. The NACK interval multiplier allows you to adjust the average
interval between NACKs for an individual receiver SE. This value (a percentage from 10 to 100 percent
of normal, to a multiple of normal from 2 times to 10 times) adjusts the default average NACK interval.
The default or normal setting is 20 minutes. As an example, if the NACK interval multiplier is set to 3,
the interval between NACKs becomes 20 minutes x 3, or 60 minutes.
Note
The Multicast Cloud feature is supported in all releases starting from Release 3.1.1.
To send an immediate NACK request rather than wait for the scheduled interval, enter the distribution
multicast send-nack-now command on a multicast receiver SE.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-20
Chapter 4
Configuring Devices
Configuring the Service Engine
To configure the NACK interval multiplier, do the following:
Step 1
In the CDSM GUI, choose Devices > Devices > Replication > Distribution. The Distribution page is
displayed.
Step 2
Click and drag the Content NACK Interval Multiplier slider control across the calibrated ruler to
adjust the interval between NACK messages. The scale ranges from 10 percent of normal to 10 times
normal. The center of the scale corresponding to “normal” denotes the default of 20 minutes. The value
corresponding to the slider position is displayed to the right of the slider.
Step 3
Click Submit to save the settings.
Enabling SEs for Multicasting
Enabling SEs for Multicasting
Before you can create a multicast cloud, the SEs must be enabled for multicasting. These
multicast-enabled SEs can then be assigned as sender and receiver SEs of a multicast cloud.
Note
The Multicast Cloud feature is supported in all releases starting from Release 3.1.1.
To enable SEs for multicasting, do the following:
Step 1
From the CDSM GUI, choose Devices > Devices > Replication > Multicast Distribution. The
Multicast Distribution page is displayed.
Step 2
Check the Enable multicast receiver check box if this SE is to act as a multicast receiver.
Check the Enable multicast sender check box if this SE is to act as a multicast sender.
Step 3
Click Submit to save the settings.
Service Control
The Service Control pages provide settings for client request filtering, URL signing, and Authorization
Server settings. Additionally, transaction logs that monitor traffic are configured under the Service
Control. Configuring service control consists of the following procedures:
•
Configuring Service Rules
•
Configuring URL Signing Key
•
Configuring the Authorization Service
•
Configuring Transaction Logs
Table 4-11 describes the icons for the Service Control pages.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-21
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-11 Service Control Icons
Icon
Function
Refreshes the table or page.
Applies the default settings to the device.
Creates a new item.
Creates a filtered table.
Views all data. Click this icon to view all data after you have created
a filtered table.
Prints the current window.
Edits an item.
Deletes an item. To delete an item, click the Edit icon and then click
this icon.
Configuring Service Rules
Configuring Service Rules
Note
This is a licensed feature. Please ensure that you have purchased a Service Rule license for this advanced
feature.
The Rules Template licensed feature provides a flexible mechanism to specify configurable caching
requests by allowing these requests to be matched against an arbitrary number of parameters, with an
arbitrary number of policies applied against the matches. You can specify a set of rules, each clearly
identified by an action and a pattern. Subsequently, for every incoming request, if a pattern for a rule
matches the given request, the corresponding action for that rule is taken.
Note
The processing time on the SE is directly related to the number of service rules configured. Processing
times increase with an increase in the total number of rules configured. If the SE processing time is
greater than twice the datafeed poll rate, then the device goes offline until the processing is completed.
You can avoid this by configuring a higher datafeed poll rate. The recommended datafeed poll rate for
750 service rules is 300 seconds. To configure the datafeed poll rate, see the “Configuring System
Settings” section on page 6-7.
Configuring a service rule consists of the following tasks:
•
Enabling the service rules. (Only needs to be performed once.)
•
Configuring a pattern list and adding a pattern to it.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-22
Chapter 4
Configuring Devices
Configuring the Service Engine
•
Associating an action with an existing pattern list.
There are three cases for service rules:
1.
If allow rules are configured, then it is an implicit deny.
2.
If deny rules are configured, then it is an implicit allow.
3.
If both allow and deny rules are configured, then it is an implicit allow.
For example, if all URL requests that match HTML are blocked implicitly, all requests that match other
URL requests are allowed.
If all URL requests that match WMV are allowed implicitly, all request that match other URL requests
are blocked.
If both of the above rules are configured, then HTML URL requests are blocked, and all other URL
requests are allowed.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure or edit service rule settings, do the following:
Step 1
Choose Devices > Devices > Service Control > Enable Rules. The Enable Service Rules page is
displayed.
Step 2
Check the Enable check box to enable the use of rule settings.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
Step 4
Choose Devices > Devices > Service Control > Service Rules. The Service Rules Table page is
displayed.
The table is sortable by clicking the column headings.
For information about Aggregate Settings, see the “Aggregate Settings” section on page 4-8“Aggregate
Settings” section on page 4-8.
Step 5
Click the Create New icon in the task bar. The Service Rules page is displayed (Figure 4-12).
To edit a service rule, click the Edit icon next to the service rule you want to edit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-23
Chapter 4
Configuring Devices
Configuring the Service Engine
Figure 4-12
Step 6
Service Rules Page
Create a pattern list and add a pattern to it.
a.
From the Rule Type drop-down list, choose pattern-list.
b.
In the Rule Parameters field, configure the pattern list number and the pattern type, following the
rules usage guidelines shown on the Service Rules page. See Table 4-12 for a description of pattern
types. The rule patterns are not case-sensitive.
For example, to create pattern list number 72 with the pattern type domain and the yahoo.com
domain as the domain to be acted on, enter 72 domain yahoo.com in the Rule Parameters field.
Table 4-12
Service Rules Pattern Types
Pattern Type
Description
Syntax
domain
rule pattern-list list_num
Matches the domain name in the URL or the host header against a
regular expression. For example, “.*ibm.*” matches any domain name domain dn_regexp
that contains the “ibm” substring. “\.foo\.com$” matches any domain
name that ends with the “.foo.com” substring.
In regular expression syntax, the dollar sign ($) metacharacter directs
that a match is made only when the pattern is found at the end of a line.
group-type
Patterns can be combined by using the AND or OR function with the rule pattern-list list-num
group-type pattern (for example, rule pattern-list 1group-type and). group-type {and | or}
The default is OR.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-24
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-12
Service Rules Pattern Types (continued)
Pattern Type
Description
Syntax
header-field
Request header field pattern.
rule pattern-list list_num
header-field {referer ref_regexp
| request-line req_regexp |
user-agent ua_regexp}
Request header field patterns referer, request-line, and user-agent
are supported for the allow, block, and redirect actions. The referer
pattern is matched against the Referer header in the request, the
request-line pattern is matched against the first line of the request, and
the user-agent pattern is matched against the User-Agent header in the
request. The user-agent pattern is not case sensitive.
Note
Flash Media Streaming supports the referer header field
pattern for the allow and block actions.
scr-ip
Matches the source IP address and netmask of the request.
rule pattern-list list_num src-ip
s_ipaddress s_subnet
url-regex
Matches the URL against a regular expression. The match is not case
sensitive.
rule pattern-list list_num
url-regex url_regexp
url-regsub
For the rewrite and redirect actions, matches the URL against a
rule pattern-list list_num
regular expression to form a new URL in accordance with the pattern url-regsub url_regexp url_sub
substitution specification. The match is not case sensitive. The valid
substitution index range is from 1 to 9.
Note
For HTTP client requests for Windows Media Streaming live
programs, an ASX file is created automatically; therefore, if
you use the url-regsub pattern list to rewrite the filename from
an .asf file extension to an .asx file extension, the SE is not able
to find the file and returns a 404 error message.
Note
Only one url-regsub pattern list is supported. Multiple
substitutions for the same pattern list are not supported.
Note
Step 7
A domain pattern list matching an SE IP address is not supported when IP-based redirection is
enabled on the Service Router. See the “Configuring the Service Router” section on page 4-101
for more information about IP-based redirection. Flash Media Streaming bypasses the rules
configuration if the request is from another SE.
Click Submit to save the settings.
The maximum number of pattern lists allowed is 128.
Step 8
Associate an action with an existing pattern list.
a.
Choose an action type from the Rule Type drop-down list. See Table 4-13 for a description of rule
actions.
b.
In the Rule Parameters field, enter the list number of the pattern list that you want to associate with
this action.
For example, if you want to block access by any protocol to yahoo.com, then choose block from the
Rule Type drop-down list, and enter pattern-list 72 protocol all in the Rule Parameters field.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-25
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-13
Note
For the Web Engine and Flash Media Streaming, the Service Rule file must be used if service
rules are to be configured.
Note
All Windows Media Streaming per-device service rules configured for URL signature and
validation must be converted to the per-delivery service Service Rule XML file. This change
only applies to the generate-url-signature and validate-url-signature service rule actions for
Windows Media Streaming. The other service rule actions (allow, block, no-cache, redirect,
refresh, replace, and rewrite) still use the per-device service rule configuration for Windows
Media Streaming. For more information, see the “Converting Old Windows Media Streaming
Service Rules for URL Signing and Validation” section on page F-24“Converting Old Windows
Media Streaming Service Rules for URL Signing and Validation” section on page F-25.
Note
Windows Media Streaming supports all service rule actions listed in Table 4-13, except
validate-url-signature. Movie Streamer supports the following service rule actions: allow, block,
redirect, rewrite, and validate-url-signature.
Service Rule Actions
Action Type
Description
Syntax
allow
Allows incoming requests that match the pattern list.
rule action allow pattern-list
list_num [protocol {all | http | rtmp |
rtsp}]
This rule action can be used in combination with block actions to
allow selective types of requests. The allow action does not carry
any meaning as a standalone action.
block
Blocks this request and allows all others.
rule action block pattern-list
list_num [protocol {all | http | rtmp |
rtsp}]
no-cache
Does not cache this object.
rule action no-cache pattern-list
list_num [protocol {all | http | rtmp |
rtsp}]
redirect
Redirects the original request to a specified URL. Redirect is
rule action redirect url pattern-list
relevant to the RADIUS server only if the RADIUS server has been list_num [protocol {all | http | rtmp |
configured for redirect.
rtsp}]
refresh
For a cache hit, forces an object freshness check with the server.
rule action refresh pattern-list
list_num [protocol {all | http}]
replace
Replace the text string in the object.
rule action replace string_to_find
string_to_replace pattern-list
list_num [protocol {all | http | rtmp |
rtsp}]
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-26
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-13
Service Rule Actions (continued)
Action Type
Description
Syntax
rewrite
Rewrites the original request as a specified URL.
rule action rewrite pattern-list
list_num [protocol {all | http | rtmp |
rtsp}]
validate-urlsignature
Validates the URL signature for a request using the configuration
on your SE for the URL signature and allows the request
processing to proceed for this request.
rule action validate-url-signature
{error-redirect-url url | exclude {all
error-redirect-url url | client-ip
error-redirect-url url | expiry-time
The error-redirect-url keyword redirects requests that failed
error-redirect-url url |
validation to a specified URL. The error-redirect-url keyword is
domain-name error-redirect-url
only supported for HTTP URLs.
url} pattern-list list_num [protocol
The exclude keyword excludes the client IP address, the content {all | http | rtmp | rtsp}]}
expiry time, domain, or both the client IP address and expiry time
from the URL signature validation, and redirects requests that
failed validation to a specified URL.
The exclude client-ip keywords instruct the SE to ignore the
client’s IP address when processing the validation of the signed
URL. The command could be configured as rule action
validate-url-signature exclude client-ip error-redirect-url aa
pattern-list 1 protocol all.
The exclude expiry-time keywords instruct the SE to ignore the
expiry time that normally limits access to the content when the
expiry time has occurred. The command could be configured as
rule action validate-url-signature exclude expiry-time
error-redirect-url pattern-list 1 protocol all.
The exclude domain-name keyword instructs the SEs to ignore
the domain in the URL when processing the validation of the
signed URL. The command could be configured as rule action
validate-url-signature exclude domain-name
error-redirect-url pattern-list 1 protocol all.
The exclude all keywords instruct the SE to ignore both the client
IP address and the content expiration time when processing the
validation of the signed URL. The command could be configured
as rule action validate-url-signature exclude all
error-redirect-url aa pattern-list 1 protocol all.
Step 9
Note
Click Submit to save the settings.
When configuring service rules, you must configure the same service rules on all SEs participating in a
delivery service in order for the service rules to be fully implemented. The rule action must be common
for all client requests because the SR may redirect a client request to any SE in a delivery service
depending on threshold conditions.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-27
Chapter 4
Configuring Devices
Configuring the Service Engine
Execution Order of Rule Actions
Execution Order of Rule Actions
The order in which the rule actions are implemented for Windows Media Streaming and Movie Streamer
is the order in which they were configured, except for the validate-url-signature action. If the rule pattern
associated with the validate-url-signature action is matched, regardless of the configuration order of the
rules, the validate-url-signature action is performed before any other action.
1.
validate-url-signature
2.
block or allow
Note
Note
The allow and block actions carry the same precedence. The order of implementation
depends on the order of configuration between allow and block actions. Other actions always
take precedence over allow.
3.
redirect (before cache lookup)
4.
rewrite (before cache lookup)
For the Web Engine and Flash Media Streaming, the Service Rule file must be used if service rules are
to be configured. See the Appendix F, “Creating Service Rule Files” for more information.
Configuring URL Signing Key
Configuring URL Signing Key
URL signature keys are word values that ensure URL-level security. The URL signature key is a shared
secret between the device that assigns the key and the device that decrypts the key. Based on your
network settings, either the SE itself or some other external device can assign the signature key to the
URL, but the SE decrypts the URL signature key.
The CDS uses a combination of key owners, key ID numbers, and a word value to generate URL
signature keys. You can have a maximum of 32 key owners. Each key owner can have up to 16 key ID
numbers.
To create request-specific URL signature keys, you can choose to append the IP address of the client that
has made the request to the URL signature key.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To create a URL signature key, do the following:
Step 1
Choose Devices > Devices > Service Control > URL Signing. The URL Signing Table page is
displayed.
The table is sortable by clicking the column headings.
For information about Aggregate Settings, see the “Aggregate Settings” section on page 4-8“Aggregate
Settings” section on page 4-8.
Step 2
Click the Create New icon in the task bar. The URL Signing page is displayed.
To edit the URL signature, click the Edit icon next to the URL Signature Key ID owner you want to edit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-28
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 3
Enter the settings as appropriate. See Table 4-14 for a description of the fields.
Table 4-14
URL Signature Key Settings
Field
Description
Cryptographic
Algorithm
Choose either Symmetric Key or Asymmetric Key. For more information, see
the “URL Signing and Validating” section on page I-6“URL Signing and
Validating” section on page I-6.
Key ID Owner
Specify the ID number for the owner of this encryption key. Valid entries are
from 1 to 32.
Key ID Number
Specify the encryption key ID number. Valid entries are from 1 to 16.
Key
Field for Symmetric Key only. Enter a unique URL signature key with up to 16
characters (excluding double quotes at the beginning and end of the string). This
field accepts only 7-bit printable ASCII characters (alphabetic, numerics, and
others) and does not support a space or the following special characters: pipe (|),
question mark (?), double quotes ("), and apostrophe (’). The following special
characters are allowed: {}!#$%&()*+,-./;:<=>@\~^[]_
Quoted and unquoted strings are allowed. Double quotes (") are allowed at the
beginning and end of the string only. If you do not surround the key string with
double quotes, quotes are added when you click Submit.
Public Key URL
Field for Asymmetric Key only. The location of the public key file. Only HTTP,
HTTPS, or FTP addresses are supported. The public/private key pair is stored in
Privacy Enhanced Mail (PEM) format.
Note
Private Key URL
Field for Asymmetric Key only. The location of the private key file. Only HTTP,
HTTPS, or FTP addresses are supported. The public/private key pair is stored in
Privacy Enhanced Mail (PEM) format.
Note
Symmetric Key
Step 4
While Validation, the public key file is checked if the file size exceeds
2000 bytes and if the file starts with "-----BEGIN PUBLIC KEY-----"
and contains "-----END PUBLIC KEY-----" line
While Validation, the private key file is checked if the file size exceeds
2000 bytes and if the file starts with "-----BEGIN EC PRIVATE
KEY-----" and contains "-----END EC PRIVATE KEY-----" line
Field for Asymmetric Key only. A 16-byte American Encryption Standard
(AES) key used for AES encryption of the signed URL.
Click Submit to save the settings.
For information on the URL signing mechanism, see Appendix I, “URL Signing and Validation.”
Configuring the Authorization Service
Configuring the Authorization Service
When Authorization Service is enabled, client requests are blocked if the request is for an unknown
server or if the client’s IP address or geographic location is not allowed to request content. The
Authorization Service is enabled by default and includes both types of blocking.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-29
Chapter 4
Configuring Devices
Configuring the Service Engine
The Authorization Service verifies that all client requests have a service routing fully-qualified domain
name (RFQDN) or origin server FQDN (OFQDN) that is recognized as part of a delivery service. For
more information about RFQDNs and origin server, see the “Content Origins” section on page 5-1. If
you want to allow client requests for unknown hosts, check the Enable Unknown-Server Requests
check box.
Note
The string “.se.” cannot be used in the RFQDN and OFQDN.
To block client requests based on geographical location, the SE communicates with a Geo-Location
server, which maps IP addresses to a geographic locations. The Geo-Location server, which is the same
Geo-Location server used for location-based routing on the SR, identifies the geographic location of a
client request by the country, state, and city of the client. See the “Configuring Request Routing
Settings” section on page 4-105“Configuring Request Routing Settings” section on page 4-105. For
more information about the Geo-Location servers, see the “Geo-Location Servers” section on
page 4-107.
Each delivery service participating in the Authorization Service has a Geo/IP file that contains
information on the allowed client IP addresses and geographic locations, and denied client IP addresses
and geographic locations. The Authorization Service blocks client requests based on the Geo/IP file
uploaded for the delivery service.
The SE that receives the client request compares the client’s information, as well as the URL string
pattern, with the information configured for the delivery service and allows or denies the request. If the
Authorization Service denies the request, the protocol engine receives the denied message and sends a
request denied message to the client. For more information, see the“Authorization Plugins” section on
page 5-23 “Authorization Plugins” section on page 5-24.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable the Authorization Service, do the following:
Step 1
Choose Devices > Devices > Service Control > Authorization Service. The Authorization Service page
is displayed.
Step 2
To enable the Authorization Service, check the Enable Authorization check box.
The Authorization Service is enabled by default.
Step 3
To disable the Geo Plugin on this SE, uncheck the Enable Geo Plugin check box. The Geo Plugin is
enabled by default.
The Geo/Ip Plugin is configured for each delivery service that has a Geo/Ip file associated. Every SE in
the delivery service contacts the Geo-Location server to look up the client IP address for the allowed
geographical locations. However, not every SE needs to contact the Geo-Location server (for example,
upstream SEs). Disabling the Geo Plugin on upstream SEs reduces the number of times the
Geo-Location server is contacted.
Step 4
In the Primary Address and associated Port fields, enter the IP address and port number of the primary
Geo-Location Server.
Step 5
In the Secondary Address and associated Port fields, enter the IP address and port number of the
primary Geo-Location Server.
Step 6
To allow client requests for unknown hosts, while at the same time keeping the Authorization Service
enabled, check the Enable Unknown-Server Requests check box.
Step 7
Click Submit to save the settings.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-30
Chapter 4
Configuring Devices
Configuring the Service Engine
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
Note
If the primary Geo-Location server is shut down and a secondary Geo-location server is
configured and is up, requests are sent to the secondary Geo-Location server in a failover-type
scenario. If the primary Geo-Location server is brought back up and is online, requests are still
routed to the secondary Geo-Location server as long as the secondary Geo-Location server is up.
Only if the secondary Geo-Location server goes down and the primary Geo-Location server is
up will a fallback occur and requests once again will be routed to the primary Geo-Location
server.
Configuring Transaction Logs
Configuring Transaction Logs
Transaction logs allow administrators to view the traffic that has passed through the SE. Typical fields
in the transaction log are the date and time when a request was made, the URL that was requested,
whether it was a cache hit or a cache miss, the type of request, the number of bytes transferred, and the
source IP address. For more information about transaction logs and their formats, see the “Transaction
Logs” section on page 7-50.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable transaction logging, do the following:
Table 4-15
Step 1
Choose Devices > Devices > Service Control > Transaction Logging. The Transaction Log Settings
page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-15 for a description of the fields.
Transaction Log Settings Fields
Field
Description
General Settings
Transaction Log Enable
Enables transaction logging.
Snapshot Counter Log
Enable
Enables the Snapshot Counter transaction log. For more information, see
the “Snapshot Counter Transaction Logs” section on page 7-93“Snapshot
Counter Transaction Logs” section on page 7-95.
Log Windows Domain
If NTLM authentication is configured, you can record the Windows
domain name and username in the “authenticated username” field of the
transaction log by checking this check box. For more information, see the
“Transaction Logging and NTLM Authentication” section on
page 7-60“Transaction Logging and NTLM Authentication” section on
page 7-61.
Compress Files before
Export
When this check box is checked, archived log files are compressed into
gzip format before being exported to external FTP servers
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-31
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-15
Transaction Log Settings Fields (continued)
Field
Description
Log File Format
Log file format choices are extended-squid or apache. The default is
apache. For more information, see the “Transaction Log Formats for Web
Engine” section on page 7-51“Transaction Log Formats for Web Engine”
section on page 7-52.
Log Format Custom
Or, choose Log Format Custom and enter a custom format string. For
more information, see the “Custom Format” section on
page 7-54“Custom Format” section on page 7-55.
Archive Settings
Max size of Archive File
Maximum size (in kilobytes) of the archive file to be maintained on the
local disk. The range is from 1000 to 2000000. The default is 500000.
Max number of files to be
archived
Maximum number of files to be maintained on the local disk. The range
is from 1 to 10000. The default is 10.
Archive occurs
How often the working log is archived and the data is cleared from the
working log. Choose one of the following:
•
Choose every to archive every so many seconds, and enter the
number of seconds for the interval. The range is from 120 to 604800.
•
Choose every hour to archive using intervals of one hour or less, and
choose one of the following:
– at—Specifies the minute in which each hourly archive occurs
– every—Specifies the number of minutes for the interval (2, 5, 10,
15, 20, or 30)
•
Choose every day to archive using intervals of one day or less, and
choose one of the following:
– at—Specifies the hour in which each daily archive occurs
– every—Specifies the number of hours for the interval (1, 2, 3, 4,
6, 8, 12, 24)
•
Choose every week on to archive at intervals of one or more times a
week, choose the days of the week, and choose what time each day.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-32
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-15
Transaction Log Settings Fields (continued)
Field
Description
Export Settings
Enable Export
Enables exporting of the transaction log to an FTP server.
Export occurs
How often the working log is sent to the FTP server and the data is cleared
from the working log. Choose one of the following:
•
Choose every to export every so many minutes, and enter the number
of minutes for the interval. The range is from 1 to 10080.
•
Choose every hour to export using intervals of one hour or less, and
choose one of the following:
– at—Specifies the minute in which each hourly export occurs
– every—Specifies the number of minutes for the interval (2, 5, 10,
15, 20, or 30)
•
Choose every day to export using intervals of one day or less, and
choose one of the following:
– at—Specifies the hour in which each daily export occurs
– every—Specifies the number of hours for the interval (1, 2, 3, 4,
6, 8, 12, 24)
•
Choose every week on to export using intervals of one or more times
a week, choose the days of the week, and what time each day.
FTP Export Server
IP address or hostname of the FTP server.
Name
Name of the user.
Password
Password for the user.
Confirm Password
Confirms the password for the user.
Directory
Name of the directory used to store the transaction logs on the FTP server.
SFTP
Check the SFTP check box, if you are using an SFTP server.
Windows Media Settings
Enable Windows Media
Settings
Enables Windows Media transaction logging.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-33
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-15
Transaction Log Settings Fields (continued)
Field
Description
Log File Format
Sets Windows Media Streaming Engine to generate transaction logs in the
following formats:
•
•
extended
wms-41
extended
wms-90
Uses the standard Windows Media Services 4.1 format
to generate the transaction log and includes the
following three additional fields in the transaction log:
•
SE_action (cache hit or cache miss)
•
SE-bytes (number of bytes sent from the SE for a
cache hit)
•
username (username of the Windows Media request
when NTLM, Negotiate, Digest, or basic
authentication is used)
Uses the standard Windows Media Services 9 format to
generate the transaction log and includes the following
three additional fields in the transaction log:
•
SE_action (cache hit or cache miss)
•
SE-bytes (number of bytes sent from the SE for a
cache hit)
•
username (username of the Windows Media request
when NTLM, Negotiate, Digest, or basic
authentication is used)
•
wms-41
Standard Windows Media Services 4.1 format
•
wms-90
Standard Windows Media Services 9 format
The default is wms-41. For more information, see the “Windows Media
Transaction Logging” section on page 7-64“Windows Media Transaction
Logging” section on page 7-65.
Web Engine Settings
Session Log
The Session Log drop-down list has the following options:
•
enable—Enables Session Log for this device, which consists of
per-session transaction logging (Per Session logs) and per-fragment
transaction logging (Web Engine custom format transaction logs).
•
enable exclusive—Enables Session Log only for per-session
transaction logging.
•
disable—Disables Session Log.
For more information, see the “Web Engine User Level Session
Transaction Logs” section on page 7-89.“Web Engine User Level Session
Transaction Logs” section on page 7-90
Splunk UF Export Settings
Export Enable
Enables the automatic export of the selected transaction logs to the
designated export server. For more information, see the “Real-Time
Exporting of Transaction Logs for Billing and Analytic Reports” section
on page 7-95“Real-Time Exporting of Transaction Logs for Billing and
Analytic Reports” section on page 7-96.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-34
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-15
Transaction Log Settings Fields (continued)
Step 3
Field
Description
Monitors
Check the check boxes of the type of transaction logs to export. The All
check box means all transaction logs are exported.
Export Server and Port
IP address and port number of the CDNM, CDN, or other export server
that is to receive the transaction log files. A maximum of three export
servers can be specified. The default port number is 9998.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
Application Control
The Application Control pages provide settings for bandwidth management of delivery services and
protocol engines. Configuring application control consists of the following procedures:
•
Configuring Default and Maximum Bandwidth
•
Configuring Bandwidth Schedules
•
Configuring Windows Media Streaming—General Settings
•
Configuring Windows Media Streaming—Bypass List
•
Configuring Movie Streamer—General Settings
•
Configuring RTSP Advanced Settings
•
Configuring Flash Media Streaming—General Settings
•
Configuring Flash Media Streaming—FMS Administrator
•
Configuring Flash Media Streaming—Service Monitoring
•
Configuring Flash Media Streaming—Service Monitoring
•
Configuring Web Engine HTTP Cache Freshness
Configuring Default and Maximum Bandwidth
Configuring Default and Maximum Bandwidth
The bandwidth used for delivering content is determined by the settings in the Default and Maximum
Bandwidth page, and the Scheduled Bandwidth page. The default settings are used unless a scheduled
bandwidth is configured for a specified time period. For Flash Media Streaming bandwidth limits, see
the “Configuring Flash Media Streaming—General Settings” section on page 4-45“Configuring Flash
Media Streaming—General Settings” section on page 4-45 and the “Configuring Flash Media
Streaming—Service Monitoring” section on page 4-46.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-35
Chapter 4
Configuring Devices
Configuring the Service Engine
Note
The bandwidth used for delivering content is always the minimum bandwidth configured of the
following configurations: default bandwidth, maximum bandwidth, and scheduled bandwidth. When the
bandwidth limit is reached, new client requests are dropped and a syslog entry is written. The client
receives an error message “453: Not enough bandwidth.”
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the default and maximum bandwidth settings, do the following:
Step 1
Choose Devices > Devices > Application Control > Default and Maximum Bandwidth. The Default
and Maximum Bandwidth page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-16 for a description of the fields.
Table 4-16
Field
Application Control Default and Maximum Bandwidth Fields
Description
Windows Media Default
Default bandwidth allowed for incoming Windows Media traffic from
Incoming
Bandwidth client devices.
Maximum Maximum bandwidth permitted by system license. The maximum
Bandwidth bandwidth for concurrent Windows Media streams enforces the
aggregate bandwidth of all concurrent Windows Media streaming
sessions, which includes RTSP-using-UDP, RTSP-using-TCP,
MMS-over-HTTP, and live stream splitting.
The default is 200 Mbps.1
Windows Media Default
Default bandwidth allowed for outgoing Windows Media traffic from
Outgoing
Bandwidth the SE.
Maximum Maximum bandwidth permitted by system license. The maximum
Bandwidth bandwidth for concurrent Windows Media streams enforces the
aggregate bandwidth of all concurrent Windows Media streaming
sessions, which includes RTSP-using-UDP, RTSP-using-TCP,
MMS-over-HTTP, and live stream splitting.
The default is 200 Mbps.1
Movie Streamer Default
Default bandwidth allowed for incoming Movie Streamer traffic from
Incoming
Bandwidth client devices.
Maximum Maximum bandwidth permitted by system license. The maximum
Bandwidth bandwidth for concurrent Movie Streamer streams enforces the
aggregate bandwidth of all concurrent Movie Streamer sessions.
The default is 200 Mbps.1
Movie Streamer Default
Default bandwidth allowed for outgoing Movie Streamer traffic from
Outgoing
Bandwidth the SE.
Maximum Maximum bandwidth permitted by system license. The maximum
Bandwidth bandwidth for concurrent Movie Streamer streams enforces the
aggregate bandwidth of all concurrent Movie Streamer sessions.
The default is 200 Mbps.1
1. The maximum allowed is 8 Gbps on a CDE220-2G2, 12 Gbps on a CDE220-2S3i, and 44 Gbps on a CDE250.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-36
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Bandwidth Schedules
Configuring Bandwidth Schedules
Bandwidth Schedule settings take precedence over Default Bandwidth settings.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure a Bandwidth Schedule, do the following:
Step 1
Choose Devices > Devices > Application Control > Bandwidth Schedules. The Application Control
Bandwidth Schedule Table page is displayed.
The table is sortable by clicking the column headings.
For information about Aggregate Settings, see the “Aggregate Settings” section on page 4-8“Aggregate
Settings” section on page 4-8.
Step 2
Click Create New in the task bar. The Scheduled Bandwidth page is displayed.
To edit a bandwidth schedule, click the Edit icon next to the scheduled bandwidth you want to edit.
Step 3
Enter the settings as appropriate. See Table 4-17 for a description of the fields.
Table 4-17
Application Control Bandwidth Schedule Fields
Field
Description
Bandwidth Type
Windows Media Incoming—Incoming Windows Media streaming content
requests from end users.
Windows Media Outgoing—Outgoing Windows Media content from SEs.
Movie Streamer Incoming—Incoming Movie Streamer content requests from
SEs or origin servers.
Movie Streamer Outgoing—Outgoing Movie Streamer content in response to
RTSP requests from end users.
Bandwidth Rate
Maximum amount of bandwidth you want to allow (in kilobits per second).
Start Time
Time of day for the bandwidth rate setting to start, using a 24-hour clock in local
time (hh:mm).
End Time
Time of day for the bandwidth rate setting to end (hh:mm).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-37
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-17
Application Control Bandwidth Schedule Fields (continued)
Field
Description
Use Specific Days
Days of the week on which configured bandwidth settings apply.
Specific Day Range
Step 4
•
Full Week—Bandwidth settings are applied to the entire week.
•
Sun, Mon, Tue, Wed, Thu, Fri, and Sat—Specific days of the week on which
configured bandwidth settings apply.
Range of days of the week on which configured bandwidth settings apply.
•
Start day—Day of the week to start for allowable bandwidth.
•
End day—Day of the week to end for allowable bandwidth.
Click Submit to save the settings.
To delete a bandwidth schedule, click the Edit icon for the group, then click the Delete icon in the task
bar.
Bandwidth Graph
Bandwidth Graph
To view a graphical representation of the bandwidth settings, click the Display Graph icon in the task
bar. The Application Bandwidth graph is displayed in a new window.
The vertical axis of the graph represents the amount of bandwidth in kilobits per second (kb/s) , and the
horizontal axis represents the days of the week. The units shown on the vertical axis are determined
dynamically based on the bandwidth rate for a particular bandwidth type. The units shown on the
horizontal axis represent 24 hours per each day of the week. Each type of bandwidth is represented by a
different color. A legend at the bottom of the graph maps colors to the corresponding bandwidth type.
To view the graph by bandwidth type, detailed or composite view, or days of the week, click a view
option in the text at the top of the window. Table 4-18 describes the view options.
Table 4-18
Viewing Options for Content Services Bandwidth Graph
Option
Description
Windows Media In
Displays the bandwidth settings for incoming Windows Media traffic.
Windows Media Out
Displays the bandwidth settings for outgoing Windows Media traffic.
Movie Streamer In
Displays the bandwidth settings for incoming Movie Streamer traffic.
Movie Streamer Out
Displays the bandwidth settings for outgoing Movie Streamer traffic.
All Servers
Displays a consolidated view of all configured bandwidth types. This is the
default view and is combined with the Full Week view.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-38
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-18
Viewing Options for Content Services Bandwidth Graph (continued)
Option
Description
Show Detailed
Bandwidth/Show
Effective Bandwidth
Toggles between the two options:
Show Detailed Bandwidth—Displays detailed bandwidth settings for
the SE and its associated device groups. The bandwidth settings of the
device and device groups are shown in different colors for easy
identification.
Show Effective Bandwidth—Displays the composite (aggregate)
bandwidth settings for the SE and its associated device groups.
Show Aggregate
View/Show
Non-Aggregate View
Toggles between the two options:
Show Aggregate View—Displays the bandwidth settings configured
for the corresponding device groups.
Show Non-Aggregate View—Displays the bandwidth settings
configured for the SE.
Sun, Mon, Tues, Wed,
Thurs, Fri, Sat
Displays the bandwidth settings for the corresponding day of the week.
Full Week
Displays the bandwidth settings for the entire week. This is the default
view and is combined with the All Servers view.
Configuring Windows Media Streaming—General Settings
Configuring Windows Media Streaming—General Settings
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the General Settings for Windows Media Streaming, do the following:
Step 1
Choose Devices > Devices > Application Control > Windows Media Streaming > General Settings.
The Windows Media Streaming General Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-19 for a description of the fields.
Table 4-19
Windows Media Streaming General Settings Fields
Field
Description
Enable Windows Media Services When checked, Windows Media Services is enabled. To disable
services, uncheck the check box.
Windows Media Proxy Settings
Enable Outgoing HTTP Proxy
When enabled, allows an outgoing HTTP proxy server for
streaming media in MMS format (MMS-over-HTTP). The
Outgoing Proxy feature only works on the Content Acquirer in a
delivery service.
Outgoing HTTP Proxy Host
Name and Port
Hostname, or IP address, and port of the outgoing HTTP proxy.
Valid port numbers range from 1 to 65535.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-39
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-19
Windows Media Streaming General Settings Fields (continued)
Field
Description
Enable Outgoing RTSP Proxy
When enabled, allows an outgoing RTSP proxy server for streaming
media using RTSP. The Outgoing Proxy feature only works on the
Content Acquirer in a delivery service.
Outgoing RTSP Proxy Host
Name and Port
Hostname, or IP address, and port of the outgoing RTSP proxy.
Valid port numbers range from 1 to 65535.
Enable Accelerate Proxy Cache
Performance
When enabled, caching performance improvements are applied to
the Windows Media proxy.
Windows Media General Settings
Disable HTTP Windows Media
Traffic
To disallow streaming over HTTP, check the check box.
Disable RTSPT WMT Traffic
To disallow streaming over RTSPT (RTSP using TCP), check the
check box.
Disable RTSPU WMT Traffic
To disallow streaming over RTSPU (RTSP using UDP), check the
check box.
Maximum Concurrent
Connections: Override Default
and Custom Value
To override the default maximum number of concurrent sessions,
check the check box and enter a value in the Custom Value field.
The default is 200 sessions. The range is from 1 to 40000.
Enforce Maximum Outgoing
Bitrate
Enforces the maximum stream bit rate for serving content when
checked.
Maximum Outgoing Bitrate
The maximum streaming bit rate that can be served in kilobits per
second (kbps). The range is from 1 to 2,147,483,647. The default is
0, which means no bitrate limit.
Enforce Maximum Incoming
Bitrate
Enforces the maximum incoming bit rate for receiving content
when checked.
Maximum Incoming Bitrate
The maximum streaming bit rate (kbps) that can be received. The
range is from 1 to 2,147,483,647. The default is 0, which means no
bitrate limit.
Enable Accelerate Live-Split
Performance
Enables performance improvements in live splitting for the
Windows Media proxy.
Enable Accelerate VOD
Performance
Enables performance improvements in Video On Demand for the
Windows Media proxy.
Restrict HTTP Allowed
Extensions
Allows you to add or remove permitted extensions.
HTTP Allowed Extensions
List of allowable extensions for HTTP.
You can add or delete filename extensions from this list with the
following restrictions:
•
Each extension must be alphanumeric, with the first character
in the extension being an alphabetic character.
•
You cannot have more than 10 characters in a filename
extension.
•
You cannot add more than 6filename extensions to the allowed
list.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-40
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-19
Windows Media Streaming General Settings Fields (continued)
Field
Description
Enable Fast Start Feature
Enables Fast Start for MMS-over-HTTP or RTSP.
Fast Start Max Bandwidth
Maximum bandwidth (kbps) allowed per Windows Media Player
when Fast Start is used to serve packets to this player. The default
is 3500. The range is from 1 to 65535.
Enable Fast Cache
Enables Fast Cache for MMS-over-HTTP or RTSP.
Fast Cache Max Delivery Rate
Maximum delivery rate (kbps) allowed per Windows Media Player
when Fast Cache is used to deliver packets to this player. The
default is 5. The range is from 1 to 65535.
Windows Media Multicast Settings
Number of hops to live
Number of hops to live for multicast Windows Media packets. The
default is 5. The range is from 0 to 255.
Windows Media Advanced Client Settings
Idle Timeout
Number of seconds to timeout when the client connection is idle.
The default is 60 The range is from 30 to 300.
Maximum Data Packet Size
Maximum packet size (in bytes) allowed. The default is 1500. The
range is from 576 to 16,000.
Windows Media Advanced Server Settings
Enable Log Forwarding
Enables log forwarding to an upstream SE or Windows Media
server.
Inactive Timeout
Number of seconds to timeout when the upstream SE or Windows
Media server connection is idle. The default is 65535. The range is
from 60 to 65535.
Windows Media Cache Settings
Enable
When checked, Windows Media cache settings are enabled.
Max Object Size
The maximum content object size (in megabytes) the SE can cache.
The default is 25600. The range is from 1 to 1000000.
Age Multiplier
The age multiplier value (as a percentage) enables the SE to
estimate the life of an object by multiplying the time since the
object was last modified by a percentage to obtain an approximate
expiration date. After this date, the object is considered stale, and
subsequent results cause a fresh retrieval by the SE. The default
value is 30. The range is from 0 to 100.
Maximum TTL
The maximum time-to-live for objects in the cache. The value
ranges are the following:
1 to 157680000 seconds
1 to 2628000 minutes
1 to 43800 hours
1 to 1825 days
The default is 1 day.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-41
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-19
Step 3
Windows Media Streaming General Settings Fields (continued)
Field
Description
Minimum TTL
The minimum time-to-live (in minutes) for objects in the cache. The
default is 60. The range is from 0 to 86400.
Enable Re-evaluate Request
When checked, the cache is validated with the origin server instead
of validating the cache using heuristics. When Enable Re-evaluate
Request is checked, the cached content freshness is revalidated
every time the content is requested, which limits the effectiveness
of the other cache settings and increases the time to start streaming
the content.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Windows Media Streaming—Bypass List
Configuring Windows Media Streaming—Bypass List
Incoming bandwidth refers to the bandwidth between a local SE and the origin server. When the SE is
configured for Windows Media proxy services, incoming bandwidth usage for Video On Demand (VOD)
content is unpredictable. This unpredictability is because the consumption of incoming bandwidth for
VOD content can be triggered arbitrarily by an end user requesting the content. If the VOD content is
not found in the SE cache, a cache miss occurs, and the Windows Media proxy must fetch the content
from the origin server. The SE administrator cannot predict the incoming bandwidth usage for such
events, so a large number of cache-miss VOD requests can consume all of the incoming bandwidth.
The Windows Media incoming bandwidth bypass configuration allows the administrator to configure a
list of hosts that bypasses the incoming bandwidth limitation.
To configure the list of hosts for bypassing incoming bandwidth limits, do the following:
Step 1
Choose Devices > Devices > Application Control > Windows Media Streaming > Bypass List. The
Bypass List page is displayed.
Step 2
In the Windows Media BW Incoming Bypass List field, enter up to four IP addresses or hostnames of
hosts you want to bypass the incoming bandwidth check. Separate each entry with a space.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-42
Chapter 4
Configuring Devices
Configuring the Service Engine
Configuring Movie Streamer—General Settings
Configuring Movie Streamer—General Settings
The Movie Streamer is an open-source, standards-based, streaming server that delivers hinted MPEG-4,
hinted 3GPP, and hinted MOV files to clients over the Internet and mobile networks using the
industry-standard RTP and RTSP.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the general settings for Movie Streamer, do the following:
Step 1
Choose Devices > Devices > Application Control > Movie Streamer > General Settings. The Movie
Streamer General Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-20 for a description of the fields.
Table 4-20
Movie Streamer General Settings Fields
Field
Description
Enable Movie Streamer Services When checked, Movie Streamer Services is enabled. To disable
services, uncheck the check box.
Movie Streamer Proxy Settings
Host Name
Hostname or IP address of the proxy server for Movie Streamer.
Port
Port of the proxy server for Movie Streamer. Valid port numbers
range from 1 to 65535. The default is 554.
Movie Streamer General Settings
Maximum Concurrent
Connections: Override Default
and Custom Value
To override the default maximum number of concurrent sessions,
check the check box and enter a value in the Custom Value field.
Enforce Maximum Outgoing
Bitrate
Enforces the maximum stream bit rate for serving content when
checked.
Maximum Outgoing Bitrate
The maximum streaming bit rate that can be served in kilobytes per
second (Kbps). The range is from 1 to 2147483647, depending on
the hardware model.
Enforce Maximum Incoming
Bitrate
Enforces the maximum incoming bit rate for receiving content
when checked.
Maximum Incoming Bitrate
The maximum streaming bit rate (Kbps) that can be received. The
range is from 1 to 2147483647, depending on the hardware model.
Enable Accelerate VOD
Performance
Enables performance improvements in Video On Demand for the
Movie Streamer proxy.
The default is 200 sessions. The range is from 1 to 40,000.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-43
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-20
Movie Streamer General Settings Fields (continued)
Field
Description
Movie Streamer Advanced Client Settings
Idle Timeout
RTP Timeout
The Idle Timeout field and the RTP Timeout field, are only
intended for performance testing when using certain testing tools
that do not have full support of the RTCP receiver report. Setting
these timeouts to high values causes inefficient tear-down of client
connections when the streaming sessions have ended.
The Idle Timeout field has a range from 0 to 300, whereas the RTP
Timeout field has a range from 30-180. This is by design.
For typical deployments, it is preferable to leave these parameters
set to their defaults. The default is 300 for the Idle Timeout field
and 180 for the RTP Timeout field.
Movie Streamer Cache Settings
Step 3
Enable
When checked, Movie Streamer caches content on the SE and the
cache settings are enabled.
Age Multiplier
The age multiplier value (as a percentage) enables the SE to
estimate the life of an object by multiplying the time since the
object was last modified by a percentage to obtain an approximate
expiration date. After this date, the object is considered stale, and
subsequent results cause a fresh retrieval by the SE. The default
value is 30. The range is from 0 to 100.
Maximum TTL
The maximum time-to-live for objects in the cache. The value
ranges are the following:
1 to 157680000 seconds
1 to 2628000 minutes
1 to 43800 hours
1 to 1825 days
The default is 1 day.
Enable Re-evaluate Request
When checked, the cache is validated with the origin server instead
of validating the cache using heuristics.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-44
Chapter 4
Configuring Devices
Configuring the Service Engine
Configuring RTSP Advanced Settings
Configuring RTSP Advanced Settings
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure RTSP advanced settings for Movie Streamer and Windows Media Streaming, do the
following:
Step 1
Choose Devices > Devices > Application Control > RTSP Advanced Settings. The RTSP Advanced
Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-21 for a description of the fields.
Table 4-21
Step 3
RTSP Advanced Settings Fields
Field
Description
Maximum Initial
Setup Delay
Maximum delay allowed (in seconds) between TCP accept and the first RTSP
message from the client. The default is 10 seconds.
Maximum Request
Rate
Maximum number of incoming requests per second that the RTSP gateway
allows. The default is 40 requests per second.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Flash Media Streaming—General Settings
Configuring Flash Media Streaming—General Settings
The Flash Media Streaming engine delivers Adobe Flash applications and video files, as well as MP3
audio files using HTTP and an Adobe proprietary protocol, RTMP. For more information, see the “Flash
Media Streaming Engine” section on page 1-26.
Note
Flash Media Streaming uses port 1935 for RTMP and RTMPE streaming. Flash Media Streaming also
supports RTMPT and RTMPTE over port 80.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable Flash Media Streaming, do the following:
Step 1
Choose Devices > Devices > Application Control > Flash Media Streaming > General Settings. The
Flash Media Streaming General Settings page is displayed.
Step 2
Check the Enable Flash Media Streaming check box.
Step 3
Enter the settings as appropriate. See Table 4-22 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-45
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-22
Step 4
Flash Media Streaming Fields
Field
Description
Restricted Maximum
Bandwidth
Maximum bandwidth allowed for Flash Media Streaming. The range is from
1000 to 8000000 Kbps. The default is 200000.
Restricted Maximum
Sessions
Maximum concurrent sessions the Flash Media Streaming engine supports.
The range is from 1 to 15000. The default is 200.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Flash Media Streaming—FMS Administrator
Configuring Flash Media Streaming—FMS Administrator
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable servers to send Flash Media Server (FMS) Administration API calls to this device, do the
following:
Step 1
Choose Devices > Devices > Application Control > Flash Media Streaming > FMS Admin Allow
Hosts. The FMS Admin Allow Hosts page is displayed.
Step 2
Check the Enable check box.
Step 3
In the FMS Admin Allow Hosts field, enter the IP addresses (space delimited) of the servers that are
allowed to send Flash Media Server Administration API calls to this device.
The Adobe Flash Media Server Administration APIs and the Administration Console that was built using
the Administration APIs are supported. These APIs can be used to monitor and manage the Adobe Flash
Media Server running on a Cisco CDS Service Engine.
Step 4
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Flash Media Streaming—Service Monitoring
Configuring Flash Media Streaming—Service Monitoring
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable Flash Media Streaming Service Monitoring, do the following:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-46
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 1
Choose Devices > Devices > Application Control > Flash Media Streaming > Service Monitoring.
The Service Monitoring page is displayed.
Step 2
Check the Enable Service Monitoring check box.
Service Monitoring monitors the Flash Media Streaming engine memory usage. If the memory usage
reaches the 1.5 GB limit for either the Flash Media Streaming core process or the Flash Media Streaming
edge process, an alarm is raised and the Service Router does not redirect any new Flash Media Streaming
requests to this SE.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Web Engine HTTP Cache Freshness
Configuring Web Engine HTTP Cache Freshness
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the web engine HTTP cache freshness, do the following:
Step 1
Choose Devices > Devices > Application Control > Web > HTTP > HTTP Cache Freshness. The
HTTP Cache Freshness page is displayed (Figure 4-13).
Figure 4-13
Step 2
HTTP Cache Freshness Page
Enter the settings as appropriate. See Table 4-23 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-47
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-23
HTTP Cache Freshness Fields
Field
Description
Enable
When checked, HTTP cache freshness is enabled.
Object Age Multiplier The age multiplier value (as a percentage) enables the SE to guess the life
of an object by multiplying the time since the object was last modified by a
percentage to obtain an approximate expiration date. After this date, the
object is considered stale, and subsequent results cause a fresh retrieval by
the SE. The range is from 0 to 100. The default value is 30.
Max TTL Scale
The scale (seconds, hours, minutes, or days) to use for the Max Object TTL.
The time-to-live (TTL) sets a ceiling on estimated expiration dates. If an
object has an explicit expiration date, this takes precedence over the
configured TTL. The default is days.
Max Object TTL
The maximum time-to-live (TTL) for objects in cache. The ranges are as
follows:
1 to 1825 days
1 to 43800 hours
1 to 2628000 minutes
1 to 157680000 seconds
The default is 61 day.
Minimum TTL
Step 3
The minimum time-to-live (in minutes) for objects in the cache. The range
is from 0 to 86400. The default value is 60.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
General Settings
The General Settings pages provide settings for access control of the device, maintenance, network
connectivity, and monitoring. The configuring of general settings consists of the following procedures:
•
Configuring Content Management
•
Login Access Control
•
Authentication
•
Scheduling Database Maintenance
•
Setting Storage Handling
•
Network Settings
•
Configuring Notification and Tracking
•
Configuring Troubleshooting
•
Configuring Service Router Settings
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-48
Chapter 4
Configuring Devices
Configuring the Service Engine
Configuring Content Management
Configuring Content Management
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the maximum number of entries for cache content, do the following:
Step 1
Choose Devices > Devices > General Settings > Content Management. The Content Management
page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-24 for a description of the fields.
Table 4-24
Content Management Fields
Field
Description
Max Cache Content
Entries
Enter the value for the maximum entries of cached content allowed. The range
is from 1 to 20,000,000. The default is 20,000,000.
Cache content eviction By default, Content Manager prefers to keep small content objects over large
preferred size
content objects, because the overhead of fetching a small object is higher than
larger objects.
The Cache content eviction preferred size default is large, which means the
large size files are evicted before small files.
Enable Eviction
Protection
Check the Enable Eviction Protection check box to enable eviction
protection.
For more information, see the “Eviction Protection” section on page 1-11.
Minimum cache entry
size to protect
From the Minimum cache entry size to protect drop-down list, select the
minimum cache entry size (100 MB, 500 MB, 1 GB, and 4 GB) to protect from
deletion.
Minimum duration to
protect the content
from eviction
From the Minimum duration to protect the content from eviction
drop-down list, select the age (1–4 hours for 100 MB size, 1, 4, 8, or 24 hours
for all other sizes) of the content object to be protected from deletion.
Hit Count Decay Half
Life
Enter the half-life decay period (in days) at which to decay hit-count by half.
The range is 1 to 30. The default is 14 days.
The decay mechanism reduces the hit count by half and is applied for the
content object every two weeks by default.
Threshold of Disk
Failures Per Bucket
Enter the threshold, as a percentage, for disk failures in a bucket. The disks in
each bucket are monitored, and if the threshold is exceeded, a minor alarm is
raised. The default is 30. The range is 1 to 100.
For more information, see the “Bucket Allocation” section on page 1-7.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-49
Chapter 4
Configuring Devices
Configuring the Service Engine
Login Access Control
Login Access Control
Login authentication and authorization are used to control user access and configuration rights to
CDSMs, SEs, and SRs. Login authentication is the process by which the devices verify whether the
person who is attempting to log in to the device has a valid username and password. The person logging
in must have a user account registered with the device. User account information serves to authorize the
user for login and configuration privileges. The user account information is stored in an authentication,
authorization, and accounting (AAA) database, and the devices must be configured to access the
particular authentication server (or servers) where the AAA database is kept.
In a CDS network, user accounts can be created for access to the CDSM and, independently, for access
to the SEs and SRs that are registered to the CDSM. For user accounts that access the CDSM, see the
“Configuring AAA” section on page 6-1.
Login Authentication
Login Authentication
Login authentication provides the configuration for independent logins; in other words, login access to
the device only.
Login authentication can also be used to log in to the CDSM GUI. When logging in to the CDSM GUI
with an external user account (RADIUS or TACACS+), the user is authenticated by the external
database. After the external user is authenticated, its role depends on the privilege configured in the
external database (zero [0] means a normal user and 15 means a super user). The privilege level of 0 or
15 is mapped to the read-only or admin user role in the CDSM GUI. No CDSM local user is created in
the CDSM database for the external user that logs in, so the external user cannot be managed by the
CDSM GUI.
Note
If you plan to use a RADIUS server or a TACACS+ server for authentication, you must configure the
server settings before you configure and submit these settings. See the “Configuring RADlUS Server
Settings” section on page 4-58 and the “Configuring TACACS+ Server Settings” section on page 4-59
for more information.
When the primary login server and the primary enable server are set to local, usernames and passwords
are local to each device. Local authentication and authorization uses locally configured login and
passwords to authenticate login attempts.
Note
If the Enable Failover Server Unreachable option is enabled, it applies to both the login authorization
methods and the exec authentication methods.
If you are going to use different servers for login authentication and enable authentication (for example,
local for login authentication and RADIUS for the enable authentication), then the username and
password must be the same for both servers.
By default, local login authentication is enabled. You can disable local login authentication only after
enabling one or more of the other login authentication servers. However, when local login authentication
is disabled, if you disable all other login authentication methods, a warning message is displayed stating
“At least one authentication method is required to select for login.”
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-50
Chapter 4
Configuring Devices
Configuring the Service Engine
Caution
Make sure that RADIUS or TACACS+ authentication is configured and operating correctly before
disabling local authentication and authorization. If you disable local authentication and RADIUS or
TACACS+ is not configured correctly, or if the RADIUS or TACACS+ server is not online, you may be
unable to log in to the device.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the login authentication and enable authentication schemes for the device, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > Login Authentication. The
Login Authentication page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-25 for a description of the fields.
Table 4-25
Login Authentication Fields
Field
Description
Login Authentication Settings
Enable Failover Server If Enable Failover Server Unreachable is enabled, the following applies:
Unreachable
• Only two login authentication schemes (a primary and secondary scheme)
are allowed on the device.
•
Device fails over from the primary authentication scheme to the
secondary authentication scheme only if all specified authentication
servers of the primary authentication scheme are unreachable.
Conversely, if the Enable Failover Server Unreachable option is disabled,
the device contacts the secondary authentication database, regardless of the
reason the authentication failed with the primary authentication database.
Note
Authentication Login
Servers
To use this option, you must set TACACS+ or RADIUS as the primary
authentication method and local as the secondary authentication
method.
When enabled, login authentication servers are used to authenticate user
logins and whether the user has access permissions to the device.
Check this option and set one or more Login servers for login authentication.
By unchecking this option, local authentication is used by default. Three
servers can be configured.
Note
If local is selected for any of the Login servers, the password in the
username is used to authenticate the user. See the “Creating, Editing,
and Deleting Users—Usernames” section on page 4-57“Creating,
Editing, and Deleting Users—Usernames” section on page 4-57.
Primary Login Server
Choose local, RADIUS, or TACACS+.
Secondary Login
Server
Choose local, RADIUS, or TACACS+.
Tertiary Login Server
Choose local, RADIUS, or TACACS+.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-51
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-25
Login Authentication Fields (continued)
Field
Description
Enable Authentication Settings
Primary Enable Server The enable server is used to allow normal users to enter the privileged EXEC
mode.Choose local, RADIUS, or TACACS+.
Secondary Enable
Server
Choose local, RADIUS, or TACACS+.
Tertiary Enable Server Choose local, RADIUS, or TACACS+.
Local Enable
Password
Set the local enable password for normal users to log in to the Enable server
and have privileged EXEC mode.
If multiple authorization methods are configured, the SE tries to authenticate
the enable password by way of each configured method until one of them is
successful.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Exec Authorization
Exec Authorization
Exec authorization provides the configuration for determining the services allowed for each user that
logs in to the device.
Exec authorization can also be used to determine the services the user has for the CDSM GUI. When
logging in to the CDSM GUI with an external user account (RADIUS or TACACS+), the user is
authenticated by the external database. After the external user is authenticated, its role depends on the
privilege configured in the external database (zero [0] means a normal user and 15 means a super user).
The privilege level of 0 or 15 is mapped to the read-only or admin user role in the CDSM GUI. No CDSM
local user is created in the CDSM database for the external user that logs in, so the external user cannot
be managed by the CDSM GUI.
Note
If you plan to use a TACACS+ server for authorization, you must configure the server settings before
you configure and submit these settings. See the “Configuring RADlUS Server Settings” section on
page 4-58 and the “Configuring TACACS+ Server Settings” section on page 4-59 for more information.
When the primary authorization server is set to local, usernames and passwords are local to each device.
Local authorization uses locally configured login and passwords to authorize services for the user.
Note
If the Enable Failover Server Unreachable option is enabled, it applies to both the login authorization
methods and the exec authentication methods.
If you are going to use different servers for login authentication and enable authentication (for example,
local for login authentication and RADIUS for the enable authentication), then the username and
password must be the same for both servers.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-52
Chapter 4
Configuring Devices
Configuring the Service Engine
Caution
Make sure that RADIUS or TACACS+ authentication is configured and operating correctly before
disabling local authentication and authorization. If you disable local authentication and RADIUS or
TACACS+ is not configured correctly, or if the RADIUS or TACACS+ server is not online, you may be
unable to log in to the device.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the exec authorization schemes for the device, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > Exec Authorization. The
Exec Authorization page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-26 for a description of the fields.
Table 4-26
Exec Authorization Fields
Field
Description
Authorization Exec
Servers
When enabled, authorization exec servers are used to authorize services for
logged in users.
Check this option and set one or more servers for exec authorization. By
unchecking this option, local authentication is used by default. Three servers
can be configured.
Note
Primary Exec Server
If a user encounters failure during EXEC shell) startup authorization,
the user fails to log in to the SE even if the user passed the login
authentication.
Choose local, RADIUS, or TACACS+.
Secondary Exec Server Choose local, RADIUS, or TACACS+.
Tertiary Exec Server
Choose local, RADIUS, or TACACS+.
Primary Enable Server
The enable server determines if the normal user can enter the privileged
EXEC mode. Choose local, RADIUS, or TACACS+.
Normal User
Commands
Choose Enable or Enable if Authenticated.
Super User Commands
Choose Enable or Enable if Authenticated.
The Enable if Authenticated option turns off authorization on the
TACACS+ server and authorization is granted to any Normal user who is
authenticated.
The Enable if Authenticated option turns off authorization on the
TACACS+ server and authorization is granted to any Super user who is
authenticated.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-53
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-26
Exec Authorization Fields (continued)
Field
Description
Enable Config
Commands
Check the Enable Config Commands check box to enable authorization of
the configuration mode commands.
By default, this option is disabled, which means all configuration commands
issued are allowed.
Enable Console Config Check the Enable Console Commands check box to enable authorization of
all commands issued on a console TTY connection.
By default, this option is disabled, which means commands issued through a
console TTY connection always succeed.
Note
Step 3
The following commands bypass authorization and accounting: CTRL+C, CTRL+Z, exit, end,
and all of configuration commands for entering submode (for example, interface
GigabitEthernet 1/0).
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring SSH
Configuring SSH
Secure Shell (SSH) consists of a server and a client program. Like Telnet, you can use the client program
to remotely log in to a machine that is running the SSH server. However, unlike Telnet, messages
transported between the client and the server are encrypted. The functionality of SSH includes user
authentication, message encryption, and message authentication.
The SSH page allows you to specify the key length and login grace time.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable the SSH daemon, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > SSH. The SSH page is
displayed.
Step 2
Check Enable to enable the SSH feature. SSH enables login access to the device through a secure and
encrypted channel.
Step 3
In the Length of Key field, specify the number of bits needed to create an SSH key. The default is 2048.
Step 4
In the Login Grace Time field, specify the number of seconds the server waits for the user to
successfully log in before it ends the connection. The authentication procedure must be completed within
this time limit. The default is 300 seconds.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-54
Chapter 4
Configuring Devices
Configuring the Service Engine
Note
Step 5
Select the SSH version.
a.
To allow clients to connect using SSH protocol version 1, check the Enable SSHv1 check box.
b.
To allow clients to connect using SSH protocol version 2, check the Enable SSHv2 check box.
Note
Step 6
When changing the Login Grace Time, you need to first uncheck the Enable check box and
click Submit. Enter the new Login Grace Time, check Enable, and click Submit.
You can enable both SSHv1 and SSHv2, or you can enable one version and not the other. You
cannot disable both versions of SSH unless you disable the SSH feature by unchecking the
Enable check box.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Enabling Telnet
Enabling Telnet
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable the Telnet service, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > Telnet. The Telnet page is
displayed.
Step 2
Check Telnet Enable to enable the terminal emulation protocol for remote terminal connections.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Setting the Message of the Day
Setting the Message of the Day
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
The Message of the Day (MOTD) feature enables you to provide information bits to the users when they
log in to a device. There are three types of messages that you can set up:
•
MOTD banner
•
EXEC process creation banner
•
Login banner
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-55
Chapter 4
Configuring Devices
Configuring the Service Engine
To configure the Message of the Day settings, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > Message of the Day. The
MOTD page is displayed.
Step 2
Check Enable to enable the MOTD settings. The Message of the Day (MOTD) banner, EXEC process
creation banner, and Login banner fields become enabled.
Step 3
In the Message of the Day (MOTD) Banner field, enter a string that you want to display as the MOTD
banner when a user attempts to log in to the device.
Note
In the Message of the Day (MOTD) Banner, EXEC Process Creation Banner, and Login Banner
fields, you can enter a maximum of 980 characters. A new line character (or Enter) is counted
as two characters, as it is interpreted as \n by the system. You cannot use special characters such
as `, % ,^ , and " in the MOTD text.
Step 4
In the EXEC Process Creation Banner field, enter a string to be displayed as the EXEC process
creation banner when a user enters into the EXEC shell of the device.
Step 5
In the Login Banner field, enter a string to be displayed after the MOTD banner when a user attempts
to log in to the device.
Step 6
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Changing the CLI Session Time
Changing the CLI Session Time
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To change the CLI session time, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > CLI Session Time. The CLI
Session Time page is displayed.
Step 2
In the CLI Session Time field, enter the time (in minutes) that the device waits for a response before
ending the session.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-56
Chapter 4
Configuring Devices
Configuring the Service Engine
Changing Users—Admin Password
Changing Users—Admin Password
Every device (CDSM, SE, and SR) has a built-in user account. The username is admin and the default
password is default. This account allows access to all services and entities in the CDS. Any user that can
access the Admin Password page in the CDSM can configure a new password for the administrator user
account on individual SEs and SRs.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To change the Admin password, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > Users > Admin Password.
The Admin Password page is displayed.
Step 2
In the Password field, enter a new password.
The following characters are not allowed: ?./;[]{}"@=|
Step 3
In the Confirm Password field, re-enter the password.
Step 4
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Creating, Editing, and Deleting Users—Usernames
Creating, Editing, and Deleting Users—Usernames
You can create, edit, and delete user accounts for login access to individual devices or device groups. A
privilege profile must be assigned to each new user account. The Usernames page uses privilege profiles
to determine which tasks a user can perform and the level of access provided. Users with administrative
privileges can add, delete, or modify user accounts through the CDSM or the device CLI.
To create, edit, or delete a user account, do the following:
Step 1
Choose Devices > Devices > General Settings > Login Access Control > Users > Usernames. The
User Table page is displayed.
The table is sortable by clicking the column headings.
For information about Aggregate Settings, see the “Aggregate Settings” section on page 4-8“Aggregate
Settings” section on page 4-8.
Step 2
Click the Create New icon in the task bar. The Local User page is displayed.
To edit a local user, click the Edit icon next to the name you want to edit.
Step 3
Enter the settings as appropriate. See Table 4-27 for a description of the fields.
Table 4-27
Local User Fields
Field
Description
Username
Name of user.
Password
User password.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-57
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-27
Step 4
Local User Fields (continued)
Field
Description
Confirm Password
Re-enter user password.
Privilege
There are two types of predefined privilege profiles:
•
Normal user—User has read access and can see some of the SE, SR, or
CDSM settings.
•
Superuser—User has administrative privileges such as creating new
users and modifying the SE, SR, or CDSM settings.
Click Submit to save the settings.
To delete a user, click the Edit icon for the user, then click the Delete icon in the task bar.
Authentication
Authentication
User authentication and authorization (configuration rights) data can be maintained in any combination
of these three databases:
•
Local database (located on the device)
•
RADIUS server (external database)
•
TACACS+ server (external database)
The Login Authentication page allows you to choose an external access server or the internal (local)
device-based authentication, authorization, and accounting (AAA) system for user access management.
You can choose one method or a combination of the three methods. The default is to use the local
database for authentication.
Configuring RADlUS Server Settings
Configuring RADlUS Server Settings
Note
The CDSM does not cache user authentication information. Therefore, the user is reauthenticated against
the Remote Authentication Dial In User Service (RADIUS) server for every request. To prevent
performance degradation caused by many authentication requests, install the CDSM in the same location
as the RADIUS server, or as close as possible to it, to ensure that authentication requests can occur as
quickly as possible.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the RADIUS server settings, do the following:
Step 1
Choose Devices > Devices > General Settings > Authentication > RADIUS Server. The RADIUS
Server Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-28 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-58
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-28
Step 3
RADIUS Server Settings Fields
Field
Description
Enable Radius
Authentication
Enables RADIUS authentication.
Time to wait
Number of seconds to wait for a response before timing out on a connection to
a RADIUS server. The range is from 1 to 20. The default is 5.
Number of
retransmits
Number of attempts allowed to connect to a RADIUS server. The default is 2.
Enable redirect
Redirects an authentication response to a different authentication server if an
authentication request using the RADIUS server fails.
Redirect Message
[1-3]
Message sent to the user if redirection occurs.
Note
If the redirect message has a space, it must be in quotes (" ").
Location [1-3]
Sets an HTML page location. This is the URL destination of the redirect
message that is sent when authentication fails.
Shared Encryption
Key
Encryption key shared with the RADIUS server. The maximum number of
characters allowed is 15.
Server Name [1-5]
IP address or hostname of the RADIUS server.
Server Port [1-5]
Port number on which the RADIUS server is listening. The default is 1645.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
To use RADIUS for login authentication and authorization, see the “Login Authentication” section on
page 4-50“Login Authentication” section on page 4-50.
Configuring TACACS+ Server Settings
Configuring TACACS+ Server Settings
Note
The CDSM does not cache user authentication information. Therefore, the user is reauthenticated against
the Terminal Access Controller Access Control System Plus (TACACS+) server for every request. To
prevent performance degradation caused by many authentication requests, install the CDSM in the same
location as the TACACS+ server, or as close as possible to it, to ensure that authentication requests can
occur as quickly as possible.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the TACACS+ server settings, do the following:
Step 1
Choose Devices > Devices > General Settings > Authentication > TACACS+ Server. The TACACS+
Server Settings page is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-59
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 2
Enter the settings as appropriate. See Table 4-29 for a description of the fields.
Table 4-29
Field
Description
Enable TACACS+
Servers
Enables TACACS+ authentication.
Use ASCII
Password
Authentication
Changes the default password type from Password Authentication Protocol
(PAP) to ASCII clear text format.
Time to wait
Number of seconds to wait for a response before timing out on a connection to
a TACACS+ server. The range is from 1 to 20. The default is 5.
Number of
retransmits
Number of attempts allowed to connect to a TACACS+ server. The default is 2.
Security Word
Encryption key shared with the TACACS+ server. The range is from 1 to 99. An
empty string is the default.
Primary Server
IP address or hostname of the primary TACACS+ server.
Secondary Server
IP address or hostname of the backup TACACS+ server. Up to two backup
servers are allowed.
Tertiary Server
Step 3
TACACS+ Server Settings Fields
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
To use TACACS+ for login authentication and authorization, see the “Login Authentication” section on
page 4-50“Login Authentication” section on page 4-50.
Configuring AAA Accounting
Configuring AAA Accounting
Accounting tracks all user actions and when the action occurred. It can be used for an audit trail or for
billing for connection time or resources used (bytes transferred).
The CDS accounting feature uses TACACS+ server logging. Accounting information is sent to the
TACACS+ server only, not to the console or any other device. The syslog file on the SE logs accounting
events locally. The format of events stored in the syslog is different from the format of accounting
messages.
The TACACS+ protocol allows effective communication of AAA information between SEs and a central
TACACS+ server. It uses TCP for reliable connections between clients and servers. SEs send
authentication and authorization requests, as well as accounting information to the TACACS+ server.
Note
Before you can configure the AAA accounting settings for a device, you must first configure a
TACACS+ server for the device. See the “Configuring TACACS+ Server Settings” section on
page 4-59“Configuring TACACS+ Server Settings” section on page 4-59.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-60
Chapter 4
Configuring Devices
Configuring the Service Engine
Note
The CDSM does not cache user authentication information. Therefore, the user is reauthenticated against
the Terminal Access Controller Access Control System Plus (TACACS+) server for every request. To
prevent performance degradation caused by many authentication requests, install the CDSM in the same
location as the TACACS+ server, or as close as possible to it, to ensure that authentication requests can
occur as quickly as possible.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the AAA accounting settings, do the following:
Step 1
Choose Devices > Devices > General Settings > Authentication > AAA Accounting. The AAA
Accounting Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-29 for a description of the fields.
Table 4-30
AAA Accounting Settings Fields
Field
Description
System Events
Enables accounting records on the TACACS+ server about system events; such
as system reboot, interface up or down states, and accounting configuration
enabled or disabled.
From the System Events drop-down list choose start-stop or stop-only.
The start-stop option records events when they start and when they stop. The
stop-only option records events when they stop.
Exec Shell Events
Enables accounting records on the TACACS+ server about user EXEC terminal
sessions, including username, date, and start and stop times.
From the Exec Shell Events drop-down list choose start-stop or stop-only.
The start-stop option records events when they start and when they stop. The
stop-only option records events when they stop.
Normal User
Commands
Enables accounting records on the TACACS+ server for Normal users using
commands in the EXEC mode.
From the Normal User Commands drop-down list choose start-stop or
stop-only.
The start-stop option records events when they start and when they stop. The
stop-only option records events when they stop.
Super User
Commands
Enables accounting records on the TACACS+ server for Super users using
commands in the EXEC mode.
From the Super User Commands drop-down list choose start-stop or
stop-only.
The start-stop option records events when they start and when they stop. The
stop-only option records events when they stop.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-61
Chapter 4
Configuring Devices
Configuring the Service Engine
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring an Access Control List
Configuring an Access Control List
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure an access control list (ACL) for group authorization, do the following:
Step 1
Choose Devices > Devices > General Settings > Authentication > Access Control List > Configure
Access Control List. The Access Control List Table page is displayed.
The table is sortable by clicking the column headings.
Step 2
Click the Create New icon in the task bar. The Configure Access Control List page is displayed.
To edit a group, click the Edit icon next to the name you want to edit.
Step 3
Enter the settings as appropriate. See Table 4-31 for a description of the fields.
Table 4-31
Access Control List Fields
Field
Description
Action
Whether to permit or deny access for this group.
Group Name
If this action is for all groups, choose Any Group Name.
If this action is for a specific group, choose Enter Group Name and enter
the group name in the field.
Change Position
Step 4
To change the order of this group in the access control list, which is
displayed in the Access Control List Table page, click Change Position.
Click Submit to save the settings.
To delete a group, click the Edit icon for the group, then click the Delete icon in the task bar.
Step 5
From the left-panel menu, choose Enable Access Control List. The Enable Access Control List page is
displayed.
Step 6
Check the Enable Access Control List check box and click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
To move a group up or down in the Access Control List table, click the Up arrow or Down arrow in the
Move column.
The ACL can be applied from the device or from a device group. The source of the currently applied
settings is shown in the Access Control List Table page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-62
Chapter 4
Configuring Devices
Configuring the Service Engine
Scheduling Database Maintenance
Scheduling Database Maintenance
The database maintenance runs at the scheduled time only when the following three conditions are
satisfied:
•
Last vacuum process happened more than 30 minutes in the past.
•
Percent increase in disk space usage is greater than 10 percent.
•
Available free disk space is greater than 10 percent of the total disk space.
If any of these conditions are not satisfied, the database maintenance does not run at the scheduled time.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To schedule a database cleaning or reindexing, do the following:
Step 1
Choose Devices > Devices > General Settings > Database Maintenance. The Database Maintenance
Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-32 for a description of the fields.
Table 4-32
Field
Database Maintenance Settings Fields
Description
Full Database Maintenance Settings
Enable
When enabled, a full database maintenance routine is performed on the device.
Every Day
The days of the week when the maintenance is performed
Sun-Sat
When Every Day is enabled, all days of the week are also enabled.
At (time)
Time of day the maintenance is performed. Time is entered in 24-hour format as
hh:mm. The default is 04:00.
Regular Database Maintenance Settings
Step 3
Enable
When enabled, a re-indexing routine is performed on the device.
Every Day
The days of the week when the maintenance is performed.
Sun-Sat
When Every Day is enabled, all days of the week are also enabled.
At (time)
Time of day the maintenance is performed. Time is entered in 24-hour format as
hh:mm. The default is 02:00.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-63
Chapter 4
Configuring Devices
Configuring the Service Engine
Setting Storage Handling
Setting Storage Handling
The Storage option offers disk error-handling settings.
Enabling Disk Error Handling
Enabling Disk Error Handling
The Disk Error Handling page allows you to configure how disk errors are handled, and to define disk
error-handling thresholds for bad sectors and disk errors (I/O errors).
The Threshold for Bad Sectors and the Threshold for Disk Errors counts only apply to bad sectors
and disk errors detected since the last reboot of the device. These counts do not persist across a device
reboot (reload).
If the Enable Disk Error Handling Reload option is enabled and a SYSTEM disk drive is marked bad
because the disk error-handling threshold (bad sectors or disk errors) was reached, the device is
automatically reloaded. Following the device reload, the bad sector and disk error threshold counts are
reset, and a syslog message and an SNMP trap are generated.
If a critical disk drive is marked bad, the redundancy of the system disks for this device is affected.
Critical disks are disks with SYSTEM partitions. However, drives with SYSTEM partitions use RAID1.
With the RAID system, if the critical primary disk fails, the other mirrored disk (mirroring only occurs
for SYSTEM partitions) seamlessly continues operation. There is a separate alarm for bad RAID. The
SMART statistics that are returned by the show disks SMART-info detail command include sector
errors directly reported by the drive itself.
For more information about the SMART sector errors, latent sector handling, and the disk repair
command, see the “Disk Maintenance” section on page 8-26.
Note
We do not recommend enabling the Enable Disk Error Handling Reload option, because the software
state may be lost when the device is reloaded.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure a disk error-handling method, do the following:
Step 1
Choose Devices > Devices > General Settings > Storage > Disk Error Handling. The Disk Error
Handling Settings page is displayed.
Step 2
Check the Enable check box.
Step 3
Check the Enable Disk Error Handling Reload check box if you want the device to reload when a
critical disk (SYSTEM) has problems.
Step 4
Check the Enable Disk Error Handling Threshold check box if you want to set the number of disk
errors allowed before the disk is marked bad, and enter the following:
a.
In the Threshold for Bad Sectors field, enter the number of allowed bad sectors before marking the
disk bad. This threshold only applies to bad sectors detected since the last reboot of the device. The
range is 0 to 100. The default threshold is 30
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-64
Chapter 4
Configuring Devices
Configuring the Service Engine
b.
In the Threshold for Disk Errors field, enter the number of allowed disk errors (I/O errors) before
marking the disk bad. This threshold only applies to disk and sector errors detected since the last
reboot of the device. The range is from 0 to 100,000. The default is 500.
Note
Step 5
When both Threshold for Bad Sectors and Threshold for Disk Errors are set to 0, it means
never mark the disk bad when it detects bad sectors or disk errors, and the disk_failure alarm
is not raised. A disk with SYSTEM partitions uses RAID1. There is a separate alarm for bad
RAID.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
When a sector I/O error is detected, a “badsector” alarm is raised against the corresponding disk, which
occurs during the lifetime of a disk. A “badsector” alarm is raised when the number of bad sectors for a
specific disk exceeds the “badsector” alarm threshold. The default threshold for bad sector alarms is set
to 15 errored sectors. See the Cisco Internet Streamer CDS 3.2 Command Reference for information on
setting the threshold for bad sector alarms and remapped sector alarms, by using the following
commands:
(config)# disk error-handling threshold alarm-bad-sectors <threshValue>
(config)# disk error-handling threshold alarm-remapped-sectors <threshValue>
(config)# disk error-handling bad-sectors-mon-period <minutes>
The Disk Failure Percentage Threshold field on the Service Monitor page sets the overall percentage
of CDNFS disk failures. When the percentage of failed disks (default is 75) exceeds this threshold, no
further requests are sent to this device. The Disk Failure Threshold setting is only for the CDNFS disks.
For more information, see the “Setting Service Monitor Thresholds” section on page 4-85.
Network Settings
The Network pages provide settings for network connectivity. Configuring network settings consist of
the following procedures:
•
Enabling FTP Services
•
Enabling DNS
•
Enabling RCP
•
Configuring NTP
•
Configuring TCP
•
Setting the Time Zone
•
Viewing Network Interfaces
•
Configuring External IP Addresses
•
Configuring Port Channel and Load Balancing Settings
•
Configuring IP General Settings
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-65
Chapter 4
Configuring Devices
Configuring the Service Engine
•
Configuring IP ACL for IPv4 and IPv6
•
Configuring Static IPv4 Routes
•
Configuring Static IPv6 Routes
•
Configuring DSR VIP
Enabling FTP Services
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable FTP services to listen for connection requests, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > FTP. The FTP Settings page is displayed.
Step 2
Check the Enable FTP Services check box.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Enabling DNS
DNS Settings are required on all SEs, SRs, and CDSMs. The SEs need to be able to resolve the content
origin server host name, the SRs need to be able to communicate with the DNS servers, and the CDSMs
need to resolve host names.
To configure Domain Name System (DNS) servers, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > DNS. The DNS Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-33 for a description of the fields.
Table 4-33
Step 3
DNS Settings Fields
Field
Description
Enable
Enables Domain Name System (DNS) on the device.
List of DNS Servers
Space-delimited list of IP addresses for up to eight name servers
for name and address resolution.
Domain Names
A space-delimited list of up to three default domain names. A
default domain name allows the system to resolve any unqualified
hostnames. Any IP hostname that does not contain a domain name
will have the configured domain name appended to it. This
appended name is resolved by the DNS server and then added to
the host table. A DNS server must be configured on the system for
hostname resolution to work correctly. To do this, use the List of
DNS Servers field.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-66
Chapter 4
Configuring Devices
Configuring the Service Engine
To remove the settings from the device, click the Remove Settings icon in the task bar.
Enabling RCP
Remote Copy Protocol (RCP) lets you download, upload, and copy configuration files between remote
hosts and a switch. Unlike TFTP, which uses User Datagram Protocol (UDP), a connectionless protocol,
RCP uses TCP, which is connection oriented. This service listens for requests on TCP port 514.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable RCP services, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > RCP. The RCP page is displayed.
Step 2
Check the RCP Enable check box to have the RCP services listen for RCP requests.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring NTP
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the device to synchronize its clock with an NTP server, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > NTP. The NTP page is displayed.
Step 2
Check Enable to enable NTP.
Step 3
In the NTP Server field, enter the IP address or hostname of up to four NTP servers. Use a space to
separate the entries.
Step 4
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring TCP
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the TCP settings for service engine, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > TCP. The TCP page is displayed.
Step 2
Check Enable TCP Timestamps to enable TCP timestamps. By default, it is enabled.
Step 3
Check Enable fast recycling of TIME-WAIT sockets to set tcp_tw_recycle parameter. By default, it
is enabled.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-67
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 4
Check Enable safe reusing of TIME-WAIT sockets to set tcp_tw_reuse parameter By default, it is
enabled.
Step 5
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Setting the Time Zone
If you have an outside source on your network that provides time services, such as an NTP server, you
do not need to set the system clock manually. When manually setting the clock, enter the local time. The
device calculates Coordinated Universal Time (UTC) based on the time zone set.
Note
Caution
Two clocks exist in the system: the software clock and the hardware clock. The software uses the
software clock. The hardware clock is used only at startup to initialize the software clock.
We highly recommend that you use NTP servers to synchronize the devices in your CDS network. If you
change the local time on the device, you must change the BIOS clock time as well; otherwise, the
timestamps on the error logs are not synchronized. Changing the BIOS clock is required because the
kernel does not handle time zones.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To manually configure the time zone, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > Time Zone. The Time Zone page is
displayed with the default settings of UTC (offset = 0) and no daylight savings time configured.
Step 2
To configure a standard time zone, do the following:
a.
Click the Standard Time Zone radio button.
The standard convention for time zones uses a Location/Area format in which Location is a
continent or a geographic region of the world and Area is a time zone region within that location.
For a list of standard time zones that can be configured and their UTC offsets, see Table 4-34 on
page 4-70.
b.
From the Standard Time Zone drop-down list, choose a location for the time zone. The page
refreshes, displaying all area time zones for the chosen location in the second drop-down list.
c.
Choose an area for the time zone.
The UTC offset (hours and minutes ahead or behind UTC) for the corresponding time zone is
displayed. During summer time savings, the offset may differ and is displayed accordingly.
Note
Some of the standard time zones (mostly time zones within the United States) have daylight
savings time zones configured automatically.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-68
Chapter 4
Configuring Devices
Configuring the Service Engine
Step 3
Step 4
To configure a customized time zone, do the following:
a.
Click the Customized Time Zone radio button.
b.
In the Customized Time Zone field, enter a name to for the time zone. The time zone entry is case
sensitive and can contain up to 40 characters. Spaces are not allowed. If you specify any of the
standard time zone names, an error message is displayed when you click Submit.
c.
For UTC offset, choose + or – from the UTC Offset drop-down list to indicate whether the
configured time zone is ahead or behind UTC. Also, choose the number of hours (0 to 23) and
minutes (0 to 59) offset from UTC for the customized time zone. The range for the UTC offset is
from –23:59 to 23:59, and the default is 0:0.
To configure customized summer time savings, do the following:
Note
Customized summer time can be specified for both standard and customized time zones.
The start and end dates for summer time can be configured in two ways: absolute dates or recurring dates.
Absolute dates apply once and must be reset every year. Recurring dates apply every year.
a.
Click the Absolute Dates radio button to configure summer settings once.
b.
In the Start Date and End Date fields, specify the month, day, and year that the summer time
savings starts and ends in mm/dd/yyyy format.
Alternatively, click the Calendar icon and select a date. The chosen date is highlighted in blue.
Click Apply.
Step 5
c.
Click the Recurring Dates radio button to configure a recurring summer setting.
d.
Using the drop-down lists, choose the start day, week, and month when the summer time savings
starts. For example, if the summer time savings begins the first Sunday in March, you would select
Sunday, 1st, March from the drop-down lists.
e.
Using the drop-down lists, choose the start day, week, and month when the summer time savings
ends.
Using the Start Time drop-down lists and the End Time drop-down lists, choose the hour (0 to 23) and
minute (0 to 59) at which daylight savings time starts and ends.
Start Time and End Time fields for summer time are the times of the day when the clock is changed to
reflect summer time. By default, both start and end times are set at 00:00.
Step 6
In the Offset field, specify the minutes offset from UTC (0 to 1439). (See Table 4-34 on page 4-70.)
The summer time offset specifies the number of minutes that the system clock moves forward at the
specified start time and backward at the end time.
Step 7
To not specify a summer or daylight savings time for the corresponding time zone, click the No
Customized Summer Time Configured radio button.
Step 8
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Table 4-34 lists the UTC offsets for the different locations around the world.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-69
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-34
Time Zone—Offset from UTC
Time Zone
Offset from UTC
(in hours)
Time Zone
Offset from UTC
(in hours)
Africa/Algiers
+1
Asia/Vladivostok
+10
Africa/Cairo
+2
Asia/Yekaterinburg
+5
Africa/Casablanca
0
Asia/Yakutsk
+9
Africa/Harare
+2
Australia/Adelaide
+9.30
Africa/Johannesburg
+2
Australia/Brisbane
+10
Africa/Nairobi
+3
Australia/Darwin
+9.30
America/Buenos_Aires
–3
Australia/Hobart
+10
America/Caracas
–4
Australia/Perth
+8
America/Mexico_City
–6
Australia/Sydney
+10
America/Lima
–5
Canada/Atlantic
–4
America/Santiago
–4
Canada/Newfoundland
–3.30
Atlantic/Azores
–1
Canada/Saskatchewan
–6
Atlantic/Cape_Verde
–1
Europe/Athens
+2
Asia/Almaty
+6
Europe/Berlin
+1
Asia/Baghdad
+3
Europe/Bucharest
+2
Asia/Baku
+4
Europe/Helsinki
+2
Asia/Bangkok
+7
Europe/London
0
Asia/Colombo
+6
Europe/Moscow
+3
Asia/Dacca
+6
Europe/Paris
+1
Asia/Hong_Kong
+8
Europe/Prague
+1
Asia/Irkutsk
+8
Europe/Warsaw
+1
Asia/Jerusalem
+2
Japan
+9
Asia/Kabul
+4.30
Pacific/Auckland
+12
Asia/Karachi
+5
Pacific/Fiji
+12
Asia/Katmandu
+5.45
Pacific/Guam
+10
Asia/Krasnoyarsk
+7
Pacific/Kwajalein
–12
Asia/Magadan
+11
Pacific/Samoa
–11
Asia/Muscat
+4
US/Alaska
–9
Asia/New Delhi
+5.30
US/Central
–6
Asia/Rangoon
+6.30
US/Eastern
–5
Asia/Riyadh
+3
US/East–Indiana
–5
Asia/Seoul
+9
US/Hawaii
–10
Asia/Singapore
+8
US/Mountain
–7
Asia/Taipei
+8
US/Pacific
–8
Asia/Tehran
+3.30
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-70
Chapter 4
Configuring Devices
Configuring the Service Engine
The offset time (number of hours ahead or behind UTC) as displayed in the table is in effect during
winter time. During summer time or daylight savings time, the offset may be different from the values
in the table and is calculated and displayed accordingly by the system clock.
Viewing Network Interfaces
The Network Interfaces page is informational only. To view this information, choose Devices >
Devices > General Settings > Network > Network Interfaces. Information about the network
interfaces configured for the device is displayed.
Configuring External IP Addresses
The External IP page allows you to configure up to eight Network Address Translation (NAT) IP
addresses. This allows a router to translate up to eight internal addresses to registered unique addresses
and translate external registered addresses to addresses that are unique to the private network.
To configure NAT IP addresses, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > External IP. The External IP Settings page
is displayed.
Step 2
Check the Enable check box.
Step 3
In the External IP Address fields (1–8), enter up to eight IP addresses.
Step 4
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Port Channel and Load Balancing Settings
For information about configuring port channels using the CLI, see the “Redundant Dedicated
Management Ports” section on page J-6.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure load balancing on port channels, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > Port Channel Settings. The Port Channel
Settings page is displayed.
Step 2
From the Load Balancing Method drop-down list, choose one of the following load balancing methods:
•
dst-ip—Destination IP address
•
dst-mac—Destination MAC address
•
dst-mixed-ip-port—Destination IP address and TCP/UDP port
•
dst-port—Destination port
•
round robin—Each interface in the channel group
•
src-dst-ip—Source and destination IP address
•
src-dst-mac—Source and destination MAC address
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-71
Chapter 4
Configuring Devices
Configuring the Service Engine
•
src-dst-mixed-ip-port—Source destination IP address and source destination port
•
src-dst-port—Source and destination port
•
src-mixed-ip-port—Source IP address and source destination port
•
src-port—Source port
Round robin allows traffic to be distributed evenly among all interfaces in the channel group. The other
balancing options give you the flexibility to choose specific interfaces (by IP address, MAC address,
port) when sending an Ethernet frame.
The source and destination options mean that while calculating the outgoing interface, take into account
both the source and destination (MAC address or port).
Note
Step 3
Round-robin load-balancing mode is not supported when Link Aggregation Control Protocol
(LACP) is enabled on the port channel.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring IP General Settings
The Path Maximum Transmission Unit (MTU) Discovery discovers the largest IP packet size allowable
between the various links along the forwarding path and automatically sets the correct value for the
packet size. By using the largest MTU the links can support, the sending device can minimize the number
of packets it must send.
Note
The Path MTU Discovery is a process initiated by the sending device. If a server does not support IP
Path MTU Discovery, the receiving device has no mechanism available to avoid fragmenting datagrams
generated by the server.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable Path MTU Discovery, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > IP General Settings. The IP General
Settings page is displayed.
Step 2
Check Enable Path MTU Discovery.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-72
Chapter 4
Configuring Devices
Configuring the Service Engine
Configuring IP ACL for IPv4 and IPv6
Access control lists (ACLs) provide a means to filter packets by allowing a user to permit or deny IP
packets from crossing specified interfaces. Packet filtering helps to control packet movement through
the network. Such control can help limit network traffic and restrict network use by certain users or
devices.
Note
ACLs for IPv6 are separate from IPv4. To create IP ACLs for IPv4, choose Devices > Devices > General
Settings > Network > IP ACL. To create IP ACLs for IPv6, choose Devices > Devices > General
Settings > Network > IPv6 ACL.
You can also apply ACLs to management services such as SNMP, SSH, HTTPS, Telnet, and FTP. ACLs
can be used to control the traffic that these applications provide by restricting the type of traffic that the
applications handle.
In a managed CDS network environment, administrators need to be able to prevent unauthorized access
to various devices and services. CDS supports standard and extended ACLs that allow administrators to
restrict access to or through a CDS network device, such as the SE. Administrators can use ACLs to
reduce the infiltration of hackers, worms, and viruses that can harm the network.
ACLs provide controls that allow various services to be tied to a particular interface. For example, the
administrator can use IP ACLs to define a public interface on the Service Engine for content serving and
a private interface for management services (for example, Telnet, SSH, SNMP, HTTPS, and software
upgrades). A device attempting to access one of the services must be on a list of trusted devices before
it is allowed access. The implementation of ACLs for incoming traffic on certain ports for a particular
protocol type is similar to the ACL support for the Cisco Global Site Selector and Cisco routers.
To use ACLs, the system administrator must first configure ACLs and then apply them to specific
services. The following are some examples of how IP ACLs can be used in various enterprise
deployments:
Note
•
Application layer proxy firewall with a hardened outside interface has no ports exposed. (Hardened
means that the interface carefully restricts which ports are available for access primarily for security
reasons. Because the interface is outside, many types of attacks are possible.) The device’s outside
address is globally accessible from the Internet, while its inside address is private. The inside
interface has an ACL to limit Telnet, SSH, and CDSM traffic.
•
Device is deployed anywhere within the enterprise. Like routers and switches, the administrator
wants to limit Telnet, SSH, and CDSM access to the IT source subnets.
•
Device is deployed as a reverse proxy in an untrusted environment, and the administrator wishes to
allow only port 80 inbound traffic on the outside interface and outbound connections on the
back-end interface.
IP ACLs are defined for individual devices only. IP ACLs cannot be managed through device groups.
When you create an IP ACL, you should note the following constraints:
•
IP ACL names must be unique within the device.
•
IP ACL names must be limited to 30 characters and contain no spaces or special characters.
•
CDSM can manage up to 50 IP ACLs and a total of 500 conditions per device.
•
When the IP ACL name is numeric, numbers 1 through 99 denote standard IP ACLs and numbers
100 through 199 denote extended IP ACLs. IP ACL names that begin with a number cannot contain
nonnumeric characters.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-73
Chapter 4
Configuring Devices
Configuring the Service Engine
•
Extended IP ACLs cannot be used with SNMP applications.
Creating a New IP ACL
To create a new IP ACL, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > IP ACL for IPv4 addressing. Choose
Devices > Devices > General Settings > Network > IPv6 ACL for IPv6 addressing. The IP ACL Table
page is displayed.
The table is sortable by clicking the column headings.
Step 2
Click the Create New icon in the task bar. The IP ACL page is displayed.
To edit an ACL, click the Edit icon next to the name you want to edit.
Step 3
In the Name field, enter a name, observing the naming rules for IP ACLs.
Step 4
From the ACL Type drop-down list, choose an IP ACL type (Standard or Extended). The default is
Standard.
Step 5
Click Submit. The page refreshes and the Modifying IP ACL page for a newly created IP ACL is
displayed.
Note
Clicking Submit at this point merely saves the IP ACL; IP ACLs without any conditions defined
do not appear on the individual devices.
Adding Conditions to an IP ACL
To add conditions to an IP ACL, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > IP ACL for IPv4 addressing. Choose
Devices > Devices > General Settings > Network > IPv6 ACL for IPv6 addressing. The IP ACL Table
page is displayed.
Step 2
Click the Edit icon next to the name of the IP ACL you want to add a condition to. The Modifying IP
ACL page is displayed.
Step 3
Click the Create New icon in the task bar. The Condition page is displayed.
To edit a condition, click the Edit icon next to the name you want to edit.
Note
Step 4
Step 5
The number of available fields for creating IP ACL conditions depends on the whether the IP
ACL type is standard or extended.
Enter values for the properties that are enabled for the type of IP ACL that you are creating.
•
To create a standard IP ACL, go to Step 5.
•
To create an extended IP ACL, go to Step 6.
To set up conditions for a standard IP ACL, do the following:
a.
From the Purpose drop-down list, choose a purpose (Permit or Deny).
b.
In the Source IP field, enter the source IP address.
c.
In the Source IP Wildcard field, enter a source IP wildcard address.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-74
Chapter 4
Configuring Devices
Configuring the Service Engine
d.
Click Submit. The Modifying IP ACL page is displayed showing the new condition and its
configuration.
e.
To add another condition to the IP ACL, repeat the steps.
f.
To reorder your list of conditions in the Modifying IP ACL page, use the Up arrow or Down arrow
in the Order column, or click a column heading to sort by any configured parameter.
Note
g.
The order of the conditions listed becomes the order in which IP ACLs are applied to the
device.
When you have finished adding conditions to the IP ACL, and you are satisfied with all your entries
and the order in which the conditions are listed, click Submit in the Modifying IP ACL page to
commit the IP ACL to the device database.
A green “Change submitted” indicator appears in the lower right corner of the Modifying IP ACL
page to indicate that the IP ACL is being submitted to the device database.
Table 4-35 describes the fields in a standard IP ACL.
Table 4-35
Standard IP ACL Conditions
Field
Default Value
Description
Purpose1
Permit
Specifies whether a packet is to be passed (Permit) or dropped
(Deny).
Source IP1
0.0.0.0
Source IPv6
0::0
IP address of the network or host from which the packet is being
sent, specified as a 32-bit quantity in 4-part dotted decimal format.
for IPv4.
Source IP1
Wildcard
255.255.255.255
Source Prefix
0
Wildcard bits to be applied to the source, specified as a 32-bit
quantity in 4-part dotted decimal format for IPv4. Place a 1 in the
bit positions that you want to ignore and identify bits of interest
with a 0.
1. Required field.
Step 6
To set up conditions for an extended IP ACL, do the following:
a.
From the Purpose drop-down list, choose a purpose (Permit or Deny).
b.
From the Extended Type drop-down list, choose Generic, TCP, UDP, or ICMP.
After you choose a type of extended IP ACL, various options become available depending on what
type you choose.
c.
Enter the settings as appropriate. See Table 4-36 for descriptions of the extended IP ACL fields.
d.
Click Submit. The Modifying IP ACL page is displayed showing the new condition and its
configuration.
e.
To add another condition to the IP ACL, repeat the steps.
f.
To reorder your list of conditions from the Modifying IP ACL page, use the Up arrow or Down arrow
in the Order column, or click a column heading to sort by any configured parameter.
Note
The order of the conditions listed becomes the order in which IP ACLs are applied to the
device.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-75
Chapter 4
Configuring Devices
Configuring the Service Engine
g.
When you have finished adding conditions to the IP ACL, and you are satisfied with all your entries
and the order in which the conditions are listed, click Submit in the Modifying IP ACL page to
commit the IP ACL to the device database.
A green “Change submitted” indicator appears in the lower-left corner of the Modifying IP ACL
page to indicate that the IP ACL is being submitted to the device database.
Table 4-36
Extended IP ACL Conditions
Field
Default Value
Description
Purpose1
Permit
Specifies whether a packet is to be passed (Permit) or dropped Generic, TCP,
(Deny).
UDP, ICMP
Protocol
ip
Internet protocol (gre, icmp, ip, tcp, or udp). To match any
Internet protocol, use the ip keyword.
Generic
Established
Unchecked (false)
When checked, a match with the ACL condition occurs if the
TCP datagram has the ACK or RST bits set, indicating an
established connection. Initial TCP datagrams used to form a
connection are not matched.
TCP
Source IP1
0.0.0.0
SourceIPv6
0::0
IP address of the network or host from which the packet is being Generic, TCP,
sent, specified as a 32-bit quantity in 4-part dotted decimal
UDP, ICMP
format for IPv4.
Source IP Wildcard1 255.255.255.255
Source Prefix
0
Source Port 1
0
Extended Type
Wildcard bits to be applied to the source, specified as a 32-bit
quantity in 4-part dotted decimal format for IPv4. Place a 1 in
the bit positions that you want to ignore and identify bits of
interest with a 0.
Generic, TCP,
UDP, ICMP
Decimal number or name of a port. Valid port numbers are 0 to TCP, UDP
65535. See Table 4-37 and Table 4-38 for port name
descriptions and associated port numbers.
Valid TCP port names are as
follows:
Valid UDP port names are as
follows:
•
domain
•
bootpc
•
exec
•
bootps
•
ftp
•
domain
•
ftp-data
•
netbios-dgm
•
https
•
netbios-ns
•
nfs
•
netbios-ss
•
rtsp
•
nfs
•
ssh
•
ntp
•
telnet
•
snmp
•
www
•
snmptrap
Source Operator
range
Specifies how to compare the source ports against incoming
packets. Choices are <, >, ==, !=, or range.
TCP, UDP
Source Port 2
65535
Decimal number or name of a port. See Source Port 1.
TCP, UDP
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-76
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-36
Extended IP ACL Conditions (continued)
Field
Default Value
Description
Extended Type
Destination IP
0.0.0.0
Destination IPv6
0::0
IP address of the network or host to which the packet is being
sent, specified as a 32-bit quantity in 4-part dotted decimal
format for IPv4.
Generic, TCP,
UDP, ICMP
Destination IP
Wildcard
255.255.255.255
Wildcard bits to be applied to the source, specified as a 32-bit
quantity in 4-part dotted decimal format for IPv4. Place a 1 in
the bit positions that you want to ignore and identify bits of
interest with a 0.
Generic, TCP,
UDP, ICMP
0
Destination Prefix
Destination Port 1
0
Decimal number or name of a port. Valid port numbers are 0 to TCP, UDP
65535. See Table 4-37 and Table 4-38 for port name
descriptions and associated port numbers.
Valid TCP port names are as
follows:
Valid UDP port names are as
follows:
•
domain
•
bootpc
•
exec
•
bootps
•
ftp
•
domain
•
ftp-data
•
netbios-dgm
•
https
•
netbios-ns
•
nfs
•
netbios-ss
•
rtsp
•
nfs
•
ssh
•
ntp
•
telnet
•
snmp
•
www
•
snmptrap
Destination Operator range
Specifies how to compare the destination ports against incoming TCP, UDP
packets. Choices are <, >, ==, !=, or range.
Destination Port 2
65535
Decimal number or name of a port. See Destination Port 1.
TCP, UDP
ICMP Param Type1
None
Choices are None, Type/Code, or Msg.
ICMP
ICMPv6 Param Type
ICMP Message1
ICMPv6 Message
administrativelyprohibited
•
None—Disables the ICMP Type, Code, and Message fields.
•
Type/Code—Allows ICMP messages to be filtered by
ICMP message type and code. Also enables the ability to set
an ICMP message code number.
•
Msg—Allows a combination of type and code to be
specified using a keyword. Activates the ICMP Message
drop-down list. Disables the ICMP Type field.
Allows a combination of ICMP type and code to be specified
using a keyword chosen from the drop-down list.
ICMP
See Table 4-39 for descriptions of the ICMP messages.
ICMP
Type1
ICMPv6 Type
0
Number from 0 to 255. This field is enabled when you choose
Type/Code.
ICMP
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-77
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-36
Extended IP ACL Conditions (continued)
Field
Use ICMP
Code1
Default Value
Description
Extended Type
Unchecked
When checked, enables the ICMP Code field.
ICMP
0
Number from 0 to 255. Message code option that allows ICMP ICMP
messages of a particular type to be further filtered by an ICMP
message code.
Use ICMPv6 Code
ICMP Code1
ICMPv6 Code
1. Required field.
Table 4-37 lists the UDP keywords that you can use with extended access control lists.
Table 4-37
UDP Keywords and Port Numbers
Port Name
Description
UDP Port Number
bootpc
Bootstrap Protocol (BOOTP) client service
68
bootps
Bootstrap Protocol (BOOTP) server service
67
domain
Domain Name System (DNS) service
53
netbios-dgm
NetBIOS datagram service
138
netbios-ns
NetBIOS name resolution service
137
netbios-ss
NetBIOS session service
139
nfs
Network File System service
2049
ntp
Network Time Protocol settings
123
snmp
Simple Network Management Protocol service
161
snmptrap
SNMP traps
162
Table 4-38 lists the TCP keywords that you can use with extended access control lists.
Table 4-38
TCP Keywords and Port Numbers
Port Name
Description
TCP Port Number
domain
Domain Name System service
53
exec
Remote process execution
512
ftp
File Transfer Protocol service
21
ftp-data
FTP data connections (used infrequently)
20
https
Secure HTTP service
443
nfs
Network File System service applications
2049
rtsp
Real-Time Streaming Protocol applications
554
ssh
Secure Shell login
22
telnet
Remote login using Telnet
23
www
World Wide Web (HTTP) service
80
Table 4-39 lists the keywords that you can use to match specific ICMP message types and codes.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-78
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-39
Keywords for ICMP Message Type and Code
Message
Description
administratively-prohibited
Messages that are administratively prohibited from being allowed
access.
alternate-address
Messages that specify alternate IP addresses.
conversion-error
Messages that denote a datagram conversion error.
dod-host-prohibited
Messages that signify a Department of Defense (DoD) protocol
Internet host denial.
dod-net-prohibited
Messages that specify a DoD protocol network denial.
echo
Messages that are used to send echo packets to test basic network
connectivity.
echo-reply
Messages that are used to send echo reply packets.
general-parameter-problem
Messages that report general parameter problems.
host-isolated
Messages that indicate that the host is isolated.
host-precedence-unreachable
Messages that have been received with the protocol field of the IP
header set to 1 (ICMP) and the type field in the ICMP header set to
3 (Host Unreachable). This is the most common response. Large
numbers of this datagram type on the network are indicative of
network difficulties or may be indicative of hostile actions.
host-redirect
Messages that specify redirection to a host.
host-tos-redirect
Messages that specify redirection to a host for type of
service-based (ToS) routing.
host-tos-unreachable
Messages that denote that the host is unreachable for ToS-based
routing.
host-unknown
Messages that specify that the host or source is unknown.
host-unreachable
Messages that specify that the host is unreachable.
information-reply
Messages that contain domain name replies.
information-request
Messages that contain domain name requests.
mask-reply
Messages that contain subnet mask replies.
mask-request
Messages that contain subnet mask requests.
mobile-redirect
Messages that specify redirection to a mobile host.
net-redirect
Messages that are used for redirection to a different network.
net-tos-redirect
Messages that are used for redirection to a different network for
ToS-based routing.
net-tos-unreachable
Messages that specify that the network is unreachable for the
ToS-based routing.
net-unreachable
Messages that specify that the network is unreachable.
network-unknown
Messages that denote that the network is unknown.
no-room-for-option
Messages that specify the requirement of a parameter, but that no
room is available for it.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-79
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-39
Keywords for ICMP Message Type and Code (continued)
Message
Description
option-missing
Messages that specify the requirement of a parameter, but that
parameter is not available.
packet-too-big
Messages that specify that the ICMP packet requires fragmentation
but the Do Not Fragment (DF) bit is set.
parameter-problem
Messages that signify parameter-related problems.
port-unreachable
Messages that specify that the port is unreachable.
precedence-unreachable
Messages that specify that host precedence is not available.
protocol-unreachable
Messages that specify that the protocol is unreachable.
reassembly-timeout
Messages that specify a timeout during reassembling of packets.
redirect
Messages that have been received with the protocol field of the IP
header set to 1 (ICMP) and the type field in the ICMP header set to
5 (Redirect). ICMP redirect messages are used by routers to notify
the hosts on the data link that a better route is available for a
particular destination.
router-advertisement
Messages that contain ICMP router discovery messages called
router advertisements.
router-solicitation
Messages that are multicast to ask for immediate updates on
neighboring router interface states.
source-quench
Messages that have been received with the protocol field of the IP
header set to 1 (ICMP) and the type field in the ICMP header set to
4 (Source Quench). This datagram may be used in network
management to provide congestion control. A source quench
packet is issued when a router is beginning to lose packets due to
the transmission rate of a source. The source quench is a request to
the source to reduce the rate of a datagram transmission.
source-route-failed
Messages that specify the failure of a source route.
time-exceeded
Messages that specify information about all instances when
specified times were exceeded.
timestamp-reply
Messages that contain timestamp replies.
timestamp-request
Messages that contain timestamp requests.
traceroute
Messages that specify the entire route to a network host from the
source.
ttl-exceeded
Messages that specify that ICMP packets have exceeded the
time-to-live configuration.
unreachable
Messages that are sent when packets are denied by an access
control list; these packets are not dropped in the hardware but
generate the ICMP-unreachable message.
Applying an IP ACL to an Interface
The IP ACLs can be applied to a particular interface (such as management services to a private IP
address) so that the device can have one interface in a public IP address space that serves content and
another interface in a private IP address space that the administrator uses for management purposes. This
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-80
Chapter 4
Configuring Devices
Configuring the Service Engine
feature ensures that clients can access the Service Engine only in the public IP address space for serving
content and not access it for management purposes. A device attempting to access one of these
applications that is associated with an IP ACL must be on the list of trusted devices to be allowed access.
To apply an IP ACL to an interface from the CLI, use the following interface configuration command:
interface {GigabitEthernet | Portchannel | Standby | TenGigabitEthernet} slot/port [ip | ipv6]
access-group {accesslistnumber | accesslistname} {in | out}
Deleting an IP ACL
You can delete an IP ACL, including all conditions and associations with network interfaces, or you can
delete only the IP ACL conditions. Deleting all conditions allows you to change the IP ACL type if you
choose to do so. The IP ACL entry continues to appear in the IP ACL listing; however, it is in effect
nonexistent.
To delete an IP ACL, do the following:
Step 1
Choose Devices > Devices. > General Settings > Network > IP ACL for IPv4 addressing. Choose
Devices > Devices. > General Settings > Network > IPv6 ACL for IPv6 addressing.The IP ACL Table
page is displayed.
Step 2
Click the Edit icon next to the name of the IP ACL that you want to delete. The Modifying IP ACL page
is displayed. If you created conditions for the IP ACL, you have three options for deletion:
•
Delete ACL—This option removes the IP ACL, including all conditions and associations with
network interfaces and applications.
•
Delete All Conditions—This option removes all the conditions, while preserving the IP ACL name.
•
Delete IP ACL Condition—This option removes one condition from the ACL.
Step 3
To delete the entire IP ACL, click Delete ACL in the task bar. You are prompted to confirm your action.
Click OK. The record is deleted.
Step 4
To delete only the conditions, click Delete All Conditions in the task bar. You are prompted to confirm
your action. Click OK. The window refreshes, conditions are deleted, and the ACL Type field becomes
available.
Step 5
To delete one condition, do the following:
a.
Click the Edit icon next to the condition. The condition settings are displayed.
b.
Click the Delete IP ACL Condition icon in the task bar. The IP ACL table is displayed.
c.
Click Submit to save the IP ACL table to the database.
Configuring Static IPv4 Routes
The Static IP Routes page allows you to configure a static IPv4 route for a network or host. Any IP packet
designated for the specified destination uses the configured route.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure a static IP route, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > Static IP Routes. The IP Route Table page
is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-81
Chapter 4
Configuring Devices
Configuring the Service Engine
The table is sortable by clicking the column headings.
Step 2
Click the Create New icon in the task bar. The IP Route page is displayed.
To edit a static route, click the Edit icon next to the name you want to edit.
Step 3
In the Destination Network Address field, enter the destination network IP address.
Step 4
In the Netmask field, enter the destination host netmask.
Step 5
In the Gateway’s IP Address field, enter the IP address of the gateway interface.
Step 6
Click Submit to save the settings.
To delete a route, click the Edit icon for the route, then click the Delete icon in the task bar.
Configuring Static IPv6 Routes
The Static IPv6 Routes page allows you to configure a staticIPv6 route for a network or host. Any IP
packet designated for the specified destination uses the configured route.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure a static IPv6 route, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > Static IPv6 Routes. The IPv6 Route Table
page is displayed.
The table is sortable by clicking the column headings.
Step 2
Click the Create New icon in the task bar. The IPv6 Route page is displayed.
To edit a static route, click the Edit icon next to the name you want to edit.
Step 3
In the Destination Network Address field, enter the destination network IPv6 address.
Step 4
In the Prefix field, enter the prefix length of the route, subnet, or address range. For example, for
2001:DB8::/32, the prefix length is 32.
Step 5
In the Gateway’s IPv6 Address field, enter the IPv6 address of the gateway interface.
Step 6
Click Submit to save the settings.
To delete a route, click the Edit icon for the route, then click the Delete icon in the task bar.
Configuring DSR VIP
The CDS supports Virtual IP (VIP) configuration for Direct Server Return (DSR) when working with
networks that use load balancers. DSR bypasses the load balancer for all server responses to client
requests by using MAC Address Translation (MAT).
The CDS allows for the configuration of up to four VIPs (on loopback interfaces).
Client requests are sent to the load balancer and the load balancer sends the requests on to the Service
Router. If DSR VIP is configured on the CDS (and supported on the load balancer), all CDS responses
to the client are sent directly to the client, bypassing the load balancer.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-82
Chapter 4
Configuring Devices
Configuring the Service Engine
Note
If DSR VIP is configured on an SE, the DSR VIP IP address cannot be the same as the Origin Server
FQDN (OFQDN).
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure a DSR VIP, do the following:
Step 1
Choose Devices > Devices > General Settings > Network > DSR VIP. The DSR VIP page is displayed.
Step 2
In the Direct Server Return VIP 1 field, enter the IPv4 address of the Direct Server Return VIP. In the
Direct Server Return IPv6 VIP1 field, enter the IPv6 address of the Direct Server Return VIP.
Step 3
Enter any additional DSR VIPs in the remaining fields (Direct Server Return [IPv6] VIP 2 to 4).
Step 4
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Notification and Tracking
The Notification and Tracking pages provide settings for alarms, thresholds, SNMP connectivity, and
device monitoring. Configuring notification and tracking consists of the following procedures:
•
Enabling Alarm Overload Detection
•
Setting Service Monitor Thresholds
•
Configuring SNMP
•
Enabling System Logs
Alarm Settings
The Alarm Settings page covers the following configuration settings;
•
Enabling Alarm Overload Detection
•
Alarms for Admin Shutdown Interface
Enabling Alarm Overload Detection
The device tracks the rate of incoming alarms from the Node Health Manager. If the rate of incoming
alarms exceeds the high-water mark (HWM) threshold, the device enters an alarm overload state. This
condition occurs when multiple applications raise alarms at the same time. When a device is in an alarm
overload state, the following events occur:
•
Traps for the raise alarm-overload alarm and clear alarm-overload alarm are sent. SNMP traps for
subsequent alarm raise-and-clear operations are suspended.
•
Traps for alarm operations that occur between the raise-alarm-overload alarm and the
clear-alarm-overload alarm operations are suspended, but individual device alarm information is
still collected and available using the CLI.
•
Device remains in an alarm overload state until the rate of incoming alarms decreases to less than
the low-water mark (LWM).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-83
Chapter 4
Configuring Devices
Configuring the Service Engine
•
If the incoming alarm rate falls below the LWM, the device comes out of the alarm overload state
and begins to report the alarm counts to the SNMP servers and the CDSM.
Alarms that have been raised on a device can be listed by using the CLI commands shown in Table 4-40.
These CLI commands allow you to systematically drill down to the source of an alarm.
Table 4-40
Viewing Device Alarms
Command Syntax
Description
show
alarms
Displays a list of all currently raised alarms (critical, major, and
minor alarms) on the device.
show alarms critical Displays a list of only currently raised critical alarms on the device.
show alarms major
Displays a list of only currently raised major alarms on the device.
show alarms minor
Displays a list of only currently raised minor alarms on the device.
show alarms detail
Displays detailed information about the currently raised alarms.
show alarms history Displays a history of alarms that have been raised and cleared on the
device. The CLI retains the last 100 alarm raise and clear events
only.
show alarms status
Displays the counts for the currently raised alarms on the device.
Also lists the alarm-overload state and the alarm-overload settings.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the alarm overload detection, do the following:
Step 1
Choose Devices > Devices > General Settings > Notification and Tracking > Alarm Settings. The
Alarm Settings page is displayed.
Step 2
Uncheck the Enable Alarm Overload Detection check box if you do not want to configure the device
to suspend alarm raise and clear operations when multiple applications report error conditions. Alarm
overload detection is enabled by default.
Step 3
In the Alarm Overload Low Water Mark field, enter the number of alarms per second for the clear
alarm overload threshold. The low water mark is the level to which the number of alarms must drop
below before alarm traps can be sent. The default value is 1.
Step 4
In the Alarm Overload High Water Mark field, enter the number of alarms per second for the raise
alarm-overload threshold. The high-water mark is the level the number of alarms must exceed before
alarms are suspended. The default value is 10.
Step 5
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Alarms for Admin Shutdown Interface
When the Alarms for Admin Shutdown Interface check box is checked, the interface alarm is
shutdown. If there is already an alarm raised when the setting is submitted, unchecking the option and
submitting the change does not clear the outstanding alarm. There are two ways to avoid this situation:
1.
Clear the outstanding alarm first before disabling this option.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-84
Chapter 4
Configuring Devices
Configuring the Service Engine
2.
Note
Disable this option and reboot. The alarm is cleared during reboot.
The Alarms for Admin Shutdown Interface option should be enabled before any of the above for the
alarm to take affect.
To enable the Alarms for Admin Shutdown Interface option, do the following:
Step 1
Choose Devices > Devices > General Settings > Notification and Tracking > Alarm Settings. The
Alarm Settings page is displayed.
Step 2
Check the Alarms for Admin Shutdown Interface check box to enable this option.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Setting Service Monitor Thresholds
The Service Monitor page is where you configure workload thresholds for the device. In load-based
routing, these thresholds are used to determine the best device to serve requested content. For more
information about load-based routing, see the “Configuring the Service Router” section on page 4-101.
Note
Threshold monitoring is performed on each device in the CDS. The protocol engine and NIC bandwidth
thresholds are only monitored on the SE. They are not monitored on the SR and CDSM.
Note
The base license limit is set to 200 sessions and 200 Mbps bandwidth.
•
The burst count, which indicates the number of days after which a major alarm is raised, is
configurable. On the Service Engine, use the service-router service-monitor threshold burstcnt
command to configure the burst count. The default setting is one (1), which means all the minor
alarms that occur in a single day (24-hour interval) are counted as one single alarm. If the
service-router service-monitor threshold burstcnt command is set to two, all minor alarms that
occur in two days (48-hour interval) are counted as a single alarm.
•
A universal license is similar to a regular license, except it has a higher bandwidth and applies to all
protocol engines (except Web Engine). When a universal license is purchased and configured, the
alarm data for all protocol engines are cleared. Thereafter, the monitoring of the protocol engines
continues as usual for any future alarms.
•
On the Service Engine, use the service-router service-monitor license-universal enable command
to enable the universal license. The service-router service-monitor license-universal command is
disabled by default.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-85
Chapter 4
Configuring Devices
Configuring the Service Engine
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure workload thresholds, do the following:
Step 1
Choose Devices > Devices > General Settings > Notification and Tracking > Service Monitor. The
Service Monitor page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-41 for a description of the fields.
Table 4-41
Service Monitor Fields
Field
Description
CPU Settings
Enable
Allows the SR to collect CPU load information from the device.
Threshold
Value (as a percentage) that determines when the device is overloaded. The threshold
determines the extent of CPU usage allowed. The range is from 1 to 100. The default
is 80.
Sample Period
Time interval (in seconds) between two consecutive samples. The sample period is
the time during which the device and the SR exchange keep-alive messages that
contain the device load information. The range is from 1 to 60. The default is 1.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
Disk Settings
Enable
Allows the SR to collect disk transaction information from the device.
Threshold
The threshold, as a percentage, determines the extent of disk I/O load allowed. The
disk threshold is a disk I/O load threshold setting. It is not used to monitor disk
usage, it is calculated using the kernel’s diskstats status. This represents how much
disk I/O capacity the device is using. It is calcuated across all disks on the device.
The range is from 1 to 100. The default is 80.
Sample Period
Time interval (in seconds) between two consecutive samples. The range is from 1 to
60. The default is 1.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
Memory Settings
Enable
Allows the SR to collect memory usage information from the device.
Threshold
The threshold (in percent) determines the extent of memory usage allowed. The
range is from 1 to 100. The default is 80.
Sample Period
Time interval (in seconds) between two consecutive samples. The range is from 1 to
60. The default is 1.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
KMemory Settings
Enable
Allows the SR to collect kernel memory usage information from the device.
Threshold
The threshold (in percent) determines the extent of kernel memory usage allowed.
The range is from 1 to 100. The default is 50.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-86
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-41
Service Monitor Fields (continued)
Field
Description
Sample Period
Time interval (in seconds) between two consecutive samples. The range is from 1 to
60. The default is 1.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
WMT Settings1
Enable
Allows the SR to collect Windows Media Streaming stream count information from
the SE.
Threshold
Percentage of streams for which the SE has been either configured or licensed. The
range is from 1 to 100. The default is 90.
Sample Period
Time interval (in seconds) between two consecutive samples. The range is from 1 to
60. The default is 1.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
FMS Settings1
Enable
Allows the SR to collect Flash Media Streaming stream count information from the
SE.
Threshold
Percentage of streams for which the SE has been either configured or licensed. The
range is from 1 to 100. The default is 90.
Sample Period
Time interval (in seconds) between two consecutive samples. The range is from 1 to
60. The default is 1.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
Movie Streamer Settings1, 2
Enable
Allows the SR to collect stream count information from the SE.
Threshold
Percentage of streams for which the SE has been either configured or licensed. The
range is from 1 to 100. The default is 90.
NIC Bandwidth Settings1
Enable
Allows the SR to collect NIC bandwidth information from the SE.
Threshold
The threshold, as a percentage, determines the extent of NIC bandwidth usage
allowed. The range is from 1 to 100. The default is 90.
Sample Period
Time interval (in seconds) between two consecutive samples. The range is from 1 to
60. The default is 3.
Number of
Samples
Number of most recently sampled values used when calculating the average. The
range is from 1 to 120. The default is 2.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-87
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-41
Field
Service Monitor Fields (continued)
Description
Disk Failure Percentage
Threshold
Overall percentage of CDNFS disk failures. The range is from 1 to 100. The default
is 75.
When the percentage failed disks exceeds this threshold, no further requests are sent
to this device. The Disk Failure Threshold is only for the CDNFS disks.
Note
When an alarm is received for a SYSTEM disk, it is immediately marked as
a failed disk. It is not checked against the Disk Failure Threshold. The SR
continues redirecting to the SE, unless all SYSTEM disks on the SE are
marked as failed disks. If disks have both SYSTEM and CDNFS partitions,
they are treated as only system disks, which means they are not included in
the accounting of the CDNFS disk calculation.
Augmentation Alarms
Enable
Enables augmentation alarms. For more information, see the “Augmentation
Alarms” section on page 4-88.
Threshold
The augmentation alarms threshold is a percentage, that applies to the CPU, memory,
kernel memory, disk, disk fail count, NIC, and protocol engine usages. By default it
is set to 80 percent. The threshold value range is 1–100.
As an example of an augmentation alarm, if the threshold configured for CPU usage
is 80 percent, and the augmentation threshold is set to 80 percent, then the
augmentation alarm for CPU usage is raised when the CPU usage crosses 64 percent.
If “A” represents the Service Monitor threshold configured, and “B” represents the
augmentation threshold configured, then the threshold for raising an augmentation
alarm = (A * B) / 100 percent. For more information, see the “Augmentation Alarm
Example” section on page 4-90.
Transaction Logging
Enable
Enables Service Monitoring transaction logging. For more information, see the
“Service Monitor Transaction Logs” section on page 7-83“Service Monitor
Transaction Logs” section on page 7-84.
1. Protocol engines and NIC bandwidth are only monitored on the SE. They are not monitored on the CDSM and SR.
2. Sample period and number of samples are not required for Movie Streamer and Web Engine because these protocol engines
do not support bandwidth-based threshold monitoring.
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Augmentation Alarms
Augmentation alarms are soft alarms that send alerts before the threshold is reached. These alarms are
applicable to all devices—Service Engines, Service Routers and CDSMs. Augmentation thresholds
apply to device and protocol engine parameters.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-88
Chapter 4
Configuring Devices
Configuring the Service Engine
A different augmentation alarm is supported for each of the device-level thresholds. Based on the device
parameters monitored by Service Monitor, the following minor alarms could be raised for device-level
thresholds:
•
CpuAugThreshold—Service Monitor CPU augmentation alarm.
•
MemAugThreshold—Service Monitor memory augmentation alarm.
•
KmemAugThreshold—Service Monitor kernel memory augmentation alarm.
•
DiskAugThreshold—Service Monitor disk augmentation alarm.
•
DiskFailCntAugThreshold—Service Monitor disk failure count augmentation alarm.
•
NicAugThreshold—Service Monitor NIC augmentation alarm.
Check the augmentation threshold, device-level threshold, and average load for the above alarm
instance. Add more devices if necessary. A useful command is the show service-router service-monitor
command. The augmentation alarms raised are displayed in the show alarms detail command. The
alarms are cleared when the load goes below the augmentation threshold.
Note
For system disks (disks that contain SYSTEM partitions), only when all system disks are bad is the
diskfailure augmentation and threshold alarms raised. The diskfailcnt threshold does not apply to system
disks. The threshold only applies to CDNFS disks, which is also the case for the augmentation
thresholds. This is because the system disks use RAID1. There is a separate alarm for bad RAID. With
the RAID system, if the critical primary disk fails, the other mirrored disk (mirroring only occurs for
SYSTEM partitions) seamlessly continues operation. However, if the disk drive that is marked bad is a
critical disk drive, the redundancy of the system disks for this device is affected. For more information
on disk error handling and threshold recommendations, see the “Enabling Disk Error Handling” section
on page 4-64“Enabling Disk Error Handling” section on page 4-64.
As the show disk details command output reports, if disks have both SYSTEM and CDNFS partitions,
they are treated as only system disks, which means they are not included in the accounting of the CDNFS
disk calculation.
Note
The NIC augmentation alarm is only applicable if the device is an SE.
Different augmentation alarm s are supported for each of the protocol engines, which only apply if the
device is an SE. The following minor alarms could be raised for protocol-engine thresholds:
•
rtspgaugmentexceeded— RTSP gateway TPS has reached augmentation threshold limits
•
aug_memory_exceeded—Web Engine augmentation memory threshold exceeded
•
aug_session_exceeded—Web Engine has reached augmentation threshold for concurrent session
•
wmtaugmentexceeded—Windows Media Streaming has reached augmentation threshold limits
•
msaugmentexceeded—Movie Streamer has reached augmentation threshold limits
•
FmsAugThreshold—Flash Media Streaming has reached augmentation threshold limits
•
WebCalLookupAugThreshold—Web Engine has reached augmentation threshold for storage lookup
•
WebCalDiskWriteAugThreshold—Web Engine has reached augmentation threshold for storage disk
write
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-89
Chapter 4
Configuring Devices
Configuring the Service Engine
Augmentation Alarm Example
Maximum concurrent connections have a default value of 200 and maximum bandwidth has a default
value of 200 Mbps. The augmentation alarm is enabled through the Service Monitor and the
augmentation threshold is configured at 80 percent (default). The default service threshold for Flash
Media Streaming is 90 percent.
In this case, the augmentation alarm is raised for Flash Media Streaming when 0.8 * 0.9 * 200 = 144
connections or 144 Mbps of bandwidth is exceeded. The Service Router still redirects requests to this
Service Engine. The alarm is cleared when the traffic falls below either of the thresholds; that is, 144
connections or 144 Mbps in this example.
Configuring SNMP
The Cisco CDS supports the following versions of SNMP:
•
Version 1 (SNMPv1)—A network management protocol that provides a means to monitor and
control network devices, and to manage configurations, statistics collection, performance, and
security.
•
Version 2 (SNMPv2c)—The second version of SNMP, it supports centralized and distributed
network management strategies, and includes improvements in the Structure of Management
Information (SMI), protocol operations, management architecture, and security.
•
Version 3 (SNMPv3)—An interoperable standards-based protocol for network management.
SNMPv3 provides secure access to devices by a combination of authenticating and encrypting
packets over the network. The security features provided in SNMPv3 are:
– Message integrity—Ensuring that a packet has not been tampered with in-transit.
– Authentication—Determining the message is from a valid source.
– Encryption—Scrambling the contents of a packet prevent it from being seen by an unauthorized
source.
SNMPv3 provides for both security models and security levels. A security model is an
authentication strategy that is set up for a user and the group in which the user resides. A security
level is the permitted level of security within a security model. A combination of a security model
and a security level determines which security mechanism is employed when handling an SNMP
packet. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3.
Table 4-42 identifies what the combinations of security models and levels mean.
Table 4-42
SNMP Security Models and Levels
Model Level
Authentication
Encryption
Process
v1
noAuthNoPriv
Community String
No
Uses a community string match for
authentication.
v2c
noAuthNoPriv
Community String
No
Uses a community string match for
authentication.
v3
noAuthNoPriv
Username
No
Uses a username match for authentication.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-90
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-42
SNMP Security Models and Levels
Model Level
Authentication
Encryption
Process
v3
authNoPriv
MD5 or SHA
No
Provides authentication based on the
HMAC-MD5 or HMAC-SHA algorithms.
v3
authPriv
MD5 or SHA
DES
Provides authentication based on the
HMAC-MD5 or HMAC-SHA algorithms.
Provides DES 56-bit encryption in
addition to authentication based on the
CBC-DES (DES-56) standard.
The SNMPv3 agent can be used in the following modes:
•
noAuthNoPriv mode (that is, no security mechanisms turned on for packets)
•
AuthNoPriv mode (for packets that do not need to be encrypted using the privacy algorithm [DES
56])
•
AuthPriv mode (for packets that must be encrypted; privacy requires that authentication be
performed on the packet)
Using SNMPv3, users can securely collect management information from their SNMP agents without
worrying that the data has been tampered with. Also, confidential information, such as SNMP set packets
that change a Content Engine’s configuration, can be encrypted to prevent their contents from being
exposed on the wire. Also, the group-based administrative model allows different users to access the
same SNMP agent with varying access privileges.
Note the following about SNMPv3 objects:
•
Each user belongs to a group.
•
Group defines the access policy for a set of users.
•
Access policy is what SNMP objects can be accessed for reading, writing, and creating.
•
Group determines the list of notifications its users can receive.
•
Group also defines the security model and security level for its users.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the SNMP settings, do the following:
Step 1
Choose Devices > Devices > General Settings > Notification and Tracking > SNMP > General
Settings. The SNMP General Settings page is displayed.
Step 2
Enable the settings as appropriate. See Table 4-43 for a description of the fields.
Table 4-43
Field
SNMP General Settings Fields
Description
Traps
Enable SNMP
Settings
Enables the SNMP agent to transmit traps to the SNMP server.
Service Engine
Enables the Disk Fail trap, which is the disk failure error trap.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-91
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-43
SNMP General Settings Fields (continued)
Field
Description
SNMP
Enables SNMP-specific traps:
SE Alarm
•
Authentication—Enables authentication trap.
•
Cold Start—Enables cold start trap.
Enables alarm traps:
•
Raise Critical—Enables raise-critical alarm trap.
•
Clear Critical—Enables clear-critical alarm trap.
•
Raise Major—Enables raise-major alarm trap.
•
Clear Major—Enables clear-major alarm trap.
•
Raise Minor—Enables raise-minor alarm trap.
•
Clear Minor—Enables clear-minor alarm trap.
Entity
Enables SNMP entity traps.
Config
Enables CiscoConfigManEvent error traps.
Miscellaneous Settings
Notify Inform
Step 3
Enables the SNMP notify inform request.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Step 4
From the left-panel menu, click Community. The SNMP Community Table page is displayed.
The table is sortable by clicking the column headings. The maximum number of community strings that
can be created is ten.
Step 5
Click the Create New icon in the task bar. The SNMP Community page is displayed.
Click the Edit icon next to the community name to edit a community setting.
Note
Step 6
Each community is associated with a group. Each group has a view and users are assigned to a
group. If the group does not have a view associated with it, then users associated that group
cannot access any MIB entry.
Enter the settings as appropriate. See Table 4-44 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-92
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-44
Field
Description
Community
Community string used as a password for authentication when you access the
SNMP agent of the device using SNMPv1 or SNMPv2. The “Community Name”
field of any SNMP message sent to the device must match the community string
defined here to be authenticated. You can enter a maximum of 64 characters in this
field.
Group name/rw
Group to which the community string belongs. The Read/Write option allows a
read or write group to be associated with this community string. The Read/Write
option permits access to only a portion of the MIB subtree. Choose one of the
following three options from the drop-down list:
Group Name
Step 7
SNMP Community Fields
•
None—Choose this option if you do not want to specify a group name to be
associated with the community string.
•
Read/Write—Choose this option if you want to allow read-write access to the
group associated with this community string.
•
Group—Choose this option if you want to specify a group name.
Name of the group to which the community string belongs. You can enter a
maximum of 64 characters in this field. This field is available only if you have
chosen the Group option in the Group name/rw field.
Click Submit to save the settings.
To delete an SNMP community, click the Edit icon for the community, then click the Delete icon in the
task bar.
Step 8
From the left-panel menu, click Group. The SNMP Group Table page is displayed.
The table is sortable by clicking the column headings. The maximum number of groups that can be
created is ten.
Step 9
Click the Create New icon in the task bar. The SNMP Group page is displayed.
Click the Edit icon next to the Group Name to edit a group.
Step 10
Enter the settings as appropriate. See Table 4-45 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-93
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-45
SNMP Group Fields
Field
Description
Name
Name of the SNMP group. You can enter a maximum of 256 characters.
A group defines a set of users belonging to a particular security model. A group
defines the access rights for all the users belonging to it. Access rights define what
SNMP objects can be read, written to, or created. In addition, the group defines
what notifications a user is allowed to receive.
An SNMP group is a collection of SNMP users that belong to a common SNMP
list that defines an access policy, in which object identification numbers (OIDs) are
both read-accessible and write-accessible. Users belonging to a particular SNMP
group inherit all of the attributes defined by the group.
Sec Model
Security model for the group. Choose one of the following options from the
drop-down list:
•
v1—Version 1 security model (SNMP Version 1 [noAuthNoPriv]).
•
v2c—Version 2c security model (SNMP Version 2 [noAuthNoPriv]).
•
v3-auth—User security level SNMP Version 3 (AuthNoPriv).
•
v3-noauth—User security level SNMP Version 3 (noAuthNoPriv).
•
v3-priv— User security level SNMP Version 3 (AuthPriv).
The Sec Model you choose determines which of the following three security
algorithms is used on each SNMP packet:
Read View
•
noAuthNoPriv—Authenticates a packet by a string match of the username.
•
AuthNoPriv—Authenticates a packet by using either the HMAC MD5 or SHA
algorithms.
•
AuthPriv—Authenticates a packet by using either the HMAC MD5 or SHA
algorithms and encrypts the packet using the CBC-DES (DES-56) algorithm.
Name of the view (a maximum of 64 characters) that enables you only to view the
contents of the agent. By default, no view is defined. To provide read access to
users of the group, a view must be specified.
A read view defines the list of object identifiers (OIDs) that are accessible for
reading by users belonging to the group.
Write View
Name of the view (a maximum of 64 characters) that enables you to enter data and
configure the contents of the agent. By default, no view is defined.
A write view defines the list of object identifiers (OIDs) that are able to be created
or modified by users of the group.
Notify View
Name of the view (a maximum of 64 characters) that enables you to specify a
notify, inform, or trap. By default, no view is defined.
A notify view defines the list of notifications that can be sent to each user in the
group.
Step 11
Click Submit to save the settings.
To delete an SNMP group, click the Edit icon for the group, then click the Delete icon in the task bar.
Step 12
From the left-panel menu, click User. The SNMP User Table page is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-94
Chapter 4
Configuring Devices
Configuring the Service Engine
The table is sortable by clicking the column headings. The maximum number of users that can be created
is ten.
Step 13
Click the Create New icon in the task bar. The SNMP User page is displayed.
Click the Edit icon next to the username to edit a user.
Step 14
Enter the settings as appropriate. See Table 4-46 for a description of the fields.
Table 4-46
SNMP User Fields
Field
Description
Name
String representing the name of the user (256 characters maximum) who can access
the device.
An SNMP user is a person for which an SNMP management operation is
performed.
Group
Name of the group (256 characters maximum) to which the user belongs.
Remote SNMP ID Globally unique identifier for a remote SNMP entity. To send an SNMPv3 message
to the device, at least one user with a remote SNMP ID must be configured on the
device. The SNMP ID must be entered in octet string format. For example, if the
IP address of a remote SNMP entity is 192.147.142.129, then the octet string
would be 00:00:63:00:00:00:a1:c0:93:8e:81.
Authentication
Algorithm
Authentication
Password
Authentication algorithm that ensures the integrity of SNMP packets during
transmission. Choose one of the following three options from the drop-down list:
•
No-auth—Requires no security mechanism to be turned on for SNMP
packets.
•
MD5—Provides authentication based on the hash-based Message
Authentication Code Message Digest 5 (HMAC-MD5) algorithm.
•
SHA—Provides authentication based on the hash-based Message
Authentication Code Secure Hash (HMAC-SHA) algorithm.
String (256 characters maximum) that configures the user authentication
(HMAC-MD5 or HMAC-SHA) password. The number of characters is adjusted to
fit the display area if it exceeds the limit for display.
This field is optional if the no-auth option is chosen for the authentication
algorithm. Otherwise, this field must contain a value.
Step 15
Confirmation
Password
Authentication password for confirmation. The re-entered password must be the
same as the one entered in the Authentication Password field.
Private Password
String (256 characters maximum) that configures the authentication (HMAC-MD5
or HMAC-SHA) parameters to enable the SNMP agent to receive packets from the
SNMP host. The number of characters is adjusted to fit the display area if it
exceeds the limit for display.
Confirmation
Password
Private password for confirmation. The re-entered password must be the same as
the one entered in the Private Password field.
Click Submit to save the settings.
To delete an SNMP user, click the Edit icon for the user, then click the Delete icon in the task bar.
Step 16
To define a SNMPv2 MIB view, click View from the left-panel menu. The SNMP View Table page is
displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-95
Chapter 4
Configuring Devices
Configuring the Service Engine
The table is sortable by clicking the column headings. The maximum number of SNMPv2 views that can
be created is ten.
SNMP view—A mapping between SNMP objects and the access rights available for those objects. An
object can have different access rights in each view. Access rights indicate whether the object is
accessible by either a community string or a user.
Step 17
Click the Create New icon in the task bar. The SNMP View page is displayed.
Click the Edit icon next to the username to edit a view.
Step 18
Enter the settings as appropriate. See Table 4-47 for a description of the fields.
Table 4-47
SNMP View Fields
Field
Description
Name
String representing the name of this family of view subtrees (256 characters
maximum). The family name must be a valid MIB name such as ENTITY-MIB.
Family
Object identifier (256 characters maximum) that identifies a subtree of the MIB.
View Type
View option that determines the inclusion or exclusion of the MIB family from the
view. Choose one of the following two options from the drop-down list:
•
Included—The MIB family is included in the view.
•
Excluded—The MIB family is excluded from the view.
Note
Step 19
When configuring an SNMP View with Excluded, the specified MIB that
is excluded is not accessible for the community associated with the group
that has that view.
Click Submit to save the settings.
To delete an SNMP view, click the Edit icon for the view, then click the Delete icon in the task bar.
Step 20
From the left-panel menu, click Host. The SNMP Host Table page is displayed.
The table is sortable by clicking the column headings. The maximum number of hosts that can be created
is four.
Step 21
Click the Create New icon in the task bar. The SNMP Host page is displayed.
Click the Edit icon next to the hostname to edit a host.
Step 22
Enter the settings as appropriate. See Table 4-48 for a description of the fields.
Table 4-48
SNMP Host Fields
Field
Description
Trap Host
Hostname or IP address an SNMP entity to which notifications (traps and informs)
are to be sent.
Community/User
Name of the SNMP community or user (256 characters maximum) that is sent in
SNMP trap messages from the device.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-96
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-48
Step 23
SNMP Host Fields (continued)
Field
Description
Authentication
Security model to use for sending notification to the recipient of an SNMP trap
operation. Choose one of the following options from the drop-down list:
•
No-auth—Sends notification without any security mechanism.
•
v2c—Sends notification using Version 2c security.
•
Model v3-auth—Sends notification using SNMP Version 3 (AuthNoPriv).
•
Security Level v3-noauth—Sends notification using SNMP Version 3
(NoAuthNoPriv security).
•
Level v3-priv—Sends notification using SNMP Version 3 (AuthPriv
security).
Retry
Number of retries (1 to 10) allowed for the inform request. The default is 2.
Timeout
Timeout for the inform request in seconds (1 to 1000). The default is 15.
Click Submit to save the settings.
To delete an SNMP host, click the Edit icon for the host, then click the Delete icon in the task bar.
Step 24
From the left-panel menu, click Asset Tag. The SNMP Asset Tag page is displayed.
Step 25
In the Asset Tag Name field, enter a name for the asset tag and click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Step 26
From the left-panel menu, click Contact. The SNMP Contact page is displayed.
Step 27
In the Contact field, enter a name of the contact person for this device.
Step 28
In the Location field, enter a location of the contact person for this device.
Step 29
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Supported MIBs
The SNMP agent supports the following MIBs:
•
ENTITY-MIB (RFC 2037 Revision 199610310000Z))
•
MIB-II (RFC 1213)
•
HOST-RESOURCES-MIB (RFC 2790, hrSWInstalled and hrPrinterTable subgroups are not
supported)
•
BGP-4-MIB (RFC-4274)
•
UCD-SNMP-MIB
•
CISCO-ENTITY-ASSET-MIB
•
CISCO-CONFIG-MAN-MIB (Revision 9511280000Z)
•
CISCO-SERVICE-ENGINE-MIB (supports streaming media-related MIB objects)
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-97
Chapter 4
Configuring Devices
Configuring the Service Engine
ENTITY-MIB, MIB-II, HOST-RESOURCES-MIB, BGP-4-MIB, and UCD-SNMP-MIB are
public-available MIBs.
To download a copy of the CISCO-SERVICE-ENGINE-MIB, do the following:
Step 1
Choose System > CDS-IS Files > SNMP MIB. The CISCO_SERVICE-ENGINE-MIB.my is listed.
Step 2
Click one of the following links;
•
CISCO_SERVICE-ENGINE-MIB.my
•
CISCO_CDS_SERVICE_ROUTING_MIB.my
Your browser program displays a dialog box asking if you want to open or save the file.
Step 3
Choose the appropriate option; either open or save the file.
The CISCO-SERVICE-ENGINE-MIB is extended to incorporate MIB objects related to streaming. The
WMT and Movie Streamer groups incorporate statistics about the WMT server or proxy, and Movie
Streamer. The Flash Media Streaming group incorporates statistics about the Flash Media Streaming
protocol engine. For each 64-bit counter MIB object, a 32-bit counter MIB object is implemented so that
SNMP clients using SNMPv1 can retrieve data associated with 64-bit counter MIB objects. The MIB
objects of each of these groups are read-only.
•
WMT MIB group provides statistics about WMT proxy and server performance. Twenty-eight MIB
objects are implemented in this group. Six of these MIB objects are implemented as 64-bit counters.
•
Movie Streamer MIB group provides statistics about RTSP streaming engine performance. Seven
MIB objects are implemented in this group. Two of these MIB objects are implemented as 64-bit
counters.
•
Flash Media Streaming MIB group provides statistics about HTTP and RTMP streaming engine
performance.
The CISCO_CDS_SERVICE_ROUTING_MIB.my provides some object identifiers (OIDs) for Service
Router statistics. All the OIDs in the MIB are only for querying purposes; no traps have been added to
this MIB. The Service Router MIB provides two groups, cdssrStatsGroup and
cdssrServiceMonitorGroup, which contain OIDs for the statistics from the show statistics
service-router summary/dns/history/se/content-origin command and the show service-router
service-monitor command.
Use the following link to access the CISCO-ENTITY-ASSET-MIB and the
CISCO-CONFIG-MAN-MIB:
ftp://ftp.cisco.com/pub/mibs/v2/
Note
If your browser is located behind a firewall or you are connecting to the Internet with a DSL modem and
you are unable to access this file folder, you must change your web browser compatibility settings. In
the Internet Explorer (IE) web browser, choose Tools > Internet Options > Advanced, and check the
Use Passive FTP check box.
Enabling System Logs
Use the System Logs page to set specific parameters for the system log file (syslog). This file contains
authentication entries, privilege level settings, and administrative details. System logging is always
enabled. By default, the system log file is stored as /local1/syslog.txt.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-98
Chapter 4
Configuring Devices
Configuring the Service Engine
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable system logging, do the following:
Step 1
Choose Devices > Devices > General Settings > Notification and Tracking > System Logs. The
System Log Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-49 for a description of the fields.
Table 4-49
Field
System Logs Settings Fields
Description
System Logs
Enable
Enables system logs.
Facility
Facility where the system log is sent.
Console Settings
Enable
Enable sending the system log to the console.
Priority
Severity level of the message that should be sent to the specified remote syslog
host. The default priority is warning. The priorities are:
Emergency—System is unusable.
Alert—Immediate action needed.
Critical—Critical condition.
Error—Error conditions.
Warning—Warning conditions.
Notice—Normal but significant conditions.
Information—Informational messages.
Debug—Debugging messages.
Disk Settings
Enable
Enables saving the system logs to disk.
File Name
Path and filename where the system log file is stored on the disk. The default is
/local1/syslog.txt.
Priority
Severity level of the message that should be sent to the specified remote syslog
host.
Recycle
The maximum size of the system log file before it is recycled. The default is
10000000 bytes.
Host Settings
Enable
Enables sending the system log file to a host. You can configure up to four hosts.
Hostname
A hostname or IP address of a remote syslog host.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-99
Chapter 4
Configuring Devices
Configuring the Service Engine
Table 4-49
Step 3
System Logs Settings Fields (continued)
Field
Description
Priority
Severity level of the message that should be sent to the specified remote syslog
host.
Port
The destination port on the remote host. The default is 514.
Rate Limit
The message rate per second. To limit bandwidth and other resource consumption,
messages can be rate limited. If this limit is exceeded, the remote host drops the
messages. There is no default rate limit, and by default all system log messages are
sent to all syslog hosts.
Click Submit to save the settings.
Multiple Hosts for System Logging
Each syslog host can receive different priority levels of syslog messages. Therefore, you can configure
different syslog hosts with a different syslog message priority code to enable the device to send varying
levels of syslog messages to the four external syslog hosts.
However, if you want to achieve syslog host redundancy or failover to a different syslog host, you must
configure multiple syslog hosts on the device and assign the same priority code to each configured syslog
host.
Configuring Troubleshooting
The Kernel Debugger troubleshooting page allows you to enable or disable access to the kernel debugger.
Once enabled, the kernel debugger is automatically activated when kernel problems occur.
Note
The “hardware watchdog” is enabled by default and automatically reboots a device that has stopped
responding for over ten minutes. Enabling the kernel debugger disables the “hardware watchdog.”
If the device runs out of memory and kernel debugger (KDB) is enabled, the KDB is activated and dump
information. If the KDB is disabled and the device runs out of memory, the syslog reports only dump
information and reboots the device.
Enabling the Kernel Debugger
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To enable the kernel debugger, do the following:
Step 1
Choose Devices > Devices > General Settings > Troubleshooting > Kernel Debugger. The Kernel
Debugger window appears.
Step 2
To enable the kernel debugger, check the Enable check box, and click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-100
Chapter 4
Configuring Devices
Configuring the Service Router
To remove the settings from the device, click the Remove Settings icon in the task bar.
For information about monitoring the SEs, see the “Device Monitoring” section on page 7-12.
Configuring Service Router Settings
The keep-alive interval is used by the SE to send keep-alive messages to the SR. If the SE is configured
with more than one streaming interface (multi-port support on a CDE220-2S3i), the keepalives are sent
for each streaming interface.
For information on configuring device groups, see the “Configuring Device Groups” section on
page 4-4.
To configure the keep-alive interval the SE uses for messages to this SR, do the following:
Step 1
Choose Devices > Devices > General Settings > Service Routing Settings. The Service Routing
Settings page is displayed.
Step 2
In the Keepalive-Interval field, enter the number of seconds the messages from the SR should be kept
alive on this SE. The range is from 1 to 120. The default is 2 seconds.
Step 3
In the Snapshot Counter Report Interval field, enter the report interval for the wholesale snapshot
counter report. The range is from 5 to 180. The default is 10 seconds.
Step 4
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring the Service Router
Configuring a Service Router (SR) consists of the following procedures: covered in this section, except
for most of the General Settings which are covered in a separate section.
•
Activating a Service Router
•
Configuring Routing Settings
•
Configuring Application Control
•
Configuring Load Monitoring
•
Configuring Last-Resort Routing
•
Configuring Domain Subscription
•
Configuring Transaction Logs for the Service Router
For information on configuring the general settings, except last-resort routing and transaction logging,
see the “General Settings” section on page 4-48.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-101
Chapter 4
Configuring Devices
Configuring the Service Router
Activating a Service Router
Activating a Service Router
Activating an SR can be done through the Devices home page initially, or through the Device Activation
page.
To activate an SR from the Device Activation page, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the SR you want to configure. The Devices home page is displayed.
Step 3
Click Show All to display the top-level menu options, and choose Device Activation. The Device
Activation page is displayed.
Step 4
Enter the settings as appropriate. See Table 4-50 for a description of the fields.
Table 4-50
Service Router Activation Fields
Field
Description
Name
Name of the device.
Location
The Location drop-down list lists all the location configured for the CDS.
Activate
To activate or deactivate the device, check or uncheck the Activate check
box. Alternatively, you can click the Deactivate Device icon in the task
bar.
When you uncheck the Activate check box and click Submit, the
Replaceable check box is displayed. Check the Replaceable check box
when you need to replace the device or recover lost registration
information. For more information, see the “Recovering CDS Network
Device Registration Information” section on page 8-25.“Recovering CDS
Network Device Registration Information” section on page 8-28
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-102
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-50
Service Router Activation Fields (continued)
Field
Description
Server Offload
To offload this device for maintenance or a software upgrade, check the
Server Offload check box. When checked, the Service Router stops
processing client requests.
When the SR is marked as inactive or is marked with server offload on the
CDSM it stops responding to DNS queries. Instead, the SR sends a
SERVFAIL error as the DNS response, and for RTSP/HTTP requests, the
SR sends a 503 Service Unavailable message.
To monitor the current activity on an SR during the Server Offload state,
use the show interface command. If the packets received or packets sent
is increasing then the SR is processing client requests.
Note
We recommend separating the management traffic from the client
request traffic by using the port channel configuration, see the
“Configuring Port Channel” section on page J-6“Configuring Port
Channel” section on page J-6 for more information.
•
If management and client request traffic are separated, the show
interface command for the client request port channel displays
information on active sessions.
•
If management and streaming traffic are not separated, the show
interface command shows very low traffic; the packets received and
packets sent are lower than a client request session.
Once the SR has finished processing client requests, you can perform
maintenance or upgrade the software on the device. For information about
upgrading the software, see the “Upgrading the Software” section on
page 8-6“Upgrading the Software” section on page 8-6.
The Status field on the Device Activation page and the Devices Table page
displays “offloading” when Server Offload is checked.
Once the software upgrade or maintenance is complete, you need to
uncheck the Server Offload check box so that the device can again
participate in the system.
Work Type
From the Work Type drop-down list, choose SR & Proximity Engine if
you want to enable the Proximity Engine; otherwise, choose Service
Router only. For more information, see the “Configuring the Proximity
Server Settings” section on page 4-110“Configuring the Proximity Server
Settings” section on page 4-110.
Coverage Zone File
To have a local Coverage Zone file overwrite the CDS network-wide
Coverage Zone file, choose a file from the Coverage Zone drop-down list.
See the “Coverage Zone File Registration” section on
page 6-12“Coverage Zone File Registration” section on page 6-12 for
information about creating and registering a Coverage Zone file.
Otherwise, choose None.
Enable CDN Selector
To enable CDN Selector, check the Enable CDN Selector check box.
Note
CDN Selector is an early field trial (EFT) feature.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-103
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-50
Service Router Activation Fields (continued)
Field
Description
CDN Selector File
The CDN Selector File drop-down list is populated with the CDN
Selector files that are registered to the CDSM. See the “CDN Selector File
Registration” section on page 6-14“CDN Selector File Registration”
section on page 6-14 for information on registering a CDN Selector file.
The CDN Selector must be enabled on the SR.
See Appendix E, “Creating CDN Selector Files” for information on
creating a CDN Selector file.
Note
Use SR’s primary IP
address
CDN Selector is an EFT feature.
Enables the CDSM to use the IP address on the primary interface of the
SR for management communications.
Note
If the Use SR’s primary IP Address for Management
Communication check box is checked and the Management
Communication Address and Port are configured, the CDSM uses
the SR’s primary IP address for communication.
Note
Do not check the Use SR’s primary IP Address for
Management Communication check box if you want to separate
management and streaming traffic. Instead, use the Management
Communication Address and Port fields to specify where
management traffic should be sent.
Management
Manually configures a management IP address for the CDSM to
Communication Address communicate with the SR.
Manual configuration of the management IP address and port are used
when using port channel configuration to separate management and
streaming traffic. For more information about port channel configuration
see the “Configuring Port Channel and Load Balancing Settings” section
on page 4-71 and the “Configuring Port Channel” section on
page J-6“Configuring Port Channel” section on page J-6.
Management
Communication Port
Port number to enable communication between the CDSM and the SR.
Comments
Information about the settings.
Note
Step 5
To make sure the SR is binding to the primary interface (or management IP address if
configured) as the source IP address when sending management traffic to the CDSM, create a
static route from the SR to the CDSM. To configure a static IPv4 route from the SR, see the
“Configuring Static IPv4 Routes” section on page 4-81 section. To configure a static IPv6 route
from the SR, see the “Configuring Static IPv6 Routes” section on page 4-82 section.
Alternatively, you can use the ip route command and ipv6 route command on the CDS device.
Click Submit to save the settings.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-104
Chapter 4
Configuring Devices
Configuring the Service Router
Configuring Routing Settings
Configuring Routing Settings
The Routing Settings pages provide settings for the Request Routing Engine and the Proximity Engine.
Configuring the Service Router engines consists of the following procedures:
•
Configuring Request Routing Settings
•
Configuring IP-Based Redirection
•
Configuring Redirect Burst Control
•
Configuring Cross-Domain Policy
•
Configuring the Proximity Server Settings
The Service Router has two engines, the Request Routing Engine and the Proximity Engine.
The Proximity Engine contains the functionality of the Proximity Servers used for proximity-based
routing. For more information, see the “Service Router” section on page 1-32.
Configuring Request Routing Settings
Configuring Request Routing Settings
To configure the Request Routing Settings, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Request Routing Settings > General Settings. The
Request Routing Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-51 for a description of the fields.
Table 4-51
Request Routing Settings—General Settings Fields
Field
Description
Enable Location
Based Routing
When location-based routing is enabled, the Service Router first looks up the
client’s IP address in the Coverage Zone file. If there is no subnet in the Coverage
Zone file that matches the client’s IP address, the client’s geographical location is
compared to the geographical location of the Service Engines listed in the
Coverage Zone file, and the closest and least-loaded Service Engine is selected.
Geographically locating a client is used when users roam outside of their home
networks.
Location Cache
Timeout
Enter the timeout interval (in seconds) that a response from the Geo-Location
server is stored in the SR cache.
The SR caches information from the Geo-Location server during the first request
so that further requests can be served from cache instead of contacting the
Geo-Location server.
The default is 691200. The range is 0 to 864000. If the Location Cache Timeout
is 0, the response from the Geo-Location server is not cached in the SR.
The IP address and port number of the primary Geo-Location Server for
Primary
location-based routing and CDN Selector. For more information, see the
Geo-Location
Server IP Address “Geo-Location Servers” section on page 4-107.
and Port
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-105
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-51
Request Routing Settings—General Settings Fields (continued)
Field
Description
The IP address and port number of the secondary Geo-Location Server.
Secondary
Geo-Location
Server IP Address
and Port
Enable Content
Based Routing
When enabled, the SR redirects requests based on the URI. Requests for the same
URI are redirected to the same SE, provided the SE’s thresholds have not been
exceeded. This optimizes disk usage in the CDS by storing only one copy of the
content on one SE, instead of multiple copies on several SEs. For more information
about content-based routing, see the “Content-Based Routing” section on
page 1-43.
Note
Content-based routing does not work with clients sending signed URL
requests. The hashing algorithm for content-based routing considers the
whole signed URl, so a signed URL request for the same content may be
redirected to a different SE.
Number of
Number of copies of a content to keep among SEs in a delivery service. The range
Redundant Copies is from 1 to 4. The default is 1. If redundancy is configured with more than one
copy, multiple Service Engines are picked for a request with the same URI hash.
Enable Proximity
Based Routing
When enabled, the SR contacts the Proximity Server with the client IP address and
a list of SEs. The Proximity Server returns a list of SEs ordered by distance or
metric, and provides a client subnet mask. The SR caches this information for this
client. The SR redirects the client request to the SE selected, which is based on
load, availability, and delivery service subscription.
To configure a standalone Proximity Engine, see the Cisco Internet Streamer CDS
3.2 Command Reference.
To configure a collocated Proximity Engine, see the “Configuring the Proximity
Server Settings” section on page 4-110“Configuring the Proximity Server
Settings” section on page 4-110,
For more information, see the “Proximity-Based Routing” section on page 1-40.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-106
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-51
Request Routing Settings—General Settings Fields (continued)
Field
Description
Proximity Cache
Timeout
The maximum number of seconds the proximity response from the Proximity
Server is valid for a client subnet. After the Proximity Cache Timeout period has
elapsed, any new request from the same client subnet causes the SR to query the
Proximity server for a new proximity response. The proximity range is from 1 to
86400. The default is 1800.
Proximity ratings for overlapping subnets are not cached.
Proximity Server
Host [1-8]
The IP address of the Proximity Server. If you are using the collocated Proximity
Engine as one of the Proximity Servers, enter 127.0.0.1 as the IP address.
Password
The selection of the Proximity Server is based on the lowest IP address. If there is
only one Proximity Server, the SR uses that server. If another Proximity Server is
configured with an IP address lower than the first one, the SR sends a request to
the newly configured Proximity Server, and if it responds, the SR uses the new
Proximity Server with the lower IP address.
Password of the Proximity Server.
For more information on configuring the Proximity Engine, see the “Configuring
the Proximity Server Settings” section on page 4-110“Configuring the Proximity
Server Settings” section on page 4-110,
Step 3
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Geo-Location Servers
The Geo-Location servers work with the following Internet Streamer CDS features:
•
Location-based routing
•
CDN Selector
•
Authorization Service
For location-based routing, the Geo-Location servers identifies the latitude and longitude of a client
based on the IP address of the client. The Request Routing Engine compares the latitude and longitude
of each Service Engine, which is defined in the Coverage Zone file, with the latitude and longitude of
the client to assign a Service Engine that is geographically closest to the client. For more information on
location-based routing, see the “Location-Based Routing” section on page 1-40 and Appendix C,
“Creating Coverage Zone Files.”
For CDN Selector, the Geo-Location server identifies the country of a client by the IP address of the
client. The CDN Selector compares the client’s country with the countries defined in the CDN Selector
file. If the client’s country matches a country specified in the CDN Selector file, then the translated URL
associated with that CDN is used. If a match is not found, the default CDN and translated URL is used.
The Service Router then sends a 307 redirect to the client with the translated URL for the selected
third-party streaming service. For more information about CDN Selector, see Appendix E, “Creating
CDN Selector Files.”
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-107
Chapter 4
Configuring Devices
Configuring the Service Router
For Authorization Service, the Geo-Location servers identify the city, state, and country of the client
based on the IP address of the client. The Authorization Service on the Service Engine compares the city,
state, and country of the client with city, state, and country defined in the Authorization Service file. If
a match is found, the client is either allowed or denied based on what is specified in the Authorization
Service file. For more information about configuring the Authorization Service, see the “Configuring the
Authorization Service” section on page 4-29“Configuring the Authorization Service” section on
page 4-29.
Caching Geo-Location Server Information
The SR or SE caches the Geo-Location information returned from the Geo-Location servers and the
device (SE or SR) queries their own cache first before contacting the Geo-Location servers. If the IP
address of the client is found in the cache on the device, the look-up is performed using that information
and the Geo-Location servers are not contacted.
For location-based routing, the SR caches up to 10,000 IP addresses. The IP addresses are discrete,
which means they do not describe subnets. By default, the cached information expires after 8 days
(691200 seconds). The time interval that the cache expires is configurable by setting the Location Cache
Timeout field. If the cache is full, the entries are replaced according to the least recently used (LRU)
mechanism.
For CDN Selector, the SR caches information on the country, state, and city of 10,000 clients. The
cached information expires after 8 days. If the cache is full, the entries are replaced according to LRU
mechanism.
For Authorization Service, the SE caches information on the country of 10,000 clients. The cached
information expires after 8 days. If the cache is full, the entries are replaced according to the LRU
mechanism.
Note
Currently, there is no command to clear the Geo-location cache on the device.
Redundant Geo-Location Servers
The CDS offers the ability to configure primary and secondary Geo-Location servers. In the possible
event that the primary server is not reachable, the secondary Geo-Location server is contacted. The
secondary Geo-Location server is then used unless it becomes unreachable, in which case the primary
Geo-Location server is contacted. The Geo-Location server configuration determines the time to wait
before failing over to the other server. The default is 245 milliseconds.
For all features, location-based routing, CDN Selector, and Authorization Service, the cached client
information on the CDS device is checked first before querying the Geo-Location servers.
For location-based routing, if both primary and secondary Geo-Location servers are down, the CDS uses
the default route configured through the zero-IP based configuration in the Coverage Zone file. For more
information, see the “Zero-IP Based Configuration” section on page C-2“Zero-IP Based Configuration”
section on page C-2.
For CDN Selector, if both primary and secondary Geo-Location servers are down, the CDS uses the
default CDN configured in the CDN Selector file.
For Authorization Service, if both the primary and secondary Geo-Location servers are down, a request
denied message is returned to the client. The type of message that is returned depends on the protocol
engine (for example, the Flash Media Streaming engine sends “Denied by auth server”). However, the
client receives the same denied message from the protocol engine whether the client is denied based on
the Authorization Service configuration, or based on the Geo-Location servers being down and the client
information not being available in the SE cache.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-108
Chapter 4
Configuring Devices
Configuring the Service Router
Communicating with the Geo-Location Servers
The CDS communicates with the Geo-Location servers by using a proprietary version of TCP. The port
number used for communication is 7000 by default, but it can be changed as long as the Geo-Location
servers and the Internet Streamer CDS devices are configured with the same port number.
Configuring IP-Based Redirection
Configuring IP-Based Redirection
IP-based redirection uses IP addresses to route client requests to the SR and on to the SE. For more
information, see the “IP-Based Redirection” section on page 1-36.
Note
The Web Engine does not support IP-based redirection.
To enable IP-based redirection, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Request Routing Settings > IP-Based Redirection.
The IP-Based Redirection page is displayed.
Step 2
Check the Enable IP-based Redirection check box and click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring Redirect Burst Control
Configuring Redirect Burst Control
The SR learns about the state of the SEs through the keep-alive messages between the SEs and the SR.
The keep-alive messages occur every two seconds. If a burst of client requests occurs between two
keep-alive messages, the SR may not know about the current state of the SE, and might route a request
to an already overloaded SE. This scenario can happen during mixed traffic, because each protocol
engine has different memory and CPU requirements.
The Redirect Burst Control page allows you to configure how many requests (transactions per second
[TPS]) the SR should redirect to an SE during a burst.
To configure the redirect burst control, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Request Routing Settings > Redirect Burst Control.
The Redirect Burst Control page is displayed.
Step 2
Check the Enable Redirect Burst Control check box. The Redirect Burst Control is disabled by default.
Step 3
In the Rate field, enter the maximum TPS the SR can send to an SE. The default is 100000. The range
is from 1 to 100000.
Step 4
Click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-109
Chapter 4
Configuring Devices
Configuring the Service Router
Configuring Cross-Domain Policy
Configuring Cross-Domain Policy
The Access Policy page allows you to enable the Cross-Domain Policy feature on the SR. For more
information, see the “Cross-Domain Policy” section on page 1-45.
To enable the cross-domain policy, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Request Routing Settings > Access Policy. The
Access Policy page is displayed.
Step 2
Check the Enable Access Policy check box and click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Configuring the Proximity Server Settings
Configuring the Proximity Server Settings
The Proximity Server Settings are available when you choose the SR & Proximity Engine as the Work
Type in the Device Activation page for the SR. See the “Activating a Service Router” section on
page 4-102“Activating a Service Router” section on page 4-102 for more information. The Proximity
Server Settings pages are only for a Proximity Engine that is collocated with the SR. To configure a
standalone Proximity Engine, see the Cisco Internet Streamer CDS 3.2 Command Reference.
To include the Proximity Engine on the SR as one of the Proximity Servers, you must enable
proximity-based routing and add 127.0.0.1 as one of the Proximity Servers. See the “Configuring
Request Routing Settings” section on page 4-105“Configuring Request Routing Settings” section on
page 4-105 for more information.
Note
The Proximity Engine is only supported on the CDE205 platform.
For more information on the Proximity Engine, see the “Proximity Engine” section on page 1-46.
The Proximity Server Settings for the Proximity Engine consists of the following pages:
•
General Settings—Enables the BGP proximity algorithms
•
IS-IS—Configures IS-IS adjacencies
•
OSPF—Configures the OSPF adjacencies
•
BGP—Configures the location community for the BGP community-based proximity
•
SRP—Configures Service Routing Protocol (SRP)
IGP and BGP protocol peering with the network routers are the basic building blocks for the proximity
calculation. The peering with the routers is to learn the network topology and compute the best path for
each prefix. Prefixes are deposited to the routing information base (RIB).
Note
Although the Proximity Engine participates in both IGP and BGP with the routers, the routes that the
Proximity Engine learns are purely for proximity computation only. Proximity Engine is not a router.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-110
Chapter 4
Configuring Devices
Configuring the Service Router
In order for the proximity function to work, at least one of the following is required:
•
Enabled link-state protocol, such as OSPF or IS-IS for IGP proximity, which is required if the
Proximity Engine is going to peer with IGP routers.
•
Enabled policy routing protocol, such as BGP for best-path proximity and location-community
proximity, which is required if the Proximity Engine is going to peer with BGP routers.
Note
All BGP routes must resolve to IGP next hops or directly connected routes.
Note
Only one IGP (IS-IS or OSPF) is supported for the Proximity Engine.
Enabling the BGP Proximity Algorithms
Enabling the BGP Proximity Algorithms
See the “BGP Proximity Algorithms” section on page 1-48 for more information.
To enable the BGP community-based proximity, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Proximity Server Settings > General Settings. The
Proximity Routing General Settings page is displayed.
Step 2
To enable the BGP best-path proximity, check the Enable proximity algorithm BGP best-path check
box.
Note
Step 3
The BGP best-path proximity algorithm requires the configuration of the BGP proximity
settings. See the “Configuring the BGP Community-based Proximity Settings” section on
page 4-118“Configuring the BGP Community-Based Proximity Settings” section on
page 4-118.
To enable the BGP community-based proximity, check the Enable proximity algorithm BGP
location-community check box, and from the Match mode drop-down list, select either Normal or
Strict.
The Strict option instructs the Proximity Engine to return UINT-MAX as the proximity rating for PTAs
that are not associated with the PSA by way of any location-community attribute. This setting is global
and applies to all proximity requests. If PSA is BGP and has no community attributes, then all PTAs get
UINT_MAX rating. If the PSA is IGP, then this setting does not apply and other proximity algorithms,
BGP best-path and IGP metric, are used to rate the PTAs in the proximity request.
The Normal option retains the normal functioning of the BGP proximity algorithm.
Step 4
To enable the BGP redirect proximity, check the Enable proximity algorithm BGP redirect check box.
Note
Step 5
The redirect proximity algorithm requires the configuration of the BGP and the SRP proximity
settings. See the “Configuring the BGP Community-based Proximity Settings” section on
page 4-118“Configuring the BGP Community-Based Proximity Settings” section on page 4-118
and the “Configuring SRP” section on page 4-121“Configuring SRP” section on page 4-121 for
more information.
Click Submit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-111
Chapter 4
Configuring Devices
Configuring the Service Router
To remove the settings, click the Delete icon.
To restore the default settings, click the default settings icon.
Configuring the IS-IS Adjacencies
Configuring the IS-IS Adjacencies
The Proximity IS-IS page allows the Proximity Engine to establish an adjacency with its directly
connected neighbor and to receive the whole LSDB content. Protocol parameters, such as IS-type and
IS network entity title (NET), vary according to network topology and deployment.
IS-IS is a link-state routing protocol for IGP. Its protocol stack runs directly on Layer 2. The main
characteristic of the link-state protocols is that every node in the network contains an exact view of the
routing topology. It has faster convergence than vector distance protocols. Each node in the network
generates a Link State Packet (LSP) to describe its neighbors. The LSP is flooded throughout the
network to every node. Reliability of the flooding is obtained by Complete Sequence Number Packet
(CSNP) which is sent by the Designator Router (DR) periodically in the LAN. CSNP describes all the
LSPs that the DR contains. The receiver of the CSNP can compare what it has against what is listed in
the CSNP and requests the missing LSPs from the DR. Each node uses Dijkstra’s algorithm (shortest
path first [SPF]) to compute the routes from the LSPs. Routes are then added into the routing information
base (RIB).
Note
Only one IGP (IS-IS or OSPF) is supported for the Proximity Engine.
To configure the IS-IS adjacencies, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Proximity Server Settings > IS-IS > General
Settings. The Proximity IS-IS page is displayed.
Step 2
To enable ISIS adjacencies, check the Enable check box and click Submit. The Create new Proximity
IS-IS interface icon displays.
Step 3
Enter the settings as appropriate. See Table 4-52 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-112
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-52
Proximity IS-IS Fields
Field
Description
Network Entity
Enter the Network Entity (network entity title [NET]) for a Connectionless
Network Service (CLNS). Under most circumstances, one and only one NET
must be configured. A NET is a network service access point (NSAP) where
the last byte is always zero and the length can be 8 to 20 bytes. The last byte
is always the n-selector and must be zero.
The six bytes directly in front of the n-selector are the system ID. The system
ID length is a fixed size and cannot be changed. The system ID must be unique
throughout each area (Level 1) and throughout the backbone (Level 2). All
bytes in front of the system ID are the area ID. The area ID must match the
area ID of the IS-IS router that the Proximity Engine is peering with.
A NET must be configured to define the system ID and area ID.
Enable
Check the Enable log-adjacency-changes check box to enable logging of
log-adjacency-changes changes to adjacency. When enabled, syslog messages are sent whenever an
IS-IS neighbor goes up or down.
LSP MTU
Set the maximum transmission unit (MTU) size, in bytes, for link state
packets (LSPs). The LSP MTU size describes the amount of information that
can be recorded in a single LSP. The LSP MTU range is from 128 to 4352. If
the LSP MTU is not configured, the default is used. The default is 1492.
IS-Type
From the IS-Type drop-down list, choose one of the following routing
algorithms:
•
level-1—Level 1 is intra-area. The Proximity Engine learns only about
destinations inside its area.
•
level-1-2—The Proximity Engine runs both Level 1 and Level two
routing algorithms.
For Level 1, it has one link state packet database (LSDB) for destinations
inside the area (Level 1) and runs a shortest path first (SPF) calculation
to discover the area topology.
For Level 2, it also has another LSDB with link-state packets (LSPs) of
all other backbone (Level 2) routers, and runs another SPF calculation to
discover the topology of the backbone, and the existence of all other
areas.
•
level-2—The Proximity Engine communicates with Level 2 (inter-area)
routers only. The Proximity Engine is part of the backbone and does not
communicate with Level 1-only routers in its own area.
The default is level-1-2.
Authentication Type
[Level-1 or Level-2]
From the Authentication Type Level-1 drop-down list or the Authentication
Type Level-2 drop-down list, choose one of the following authentication
types for the corresponding level:
•
None—Do not use MD-5 authentication
•
cleartext—Do not encrypt the key
•
md5—Encrypt the key
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-113
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-52
Proximity IS-IS Fields (continued)
Field
Description
Enable Authentication
Check
To enable authentication check for Level 1, check the Enable Authentication
Check Level-1 check box. To enable authentication check for Level 2, check
the Enable Authentication Check Level-2 check box.
[Level-1 or Level-2]
When enabled, packets that do not have the proper authentication are
discarded. When disabled, IS-IS adds authentication to the outgoing packets,
but does not check authentication on incoming packets, which allows for
enabling authentication without disrupting the network operation.
Authentication
KeyChain
Specify the key chain to be used for the authentication for corresponding
level. The key chain can be up to 64 alphanumeric characters.
[Level 1 or Level-2]
Step 4
Click Submit. The Create new Proximity IS-IS Interface icon displays.
To delete the IS-IS configuration, click the Delete icon.
Step 5
To configure the proximity IS-IS interface, click the Create new Proximity IS-IS Interface icon. The
Proximity IS-IS Interface page is displayed.
Step 6
From the Name drop-down list, choose an interface to configure for IS-IS. The number of available
interfaces depends on the CDE.
Step 7
Enter the settings as appropriate. See Table 4-53 for a description of the fields.
Table 4-53
Proximity IS-IS Interface Fields
Field
Description
Enable IP IS-IS router Check the Enable IP IS-IS router check box to enable IS-IS routing protocol
on this interface.
IS-IS Priority for
level-1
Enter the priority of this interface for IS-IS Level 1(intra-area) priority. The
higher the priority value, the more likely a router becomes the designated
router (DR) in the Level 1 area; therefore, because the Proximity Engine is not
a router, make sure the priority level is such that it will not interfere with the
election of the DR. The IS-IS Priority for level-1 range is from 0 to 127. The
default is 64.
IS-IS Priority for
level-2
Enter the priority of this interface for IS-IS Level 2 (inter-area) priority. The
higher the priority value, the more likely a router becomes the designated
router (DR) in the Level 2 area; therefore, because the Proximity Engine is not
a router, make sure the priority level is such that it will not interfere with the
election of the DR. The IS-IS Priority for level-2 range is from 0 to 127. The
default is 64.
IS-IS Circuit Type
From the IS-IS Circuit Type drop-down list, choose one of the following
adjacency levels:
•
level-1—For Level 1 adjacency
•
level-1-2—For Level 1 and Level 2 adjacency.
•
level-2—For Level 2 adjacency.
The default is level-1-2.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-114
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-53
Proximity IS-IS Interface Fields (continued)
Field
Description
IS-IS Authentication
Type [Level-1 or
Level-2]
From the Authentication Type Level-1 drop-down list or the Authentication
Type Level-2 drop-down list, choose one of the following authentication types
for the corresponding level:
•
None—Do not use MD-5 authentication
•
cleartext—Do not encrypt the key
•
md5—Encrypt the key
To enable authentication check for Level 1, check the Enable Authentication
Enable IS-IS
Authentication Check Check Level-1 check box. To enable authentication check for Level 2, check
the Enable Authentication Check Level-2 check box.
[Level-1 or Level-2]
When enabled, packets that do not have the proper authentication are
discarded. When disabled, IS-IS adds authentication to the outgoing packets,
but does not check authentication on incoming packets, which allows for
enabling authentication without disrupting the network operation.
IS-IS Authentication
KeyChain
Specify the key chain to be used for the authentication for corresponding level.
The key chain can be up to 64 alphanumeric characters.
[Level 1 or Level-2]
Step 8
Click Submit.
To delete an IS-IS interface configuration, click the Edit icon for the interface, then click the Delete icon
in the task bar.
Step 9
Repeat Step 5 through Step 8 for each IS-IS interface.
Step 10
To configure the MD-5 key chains for IS-IS, choose Devices > Devices > Routing Settings > Proximity
Server Settings > IS-IS > MD5 Settings. The IS-IS Keychain page is displayed.
Step 11
Click the Create new KeyChain icon. The Creating New KeyChain page is displayed.
Step 12
In the Key ID field, enter the identifier for the keychain and click Submit. The page refreshes.
The Key ID is identifier for the multiple key IDs that can be configured for the key chain.
Step 13
Click the Create New KeyChain Key icon. The KeyChain Key page is displayed.
Step 14
In the Key ID field, enter the key ID. The range is from 0 to 65535.
Step 15
In the Key String field, enter the key string to be used for authentication. The key string can be up to 64
alphanumeric characters, except a space, single (‘) and double quotes (“), and the “|” symbol.
Configuring the OSPF Adjacencies
Configuring the OSPF Adjacencies
The Proximity OSPF page allows the Proximity Engine to establish an adjacency with its directly
connected neighbor (router) to receive the whole LSDB content. Other OSPF settings depend on network
topology, deployment and configuration of neighbor nodes.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-115
Chapter 4
Configuring Devices
Configuring the Service Router
OSPF is a link-state routing protocol for IGP. It runs on top of the IP protocol stack. Each node describes
its neighbors in the link state advertisement (LSA) packets. The LSAs are flooded throughout the OSPF
nodes. Each node uses shortest path first (SPF) to compute routes from the LSAs. The routes are then
deposited into RIB.
Note
Only one IGP (IS-IS or OSPF) is supported for the Proximity Engine.
To configure the OSPF adjacencies, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Proximity Server Settings > OSPF. The Proximity
OSPF page is displayed.
Step 2
To enable OSPF adjacencies, check the Enable check box and click Submit. The Create new icons for
Proximity OSPF Network, Proximity OSPF Area, and Proximity OSPF Interface icons display.
To delete the OSPF configuration, click the Delete icon.
Step 3
Check the Enable log-adjacency-changes check box to enable logging changes to the adjacency and
click Submit.
To delete the OSPF configuration, click the Delete icon.
Step 4
To configure the proximity OSPF network, click the Create new Proximity OSPF Network icon. The
Proximity OSPF Network page is displayed.
Step 5
Enter the settings as appropriate. See Table 4-54 for a description of the fields.
Table 4-54
Proximity OSPF Network Fields
Field
Description
IP Prefix
IP address that is used in combination with the Network Mask to produce the IP
prefix. The IP prefix is used to define the OSPF area and consists of a combination
of the IP address and netmask.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-116
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-54
Proximity OSPF Network Fields (continued)
Field
Description
Wildcard Mask
Network mask is used with the IP Prefix to define the area on this network. The mask
contains wild card bits where 0 is a match and 1 is a "do not care" bit, for example,
0.0.255.255 indicates a match in the first two bytes of the network number.
Area ID
Identifier of the area for which IP prefix defines. The identifier can be specified as
either a decimal value or an IP address. Valid entries are from 0 to 4294967295 or an
IP address (A.B.C.D) can be used if you intend to associate areas with IP subnets.
Each area is interface specific. For OSPF to operate on the OSPF interface, the
primary address of the interface must be covered by the network area. The Proximity
Engine sequentially evaluates the IP Prefix/ Network Mask pair for each interface
as follows:
1. The Network Mask is logically ORed with the OSPF interface IP address.
2. The Network Mask is logically ORed with the IP Prefix.
3. The software compares the two resulting values. If they match, OSPF is enabled
on the associated interface and the associated OSPF interface is attached to the OSPF
area specified.
There is no limit to the number of network areas that can be configured.
Note
An interface can only be associated to a single area. If the address ranges
specified for different areas overlap, the software adopts the first area in the
list and ignores the subsequent overlapping portions. In general, we
recommend that you configure address ranges that do not overlap to avoid
inadvertent conflicts.
When a smaller OSPF network area is removed, the OSPF interfaces belonging to
that network area are retained and remain active if a larger network area that
encompasses those interfaces still exists. Interfaces that are part of a larger area are
removed and become part of another area only if the other area is a smaller area
(subset) of the larger area.
Step 6
Click Submit.
To delete an OSPF network configuration, click the Edit icon for the network, then click the Delete icon
in the task bar.
Step 7
Repeat Step 4 through Step 6 for each OSPF network.
To delete an OSPF network, click the OSPF network to display the settings and click the Delete icon.
Step 8
To configure the proximity OSPF area, click the Create new Proximity OSPF Area icon. The Proximity
OSPF Area page is displayed.
Step 9
Enter the settings as appropriate. See Table 4-55 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-117
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-55
Step 10
Proximity OSPF Area Fields
Field
Description
Area ID
Enter an Area ID that was defined in the Proximity OSPF Network page.
Type
Choose one of the following area types:
•
NSSA (not-so-stubby area)—For areas that include an autonomous system
boundary router (ASBR) that generates type 7 LSAs and an area border
router (ABR) that translates them into type 5 LSAs. .
•
Stub—An area with only one OSPF router that does not contain an ASBR.
Click Submit.
To delete an OSPF area configuration, click the Edit icon for the area, then click the Delete icon in the
task bar.
Step 11
Repeat Step 8 through Step 10 for each OSPF area.
To delete an OSPF area, click the OSPF area to display the settings and click the Delete icon.
Step 12
To configure the proximity OSPF network, click the Create new Proximity OSPF Interface icon. The
Proximity OSPF Interface page is displayed.
Step 13
From the Name drop-down list, choose an interface to configure for OSPF. The number of available
interfaces depends on the CDE.
Step 14
In the OSPF Priority field, enter the OSPF priority. The range is 0 to 255. The default is 1.
The highest OSPF priority on a segment becomes the designated router (DR) for that segment. A priority
value of zero indicates an interface which is not to be elected as DR or backup designated router (BDR).
Step 15
Click Submit.
To delete an OSPF interface configuration, click the Edit icon for the interface, then click the Delete
icon in the task bar.
Step 16
Repeat Step 12 through Step 15 for each OSPF interface.
Configuring the BGP Community-based Proximity Settings
Configuring the BGP Community-Based Proximity Settings
A BGP community is a group of prefixes that share some common property and can be configured with
the BGP community attribute. The BGP community attribute is an optional transitive attribute of variable
length. The attribute consists of a set of four octet values that specify a community. The community
attribute values are encoded with an autonomous system (AS) number in the first two octets, with the
remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP
speaker that sees multiple community attributes in a prefix can act based on one, some, or all the
attributes.
See the “BGP Proximity Algorithms” section on page 1-48 for more information.
To configure the BGP community-based proximity settings, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Proximity Server Settings > BGP. The Proximity
BGP page is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-118
Chapter 4
Configuring Devices
Configuring the Service Router
Step 2
In the Local AS Number field, enter the autonomous system (AS) number that identifies the Proximity
Engine and tags the routing information that is passed along.
AS numbers are globally unique numbers that are used to identify ASes, and which enable an AS to
exchange exterior routing information between neighboring ASes. An AS is a connected group of IP
networks that adhere to a single and clearly defined routing policy.
There are a limited number of available AS numbers. Therefore, it is important to determine which sites
require unique AS numbers and which do not. Sites that do not require a unique AS number should use
one or more of the AS numbers reserved for private use, which are in the range from 64512 to 65535.
Step 3
Check the Enable Log Neighbor Changes check box to enable logging of status changes (up, down, or
resets) to BGP neighbors.
Use the show ip bgp neighbors command to view the status changes.
Step 4
Click Submit. The Create new icons for Location Community for BGP and Neighbor for BGP icons
display.
To delete the BGP configuration, click the Delete icon.
Step 5
To configure a BGP location community, click the Create new Location Community for BGP. The
BGP Location Community page is displayed.
Note
Step 6
The maximum number of location communities allowed for each SE is 128. The show
running-config command displays the location communities in ascending order.
In the Location Community field, enter the location community for the AS in one of the following
formats:
<AS>:<POP>
<AS1>:<POP1>-<AS2>:<POP2>
The location community numbers are used within the network to locate prefix origination points. The
configuration includes all community values that represent a location. The Location Community field
entry could be in the form of a list of community numbers, for example, 100:3535, 100:4566, 100:5678,
100:5678, 100:6789. Or, the community numbers can be expressed as intervals, such as
100:3000-100:4000, 100:5000-100:6000, and so on.
Step 7
In the optional Target Community field, enter the target community you want to associate with the
Location Community.
If Target Community field is left blank, it is the same as the Location Community. So, if the target
community is not specified, the PSA and PTA must have a common community for the PTA to be
considered in the preference and ranking.
In certain deployments it is advantageous to include certain PTAs even though the PTAs do not share any
community attributes with the PSA. A common example is an SE in a city close to the client PC; in such
case, the SE might not share any community attributes with the client PC, but should be preferred over
another SE in a far-away city. The Target Community field provides a way to associate PSA and PTA
community attributes with each other and to assign a preference level (Weight) to that association.
The Target Community values have the same format and restrictions as the Location Community field,
which are the following:
•
Must match the pattern: <AS1>:<POP1>[-<AS2>:<POP2>]
•
AS1 and AS2 must be in the range 1–65535.
•
POP1 and POP2 must be in the range 0–65535.
•
AS2 should be greater than AS1, or POP2 should be greater than POP1 if AS2 equals to AS1.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-119
Chapter 4
Configuring Devices
Configuring the Service Router
•
New BGP community setting should make sure that target community and local community pair is
unique and not existent.
Note
Step 8
Source community ranges are not allowed to overlap. A maximum of 240 unique specific source
or range source community configurations can be entered. Each unique specific source or range
source community can be associated with a maximum of 240 unique specific target or range
target communities.
In the optional Weight field, enter the weight to assigned to the location community. The default is 1.
The range is from 1 to 7 with 7 being the best association (most preferred). An association weight of 0
implicitly means no association (least preferred)
The weight is considered in the proximity ranking algorithm. If PTA1 and PTA2 have at least one
community in common as the PSA, then the weight assigned to the location community is considered.
The larger the number, the more weight the community has. If PTA1 has a weight of 5 and PTA2 has a
weight of 2, PTA1 is preferred over PTA2.
Step 9
Click Submit.
Step 10
To configure a BGP neighbor, click the Create new Neighbor for BGP. The BGP Neighbor page is
displayed.
Step 11
Enter the settings as appropriate. See Table 4-56 for a description of the fields.
Table 4-56
BGP Neighbor Fields
Field
Description
IP Address
IP address of the neighbor.
Remote AS Number
AS number to which the neighbor belongs. The range is from 1 to 65535).
EBGP multihop TTL
Time-to-live value for the external BGP (eBGP) multihop scenarios. The range
is from 2 to 255. The default is 1.
Keep Alive Interval
The keepalive interval, in seconds, for a BGP peer. The range is from 0 to 3600.
The default is 60.
Hold Timer
The hold timer interval, in seconds, for a BGP peer. The range is from 0 to
3600. The default is 180.
Password
Enter the password to enable Message Digest 5 (MD-5) authentication on a
TCP connection between the Proximity Engine and the BGP neighbor.
The password is case sensitive and can be up to 79 characters. The first
character cannot be a number. The string can contain any alphanumeric
characters, including spaces. You cannot specify a password in the format
number-space-anything. The space after the number can cause authentication
to fail.
To delete an BGP neighbor configuration, click the Edit icon for the neighbor, then click the Delete icon
in the task bar.
Step 12
Click Submit.
Step 13
Repeat Step 10 through Step 12 for each BGP neighbor.
To delete a BGP neighbor, click the BGP neighbor to display the settings and click the Delete icon.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-120
Chapter 4
Configuring Devices
Configuring the Service Router
Configuring SRP
Configuring SRP
The Service Routing Protocol (SRP) uses distributed hash table (DHT) technology to form a distributed
network of Proximity Engines. For more information, see the “Service Routing Protocol” section on
page 1-49.
Note
SRP is required if the Redirect proximity algorithm is enabled. SRP is used to gather and store
information about all the Proximity Engines that are available for redirection. See the “Configuring the
BGP Community-based Proximity Settings” section on page 4-118“Configuring the BGP
Community-Based Proximity Settings” section on page 4-118 for more information.
To configure SRP, do the following:
Step 1
Choose Devices > Devices > Routing Settings > Proximity Server Settings > SRP. The SRP page is
displayed.
Step 2
To enable SRP, check the Enable check box and click Submit. The Create new Bootstrap for SRP icon
displays.
Step 3
In the Domain field, enter a number that identifies the domain. The range is from 0 to 4294967295. The
default is 0.
All Proximity Engines running SRP routing with the same domain ID form a single network if the nodes
are found through a bootstrap node. By changing a Proximity Engine’s domain, the Proximity Engine
leaves its current network.
We recommend that a domain ID value be configured for your DHT network so that all Proximity
Engines that join this network share the same domain ID.
Step 4
In the Flooding Threshold field, enter the maximum number of subscribers to flood or send messages
to. The range is from 0 to 65535. The default is 50.
SRP uses flooding to send multicast messages for a multicast group if the number of subscribers in the
group is equal to or more than the value specified in Flooding Threshold. An effective threshold value
may improve protocol message overhead. The threshold value depends on the number of nodes in your
DHT network. In general, the threshold value should be greater than half and smaller than 3/4 of the total
number of DHT nodes in the network.
Step 5
Click Submit.
To delete the SRP configuration, click the Delete icon.
Step 6
To configure a SRP bootstrap, click the Create new Bootstrap for SRP. The Bootstrap SRP page is
displayed.
Step 7
In the Bootstrap IP address field, enter the IP address of the bootstrap node.
An IP address of a bootstrap node must be configured for each Proximity Engine before the Proximity
Engine can join the network with others under the same domain ID. The first Proximity Engine in the
network, which acts as the bootstrap node for others, does not need to configure its self as the bootstrap
node; this is the only exception to configuring a bootstrap node. All other nodes must have the bootstrap
node configured before they can join a DHT network. A maximum 25 bootstrap nodes are allowed per
Proximity Engine. The port number for a bootstrap node is 9000.
Step 8
Click Submit.
Step 9
Repeat Step 6 through Step 8 for each bootstrap node.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-121
Chapter 4
Configuring Devices
Configuring the Service Router
To delete a bootstrap node, click the edit icon next to the IP address of the bootstrap node to display the
settings and click the Delete icon.
Configuring Application Control
Configuring Application Control
The Application Control pages allow you to enable Flash Media Streaming, to enable HTTP proxy on
an SR, and to enable HTTP 302 redirection for Windows Media Technology files with an .asx extension.
To configure the application control for the SR, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the SR you want to configure. The Devices home page is displayed.
Step 3
Click Show All to display the top-level menu options, and choose Application Control.
Step 4
To enable Flash Media Streaming on the SR, choose Flash Media Streaming > General Settings. The
Flash Media Streaming Settings page is displayed.
a.
Check the Enable Flash Media Streaming check box.
b.
Click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Step 5
To enable service monitoring for Flash Media Streaming on the SR, choose Flash Media Streaming >
Service Monitoring. The Service Monitoring Settings page is displayed.
a.
Check the Enable Service Monitoring check box.
b.
Click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Step 6
To enable the HTTP 302 redirection for Windows Media Technology files with an .asx extension, do the
following:
a.
Choose Web > HTTP > HTTP Redirect. The HTTP Redirect Settings page is displayed.
b.
Check the Enable HTTP 302 for .asx File check box.
c.
Click Submit.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-122
Chapter 4
Configuring Devices
Configuring the Service Router
Configuring Load Monitoring
Configuring Load Monitoring
For information on configuring all general settings, except load monitoring and last-resort routing, see
the “General Settings” section on page 4-48.
Load monitoring provides the following functionality:
•
Monitoring and aggregates of the load information of all SEs in the CDS
•
Monitoring and aggregates of all SEs assigned to a specific delivery service (domain)
Minor alarms are raised when the monitored load exceeds the configured average or maximum threshold
for all SEs in a delivery service or all SEs in the CDS.
If the CDN Selector (an EFT feature) is configured, Web Services APIs can be used to query the different
loads (a specific SE, all SEs, a specific domain, aggregates of the CDS and aggregates of a specific
domain). See the Cisco Internet Streamer CDS 3.2 API Guide for more information.
To configure load monitoring, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the SR you want to configure. The Devices home page is displayed.
Step 3
Click Show All to display the top-level menu options, and choose General Settings > Notification and
Tracking > CDS Monitor > General Settings. The CDS Monitor General Settings page is displayed.
Step 4
In the Sample Period field, enter the number of seconds between two consecutive samples. The sample
period is the time during which the SE and the SR exchange keep-alive messages that contain the device
information. The default is 2. The range is from 1 to 300.
Step 5
Check the Enable check box to enable load monitoring. If the Enable check box is not checked, the
Streamer Settings and Domain Settings pages do not take effect.
Step 6
Click Submit.
Step 7
To enable the monitoring of all SEs in the CDS and configure the aggregate thresholds for the CDS,
choose Devices > Devices (SR) > General Settings > Notification and Tracking > CDS Monitor >
Streamer Settings. The CDS Monitor Settings page is displayed.
Step 8
Enter the settings as appropriate. See Table 4-59 for a description of the fields.
Table 4-57
CDS Load Monitoring Fields
Field
Description
Enable
Check the Enable check box to enable load monitoring of all SEs in the CDS.
Note
If the Enable check box is not checked on the CDS Monitor General Settings
page, the Streamer Settings do not take effect.
Device Average Aggregate load value (as a percentage) of the average of all SEs in the CDS. This
Threshold
threshold defines the average device load of all the SEs in the CDS. If the threshold
is exceeded, an alarm is raised. The default is 80. The range is from 1 to 100.
Device
Maximum
Threshold
Aggregate load value (as a percentage) of the maximum of all SEs in the CDS. This
threshold defines the maximum device load of all the SEs in the CDS. If the threshold
is exceeded, an alarm is raised. The default is 80. The range is from 1 to 100.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-123
Chapter 4
Configuring Devices
Configuring the Service Router
Step 9
Click Submit.
Step 10
To enable monitoring of specific delivery services (domains) and configure the aggregate thresholds for
each domain, choose Devices > Devices (SR) > General Settings > Notification and Tracking > CDS
Monitor > Domain Settings. The Domain Monitor Table page is displayed.
The table is sortable by clicking the column headings.
Step 11
Click the Create New icon.
Click the Edit icon next to the domain name to edit a table entry.
Step 12
Enter the settings as appropriate. See Table 4-58 for a description of the fields.
Table 4-58
Domain Load Monitoring Fields
Field
Description
Domain Name
The service routing fully-qualified domain name (RFQDN) (for example,
srfqdn.cisco.com) configured for the delivery service.
Enable
Check the Enable check box to enable load monitoring of this domain.
Note
If the Enable check box is not checked on the CDS Monitor General Settings
page, the Domain Settings do not take effect.
Device Average Aggregate load value (as a percentage) of the average of all SEs in the CDS. This
Threshold
threshold defines the average device load of all the SEs in the CDS. If the threshold
is exceeded, an alarm is raised. The default is 80. The range is from 1 to 100.
Device
Maximum
Threshold
Step 13
Aggregate load value (as a percentage) of the maximum of all SEs in the CDS. This
threshold defines the maximum device load of all the SEs in the CDS. If the threshold
is exceeded, an alarm is raised. The default is 80. The range is from 1 to 100.
Click Submit. The entry is added to the Domain Monitor Table.
To delete a load monitoring configuration for a domain, click the Edit icon for the domain, then click
the Delete icon in the task bar.
Configuring Last-Resort Routing
Configuring Last Resort Routing
For information on configuring all general settings, except load monitoring and last-resort routing, see
the “General Settings” section on page 4-48.
Note
When DNS-based redirection is used, for application-level requests, last-resort redirection is supported.
However, on the DNS plane, an A record with the last-resort domain name or IP address is not returned.
Last-resort routing is useful when all Service Engines have exceeded their thresholds, all Service
Engines in the domain are offline, no Service Engines have been assigned to a particular domain, or the
client is unknown. If last-resort routing is configured, the Service Router redirects requests to a
configurable alternate domain or translator response domain when all Service Engines serving a client
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-124
Chapter 4
Configuring Devices
Configuring the Service Router
network region are unavailable, or the client is unknown. A client is considered unknown if the client’s
IP address is not part of a subnet range listed in the Coverage Zone file or part of a defined geographical
area (for location-based routing) listed in the Coverage Zone file.
Last-resort routing could also be configured to redirect a client to an error domain and filename.
The URL translator provides a way to dynamically translate the client request URL in order to redirect
the client to a different CDN. With the URL translator option, the following occurs if the SR uses
last-resort routing for a client request:
1.
The SR contacts the third-party URL translator through the Web Service API. The Web Service API
is described in the Cisco Internet Streamer CDS 3.2 API Guide.
2.
The third-party URL translator sends the translated URL in the response to the SR.
3.
The SR sends a 302 redirect message to the client with the translated URL it received from the
third-party URL translator.
The timeout for connecting to the URL translator server is 500 milliseconds. There are no retries if the
URL translator cannot be reached.
If there is no configuration on the URL translator for the requested domain or the connection timeout
threshold has been reached, the SR last-resort routing falls back to the alternate domain configuration.
For more information, see the “Last-Resort Routing” section on page 1-41.
Note
If the last-resort domain or the translator response domain are not configured and the Service Engine
thresholds are exceeded, known client requests are redirected to the Origin server (if Enable Origin
Server Redirect is enabled) and unknown clients either receive an error URL (if the Error Domain and
Error Filename fields are configured), or a 404 “not found” message.
Unknown clients are only redirected to the alternate domain (last-resort domain) or translator response
domain when the Allow Redirect All Client Request check box is checked or the equivalent
service-router last-resort domain <RFQDN> allow all command is entered.
To configure last-resort routing, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the SR you want to configure. The Devices home page is displayed.
Step 3
Click Show All to display the top-level menu options, and choose General Settings > Last Resort. The
Last Resort Table page is displayed.
The table is sortable by clicking the column headings.
Step 4
Click the Create New icon.
Click the Edit icon next to the domain name to edit a table entry.
Step 5
Enter the settings as appropriate. See Table 4-59 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-125
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-59
Service Router Last Resort Fields
Field
Description
Domain Name
The service routing fully-qualified domain name (RFQDN) (for example, srfqdn.cisco.com).
Allow Redirect
Check the Allow Redirect All Client Request check box to redirect all unknown clients to the alternate
All Client Request domain or content origin.
If the Allow Redirect All Client Request check box is not checked, unknown clients (clients’ subnets
are not included in the Coverage Zone file) receive a 404 message if the error URL is not configured. If
the error URL is configured, client requests are redirected to the Error URL.
If the Allow Redirect All Client Request check box is checked, unknown client requests are redirected
to the alternate domain; otherwise, they are redirected to the origin server.
Alternate Domain Domain (for example, www.cisco.com) used to route requests to when the SEs are unavailable, or the
client is unknown. A client is considered unknown if the client’s IP address is not part of a subnet range
Name
listed in the Coverage Zone file.
Alternate Domain
If an Alternate Domain Name is not specified, requests for the domain entered in the Domain Name are
Port
routed to the Origin server.
The Alternate Domain Name could be a domain outside the CDS. It could be a third-party CDN or
external server. No DNS lookup is performed by the SR to check the liveness of this domain.
To specify a different port than the default (80), enter the port number in the Alternate Domain Port
field. Default is 80. Range is from 1 to 65535. Well-known port numbers are not allowed. For the list of
well-known ports, see the “System Port Numbers” section on page 7-9“System Port Numbers” section on
page 7-10.
Error Domain
Name
To redirect the request to an error URL for any unknown clients or when all SEs in the delivery service
are unavailable, enter the domain name of the URL.
Error Domain Port The Error Domain Name could be a domain outside the CDS. It could be a third-party CDN or external
server. No DNS lookup is performed by the SR to check the liveness of this domain.
To specify a different port than the default (80), enter the port number in the Error Domain Port field.
Default is 80. Range is from 1 to 65535. Well-known port numbers are not allowed. For the list of
well-known ports, see the “System Port Numbers” section on page 7-9“System Port Numbers” section on
page 7-10.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-126
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-59
Service Router Last Resort Fields (continued)
Field
Description
Error File Name
The filename of the error URL (for example, error.html or error/errorfile.flv).
The error URL is made using the Error Domain Name plus the Error File Name. The Error File Name
could be a filename with an extension (for example, error.html or errorfile.flv), or a directory and
filename (for example, error/errorfile.flv or reroute/reroute.avi), or a filename without an extension. If no
extension is specified, the extension is determined by the protocol used in the request.
If a filename has a specific extension, and the request comes from a protocol that does not support the
configured extension, the filename extension is automatically changed to an extension that is supported
by the protocol.
Note
Translator IP
Address
Translator Port
For Flash Media Streaming, an external FMS server must exist that hosts an application for error
handling. The SR redirects Flash Media Streaming requests to an application on the external FMS
server. An example of a Flash Media Streaming error URL is
rtmp://errordomain.com/<application>, where the application name is any application hosted on
that server. The Error File Name, in the case of Flash Media Streaming, is the name of the
application.
IP address of the URL translator server. If there is no configuration on the URL translator for the
requested domain or the connection timeout threshold has been reached, the SR last-resort routing falls
back to the alternate domain configuration.
To specify a different port than the default (80), enter the port number in the Translator Port field.
Default is 80. Range is from 1 to 65535. Well-known port numbers are not allowed. For the list of
well-known ports, see the “System Port Numbers” section on page 7-9“System Port Numbers” section on
page 7-10.
Step 6
Click Submit to save the settings. The entry is added to the Last Resort Table.
To delete a last-resort configuration, click the Edit icon for the configuration, then click the Delete icon
in the task bar.
As an example configuration for an error URL to redirect unknown clients to or to redirect clients to
when all SEs in the delivery service are unavailable follows:
•
Domain Name—wmt.cdsordis.com
•
Error Domain Name—ssftorig.ssft.com
•
Error File Name—testMessage
This configuration states that for any request where the domain name is wmt.cdsordis.com, if the client
IP address is not included in the Coverage Zone file (or the client is not part of a defined geographical
area if location-based routing is enabled) or there are no available SEs assigned to the delivery service,
redirect the request to ssforig.ssft.com/testMessage.<original_extension>.
To be more specific, if the client request was http://wmt.cdsordis.com/vod/video.wmv and the service
rule conditions were met, the client would receive a 302 redirect to http://ssftorig.ssft.com/testMessage.wmv.
If you want the Error File Name to reside in a different directory, you can configure that as well. If the
error message file was located in the “vod” directory, then the Error File Name would be configured as
vod/testMessage.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-127
Chapter 4
Configuring Devices
Configuring the Service Router
Creating ASX Error Message Files for Windows Media Live Programs
Creating ASX Error Message Files for Windows Media Live Programs
There is one thing to remember when redirecting a client request for live Windows Media Streaming
programs. Because live programs deliver an ASX file to the client, the error message must have the same
format. If you try to use an HTML or JPEG instead of an ASX file, the redirect will not work because
the Windows Media player is trying to parse the ASX file.
To satisfy the requirements of the Windows Media player, create an ASX file for the error message file
and put the URL to the error message file inside the ASX file. For example, below is a simple ASX file.
<ASX VERSION="3.0"> <Entry>
<REF HREF="http://<IP-Address-of-Server/path/filename"/>
</Entry> </ASX>
If you wanted the error file to be a GIF file on server 3.1.1.1 called testMessage.gif under the directory
vod then this file would look like:
<ASX VERSION="3.0"> <Entry>
<REF HREF="http://3.1.1.1/vod/testMessage.gif"/>
</Entry> </ASX>
There are other ways to use an ASX file to display information. Below is an example of an approach to
have the Windows Media player display an HTML web page with PARM HTMLView.
<ASX version="3.0"> <PARAM name="HTMLView"
value="http://111.254.21.99/playlist/error.htm"/> <REPEAT> <ENTRY>
<REF href="http://3.1.1.1/vod/testMessage.gif"/>
</ENTRY> </REPEAT> </ASX>
There are many ways to format and structure ASX files to display whatever error message you want, in
whatever format you want.
Configuring Domain Subscription
Configuring Domain Subscription
The Domain Subscription page allows you to subscribe the SR to specific domains. By default, the SR
takes all the domains specified in the CDSM. By specifying the domains in the Domain Subscription
page, the SR only subscribes to the assigned Content Origins.
Step 1
Choose Devices > Devices > General Settings > Domain Subscription. The Domain Subscription page
displays all defined Content Origins of the CDS.
Step 2
Click the Assign icon (blue cross mark) next to the Content Origin you want to assign to this SE.
Alternatively, click the Assign All Content Origins icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-128
Chapter 4
Configuring Devices
Configuring the Service Router
A green arrow wrapped around the blue X indicates a Content Origin assignment is ready to be
submitted. To unassign a Content Origin, click this icon. The Content Origin assignment states are
described in Figure 4-14.
Figure 4-14
Step 3
Content Origin Assignment State
Click Submit to save the settings.
A green circle with a check mark indicates a Content Origin is assigned to this SR. To unassign the
Content Origin, click this icon, or click the Remove All Content Origins icon in the task bar. Click
Submit to save the changes.
Additionally, the Filter Table icon and View All Content Origins icon allow you to first filter a table
and then view all content origins again.
Configuring Transaction Logs for the Service Router
Configuring Transaction Logs for the Service Router
Transaction logs allow administrators to view the traffic that has passed through the SR. The fields in
the transaction log are the client’s IP address, the date and time when a request was made, the URL that
was requested, the SE selected to serve the content, the protocol, and the status of the redirect. The SR
transaction log file uses the W3C Common Log file format. For more information about transaction logs
and their formats, see the “Service Router Transaction Log Fields” section on page 7-82“Configuring
Transaction Logs for the Service Router” section on page 4-129.
To enable transaction logging for the SR, do the following:
Step 1
Choose Devices > Devices > General Settings > Notification and Tracking > Transaction Logging.
The Transaction Log Settings page is displayed.
Step 2
Enter the settings as appropriate. See Table 4-60 for a description of the fields.
Table 4-60
Transaction Log Settings Fields
Field
Description
General Settings
Transaction Log Enable
Enables transaction logging.
Snapshot Counter Log Enable
Enables the Snapshot Counter transaction log. For more information,
see the “Snapshot Counter Transaction Logs” section on
page 7-93“Snapshot Counter Transaction Logs” section on page 7-95.
Compress Files before Export
When this check box is checked, archived log files are compressed
into gzip format before being exported to external FTP servers
Archive Settings
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-129
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-60
Transaction Log Settings Fields (continued)
Field
Description
Max size of Archive File
Maximum size (in kilobytes) of the archive file to be maintained on
the local disk. The range is from 1,000 to 2,000,000. The default is
500,000.
Max number of files to be
archived
Maximum number of files to be maintained on the local disk. The
range is from 1 to 10,000. The default is 10.
Archive occurs
How often the working log is archived and the data is cleared from the
working log. Choose one of the following:
•
Choose every to archive every so many seconds, and enter the
number of seconds for the interval. The range is from 120 to
604800.
•
Choose every hour to archive using intervals of one hour or less,
and choose one of the following:
– at—Specifies the minute in which each hourly archive occurs
– every—Specifies the number of minutes for the interval (2, 5,
10, 15, 20, or 30)
•
Choose every day to archive using intervals of one day or less,
and choose one of the following:
– at—Specifies the hour in which each daily archive occurs
– every—Specifies the number of hours for the interval (1, 2,
3, 4, 6, 8, 12, 24)
•
Choose every week on to archive at intervals of one or more times
a week, choose the days of the week, and choose what time each
day.
Export Settings
Enable Export
Enables exporting of the transaction log to an FTP server.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-130
Chapter 4
Configuring Devices
Configuring the Service Router
Table 4-60
Transaction Log Settings Fields (continued)
Field
Description
Export occurs
How often the working log is sent to the FTP server and the data is
cleared from the working log. Choose one of the following:
•
Choose every to export every so many minutes, and enter the
number of minutes for the interval. The range is from 1 to 100800.
•
Choose every hour to export using intervals of one hour or less,
and choose one of the following:
– at—Specifies the minute in which each hourly export occurs
– every—Specifies the number of minutes for the interval (2, 5,
10, 15, 20, or 30)
•
Choose every day to export using intervals of one day or less, and
choose one of the following:
– at—Specifies the hour in which each daily export occurs
– every—Specifies the number of hours for the interval (1, 2,
3, 4, 6, 8, 12, 24)
•
Choose every week on to export using intervals of one or more
times a week, choose the days of the week, and what time each
day.
FTP Export Server
IP address or hostname of the FTP server.
Name
Name of the user.
Password
Password for the user.
Confirm Password
Confirms the password for the user.
Directory
Name of the directory used to store the transaction logs on the FTP
server.
SFTP
Check the SFTP check box, if you are using an SFTP server.
Splunk UF Export Settings
Step 3
Export Enable
Enables the automatic export of the selected transaction logs to the
designated export server. For more information, see the “Real-Time
Exporting of Transaction Logs for Billing and Analytic Reports”
section on page 7-95“Real-Time Exporting of Transaction Logs for
Billing and Analytic Reports” section on page 7-96.
Monitors
Check the check boxes of the type of transaction logs to export. The
All check box means all transaction logs are exported.
Export Server and Port
IP address and port number of the CDNM, CDN, or other export
server that is to receive the transaction log files. A maximum of three
export servers can be specified. The default port number is 9998.
Click Submit to save the settings.
To apply the factory default settings for the device, click the Apply Defaults icon in the task bar.
To remove the settings from the device, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-131
Chapter 4
Configuring Devices
Configuring the CDSM
Configuring the CDSM
Configuring a CDSM consists of the General Settings menu items. For information on configuring
general settings, see the “General Settings” section on page 4-48.
Device activation is accomplished during installation and initialization of the CDS devices. See Cisco
Content Delivery Engine 205/220/250/420 Hardware Installation Guide for more information.
The Device Activation page for the CDSM displays information about the management IP address and
the role of the CDSM. To change the name of the CDSM, enter a new name in the Name field and click
Submit.
For information about primary and standby CDSMs, see the “Configuring Primary and Standby
CDSMs” section on page 3-11“Configuring Primary and Standby CDSMs” section on page 3-11.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
4-132
CH A P T E R
5
Configuring Services
This chapter provides information on configuring the CDS. This chapter covers the following major
topics:
•
Configuring Delivery Services, page 5-1
•
Configuring Programs, page 5-42
•
Viewing Programs, page 5-54
•
Copying a Program, page 5-57
Configuring Delivery Services
Delivery services are configured for prefetch ingest, hybrid ingest, and live programs. Dynamic ingest,
the other type of ingest, is dynamically cached upon retrieving content that is not locally stored. For more
information about content ingest types, see the “Ingest and Distribution” section on page 1-3.
Configuring a delivery service consists of defining the following:
•
Content Origins
•
Creating Multicast Clouds
•
Creating Storage Priority Classes
•
Creating Delivery Service
•
Identifying Content
Content Origins
Content is stored on origin servers. Each delivery service is configured with one origin server. The same
origin server can be used by multiple live delivery services. However, only one prefetch/caching delivery
service is allowed per origin server.
Note
When creating a live delivery service with the same Content Origin as a prefetch/caching delivery
service, the same set of SEs must be assigned to both; otherwise, the SR may redirect requests to
unassigned SEs.
For more information about origin servers, see the “Origin Servers” section on page 2-9.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-1
Chapter 5
Configuring Services
Configuring Delivery Services
Note
When VOD (prefetch/caching) and live streaming share the same content origin, and the Service Rules
XML file is configured to validate the signed URL where the domain must match the Service Routing
Domain Name, make sure to create rule patterns for the URL validation to match both the Service
Routing Domain Name and the Origin Server FQDN. Additionally, when the URL is signed, exclude the
domain from the signature. See the “Running a Python URL Signing Script” section on page I-11 for
more information. The URL validation must not include the domain for validation (use the
exclude-domain option for the exclude-validate attribute of the Rule_Validate element). See the
“Service Rule File Structure and Syntax” section on page F-3 for more information.
To create a Content Origin, do the following:
Step 1
Choose Services > Service Definition > Content Origins. The Content Origin Table page is displayed
(Figure 5-1) (Figure 5-1.
Figure 5-1
Step 2
Content Origin Table
Click the Create New icon in the task bar. The Content Origin page is displayed (Figure 5-1).
To edit a Content Origin, click the Edit icon next to the Content Origin name.
Step 3
Enter the settings as appropriate. See Table 5-1 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-2
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-1
Content Origin Fields
Field
Description
Name
Unique name of the origin server.
Origin Server
Origin Fully qualified domain name (OFQDN) of the origin server or IP address.
To support Origin server redirection for IPv6 clients and dual-stack clients, do not
use the IP address of the Origin server when configuring the Content Origin for a
delivery service; instead, use the domain name associated with the Origin server.
Note
Service Routing
Domain Name
The string “.se.” cannot be used in the OFQDN.
The FQDN to route client requests. The SE translates the service routing FQDN
(RFQDN) to the origin server whenever it needs to retrieve content from the origin
server.
Note
The string “.se.” cannot be used in the SRFQDN.
The service routing domain name configured for the Content Origin should also be
configured in the DNS servers, so client requests can get redirected to a Service
Router for request mediation and redirection.
The URLs that are published to the users have the service routing domain names
as the prefix.
NAS
From the NAS Configuration File drop-down list, choose a NAS file.
Configuration File The NAS Configuration File drop-down list is populated with the NAS files that
are registered to the CDSM. See the “NAS File Registration” section on page 6-16
for information on registering a NAS file.
A NAS file is an XML file that specifies the parameters for the Network Attached
Storage (NAS) device. For information on creating a NAS file, see Appendix H,
“Creating NAS Files.”
Note
Enable Content
Based Routing
Check the Enable Content Based Routing check box to enable content-based
routing for this content origin. Content-based routing is enabled by default.
Note
Enable Origin
Server Redirect
NAS is only supported in lab integrations as proof of concept.
This option requires that content-based routing be enabled on the SR. See
the “Configuring Request Routing Settings” section on page 4-105.
Enable Origin Server Redirect (which is the default) means the last-resort
routing behavior does not change. When Enable Origin Server Redirect is
disabled any client request for the Origin server (domain) is never redirected to the
Origin server and receives a 404 "not found" message instead.
For more information about last-resort routing, see the “Last-Resort Routing”
section on page 1-41. To configure last-resort routing, see the “Configuring
Last-Resort Routing” section on page 4-124.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-3
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-1
Content Origin Fields
Field
Description
Windows Media
Authentication
Type
The type of client authentication that is required by the origin server. The options
are:
HTTP
Authentication
Type
•
None
•
Basic authentication
•
NTLM authentication
•
Digest
•
Negotiate
HTTP Authentication provides a way for the Origin server to authenticate HTTP
requests by one of the following methods:
•
Basic Authentication
•
Challenged Authentication
Choose None to not configure HTTP Authentication. For more information, see
the “Custom HTTP Header Authentication for Origin Server” section on page 5-6.
Comments
Note
Step 4
Information about the Content Origin.
The string “.se.” cannot be used in the SRFQDN and OFQDN.
Click Submit to save the settings.
To delete a Content Origin, from the Content Origin Table page, click the Edit icon next to the Content
Origin you want to delete, and click the Delete icon in the task bar.
Caution
Do not delete a Content Origin that has a delivery service associated to it. First delete the delivery service
associated with the Content Origin, then delete the Content Origin.
Enabling OS Failover Support for Content Origin
Step 1
Choose Choose Services > Service Definition > Content Origins. The Content Origin Table page is
displayed (Figure 5-1).
Step 2
Click the Edit icon next to the Content Origin name. The Content Origin Information page is displayed.
Step 3
Click Failover Settings (Figure 5-2). Enter the settings as appropriate.See Table 5-2 for a description
of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-4
Chapter 5
Configuring Services
Configuring Delivery Services
Figure 5-2
Failover Settings Page
Table 5-2
Failover Settings Fields
Field
Description
Failover Settings for Content Origin
Enable
Check the Enable checkbox to enable OS
Failover support for this content origin. OS
Failover Support is disabled by default
Failure Alarm Duration
Determines the duration (in minutes) to retain the
failure alarm. The default value is 5 minutes. The
range is from 0 to 525600 minutes.
Note
Recovery Alarm Duration
Determines the duration (in minutes) to retain the
recovery alarm. The default value is 5 minutes.
The range is from 0 to 525600 minutes.
Note
Step 4
When it is set to 0, it means this alarm will
not be raised.
When it is set to 0, it means this alarm will
not be raised.
Click Submit to save the failover settings.
Origin Servers List for Content Origin
Origin Server
FQDN or IP Address of Origin Server
Timeout
Connection timeout of Origin Server.
Retry
The number of retry times when connection to
Origin Server fails.
Priority
The order of Origin Server switching during
failover.
Switch To
Click the Switch To button to manually switch to
the correponding Origin Server
Note
Switch To button is enabled only when
OS Failover is enabled.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-5
Chapter 5
Configuring Services
Configuring Delivery Services
a. To add a new Origin server for the Content Origin, click the Create New icon next to the Origin
Servers for the Content Origin.
b. Enter the settings as appropriate. See Table 5-3 for a description of the fields.
Table 5-3
New Origin Server List Fields
Field
Description
Origin Server
FQDN or IP Address of Origin Server
Timeout
Connection timeout of Origin Server. The default
value is 5 seconds. The range is from 1 to 255
seconds
Retry
The number of retry times when connection to
Origin Server fails. The default value is 0. The
range is from 0 to 255.
Note
Priority
When it is set to 0, it means there are no
retries when connection fails.
The order of Origin Server switching during
failover. The default value is 500. The range is
from 1 to 1000.
Note
Value 1 indicates higest priority and value
1000 indicates lowest priority.
c. Click Submit to save the settings for new Origin Server.
To edit the Origin Server for Content Origin, click the Edit icon next to the Origin Server Name in the
Failover Settings page and modify the settings.
To delete the Origin Server for Content Origin, click the Edit icon next to the Origin Server Name in the
Failover Settings page, the Origin Server Definition page is displayed. Click the Trash icon in the task
bar.
Custom HTTP Header Authentication for Origin Server
Custom HTTP Headier Authentication provides a way for the Origin server to authenticate HTTP
requests by the following methods:
•
Basic HTTP Header Authentication
•
Challenged HTTP Header Authentication
Note
If a Manifest file is located on an Origin server that requires custom HTTP header authentication,
fetching the Manifest file by using the Specify external manifest file method fails. The Manifest file
must be located on a server that does not require custom HTTP header authentication.
Note
Custom HTTP Header authentication supports HTTP 302 redirection. But the authentication process
could only be used for the first server. It is not supported for the redirected destination server.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-6
Chapter 5
Configuring Services
Configuring Delivery Services
Basic HTTP Header Authentication
The basic HTTP header authentication method uses a shared key between the Origin server and the
Content Acquirer of the delivery service. Each HTTP request to the Origin server includes the shared
key in the HTTP header. If Basic Authentication is selected from the HTTP Authentication Type
drop-down list, the following fields are displayed:
•
HTTP Authentication Header—Name of the HTTP authentication header
•
HTTP Authentication Shared Key—Shared key. The shared key must be at least 16 characters and
must be composed of TEXT characters defined in RFC 2616 HTTP/1.1. The range is from 16 to 128
characters.
Challenged HTTP Header Authentication
The challenged HTTP header authentication method uses a shared secret key between the Origin server
and the Content Acquirer of the delivery service. The authentication message does not display the secret
key. The shared secret key uses a random challenge string and cryptographic hash algorithm.
The random challenge string is composed of TEXT characters defined in RFC 2616 HTTP/1.1 and is the
same length as the secret key. Following is the process that occurs for the challenged HTTP header
authentication method:
1.
A binary XOR between the challenge string and the secret key is created.
2.
The authentication value is created by using the cryptographic hash of the XOR value.
3.
The following authentication headers are added to the HTTP request that is sent to the Origin server:
– Header with challenge string
– Header with authentication value
4.
The hashing algorithm is implemented and the name of the hashing function is included in the HTTP
header.
5.
The prefix name (identified as HPFX in this scenario) of the authentication HTTP header is used to
construct the following header names:
– Challenge string header—HPFX-CSTR
– Authentication value header—HPFX-AUTH
– Hashing function header—HPFX-HASH
6.
When the Origin server receives the request, it must do the following:
a. Compute a binary XOR between the HPFX-CSTR header value and the secret key configured
in the CDS.
b. Compute the authentication value with the cryptographic hash in the HPFX-HASH header.
c. Grant access if the Origin server computed authentication value and the authentication value
header (HPFX-AUTH) match (both are lower case).
If Challenged Authentication is selected from the HTTP Authentication Type drop-down list, the
following fields are displayed:
•
HTTP Authentication Header Prefix—Prefix of the HTTP authentication header
•
HTTP Authentication Shared Secret Key—Shared secret key. The shared secret key must be at
least 16 characters and must be composed of TEXT characters defined in RFC 2616 HTTP/1.1. The
range is from 16 to 128 characters.
•
HTTP Authentication Hashing Function—Hashing algorithm for the shared secret key. Select
MD5.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-7
Chapter 5
Configuring Services
Configuring Delivery Services
Creating Multicast Clouds
A multicast cloud is created by specifying an IP multicast address for advertising the data being
transferred, an IP multicast address range for transferring the data, a primary multicast sender SE and an
optional backup sender, a set of receiver SEs, and a maximum rate at which to send the data.
Note
The Multicast Cloud feature is supported in all releases starting from Release 3.1.1.
Note
We highly recommend that you avoid using multicast addresses of the form x.0.0.y (for example,
238.0.0.1). These addresses hash to the same Ethernet address space as 224.0.0.x, which is used
frequently by routers and switches for local multicasts. Additional traffic on these addresses adds to the
workload of these network elements.
To create a multicast cloud, do the following:
Step 1
From the CDSM GUI, choose Services > Service Definition > Multicast Clouds. The Multicast Clouds
table page is displayed.
Step 2
Click the Create New icon in the task bar. The Multicast Cloud Definition page is displayed.
To edit a multicast cloud, click the Edit icon next to the multicast cloud name.
Step 3
Table 5-4
Enter the settings as appropriate. See Table 5-4 for a description of the fields.
Multicast Cloud Fields
Field
Description
Multicast Cloud Information
Name
Identifier for the multicast cloud. The name must be unique across the system.
Advertisement IP address
Unique advertisement address provides all the SEs in one cloud with the same advertisement
address and allows them to communicate multicast session information. The advertisement IP
address must conform to these guidelines:
Port
•
It must be unique across the system.
•
It must be within the RFC multicast range (224.0.0.0–239.255.255.255).
•
It must not be within the start and end range specified by this cloud.
Port used for file addresses. The default port is 7777.
The allowed multicast port range is 1 through 65535. However, the multicast-enabled network
may impose certain restrictions on your choice of port. Normally, port numbers below 1024
should be avoided, but the SE does not enforce any restrictions.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-8
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-4
Multicast Cloud Fields
Field
Description
Multicast Address Settings
Start IP address
The multicast address range is used to provide each delivery service associated with it a unique
multicast address. When you assign a multicast cloud to a delivery service, an unused IP address
is automatically selected from this range to ensure that the address is used by only one delivery
service and by only one multicast cloud.
The Start IP address is the start of the IP address range, which must be within the range
224.0.0.0 to 239.255.255.255.
The IP address range must conform to the following:
•
IP address range cannot overlap with program multicast addresses.
•
IP address range must contain all multicast addresses used by this cloud with its associated
delivery service.
Note
The IP address range in one multicast cloud can overlap that of another multicast cloud.
A message alerts you if there is an overlap, but allows the operation. You must choose a
multicast IP address that does not conflict internally within the same multicast-enabled
network configuration. This multicast IP address is not related to the IP address of the
SE.
End IP address
End of the IP address range, which must be higher than the start IP address. The end IP address
must be within the range 224.0.0.0 to 239.255.255.255.
Default Multicast-out
Bandwidth
Maximum multicast rate in kilobits per second (Kbps). This value applies to the sender SE
24 hours a day, 7 days a week. The minimum rate is 10 Kbps.
To customize bandwidth rates for different days, use the Replication Scheduled Bandwidth page.
The settings on the Replication Scheduled Bandwidth page override the Default Multicast-out
Bandwidth field for the period specified in the Replication Scheduled Bandwidth page. For
more information, see the “Replication” section of the “Configuring Devices” chapter in the
Cisco Internet Streamer CDS 3.2 Software Configuration Guide.
Synchronize Primary and
Backup SE Multicast-out
Bandwidth
When checked, Default Multicast-out Bandwidth settings are used by both primary and
backup senders, if a backup sender is configured.
Backup SE Default
Multicast-out Bandwidth
Maximum multicast rate in kilobits per second (Kbps) for the backup sender. The minimum rate
is 10 Kbps.
Advanced Settings
Multicast medium
Means of transmitting the multicast, either Satellite or Terrestrial. The default is Satellite.
TTL
Number of hops (time-to-live [TTL]) a packet travels before it is discarded, regardless of
whether or not the packet has reached its destination. The range is from 1 to 255. The default is
255.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-9
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-4
Multicast Cloud Fields
Field
Description
FEC transmission group
Size of the FEC (forward error correction) block in packets. (Refer to RFC 3208 PGM Reliable
Transport Protocol Specification for more information.) The allowable inputs are 2, 4, 8, 16, 32,
64, and 128. The default is 16.
FEC data encoding protects transmissions against errors, without requiring retransmission. The
FEC number denotes the number of packets that is encoded into one FEC transmission group.
When the FEC number goes up, the transmission group becomes larger, so the multicast may be
more error-resistant. However, there is more computational overhead and bandwidth usage on
the multicast sender and receivers.
For more information, see the “Multicast Forward Error Correction and Proactive Forward Error
Correction” section on page 2-15.
# of Carousel passes
Maximum number of times a multicast sender attempts to send missing content for on-demand
carousels. The range is from 1 to 1000000000 (1 billion). The default is 5.
Note
If the multicast sender finishes the last carousel on an object at time t and the multicast
sender receives a NACK within t + carousel_delay, the multicast sender starts the next
carousel of this object at time t + carousel_delay. That is, the multicast carousel is not
triggered immediately upon receipt of a NACK if the carousel delay (Delay between
passes field) is greater than zero (0).
For more information, see the “Configuring Carousel Passes” section on page 5-10.
Note
If the number of carousel passes configured is used up, the syslog displays a warning
message as an alert.
Delay between passes
Delay, in minutes, between file transmissions. The range is from 0 to 10080 (one week). The
default is 0.
PGM Router-assist
Specifies whether IP routers are to be used to assist in distribution of content. To enable the IP
router alert option for Pragmatic Group Multicasting (PGM) packets, check the PGM
Router-assist check box.
Primary-to-backup failover Amount of time (in minutes) allotted for the backup sender to detect whether the primary sender
grace period
is active. If the backup sender does not hear a heartbeat from the primary sender within this grace
period, the backup sender assumes the active role. The range is from 5 to 7200. The default is 30.
Backup-to-primary
fallback grace period
Amount of time (in minutes) allotted for the primary sender to detect whether the backup is
active. If the backup sender does not respond within this grace period, the primary sender
assumes the active role. The range is 5–7200. The default is 30.
Comments
Comments about the multicast cloud.
Step 4
Click Submit to save the settings.
To delete a multicast cloud, click the Edit icon next to the multicast cloud that you want to delete, the
Multicast Cloud Definition page is displayed. Click the Trash icon in the task bar.
Configuring Carousel Passes
The number of carousel passes is the maximum number of times a multicast sender can retransmit the
multicast for missing files. The primary sender sends the first carousel pass automatically. After the first
round, multicast receiver SEs request missing content by sending a negative acknowledgment (NACK)
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-10
Chapter 5
Configuring Services
Configuring Delivery Services
to the sender that identifies the missing content. Late-joining receivers or receivers that missed some
content send a NACK to the sender for any files that were not received. The multicast sender sends out
the requested content when it receives the NACK from the receiver. After all receiver SEs have received
all the multicast content or the sender has reached the maximum number of carousel passes, whichever
comes first, the sender stops transmitting content.
The multicast fixed-carousel enable command enables fixed-carousel sending. By default, the SE uses
intelligent carousel sending, which means that the retransmission is guided by feedback from the
multicast receivers in the form of NACKs. Fixed-carousel sending causes the content to be sent without
depending on any receiver feedback. When this feature is enabled, the SE continuously retransmits the
content after waiting the time specified by the sender-delay option. This configuration is allowed only
for the primary sender and is not supported on the backup sender.
If the primary sender fails and the backup sender becomes active, the backup sender takes charge of
NACK processing. The backup sender’s carousel passes are always triggered by a NACK. When the
maximum number of carousel passes is reached for a file on the current active sender, if the delivery
service is configured with the Multicast Unicast, file distribution falls back to unicast. See the
“Multicast Replication” section on page 2-13.
The delivery service can be set to fall back to unicast (Multicast Unicast Option set to Multicast
Unicast) after the maximum number of carousel passes has been reached. If the administrator wants the
SEs to fall back to unicast (for example, with a multi-tier unicast deployment using a terrestrial multicast
medium), the multicast cloud should be configured for a low number of carousel passes (such as 1, 2, or
3).
If multicast replication is preferred (for example, with a hub and spoke or star topology deployment
using a satellite multicast medium), use a high number of carousel passes, such as 10 or more.
To adjust the pacing of the multicast transmission, you can specify how much time must elapse before
missing files are resent (the Delay between passes field on the Multicast Cloud Definition page.
Assigning SEs to a Multicast Cloud
To add SEs to a multicast cloud, do the following:
Step 1
From the CDSM GUI, choose Services > Service Definition > Multicast Clouds. The Multicast Clouds
table is displayed.
Step 2
Click the Edit icon next to the name of the multicast cloud that you want to assign sender and receiver
SEs to. The Multicast Cloud Definition page is displayed.
Step 3
In the left-panel menu, click Assign Service Engines. The Service Engine Assignment page is
displayed.
Step 4
Assign the SEs to the multicast cloud by selecting a role (receiver, primary sender, and backup sender)
for each SE. Table 5-5 describes the SE role assignments for a multicast cloud.
a.
From the Role drop-down list, select Primary Sender, click the Assign icon (blue cross mark) next
to the SE that is the primary sender for the multicast cloud, and click Submit.
The SE states are described in Figure 5-3.
b.
From the Role drop-down list, select Backup Sender, click the Assign icon next to the SE that is
the backup sender for the multicast cloud, and click Submit.
c.
From the Role drop-down list, select Receiver, click the Assign icon next to the SE that is a receiver
for the multicast cloud, and click Submit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-11
Chapter 5
Configuring Services
Configuring Delivery Services
Alternatively, click the Assign all Service Engines icon in the task bar to assign all remaining SEs
as multicast receivers to the multicast cloud and click Submit.
Note
The CDSM GUI allows you to assign SEs that are not multicast enabled. However, you must
ensure that any SE that you assign to a multicast cloud is multicast enabled. (See the “Enabling
SEs for Multicasting” section on page 4-21.)
Figure 5-3
Table 5-5
SE Assignment State
SE Role Assignments for Multicast Clouds
Role Assignment
Description
Primary sender
Primary SE that pushes content to a set of SE receivers using multicast. A
Primary sender cannot be the following:
•
Backup sender or Receiver for the same cloud.
•
Primary sender or Backup sender for a different cloud.
A sender SE cannot be deleted from the network. Before deleting a sender SE,
you must choose another SE as the sender for the multicast cloud.
Backup sender
Backup sender SE that takes over in the event of failure of the Primary sender. A
Backup sender cannot be the following:
•
Primary sender or Receiver for the same cloud.
•
Primary sender or Backup sender for a different cloud.
The Primary and Backup senders of a multicast cloud should subscribe to the
same set of multicast-enabled delivery services.
Receiver
SEs that receive content from the Primary sender. Use the following guidelines
when adding receiver SEs:
•
Multicast cloud must have at least one Receiver. To create a functional
multicast cloud, you must add at least one receiver SE.
•
Maximum number of receivers that can be added is the total number of SEs
in the system (excluding the sender SE).
•
Receiver cannot be a receiver in another multicast cloud.
•
Receiver cannot be a sender in the same multicast cloud. Only SEs that are
not assigned to another multicast cloud are displayed in the Service Engine
Assignment page.
•
Content Acquirer for the delivery service cannot be a receiver in the
multicast cloud
•
Only a fully configured multicast cloud (with at least one receiver SE) can
be assigned to a delivery service to enable multicast capability.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-12
Chapter 5
Configuring Services
Configuring Delivery Services
To remove an SE from the multicast cloud, click the Unassign icon next to the SE you want to remove,
and click Submit. Alternatively, to remove all receiver SEs, you can click the Remove all Service
Engines icon in the task bar and click Submit. After you click Submit, a blue cross mark appears next
to the unassigned SE.
Configuring the Multicast Sender Delay Interval
The multicast sender delay interval is the amount of time before each multicast transmission begins. A
period of delay before the actual multicast transmission begins is required to allow content metadata time
to propagate to the receiver SEs. Metadata contains the content file and configuration information that
is necessary for the successful transmission of content files. The default sender delay interval is 16
minutes. The multicast sender-delay command is used to configure the duration of the delay.
When configuring the sender delay interval, you must take into account that the content metadata must
first be propagated to the receiver before the multicast transmission can commence. During a multicast
session, a receiver SE sends out periodic requests for files that it has not yet received. The sender
retransmits files only as requested by the receiver SE. A multicast receiver rejects a multicast sender’s
advertisement of a file if the associated content metadata has not arrived yet. The sender delay option
allows you to configure enough time for the metadata to propagate to the receiver and avoid having the
receiver reject the multicast sender’s advertisement of a file.
Note
The sender delay interval cannot be configured using the CDSM.
Assigning Multicast Clouds to Delivery Services
Before you can assign a multicast cloud to a delivery service, the delivery service must be
multicast-enabled. One multicast cloud can be used in multiple delivery services, the IP address to use
for this Delivery Service is just different for each delivery service.
Note
When a multicast cloud is assigned to a delivery service, the SEs that are part of the multicast cloud must
also be individually assigned to the delivery service for multicasting. Assign the multicast cloud to the
delivery service first, then assign the individual SEs to the delivery service.
To enable a delivery service for multicast and assign a multicast cloud to the delivery service, do the
following:
Step 1
Choose Services > Service Definition > Delivery Services > Definition. The Delivery Service
definition page is displayed.
Step 2
Enable multicasting on the delivery service. In the Unicast Multicast Option field, select either
Multicast only or Multicast Unicast.
Step 3
Click Submit.
Step 4
From the left-panel menu, choose Assign Multicast Cloud. The Multicast Cloud table is displayed.
Step 5
Click the Assign icon in the task bar. The Assign Multicast Cloud page is displayed.
Multicast clouds must first be defined before they can be added to a multicast-enabled delivery service.
See the “Creating Multicast Clouds” section on page 5-8 for more information.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-13
Chapter 5
Configuring Services
Configuring Delivery Services
Step 6
From the Multicast Cloud drop-down list, choose a multicast cloud. The page refreshes, showing the IP
address range for that multicast cloud and the automatically selected IP address for this delivery service.
In the IP address to use for this Delivery Service field, if the automatically selected IP address is not
acceptable, enter any available IP address from the IP multicast address range.
Step 7
Click Submit to save the settings.
To remove a multicast cloud from a delivery service, click the Edit icon next to the multicast cloud that
you want to remove. the assigned multicast cloud page is displayed. Click the Trash icon in the task bar.
Creating Storage Priority Classes
Assigning a cache storage priority to a delivery service enables the CDN operator with multiple tenants
to provide preference settings for keeping cached content for a delivery service. By default, the Content
Manager deletes cached content based on popularity (an algorithm involving the number of cache hits,
the size of the content object, and the decay of the content object). The cache storage priority setting
assigned to a delivery service influences the content popularity and thereby the content that is evicted.
Each cache storage priority class is identified with a name and has a popularity multiplication factor. The
popularity multiplication factor ranges from 0 to 100, where 0 is the lowest priority and 100 is the highest
priority. If no cache storage priority classes are defined or assigned to a delivery service, the default
multiplication factor of 50 is used.
Following are two examples of how the storage priority class is applied:
•
Content with a storage priority class of 100 that is accessed once has the same priority as content
with a storage priority class of 50 that is accessed twice.
•
Content with a storage priority class of 0 is always the first to be evicted regardless of how many
times the content is accessed.
The storage priority class must first be defined before it can be assigned to a delivery service. To define
a storage priority class and assign it to a delivery service, do the following:
Step 1
Choose Services > Service Definition > Storage Priority Classes. The Storage Priority Classes table
is displayed.
Step 2
In the task bar, click the Create New icon. The Storage Priority Class Definition page is displayed.
To edit a storage priority class, click the Edit icon next to the storage priority class name.
Step 3
Enter the settings as appropriate. See Table 5-6 for descriptions of the fields.
Table 5-6
Storage Priority Class Definition Fields
Field
Description
Class Name
Unique name for the storage priority class.
Storage Popularity
Multiplication Factor
Factor used to multiply the popularity of the content by. The range is from 0
to 100, where 0 is the lowest priority and 100 is the highest priority. Content
with a Storage Popularity Multiplication Factor of 0 is always evicted first,
regardless of popularity calculated. The default is 50.
Comments
Information about the storage priority class.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-14
Chapter 5
Configuring Services
Configuring Delivery Services
Step 4
Click Submit to save the settings.
After creating a storage priority class, you can assign it to a delivery service. See the “Service
Definition” section on page 5-15.
If the multiplication factor of a priority class is modified, or the delivery service priority class
assignment changed, the change is only applied to new accesses to the content, none of the existing
popularity calculations are affected. The storage priority class multiplication factor corresponding to the
content is used with each access from the protocol engine. Each access is multiplied with the
multiplication factor when updating the popularity.
A priority class definition cannot be deleted if it is assigned to a delivery service. To delete a priority
class, first unassign it from all delivery services by changing the setting of the Storage Priority Class,
then delete the priority class.
Creating Delivery Service
A delivery service is a configuration used to define how content is acquired, distributed, and stored in
advance of a client request. For more information about delivery services, see the “Delivery Service”
section on page 2-3.
Before creating delivery services, make sure the devices that participate in the delivery service are
configured for the type of content to be delivered.
A delivery service configuration consists of the following:
1.
Service Definition
2.
General Settings
3.
Authorization Plugins
4.
Assign Multicast Cloud
5.
SE and Content Acquirer Assignment or Device Group and Content Acquirer Assignment
6.
Assign IP Address
7.
Location Settings
8.
Identifying Content
Configuring the first five are described in the following procedure. Identifying content is described in
the “Identifying Content” section on page 5-28.
Tip
For information about verifying a delivery service, see Appendix K, “Verifying the Internet Streamer
CDS.”
To create a delivery service, do the following:
Service Definition
Step 1
Choose Services > Service Definition > Delivery Services. The Delivery Services Table page is
displayed (Figure 5-4).
Step 2
Click the Create New icon in the task bar. The Delivery Services Definition page is displayed
(Figure 5-4).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-15
Chapter 5
Configuring Services
Configuring Delivery Services
To edit a delivery service, click the Edit icon next to the delivery service name.
Figure 5-4
Note
Step 3
Delivery Service Definition Page
The Edit content origin button will not allow to edit the Origin Server Failover Settings. However to
edit the Origin Failover Settings, see Enabling OS Failover Support for Content Origin, page 5-4.
Enter the settings as appropriate. See Table 5-7 for a description of the fields.
Table 5-7
Field
Delivery Service Definition Fields
Description
Delivery Service Information
Name
Unique name for the delivery service.
Note
Origin Server
Spaces are not allowed in the delivery service name.
Displays the Origin Server IP address.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-16
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-7
Delivery Service Definition Fields (continued)
Field
Description
Content Origin
All Content Origins that have been created are listed in the drop-down list. The
delivery service and the Content Origin have a one-to-one relationship. To
create a new Content Origin, see the “Content Origins” section on page 5-1.
Note
To edit the Content Origin press Edit content origin button and to
modify the failover settings for the corresponding content origin refer
“Enabling OS Failover Support for Content Origin” section on
page 5-4.
Live Delivery Service When checked, creates a live program to distribute live or scheduled programs
to the SEs associated with this delivery service and with the live program. This
delivery service does not have a related Manifest file and cannot be used to
distribute file-based content as regular delivery services do. The live program
learns about a live stream through a program file that describes the attributes
of the program.
Checking this check box disables the Delivery Service Quota field and fields
in the Acquisition and Distribution Properties section.
Preposition Storage
Quota
Maximum content disk storage size for each SE, in megabytes, for prefetched
content and metadata, and hybrid metadata for this delivery service.
Note
Session Quota
The Preposition Storage Quota configured does not affect cache
content quota size; it only restricts prefetched content storage for each
SE. If the total prefetched content storage size is less than the
configured quota, then the extra storage is used for dynamic cache files.
Maximum number of concurrent sessions allowed for this delivery service. The
default is zero, which means no session limits are set for this delivery service.
For more information, see the “Wholesale CDN” section on page 2-30.
Session Quota
Augment Buffer
Buffer, as a percentage, of the maximum number of concurrent sessions
allowed over the Session Quota. If this threshold is exceeded, no new sessions
are created until the number of concurrent sessions is below this threshold. The
range is from 0 to 1000. The default is 10.
For more information, see the “Wholesale CDN” section on page 2-30.
Bandwidth Quota
Maximum bandwidth allowed for this delivery service. The default is zero,
which means no bandwidth limits are set for this delivery service.
For more information, see the “Wholesale CDN” section on page 2-30.
Bandwidth Quota
Augment Buffer
Buffer, as a percentage, of the maximum bandwidth allowed over the
Bandwidth Quota. If this threshold is exceeded, no new sessions are created
until the bandwidth used is below this threshold. The range is from 0 to 1000.
The default is 10.For more information, see the “Wholesale CDN” section on
page 2-30.
Storage Priority Class Select the storage priority class to assign to the delivery service. For more
information, see the “Creating Storage Priority Classes” section on page 5-14.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-17
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-7
Delivery Service Definition Fields (continued)
Field
Description
Acquisition and Distribution Properties
Distribution Priority
Content distribution priority setting. Options are High, Medium, and Low. The
default is Medium.
The priority of content acquisition also depends on the origin server. Requests
from different origin servers are processed in parallel. Requests from the same
origin server are processed sequentially by their overall priority.
Use null cipher for
Distribution
When checked, disables encryption for distribution.
Content Acquirer
failover/fallback
grace period
Number of minutes before a Content Acquirer failover or a temporary Content
Acquirer fallback occurs. The range is from 20 to 120 minutes. For more
information, see the “Content Acquirer Redundancy” section on page 1-51.
Never
When checked, SE failover or fallback never occurs.
When checked, applies the system-wide QoS settings for unicast data to the
delivery service. The unicast data refers to the ingest and distribution traffic
among SEs.
Use system-wide
settings for QoS for
unicast data
To override the system-wide QoS settings with delivery service-specific QoS
values, leave this check box unchecked, and configure the delivery
service-specific QoS values in the QoS value for unicast data field.
If an SE is configured with the ip dscp all command, this setting
overrides both the system-wide QoS setting and any delivery service
QoS setting.
QoS value for unicast Configures a Differentiated Services Code Point (DSCP) value for the QoS.
The unicast data refers to the ingest and distribution traffic among SEs.
data
Note
If you choose Other, enter a decimal value in the corresponding field.
You can set QoS settings on a per-delivery service basis and a system-wide
global configuration basis. Delivery service settings take precedence over
global settings.
Note
If an SE is configured with the ip dscp all command, this setting
overrides both the system-wide QoS setting and any delivery service
QoS setting.
QoS value for content Configures a Differentiated Services Code Point (DSCP) value for the QoS on
delivery
a per-delivery service basis. Content delivery refers to the traffic the SEs serve
to clients.
If you choose Other, enter a decimal value in the corresponding field.
Comments
Note
This feature applies only to Windows Media Streaming and Web
engines. You cannot have a cache hit/miss delivery service and a live
delivery service for the same delivery service definition when using the
QoS value for content delivery setting.
Note
If an SE is configured with the ip dscp all command, this setting
overrides both the system-wide QoS setting and any delivery service
QoS setting.
Information about the delivery service.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-18
Chapter 5
Configuring Services
Configuring Delivery Services
Step 4
Click Submit to save the settings.
To delete a delivery service, from the Delivery Service Table page, click the Edit icon next to the
delivery service you want to delete, and click the Delete icon in the task bar.
General Settings
Step 5
From the left-panel menu, click General Settings. The General Settings page is displayed.
Step 6
Enter the settings as appropriate. See Table 5-8 for a description of the fields.
Table 5-8
General Settings Fields
Field
Maximum bitrate
limit per session
for HTTP
Description
Maximum rate, in Kbps, at which a client can receive content. The default is 1000. This bit rate applies
to content that is stored locally, specifically, prefetched, hybrid, or cached. For a cache miss, content is
delivered at the rate the origin server sends it.
To configure a delivery service for non-paced HTTP sessions, set the Maximum bitrate limit per session
for HTTP field to 0. This setting provides best-effort behavior and sessions use the available bandwidth.
Disable HTTP
Download
When the content file is smaller than the chunk size, UKSE sends the entire file immediately. In this case,
UKSE does not check pacing; therefore, the bit rate for files smaller than the chunk size is not honored.
Check the Disable HTTP Download check box to not allow clients to download HTTP content through
this delivery service. This option disables all HTTP-based content served from this delivery service. The
Web Engine returns a 403 forbidden message.
Note
Enable Content
Flow Trace
Enable Filter
Trace Flow to
Client
Because the Web Engine receives all HTTP requests before either Windows Media Streaming or
Flash Media Streaming, if you disable HTTP download for a Windows Media Streaming delivery
service or a Flash Media Streaming delivery service, and a client uses an HTTP request to
download the SWF file, the Web Engine returns a 403 forbidden message.
The Content Flow Trace and the Filter Trace Flow to Client are used for debugging purposes to monitor
the path a request takes through the CDS in case of errors. They should not be enabled during high traffic
loads.
Check the Enable Content Flow Trace check box to enable the content flow trace for the delivery
service. Check the Enable Filter Trace Flow to Client check box to enable sending the response
information as part of the HTTP headers to the client.
For more information, see the “Content Flow Trace” section on page 7-56.
Note
Authorization Server and Transaction Logging must be enabled on each SE in the delivery service
for Content Flow Trace and Filter Trace Flow to Client to work properly.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-19
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-8
General Settings Fields (continued)
Field
Description
Enable streaming
over HTTP
Check the Enable streaming over HTTP check box and specify the file types in the HTTP Allowed
Extensions field to configure progressive download or streaming for certain media files. This setting
applies only to the following file types: .asf, none, .nsc, .wma, .wmv, and nsclog.
HTTP Allowed
Extensions
If you want Windows Media Streaming to serve HTTP requests, check the Enable streaming over HTTP
check box.
Note
The Enable streaming over HTTP check box should be checked if the content origin for this
delivery service is used for a live program.
Note
For MP3 live streaming (which uses the Web Engine), if a Windows Media player client requests
an MP3 and the request URL does not have a file extension, and if the HTTP Allowed Extensions
field contains “none,” then the playback fails because the Windows Media Streaming engine
attempts to play the stream instead of the Web Engine. For the delivery service to support MP3
live streaming, either uncheck the Enable streaming over HTTP check box or remove “none”
from the HTTP Allowed Extensions field. MP3 live streaming only supports the Icecast and
Shoutcast origin servers. The supported mime-types (codecs) are “audio/mpeg” and “audio/aacp.”
This delivery service setting has priority over the Windows Media Streaming engine settings on the
Service Engines. If Windows Media Streaming is enabled on the Service Engines, and the media types
are specified in the HTTP Allowed Extensions field, the delivery service streams the media types
specified. If Windows Media Streaming is not enabled, or the media types are not specified in the HTTP
Allowed Extensions field, the delivery service uses HTTP download.
Outgoing Cookie
Enter the cookie, if required by the origin server. Some origin servers allow or deny a request based on
the cookie included in the request header. If a cookie is configured, all outgoing requests from the SE to
the origin server include the configured cookie in the request header.
Check the Enable Error Response Caching check box and enter the error status codes (space delimited)
Enable Error
Response Caching that are able to be cached in the Cacheable Error Responses field.
Cacheable Error
Responses
Follow Origin
Server redirects
Number of
redirects allowed
By default, the error status codes that are able to be cached (400, 403, 404, 500, and 503) are listed.
Check the Follow Origin Server redirects check box to have the Web Engine handle 302 redirects rather
than forwarding the response to the client. If the Follow Origin Server redirects is not enabled, a 302
redirect sent from the Content Acquirer to the SE is sent back to the client. If the Origin server redirects
the request to an external server, the client makes the connection to the external server to get the asset,
which completely bypasses the CDS. If the Follow Origin Server redirects is enabled, the destination
server may return any other valid HTTP response, which may be sent back to the client.
Number of redirects allowed sets the number of times a redirect is followed. If the number of redirects
is exceeded, an error is returned to the client. The default is 3. The range is from 1 to 3.
As an example, if the Number of redirects allowed is set to 2 and the Origin server redirects to a server
B, B redirects to C, and C redirects to D, then only redirection to C is followed. When C returns 302, the
Web Engine on the SE returns an error code 310 to the client.
Note
The Follow Origin Server Redirect feature is not supported for the HEAD request; only the GET
request is supported.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-20
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-8
Field
General Settings Fields (continued)
Description
URL Hash Level Enter the directory level that is used to calculate the URL hash for cache routing. The range is from 0 to
for Cache Routing 10. The default, 0, means use the entire URL to create the hash.
The URL hash is used by the Cache Router in selecting an upstream SE. The URL hash calculation is
based on the directory level. By setting the URL Hash Level for Cache Routing to a directory level of
a URL, all URLs that have the same directory structure take the same hierarchical path to the origin
server.
For example, if the URL Hash Level for Cache Routing field is set to 5, then all content URLs that have
the same directory structure up to the fifth directory level are routed the same. For this example, the
portion of the URL in bold is the included directory level:
http://ofqdn/content/content_type/moviename/quality/filename
Note
HTTP Response
Read Timeout
If the upstream SE has reached a threshold causing the liveness query to fail, the request goes to
the parent SE. As long as the threshold have not been exceeded, all URLs with the same directory
level take the same path for the configured directory level.
If the Origin server does not respond within the HTTP Response Read Timeout, the connection is
terminated and the content is not served. Similarly, if the upstream SE does not respond within the HTTP
Response Read Timeout, the connection is terminated and the content is not served. The default is 5.
The range is from 1 to 60.
Note
If the Follow Origin Server Redirect feature is enabled, the HTTP Response Read Timeout
value is used for each redirected Origin server. Because each Origin server may have a different
idle period, it may cause additional delays to the user depending on the value and frequency of
the idle periods.
Disable File
Caching on Disk
Check the Disable File Caching on Disk check box to not cache any content. Cache bypass is performed
on all content objects.
Memory Cache
Size
Enter the maximum file size (in MB) that defines a small file. The range is from 1 to 10 MB. The default
is 2 MB.
Small files are cached in RAM (tmpfs) first. Simultaneously, an asynchronous task is created to store the
files on the disk. These files stay in tmpfs till their data source is active. An internal web engine timer is
triggered every 4 seconds to monitor the status of data sources. If a data source is not serving a client, the
data source will be deleted, along with its corresponding file in the tmpfs. In an abnomal condition, for
example, lackof tmpfs space or of fds space, the file may not be in tmpfs.
Large files are normally stored on the disk directly.
The response time for caching a small file is much less than that of a large file.
The Memory Cache Size value should be carefully chosen because it affects the performance and
response time for the delivery service. When picking a value that defines a small file versus a large file
for a delivery service, not only should the file size of the majority of the traffic be considered, but also
the hardware of all the SEs in the delivery service (the value is limited by the least-capable SE), the
bit-rate setting, and other parameters.
Origin Server
HTTP Port
Port used by Web Engine to communicate with Origin servers. Default is 80. Range is from 1 to 65535.
Well-known port numbers are not allowed. For the list of well-known ports, see the “System Port
Numbers” section on page 7-9.
Note
If the Origin Server HTTP Port is set to a different port than the default (80), then the port number
of the Origin server must be included in the URL when adding content. See the “Identifying
Content” section on page 5-28.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-21
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-8
General Settings Fields (continued)
Field
Description
Skip Location
Leader Selection
for Edge SE
When the Skip Location Leader Selection for Edge SE check box is checked (option is enabled), the
location leader selection is skipped at the edge location, and the edge SE directly contacts the location
leader of the upstream tier. None of the other edge SEs are contacted.
When the Skip Location Leader Selection for Edge SE check box is unchecked (option is disabled), the
location leader selection takes place at the edge tier. The edge SE may or may not directly contact the
location leader of the upstream tier or the SEs in the edge tier. Contact is based on the location leader
selection.
This option is mainly used to improve the edge-tier caching efficiency to avoid content duplication at the
edge-tier SEs.
WMT User Agent Enter the user agents for Windows Media Streaming. The WMT User Agent field accept
comma-separated values for identifying the user agents.
Note
The ampersand (&) cannot be used when specifying a user agent.
The following user agents are supported for Windows Media Streaming: NSPlayer, WMServer,
WMPlayer, NSServer, Windows Media Player, and VLC.
Windows Media Streaming has been enhanced to support custom user agents that are configured through
the CDSM GUI. The maximum number of user agents allowed is 32. Each user-agent identifier can have
a maximum of 32 characters. The following example specifies Windows Media Player, NSPlayer, and
LAVF as Windows Media Streaming user agents:
NSPlayer,LAVF,Windows-Media-Player
Note
The Content Origin for a delivery service can be used for one delivery service and multiple live
delivery services. The WMT User Agent field applies to all the delivery services associated with
the same Content Origin.
Delivery
streaming
protocol support
To enable HTTPS when streaming to clients, in the Delivery streaming protocol support drop-down list,
select HTTPS only. The default is HTTP only.
Origin Server
streaming
protocol support
To enable HTTPS for communications with the Origin server, in the Origin Server streaming protocol
support drop-down list, select HTTPS only. The default is HTTP only.
For more information about HTTPS Streaming and how to configure it, see the “HTTPS Streaming”
section on page 2-25.
If the setting of the Delivery streaming protocol support field is different that the setting of the Origin
Server streaming protocol support (specifically, streaming to clients is HTTPS and ingests from Origin
server is HTTP, or the other way around), a warning is displayed to the client.
For more information about HTTPS Streaming and how to configure it, see the “HTTPS Streaming”
section on page 2-25.
Force Quota
Usage Reporting
Step 7
Quota usage reporting is automatically sent whenever a session quota or a bandwidth quota is configured
for a delivery service with a setting other than zero (zero means no limits are configured). To monitor the
session counter and bandwidth counter when session quota and bandwidth quota are not configured,
check the Force Quota Usage Reporting check box.
Click Submit to save the settings.
To remove the settings from the delivery service, click the Remove Settings icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-22
Chapter 5
Configuring Services
Configuring Delivery Services
Authorization Plugins
The Authorization Plugins page allows you to upload or import a Geo/IP file and assign a Service Rule
file that has been registered to the CDS.
A Geo/IP file is an XML file that configures the delivery service to allow or deny client requests based
on the client’s IP address or based on the client’s geographic locations (country, state, city). Each SE
participating in the Authorization Service must have Authorization Service enabled and the IP address
and port of the Geo-Location server specified. See the “Configuring the Authorization Service” section
on page 4-29 for more information. For more information on the XML configuration file for the Geo/IP
file, see Appendix D, “Creating Geo/IP Files.”
A Service Rule file is an XML configuration file that specifies service rules for all the SEs in the delivery
service. For more information on the XML file for the Service Rule, see Appendix F, “Creating Service
Rule Files.”
The Service Rule file is only supported for the Web Engine and Flash Media Streaming; for
Windows Media Streaming and Movie Streamer, use the per-device service rule configuration.
For more information, see the “Configuring Service Rules” section on page 4-22. The
Authorization Service must be enabled on all SEs participating in a delivery service that uses the
Service Rule file. The Authorization Service is enabled by default. For more information, see
the “Configuring the Authorization Service” section on page 4-29.
Note
Step 8
From the left-panel menu, click Authorization Plugins. The Authorization Plugins page is displayed.
Step 9
To upload or import a Geo/IP file for the delivery service, do the following:
a.
In the Geo/Ip Plugin Settings section, click the Configure icon for Geo/Ip File. The File
Management page is displayed.
b.
Choose a file import method from the File Import Method drop-down list:
c.
•
Upload—Uploads a file from any location that is accessible from your PC using the browse
feature.
•
Import—Imports a file from an external HTTP, HTTPS, or FTP server.
Enter the fields as appropriate.Table 5-9 describes the upload method fields. Table 5-10 describes
the import field methods.
Table 5-9
Upload Method
Property
Description
Source File Upload
Local directory path to the file. To locate the file, use the Browse
button. Click Validate to validate the XML file.
Destination Filename
Name of the file. This field is filled in automatically with the filename
from the local directory path.
Table 5-10
Import Method
Property
Description
File URL
The URL where the file is located, including path and filename. Click
Validate to validate the XML file.
Destination File Name
Name of the file.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-23
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-10
Property
Description
Update Interval
Frequency with which the CDSM looks for changes to the file. The
default value is 10 minutes.
Username
Name of the user to be authenticated when fetching the file.
Password
User password for fetching the file.
d.
Step 10
Import Method (continued)
To save the settings, click Submit.
To assign a Service Rule file, do the following:
a.
From the Service Rule File drop-down list, choose a Service Rule configuration file.
The Service Rule File drop-down list is populated with the Service Rule files that are registered to
the CDSM. See the “Authorization File Registration” section on page 6-15 for information on
registering a Service Rule file.
See Appendix F, “Creating Service Rule Files.” for information on creating a Service Rule file.
b.
Click Submit.
Assign Multicast Cloud
See the “Assigning Multicast Clouds to Delivery Services” section on page 5-13 for information on
assigning multicast clouds to a delivery service.
Note
The Multicast Cloud feature is supported in all releases starting from Release 3.1.1.
SE and Content Acquirer Assignment or Device Group and Content Acquirer Assignment
Step 11 through Step 14 use the Assign Service Engines option to describe the procedure of assigning
the Service Engines to the delivery service and selecting one of them as the Content Acquirer. If you
have device groups defined, you can use the Assign Device Groups option instead. To assign device
groups, follow Step 11 through Step 14 and substitute Device Groups for each instance of Service
Engines or SE.
Note
Step 11
Use either Assign Service Engines, or Assign Device Groups to assign Service Engines and
select a Content Acquirer.
From the left-panel menu, click Assign Service Engines. The Service Engine Assignment page is
displayed (Figure 5-5).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-24
Chapter 5
Configuring Services
Configuring Delivery Services
Figure 5-5
Step 12
Service Engine Assignment Page
Click the Assign icon (blue cross mark) next to the SE you want to assign to this delivery service.
Alternatively, in the task bar, click Assign All Service Engines. The SE assignment states are described
in Figure 5-6.
Figure 5-6
SE Assignment State
A green arrow wrapped around the blue cross mark indicates an SE assignment is ready to be submitted.
To unassign an SE, click this icon.
Step 13
From the Assign Content Acquirer drop-down list in the task bar, choose an SE to be the Content
Acquirer for this delivery service.
The list contains all SEs currently assigned to the delivery service.
The Primed check box indicates if an SE is primed with a live stream. For more information about
priming, see the “Priming a Live Delivery Service” section on page 5-49.
Step 14
Click Submit to save the SE and Content Acquirer assignments.
A green circle with a check mark indicates an SE is assigned to this delivery service. To unassign the
SE, click this icon, or click Unassign All Service Engines in the task bar. Click Submit to save the
changes.
Note
To view all the Service Engines assigned to the delivery service, in the left-panel menu, click
List assigned Service Engines.
Assign IP Address
The Multiple Logical IP Addresses feature allows for the configuration of multiple logical IP addresses
for each gigabit Ethernet interface, port channel, or standby interface on an SE. Each logical IP address
can be assigned to a delivery service. The same logical IP address can be used for more than one delivery
service as long as the delivery services use the same content origin.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-25
Chapter 5
Configuring Services
Configuring Delivery Services
The Multiple Logical IP Addresses feature supports up to 24 unique IP addresses within the same subnet
for the same interface. The netmask is unique per interface, which means for a single interface you
cannot have multiple IP addresses with different netmask values. Up to 24 unique IP addresses are
supported in the SE to SR keepalive messages.
To configure multiple IP addresses on an interface use the ip address command multiple times in the
config-if mode, or use the range keyword option (ip address range).
(config-if)# ip address <ip_addr> <subnetmask>
(config-if)# ip address range <lower_ip_addr_range> <upper_ip_addr_range> <subnetmask>
To view configured IP address for an interface, use the show interface command or the show
running-config command. The IP address assignments for each SE can also be displayed in the CDSM
GUI by viewing the Network Interfaces page (Devices > Devices > General Settings > Network >
Network Interfaces).
Note
SNMP traps are still per interface; not per IP address. However, transaction logs include the
server IP address.
If a delivery service is mapped to a specific IP address, the SR does not perform load balancing to any
other IP address. If the delivery service is not mapped to an IP address, load balancing is performed.
The CLI is used to assign the multiple IP addresses to each interface on the SE. For information on the
interface command, see the Cisco Internet Streamer CDS 3.2 Command Reference.
The IP address assignments for each SE can be displayed in the CDSM GUI by viewing the Network
Interfaces page (Devices > Devices > General Settings > Network > Network Interfaces).
Note
Removing an IP address from a delivery service interrupts the service. Changing an IP address
for a delivery service causes all new requests to use the new IP address.
If using Device Groups for delivery services, assigning IP addresses to the SE interfaces must
happen before assigning the device to the device group.
Step 15
To assign an IP address of an SE to a delivery service, click Assign IP Address from the left-panel menu.
The Interface IP Entries page displays the SEs assigned to this delivery service.
Step 16
Click the Edit icon next to the SE you want to assign the IP address for. The Modify IP Assignment page
is displayed.
Step 17
In the Address field, enter the IP address for the SE.
Step 18
In the Ipv6Address field, enter the IPv6 address for the SE
If the dual-stack client intent is to use either (IPv4 or IPv6) transports, map both the IPv4 address and
IPv6 address of the Service Engine to the Delivery Service.
Step 19
Click Submit.
Location Settings
Step 20
To enable session tracking for ABR and Generic sessions, click Location Settings from the left-panel
menu. The Location Settings table is displayed (Figure 5-2).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-26
Chapter 5
Configuring Services
Configuring Delivery Services
Figure 5-7
Location Settings Table
The Location Settings table lists the locations for the SEs associated with the delivery service. For more
information about locations, see the “Configuring Locations” section on page 4-1.
To track ABR and Generic sessions using transaction logs for the custom-format Web Engine transaction
logs and the Per Session log, the Generic Session Tracking, the HLS Session Tracking and HSS Session
Tracking must be enabled for the SEs in the edge location of each delivery service serving HLS and HSS
content. For more information about ABR Session Tracking and Generic Session Tracking, see the “Web
Engine User Level Session Transaction Logs” section on page 7-89.
Step 21
Enter the settings as appropriate. See Table 5-11 for a description of the fields.
Table 5-11
Location Settings Fields
Field
Description
Enable Generic Session
Tracking
Enables Generic session tracking at the edge location
Enable HSS Session Tracking Enables HSS session tracking at the edge location
Enable HSS Streaming from
NAS
Enables HSS from Network-attached Storage (NAS) devices.
Note
Not supported in Release 3.1.
Enable HLS Session Tracking Enables HLS session tracking at the edge location
Note
Step 22
URL Resolve Rule does not work when ABR Session Tracking is enabled
Click Submit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-27
Chapter 5
Configuring Services
Configuring Delivery Services
Identifying Content
Content items are identified within the delivery service configuration for prefetch and hybrid ingests.
Live program content is identified through the Live Program page, and therefore does not have content
items listed for it in the delivery service. The procedures outlined in this section take you through adding
content for the delivery service and assumes you have already defined the delivery service (see the
“Creating Delivery Service” section on page 5-15).
Note
The recommended maximum number of prefetched content items is 200,000.
When you configure a delivery service for content acquisition, you must choose one of the following
methods:
•
Identifying Content Using the CDSM
The CDSM provides a user-friendly interface that you can use to add content items and specify crawl
tasks without having to create and update a Manifest file. The CDSM automatically validates all user
input and generates an XML-formatted Manifest file in the background that is free of syntax errors.
Only one Manifest file is generated per delivery service for all content items. You can save your
CDSM-generated Manifest file to any accessible location.
•
Identifying Content Using a Manifest File
The externally hosted Manifest files contain the XML tags, subtags, and attributes that define the
parameters for content ingest. You must be familiar with the structure of the XML-based Manifest
file and be sure the XML tags are properly formatted and syntactically correct before you can create
and use Manifest files effectively.
To verify that the content has been acquired, after you have configured the content acquisition method,
see the “Verifying Content Acquisition” section on page 5-42.
Identifying Content Using the CDSM
There are several options in identifying content to be acquired using the CDSM. You can do any of the
following:
•
Identify a single content item.
•
Define a crawl task that searches the origin server at the specified location (URL) and to the
specified link depth, and create a list of all content that meets those specifications.
•
Define a crawl task with the specifications described in the bullet above, and in addition specify
content acquisition rules that further narrow the search.
•
Select individual items by performing a quick crawl, and select the items from the crawl result list
to be included in the content list.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-28
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-12 describes the icons for identifying content using the CDSM.
Table 5-12 Delivery Service Content Icons
Icon
Function
Refreshes the table.
Adds a content item for acquisition.
Deletes a selected item.
Manages between host and proxy servers for content acquisition.
Saves to disk.
Processes content changes.
Views complete URL (+) or view (-) partial URL that is used to
acquire content.
Edits settings for acquiring content from this URL.
Deletes content item.
For more information about the crawler feature, see the “Crawling” section on page 2-10.
To identify content for acquisition using the CDSM, do the following:
Step 1
Choose Services > Service Definition > Delivery Services > Delivery Service Content. The Content
Table page is displayed with “Use GUI to specify content acquisition” as the method (Figure 5-8).
Figure 5-8
Step 2
Content Table Page
Click the Add Content icon in the task bar. The Content Manager page is displayed (Figure 5-9).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-29
Chapter 5
Configuring Services
Configuring Delivery Services
Figure 5-9
Content Manager Page
To edit a content item, click the Edit icon next to the content. For more information about manipulating
the content items in the Content Table page, see the “Configuring Proxy Server Settings” section on
page 5-37.
Step 3
Choose a protocol from the Source URL drop-down list, and enter the source URL in the associated
field.
The source URL is the origin server domain name or IP address, followed by a path, or path and
filename, if applicable. If the Origin Server HTTP Port in the Delivery Services > General Settings
page is set to a different port than the default (80), then the port number of the Origin server must be
included in the URL when adding content.
Note
Step 4
The URL format for Server Message Block (SMB) servers is: \\SMB
server:port\sharedfolder\filepath. If port is not specified in the URL, the default port, 139, is
used. Maximum file size, when using SMB for acquisition, is 2 GB. Symbolic links within
exported file systems (SMB or NFS) must contain a relative path to the target file, or the target
file should be copied into the exported volume.
Do one of the following:
•
To identify a single content item, check the Single Item check box, and go to the “Configuring
Advanced Settings” section on page 5-34 in this procedure.
•
To define a crawl, uncheck the Single Item check box, and in the Link Depth field, enter the depth
of the links to search. Go to the “Defining a Crawl Task” section on page 5-31 in this procedure.
•
To perform a quick crawl, uncheck the Single Item check box, and, in the Link Depth field, enter
the depth of the links to search. Go to the “Launching Quick Crawl” section on page 5-32 in this
procedure.
The crawler feature starts with the Source URL, identifies every web link in the page, and adds every
link to the list of URLs to search, until the links have been followed to the specified depth.
The Link Depth field specifies how many levels of a website to crawl or how many directory levels of
an FTP server to search. This is optional. The range is –1 to 2147483636.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-30
Chapter 5
Configuring Services
Configuring Delivery Services
If the depth is –1, there is no depth constraint.
If the depth is 0, content is acquired only at the starting URL.
If the depth is 1, content is acquired starting at the URL and includes content the URL references.
Defining a Crawl Task
To define a crawl task, do the following:
Step 1
Click the Define a Crawl Task radio button.
Step 2
Do one of the following:
Step 3
•
Click Submit (or Update if you are editing an existing content) to add a crawl task to the delivery
service. The local Manifest file is automatically reparsed, changes are detected, and the
corresponding content items are acquired or removed.
•
Go to the “Configuring Advanced Settings” section on page 5-34, if applicable.
•
Continue to the next step and create acquisition rules.
Click the Show Optional Content Acquisition Rules arrow to further refine the crawl task. The fields
in the acquisition rules are displayed (Figure 5-10), and the arrow becomes the Hide Optional Content
Acquisition Rules arrow.
Figure 5-10
Step 4
Content Manager Page—Acquisition Rules Fields
Enter the settings as appropriate. See Table 5-13 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-31
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-13
Acquisition Rule Fields
Field
Description
MIME Type
A content item qualifies for acquisition only if its MIME type matches this
MIME type (for example, video/mpeg).
Note
Step 5
The MIME type cannot exceed 32 characters.
Extension
A content item is acquired only if its extension matches this extension.
Time Before
Files that were modified before this time qualify for acquisition. Use the
dd-mm-yyyy hh:mm:ss [TMZ] format, where TMZ (the time zone) is
optional. UTC is the default. Alternatively, click the Calendar icon to
choose a date from the calendar and enter a time, and click Apply.
Time After
Files that were modified after this time qualify for acquisition. Use the
format dd-mm-yyyy hh:mm:ss [TMZ] format, where TMZ (the time zone)
is optional. UTC is the default. Alternatively, click the Calendar icon to
choose a date from the calendar and enter a time, and click Apply.
Minimum Size
Content equal to or larger than this value qualifies for acquisition. Choose
MB, KB, or Bytes as the unit of measure. The range is 0 to 2147483636.
Max Size
Content equal to or less than this value qualifies for acquisition. Choose
MB, KB, or Bytes as the unit of measure. The range is 0 to 2147483636.
Click Add to add the rule to the rules list. An entry is added showing the values under each column
heading.
Note
A maximum of ten rules can be configured for each crawl task.
To modify a content acquisition rule, click the Edit icon next to the rule. Once you have finished, click
the small Update button in the content acquisition rules section to save the edits.
To delete a content acquisition rule, click the Edit icon next to the rule. Click the Delete button in the
content acquisition rules section. The rule is removed from the rules listing.
Step 6
When you have finished adding and modifying content acquisition rules, do one of the following:
a.
If this is a new crawl task, click Submit.
b.
If you are editing an existing crawl task, click Update.
c.
Go to the “Configuring Advanced Settings” section on page 5-34, if applicable.
Launching Quick Crawl
Quick Crawl is a utility that automatically crawls websites starting from the specified source URL. You
can use this utility when you know only the domain name and not the exact location of the content item.
Quick Crawl supports crawling only for HTTP and HTTPS acquisition protocols.
To launch a quick crawl, do the following:
Step 1
Click the Select Individual Items radio button and click Launch Quick Crawl. The Quick Crawl Filter
window is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-32
Chapter 5
Configuring Services
Configuring Delivery Services
Step 2
Enter the settings as appropriate. See Table 5-14 for a description of the fields.
Table 5-14
Quick Crawl Filter Fields
Field
Description
MIME Type
A content item is listed in the results only if its MIME type matches this
MIME type (for example, video/mpeg).
Extension
A content item is listed only if its extension matches this extension.
Modified After
A content item is listed only if it was modified after this date. Click the
Calendar icon to choose a date from the calendar, or enter the date in
mm/dd/yyyy format.
Modified Before
A content item is listed only if it was modified before this date. Click the
Calendar icon to choose a date from the calendar, or enter the date in
mm/dd/yyyy format.
Minimum Size
Content equal to or larger than this value is listed in the results. Choose MB,
KB, or Bytes as the unit of measure. The range is 0 to 2147483636.
Max Size
Content equal to or less than this value is listed in the results. Choose MB,
KB, or Bytes as the unit of measure. The range is 0 to 2147483636.
Link Depth
How many levels of a website to crawl or how many directory levels of an
FTP server to crawl. The range is –1 to 2147483636.
If entered, the value from the Content Manager page is brought over to this
field.
Step 3
Max Item Count
The maximum number of content items that is listed in the results. The
maximum value is 1000.
Domain
The host.domain portion of the source URL. Edit this field to limit the
search to a specific host on a domain.
Username
The username to log in to host servers that require authentication.
Password
The password for the user account.
Click Start Quick Crawl to being search. The Searching for Content status displays a progress bar and
shows the number of items found.
Click Show Results to display the content items before the search is complete.
Click Refresh Results to refresh the progress bar.
When finished, the search results list the MIME type, size, date modified, and URL of each content item
that met the search criteria.
Step 4
Check the check box next to the content items you want to include in this delivery service. Use the Row
drop-down list to show all content items, or use the Page option at the bottom of the table to go to the
next page.
Alternatively, click Select All to select all content items. To deselect all, click Select None.
Step 5
Click Add Selected to add all selected content items to the delivery service. The Content Table page is
displayed with all the selected content items listed.
Click Show Filter to return to the filter and change the filter settings.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-33
Chapter 5
Configuring Services
Configuring Delivery Services
Step 6
To configure advanced settings for the content items listed, click All at the bottom of the Content Table
page, and then click Edit Selected Items. The Content Manager page is displayed with the Advanced
Settings option.
Configuring Advanced Settings
Advanced settings offer controls on how the content is delivered to the client devices.
To configure the advanced settings, do the following:
Step 1
Click the Show Advanced Settings arrow. The Advanced Settings fields are displayed (Figure 5-11),
and the arrow becomes the Hide Advanced Settings arrow.
Figure 5-11
Step 2
Content Manager Page—Advanced Settings Fields
Enter the settings as appropriate. See Table 5-15 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-34
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-15
Advanced Settings for Serving Content
Field
Description
Content Serving Time
High Priority Content
Specifies the importance, and therefore the processing order, of the item
acquisition or crawl task.
Start Serving Time
Specifies the time for the SE to start delivering content. Use the format
dd-mm-yyyy hh:mm:ss [TMZ] format, where TMZ (the time zone) is
optional. UTC is the default. Alternatively, click the Calendar icon to
choose a date from the calendar and enter a time, and click Apply.
If you do not specify a time, content is ready for delivery as soon as it is
acquired and distributed to the SEs in the delivery service.
Stop Serving Time
Specifies the time for the SE to stop delivering content. Use the
dd-mm-yyyy hh:mm:ss [TMZ] format, where TMZ (the time zone) is
optional. UTC is the default. Alternatively, click the Calendar icon to
choose a date from the calendar and enter a time, and click Apply.
If you do not specify a time, content continues to be available for delivery
until you remove it from the delivery service either by changing the local
Manifest file, using the Content Removal page, or renaming the delivery
service. For information about the Content Removal page, see the
“Removing Content” section on page 8-36.
Authentication
Use weak SSL
certificate
If checked, allows acceptance of expired or self-signed certificates during
authentication.
Disable basic
authentication
If checked, NTLM headers are not stripped off that would allow fallback to
the basic authentication method while acquiring content.
Windows Media
Playback
Authentication
Sets the authentication for Windows Media playback to one of the
following:
•
As acquired—Requires authentication on playback based on settings
from origin server.
•
Require authentication—Requires authentication upon playback.
•
No authentication—Does not require authentication upon playback.
User Name
Name of the user for authentication.
Password
Password of the user for authentication.
User Domain Name
NTLM user domain name for the NTLM authentication scheme.
URL Settings
Ignore Query String
If checked, ignores any string after the question mark (?) character in the
requested URL for playback.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-35
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-15
Field
Advanced Settings for Serving Content (continued)
Description
Content Settings
TTL
Time period for revalidation of content. Select unit of measure from the
drop-down list.
If no TTL is entered, the content is fetched only once, and its freshness is
never checked again.
Note
Retry Interval
Step 3
Revalidation is enabled by default for the Web Engine.
Time period in which the Content Acquirer can attempt to acquire the
content again if the acquisition fails.
Click Submit to process the content request. When you click Submit, the local Manifest file for this
delivery service is automatically reparsed, changes are detected, and the corresponding items are
acquired or removed. This action, however, does not trigger a recheck of all the content in the delivery
service.
Content Table
The Content Table page (Figure 5-13) offers the task bar functions described in Figure 5-12.
Figure 5-12
Content Table Task Bar Icons
The Refresh Table icon refreshes the content table.
The Add Content icon allows you to add content items by displaying the Content Manager page.
To delete a content item, check the check box next to each item you want to delete, and click the Delete
Selected Items icon. To select all content items, click All. To deselect all content items, click None.
Figure 5-13
Content Table Page
For information on the Manage Host and Proxy Settings icon, see the “Configuring Proxy Server
Settings” section on page 5-37.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-36
Chapter 5
Configuring Services
Configuring Delivery Services
After you save the CDSM-generated Manifest file by clicking Submit in the Content Manager page, you
can save the Manifest file locally, and modify it. Choose the content item in the table, and click the Save
Settings Locally icon in the task bar. A web browser window with the CDSM-generated Manifest file
elements is displayed. Choose the File Save As option, enter a name for the Manifest file, and click OK.
The Manifest file is saved on your PC. See Appendix B, “Creating Manifest Files,” for more information.
To acquire configured content items immediately, click the Process Content Changes icon in the task
bar.
Note
If you change the Manifest file that you saved, and you want to use that Manifest file instead of the
content that you defined in the CDSM, or if you want to use the Manifest file for another delivery service,
then you must use the Specify external manifest file method and point to the Manifest file. When you
change the content acquisition method, any content items that you added are removed. For information
about the Manifest file, see the “Identifying Content Using a Manifest File” section on page 5-38 and
Appendix B, “Creating Manifest Files.”
To edit multiple content items, check the check box next to each item you want to edit, and click Edit
Selected Items.
Configuring Proxy Server Settings
When the Content Acquirer cannot directly access the origin server, because the origin server is set up
to allow access only by a specified proxy server, you can configure acquisition through a proxy server.
When a proxy server is configured for the Content Acquirer, the Content Acquirer contacts the proxy
server instead of the origin server, and all requests to that origin server go through the proxy server.
Note
Content acquisition through a proxy server is supported only for HTTP requests.
Note
Before configuring a proxy server, verify that the Content Acquirer is able to ping the proxy server. If
the proxy is not servicing the configured port, you will get the message: “failed: Connection refused.”
To configure a proxy server for content items identified using the CDSM, do the following:
Step 1
From the Content Table page, click the Manage Host and Proxy Settings icon in the task bar.
The Content Hosts Table page is displayed, listing all previously created host URLs, the number of
content items for each host, and a proxy server (if configured).
To return to the Content Table page, click Return to Content Listing.
Step 2
Check the check box next to each host you want to configure with a proxy server.
Step 3
Click Manage Proxy for Selected Hosts. The Proxy Server page is displayed.
Under the Defining Proxy Server for the Following Hosts heading, a bulleted list of host servers is
displayed for which proxy servers are being configured.
Step 4
In the Proxy Server Specifications area, enter the settings as appropriate. See Table 5-16 for a description
of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-37
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-16
Proxy Server Fields
Field
Description
Proxy Host
Hostname or IP address of the proxy server used by the Content Acquirer for
content acquisition. When you use a domain name instead of an IP address,
make sure that the domain name can be resolved by the DNS servers.
Proxy Port
Port number of the proxy server on which the Content Acquirer fetches content.
The range is from 1 to 65535.
Disable Basic
Authentication
When checked, NTLM headers cannot be stripped off that would allow fallback
to the basic authentication method.
If you leave this check box unchecked, NTLM authentication headers can be
stripped to allow fallback to the basic authentication method and the username
and password information can be passed to the origin server in clear text with a
basic authentication header.
User Name
Name of the user to be authenticated to fetch the content.
Password
Password of the user to pass authentication from the proxy.
Note
Step 5
If the specified proxy fails, the Content Acquirer, by default, contacts the origin server directly
and tries to fetch the content.
Click Add to add the proxy server.
To edit the proxy server settings, choose the proxy server from the Select a Proxy Server list, and click
Edit. The values for the proxy server are displayed in the Proxy Server Specification section. Once you
have finished modifying the settings, click Update.
To delete the proxy server settings, choose the proxy server from the Select a Proxy Server list, and click
Delete.
Step 6
To assign the proxy server to the host or hosts listed on this page, choose a proxy server from the Select
a Proxy Server list, and click Save Assignment. The Content Hosts Table page is displayed.
Identifying Content Using a Manifest File
The Manifest file provides information about the content to be prefetched, or fetched at a later time (as
in hybrid ingest), or provides information about live content streamed through the delivery service.
Note
Before configuring the CDSM to receive the Manifest file, you need to create one. See Appendix B,
“Creating Manifest Files” for details on creating a Manifest file. After you create the Manifest file, use
the Manifest Validator utility to verify the syntax. See the “Manifest Validator Utility” section on
page B-15 for more information.
Note
If a Manifest file is located on an Origin server that requires custom HTTP header authentication,
fetching the Manifest file by using the Specify external manifest file method fails. The Manifest file
must be located on a server that does not require custom HTTP header authentication.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-38
Chapter 5
Configuring Services
Configuring Delivery Services
To configure the Manifest file settings, do the following:
Step 1
Choose Services > Service Definition > Delivery Services > Delivery Service Content. The Content
Table page is displayed with Use GUI to specify content acquisition as the method.
Step 2
To change to the Specify external Manifest file method, do the following:
a.
Click Change Method.
b.
From the drop-down list choose, Specify external manifest file.
c.
Click Save.
d.
In the confirmation dialog box, click OK.
The Content Manager page displays the Manifest file settings (Figure 5-14).
Note
When you change the content acquisition method from Use the GUI to specify content
acquisition to Specify external Manifest file for an existing delivery service, any content items
that you added using the CDSM are removed. To save the existing settings, click the Save
Settings Locally icon in the task bar.
Figure 5-14
Step 3
Content Manager Page—Manifest File Settings
Enter the settings as appropriate. See Table 5-17 for a description of the fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-39
Chapter 5
Configuring Services
Configuring Delivery Services
Table 5-17
Manifest File Settings Fields
Field
Description
Define Basic Manifest Settings
Manifest URL
Address of the Manifest file for the delivery service. The Manifest
URL must be a well-formed URL. If the protocol (FTP, HTTP, or
HTTPS) for the URL is not specified, HTTP is used.
To validate the Manifest file from this page, click Validate. A new
window displays the validation results. For more information, see
the “Manifest Validator Utility” section on page B-15.
Check Manifest Every
Frequency, in minutes (0 to 52560000), at which the Content
Acquirer assigned to the delivery service checks for updates to the
Manifest file.
To fetch the Manifest file now, click Fetch Manifest Now.
Weak Certificate Verification
When checked, enables weak certificate verification for fetching the
Manifest file. This is applicable when the Manifest file is fetched
using HTTPS.
Note
Manifest Username
To use weak certification for content ingest, you need to
specify weak certification within the Manifest file.
Username of the account that is allowed to fetch the Manifest file
from the server. The Manifest username must be a valid ID. If the
server allows anonymous login, the user ID can be null.
Note
The Manifest Username and Manifest Password fields allow
you to enter any secure login information needed to access
the Manifest file at its remote location.
Manifest Password
Password for the user.
Confirm Password
Password confirmation.
Define Manifest Proxy Information
Disable All Proxy
Disables the outgoing proxy server for fetching the Manifest file.
Any outgoing proxy server configured on the Content Acquirer is
bypassed, and the Content Acquirer contacts the server directly.
Proxy Hostname
Hostname or IP address of the proxy server used by the Content
Acquirer to retrieve the Manifest file.
Proxy Port
Port number of the proxy sever where the Content Acquirer fetches
the Manifest file. The range is from 1 to 65535.
Proxy Username
Name of the user to be authenticated to fetch the Manifest file.
Proxy Password
Password of the user to pass authentication on the proxy.
Confirm Password
Re-entry of the same password for confirmation to pass
authentication on the proxy.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-40
Chapter 5
Configuring Services
Configuring Delivery Services
Note
When you configure a proxy server in the Manifest File Settings page, the proxy configuration
is valid only for acquiring the Manifest file itself and not for acquiring the delivery service
content. Requests for the Manifest file go through the proxy server, whereas requests for content
go directly to the origin server.
Step 4
Click Submit to save the settings.
Step 5
To fetch a new or updated Manifest file, click Fetch Manifest Now. You are prompted to confirm your
decision.
When you click this button, a process initiates that checks to see if the Manifest file has been updated,
and that the updated Manifest file has been downloaded and reparsed. Also, regardless of whether the
Manifest file has been updated, all content for the delivery service is rechecked and any new content is
ingested, unless the ttl attribute in the Manifest file is set to a negative number. For more information,
see the “Refreshing and Removing Content” section on page B-13.
Note
Step 6
Content that is removed from the Manifest file is made unavailable as soon as the updated
Manifest file is fetched. Obsolete content is not immediately deleted from the delivery service
cache, but is eventually removed to make room for new content.
To force the replication of content and refresh the information, do the following:
a.
In the left-panel menu, click Replication Status. The Replication Status page is displayed.
b.
In the “View Detailed Replication Status for Delivery Service by Device” section, run a search for
a selected device. The Replication Items are displayed.
c.
Click the Force Replication information refresh icon in the task bar. You are prompted to confirm
your decision.
For more information on delivery service replication, see the “Replication Status for a Delivery
Service” section on page 7-33.
Proxy Server Settings
There are three ways to configure the proxy server when using a Manifest file to ingest content: through
the CDSM, through the CLI, or through the Manifest file. If you need to configure the SE to use the
proxy for both caching and prefetched content, use the CLI to configure the proxy. The CLI command
is a global configuration command that configures the entire SE to use the proxy. If only the Content
Acquirer portion of the SE needs to use the proxy for acquiring prefetched content, use the Manifest file
to specify the outgoing proxy. When you configure the proxy server in the Manifest file, you are
configuring the Content Acquirer to use the proxy to fetch content for the delivery service.
Note
Proxy configurations in the Manifest file take precedence over proxy configurations in the CLI.
Furthermore, a noProxy configuration in the Manifest file takes precedence over the other proxy server
configurations in the Manifest file.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-41
Chapter 5
Configuring Services
Configuring Programs
Verifying Content Acquisition
After you have configured the content acquisition method, you can verify that the content has been
ingested by logging in to the SE acting as the Content Acquirer for the delivery service and using the
cdnfs browse command.
The cdnfs browse command is an interactive command and has the following subcommands used to
view CDS network files and directories:
ContentAcquirer# cdnfs browse
------ CDNFS interactive browsing -----dir, ls:
list directory contents
cd,chdir: change current working directory
info:
display attributes of a file
more:
page through a file
cat:
display a file
exit,quit: quit CDNFS browse shell
The ls command lists the websites as directories. File attributes and content can be viewed using the
cdnfs browse sub-commands.
For more information about the cdnfs command, see Cisco Internet Streamer CDS 3.2 Command
Reference. For online documentation, see the “Related Publications” section on page xx.
Configuring Programs
A program in the CDS is defined as a scheduled live or rebroadcast event that streams content to client
devices. The CDS streams live or rebroadcast content by using the Movie Streamer, Windows Media
Streaming, or Flash Media Streaming engine. For more information, see the “Programs” section on
page 2-20.
To view existing programs, see the “Viewing Programs” section on page 5-54.
Each live program can have up to ten different playtimes scheduled. The program is broadcast from all
Service Engines simultaneously.
Flash Media Streaming uses Real Time Media Protocol (RTMP) to stream live content by dynamic
proxy. Configuration of live or rebroadcast programs is not required. When the first client requests live
streaming content, the stream is created. For more information, see the “Live Streaming” section on
page 1-29.
Caution
If you have configured delivery services for live programs, make sure there are no external proxy servers
physically located between your receiver SEs and your Content Acquirer that require proxy
authentication. Also, make sure that proxy authentication is not enabled on any receiver SEs that might
be in the logical, hierarchical path between the Content Acquirer and the receiver SE that is going to
serve the live stream to the requesting clients. If a live stream encounters any device that requires proxy
authentication, the stream is dropped before it reaches its destination.
Note
All SEs in a Windows Media live delivery service must have Real Time Streaming Protocol with TCP
(RTSPT) enabled, because SEs must use the RTSPT protocol to communicate with each other. RTSPT
is enabled by default.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-42
Chapter 5
Configuring Services
Configuring Programs
Tip
For information about verifying a live or rebroadcast program, see Appendix K, “Verifying the Internet
Streamer CDS.”
Note
The following rules apply to live splitting for Movie Streamer:
1.
For unicast streaming, the client request must be sent by RTSP.
2.
For multicast streaming, the client request must be sent by HTTP.
Multicast Live Stream Interruptions
During a Windows Media live broadcast, any interruption of the live stream that lasts five minutes or
longer causes the multicast broadcast to cease for the duration of the currently scheduled period. If the
live stream is interrupted for less than five minutes, the broadcast resumes.
Live stream interruptions can be caused by unexpected encoder failures or by an operational restart. If
the live stream stops for more than five minutes and resumes later while the program is still scheduled,
you can modify the schedule or any other attribute of the program (such as the description) to trigger a
restart of the multicast broadcast. Restarting might take up to five minutes under these circumstances.
This does not apply to unicast delivery of a Windows Media live event or to Movie Streamer live
programs.
Defining a Program
To define a live or rebroadcast program, do the following:
Step 1
Choose Services > Live Video > Live Programs. The Program Table page is displayed.
Step 2
Click the Create New icon in the task bar. The Program Definition page is displayed.
To edit an existing program, click the Edit icon next to the program name.
Step 3
In the Name field, enter a unique name for the program.
Step 4
From the Type drop-down list, choose a program type.
Step 5
Check the Auto Deletion check box if you want the program to be automatically deleted 24 hours after
it has finished. This option only applies to live programs.
Step 6
Check the Block per Schedule check box if you want the live program to stop all active streams when
the scheduled playtime ends.
Step 7
In the Description field, enter information about the program.
Step 8
Click Submit to save the settings.
You have defined the type of program that you want to configure. Proceed to the section for configuring
that type of program:
•
To configure Movie Streamer live and Windows Media live programs, see the next section,
“Configuring Live Programs.”
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-43
Chapter 5
Configuring Services
Configuring Programs
•
To configure Windows Media rebroadcast and Movie Streamer rebroadcast programs, see the
“Configuring a Rebroadcast” section on page 5-50.
For information about copying a program, see the “Copying a Program” section on page 5-57.
Configuring Live Programs
Once you have defined the program type, you must select a live delivery service, configure the streaming,
and create a schedule. This procedure takes you through these steps and assumes you have already
defined the program (see the “Defining a Program” section on page 5-43).
To configure a Movie Streamer live or Windows Media live program, do the following:
Step 1
After you have chosen a program from the Program Table page, click Select Live Delivery Service. The
Select Live Delivery Service page is displayed listing all the live delivery services configured.
To set the QoS value for live programs, set the QoS value for the delivery service. See the “Service
Definition” section in the “Creating Delivery Service” section on page 5-15 for more information.
Step 2
Click the radio button next to the name of the live delivery service you want to associate with the
program and click Submit. Alternatively, click the Create New Live Delivery Service icon in the task
bar.
If you are creating a new live delivery service, the New Live Delivery Service page is displayed.
a.
The Name field is automatically populated with a unique delivery service name. If you wish to
change the name given by default, enter a unique name for the delivery service in this field.
b.
From the Content Origin drop-down list, choose a Content Origin.
c.
Click Submit to save the settings.
SE and Content Acquirer Assignment or Device Group and Content Acquirer Assignment
Step 3 through Step 7 use the Assign Service Engines option to describe the procedure of assigning the
Service Engines to the live program and selecting one of them as the Content Acquirer. If you have
device groups defined, you can use the Assign Device Groups option instead. To assign device groups,
follow Step 3 through Step 7 and substitute Device Groups for each instance of SE.
Step 3
From the left-panel menu, choose Assign Service Engines. The Service Engine Assignment page is
displayed (Figure 5-15).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-44
Chapter 5
Configuring Services
Configuring Programs
Figure 5-15
Step 4
Service Engine Assignment Page
Click the Assign icon (blue cross mark) next to the SE you want to assign to this delivery service. Or, in
the task bar, click the Assign All Service Engines icon. The SE assignment states are described in
Figure 5-16.
Figure 5-16
SE Assignment State
A green arrow wrapped around the blue cross mark indicates an SE assignment is ready to be submitted.
To unassign an SE, click this icon.
Step 5
From the Assign Content Acquirer drop-down list in the task bar, choose an SE to be the Content
Acquirer for this live delivery service.
The list contains all SEs currently assigned to the delivery service.
Step 6
Check the Primed check box for each SE you want to prime with the live stream. For more information
about priming, see the “Priming a Live Delivery Service” section on page 5-49.
Step 7
Click Submit to save the SE and Content Acquirer assignments.
A green circle with a check mark indicates an SE is assigned to this delivery service. To unassign the
SE, click this icon, or click the Unassign All Service Engines icon in the task bar. Click Submit to save
the changes.
Step 8
In the left-panel menu, choose Live Streaming. The Live Stream Settings page is displayed.
The Live Stream Setting page differs depending on whether you are configuring a Movie Streamer live
stream or a Windows Media live stream.
Step 9
Enter the settings as appropriate. See Table 5-18 for a description of the Windows Media Live Stream
Settings fields, and Table 5-19 for a description of the Movie Streamer Live Stream Settings fields.
Note
The string “ipfwd” cannot be used as the program name or in the URL because ipfwd is a
keyword used in the IP-forwarding feature.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-45
Chapter 5
Configuring Services
Configuring Programs
Table 5-18
Windows Media Live Stream Settings Fields
Field
Description
Live Source URL
The URL of the origin Windows Media encoder or Windows Media
server using the following format:
•
http://WMencoder_or_WMStreamerServer:port/path/file
•
rtsp://WMencoder_or_WMStreamerServer:port/path/file
For encoder failover, you can specify more than one encoder. Separate
live source URLs in the list by using a semicolon (;).
Note
If you use a .wsx file as the Live Source URL and specify the
encoders within the .wsx files, failover does not work for
unicast-in multicast-out. We recommend you use a managed
live-based encoder with redundancy, as it supports encoder
failure with all type of streams.
Note
If the Live Source URL is changed, the existing session
continues to use the old URL and does not move to the new one.
Enable Unicast Delivery to
Client
If enabled, the program uses unicast transmission.
Unicast URL Reference
If Enable Unicast Delivery to Client is checked, this field is
auto-populated with a list of suggested URLs created from the Origin
Server and the Service Routing Domain Name fields associated with the
live delivery service. Choose one from the drop-down list.
Enable Multicast Delivery
to Client
If enabled, the program uses multicast transmission.
Enable Multicast Delivery
to SE
If enabled, multicast transmission is used to distribute content from the
Content Acquirer to the SEs. This option is only for multicast-enabled
networks. If your network is not enabled for multicast, this feature does
not function properly.
Multicast URL Reference
If Enable Multicast Delivery to Client is checked, this field is
auto-populated with a list of suggested URLs created from the Origin
Server and the Service Routing Domain Name fields associated with the
live delivery service. Choose one from the drop-down list.
NSC Reference for
Multicast
The URL for the NSC file used for a server-side playlist as the media
source in a multicast program. This field is available when Enable
Multicast Delivery to Client is checked.
Multicast Address and Port
The multicast address and port to use for streaming this program using
multicast. The address range is 224.0.0.0 to 239.255.255.255. The port
number must be even, and within the range of 1 to 65535. These values
must be unique within the system.
Even numbered ports are for Real-Time Transport Protocol (RTP), and
odd numbered ports are for Real-Time Transport Control Protocol
(RTCP).
Multicast TTL
Specify the multicast time-to-live (number of hops). The default is 15
hops.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-46
Chapter 5
Configuring Services
Configuring Programs
Table 5-19
Movie Streamer Live Stream Settings Fields
Field
Description
Origin Server SDP File URL The URL for the Session Description Protocol (SDP) file generated on
the encoder. From the drop-down list, select either rtsp or http, and enter
the remainder of the URL in the field. The remainder of the URL format
is host [:port]/[filename], where the port and filename are optional. For
the Darwin Streaming Server encoder, you need to specify the SDP file.
For the Digital Rapid encoder, you do not need to specify the SDP file.
When you click the Auto Populate button, the Incoming Live Streams
Settings fields (the next section on the Live Streaming Settings page) are
automatically populated based on the Origin Server SDP File URL.
Backup SDP URL
The backup URL for the SDP file. This field is only for RTSP. Add a
valid backup URL and click Auto Populate. The Incoming Live Streams
Settings backup fields (the next section on the Live Streaming Settings
page) are automatically populated based on the Backup SDP URL.
The Cisco CDS only supports failover between a primary origin server
and a backup origin server for a Movie Streamer live program when the
backup origin server uses the same codec as the primary.
When you click the Auto Populate button, the Incoming Live Streams
Settings fields (the next section on the Live Streaming Settings page) are
automatically populated based on the Backup SDP URL.
Incoming Live Streams Settings
Note
Manually enter these fields when Auto Populate cannot parse the SDP URL.
Source Server
The stream source IP address.
Backup Source Server
The backup stream source IP address.
Receiving IP
For RTSP, the Primary Receiving IP is the IP address of the Content
Acquirer acting as the primary receiver. This is always unicast-in.
For HTTP, the Primary Receiving IP is the multicast-in IP address used
to broadcast the live stream.
Backup Receiving IP
For RTSP, the Backup Receiving IP is the IP address of the Content
Acquirer acting as the backup receiver. Both the primary and backup
Content Acquirer are located in the root location of the delivery service.
For HTTP, the Backup Receiving IP is the multicast-in IP address used
to broadcast the live stream.
Receiving Ports
Receiving Ports are used to define each port related to audio and video
streams.
Backup Receiving Ports
Backup Receiving Ports are used to define each port related to audio and
video streams.
Outgoing Live Streams Settings
Unicast URL Reference
This field is auto-populated with a list of suggested URLs by using the
Origin Server and the Service Routing Domain Name fields associated
with the live delivery service. Choose one from the drop-down list.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-47
Chapter 5
Configuring Services
Configuring Programs
Table 5-19
Movie Streamer Live Stream Settings Fields (continued)
Field
Description
Enable Multicast Delivery to If enabled, the program uses multicast transmission.
Client
If you wish to enable support for Content Acquirer failover, you must
check this check box. Content Acquirer failover for a live program works
only when the incoming stream is a multicast stream.
Multicast URL Reference
This field is available if the Enable Multicast Delivery to Client check
box is checked. The multicast URL reference (Announce URL) has the
following format:
http://sourceHost_or_FQDN/path/filename.sdp
This URL uses the Origin Server and the Service Routing Domain Name
and points to a meta-file (SDP) that is generated and resides on an
external server. Choose one from the drop-down list.
Multicast TTL
Specify the multicast time-to-live (number of hops). The default is 15
hops.
Multicast Address
The multicast address to use for streaming this program using multicast.
The address range is 224.0.0.0 to 239.255.255.255. These values must be
unique within the system.
Multicast Port
The multicast port to use for streaming this program using multicast.The
port number must be even and within the range of 1 to 65535. These
values must be unique within the system.
Even numbered ports are for Real-Time Transport Protocol (RTP), and
odd numbered ports are for Real-Time Transport Control Protocol
(RTCP).
Step 10
Click Submit to save the settings.
Step 11
From the left-panel menu, choose Schedule. The Schedule page is displayed.
Step 12
Click the Play Forever radio button to have the program play continuously.
Alternatively, click the Schedule Playtime radio button to schedule up to ten different playtimes. The
Playtime Editor is displayed in the page.
To edit an existing playtime, click the Edit icon next to the Initial Start Time.
To delete an existing playtime, click the Delete icon next to the Initial Start Time.
Step 13
Enter the settings for the playtime as appropriate. See Table 5-20 for a description of the fields.
Table 5-20
Playtime Fields
Field
Description
Start Playback on
Start date and time for the program.
UTC or SE (Local) Time Which clock the start time should use, UTC or SE local.
Duration
Length of the program. In the drop-down list, choose minutes, hours, or
days as the unit of time.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-48
Chapter 5
Configuring Services
Configuring Programs
Table 5-20
Playtime Fields (continued)
Field
Description
Repeat Frequency
The repeat frequency has the following options:
Repeat Forever
Repeat Until
•
Do Not Repeat—Plays once.
•
Repeat Every—Repeats every so many days, hours, or minutes.
•
Repeat Weekly—Repeats at the same hour on the days you choose.
These fields display when Repeat Every or Repeat Weekly are chosen for
Repeat Frequency.
Repeat Forever repeats the program forever using the repeat frequency set
in the previous fields.
Repeat Until repeats the program based on the repeat frequency set in the
previous fields and until the date and time specified in this field.
Step 14
Click Submit to save the settings.
Click Add Playtime to add additional playtimes to an existing schedule. The Playtime Editor is
displayed in the page.
Priming a Live Delivery Service
The first client requesting a program often experiences the longest wait time for the program to begin
playing. Users can experience long wait times because of the full RTSP negotiation that is required to
pull the live stream from the source. Delays can also occur if the edge SE has not buffered enough stream
data to fill the media player’s buffer at the time the program is requested. For Windows Media streaming,
when the buffer is not filled, some data to the client might be sent at the suboptimal line rate instead of
at the Fast Start rate.
Delivery services for unicast-managed live programs can be primed for faster start-up times. When a live
delivery service is primed, a unicast-out stream is pulled from the origin server to an SE before a client
ever requests the stream. When the first request for the stream goes out, the stream is already in the
delivery service.
Note
It is not possible to monitor non-primed streams because they are played directly from the origin server.
Primed streams can be monitored because they are buffered on the SE.
Windows Media Streaming Live Streaming Encoder Failover
In normal situations, when a new client request is received (or priming live program is enabled) the
Content Acquirer ingests the content from first encoder in the configured list (for example,
rtsp://Encoder_1:port/path/file; rtsp://Encoder_2:port/path/file).
If the first encoder is unreachable, the Content Acquirer considers it has failed and does not attempt to
contact it until the timeout period of 300 seconds has expired. The Content Acquirer attempts a
connection with the failed encoder every 300 seconds.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-49
Chapter 5
Configuring Services
Configuring Programs
The Content Acquirer selects a source encoder in the following way:
1.
If there is an existing session that is using an encoder, then select it as the source; otherwise, select
the first one in the configured list of encoders for the requested URL. If the first encoder does not
have the requested URL, try the next one in the list, until an encoder with the requested URL is
contacted.
a. If the first encoder is unreachable, try the next encoder in the list, and mark the first encoder as
bad and start the timeout interval for it.
b. If the encoder is not marked as bad, then check to see if the encoder has the content with the
requested URL.
c. If the encoder is marked as bad and the timeout interval has been reached, try the encoder. If the
timeout interval has not been reached, check the next encoder.
2.
If all the sources are marked bad and all timeout intervals have not been reached, try the encoder
that is closest to reaching the timeout interval.
Note
An alarm is raised when an encoder is requested but cannot be reached.
The Content Acquirer supports fail over for several encoders in the following ways:
Note
•
If failure occurs during streaming a session, the streaming stops and the Windows Media Player
sends another request. The reachable-encoder selection process is started as described above. The
streaming session recovers automatically. The user typically only experiences around a 60-second
freeze for RTSP URL content.
•
"The Content Acquirer continues to ingest from the reachable encoder, even if the failed encoder
recovers, for the previous streaming sessions and new incoming client requests. This provides a
better end-user experience.
Alarms from Content Acquirer are cleared when the specific encoder is reachable again, or when the
alarm is manually cleared through the CLI or the CDSM GUI.
Configuring a Rebroadcast
Once you have defined the program type for a rebroadcast program, you need to select media files,
configure the streaming, and create a schedule. This procedure takes you through these steps and
assumes you have already defined the program (see the “Defining a Program” section on page 5-43).
Note
For rebroadcast programs, media can only be selected from one delivery service. The SEs and device
groups assigned to the delivery service are selected automatically when you choose the media files for
the program.
To configure a Movie Streamer rebroadcast or Windows Media rebroadcast program, do the following:
Step 1
After you have chosen a program from the Program Table page, click Select Media. The Select Media
page is displayed.
Step 2
Choose a delivery service from the list by clicking the radio button next to the name of the delivery
service and click Show Media in Selected Delivery Service. The Media File Selection pane is
displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-50
Chapter 5
Configuring Services
Configuring Programs
Step 3
In the Criteria field, enter the search criteria for the media files you want to add to the program and click
Use Criteria. All the media files that match the search criteria are displayed.
Use an asterisk (*) to match any number of characters, or a question mark (?) to match exactly one
character. For example, use “*.mpg” for all files with the suffix “mpg,” and “file?.mpg” to match
file1.mpg, file2.mpg, and so on.
To start a new search, click Select Media.
To choose a new delivery service to choose files from, click All Delivery Services, choose a delivery
service, and click Show Media in Selected Delivery Service.
Step 4
Check the Pick check box next to each file you want to rebroadcast and click Add Media. The files are
displayed in the Media Files in Program pane.
To select all files, click All. To deselect all files, click None. The file list can span several pages. To see
the files from the other pages, click the page number, or from the Row drop-down list, select one of the
options.
Step 5
In the Media Files in Program pane, use the Up arrow and Down arrow next to each file to alter the order
of the files. Files are played in the order in which they are listed.
Note
The Up arrow and Down arrow are only displayed if the list of media files in the program is
sorted by position. If you sort the media files by name or length, the arrows are not displayed.
Note
Multiple media files can be selected for Movie Streamer rebroadcasts. Playlist content is
seamlessly updated without impacting current rebroadcasting.
To remove a media file from the list, check the Pick check box next to the file, and click Remove Media.
To select all files, click All. To deselect all files, click None.
Step 6
Click Submit to save the settings.
Note
For rebroadcast programs, media can only be selected from one delivery service. The SEs
assigned to that delivery service are selected automatically when you choose the media files for
the program. If at a later time you add new SEs to the delivery service, you must manually add
them to the program.
SE Assignment or Device Group Assignment
Step 7 through Step 9 use the Assign Service Engines option to describe the procedure of assigning the
Service Engines to the rebroadcast program. If you have device groups defined, you can use the Assign
Device Groups option instead. To assign device groups, follow Step 7 through Step 9 and substitute
Device Groups for each instance of SE.
Step 7
To add new SEs to the rebroadcast program, from the left-panel menu, choose Assign Service Engines.
The Service Engine Assignment page is displayed.
Note
SEs must have the same NTP time. Multiple SEs can be assigned for additional redundancy, but
all SEs assigned must be in different multicast domains, because all assigned SEs send packets
to the same specified multicast address.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-51
Chapter 5
Configuring Services
Configuring Programs
Step 8
Click the Assign icon (blue cross mark) next to the SE you want to assign to this delivery service. Or, in
the task bar, click the Assign All Service Engines icon. The SE assignment states are described in
Figure 5-17.
Figure 5-17
SE Assignment State
A green arrow wrapped around the blue cross mark indicates an SE assignment is ready to be submitted.
To unassign an SE, click this icon.
Step 9
Click Submit to save the SE assignments.
A green circle with a check mark indicates an SE is assigned to this delivery service. To unassign the
SE, click this icon, or click the Unassign All Service Engines icon in the task bar. Click Submit to save
the changes.
Step 10
From the left-panel menu, choose Streaming. The Streaming Settings page is displayed.
Step 11
Enter the settings as appropriate. See Table 5-21 for a description of the Windows Media Rebroadcast
Stream Settings fields, and Table 5-22 for a description of the Movie Streamer Rebroadcast Stream
Settings fields.
Table 5-21
Windows Media Rebroadcast Stream Settings Fields
Field
Description
Multicast URL Reference
The reference URL for multicast streaming has the following format:
http://SRDN/program-name.nsc.
NSC Reference for
Multicast
The URL for the NSC file used for a server-side playlist as the media
source in a multicast program.
Multicast Address and Port
The multicast address and port to use for streaming this program using
multicast. The address range is 224.0.0.0 to 239.255.255.255.
The port number must be even and within the range of 1 to 65535. These
values must be unique within the system.
Even numbered ports are for Real-Time Transport Protocol (RTP), and
odd numbered ports are for Real-Time Transport Control Protocol
(RTCP).
Multicast TTL
Specify the multicast time-to-live (number of hops). The default is 15
hops.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-52
Chapter 5
Configuring Services
Configuring Programs
Table 5-22
Movie Streamer Rebroadcast Stream Settings Fields
Field
Description
Multicast URL Reference
The reference URL for multicast streaming has the following format:
http://SRDN/programID.sdp.
Multicast TTL
Specify the multicast time-to-live (number of hops). The default is 15
hops.
Multicast Address and Port
The multicast address and port to use for streaming this program using
multicast. The address range is 224.0.0.0 to 239.255.255.255.
The port number must be even and within the range of 1 to 65535. These
values must be unique within the system.
Even numbered ports are for Real-Time Transport Protocol (RTP), and
odd numbered ports are for Real-Time Transport Control Protocol
(RTCP).
Note
Because Movie Streamer rebroadcast files can contain multiple
tracks (1 to 3), you can define up to three multicast addresses and
ports for each track in the file. Click Add Multicast
Address/Port to add another multicast address.
Step 12
Click Submit to save the settings.
Step 13
From the left-panel menu, choose Schedule. The Schedule page is displayed.
Step 14
Click the Loop Back Continuously radio button to have the program play continuously.
Alternatively, click the Schedule Playback radio button to schedule up to ten different playback times.
The Playtime Editor is displayed in the page.
To edit an existing playtime, click the Edit icon next to the Initial Start Time.
To delete an existing playtime, click the Delete icon next to the Initial Start Time.
Step 15
Enter the settings for the playtime as appropriate. See Table 5-23 for a description of the fields.
Table 5-23
Playtime Fields
Field
Description
Start Playback on
The start date and time for the program.
UTC or SE (Local) Time Which clock the start time should use, UTC or SE local.
Duration
The length of the program. In the drop-down list, choose minutes, hours, or
days as the unit of time.
Playback Options
The playback options are the following:
•
Playback Once and Stop
•
Loop for number of minutes, hours, or days
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-53
Chapter 5
Configuring Services
Viewing Programs
Table 5-23
Playtime Fields (continued)
Field
Description
Repeat Frequency
The repeat frequency has the following options:
Repeat Forever
Repeat Until
•
Do Not Repeat—Plays once.
•
Repeat Every—Repeats every so many days, hours, or minutes.
•
Repeat Weekly—Repeats at the same hour on the days you choose.
These fields display when Repeat Every or Repeat Weekly are chosen for
Repeat Frequency.
Repeat Forever repeats the program forever using the repeat frequency set
in the previous fields.
Repeat Until repeats the program based on the repeat frequency set in the
previous fields and until the date and time specified in this field.
Step 16
Click Submit to save the settings.
Click Add Playtime to add additional playtimes to an existing schedule. The Playtime Editor is
displayed in the page.
Viewing the Multicast Addresses
The multicast delivery feature is enabled by setting up a multicast address for a live or rebroadcast
program to which different client devices, configured to receive content from the same program, can
subscribe. The delivering device sends content to the multicast address set up at the delivery service,
from which it becomes available to all subscribed receiving devices.
A set of multicast addresses can be specified either in the Program API or by using the CDSM. When a
program requires a multicast address, you can specify the multicast address within the stream settings
of the program. Addresses are allocated for the life of a program.
To view the multicast addresses used by live programs and rebroadcasts, choose Services > Live Video
> Multicast Addresses. The Multicast Addresses page is displayed.
The list of multicast addresses that have been currently configured for specific programs is displayed in
the Multicast Addresses table.
Viewing Programs
The Programs Table page lists all the programs defined in your CDS network. Programs can be defined
through the CDSM or through an API. For information on adding or editing a program definition, see
the “Defining a Program” section on page 5-43.
The Programs Table page allows you to view scheduled programs by day, week, month, or year. You can
sort and filter programs by name, type, or schedule. You can also preview live programs while they are
playing. See the “Previewing a Program” section on page 5-57 for more information.
Table 5-24 describes the icons for the Programs Table page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-54
Chapter 5
Configuring Services
Viewing Programs
Table 5-24 Programs Table Icons
Icon
Function
Creates a new program. See the “Defining a Program” section on page 5-43
for more information
Creates a filtered table. Filter the table based on the field values.
Views all table entries. Click this icon to view all entries after you have
created a filtered table.
Refreshes the table.
Prints the current window.
Edits a program. See the “Defining a Program” section on page 5-43 for
more information
Previews a program.
To view all the programs defined in your CDS network, do the following:
Step 1
Choose Services > Live Video > Live Programs. The Programs Table page displays with a list of all
the programs that have been defined through either the CDSM or the Program API.
Step 2
Click the Day, Week, Month, or Year tab to view the playback schedules. Scheduled programs are listed
by start time (initial start time plus any repeat intervals). Times begin with the current device time
(current system time plus device time zone offset).
The Unscheduled tab displays all unscheduled programs defined in your CDS network. The All tab
displays all the programs defined in your CDS network. The Programs Table page opens to the All view
by default.
Step 3
Sort columns by clicking the column heading. You can also combine filtering conditions. For example,
you can filter only Windows Media live programs and then choose the Week tab to view the week of
November 23 to November 29, 2007. Table 5-25 describes the information that is displayed in this page.
Table 5-25
Programs Table Page Information
Item
Description
Tabs
Day/Week/Month/Year
Lists programs based on their schedule. The current day, week,
month, or year is displayed by default. You can navigate to the next
or previous day, week, month, or year by clicking the back or
forward arrows on either side of the date.
Unscheduled
Lists only programs with no schedule defined.
All
Lists all programs. This is the default view.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-55
Chapter 5
Configuring Services
Viewing Programs
Table 5-25
Programs Table Page Information (continued)
Item
Description
Program Listing Table
Program
Program name, which must be unique to the CDSM.
Type
Program type. Program types are:
Schedule
•
Movie Streamer live
•
Movie Streamer rebroadcast
•
Windows Media live
•
Windows Media rebroadcast
Describes the schedule. Options are:
•
None (the program has no schedule)
•
Loop continuously
•
Number of playtimes (the number of times that the program is
scheduled to be shown)
Start Time—Program start time in a scheduled view (Day, Week,
Month, or Year tab). Lists up to three start times if repeat
broadcasts are configured.
Duration—Duration of the program or the looping time in a
scheduled view (Day, Week, Month, or Year tab).
Viewing and Modifying API Programs
Programs created through APIs are based on a program file. A program file contains the elements that
define the schedule, content, and presentation parameters. It is a text file written in XML format, similar
to the Manifest file. The program file contains most of the program settings and resides on an external
server. The CDSM gets the program file, parses it, and saves the program file to the database. The
program is automatically updated at intervals by the CDSM refetching the program file and reparsing it.
The program file supports RTSP.
In contrast, programs defined using the CDSM are not based on a program file; instead, the settings
entered in the CDSM are saved directly to the database.
Programs created using an API can be viewed in the CDSM as read-only, and modifications to API
programs can be done through the API. You can also edit the API program using the CDSM; however,
if you choose this option, the information about the API program file is deleted and the program can no
longer be modified through the API. A third option is to copy the API program using the CDSM Copy
Program feature. The new copy does not contain the program file information and is treated as a
CDSM-generated program for the purposes of editing. (See the “Copying a Program” section on
page 5-57.)
You can delete any program from the list (whether created through the CDSM or through an API) in the
Programs Table page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-56
Chapter 5
Configuring Services
Copying a Program
Previewing a Program
You can preview live programs by live split or by joining a multicast broadcast. Live programs can only
be viewed during the scheduled playtime. You can preview a rebroadcast program by joining the
multicast broadcast during the scheduled playtime.
To preview a live Movie Streamer or Windows Media program or scheduled rebroadcast, do the
following:
Step 1
Choose Services > Live Video > Live Programs. The Programs Table page is displayed.
Step 2
Click the Day, Week, Month, or Year tab.
Step 3
Click the Play icon next to the name of a program. A program preview window pops up, displaying the
program information with links to view the program.
Note
Step 4
The Play icon only appears while the live program is playing. If a program is not currently
playing, you cannot view it.
Click the URL reference link for the program. You have the option to choose a multicast or unicast URL
reference, if such are defined for the program. A new window with the URL reference opens.
To successfully view the program, you must meet these conditions:
•
You must be able to access the client network.
•
You must have a Windows Media plug-in installed to view Windows Media live programs.
•
You must have a QuickTime plug-in installed to view Movie Streamer live programs.
Copying a Program
The copy program feature allows you to create a copy of an existing program and then modify a subset
of attributes, which eliminates the need to re-enter all the program settings each time you create
programs with similar characteristics.
When you copy a program, a duplicate of the program is created and saved to the database. Any changes
that you make to the new copy of the program do not affect the original program and vice versa. Note,
however, that if multicast is configured, the multicast address and port cannot be copied. These
parameters must be unique across the system. If a program address pool is configured, these parameters
can be automatically selected by the system.
To create a copy of an existing program, do the following:
Step 1
Choose Services > Live Video > Live Programs. The Programs Table page is displayed.
Step 2
Click the Edit icon next to the name of the program that you want to copy. The Program Definition page
is displayed.
Step 3
Click the Copy Program icon in the task bar. You are prompted to confirm your decision. Click OK.
The window refreshes, displaying ProgramName_dup in the Name field.
Step 4
Edit any program information that you want to change. (See the “Defining a Program” section on
page 5-43.)
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-57
Chapter 5
Configuring Services
Copying a Program
Note
You cannot change the program type.
Step 5
Click Submit to save the settings.
Step 6
Edit any of the other program properties found in the left-panel menu, such as the program schedule,
program, or device assignments.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
5-58
CH A P T E R
6
Configuring the System
This chapter provides information on configuring the system parameters of the CDS. This chapter has
the following major topics:
•
Configuring AAA, page 6-1
•
Changing a Password, page 6-7
•
Configuring System Settings, page 6-7
•
Viewing or Downloading XML Schema Files, page 6-22
For information on logs, see the “System Audit Logs” section on page 7-8. For information on upgrading
the CDS software, see the “Software Upgrade” section on page 8-1. For information on the ports used
by the CDS, see the “System Port Numbers” section on page 7-9.
Configuring AAA
Authentication determines who the user is and whether that user should be allowed access to the network
or a particular device. It allows network administrators to bar intruders from their networks. It may use
a simple database of users and passwords. It can also use one-time passwords.
Authorization determines what the user is allowed to do. It allows network managers to limit which
network services are available to different users.
Accounting tracks what users did and when they did it. It can be used for an audit trail or for billing for
connection time or resources used (bytes transferred).
Collectively, authentication, authorization, and accounting are sometimes referred to as AAA. Central
management of AAA means the information is in a single, centralized, secure database, which is much
easier to administer than information distributed across numerous devices.
In the CDS network, login authentication and authorization are used to control user access and
configuration rights to the CDSM, SEs, and SRs. There are two levels of login authentication and
authorization:
•
Device
•
CDSM
In a CDS network, user accounts can be created for access to the CDSM and, independently, for access
to the SEs and SRs that are registered to the CDSM.
This section covers login authentication and authorization for the CDSM. For information about device
login authentication and authorization, see the “Login Access Control” section on page 4-50 and the
“Authentication” section on page 4-58.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-1
Chapter 6
Configuring the System
Configuring AAA
Login authentication is the process by which CDSM verifies whether the person who is attempting to
log in has a valid username and password. The person logging in must have a user account registered
with the device. User account information serves to authorize the user for login and configuration
privileges. The user account information is stored in the AAA database. When the user attempts to log
in, the CDSM compares the person’s username, password, and privilege level to the user account
information that is stored in the database.
Each user account can be assigned to a role and a domain. A role defines which CDSM configuration
pages the user can access and which services the user has authority to configure or modify. A domain
defines which entities in the network the user can access and configure or modify. You can assign a user
account to zero or more roles, and to zero or more domains.
Creating, Editing, and Deleting Users
Note
This section is addressed to users with administrator-level privileges (admin users) only.
Two default user accounts are preconfigured in the CDSM. The first account, called admin, is assigned
the administrator role that allows access to all services and access to all entities in the system. This
account cannot be deleted from the system, but it can be modified. Only the username and the role for
this account are unchangeable. To change the password for this account, use the username admin
password <password> command through the CLI.
The second preconfigured user account is called default. Any user account that is authenticated but has
not been registered in the CDSM gets the access rights (role and domains) assigned to the default
account. This account is configurable, but it cannot be deleted nor can its username be changed.
When you create a new user account in the CDSM, you have the option to create the user account in the
CLI for the CDSM device at the same time. Using this option to create the new account in the CLI
provides the following benefits:
•
User account is created in the primary and standby CDSM management databases and in the CDSM
CLI from one central point.
•
Users can change their passwords, and the password changes are propagated to a standby CDSM.
If you choose to create the user account from the CDSM without creating the user account in the CDSM
CLI at the same time, the following results apply:
•
User account is created in the primary and standby CDSM management databases.
•
No user account is created in the CDSM CLI, and the user cannot log in to the CDSM until an
account is created from the CLI.
•
Local users cannot change their passwords using the CDSM.
•
Local users can change their passwords using the CLI; however, the password changes are not
propagated from the CLI to the CDSM databases when the CLI user option is enabled in the CDSM.
If a user account has been created from the CLI only, when you log in to the CDSM for the first time,
the Centralized Management System (CMS) database automatically creates a user account (with the
same username as configured in the CLI) with default authorization and access control. However, to
change the password in this scenario, the user account must be explicitly configured from the CDSM
with the CLI user option enabled.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-2
Chapter 6
Configuring the System
Configuring AAA
To create or edit a user account, do the following:
Step 1
Choose System > AAA > Users. The User Table page is displayed.
Table 6-1 describes the icons for the User Table page.
Table 6-1
Icon
User Table Icons
Function
Creates a new entry.
Edits an entry.
Creates a filtered table. Filter the table based on the field values.
Views all table entries. Click this icon to view all entries after you
have created a filtered table.
Refreshes the table.
Prints the current window.
Step 2
Click the Create New icon in the task bar. The User Account page is displayed.
To edit an account, click the Edit icon next to the username.
Note
Step 3
The User Account page can only be accessed by users with administrator-level privileges.
In the Username field, enter the user account name. The username must be between 4 and 32 characters
in length, and begin with a letter.
The following characters are not permitted in a username: ? . / ; [ ] { } " @ = |.
Step 4
If you want to create a local user account with a password and privilege level from the CDSM, check the
Create CLI User check box. The user account is created automatically in the CLI. To prevent the
creation of a CLI user account from the GUI, leave the check box unchecked.
Step 5
In the Password field, enter a password for the CLI user account, and re-enter the same password in the
Confirm Password field.
The password strength must be a combination of alphabetic character, at least one number, at least one
special character, and at least one uppercase character.
The following characters are not allowed: ?./;[]{}"@=|
Step 6
From the Privilege Level drop-down list, choose a privilege level for the CLI user account. The choices
are 0 (zero) (normal user) or 15 (superuser). The default value is 0.
Note
A superuser can use privileged-level EXEC commands, whereas a normal user can use only
user-level EXEC commands.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-3
Chapter 6
Configuring the System
Configuring AAA
Step 7
In the Username Information area, enter the following information about the user: First Name, Last
Name, Phone Number, Email Address, Job Title, and Department.
Step 8
In the Comments field, enter any additional information about this account.
Step 9
Click Submit to save the settings.
Step 10
From the left-panel menu, click Role Management. The Role Management Table page is displayed.
Table 6-1 describes the icons for the Role Management page.
Table 6-2
Icon
Role Management Icons
Function
Creates a new entry.
Edits an entry.
Creates a filtered table. Filter the table based on the field values.
Views all table entries. Click this icon to view all entries after you
have created a filtered table.
Refreshes the table.
Assigns all roles.
Removes all roles.
Views read-only items.
Indicates that the current transaction was successfully completed.
To add roles, see the “Creating, Editing, and Deleting Roles” section on page 6-5.
To view the setting for the role, click the View (eyeglasses) icon next to the role.
Step 11
Click the Assign icon (blue cross mark) next to each role name you want to assign to the user account.
To remove the role from the user account, click the Assign icon again.
To assign all roles, click the Assign all Roles icon in the task bar. To unassign all roles, click the Remove
all Roles icon in the task bar.
Step 12
Click Submit to save the settings.
A green arrow wrapped around the blue cross mark indicates an SE assignment is ready to be submitted.
To unassign an SE, click this icon.
Step 13
From the left-panel menu, click Domain Management. The Domain Management Table page is
displayed.
To add domains, see the “Creating, Editing, and Deleting Domains” section on page 6-6.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-4
Chapter 6
Configuring the System
Configuring AAA
To view the setting for the domain, click the View (eyeglasses) icon next to the domain.
Step 14
Click the Assign icon next to each domain name you want to assign to the user account.
To remove the domain from the user account, click the Assign icon again.
To assign all domains, click the Assign All icon in the task bar. To unassign all domains, click the
Remove All icon in the task bar.
Step 15
Click Submit to save the settings.
To delete a user, in the User Table page, click the Edit icon next to the username, and from the User
Account page, click the Delete icon in the task bar.
Note
Deleting a user account from the CLI does not delete the corresponding account in the CDSM database.
User accounts created in the CDSM should always be deleted from within the CDSM.
Creating, Editing, and Deleting Roles
Although the CDSM provides many types of services, not all users have access to all services. Users are
assigned a role, which indicates the services to which they have access. A role is a set of enabled
services.
Each user account can be assigned zero or more roles. Roles are not inherited or embedded. The CDSM
provides one predefined role, known as the admin role. The admin role has access to all services and all
CDS network entities.
Note
The admin user account, by default, is assigned to the role that allows access to all domains and all
entities in the system. It is not possible to change the role for this user account.
To create or edit a role, do the following:
Step 1
Choose System > AAA > Roles. The Roles Table page is displayed.
Step 2
Click the Create New icon in the task bar. The Role page is displayed.
To edit a role, click the Edit icon next to the role name.
Step 3
In the Name field, enter the name of the role.
Step 4
To enable read-only access for this role, check the Read-Only check box. Users assigned to this role are
only be able to view the CDSM pages. They are not able to make any changes.
Step 5
To expand a listing of services under a category, click the folder, and then check the check box next to
the service or services you want to enable for this role. To choose all the services under one category
simultaneously, check the check box for the top-level folder.
Step 6
In the Comments field, enter any comments about this role.
Step 7
Click Submit to save the settings.
To delete a role, in the Roles Table page, click the Edit icon next to the role name. Once the Role page
is displayed, click the Delete icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-5
Chapter 6
Configuring the System
Configuring AAA
Creating, Editing, and Deleting Domains
A domain is a set of CDS network entities or objects that make up the CDS network. Whereas a role
defines which services a user can perform in the CDS network, a domain defines the entities to which
the user has access. An entity can be a Service Engine, a device group, or a delivery service. These
predefined entities are treated like services and can be enabled or disabled when you set up user roles.
When you configure a domain, you can choose to include Service Engines, device groups, or delivery
services in the domain.
To create or edit a domain, do the following:
Step 1
Choose System > AAA > Domains. The Domains Table page is displayed.
Step 2
Click the Create New icon in the task bar. The Domain page is displayed.
To edit a domain, click the Edit icon next to the domain name.
Step 3
In the Name field, enter the name of the domain.
Step 4
From the Entity Type drop-down list, choose Service Engines, Device Groups, or Delivery Services.
Step 5
In the Comments field, enter any comments about this domain.
Step 6
Click Submit to save the settings. If the entity type you chose has not already been assigned to the
domain, then a message displays indicating that the entity type has not been assigned.
Step 7
From the left-panel menu, click Entity Management. The Entity Management page is displayed.
Step 8
Click the Assign icon (blue cross mark) next to each entity name you want to include. A green arrow
wrapped around the blue cross mark indicates an entity is assigned.
To assign all entities in the domain, click the Assign All icon in the task bar.
To remove an entity from the domain, click the Assign icon again.
To remove all entities from the domain, click the Remove All icon in the task bar.
Step 9
Click Submit to save the settings.
To delete a domain, in the Domain Table page click the Edit icon next to the domain name. Once the
Domain page is displayed, click the Delete icon in the task bar.
Creating a Domain Example
Following is an example of the tasks need to create a domain for a non-administrator user to be able to
see a playlist view and have rights access to the SE, delivery service, and device group assigned to the
playlist:
1.
Choose System > AAA > Domains, create a domain for entity type Delivery Services. Make sure
the delivery service the playlist uses is assigned to this domain.
2.
Choose System > AAA > Domains, create a domain for entity type Service Engine.Make sure the
SE the playlist uses is assigned to this domain.
3.
Choose System > AAA > Domains, create a domain for entity type Device Group. Make sure the
Device Group the playlist uses is assigned to this domain.
Choose System > Users, select a user and assign the domains just configured to this user.
The non-administrator user should see the playlist.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-6
Chapter 6
Configuring the System
Changing a Password
Changing a Password
If you are a user without admin privileges and you are logged in to the CDSM, you can change your own
CDSM and CLI user password if you meet the following requirements:
Caution
•
Your CLI user account and password were created in the CDSM and not in the CLI.
•
You are authorized to access the Password page.
We do not recommend changing the CLI user password from the CLI. Any changes to CLI user
passwords from the CLI are not updated in the management database and are not propagated to the
standby CDSM. Therefore, passwords in the management database do not match a new password
configured in the CLI.
The advantage of initially setting passwords from the CDSM is that both the primary and the standby
CDSMs are synchronized, and CDSM users do not have to access the CLI to change their passwords.
To change the CDSM and CLI user password for the user account that is currently logged in to the
CDSM, do the following:
Step 1
Choose System > Password. The Password page is displayed.
Step 2
In the New Password field, enter the changed password.
The following characters are not allowed: ?./;[]{}"@=|
Step 3
In the Confirm New Password field, re-enter the password for confirmation.
Step 4
Click Submit to save the settings.
Configuring System Settings
This section covers the following topics:
•
System Properties
•
Configuring Device Offline Detection
•
Configuring Distribution QoS
•
Configuring Service Routing
•
CDN Selector File Registration
•
Authorization File Registration
•
NAS File Registration
•
HTTPS Streaming
•
Configuring the CDSM to Communicate with an External System
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-7
Chapter 6
Configuring the System
Configuring System Settings
System Properties
To modify the system properties, do the following:
Step 1
Choose System > Configuration > System Properties. The System Properties page is displayed.
Step 2
Click the Edit icon next to the system property you want to change. The Modify Config Property page
is displayed.
Step 3
For true or false values, choose a setting from the Value drop-down list. For other values, enter a new
value. The range is displayed for each numeric value.
Table 6-3 describes the system properties.
Table 6-3
System Properties Fields
Field
Description
cdsm.gui.rowCount
Row count for all pages containing table. The default is 10
cdsm.session.timeout
Length of a Content Distribution Manager session (in minutes). The
default is 10. The range is from 5 to 120.
DeviceGroup.overlap
SE feature overlapping (enable or disable).
System.CmsUnsProgram
Sync.Interval
Interval by which CMS synchronizes program import UNS objects (in
minutes). The default is 1440 minutes. The range is from 1 to 43200.
System.datafeed.pollRate
Poll rate between the SE or the SR and the CDSM (in seconds). The
default is 300. The range is from 30 to 1800.
System.device.recovery.key
Device identity recovery key. This property enables a device to be
replaced by another node in the CDS network.
System.healthmonitor.collect Sets the collect and send rate in seconds for the CMS device health (or
Rate
status) monitor. The default is 120. The range is from 5 to 3600.
System.Icm.enable
Local and CDSM feature (enable or disable). This property allows
settings that are configured using the local device CLI or the CDSM to
be stored as part of the CDS network configuration data.
System.monitoring.collect
Rate
Rate at which the SE collects and sends the monitoring report to the
CDSM (in seconds). The default is 300 seconds. The range is from 30
to 1800.
System.monitoring.daily
ConsolidationHour
Hour at which the CDSM consolidates hourly and daily monitoring
records. The default is 1. The range is from 0 to 23.
System.monitoring.enable
SE statistics monitoring (enable or disable).
System.monitoring.monthly
ConsolidationFrequency
Frequency (in days) with which the CDSM consolidates daily
monitoring records into monthly records. The default is 14. The range
is from 1 to 30.
System.monitoring.record
LimitDays
Maximum number of days of monitoring data to maintain in the system.
The default is 1825. The range is from 0 to 7300.
System.repstatus.update
Enabled
Replication status periodic calculations on an SE (enable or disable).
System.repstatus.updateRate
Rate of replication status periodic updates calculated on an SE (in
minutes). The default is 10. The range is from 5 to 1440.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-8
Chapter 6
Configuring the System
Configuring System Settings
Table 6-3
System Properties Fields (continued)
Field
Description
System.repstatus.updateRate
Sec
Rate of replication status periodic updates calculated on an SE (in
seconds). The default is 600 seconds. Setting this rate overrides the
update rate set in minutes. The ranges is from 30 to 86400.
Note
The rep_status_failed alarm gets triggered if the replication
misses three times in a row. You can configure a lower value for
the System.repstatus.updateRateSec to have the alarm trigger
sooner.
System.repstatus.updateSync Sending summary replication status with requested detailed status
Enabled
(enable or disable).
System.security.minPassword Minimum number of characters required for a user password. The
Length
default is 6. The range is from 6 to 31.
System.security.minUser
NameLength
Step 4
Minimum number of characters required for a user name. The default
is 4. The range is from 1 to 32.
Click Submit to save the settings.
Configuring Device Offline Detection
Communication between all devices and the CDSM use User Datagram Protocol (UDP), which allows
for fast detection of devices that have gone offline. UDP heartbeat packets are sent at a specified interval
from each SE to the primary CDSM in a CDS network. The primary CDSM tracks the last time it
received a UDP heartbeat packet from each SE. If the CDSM has not received the specified number of
UDP packets, it displays the status of the nonresponsive SEs as offline.
Note
In CDS networks with heavy traffic, dropped UDP packets can cause the CDSM to incorrectly report the
status of SEs as offline. To avoid this problem, configure a higher value for dropped UDP heartbeat
packets.
To configure Device Offline Detection, do the following:
Step 1
Choose System > Configuration > Device Offline Detection. The Configure Device Offline Detection
page is displayed.
Note
The Device Offline Detection feature is in effect only when the CDSM receives the first UDP
heartbeat packet from an SE. UDP port of the heartbeat on the CDSM must be reachable for all
devices; otherwise, the device shows as offline.
Step 2
In the Heartbeat Rate field, specify how often, in seconds, the SEs should transmit a UDP heartbeat
packet to the CDSM. The default is 10. The range is from 5 to 3600.
Step 3
In the Heartbeat Fail Count field, specify the number of UDP heartbeat packets that can be dropped
during transmission from SEs to the CDSM before an SE is declared offline. The default is 3. The range
is from 1 to 100.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-9
Chapter 6
Configuring the System
Configuring System Settings
Note
Step 4
Decreasing the heartbeat interval (Heartbeat Rate * Heartbeat Fail Count) may take twice the
original configured time to take effect. During this time, the online device status is not changed
to “Offline” or “Online [Waiting for datafeed].”
In the Heartbeat UDP Port field, specify the CDSM port number that the SEs use to send UDP heartbeat
packets. The default is 2000. The range is from 1000 to 10000.
The Maximum Offline Detection Time field displays the product of the failed heartbeat count and
heartbeat rate, where:
Maximum Offline Detection Time =Heartbeat Rate * Heartbeat Fail Count
Step 5
Click Submit to save the settings.
Configuring Distribution QoS
The Distribution QoS settings allow you to configure system-wide QoS priorities for delivery service
distribution and metadata replication. The delivery service distribution priority (low, medium, or high)
is set on the definition page for each delivery service.
Note
When a single URL is associated with more than one delivery service, the content is distributed only one
time to all the Service Engines subscribed to each delivery service. When different QoS settings are
configured for different delivery services that contain the same content, the delivery service priority
setting determines which QoS settings are applied to the content distribution. The delivery service with
the higher priority dictates which QoS settings are used.
To configure system-wide QoS settings, do the following:
Step 1
Choose System > Configuration > Distribution QoS. The Distribution QoS page is displayed.
Step 2
Check the Set QoS for Unicast Data check box to enable system-wide QoS settings for unicast data.
The unicast data refers to the ingest and distribution traffic among SEs.
Step 3
To set the QoS value for a delivery service with low priority, choose a Differentiated Service Code Point
(SCDP) value from the QoS value with low priority drop-down list. Alternatively, enter a decimal value
in the corresponding field.
Note
See the next section, “Setting DSCP Values for QoS Packets,”for more information. You can
override the system-wide settings for unicast data by configuring QoS settings on a per-delivery
service basis. Sse the “Creating Delivery Service” section on page 5-15 for more information.
Step 4
To set the QoS value for a delivery service with medium priority, choose a DSCP value from the QoS
value with medium priority drop-down list. Alternatively, enter a decimal value in the corresponding
field.
Step 5
To set the QoS value for a delivery service with high priority, choose a DSCP value from the QoS value
with high priority drop-down list. Alternatively, enter a decimal value in the corresponding field.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-10
Chapter 6
Configuring the System
Configuring System Settings
Step 6
Set the QoS value for each priority (low, medium, and high) for a delivery service by choosing the
Differentiated Service Code Point (DSCP) value from the QoS value drop-down list or by entering a
decimal value in the corresponding field.
Step 7
Check the Set QoS for metadata check box to enable QoS settings for metadata replication.
Metadata is created based on the Manifest file and is part of the ingest and distribution traffic.
Step 8
Set the QoS value for metadata replication by choosing the DSCP value from the QoS value drop-down
list or by entering a decimal value in the corresponding field.
Step 9
Click Submit to save the settings.
Setting DSCP Values for QoS Packets
The CDS allows you to set Differentiated Services Code Point (DSCP) values for Unicast QoS packets.
DSCP values define relative priority levels for the packets. You can either choose a DSCP keyword from
the drop-down list or enter a value in the corresponding field. (See Table 6-4.)
Table 6-4
DSCP Values
Keyword
Description and Value
af11
Sets packets with AF11 DSCP (001010).
Note
The number in parentheses denotes the DSCP value for each
per-hop behavior keyword.
af12
Sets packets with AF12 DSCP (001100).
af13
Sets packets with AF13 DSCP (001110).
af21
Sets packets with AF21 DSCP (010010).
af22
Sets packets with AF22 DSCP (010100).
af23
Sets packets with AF23 DSCP (010110).
af31
Sets packets with AF31 DSCP (011010).
af32
Sets packets with AF32 DSCP (011100).
af33
Sets packets with AF33 DSCP (011110).
af41
Sets packets with AF41 DSCP (100010).
af42
Sets packets with AF42 DSCP (100100).
af43
Sets packets with AF43 DSCP (100110).
cs1
Sets packets with CS1 (precedence 1) DSCP (001000).
cs2
Sets packets with CS2 (precedence 2) DSCP (010000).
cs3
Sets packets with CS3 (precedence 3) DSCP (011000).
cs4
Sets packets with CS4 (precedence 4) DSCP (100000).
cs5
Sets packets with CS5 (precedence 5) DSCP (101000).
cs6
Sets packets with CS6 (precedence 6) DSCP (110000).
cs7
Sets packets with CS7 (precedence 7) DSCP (111000).
default
Sets packets with the default DSCP (000000).
ef
Sets packets with EF DSCP (101110).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-11
Chapter 6
Configuring the System
Configuring System Settings
Configuring Service Routing
The Service Routing menu options consist of the following:
•
Coverage Zone File Registration
•
Configuring Global Routing
Coverage Zone File Registration
A coverage zone can be associated with one or more SEs: each SE can have its own unique coverage
zone, or SEs can be associated with more than one coverage zone and have overlapping coverage zones.
For more information about coverage zones, see the “Coverage Zone File” section on page 1-37.
See Appendix C, “Creating Coverage Zone Files,” for information about creating a Coverage Zone file.
The system administrator places a Coverage Zone file where the CDSM or individual devices can access
the URL. The administrator then registers the Coverage Zone file URL in the CDSM. Coverage Zone
files can be applied globally to the entire CDS network, or locally to a specific SR. If a Coverage Zone
file is made global, then it is read and parsed by each SR that does not have a Coverage Zone file
assigned. If the coverage zone is specified in an individual SR configuration, it is only applied to that
particular SR.
You have the choice of using two types of coverage zones:
•
Default coverage zones
•
User-defined coverage zones
A default coverage zone consists of all the SEs that reside in the same local network segment, or subnet.
The CDSM provides a check box to specify whether the default coverage zone is to be used.
A user-defined coverage zone consists of all the SEs that are specified in a Coverage Zone file. This file
defines the network segments to be covered in the routing process. The Coverage Zone file is registered
with the CDSM and then applied to an SR for routing definitions.
To apply a custom coverage zone to an SR, you first need to register a Coverage Zone file URL in the
CDSM. After you have registered the Coverage Zone file URL with the CDSM, you can apply the
Coverage Zone file in one of two ways:
Note
•
Globally—Deploy the Coverage Zone file across the entire CDS network
•
Locally—Deploy the Coverage Zone file on a specific SR
If you apply a Coverage Zone file locally for a device, this file overwrites the global Coverage Zone file
for that device.
To register a Coverage Zone file, do the following:
Step 1
Choose System > Configuration > Service Routing > Coverage Zone File Registration. The
Coverage Zone File Table page is displayed.
Step 2
Click the Create New icon in the task bar. The Registering Coverage Zone File page is displayed.
To edit a Coverage Zone file registration, click the Edit icon next to the registration you want to edit.
Step 3
Choose a file import method from the File Import Method drop-down list:
•
Upload—The upload method allows you to upload a Coverage Zone file from any location that is
accessible from your PC by using the browse feature.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-12
Chapter 6
Configuring the System
Configuring System Settings
•
Import—The import method allows you to import the Coverage Zone file from an external HTTP,
HTTPS, or FTP server.
When you choose a method, the page refreshes and displays the configuration fields that are associated
with the method that you chose.
Step 4
Enter the fields as appropriate. Table 6-5 describes the upload method fields. Table 6-6 describes the
import method fields.
Table 6-5
Property
Description
Coverage Zone File Upload
Local directory path to the Coverage Zone file. To locate the
file, use the Browse button. Click the Validate button to
validate the Coverage Zone file.
Destination Filename
Name of the Coverage Zone file. This field is filled in
automatically with the filename from the local directory path.
Table 6-6
Step 5
Upload Method for Coverage Zone Files
Import Method for Coverage Zone Files
Property
Description
Coverage Zone File URL
The URL where the Coverage Zone file is located, including
path and filename. Click the Validate button to validate the
Coverage Zone file.
Destination File Name
Name of the Coverage Zone file.
Update Interval (minutes)
Frequency with which the CDSM looks for changes to the
Coverage Zone file. The default value is 10 minutes.
Username
Name of the user to be authenticated when fetching the
Coverage Zone file.
Password
User password for fetching the Coverage Zone file.
To save the settings, click Submit.
Configuring Global Routing
After you have registered the Coverage Zone file, you can use this file as your global routing
configuration.
To set a global Coverage Zone file, do the following:
Step 1
Choose System > Configuration > Service Routing > Global Routing Config. The Set Global
Coverage Zone File page is displayed.
Step 2
From the Coverage Zone File drop-down list, choose a Coverage Zone file.
Step 3
In the DNS TTL field, configure the time period (in seconds) for caching DNS replies. Enter a number
from 0 to 60. The default is 60 seconds.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-13
Chapter 6
Configuring the System
Configuring System Settings
Step 4
Click Submit to save settings.
To apply a Coverage Zone file to an individual SR for local coverage zone configuration, see the
“Configuring the Service Router” section on page 4-101.
CDN Selector File Registration
A CDN Selector file is associated with one or more SRs. Each SR can have its own unique CDN Selector
file or multiple SRs can have the same CDN Selector file.
CDN Selector must be enabled on the SR and a CDN Selector file must be selected for the SR. For more
information about enabling CDN Selector, see the “Activating a Service Router” section on page 4-102.
For more information about creating a CDN Selector file, see Appendix E, “Creating CDN Selector
Files.” To select a CDN Selector file for the SR, you first need to register the CDN Selector file in the
CDSM.
Note
CDN Selector is an early field trial (EFT) feature.
To register a CDN Selector file, do the following:
Step 1
Choose System > Configuration > CDN Selector File Registration. The CDN Selector File Table page
is displayed.
Step 2
Click the Create New icon in the task bar. The Registering CDN Selector File page is displayed.
To edit a CDN Selector file registration, click the Edit icon next to the registration you want to edit.
Step 3
Choose a file import method from the File Import Method drop-down list:
•
Upload—The upload method allows you to upload a CDN Selector file from any location that is
accessible from your PC by using the browse feature.
•
Import—The import method allows you to import the CDN Selector file from an external HTTP,
HTTPS, or FTP server.
When you choose a method, the page refreshes and displays the configuration fields that are associated
with the method that you chose.
Step 4
Enter the fields as appropriate. Table 6-5 describes the upload method fields. Table 6-6 describes the
import method fields.
Table 6-7
Upload Method for XML Files
Property
Description
CDN Selector File Upload
Local directory path to the file. To locate the file, use the
Browse button. Click the Validate button to validate the XML
file.
Destination Filename
Name of the file. This field is filled in automatically with the
filename from the local directory path.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-14
Chapter 6
Configuring the System
Configuring System Settings
Table 6-8
Step 5
Import Method for XML Files
Property
Description
CDN Selector File URL
The URL where the file is located, including path and filename.
Click the Validate button to validate the XML file.
Destination File Name
Name of the file.
Update Interval (minutes)
Frequency with which the CDSM looks for changes to the file.
The default value is 10 minutes.
Username
Name of the user to be authenticated when fetching the file.
Password
User password for fetching the file.
To save the settings, click Submit.
Authorization File Registration
The Authorization File Registration page is used to register a Service Rule file to the CDS. A Service
Rule file is associated with one or more delivery services. Each delivery service can have its own unique
Service Rule file or multiple delivery services can have the same Service Rule file.
A Service Rule must be selected for a delivery service. For more information about Service Rule files,
see Appendix F, “Creating Service Rule Files.” To select a Service Rule file for a delivery service, you
first need to register the Service Rule file in the CDSM.
To register a Service Rule file, do the following:
Step 1
Choose System > Configuration > Authorization File Registration. The Authorization Plugin Files
Table page is displayed.
Step 2
Click the Create New icon in the task bar. The Registering Service Rule File page is displayed.
To edit a Service Rule file registration, click the Edit icon next to the registration you want to edit.
Step 3
Choose a file import method from the File Import Method drop-down list:
•
Import—The import method allows you to import an XML file from an external HTTP, HTTPS, or
FTP server.
•
Upload—The upload method allows you to upload an XML file from any location that is accessible
from your PC by using the browse feature.
When you choose a method, the page refreshes and displays the configuration fields that are associated
with the method that you chose.
Step 4
Enter the fields as appropriate. Table 6-5 describes the upload method fields. Table 6-6 describes the
import method fields.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-15
Chapter 6
Configuring the System
Configuring System Settings
Table 6-9
Property
Description
File Type
From the File Type drop-down list, select Rule File.
Source File Upload
Local directory path to the file. To locate the file, use the
Browse button. Click the Validate button to validate the XML
file.
Destination Filename
Name of the file. This field is filled in automatically with the
filename from the local directory path.
Table 6-10
Step 5
Upload Method for XML Files
Import Method for XML Files
Property
Description
File Type
From the File Type drop-down list, select Rule File.
File URL
The URL where the file is located, including path and filename.
Click the Validate button to validate the XML file.
Destination File Name
Name of the file.
Update Interval (minutes)
Frequency with which the CDSM looks for changes to the file.
The default value is 10 minutes.
Username
Name of the user to be authenticated when fetching the file.
Password
User password for fetching the file.
To save the settings, click Submit.
NAS File Registration
A NAS file is associated with the SEs in the root location of a delivery service. One SE in the root
location of a delivery service acts as the Content Acquirer. The NAS file is associated with the delivery
service by assigning the file to the Content Origin. Each Content Origin can have its own unique NAS
file or multiple Content Origins can have the same NAS file.
Note
NAS is only supported in lab integrations as proof of concept.
For information about assigning a NAS file to a Content Origin, see the “Content Origins” section on
page 5-1. For information about creating a NAS file, see Appendix H, “Creating NAS Files.” To assign
a NAS file to a Content Origin, you first need to register the file in the CDSM.
To register a NAS file, do the following:
Step 1
Choose System > Configuration > NAS File Registration. The NAS File Table page is displayed.
Step 2
Click the Create New icon in the task bar. The File Registration page is displayed.
To edit a NAS file registration, click the Edit icon next to the registration you want to edit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-16
Chapter 6
Configuring the System
Configuring System Settings
Step 3
Choose a file import method from the File Import Method drop-down list:
•
Upload—The upload method allows you to upload a NAS file from any location that is accessible
from your PC by using the browse feature.
•
Import—The import method allows you to import a NAS file from an external HTTP, HTTPS, or
FTP server.
When you choose a method, the page refreshes and displays the configuration fields that are associated
with the method that you chose.
Step 4
Enter the fields as appropriate. Table 6-5 describes the upload method fields. Table 6-6 describes the
import method fields.
Table 6-11
Property
Description
Source File Upload
Local directory path to the file. To locate the file, use the
Browse button. Click the Validate button to validate the XML
file.
Destination Filename
Name of the file. This field is filled in automatically with the
filename from the local directory path.
Table 6-12
Step 5
Upload Method for XML Files
Import Method for XML Files
Property
Description
File URL
The URL where the file is located, including path and filename.
Click the Validate button to validate the XML file.
Destination File Name
Name of the file.
Update Interval (minutes)
Frequency with which the CDSM looks for changes to the file.
The default value is 10 minutes.
Username
Name of the user to be authenticated when fetching the file.
Password
User password for fetching the file.
To save the settings, click Submit.
HTTPS Streaming
SEs associated with the delivery service that has HTTPS streaming enabled have a certificate installed.
The SEs do not validate certificates of downstream clients. SEs, as a client of the Origin server, do not
send their certificates to the Origin server.
Certificate Authority’s (CA’s) root certificates are expected to be available to all clients initiating HTTPS
communication; most browsers are installed with well-known CA root certificates. Trusted CA
certificates are expected to be provided for the purpose of Origin server certification validation.
Note
A single subject alternative name (SAN) certificate is installed for all delivery services in the CDS.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-17
Chapter 6
Configuring the System
Configuring System Settings
For more information about HTTPS Streaming and how to configure it, see the “HTTPS Streaming”
section on page 2-25.
Uploading certificate and key files consists of the following pages:
•
Root CA File Registration—Upload or import the certificates for the Origin servers participating
in HTTPS
•
HTTPS Certification Files Registration—Upload client certificate and key file for all SEs
•
HTTPS Certification File Scheduling—Schedule client certificate and key file notification to the
Web Engine on each SE that is participating in an HTTPS delivery service
The procedures involved in uploading certificate and key files consist of the following:
•
Uploading or Importing a Root CA File
•
Uploading Client Certificate and Key Files
•
Scheduling Web Engine Notification of Client Certificate and Key Files
Uploading or Importing a Root CA File
The root certificates are used by SEs to validate the Origin server certificates, one or more root
certificates can be uploaded to the CDSM.
After a new root certificate is uploaded to the CDSM, it is distributed to all SEs immediately. The SE
does not notify the Web Engine of the existence or update of a root certificate file; instead, the Web
Engine fetches them when necessary.
To upload or import a root CA file, do the following:
Step 1
Choose System > Configuration > HTTPS Streaming > Root CA File Registration. The Root CA
File Registration table is displayed.
Step 2
Click the Create New icon in the task bar. The File Registration page is displayed.
To edit a root CA file, click the Edit icon next to the file you want to edit.
Step 3
Choose a file import method from the File Import Method drop-down list:
•
Upload—Uploads a file from any location that is accessible from your PC using the browse feature.
•
Import—Imports a file from an external HTTP, HTTPS, or FTP server.
When you choose a method, the page refreshes and displays the configuration fields that are associated
with the method that you chose.
Step 4
Enter the fields as appropriate. Table 6-13 describes the upload method fields. Table 6-14 describes the
import method fields.
Table 6-13
Upload Method for Root CA Files
Property
Description
Source File Upload
Local directory path to the file. To locate the file, use the
Browse button.
Destination Filename
Name of the file. This field is filled in automatically with the
filename from the local directory path.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-18
Chapter 6
Configuring the System
Configuring System Settings
Table 6-14
Step 5
Import Method for Root CA Files
Property
Description
File URL
The URL where the file is located, including path and filename.
Destination File Name
Name of the file.
Update Interval (minutes)
Frequency with which the CDSM looks for changes to the file.
The default value is 10 minutes.
Username
Name of the user to be authenticated when fetching the file.
Password
User password for fetching the file.
To save the settings, click Submit.
Uploading Client Certificate and Key Files
The certificate and key files are uploaded to the CDSM, then the CDSM immediately distributes them
to all the SEs in the system. The certificate and key file distribution is independent of notifying the Web
Engine of the newly uploaded certificate and key files, which occurs based on the defined schedule or
immediately if the Immediately Run check box is checked.
One pair of certificate and key files are used by all SEs in the system to send to HTTPS clients for
authentication. Uploading new certificate and key files overwrites the existing ones. The certificate and
key files work as a pair, so updating one of them requires the other one be updated as well.
To upload the client certificate and key files, do the following:
Step 1
Choose System > Configuration > HTTPS Streaming > HTTPS Certification Files Registration.
The HTTPS Certification File page is displayed.
Step 2
To upload a certificate file, click the Browse button for the Certification File and navigate to the file.
Step 3
To upload a key file, click the Browse button for the Key File and navigate to the file.
Step 4
To save the settings, click Submit.
To delete a certificate or key file, click the Delete icon next to the file type. Deleting a certificate file or
key file deletes the file from the CDSM and all SEs in the system, and impacts the HTTPS feature. The
files should only be deleted if the HTTPS feature is no longer used. File deletion can only occur when
there are no active HTTPS certificate file tasks scheduled.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-19
Chapter 6
Configuring the System
Configuring System Settings
Scheduling Web Engine Notification of Client Certificate and Key Files
After the client certificate and key files have been uploaded to the CDSM and distributed to all the SEs
in the system, the Web Engine on each SE participating in an HTTPS delivery service needs to be
notified of the newly uploaded certificate and key files.
To schedule Web Engine notification of client certificate and key files, do the following
Step 1
Choose System > Configuration > HTTPS Streaming > HTTPS Certification Files Schedule. The
Scheduling Tasks table is displayed.
Step 2
Click the Create New icon in the task bar. The Certificate Schedule Task page is displayed.
The table lists the scheduled tasks, the SEs assigned to that task, and the status of the task (expired or
active).
To edit a schedule, click the Edit icon next to the schedule you want to edit. Expired tasks cannot be
edited.
Step 3
To schedule the task to run immediately, check the Immediately Run check box.
To schedule the task to run at a specific date and time, do the following:
a.
Click the Calendar icon next to the Schedule Date and Time field to enter the date and time. The
Calendar dialog box is displayed.
b.
From the Month drop-down list, select the month.
c.
To change the year, use the right arrow and left arrow on either side of the current year.
d.
To select the day of the month, click the day in the calendar displayed. The current date is
highlighted in yellow.
e.
In the Time field, using the 24-hour clock, enter the time of day.
To reset the date and time to today, click Set Today.
f.
Step 4
Click Apply. The date and time you selected is entered in the Schedule Date and Time field.
Click the Assign icon (blue cross mark) next to the SE you want to assign to this task. Alternatively, in
the task bar, click Assign All Service Engines. The SE assignment states are described in Figure 6-1.
Figure 6-1
Content Origin Assignment State
A green arrow wrapped around the blue cross mark indicates an SE assignment is ready to be submitted.
To unassign an SE, click this icon.
Step 5
To schedule the task, click Submit. The task is displayed in the Scheduling Tasks table.
To delete all expired tasks from the Scheduling Tasks table, click the Delete All icon. To delete a specific
task, click the Edit icon next to the task you want to delete, and when the task is displayed, click the
Delete icon.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-20
Chapter 6
Configuring the System
Configuring System Settings
Configuring the CDSM to Communicate with an External System
CDSM can be configured to communicate with extrenal systems. Currently, Prime Central is supported
as one type of external system.
Cisco PRIME for service providers is an experience delivery management architecture that enables the
integrated design, fulfillment and assurance of customer experiences such as video, mobility, and
managed cloud services delivered on converged IP networks.
As part of Cisco PRIME, the CDSM forwards alarms as SNMP traps to Prime Central. The CDSM
supports the following functionality to provide communication to Prime Central:
•
CDSM configuration settings to allow communication with Prime Central
•
Registration of the CDSM on Prime Central
•
Sending SNMP traps to Prime Central
Registering and De-Registering with Prime Central
The CDSM registers with Prime Central by checking Register check box in the External System page.
The registration process takes about 10 to 20 seconds. After registration is complete, the CDSM updates
the status (Registered or Registration Failed) of Prime Central.
Note
CDSM should be de-registered from the Prime Central before deleting the configuration settings of
Prime Central. Excluding Fault Manager Server IP and Fault Manager Server Port fields, the
configuration settings of the Prime Central listed in Table 6-15 cannot be modified when the status is
Registered.
To configure the settings for an external system (Prime Central), do the following:
Step 1
From the CDSM GUI, choose System > Configuration > External Systems. The External Systems
table is displayed.
Step 2
Click the Create New icon in the task bar. The External System page is displayed.
To edit an external system, click the Edit icon next to the external system name.
Step 3
Enter the settings as appropriate. See Table 6-15 for a description of the fields.
Table 6-15
External System Parameters
Field
Description
Name
Name of the External System
Type
Prime Central is the only option.
Status
Registration status, It can have the following values:
Registered
Unregistered
Registering
Registration Failed
Deregistering
Register
Check the Register check box to register the CDSM with Prime Central
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-21
Chapter 6
Configuring the System
Viewing or Downloading XML Schema Files
Table 6-15
Step 4
External System Parameters (continued)
Field
Description
IP Address
IP address of the Prime Central
Database SID
Database schema ID of the Prime Central
Database Port
Database Port Number of the Prime Central
Database User
Database User Name of the Prime Central
Database Password
Database Password of the Prime Central
Fault Manager Server
IP
IP Address of the Prime Central Fault Manager, used by CDSM to send SNMP
traps to the Prime Central
Fault Manager Server
Port
Port number of the Prime Central Fault Manager, used by CDSM to send
SNMP traps to the Prime Central
Comments
Description of the External System
Click Submit to save the settings.
Viewing or Downloading XML Schema Files
The XML Schema Files page provides links to the XML schema files for viewing or downloading. All
XML files can be validated through the CDSM by clicking the Validate button on the associated CDSM
page. However, if you want to use an external XML validation program, you can save the XML schema
file to use for that purpose. The following XML schema files are available:
•
CDSAuthorization.xsd—Geo/IP file used to specify the geographic regions and IP networks that are
allowed or denied access to a delivery service.
•
CDSRules.xsd—Service Rule file used by a delivery service to specify the service rules for all SEs
in a delivery service.
•
CdsCoverageZone.xsd—Coverage Zone file is used to customize the networks and geographic
regions each SE services.
•
CdsOrigin.xsd—NAS file used for defining a NAS device.
•
CDNSelector.xsd—CDN Selector file is used for third-party streaming service selection. The CDN
Selector is an early field trial (EFT) feature.
•
CdnManifest.xsd—Manifest file is used to specify the content to be prefetched and to control the
delivery of the prefetched content for a delivery service.
To open or save an XML schema file, do the following:
Step 1
Choose System > CDS-IS Files > XML Schema Files. The CDS-IS XML Schema page is displayed
with a link to each XSD (schema) file.
Step 2
Click the link for the file. Depending on the browser program used, one of the following or something
similar happens:
•
File is displayed in a new window and the File Download dialog box is also displayed
•
Opening dialog box is displayed
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-22
Chapter 6
Configuring the System
Viewing or Downloading XML Schema Files
•
File is displayed in a text editor program.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-23
Chapter 6
Viewing or Downloading XML Schema Files
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
6-24
Configuring the System
CH A P T E R
7
Monitoring the Internet Streamer CDS
The CDSM provides tools that can be used for system monitoring and system diagnostics. The topics
covered in this chapter include:
•
System Monitoring, page 7-1
•
Device Monitoring, page 7-12
•
Reports, page 7-25
•
Delivery Service Monitoring, page 7-29
•
Viewing Statistics, page 7-40
•
Log Files, page 7-50
•
Transaction Logs, page 7-50
System Monitoring
System monitoring consists of the following:
•
System Status
•
System Home Page
•
System Audit Logs
•
System Port Numbers
System Status
The CDSM displays the system status in the System Status bar that is located above the navigation tabs
in every window. The System Status bar presents the overall device, content health of the system. You
can use this feature to monitor devices and content replication in your CDS network. The System Status
bar helps you immediately identify any problems on the network, allowing you to act and respond to
problems quickly.
The system status reporting mechanism uses four alarm lights to identify problems that need to be
resolved. Each light represents a different alarm level, as follows:
•
Green—No alarms (the system is in excellent health)
•
Yellow—Minor alarms
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-1
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
•
Orange—Major alarms
•
Red—Critical alarms
When you roll your mouse over an alarm light in the System Status bar, a pop-up message provides
further details about the device or delivery service. See Figure 7-1.
The icon next to the System Status either displays a yellow triangle with an exclamation mark or a green
circle with a check mark. The yellow triangle indicates the alarms and alerts count includes only the
unacknowledged alarms and alerts. The green circle with a check mark indicates all alarms and alerts
are counted, whether they are acknowledged or unacknowledged.
Figure 7-1
System Status Bar
When you click the alarm light or the link next to the alarm light, a new window opens (Troubleshooting
Devices or Troubleshooting Service), listing the individual devices or delivery services that need
attention.
Figure 7-2
Troubleshooting Device Window
Troubleshooting Window Pop-Up Menus
When you roll your mouse over an item under the Alarm Information column in the Troubleshooting
window, the Troubleshooting Tools menu is displayed. The Troubleshooting Tools menu provides links
to all the diagnostic tools, troubleshooting tools, and monitoring applications for troubleshooting and
resolving the problem. Figure 7-2 shows the Troubleshooting Tools menu for device alarms.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-2
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
-Table 7-1 describes the icons for the Troubleshooting window.
Table 7-1
Icon
Troubleshooting Window Icons
Function
Create a filtered table. Filter the alarms by severity or device type.
View all alarms. Click this icon to view all alarms after you have
created a filtered table.
Refresh the table
Print the current window.
View acknowledged alarms.
You can sort the Troubleshooting table by clicking any column heading displayed in blue. The first time
the column heading is clicked, the table is sorted by that column in increasing order. If the column
heading is clicked again, the table is sorted by that column in decreasing order.
Note
If there is more than one alarm for a device, and the Troubleshooting window is sorted by device, then
the device is only listed once for multiple alarms associated with it. The same is true for service alarms.
Troubleshooting Window Acknowledge and Unacknowledge Alarms Function
The following procedure describes acknowledging and unacknowledging an alarm:
Step 1
To remove an alarm from the Troubleshooting window, check the check box for the alarm. The alarm is
moved to the Acknowledged Alarm window.
Step 2
To view the acknowledged alarms, click the View acknowledged alarms icon. The Acknowledged
Alarm window is displayed (Figure 7-3).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-3
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Figure 7-3
Acknowledged Alarms Window
Step 3
To unacknowledge an alarm, check the check box for the alarm. The alarm is returned to the
Troubleshooting window.
Step 4
To view the Troubleshooting window again, click the Back (blue left arrow) icon.
Device Alarms
Device alarms are associated with device objects and pertain to applications and services running on
SEs, SRs, and CDSMs. Device alarms are defined by the reporting application or service. For example,
the SR raises an alarm for an SE (the keep-alive timed out alarm) if the SE has a Layer 3 failure. Device
alarms can also reflect reporting problems between the device and the CDSM. (See Table 7-2.)
Alarm thresholds are configured for each device. For more information, see the “Setting Service Monitor
Thresholds” section on page 4-85.
Table 7-2
Device Alarms for Reporting Problems
Alarm
Alarm
Severity
Device Status
Description
Device is offline
Critical
Offline
The device has failed to communicate with the
CDSM.
Device is pending
Major
Pending
The device status cannot be determined.
Device is inactive
Minor
Inactive
The device has not yet been activated or
accepted by the CDSM.
Device has lower
software version
Minor
Online
The device is not interoperable with the CDSM
because it has an earlier software version.
To troubleshoot a device from the System Status bar, do the following:
Step 1
In the System Status bar, click the Devices alarm light or click the Device link. The Troubleshooting
Devices window is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-4
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Step 2
In the Alarm Information column, hold your mouse over the alarm message until the Troubleshooting
Tools menu is displayed. See Figure 7-2.
Step 3
Click the troubleshooting tool you want to use. The link takes you to the corresponding page in the
CDSM. Table 7-3 describes the tools available for all device alarms.
Table 7-3
Troubleshooting Tools for Device Alarms
Item
Navigation
Description
Edit/Monitor Device
Devices home page
Displays Devices home page
Telnet to Device
Opens a Telnet window
Initiates a Telnet session using
the device IP address
Run Show Commands
Devices > Device > Monitoring > Displays device show command
Show/Clear Commands > Show tool
Commands
Core Dump File
Devices > Device > Monitoring > Displays a list of core dump files
Core Dump Files
on the device.
Update Software
Devices > Devices > Device Home Displays a list of software files
> Update Software
that have been uploaded to the
CDS.
Service Alarms
Service alarms pertain to content replication problems and are associated with delivery services. Service
alarms are raised by the CDSM based on replication status reports, or by the SE health manager based
on acquisition and distribution errors.
If the same fault is reported by the replication status and by the SE health manager, the CDSM reports
both; one appears as the true alarm and the other as an error. The CDSM does not correlate nor attempt
to consolidate the errors generated by the replication status and by the SE health manager.
To troubleshoot service replication issues from the System Status bar, do the following:
Step 1
In the System Status bar, click the Services alarm light or click the Service link. The Troubleshooting
Services window is displayed. Table 7-4 lists the service alarms.
Table 7-4
Service Alarms for Delivery Service Replication Status
Alarm
Severity
Description
Replication Status is Failed
Critical
The number of SEs in the delivery service that failed to
replicate the content is greater than zero.
Replication Status is Pending Minor
The number of SEs in the delivery service with content
replication status unknown is greater than zero.
Single content item failed or
crawl job failed.
A single content failed to be acquired or replicated, or a
crawl job failed to acquire or replicate content.
Minor
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-5
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Step 2
In the Alarm Information column, hold your mouse over the alarm message until the Troubleshooting
Tools menu is displayed.
Step 3
Click the troubleshooting tool that you want to use. The link takes you to the corresponding page in the
CDSM. Table 7-5 describes the tools available for all service alarms.
Table 7-5
Troubleshooting Tools for Content Alarms
Item
Navigation
Description
View Replication Status
Services > Delivery Services
> Replication Status
Displays second-level replication
status for a delivery service
Edit Delivery Service
Services > Delivery
Services> Definition
Opens the Delivery Service
Definition page
System Home Page
The System Home page (Figure 7-4) provides overall system performance graphs, and overall system
information on configuration and software versions running on the CDS devices. Clicking the links for
devices, delivery services, and programs take you to the corresponding table pages.
Note
The number of devices that have a lower version of software than the CDSM only compares the major
and minor release numbers (X.Y) of the software release number. The software release number consists
of X.Y.Z-b#, where X is the major release number, Y is the minor release number, Z is the maintenance
release number, and b# is the build number. Devices with a lower X.Y version than the CDSM do not
interoperate with the CDSM, and the CDSM does not send configuration updates to those devices. A
minor alarm is generated for the devices with a lower version of software.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-6
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Figure 7-4
System Home Page
The information displayed in the graphs is based on a snapshot of your CDS network and represents the
state of your SEs at the end of every two polling periods. To refresh the graphs, you can click the Refresh
icon next to “System Home.” You can change the interval between polls by changing the
System.datafeed.pollRate field in System > Configuration > System Properties. The default polling
rate is 300 seconds (5 minutes).
To change the report settings for the System-Wide Bandwidth Served or System-Wide Bandwidth
Efficiency Gain graphs, click View Detailed Report. Clicking the Streaming Sessions link at the
bottom of the home page opens the System-Wide Streaming Sessions Report page (Figure 7-5). For more
information about these reports, see the “Reports” section on page 7-25.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-7
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Figure 7-5
System-Wide Streaming Sessions Report Page
System Audit Logs
The CDSM logs user activity in the system. The only activities that are logged are those that change the
CDS network. This feature provides accountability for users actions (for example, which user did what
and when). Logged activities include the following:
•
Creation of CDS network entities
•
Modification and deletion of CDS network entities
•
System configurations
To view audit trail logs, do the following:
Step 1
Choose System > Logs > Audit Trail Logs. The Audit Log page is displayed. All logged transactions
in the CDSM are listed by date and time, user, actual transaction that was logged, and the IP address of
the machine that was used.
Step 2
To determine the number of rows that you want to display, choose a number from the Rows
drop-down list.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-8
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
System Port Numbers
Information on all the protocols and ports used by the CDS can be viewed on the CDS-IS Well Known
Ports page.
To view ports used by the CDS, choose System > CDS-IS Well Known Ports. The CDS-IS Well Known
Ports page is displayed. Table 7-6 lists all ports listed on the CDS-IS Well Known Ports page.
To view all ports on one page, from the Rows drop-down list, choose All.
Table 7-6
Internet Streamer CDS- Well Known Ports
Source Group
Destination Group
Protocol
Source
Port
Destination
Port
Purpose
Administrator
CDSM
TCP
ANY
8443
Access CDSM GUI from Administrator PC
All Devices
NTP Servers
UDP
ANY
123
Query Time Servers
All Devices
NMS Servers
TCP
ANY
161
SNMP Query/Polling
All Devices
NMS Servers
UDP
ANY
162
SNMP/Trap
All Devices
Syslog Server
UDP
ANY
514
Syslog
All Devices
All Devices
TCP
ANY
22
SSH
All Devices
All Devices
TCP
ANY
23
Telnet (Disabled by default)
CDSM
SE
TCP
ANY
443
CDS Management (Notifications, updates,
queries)
CDSM
SR
TCP
ANY
443
CDS Management (Notifications, updates,
queries)
CDSM
CDSM
TCP
ANY
443
CDS Management (Notifications, updates,
queries)
CDSM
CDSM
UDP
ANY
2000
CDSM to CDSM KeepAlives
DNS Server
All Devices
UDP
ANY
1023-65535
DNS Server responses to DNS query requests
DNS
Server/Proxy
SR
UDP
ANY
53
DNS Query for RRFQDN from DNS
Server/Proxy used by Subscriber(PC)
Origin Server
SE
TCP
ANY
1023-65535
Origin Server responses to HTTP requests
Origin Server
SE
UDP
ANY
1023-65535
Origin Server responses to RTSP requests
Origin Server
SE
TCP
ANY
ESTABLIS
HED PORT
Origin Server responses to SE to the port SE
established the connection with the Origin
Server
(PC)
SE
CDSM
TCP
ANY
443
CDS Mgmt (Notifications, updates, queries)
SE
SE
TCP
ANY
443
Acquisition and Distribution
SE
SR
UDP
ANY
2323
Service Engine to Service Router KeepAlives
SE
CDSM
UDP
ANY
2000
Service Engine to CDSM KeepAlives
SE
SE
TCP
ANY
554
RTSP Requests between Service Engine
SE
SE
TCP
ANY
80
HTTP Request between Service Engine
SE
SE
TCP
ANY
5262
Metadata Receiver in Service Engine
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-9
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Table 7-6
Internet Streamer CDS- Well Known Ports
Source Group
Destination Group
Protocol
Source
Port
Destination
Port
Purpose
SE
SE
TCP
ANY
5275
Metadata Receiver in Service Engine
SE
SE
TCP
ANY
5263
Metadata Sender in Service Engine
SE
SE
TCP
ANY
5278
Metadata Sender in Service Engine
SE
SE
TCP
ANY
5264
Unicast Receiver in Service Engine
SE
SE
TCP
ANY
5271
Metadata Receiver in Service Engine
SE
SE
TCP
ANY
1935
Flash Streaming Live and Interactive
Applications
SE
SE
TCP
ANY
80
Flash VOD file requests via http
SE
SE
TCP
ANY
550
Movie Streamer audio video transport
SE
Origin Server
TCP
ANY
80
Acquire Content from Origin Server using
HTTP
SE
Origin Server
TCP
ANY
443
Acquire Content from Origin Server using
HTTPS
SE
Origin Server
TCP
ANY
21
Acquire Content from Origin Servers using FTP
SE
Origin Server
TCP
ANY
139
Acquire Content from Origin Server using SMB
SE
Origin Server
TCP
ANY
80
Get Flash vod content from Origin Server by
Acquire Content using HTTP
SE
Origin Server
TCP
ANY
1935
Get Flash live stream from Active acquirer or
proxy interactive application data from edge SE
to Origin Server using RTMP
SE
Origin Server
TCP
ANY
554
Acquire Content from Origin Server using
RTSP
SE
NFS NAS Server
TCP
ANY
2049
Mounting NFS Shares
SE
SE
TCP
ANY
5266
Multicast Receiver in Service Engine
SE
SE
TCP
ANY
5267
Multicast Sender in Service Engine
SE
SE
TCP
ANY
5272
Primary/Backup Multicast Sender
communication in Service Engine
SE
SE
TCP
ANY
5276
Multicast connectivity test tool sender request
port in Service Engine
SE
SE
TCP
ANY
5277
Multicast connectivity test tool listener
response port in Service Engine
SE
SE
TCP
ANY
4050
Multicast FXD Sender monitor port in Service
Engine
SE
SE
TCP
ANY
4051
Multicast FXD Receiver monitor port in Service
Engine
SE
SE
TCP
ANY
3057
Multicast FXD Sender PGM monitor port in
Service Engine
SE
SE
TCP
ANY
3058
Multicast FXD Receiver PGM monitor port in
Service Engine
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-10
Chapter 7
Monitoring the Internet Streamer CDS
System Monitoring
Table 7-6
Internet Streamer CDS- Well Known Ports
Source Group
Destination Group
Protocol
Source
Port
Destination
Port
Purpose
SR
CDSM
TCP
ANY
443
CDS Mgmt (Notifications, updates, queries)
SR
CDSM
UDP
ANY
2000
Service Router to CDSM KeepAlives
SR
SR
TCP
ANY
179
BGP communication Service Router
SR
SR(Proximity
Engine mode)
TCP
ANY
7003
Proximity requests to SR (Proximity Engine)
from SR
Note
The SOAP API and associated port 7003
are only available when proximity-based
routing is enabled on the SR.
SR
SR(Proximity
Engine mode)
TCP
ANY
9000
SRP communication on Service Router
Proximity Engine.
SR
SR(Proximity
Engine mode)
UDP
ANY
9000
SRP communication on Service Router
Proximity Engine.
SR
SR(Proximity
Engine mode)
UDP
ANY
9003
SRP communication on Service Router
Proximity Engine.
SR
SR(Proximity
Engine mode)
UDP
ANY
9004
SRP communication on Service Router
Proximity Engine.
SR
SR
TCP
ANY
9000
For SRP communication.
SR
SE
TCP
ANY
5283
Service Router-Service Engine RPC
Subscriber(PC) DNS Server/Proxy
UDP
ANY
53
DNS Query for RRFQDN from Subscriber(PC)
Subscriber(PC)
SR
TCP
ANY
80
HTTP Request to Service Router from
Subscriber(PC)
Subscriber(PC)
SR
TCP
ANY
80
RTMPT Request to Service Router from
Subscriber(PC)
Subscriber(PC)
SR
TCP
ANY
554
RTSP Request to Service Router from
Subscriber(PC)
Subscriber(PC)
SR
TCP
ANY
1935
RTMP(Flash) Request to Service Router from
Subscriber(PC)
Subscriber(PC)
SE
TCP
ANY
80
HTTP Request to Service Engine from
Subscriber(PC)
Subscriber(PC)
SE
TCP
ANY
80
RTMPT Request to Service Engine from
Subscriber(PC)
Subscriber(PC)
SE
TCP
ANY
554
RTSP Request to Service Engine from
Subscriber(PC)
Subscriber(PC)
SE
TCP
ANY
1935
RTMP(Flash) Request to Service Engine from
Subscriber(PC)
Subscriber(PC)
SE
TCP
ANY
1755
MMS Request to Service Engine from
Subscriber(PC)
Subscriber(PC)
SE
TCP
ANY
1111
Flash Media Server Administration
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-11
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Note
The Destination Ports that have a port range indicate the possible ports that the Source Group could be
expecting to send traffic to and receive traffic from. The specific ports required to be open to receive and
send data depends on the Source Group configuration.
Device Monitoring
This section covers the following topics:
•
Devices Table
•
Devices Home Page
•
Using show and clear Commands
•
Core Dump Files
•
CPU Utilization
For more detailed statistics on HTTP, Web Media, Movie Streamer, and Flash Media Streaming traffic,
see the “Viewing Statistics” section on page 7-40.
Devices Table
The Devices Table page displays all devices registered in the CDS network (Figure 7-6).
Figure 7-6
Devices Table Page
Table 7-7 describes the Device Table columns. You can sort the information in the table by clicking on
any column title. The table can be sorted in ascending or descending order for each column.
The table defaults to listing ten rows. You can change the number of rows by clicking the Rows
drop-down list. The bottom of the table lists the page number and the total number of pages, as well as
how many items are showing out of the total number of items.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-12
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-7
Device Table Columns
Column Heading
Description
Device Name
Host name of the device.
Type
Device type: SE, SR, CDSM (Primary), CDSM (Secondary).
IP Address
Primary IP address of the device.
Status
Status is one of the following:
•
Online—Device has been activated through the CDSM and is able to send
and receive data and control traffic.
•
Offline—Device has failed to communicate with the CDSM.
•
Pending—Device status cannot be determined. The device could be in the
process of being activated by the CDSM
•
Offloading—Device is in the Server Offload state. See the Server Offload
field in Table 4-6 on page 4-11 for more information. To monitor the current
streams on an SE during the Server Offload state, view the statistics for each
protocol engine (for example, Movie Streamer), specifically the fields noted
in Table 7-27 on page 7-41. Once all protocol engines have finished
streaming, you can perform maintenance or upgrade the software on the
device. For information about upgrading the software, see the “Upgrading
the Software” section on page 8-6.
•
Online [Waiting for datafeed]—In some situations, the CDSM may receive
regular heartbeat messages, but not receive a datafeed message for a long
time. The Online [Waiting for datafeed] state indicates that the CDSM has
not received a datafeed message from this online device in the last 2.25 *
polling rate seconds. When the datafeed message is received, the state
changes to Online.
Location
Location the device is assigned to.
Software Version
Device software version.
Table 7-8 describes the icons for the device table. To view or modify the configuration of a device, click
the Edit icon next to the device name.
Table 7-8
Icon
Device Table Icons
Function
Create New device creates a Virtual Video Infrastructure Manager,
Caching Node, or Library Node.
Note
The Create New Device pages are part of the integration with
TV CDS, which is an EFT feature.
Activate all inactive Service Engines.
Edit the device.
Export a table to a comma-separated value (CSV) file.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-13
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-8
Icon
Device Table Icons (continued)
Function
Create a filtered table. Filter the devices by the device name, device
type, and device status.
View all devices. Click this icon to view all devices after you have
created a filtered table.
Refresh the table
Print the current window.
For more information, see the “Devices, Services, and Other Tables” section on page 3-7.
Devices Home Page
The Devices home page (Figure 7-7) provides alarm status and information on the device. Only basic
information is displayed for the SR and CDSM.
By clicking the Delivery Services and Device Groups links in the Assignments area on the home page
for an SE a table is displayed listing all the delivery services or device groups in the CDS, and which
ones the SE is assigned to. Through this page, you can assign the device to additional delivery services
or device groups by clicking the icon next to the applicable delivery services or device groups and
submitting your selection.
You can update the device software, and telnet to the device from the Devices home page. For more
information about updating the software, see the “Software Upgrade” section on page 8-1.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-14
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Figure 7-7
SE Devices Home Page
The Bandwidth Served by Service Engine and the Bandwidth Efficiency Gain graphs are also displayed.
For more information, see the “Reports” section on page 7-25.
The Devices home page for an SE or an SR provides several icons. Table 7-9 describes these icons. The
CDSM home page has a subset of the icons.
Table 7-9
SE Devices Home Page Icons
Icon
Description
Displays all devices. Clicking this icon displays a list of the Service Engines. To view
or configure another Service Engine, click the Service Engine name. The configuration
page for that device is displayed and the left-panel menu displays. This feature allows
you to compare the configuration on different Service Engines. To return to the
left-panel menu, click the Display Menu icon.
Displays the left-panel menu for the device.
Refreshes the page.
Deletes the device. See the “Deleting a Device” section on page 8-10.
Updates application statistics. The device statistics are updated at a configurable time
interval, which is set in the System Configuration page
(System.monitoring.collectRate). See the “Configuring System Settings” section on
page 6-7. To see the latest statistics immediately, without waiting for the time interval
to elapse, click this icon.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-15
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-9
SE Devices Home Page Icons (continued)
Icon
Description
Forces a full database update from the CDSM to the SE. If the CDSM and SE databases
are not synchronized because of network errors or other errors, you can synchronize
them by clicking this icon.
Reboots the device. See the “Rebooting Devices” section on page 8-9.
Prints the home page.
For more information about the Devices home page, see the “Devices Home Page” section on page 3-8.
For more information on activating Devices via Device home page, see the “Activating and Setting NTP
for Each Device” section on page 3-3.
Using show and clear Commands
The show and clear commands offer more detailed monitoring of the device. Table 7-10 lists only the
show command parameters where arguments are required or are optional. Table 7-11 lists only the clear
command parameters where arguments are required. A full list of the show and clear commands is
available from the drop-down list on the respective page.
Using the CDSM show or clear Command Tool
To use the CDSM show or clear command tool, do the following:
Step 1
Choose Devices > Devices > Monitoring > Show/Clear Commands and then click either Show
Commands or Clear Commands.
Step 2
From the drop-down list, choose a command.
Step 3
Enter arguments for the command, if any.
Step 4
Click Submit to display the command output. The results of the command are displayed in a new
window.
Table 7-10
show Command Arguments
show Command
Arguments
Device
aaa
{commands [accounting | authorization] | enable
[authentication] | exec [accounting | authorization] | login
[authentication] | system [accounting | authorization]}
SE, SR,
CDSM
access-list
{300}
SE
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-16
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-10
show Command Arguments (continued)
show Command
Arguments
Device
acquirer
[delivery-service [delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name] | progress
[delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name] | proxy
authentication]
SE
alarms
[critical | detail | history | major | minor | status]
SE, SR,
CDSM
authentication
{user}
SE, SR,
CDSM
authsvr
[location-server | unknown-server]
SE
bandwidth
[flash-media-streaming | movie-streamer | wmt]
SE
bitrate
[wmt | movie-streamer]
SE
cache
[content 1-1000]
SE
cache-router
{routes {dss-engine | fms-engine | web-engine | wmt-engine} | SE
upstream-status}
capability
{profile 1-65535}
SE
cdn-statistics
{flash-media-streaming {device-group-name
device-group-name | device-groups | service-engines}
movie-streamer {service-engines | device-group-name
groupname | device-groups} | http {service-engines |
device-group-name groupname | device-groups} | wmt
{service-engines | device-group-name groupname |
device-groups}}
CDSM
cdnfs
{usage | volumes}
SE
clock
[detail | standard-timezones {all | details timezone | regions |
zones region-name}]
SE, SR,
CDSM
cms
{database {content {dump filename | text | xml} |
maintenance [detail]} | info | processes}
SE, SR,
CDSM
content
{all | diskpath diskpath| last-folder-url url | url url}
SE
content-mgr
{content {all {all-disk-volumes output-file filename |
SE
disk-volume disk_num output-file filename} | cache
{all-disk-volumes output-file filename| disk-volume disk_num
output-file filename} | prepos {all-disk-volumes output-file
filename | disk-volume disk_num output-file filename}}|
disk-info | eviction-list size file_size {all-disk-volumes
output-file filename | disk-volume disk_num output-file
filename} | eviction-protection output-file filename |
health-info}
content-origin
[request-fqdn domain_name]
SE
device-mode
{configured | current}
SE, SR,
CDSM
disks
[current | details | error-handling [details] | raid-state |
SMART-info [details]]
SE, SR,
CDSM
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-17
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-10
show Command Arguments (continued)
show Command
Arguments
Device
distribution
[delivery-services [delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name]]
SE, SR
[forwarder-list [delivery-service-id delivery-service-num
[detail] | delivery-service-name delivery-service-name [detail]
| detail]]
[location {forwarder-load-weight | live-load-weight |
location-leader-preference} [delivery-service-id
delivery-service-num | delivery-service-name
delivery-service-name]]
[object-status object-url]
[processes | remote]
[remote ip-address {metadata-sender delivery-service-id
delivery-service-num [start-generation-id gen-id
end-generation-id gen-id] | unicast-sender delivery-service-id
delivery-service-num {cdn-url cdn_url | probe |
relative-cdn-url cdn_url}}]
[remote traceroute {forwarder-next-hop delivery-service-id
delivery-service-num {max-hop maxhop_num | trace-till-good |
trace-till-root} | unicast-sender delivery-service-id
delivery-service-num {cdn-url cdn-url | probe |
relative-cdn-url cdn-url} {max-hop maxhop_num |
trace-till-good | trace-till-root}}]
flash-media-streaming [logging filename | mtrack] | stream-status live [all filename]] SE, SR
interface
{GigabitEthernet slot/port | PortChannel port-num | Standby SE, SR,
group_num | TenGigabitEthernet slot/port}
CDSM
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-18
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-10
show Command Arguments (continued)
show Command
Arguments
Device
ip
On SE or CDSM: {access-list [acl-name | acl-num] | routes}
SE, SR,
CDSM
On SR: {access-list [acl-name | acl-num] | bgp {ip-prefix |
network-ip-address | all | community [location-community] |
ipv4 unicast | memory | neighbors [neighbor-ip-address] |
nexthop-database | summary} | interface brief | opsf
[border-routers | database [adv-router
ip-address-advertising-router | asbr-summary
[ip-address-link-state-id | detail] | database-summary | detail |
external [ip-address-link-state-id | detail] | network
[ip-address-link-state-id | detail] | nssa-external
[ip-address-link-state-id | detail] | router
[ip-address-link-state-id | detail] | self-originated [detail] |
summary [ip-address-link-state-id | detail]] | interface |
memory | neighbor [ip-address-neighbor [detail] |detail |
summary] | request-list ip-address-neighbor-router
{GigabitEthernet slot/port | PortChannel channel-number} |
retransmission-list {GigabitEthernet slot/port | PortChannel
channel-number} | route [single-ip-route] | rspf route
[ip-address-advertising-router] | traffic] | proximity
{algorithm | server} | rib {clients [single-client] | memory |
recursive-next-hop [ip-address-next-virtual-hop] | route
[ip-address-single-route | bgp | direct | isis | ospf | summary] |
unresolved-next-hop [ip-address-unresolved-next-hop]} | route
| static route}
ipv6
access-list [1-99 standard IPv6 | 100-199 extended IPv6 |
access_list_name] | routes
SE, SR,
CDSM
isis
adjacency [detail] | clns route | database [advertise | detail
SR
[lsp id] | private | summary | lsp-id] | hostname-table |
interface [GigabitEthernet slot/port | PortChannel
channel-number] | ip {route [ip-address-route [detail] | detail |
summary] | rspf route [lsp-id] | memory | process | rrm
{GigabitEthernet slot/port | PortChannel channel-number} |
spf-log [detail] | srm {GigabitEthernet slot/port |
PortChannel channel-number} | ssn {GigabitEthernet
slot/port | PortChannel channel-number}}
key
{chain [decrypt | keychain-name]}
SR
lacp
{counters | internal}
SE, SR,
CDSM
movie-streamer
[bandwidth | cache | proxy]
SE
ntp
{status}
SE, SR,
CDSM
processes
[cpu | debug pid | memory | system [delay 1-60 | count 1-100]] SE, SR,
CDSM
programs
[movie-streamer [cli | live | rebroadcast] | program-id
program-id | program-name program-name | wmt [cli | live |
rebroadcast]
SE
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-19
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-10
show Command Arguments (continued)
show Command
Arguments
Device
rtsp
{gateway}
SE
rule
SE
{action [all [protocol {http | rtmp | rtsp}] | allow [protocol
{http | rtmp | rtsp}] | block [protocol {http | rtmp | rtsp}] |
generate-url-signature [protocol {http | rtmp | rtsp}] |
no-cache [protocol {http | rtmp | rtsp}] | protocol {http | rtmp
| rtsp} | redirect [protocol {http | rtmp | rtsp}] |
refresh [protocol {http | rtmp | rtsp}] |
rewrite [protocol {http | rtmp | rtsp}] |
protocol {http | rtmp | rtsp}] | validate-url-signature
[protocol {http | rtmp | rtsp}]] |
all | pattern-list {1-512 pattern-type | all}}
service-registry
{process | service}
SR
service-router
On SE: {keepalive-interval | service-monitor}
SE, SR,
CDSM
On SR: {access-policy | content-based-routing | forwarding
[content-origin content-origin] | lastresort [domain
domain-name] | load {all | sename sename} |
location-based-routing | memory | proximity-based-routing |
redirect-burst-control | redirect-mode | routes
[content-origin content-origin] | service-monitor | services {all
| sename sename] | subscribe domain | summary
[content-origin content-origin]}}
On CDSM: {service-monitor}
services
{ports [port-num] | summary}
SE, SR,
CDSM
snmp
{alarm-history | engine ID | group | stats | user}
SE, SR,
CDSM
srp
{database {key-hex-string | brief | content | group |
maincontent target-string | record key-hex-string | service | size
low high | statistics | subid key-hex-string target-string | update
start end} | leafset | memory | multicast database [brief |
statistics | group-id [elements start end | message target-string
| sender key-hex-string] | neighbor [detail | down] | process |
replica-set [statistics] | route [backup | statistics]
subscribers}
statistics
On all devices: aaa | fd | icmp | ip | lsof | netstat | radius |
services | snmp | tacacs | tcp | udp
On SR only: {cdn-select summary | ip [ospf | proximity {rib |
server}] | isis [GigabitEthernet slot/port | PortChannel
channel-number] | proximity-engine all | service-registry |
service-router {all | content-origin content-origin | dns |
history | keepalive | routing [geo-location | proximity] se
se-name | summary} srp}
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-20
SE, SR,
CDSM
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-10
show Command Arguments (continued)
show Command
Arguments
Device
statistics
On CDSM only: content-distribution-network device status
device-name or device-group-name or device-ID
SE, SR,
CDSM
replication {content-items content-item | delivery-service
[selected-delivery-service content-origin-name] | item
content-item-url | service-engines selected-delivery-service
content-origin-name}
On SE only:
access-lists 300
acquirer [contents {delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name} |
delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name | errors
{delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name} | job-list
{delivery-service-id delivery-service-num |
delivery-service-name delivery-service-name}]
authsvr [delivery-service-id delivery-service-num | global] |
cdnfs | content-mgr
distribution {all | errors {delivery-service-id
delivery-service-num | delivery-service-name name} |
metadata-receiver | metadata-sender | unicast-data-receiver
[delivery-service-id delivery-service-num [pending-queue
num_of_jobs | suspended-queue num_of_jobs | waiting-queue
[first [max_jobs] | last [max_jobs]]] | delivery-service-name
delivery-service-name [pending-queue num_of_jobs |
suspended-queue num_of_jobs | waiting-queue [first
[max_jobs] | last [max_jobs]]] | hot-forwarders [forwarder_id
forwarder_id {idle-queue [num-of-delivery-services] |
priority-queue [num-of-delivery-services]} | forwarder_name
forwarder_name {idle-queue [num-of-delivery-services] |
priority-queue [num-of-delivery-services]}] | idle-forwarders
[max_idle_forwarders]] | unicast-data-sender}
flash-media-streaming [connections | dvrcast | errors |
flvcache | livestats | performance | proxy | rules | server | swf
| vod]
movie-streamer {all | bw-usage | errors | performance |
requests | rule}
replication {content-items content-item | delivery-service
[selected-delivery-service content-origin-name]}
transaction-logs
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-21
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-10
show Command Arguments (continued)
show Command
Arguments
Device
statistics
web-engine [abr {hls-media-app [detail | fragment-file |
manifest-file | meta-file | session | summary] |
smoothhd-media-app [detail | fragment-file | manifest-file |
meta-file | session | summary] | zeri-media-app [detail |
fragment-file | manifest-file | meta-file | summary]| detail |
error | key-client | performance | usage]
SE, SR,
CDSM
wmt {all | bytes {incoming | outgoing} | cache | errors |
multicast multicast-station | requests | rule | savings |
streamstat [incoming | live | outgoing | stream-id 1-999999] |
usage}
Note
tech-support
[list-files list-file-directory | page | service
{acquisition-distribution | authentication | cms |
flash-media-streaming | kernel | movie-streamer | rules |
web-engine | wmt}]
SE, SR,
CDSM
user
{uid number | username name}
SE, SR,
CDSM
users
{administrative}
SE, SR,
CDSM
version
[pending]
SE, SR,
CDSM
web-engine
{all | delivery-service-configuration | health}
SE
wmt
[bandwidth [incoming bypass-list] | detail | diagnostics
{header-info {nsc-file nsc-file | stream-file stream-file} |
network-trace tcpdump-file} | http allow extension | proxy]
SE
All WMT playable contents can be delivered by either HTTP or RTSP, based on the request. Any content
that is cached by the WMT is stored using the RTSP scheme, regardless of whether the content was
cached due to an HTTP or RTSP request. Therefore, in the show command, the content displays as RTSP.
Table 7-11
clear Command Arguments
clear Command Arguments
Device
cache
{all | content 1-15000 | flash-media-streaming}
SE
content
{last-folder-url url | url url}
SE
isis
adjacency {all | GigabitEthernet slot/port | PortChannel
channel-number} | ip rspf route [lsp-id]
SR
ip
On all devices: {access-list counters 1-99 (standard IP) or
100-199 (extended IP) or access-list-name}
SE, SR, CDSM
On SR only: bgp {neighbor-ip-address | all} | ospf {neighbor {all
| GigabitEthernet slot/port | PortChannel channel-number} |
rspf route [ip-address-advertising-router | traffic}
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-22
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
Table 7-11
clear Command Arguments (continued)
clear Command Arguments
Device
ipv6
access-list counters [1-99 standard IPv6 | 100-199 extended IPv6 SE, SR, CDSM
| access_list_name]
service-router
{proximity-based-routing proximity-cache}
srp
database offline | descriptor {all | key-hex-string} | group
messages | neighbor {key-hex-string | hostname:port} | resource
key-hex-string unicast_resource | route prefix/length
statistics
On all devices: aaa | all | history | icmp | ip | radius | running |
snmp | tacacs | tcp | udp
SR
SE, SR, CDSM
On CDSM and SE only: distribution {all | metadata-receiver |
metadata-sender | unicast-data-receiver | unicast-data-sender}
On SR only: http requests | ip [ospf | proximity [rib | server]] |
isis [GigabitEthernet slot/port | PortChannel channel-number] |
service-registry | service-router | srp [replica-set]
On SE only: {access-lists 300 | authsvr {all | delivery-service-id
delivery-service-num | global}| content-mgr |
flash-media-streaming | movie-streamer | qos policy-service |
rule {action {allow | block | generate-url-signature | no-cache |
redirect | refresh | rewrite | validate-url-signature} | all | pattern
{1-512 | all} | rtsp} | transaction-logs | web-engine [force] |
wmt}
Note
users
{administrative}
SE, SR, CDSM
wmt
{encoder-alarm-msg alarm-message | stream-id 1-999999
[stale-stat]}
SE
The clear statistics web-engine and clear statistics all commands only clear normal statistics, not the
Web Engine statistics details. To clear all Web Engine statistics, use the clear statistics web-engine
force command. We do not recommend using the clear statistics web-engine force command, but if it
is used, restart the Web Engine service by entering the web-engine stop and web-engine start
commands.
Core Dump Files
The Core Dump Files page lists any core dump files for the device. To view a list of core dump files for
the device, choose Devices > Devices > Monitoring > Core Dump Files. The Core Dump File page is
displayed and lists any core dump files that have occurred on the device.
To delete a core dump file, check the check box next to the filename and click the Delete icon in the task
bar.
To delete all core dump files, check the check box in the heading of the check box column, and click the
Delete icon in the task bar.
To refresh the table, click the Refresh Table icon in the task bar.
To print the table, click the Print icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-23
Chapter 7
Monitoring the Internet Streamer CDS
Device Monitoring
The core dump files are located in the /local1/local1/core_dir directory.
CPU Utilization
The CPU Utilization report displays the CPU usage for the SE.
To view the CPU Utilization report for an SE, do the following:
Step 1
Choose Devices > Devices > Monitoring > Statistics > CPU Utilization. The CPU Utilization Report
page is displayed.
Step 2
Enter the settings as appropriate. Table 7-12 describes the report settings.
Table 7-12
Step 3
CPU Utilization Report Settings
Field
Description
Chart Size
The chart display size choices are small, medium, or large.
Time Frame
The time frame options are last hour, last day, last week, last month, or
custom. There is a difference in the meaning of the graphs based on the time
frame chosen:
•
Last Hour—Shows raw data collected from the SEs. Real-time values are
reported.
•
Last Day—Shows hourly data, which consolidates the raw data.
Consolidation is done by averaging the raw data for each hour. So the
value reported in the Last Day graph are average values per hour.
•
Last Week, Last Month, and Custom—Shows daily data, which
consolidates hourly data. Consolidation is done by averaging the hourly
data for each day. So these are average values per day.
Time Zone
The time zone choices are SE local time, CDSM local time, or UTC.
Custom Date Range
The custom date range is used when Time Frame is set to custom. Enter the
dates, beginning and end, for the chart in the mm/dd/yyyy format, or choose
the dates by using the calendar icons.
Click Update to see the report.
To export the report to a CSV (comma-separated value) file, click the Export icon in the task bar. A
dialog box is displayed. Choose either Open or Save.
If you choose Open, the tabular report is displayed in the same browser window or a new browser
window, depending on your browser.
If you choose Save, you are prompted to choose a location where to save the file. The file can be opened
with any spreadsheet program.
To print the report, click the Print icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-24
Chapter 7
Monitoring the Internet Streamer CDS
Reports
Reports
There are three reports available for monitoring traffic in graphical or tabular format:
•
Bandwidth Served
•
Bandwidth Efficiency Gain
•
Streaming Sessions
The reports have the following three scopes:
•
System-wide
•
Location
•
Service Engine
To access the system-wide reports, click the Home link in the upper-right corner of the CDSM browser
window. To change the report parameters for the System-Wide Bandwidth Served or System-Wide
Bandwidth Efficiency Gain graphs, click View Detailed Report. Clicking the Streaming Sessions link
opens the System-Wide Streaming Sessions page.
Note
Each report has a new data point every five minutes. The last data point (or last few data points if the
System.datafeed.pollRate is greater than five minutes) for system-wide reports and location-based
reports may fluctuate until the data point time interval has passed. The System.datafeed.pollRate
determines how often the system polls each SE for data. If the poll rate is one minute, five polling values
contribute to the data point in the report. The last data points in the system-wide reports are dynamic
because they may not have all the polling values yet.
The System-monitoring.collectRate is the rate at which the SE collects and reports statistics data to the
CDSM. At each collection period, the SE collects bandwidth values from each protocol engine and
reports that information to the CDSM.
To change the System.datafeed.pollRate and System.monitoring.collectRate settings, see the “System
Properties” section on page 6-8
Note
If the report states, “Insufficient data. Please make sure NTP is configured on the SE.” Be sure NTP is
configured for each device that is contributing data to the report. See the “Configuring NTP” section on
page 4-67 for more information.
To access reports covering activity for a location, do the following:
Step 1
Choose Devices > Locations. The Location Table page is displayed.
Step 2
Click the Edit icon next to the location name. The Location page is displayed.
Step 3
Choose Statistics and choose one of the following reports: Bandwidth Served, Bandwidth Efficiency
Gain, or Streaming Sessions.
To access reports covering activity for an SE, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-25
Chapter 7
Monitoring the Internet Streamer CDS
Reports
Step 2
Click the Edit icon next to the device name. The Devices home page is displayed.
Step 3
Choose Monitoring > Statistics and choose one of the following reports: Bandwidth Served,
Bandwidth Efficiency Gain, or Streaming Sessions.
To export the report to a CSV (comma-separated value) file, click the Export icon in the task bar. A
dialog box is displayed. Choose either Open or Save.
If you choose Open, depending on your browser, the tabular report is displayed in either a new browser
window or the same browser window.
If you choose Save, you are prompted to choose a location where to save the file. The file can be opened
with any spreadsheet program.
To print the report, click the Print icon in the task bar.
The reports are described in the following sections.
Bandwidth Served
The Bandwidth Served report provides information about the total outgoing bandwidth of all the
protocol engines on an SE, or if you are viewing the system-wide report, all the protocol engines on all
the SEs in the system. The Bandwidth Served report also provides a table with the Maximum Value,
Average Value, and License Limit. The Maximum Value is the maximum rate (in bits per second)
achieved for the specified content type. The Average Value is the average rate (in bits per second) for the
specified content type during the specified period of time. The License Limit does not currently apply
to the Internet Streamer CDS software.
Note
The Bandwidth Served report displays information based on clients that have completed their
downloads. Clients that are in the process of downloading when the report is generated are not reflected
in the Bandwidth Served report.
To change the report settings and view the changes, navigate to the page using the instructions provided
at the beginning of the “Reports” section on page 7-25.
Table 7-13 describes the report settings.
Table 7-13
Bandwidth Served Report Settings
Field
Description
Server
The options are HTTP, Windows Media, Movie Streamer, or Flash Media
Streaming. Check the check boxes next to the protocol engines you want
to include in the graph.
Chart Style
The options are line or area.
Chart Size
The chart display size choices are small, medium, or large.
Aggregation Method
For system-wide and location reports only. Choices are sum or average,
where sum gives you the sum total of all bandwidth served in the system
or location, and average divides the sum total by the number of SEs in the
system or location.
Include Child Location
For location report only. If checked, all child locations are included in the
report.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-26
Chapter 7
Monitoring the Internet Streamer CDS
Reports
Table 7-13
Tip
Bandwidth Served Report Settings (continued)
Field
Description
Time Frame
The time frame options are last hour, last day, last week, last month, or
custom. There is a difference in the meaning of the graphs based on the
time frame chosen:
•
Last Hour—Shows raw data collected from the SEs. Real-time values
are reported.
•
Last Day—Shows hourly data, which consolidates the raw data.
Consolidation is done by averaging the raw data for each hour. So the
value reported in the Last Day graph are average values per hour.
•
Last Week, Last Month, and Custom—Shows daily data, which
consolidates hourly data. Consolidation is done by averaging the
hourly data for each day. So these are average values per day.
Time Zone
The time zone choices are SE local time, CDSM local time, or UTC.
Custom Date Range
The custom date range is used when Time Frame is set to custom. Enter
the dates, beginning and end, for the chart in the mm/dd/yyyy format, or
choose the dates by using the calendar icons.
Set the Chart Style to medium to see the legend and timeline across the bottom.
Bandwidth Efficiency Gain
After an SE has been in use for some time and has collected statistics, the Bandwidth Efficiency Gain
report can demonstrate the value of the SE in terms of bandwidth savings. The bandwidth efficiency is
calculated by subtracting the bandwidth in from the bandwidth out, providing the bandwidth saved from
serving content from the SE (cache hit, pre-positioned content, or splitting of live streams).
Table 7-14 describes the report settings.
Table 7-14
Bandwidth Efficiency Gain Report Settings
Field
Description
Series
The series options are In, Out, and Efficiency Gain. The In option creates a
graph for bandwidth used for incoming data. The Out option is for outgoing
data, and Efficiency Gain is the combination of the two.
Chart Size
The chart display size choices are small, medium, or large.
Aggregation Method
For system-wide and location reports only. Choices are sum or average,
where sum gives you the sum total of all bandwidth served in the system or
location, and average divides the sum total by the number of SEs in the
system or location.
Include Child Location
For location report only. If checked, all child locations are included in the
report.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-27
Chapter 7
Monitoring the Internet Streamer CDS
Reports
Table 7-14
Tip
Bandwidth Efficiency Gain Report Settings (continued)
Field
Description
Time Frame
The time frame options are last hour, last day, last week, last month, or
custom. There is a difference in the meaning of the graphs based on the time
frame chosen:
•
Last Hour—Shows raw data collected from the SEs. Real-time values
are reported.
•
Last Day—Shows hourly data, which consolidates the raw data.
Consolidation is done by averaging the raw data for each hour. So the
value reported in the Last Day graph are average values per hour.
•
Last Week, Last Month, and Custom—Shows daily data, which
consolidates hourly data. Consolidation is done by averaging the hourly
data for each day. So these are average values per day.
Time Zone
The time zone choices are SE local time, CDSM local time, or UTC.
Custom Date Range
The custom date range is used when Time Frame is set to custom. Enter the
dates, beginning and end, for the chart in the mm/dd/yyyy format, or choose
the dates by using the calendar icons.
Set the Chart Size to medium to see the legend and timeline across the bottom.
Streaming Sessions
The Streaming Sessions report lists the total number of streaming sessions in progress at the collection
time. It allows you to plan for future hardware provisioning and licensing requirements based on
utilization data. Table 7-15 describes the report settings.
Table 7-15
Streaming Sessions Report Settings
Field
Description
Server
The options are Windows Media unicast, Windows Media multicast, Movie
Streamer unicast, or Flash Media unicast. Check the check boxes next to the
streaming types you want to include in the graph.
Chart Size
The chart display size choices are small, medium, or large.
Aggregation Method
For system-wide and location reports only. Choices are sum or average, where
sum gives you the sum total of all bytes served in the system or location, and
average divides the sum total by the number of SEs in the system or location.
Include Child Location For location report only. If checked, all child locations are included in the
report.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-28
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-15
Streaming Sessions Report Settings (continued)
Field
Description
Time Frame
The time frame options are last hour, last day, last week, last month, or
custom. There is a difference in the meaning of the graphs based on the time
frame chosen:
•
Last Hour—Shows raw data collected from the SEs. Real-time values are
reported.
•
Last Day—Shows hourly data, which consolidates the raw data.
Consolidation is done by averaging the raw data for each hour. So the
value reported in the Last Day graph are average values per hour.
•
Last Week, Last Month, and Custom—Shows daily data, which
consolidates hourly data. Consolidation is done by averaging the hourly
data for each day. So these are average values per day.
Time Zone
The time zone choices are SE local time, CDSM local time, or UTC.
Custom Date Range
The custom date range is used when Time Frame is set to custom. Enter the
dates, beginning and end, for the chart in the mm/dd/yyyy format, or choose
the dates by using the calendar icons.
Note
Streaming Sessions statistics report for Movie Streamer is only available for unicast. When a client is
joining a multicast group for multicast streaming, CDS Movie Streamer only knows that a client is
downloading the SDP file, but no information is exchanged between the client and Movie Streamer on
the streaming data session; therefore there are no session statistics for multicast Movie Streamer
sessions.
Tip
Set the Chart Size to medium to see the legend and timeline across the bottom.
Delivery Service Monitoring
This section covers the following topics:
•
Delivery Services Table
•
Replication Status for a Delivery Service
Delivery Services Table
The Delivery Services Table page lists all delivery services on the system and displays the replication
status information for each delivery service. This display summarizes the replication status of all SEs
associated with a specific delivery service in a given state.
Table 7-16 describes the icons for the delivery service table. To view or modify the configuration of a
delivery service, click the Edit icon next to the delivery service name. To create a new delivery service,
click the Create New icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-29
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-16
Icon
Delivery Service Table Icons
Function
Creates a new delivery service.
Edits a delivery service.
Creates a filtered table. Filter the delivery service by the delivery
service name and content origin.
Views all delivery services. Click this icon to view all delivery services
after you have created a filtered table.
Refreshes the table.
Prints the current window.
For more information, see the “Devices, Services, and Other Tables” section on page 3-7.
To view system-wide replication status for each delivery service, do the following:
Step 1
Choose Services > Delivery Services to display the Delivery Services Table page. See Figure 7-8.
Figure 7-8
Step 2
Delivery Services Table Page
View the replication status information for each delivery service. Table 7-17 describes the status
information that is displayed on this page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-30
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-17
System-Wide Replication Status by Delivery Service
Column Heading
Description
Delivery Service
Name of the delivery service.
Type
Type of delivery service. The delivery service types are Live and Content.
Content Origin
Name of the Content Origin assigned to the delivery service.
Status
Graphical display indicating acquisition, replication, and device errors. Status
lights represent the highest level of errors encountered:
•
Green—No errors encountered.
•
Yellow—Only minor errors encountered.
•
Red—At least one critical error encountered, such as an acquisition failure,
a content replication failure, or a failed or nonresponsive SE.
For details of the errors, click the status light for a particular delivery service,
which takes you to the Replication Status for Delivery Service page. (See
Table 7-18 for a description of status errors and their corresponding status lights.)
State
State of the delivery service. States are reported for the Content Acquirer and for
receiver SEs. (See Table 7-19 for a definition of the different delivery service
states.)
The state is also a link to the Replication Status for Delivery Service page that
provides a more detailed view of the replication status for the delivery service.
(See Figure 7-9.)
Manifest State
State of the Manifest file. States reported are as follows:
•
Fetching—The Manifest file is being fetched.
•
Fail Fetching—The Manifest file has failed to be fetched.
•
Parsing—The Manifest file is being parsed.
•
Fail Parsing—The Manifest file has failed to be parsed.
•
Completed—The Manifest file was successfully fetched and parsed.
•
No Status Reported—Content Acquirer is in a Pending or Disabled state.
Table 7-18 describes the status errors and their corresponding status lights.
Table 7-18
Delivery Service Status Errors
Status Light
Error
Description
Yellow
Manifest retrieval error
The Content Acquirer cannot retrieve the Manifest file
for one or two consecutive attempts.
Red
Manifest retrieval error
The Content Acquirer cannot retrieve the Manifest file
for three consecutive attempts.
Red
Manifest syntax error
The Content Acquirer fails to parse the Manifest file.
Red
Crawl job processing error
The Content Acquirer encounters problems while
crawling for content.
Red
Acquisition or content
replication error
The SE fails to obtain the content.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-31
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-18
Delivery Service Status Errors (continued)
Status Light
Error
Description
Red
Disk quota exceeded error
The SE cannot store or process the content because there
is no more disk space available.
Yellow
Replication status update
error
Content replication failed for one or two consecutive
attempts.
Red
Replication status update
error
Content replication failed for three or more consecutive
attempts.
Red
SE unreachable error
The SE is offline or the SE has not responded to
replication status requests for three consecutive polling
periods.
Red
Root SE failover
The Content Acquirer has failed over to a temporary
Content Acquirer. Receiver SEs have not identified a
valid Content Acquirer.
Red
Receiver SE device or
delivery service error
Receiver SE is not reporting replication status or any
other content replication problem.
Table 7-19 defines the different delivery service states.
Table 7-19
Delivery Service States in Replication Status
State
Description
Completed
All receiver SEs are in the Completed state, and the Content Acquirer is in the Completed,
Re-checking Content, Retrieving Manifest, or Processing Manifest state. (See Table 7-22
on page 7-35 for a description of SE states.)
When the Content Acquirer in the Re-checking Content state determines that new content
needs to be acquired, the delivery service state changes to In Process.
In Process
Failed
In Process can mean:
•
Content Acquirer is in the Retrieving Manifest, Processing Manifest, Acquiring
Content, or Re-checking Content state.
•
Any receiver SE is in the Pending Update from Content Acquirer, Replicating, or
Recovering from Failure state.
•
Content Acquirer has failed and receiver SEs are still reporting status.
Failed can mean:
•
Acquisition or content replication error has occurred. (See Table 7-18 on page 7-31.)
•
SE has gone offline or has not reported status in three consecutive polling periods.
•
Delivery service has more than one Content Acquirer
•
Delivery service has no Content Acquirer, but has receiver SEs reporting replication
status.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-32
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Replication Status for a Delivery Service
To view the replication status for a delivery service, you can either click the alarm light or Replication
Status link in the Delivery Services Table page, or click the Replication Status option from the Delivery
Service left-panel menu. Figure 7-9 shows the Replication Status page for a delivery service. The
Replication Status page is refreshed automatically every 15 seconds.
Figure 7-9
Delivery Service Replication Status Page
Table 7-20 describes the fields in Acquisition Status section of this page.
This page also allows you to do the following:
•
See a detailed view of replication status using search criteria. (See the “Content Replication Status
by Delivery Service” section on page 7-36.)
•
Query the replication status of content items (by pattern) for a selected SE in the delivery service.
(See the “Content Replication Status by Device” section on page 7-38.)
The information on the Replication Status page is refreshed approximately every ten seconds.
Table 7-20
Replication Status for a Delivery Service
Field
Description
User Selected Content
Acquirer
Name of the user-selected Content Acquirer.
Current Content Acquirer
Name of the current Content Acquirer. The current Content Acquirer
is the same as the user-selected Content Acquirer as long as the
user-selected one is active; if it fails for any reason, the temporary
Content Acquirer becomes the current Content Acquirer.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-33
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-20
Replication Status for a Delivery Service (continued)
Field
Description
Disk Quota Used
Amount of available disk space used for the delivery service.
Status
State of the Content Acquirer. (For a description of Content Acquirer
states, see Table 7-22.)
Manifest Last Modified Time Time when the Manifest file was last saved, as recorded on the SE.
Manifest Last Checked Time
Time when the Content Acquirer last checked the Manifest file for
changes.
Table 7-21 describes the information about the devices in this delivery service shown at the bottom of
the Replication Status page.
Table 7-21
Replication Status for Devices Assigned to a Delivery Service
Field
Description
Device
Name of the SE assigned to the delivery service.
Type
Type of SE: Acquirer, Receiver, or Temporary Acquirer.
Status
Graphical display indicating acquisition, replication, and device errors.
Status lights represent the highest level of errors encountered:
•
Green—No errors encountered.
•
Yellow—Only minor errors encountered.
•
Red—At least one critical error encountered, such as an
acquisition failure, a content replication failure, or a failed or
nonresponsive SE.
State
State of either the Content Acquirer or receiver SEs. (See Table 7-22
for a description of SE states.)
Progress
Replication progress (in percent). The interval between progress
updates is configurable (see the “System Properties” section on
page 6-8).
Last Report Time
Time when the last report from the SE was received by the CDSM. This
time stamp uses the CDSM clock.
File Count
Completed
Number of files that the SE has successfully acquired or received.
In Process
Number of new files to be acquired or replicated. Includes only files
for which no acquisition or replication attempts have previously been
made.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-34
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-21
Replication Status for Devices Assigned to a Delivery Service (continued)
Field
Description
Failed
For the Content Acquirer: Number of files that failed to be acquired in
at least one attempt.
For receiver SEs: Number of files that failed to be replicated in at least
one attempt.
Note
Total
The failure count for the receiver SE has no relationship to the
failure count for the Content Acquirer. If the Content Acquirer
fails to replicate an item, the receiver counts this item as “In
Process.”
Total number of Completed, In Process, and Failed files.
Table 7-22 describes the states of the Content Acquirer or receiver SE.
Table 7-22
Device States
State
Description
Content Acquirer
Retrieving Manifest
The Content Acquirer is retrieving the Manifest file from the origin
server or rechecking the Manifest file for changes.
Processing Manifest
The Content Acquirer has retrieved the Manifest file and is parsing it.
Acquiring Content
The Content Acquirer has processed the Manifest file and is crawling or
fetching content.
Re-checking Content
The Content Acquirer is checking the content or crawl job freshness.
No Status Reported
No Status Reported can mean:
Completed
•
The Content Acquirer is unreachable for three consecutive polling
periods.
•
The Content Acquirer is offline.
•
The CDSM has recently restarted and has not yet received a report
from the Content Acquirer.
The Content Acquirer is not in the Retrieving Manifest, Processing
Manifest, Acquiring Content, Re-checking Content, or No Status
Reported state.
Receiver SE
Pending Update from
Acquirer
The receiver SE is not synchronized with the Content Acquirer.
Replicating
The receiver SE is synchronized with the Content Acquirer and is
replicating content.
Completed
The receiver SE has finished replicating all the content with no errors.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-35
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-22
Device States (continued)
State
Description
Recovering from Failure
The receiver SE has not identified the Content Acquirer. This state occurs
during a failover from the Content Acquirer to a temporary Content
Acquirer.
No Status Reported
No Status Reported can mean:
•
Receiver SE is unreachable for three consecutive polling periods.
•
Receiver SE is offline.
•
CDSM has recently restarted and has not yet received a report from
the receiver Service Engine.
Content Replication Status by Delivery Service
In the View Detailed Replication Status section of the Replication Status page, enter a search string in
the Get Detailed Status Using field and click Go.
For help on allowed search string characters, click Search Criteria.
Use an asterisk (*) to match one or more characters, or a question mark (?) to match only a single
character. The criteria are matched against the relative cdn-url attribute specified in the <item> tag in
the Manifest file. We recommend that you start the search criteria by specifying wildcards such as *.htm
or *clip.mpeg.
Figure 7-10 shows the results of a detailed status search for a delivery service.
Figure 7-10
Replication Status for Searched Content Items in a Delivery Service
Table 7-23 describes the information displayed for the replication items.
Table 7-23
Replication Status of Items for a Delivery Service
Column Heading
Description
Url
URL of the origin server that stores the content.
Size
Size of the file to be acquired or crawled.
Status
Status of replication of content in the delivery service. The status is shown
as Complete if replication is completed on all SEs assigned to the delivery
service.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-36
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-23
Note
Replication Status of Items for a Delivery Service
Column Heading
Description
Replicated SEs
Number of SEs that have replicated this item.
Playtime
Duration of playback of the file.
Modification Time
Timestamp of the earliest update for that delivery service from an active
SE.
When you click the Force replication information refresh icon in the task bar, the system displays a
dialog box asking you to confirm whether you want to refetch the information from SEs assigned to this
delivery service. To continue with the refresh process, click OK. You are notified that the request has
been queued and are asked to check back later.
To return to the previous page, click the Back icon in the task bar.
To get detailed information about the replication status of the content item, click the View icon
(eyeglasses) next to the URL. Detailed replication information is displayed (Figure 7-11). This page
provides details on the replication status of the content item for every SE in the delivery service.
Table 7-24 describes the information on this page.
Figure 7-11
Note
Replication Status for Searched Content Items in a Delivery Service—Detail
The Replication Item page is specifically designed to limit listings to 5000 objects for scalability
reasons. These are system limits and not specifically enforced for replication status reporting.
Table 7-24
Replication Status of an Item for All SEs in a Delivery Service
Column Heading
Description
SE
Name of the SE to which the item has been replicated.
Size
Size of the file to be acquired or crawled.
Status
Status of the replication of the content on the SE. Status is shown as Complete
if replication is complete on all SEs assigned to the delivery service.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-37
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Table 7-24
Replication Status of an Item for All SEs in a Delivery Service
Column Heading
Description
Playtime
Duration of playback of the file.
Modification Time
Timestamp of the latest update for the content item as recorded on the origin
server.
To return to the previous page, click the Back icon in the task bar.
Content Replication Status by Device
Queries to determine the detailed replication status of a content item trigger extensive CPU cycles and
high consumption of memory, because all the SEs assigned to a delivery service need to be polled, and
the retrieved replication status is cached in the memory of the CDSM. This results in performance
degradation. To optimize the use of memory resources without compromising the need to obtain detailed
replication status of a particular content item, you can choose an SE assigned to a delivery service and
generate a query.
To view the detailed replication status for a delivery service by device, do the following:
Step 1
From the Replication Status page, in the Devices Assigned to Delivery Service section (see Figure 7-9),
click the radio button next to the name of the device that you want to view.
Step 2
In the View Detailed Replication Status for Delivery Service by Device section, do the following:
a.
Choose content items (all, replicated, or nonreplicated) from the Get drop-down list.
b.
In the Content Items Using field, enter a string that specifies the type of content items that you want
displayed and click Go.
Note
Use an asterisk (*) to match one or more characters, or a question mark (?) to match only a single
character.
The Replication Items page for the selected device is displayed (Figure 7-12). Table 7-25 describes the
fields displayed in this page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-38
Chapter 7
Monitoring the Internet Streamer CDS
Delivery Service Monitoring
Figure 7-12
Table 7-25
Step 4
Replication Status of Items for a Delivery Service by Device
Column Heading
Description
Url
URL of the origin server that stores the content.
Size
Size of the file to be acquired or crawled.
Status
Status of replication of content for the selected SE.
Playtime
Duration of playback of the file.
Modification Time
Timestamp of the latest update to the content item as recorded on the
origin server.
Note
Step 3
Replication Items for a Selected Device
When you click the Force replication information refresh icon in the task bar, the system
displays a dialog box asking you to confirm whether you want to refetch the information from
SEs assigned to this delivery service. To continue with the refresh process, click OK. You are
notified that the request has been queued and are asked to check back later.
To refine your search from this window, do the following:
a.
Make a choice from the Get drop-down list.
b.
Enter a search string in the Content Items Using field.
c.
To retrieve the specified items, click Go.
To return to the Replication Status page, click the Back icon in the task bar.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-39
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Viewing Statistics
The Statistics pages track system-wide delivery, replication, and routing traffic in the CDS. You can view
statistics on delivery traffic (Movie Streamer, Windows Media, HTTP, and Flash Media) listed by SE or
device group. The Routing Statistics page lists client requests and redirects. The Replication Statistics
page lists the replication status for all SEs in the CDS, and provides a drill-down to all delivery services
for a chosen SE, and all content items associated with that delivery service. The Proximity Engine
statistics provides overall statistical information on the Proximity Engine, and specific statistical
information on IS-IS, OSPF, and SRP.
This section contains the following procedures:
•
Viewing Service Engines and Device Group Statistics
•
Viewing Routing Statistics
•
Viewing Replication States
•
Viewing Proximity Engine Statistics
Viewing Service Engines and Device Group Statistics
To view the statistics for all SEs or all device groups, do the following:
Step 1
Choose Devices > Statistics. The Statistics page is displayed.
Step 2
Choose Service Engines or Device Groups, and then choose one of the following content delivery
types:
•
Movie Streamer
•
HTTP
•
Windows Media
•
Flash Media
Table 7-26 describes the icons provided on the Statistics pages.
Table 7-26
Icon
Statistics Icons
Function
Update application statistics. The statistics are updated at a configurable time
interval, which is set in the System Configuration page
(System.monitoring.collectRate). See the “Configuring System Settings” section on
page 6-7. To see the latest statistics immediately, without waiting for the time interval
to elapse, click this icon.
Export a table to a comma-separated value (CSV) file.
Refresh the table
Print the current window.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-40
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Table 7-27 describes each statistic for each content delivery type.
Table 7-27
Service Engine and Device Group Statistics
Statistic
Description
Movie Streamer
Bandwidth In
Current bandwidth used for input by the Movie Streamer in bits per second.
Bandwidth Out
Current bandwidth used for output by the Movie Streamer in bits per second.
Bandwidth In
Total bandwidth, in bits per second, received by the Movie Streamer since it was
started.
Bandwidth Out
Total bandwidth, in bits per second, transmitted by the Movie Streamer since it
was started.
Packets In
Total packets received by the Movie Streamer since it was started.
Packets Out
Total packets transmitted by the Movie Streamer since it was started.
RTSP Connections
Number of clients currently connected over RTSP.
RTP Connections
Number of clients connected since startup.
Updated
Timestamp indicating when the statistics were updated.
HTTP
Requests/Sec
Number of requests per second.
Bytes/Sec
Number of bytes per second.
Request Latency
Average number of seconds per HTTP request.
Hit Rate
Average number (as a percentage) of content items successfully served per
minute from the cache of the SE or from all the SEs in the device group.
Updated
Timestamp indicating when the statistics were updated.
Windows Media
Concurrent
Requests
Total number of simultaneous requests the Windows Media Streaming Engine
has served.
Bandwidth
Current bandwidth, in bits per second, that is used for output.
Cache Hit Rate
Average number (as a percentage) of content items successfully served per
minute from the cache of the SE or from all the SEs in the device group
Updated
Timestamp indicating when the statistics were updated.
Flash Media
Byte/Sec
Total number of bytes per second served.
All Connections
Number of clients currently connected.
Cache Hit Rate
Average number (as a percentage) of content items successfully served per
minute from the cache of the SE or from all the SEs in the delivery service.
Updated
Timestamp indicating when the statistics were updated.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-41
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Viewing Routing Statistics
To view the routing statistics for SRs, do the following:
Step 1
Choose Devices > Statistics > Routing Statistics.
Step 2
Choose one of the following options:
•
Routing Requests
•
Routing Redirects
See Table 7-26 for descriptions of the icons provided on the Routing Statistics pages. Table 7-28
describes each routing statistic.
Table 7-28
Service Router Statistics
Statistic
Description
Routing Requests
Total Requests
Total number of content requests received from clients.
HTTP Requests
Number of ASX and traditional HTTP web requests received.
RTSP Requests
Number of RTSP requests received.
RTMP Requests
Number of RTMP requests received.
Updated
Timestamp indicating when the statistics were updated.
Routing Redirects
Total Requests
Total number of content requests received from clients.
Reqs Redirected
Total number of redirected client requests.
Reqs Not Redirected
Total number of client requests not redirected.
Updated
Timestamp indicating when the statistics were updated.
Viewing Replication States
To view system-wide replication states by device, do the following:
Step 1
Choose Devices > Statistics > Replication Status. The replication states for all SEs in the CDS are
displayed.
Table 7-29 describes the status information displayed on this page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-42
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Table 7-29
Device Replication Status Page
Column Heading
Description
Device
Name of the SE.
Status
Graphical display indicating acquisition, replication, and device errors. Status
lights represent the highest level of errors encountered:
•
Green—No errors encountered.
•
Yellow—Only minor errors encountered.
•
Red—At least one critical error encountered, such as an acquisition
failure, a content replication failure, or a failed or nonresponsive SE.
(See Table 7-18 for a description of status errors and their corresponding
status lights.)
Delivery Service
Count
Step 2
Number of delivery services reporting SEs in a particular state. (See
Table 7-22 for a description of SE states.)
Completed
Number of delivery services reporting this SE in a Completed state.
In Process
In Process can mean:
•
Number of delivery services reporting this SE (as a Content Acquirer) in
the Retrieving Manifest, Processing Manifest, Acquiring Content, or
Re-checking Content state.
•
Number of delivery services reporting this SE (as a receiver SE) in the
Pending Update from Acquirer, Replicating, or Recovering from Failure
state.
Failed
Number of delivery services reporting this SE in the Failed or Failed Update
state.
Unknown
Number of delivery services reporting this SE in the No Status Reported state.
To view the statistics on the delivery services associated with this SE, click View (the eyeglasses icon)
next to the SE.
The Replication Status for each delivery service that uses the SE to deliver content is displayed. The first
column in this table lists the delivery service that uses the SE, the columns that follow list information
about the SE’s function in the delivery service. For a description of the subsequent columns, see
Table 7-21 on page 7-34.
Step 3
To view replication details for the selected delivery service, click the radio button next to the delivery
service name.
To view the forwarding path for this delivery service, click View (the eyeglasses icon) next to the
delivery service. After you are finished viewing the forwarding path, choose Replication Status to
return to the Replication Status page.
Step 4
From the Get drop-down list, choose the type of items to display (all, replicated, or non replicated).
Step 5
In the Content Items Using field, enter a regular expression (such as *.html, *.mpg, *.jpg, or *.*). Use
an asterisk (*) to match one or more characters, and a question mark (?) to match exactly one character.
Step 6
To retrieve the specified items, click Go. The Replication Items for Delivery Service page is displayed.
Table 7-30 describes the fields displayed in this page.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-43
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
The Replication Items for Delivery Service page is specifically designed to limit listings to 5000
objects for scalability reasons. These are system limits and are not specifically enforced for
replication status reporting.
Note
Table 7-30
Replication Status of Items for SEs in a Selected Delivery Service
Column Heading
Description
URL
URL of the origin server that stores the content.
Size
Size of the file to be acquired or crawled.
Status
Status of replication of content from the Content Acquirer.
Playtime
Duration of playback of the file.
Modification Time
Timestamp of the earliest update for that delivery service from an
active SE.
Step 7
To further qualify your search, change the item type from the drop-down list, if you wish, or specify
another file type (such as *.html, *.mpg, or *.jpg) in the Content Items Using field. To retrieve the
specified items, click Go.
Step 8
To forcibly refetch the latest content replication information, click the Force Replication Information
Refresh icon in the task bar. You are asked to confirm whether or not you wish to refetch the information
from the SE assigned to the particular delivery service.
Step 9
To continue with the refresh process, click OK. You are notified that your request has been sent and
prompted to check back after a few minutes.
Step 10
To return to the Replication Status page, click the Back button in the task bar.
To view the SE forwarder path for a selected delivery service, click the View icon next to the name of
the delivery service. To return to the Replication Status page, choose Replication Status in the left-panel
menu.
Viewing Proximity Engine Statistics
This section contains the following procedures:
•
Viewing Overall Proximity Statistics
•
Viewing IS-IS Statistics
•
Viewing OSPF Statistics
•
Viewing SRP Statistics
See Table 7-26 for descriptions of the icons provided on the Proximity Statistics pages.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-44
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Viewing Overall Proximity Statistics
To view the overall statistics of the Proximity Engine, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the Service Router. The Devices home page is displayed.
Step 3
Choose Statistics > Proximity. The Proximity Statistics are displayed.
Table 7-31 describes each proximity statistic.
Table 7-31
Proximity Statistics
Statistic
Description
Application total requests
Total number of proximity requests received from applications.
Application total replies
Total number of proximity replies sent to applications.
Invalid Application request
Invalid proximity requests from applications.
PSA non-rankable application
requests
Proximity source address (PSA) non-rankable proximity
requests from applications.
Failed proximity requests
Failed proximity requests to routing protocols.
Failed PSA lookups
Failed PSA lookups.
Failed PTA lookups
Failed proximity target address (PTA) lookups.
Location Application requests
Local proximity requests from applications.
Message
Routing protocol participating in message exchange.
Sent Prox Req
Proximity message exchanges between the routing process and
the routing protocols.
Received Prox Req
Proximity message exchanges between the routing process and
the routing protocols.
Proximity Server Requests Received
Received requests by the Proximity Engine.
Proximity Server Response Sent
Responses made by the Proximity Engine.
Proximity Server Faults Sent
Faults sent by the Proximity Engine.
Proximity Server Redirect Faults
Sent
Faults sent by the Proximity Engine that were redirected
requests.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-45
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Viewing IS-IS Statistics
To view the IS-IS statistics of the Proximity Engine, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the Service Router. The Devices home page is displayed.
Step 3
Choose Statistics > ISIS. The IS-IS Statistics are displayed.
Table 7-32 describes each IS-IS statistic.
Table 7-32
IS-IS Statistics
Statistic
Description
First Section (LAN-IIH, P2P-IIH, CSNP, and PSNP PDU-type packets)
Interface
From the Interface drop-down list, choose a specific interface
or All.
PDU
Packet data unit (PDU) type.
Received
Packets received by IS-IS.
Sent
Packets sent by IS-IS.
RcvAuthErr
Count of messages that failed authorization.
OtherRcvErr
Count of messages that failed due to other errors.
Second Section (LSU PDU-type packets)
PDU
Packet data unit (PDU) type.
Received
Packets received by IS-IS.
Flooded
Packets flooded by IS-IS.
RcvAuthErr
Count of messages that failed authorization
OtherRcvErr
Count of messages that failed due to other errors.
ReTransmit
Packets retransmitted by IS-IS.
Third Section
DIS elections
Designated Intermediate System (DIS)
SPF calculations
Shortest path first (SPF) calculation count by IS-IS.
LSPs sourced
Link state packets (LSPs) sourced out by IS-IS.
LSPs refreshed
LSPs refreshed by IS-IS.
LSPs purged
LSPs purged by IS-IS.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-46
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Viewing OSPF Statistics
To view the OSPF statistics of the Proximity Engine, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the Service Router. The Devices home page is displayed.
Step 3
Choose Statistics > OSPF. The OSPF Statistics are displayed.
Table 7-33 describes each OSPF statistic.
Table 7-33
OSPF Statistics
Statistic
Description
Router Information Changes
Router ID changes
Total number of OSPF router IDs changed.
DR elections
Total number of OSPF designated router (DR) elections.
Older LSAs received
Total number of older link state advertisements (LSAs)
received.
Neighbor state changes
Total number of neighbor state changes.
Neighbor dead postponed
Total number of times a dead neighbor event was postponed.
Neighbor dead interval expirations
Total number of neighbors that exceeded the router dead
interval (RDI) and are now considered down.
Neighbor sequence number
mismatches
Total number of neighbor sequence mismatches.
SPF computations
Total number of SPF computations.
LSA Statistics
LSA Type
LSA types consist of Router, Network, Summary Net,
Summary autonomous system border router (ASBR), AS
External, Opaque Link, Opaque Area, and Opaque AS.
Generated
Total number of LSA packets generated.
Refreshed
Total number of LSA packets refreshed.
Flushed
Total number of LSA packets that were flushed.
Aged out
Total number of LSA packets that were aged out.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-47
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Table 7-33
OSPF Statistics (continued)
Statistic
Description
Counters
LSA deletions
Hello queue
Information displayed about the LSA deletions:
Pending—Number of LSA deletions that are pending
•
HWM—High water mark (hwm) of pending deletions
•
Deleted—Number of LSAs that have been deleted
•
Revived—Number of LSAs that have been revived
•
Runs—Number of times the purge routine has run since the
OSPF process was started.
Information displayed about the packets being processed in the
hello queue:
•
Current number in queue/maximum number allowed in
queue; for example 0/200
•
High water mark (hwm) is the maximum number of packets
ever stored in the queue
•
Drops are the number of packets dropped because the
queue was full.
Flood queue
Information about the flood queue.
LSDB additions failed
Total number of link state database (LSDB) additions that
failed.
Buffers
Memory buffer size.
in use
Amount of the buffer that is currently being used.
hwm
Amount of the buffer that is reserved for the hwm.
permanent
Amount of the buffer that is permanently reserved.
alloc
Amount of the buffer that is currently allocated.
free
Amount of the buffer that is currently free.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-48
•
Chapter 7
Monitoring the Internet Streamer CDS
Viewing Statistics
Viewing SRP Statistics
To view the SRP statistics of the Proximity Engine, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon next to the Service Router. The Devices home page is displayed.
Step 3
Choose Statistics > SRP. The SRP Statistics are displayed.
Table 7-34 describes the SRP statistics for sent, received, and neighbors.
Table 7-34
SRP Statistics
Statistic
Description
Join request
Total number of requests packets sent for joining the DHT
network.
Join response
Total number of response packets received for joining the
DNT network.
LS exchange request
Total number of leafset exchange request packets sent.
LS exchange response
Total number of leafset exchange response packets received.
Route exchange request
Total number of route exchange request packets sent.
Route exchange response
Total number of route exchange response packets received.
Ping request
Total number of DHT ping request packets sent.
Ping response
Total number of DHT ping response packets received.
Lookup request
Total number of lookup request packets sent.
Lookup response
Total number of lookup response packets received.
Ping traceroute request
Total number of ping traceroute request packets sent.
Ping traceroute response
Total number of ping traceroute request packets received.
Request Retry
Total number of request retry packets.
Pkt at wrong interface
Total number of packets received at wrong interface.
Malform packet
Total number of malform packets received.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-49
Chapter 7
Monitoring the Internet Streamer CDS
Log Files
Log Files
Log files can generally be categorized into three main classes:
1.
Transaction logs
2.
Error and debug logs
3.
General system logs and core files
Transaction Logs
Transaction logs are stored under the /local/local1/logs/ directory. They are disabled by default; to enable
transaction logging either enter the transaction-logs enable command or check the Transaction Log
Enable check box on the Transaction Log Settings page. See the “Configuring Transaction Logs”
section on page 4-31 for more information.
Transaction log archiving is configured by using the transaction-logs archive command or by entering
the settings on the Transaction Log Settings page.
To allow the SR Service Monitor module to collect threshold information enter the service-router
service-monitor transaction-log enable command or check the Enable check box for each setting on
the Service Monitor page. See the “Setting Service Monitor Thresholds” section on page 4-85 for more
information. To configure the Service Monitor thresholds, use the Service Monitor page.
For more information about transaction logs, see the “Transaction Logs” section.
Error and Debug Logs
Error and debug logs are stored under the /local/local1/errorlog/ directory. By default, all software
modules only log error related information. Debug logging levels can be controlled (on a per software
module basis) through the debug command.
There is a background cron job that periodically (every hour) monitors and trims the overall size of
SYSFS (including the errorlog/ directory).
General System Logs and Core Files
General system logs primarily consist of /local/local1/syslog.txt. In addition, any core files generated
are stored to the /local/local1/core_dir/ directory. The same background cron job used for the error and
debug logs also monitors and trims the growth of syslog.txt and core_dir/ directory. If the overall space
usage of SYSFS exceeds 80 percent, this cron job raises an alarm indicating that.
When the overall SYSFS space usage exceeds 90 percent, this cron job starts freeing up space by
removing the oldest files first. The algorithm used basically removes files based on their age. Initially,
all files that are older than 30 days are removed (from the core_dir/, errorlog/, and logs/ directories). If
this does not free up enough space (that is less than 90 percent of capacity), then all files having an age
of 10 days are removed.
Transaction Logs
Transaction logs allow administrators to view the traffic that has passed through the SE. Typical fields
in the transaction log are the date and time when a request was made, the URL that was requested,
whether it was a cache hit or a cache miss, the type of request, the number of bytes transferred, and the
source IP address. For more information about configuring transaction log settings for SEs, see the
“Configuring Transaction Logs” section on page 4-31.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-50
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
This section discusses the following topics:
Note
•
Transaction Log Formats for Web Engine
•
Transaction Logging and NTLM Authentication
•
Usage Guidelines for Log Files
•
Windows Media Transaction Logging
•
Movie Streamer Transaction Log Fields
•
Flash Media Streaming Transaction Log Fields
•
Service Router Transaction Log Fields
•
Service Monitor Transaction Logs
•
Content Manager Transaction Log FieldsWeb Engine User Level Session Transaction Logs
Each transaction log includes a header line that provides the Cisco Internet Streamer CDS software
version and a summary line as the last line in the transaction log, which includes a summary of all the
requests that appear in the transaction log.
Transaction Log Formats for Web Engine
The transaction logs for Web Engine consist of the following:
•
Client Transaction Logs
•
Ingest Transaction Logs
Client Transaction Logs
The section discusses the following different logging formats for Web Engine:
•
Extended Squid
•
Apache
•
Custom Format
Note
Changing the time zone on an SE does not affect the log entry nor the log filename. Both the log entries
and the log filename always use UTC.
Note
The timestamp for Web Engine transaction log entry has no space between the date and the time. An
example follows:
[19/Oct/2010:11:20:09.133-0705] 4821 172.22.71.155 TCP_MISS/404 235 GET
http://172.22.71.155/hello application/octet-stream
Extended Squid
The Extended Squid format logs the same fields logged by the Squid-1.1 access log file format. The
Extended Squid transaction logs are located in the logs/webengine_extsquid/ directory.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-51
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
For details on the Squid-1.1 native log file format, see the Squid documentation “Frequently Asked
Questions,” “Squid Log” section, access.log heading at:
http://wiki.squid-cache.org/SquidFaq/FaqIndex
The Extended Squid-style log file format is as follows:
Current-Time Time-to-Serve Client-IP Request-Desc/Status-Returned Bytes-Xferred Method URL
MIME-Type
An Extended Squid-style log format example looks like this:
[21/May/2009:00:29:12 +0530] 952195 171.71.50.197 TCP_REFRESH_MISS/200 11120239 GET
http://7.9.0.3/1mbs_ai/1mbs1-100.wmv video/x-ms-wmv
Table 7-35 describes the fields for the Extended-Squid transaction log.
Table 7-35
Extended-Squid Transaction Log Fields
Field
Description
Current-Time
Time (milliseconds), in common log time format, the request was
received.
Time-to-Serve
Time, in microseconds, taken to complete the request.
This field could be zero if the transaction complete time is greater
than the transaction start time, which could occur if NTP is not
synchronized.
Client-IP
IP address of the requesting client.
Request-Desc/Status-Returned
Combination of Squid result codes and the response code returned
to the client.
The Request-Desc/Status-Returned field includes the error status
code for both TCP_MISS and TCP_HIT. A TCP_HIT with an
error status code means the HTTP response was served from
cache. The meaning of a TCP_MISS with an error status code has
not changed.
For more information on troubleshooting a TCP_MISS/504 status
code, see the “Troubleshooting Web Engine Cache Status Codes”
section on page A-7.
Bytes-Xferred
Bytes sent to the client, including the headers.
Method
Request method.
URL
Requested URL, including the query string.
MIME-Type
MIME type.
Table 7-36 describes the Squid codes currently supported. The TCP_ codes refer to the cache status of
the object when the request was handled by the Web Engine. In addition to the cache statistics listed in
Table 7-36, the client or server error statistics could get incremented as well depending on the response
code.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-52
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-36
Squid Code Request Descriptions
Valid Response
(Status) Code
Squid Result Code
Description
TCP_MISS
Requested object was not in
cache.
0–5xx
Cache miss
Cache bypass
Partial hit
TCP_MEM_HIT
Valid copy of the requested
object was in memory.
Currently
supports only
2xx response
code
Cache hit and memory hit
TCP_HIT
Valid copy of the requested
object was in cache.
0, 2xx, 3xx, 406, Cache hit
412, 416, 500
TCP_REFRESH_
MISS
Requested object was cached
0–-5xx
but is stale. The query returned
the new content.
TCP_REFRESH_
HIT
Requested object was cached,
but expired. The query for the
object resulted in a “304 not
modified” message.
0, 2xx, 406, 412, Cache hit
416, 500
TCP_IMS_HIT
Client issued an IMS request
for an object, which was in
cache and was not stale.
0, 2xx, 3xx, 500
Cache hit
TCP_DENIED
Access was denied for this
request.
403
—
000
—
NONE
See Request
NONE_ABORTED Description—None and
None_Aborted, for the
description.
Mapping to Cache Statistics
(show statistics web-engine
detail)
Cache miss
Request Description—None and None_Aborted
Normally, when a transaction completes, if the cache status is unknown (before the content lookup
completes, the cache status is unknown), and the request was not denied by the Authorization Server, the
request description that is written to the transaction log is “NONE.”
If a transaction completes because the client aborted the connection, “_ABORTED” is appended to
“NONE.”
If a transaction completes because the of an internal Web Engine failure, and there are no more
transactions waiting for the process within the session, then the transaction was not aborted; therefore,
the “_ABORTED” is not appended to “NONE.”
Under the conditions described above, because this occurs before the Origin Server is contacted and
there is no Authorization Server failure or redirect, the response status code that is written to the
transaction log is 000.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-53
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Apache
The Apache format is the Common Log File (CLF) format defined by the World Wide Web Consortium
(W3C) working group. This format is compatible with many industry-standard log tools. The
Apache-style transaction log files are located in the /webengine_apache/ directory.
The Apache-style log file format is as follows:
client-IP-address URI bytes-sent object-size bytes-received method status time-received time-to-serve
An Apache-style log file format example looks like this:
171.71.50.197 http://spcdn-se612-5.sanity.spcdn.net/gmedia-0.4gb.wmv 363704065 137
363710748 GET 200 [06/Nov/2007:00:25:32 +0530] 325033158
Table 7-37 describes the fields for the Apache-style transaction log.
Table 7-37
Apache-Style Transaction Log Fields
Field
Description
client-IP-address
IP address of the requesting client
URI
Requested URL, including the query string.
bytes-sent
Bytes sent to client, including the headers.
object-size
Bytes sent to client, excluding the HTTP headers.
bytes-received
Bytes received from client.
method
Request method.
status
HTTP response code for the request.
time-received
Time, in common log time format, the request was received.
time-to-serve
Time, in microseconds, taken to complete the request.
Custom Format
The transaction-logs format custom command allows you to use a log format string to log additional
fields that are not included in the predefined Extended Squid format or Apache CLF format. The log
format string is a string that can contain the tokens listed in Table 7-38 and that mimics the Apache log
format string.
The log format string can contain literal characters that are copied into the log file. Double backslashes
(\\) can be used to represent a literal backslash, and a backslash followed by a single quote (\’) can be
used to represent a literal single quote. A literal double quote cannot be represented as part of the log
format string. The control characters \t and \n can be used to represent a tab and a new line character,
respectively. The custom transaction logs are located in the /webengine_clf/ directory.
The following command can be entered to generate the well-known Apache Combined Log Format:
transaction-logs format custom "%t%r %>s %b"
The following transaction log entry example is configured by using the preceding custom format string:
[11/Jan/2003:02:12:44 -0800] "GET http://www.cisco.com/swa/i/site_tour_link.gif HTTP/1.1" 200
3436
Apache and Squid can be represented by the following custom log format patterns:
Apache-style logging with custom patterns: %a %U %O %b %I %m %>s %t %D
Squid-style logging with custom patterns:- %Z %D %a %R/%>s %O %m %U %M
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-54
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-38
Custom Log Format String Values
Format Token
Value
%a
IP address of the requesting client.
%A
IP address of the SE.
%b
Bytes sent, excluding HTTP headers.
%B
Bit rate in bits per second (bps).
%c
Time, in common log time format, that the log entry was generated.
%C
Records AuthLOOKupTime | CALLOOKuptime | CacheRouterTime |
OSDownloadTime in microseconds granularity.
CacheRouterTime displays only on revalidation scenario. In normal cache-miss
use case, the CALLOOKuptime| includes the time taken by cache route lookup
as well.
%D
Time consumed to serve the request in microseconds
%E
Encryption type (none, AES256CTR, AES256CBC) for session tracking.
%g
Storage URL when URL Resolve rule action is configured in Service Rule file.
%G
Source URL when URL Resolve rule action is configured in Service Rule file.
%h
Remote host (IP address of the requesting client is logged).
%H
Request protocol.
%i
Session ID for session tracking.
%I
Bytes received from the client.
%k
Method of session tracking (cookie, URL query)
%m
Request method.
%M
MIME type of the requested asset.
%O
Bytes sent to client, including the headers.
%p
Client that set up the transport session for the request. The value is one of the
following:
•
Local—Request is from this SE.
•
Internal—Request is from other SE
•
External—Request is from end user
%q
Query string (which is preceded by a question mark (?) if a query string exists;
otherwise, it is an empty string).
%r
First line of the request. The space in the first line of the request is replaced with
a vertical bar (|) delimiter (for example, Get|/index.html|HTTP/1.1)
%R
Request description (Squid description codes).
%s
Reserved for future use.
%>s
Status. The translog code always returns the HTTP response code for the request.
%S
Session status for session tracking.
%t
Time in common log time format (or standard English format).
%P
Profile string retrieved from URL
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-55
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-38
Custom Log Format String Values (continued)
Format Token
Value
%T
Time consumed to serve the request in seconds (a floating point number with 3
decimal places).
%u
URL path requested, including query strings.
%U
URL path requested, not including query strings.
%V
Value of the host request header field reported if the host appeared in the request.
If the host did not appear in the host request header, the IP address of the server
specified in the URL is reported.
%y
Session protocol for session tracking.
%X
Connection status when the response is completed. The %X field has the
following possible values:
•
X—Connection aborted before the response completed.
•
+ —Connection may be kept alive after the response is sent.
•
- —Connection is closed after the response is sent.
%Z
Print the request received time stamp in milliseconds; otherwise, the request
received time stamp is in seconds.
%{Header-Field}i
Any request header. Replace the Header-Field with the actual header field you
want to log; for example, %{Cache-Control}i.
Note
All client request headers are only logged on the edge SE.
Content Flow Trace
Content Flow Trace is used to track the flow of HTTP messages through the CDS and the HTTP response
from the Origin Server.
To accomplish this, custom HTTP headers are used for both the requests and the responses. Every tier
adds information to the HTTP headers before sending it to the next SE. The custom headers added by
the SEs are stripped by the Content Acquirer before the request is sent to the Origin Server. Similarly,
the custom headers are stripped from the response before sending it to the client, unless the Enable
Filter Trace Flow to Client option is enabled.
Note
The Content Flow Trace is used for debugging potential issues in the CDS and should not be used during
high traffic loads.
Content Flow Trace tracks latency in Authorization lookup, CAL lookup, content route lookup, and
Origin Server latency. It also keeps track of cache status and response codes.
Custom log format needs to be used to track the request and response headers. The custom log format
string to add to the request and response information is the following:
transaction-logs format custom "%{CDS-CLIENT-INFO}i %{CDS-RESPONSE-INFO}o"
Both the client information and the response information are printed on the same line.They are discussed
separately here for clarification.
•
Request Header Format
The CDS-CLIENT-INFO is captured on the edge SE and forwarded to all other SEs. The following
fields are included in the request header:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-56
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
– Client ip:Client port#
– Date_Time#
– User_Agent#
Following are examples of the CDS-CLIENT-INFO request headers:
192.0.2.95:17836#[03/Jun/2011:11:48:36.871+0000]#Wget/1.10.2#
192.0.2.95:21164#[03/Jun/2011:11:52:29.012+0000]#Wget/1.10.2#
192.0.2.95:28789#[03/Jun/2011:11:59:00.901+0000]#Wget/1.10.2#
•
Response Header Format
The CDS-RESPONSE-INFO is added on every SE. If the request is sent to the Origin Server, the
Origin Server IP address and Origin Server response code are added. The following fields are
included in the response header:
– <Hostname>#
– <ResponseCode>#
– <Cache_Status>#
– AT:<AuthLookupTime>#
– CLT:<CalLookupTime>#
– CRT:<ContentRouteTime>#
– OsLatency:<OSLatency>|
Following are examples of the CDS-RESPONSE-INFO response headers:
– Cache-miss on two tiers. The first line is the Origin Server information, the second line is the
Content Acquirer information, and the third line is the edge SE information.
192.168.1.12#200|
SE1-2#200#Cache_Miss#AT:855#CLT:453#CRT:0#OSLatency:2104||
SE2-3#200#Cache_Miss#AT:906#CLT:464#CRT:0#OSLatency:14486|
– Cache hit
SE1-3#200#Cache_Hit#AT:987#CLT:901#CRT:0#OSLatency:0|
– Cache hit with revalidation. he first line is the Origin Server information, the second line is the
Content Acquirer information, and the third line is the edge SE information.
192.168.1.12#304|
SE1-2#304#Cache_Status_Unknown#AT:243#CLT:673#CRT:0#OSLatency:0||
SE2-3#200#Cache_Hit#AT:278#CLT:651#CRT:0#OSLatency:2198|
Ingest Transaction Logs
Ingest transaction logs are used to log details of every upstream request sent by the Web Engine to the
upstream SEs and origin servers. Ingest transaction logs only stores request details of cache-miss content
and cache-hit content with a revalidation request; details of prefetched content are not stored in the ingest
transaction logs.
To enable the Web Engine ingest transaction logs, enter the web-engine http-ingest-logging enable
command.
The Web Engine ingest transaction logs are located in the /local/local1/logs/webengine_ingestlog_clf
directory.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-57
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
The ingest log file format is as follows:
Time URL FailOverSvrList ServerIP BytesRead BytesToRead AssetSize %DownloadComplete
DownloadTime(Seconds) ReadCallBack Status-Returned MIME-Type Revalidation-Request
CDSDomain ConnectionInfo(LocalPort|ConnectTime|Retry|Reuse) IngestStatus
Time URL FailOverSvrList ServerIP BytesRead BytesToRead AssetSize %DownloadComplete
Status-Returned MIME-Type Revalidation-Request
Time URL FailOverSvrList ServerIP BytesRead BytesToRead AssetSize %DownloadComplete
DownloadTime(Seconds) ReadCallBack Status-Returned MIME-Type Revalidation-Request
CDSDomain ConnectionInfo(LocalPort|Protocol|ConnectTime|Retry|Reuse) IngestStatus
RedirectedUrl FailoverAction
An ingest log file example for a cache-miss looks like this:
[11/Feb/2011:17:55:51+0000] http://4.0.1.6/sam.html 4.0.1.6/ 4.0.1.6 45 45 45 100 200
text/html; charset=utf-8 No
An ingest log file example for a cache-hit with a revalidation request looks like this:
[11/Feb/2011:17:59:15+0000] http://4.0.1.6/sam.html 4.0.1.6/ 4.0.1.6 0 0 0 0 304 Yes[If_None_Match: "1d58ac1-2d-230b4c40"]
An ingest log file example if one Origin Server fails looks like this:
[20/Feb/2013:13:03:28.-238+0000] - - 0 0 0 0 -1 0 0 - No - - - - FAILOVER_TO[3.4.5.6]
An ingest log file example if all Origin Servers fails looks like this:
[20/Feb/2013:13:03:28.-238+0000] - - 0 0 0 0 -1 0 0 - No - - - - NOTIFY_ALL_OS_FAIL
Table 7-39 describes the fields for the ingest transaction log.
Table 7-39
Ingest Transaction Log Fields
Field
Description
Time
Time the request was sent by the Web Engine to the upstream SE or origin
server.
Note
The time value for each piece of log is not expected to be strictly
incremental
URL
Requested URL, including the query string, sent by the Web Engine.
FailOverSvrList
Hierarchical route look-up information to the upstream SE or origin
server. When a cache route look-up is performed for the request, the list
of upstream SEs and origin server contacted to fetch the content is
included in the log entry.
ServerIP
IP address of the SE or origin server from which the content is
downloaded. This is obtained from the FailOverSvrList.
BytesRead
Number of bytes downloaded from the upstream SE or origin server.
BytesToRead
Total number of bytes to be downloaded from the upstream SE or origin
server.
AssetSize
Size of the asset (in bytes) requested.
%DownloadComplete
Percentage of asset that has been downloaded to the requesting SE.
DownloadTime(Seconds)
Time, in seconds, to download the incoming stream.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-58
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-39
Ingest Transaction Log Fields (continued)
Field
Description
ReadCallBack
Number of read callbacks received to read the response body.
Status-Returned
HTTP status code returned from the upstream SE or origin server.
MIME-Type
MIME type (spaces removed).
Revalidation-Request
Either “Yes” if the request is a revalidation request for a cache hit, or “No”
if the request is a cache-miss. If “Yes,” the Header-Name:HeaderValue
follows. The “If-None-Match” or “If-Not-Modified” headers and their
values are included in the log entry. Spaces are removed.
If the Revalidation header is an etag, the space between the header and
colon (If-none-match: "etag ") is removed. If the revalidation header is a
date header, the space is replaced by an underscore (_) for readability.
CDSDomain
Internal header added by Web Engine when contacting another SE in the
CDS hierarchy. The header value represents the request domain of the end
client request.
ConnectionInfo(LocalPort| Connection information. This field has the following values:
ConnectTime|Retry|Reuse)
• LocalPort—Local port used by the SE to talk to upstream
•
ConnectTime—Time at which the connection was established
•
Retry—Number of retries on the connection
•
Reuse—Number of times the same connection was reused
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-59
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-39
Ingest Transaction Log Fields (continued)
Field
Description
IngestStatus
Displays the ingest status. This field has the following value:
•
CONNECT_TIMEOUT
•
CONNECT_CB_SOCK_ERR
•
CONNECT_SOCK_ERR
•
CONNECT_TO_SELF
•
WRITE_READY_TIMEOUT
•
WRITE_SOCK_ERR
•
READ_TIMEOUT_HEADER
•
READ_TIMEOUT_BODY
•
READ_RCVD_ON_WRITE
•
READ_SOCK_ERR_HEADER
•
READ_SOCK_ERR_BODY
•
HEADER_INVALID_CONT_LEN
•
HEADER_PARSE_EXCEPTION
•
HEADER_PARSE_ERR
•
NO_NEED_TO_GET_BODY
•
NO_MORE_DATA_TO_READ
•
HEAD_RESPONSE
•
SUCCESS_FINISH
•
INVALID_STATE
RedirectedUrl
If a 302 response code is received, the RedirectedUrl displays the new
URL. If a 200 response code is received, the RedirectedUrl displays no
data (–).
FailoverAction
Origin Server failover action. The field has the following values:
•
FAILOVER_TO[FQDN of next OS in OS list]
•
NOTIFY_ALL_OS_FAIL
Transaction Logging and NTLM Authentication
If your device is configured for NT LAN Manager (NTLM) authentication and uses the Apache-style or
Extended Squid-style format, you can record the Windows domain name and username in the
“authenticated username” field of the transaction log. If the domain name is available, both the domain
name and the username are recorded in the “authenticated username” field, in the form
domain\username. If only the username is available, only the username is recorded in the “authenticated
username” field. If neither a domain name nor a username is available, a “-” (hyphen) is recorded in the
field.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-60
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Usage Guidelines for Log Files
This section provides some guidelines for working with log files, and includes the following topics:
Note
•
Working Logs
•
Archive Working Log
•
Exporting Log Files
The time stamp in the filename is always in UTC, but the time stamp for the log entries in the transaction
logs are determined by the protocol engine.
Working Logs
Transaction logs are located in the /local/loca1/logs directory. Each component has one or more
directories, depending on its configuration.
There is a working log file in each directory, which is a symbol link, linking to the current working log
file.
The log files are logged to a working log on the local disk as follows:
Note
•
WMT logs are logged to a working log on the local disk in /local1/logs/export/working.log
•
Movie Streamer logs are logged to a working log on the local disk in
/local1/logs/movie-streamer/working.log
•
Flash Media Streaming logs are logged to a working log on the local disk in
/local1/logs/fms_access/working.log and /local1/logs/fms_authorization/working.log
•
Service Router logs are logged to a working log on the local disk in the
/local1/logs/service_router/working.log
•
Web Engine client transaction logs are located in the /local1/logs/webengine_apache, the
/local1/logs/webengine_clf, and the /local1/logs/webengine_extsquid directories
•
Web Engine ingest transaction logs are located in the /local/local1/logs/webengine_ingestlog_clf
directory
•
Service Router transaction logs are located in the /local1/logs/service_router directory
•
Service Monitor transaction logs are located in the /local1/logs/service_monitor directory
•
Content Manager transaction logs are located in the /local1/logs/content_mgr directory
•
Per Session logs are located in the /local1/logs/webengine_abr directory
For Movie Streamer, client requests that join the multicast group do not appear in the transaction log
because multicast clients do not contact the server.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-61
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Archive Working Log
You can specify the interval at which the working log should be cleared, when the interval occurs the
data is moved to an archive log. The archive log files are located on the local disk in the /local1/logs/
directory.
The archiving of working logs can be configured to occur at a specified time interval and when the
working log file reaches a specified size. If one of the criteria is met and at least one new message has
been written to the working log, a log rotation occurs. If one of the criteria is met and no new messages
have been written to the working log, a log rotation does not occur. You can specify the maximum
number of old logs kept on disk.
Because multiple archive files are saved, the filename includes the timestamp when the file was created.
The time stamp in the filename is always in UTC, but the time stamp for the log entries in the transaction
logs are determined by the protocol engine. Because the files can be exported to an FTP/SFTP server,
the filename also contains the IP address of the SE.
The archive filenames use this format:
modulename_IPADDRESS_YYYYMMDD_HHMMSS_file-generation-number.
For example, fms_access_10.74.61.130_20070913_080051_065624_00001 is the filename for the
archive of the fms_access log.
Note
The IP address used in the archived filename is not necessarily the primary interface of the SE. The
transaction log function decides on which IP address to use in creating the archive name.
Exporting Log Files
To facilitate the post-processing of cache log files, you can export transaction logs to an external host.
This feature allows log files to be automatically exported by FTP to an external host at configurable
intervals. The username and password used for FTP are configurable, as is the directory to which the log
files are uploaded.
The log files automatically have a filename that uses the
<type>_<ipaddr>_yyyymmdd_hhmmss_<file_generation_number> format, where:
•
<type> represents the type of log file, with selog for cache logs such as HTTP, HTTPS, and FTP,
and mms_export for Windows Media Technologies (WMT) logs.
•
<ipaddr> represents the SE IP address.
•
yyyymmdd_hhmmss represents the date and time when the log was archived for export.
•
<file_generation_number> represents the File Generation Number, which has a range from 00001
to 99999.
Exporting Transaction Logs to External FTP Servers
To export transaction logs to an FTP server, you must first enable exporting of transaction logs and then
configure the FTP or secure FTP (SFTP) server parameters. This feature can support up to four FTP
servers. The following information is required for each target FTP server:
•
Server IP address or the hostname
The SE translates the hostname with a DNS lookup and then stores the IP address in the
configuration.
•
FTP user login and user password
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-62
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
•
Path of the directory where transferred files are written
Use a fully qualified path or a relative path for the user login. The user must have write permission
to the directory.
You can also compress archived log files into gzip format before exporting them to external FTP servers.
The compressed filename has a .gz extension. This compression feature uses less disk space than that
required for noncompressed archived files on both the SE and the FTP export server and also requires
less bandwidth during export because of the smaller size of the files to be exported.
For more information about exporting and archiving transaction logs, see the “Configuring Transaction
Logs” section on page 4-31 for SEs, and the “Configuring Transaction Logs for the Service Router”
section on page 4-129 for SRs.
To immediately have the transaction logs archived and exported following the next transaction, use the
following commands:
SE# transaction-log force archive
SE# transaction-log force export
The transaction-log force archive command causes the transaction log to be archived to the SE hard
disk following the next transaction. The transaction-log force export command causes the transaction
log to be exported to the configured FTP server. The transaction-log force commands do not change the
configured or default schedule for an archive or export of the transaction logs. The archive or export
interval is restarted after the forced operation. If a scheduled archive or export job is in progress when
the transaction-log force command is entered, the command has no effect.
Restarting Export After Receiving a Permanent Error from the External FTP Server
When an FTP server returns a permanent error to the SE, the export is retried at 10-minute intervals or
sooner if the configured export interval is sooner. If the error is a result of a misconfiguration, the archive
transaction logs are no longer exported to that server. You must re-enter the SE transaction log export
parameters for the misconfigured server to clear the error condition.
A permanent error (Permanent Negative Completion Reply, RFC 959) occurs when the FTP command
to the server cannot be accepted, and the action does not take place. Permanent errors can be caused by
invalid user logins, invalid user passwords, and attempts to access directories with insufficient
permissions or directories that do not exist.
Exporting Transaction Logs to External SFTP Servers
You can also export transaction logs to a Secure File Transfer Protocol (SFTP) server. You must first
enable the feature and configure the SFTP server parameters. The following information is required for
each target SFTP server:
•
SFTP server IP address or the hostname
The SE translates the hostname with a DNS lookup and then stores the IP address in the
configuration.
•
SFTP user login and user password
•
Path of the directory where transferred files are written
Use a fully qualified path or a relative path for the user login. The user must have write permission
to the directory.
To enable this feature, enter the sshd allow-non-admin-users command on the SE. If this feature is
enabled, the output of the show running-config EXEC command shows that this feature is enabled on
the SE.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-63
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Windows Media Transaction Logging
The transaction logs for Windows Media Streaming consist of the following:
•
Windows Media Client Transaction Logs
•
Windows Media Ingest Transaction Log
Windows Media Client Transaction Logs
The following logging formats are supported for Windows Media transaction logging:
•
Standard Windows Media Services Version 4.1
•
Extended Windows Media Services Version 4.1
•
Standard Windows Media Services Version 9.0
•
Extended Windows Media Services Version 9.0
The extended versions of the logging formats contain additional fields that are SE specific (For example,
the SE-action field specifies a cache hit or miss, and the SE-bytes field specifies the number of bytes that
were sent from the SE.)
The SE’s transaction logging format for Windows Media Streaming is consistent with that of the
Windows Media Services and the World Wide Web Consortium (W3C)-compliant log format. A log line
is written for every stream accessed by the client. The location of the log is not configurable. These logs
can be exported using FTP. When transaction logging is enabled, daemons create a separate working.log
file in /local1/logs/export for WMT transactions.
All client information in the transaction logs is sent to the origin server by default.
Note
Transaction logs are generated by the client or the downstream SE and sent to the upstream SE, unless
there is a disconnect before the log is sent. The upstream SE can generate the transaction log based on
the client information sent at the beginning of the session and information gathered by the SE. In this
way, a Windows Media Streaming transaction log always exists for every client session.
Note
All WMT playable contents can be delivered by either HTTP or RTSP, based on the request. Any content
that is cached by the WMT is stored using the RTSP scheme, regardless of whether the content was
cached due to an HTTP or RTSP request. Therefore, in the show command, the content displays as RTSP.
Log Formats Accepted by Windows Media Services 9
Windows Media Players connect to a Windows Media server using the following protocols:
•
Windows Media Players earlier than Version 9.0 use HTTP/1.0 or the MMS protocol.
•
Windows Media Player Version 9.0 uses HTTP/1.1 and RTSP.
Depending on the version of the Windows Media Player, logs are sent in different formats, such as text,
binary, or Extensible Markup Language (XML). Table 7-40 describes the log formats accepted by
Windows Media Services Version 9.0.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-64
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-40
Windows Media Services Version 9.0 Log Formats
Protocol
Player and Distributor
HTTP/1.0
Windows Media Player earlier than Version 9.0
MMS
Windows Media Player earlier than Version 9.0
Binary structure log
HTTP/1.1
Windows Media Player Version 9.0
XML structure log
Log Type
World Wide Web Consortium
(W3C) standard space-delimited
SE (caching and proxy server) is running Windows
text log
Media Services Version 9.0 and streaming from a
Windows Media server that is running Windows
Media Services Version 4.1
Distribution server is running Windows Media
Services Version 9.0
SE (caching and proxy server) is running Windows
Media Services Version 9.0
RTSP
Windows Media Player Version 9.0
XML structure log
Distribution server is running Windows Media
Services Version 9.0
SE (caching and proxy server) is running Windows
Media Services Version 9.0
Note
Extensible Markup Language (XML) logging for MMS-over-HTTP and MMS-over-RTSP (RTSP over
Windows Media Services Version 9.0) is supported. The posted XML log file from the Windows Media
Player to the SE (Windows Media server) can be parsed and saved to the normal Windows Media
transaction logs that are stored on the SE.
Windows Media Streaming Transaction Log Fields
Note
When a client closes a connection, a Logplaystats message is sent. When Fast Cache is enabled, the
client communicates by sending a sendevent. which means there is a sendevent every time the client
pauses and plays the content. When Fast Cache is enabled and a client closes the connection there are
two transaction log entries, sendevent and Logplaystats.
Note
Changing the time zone on an SE does not affect the log entry nor the log filename. Both the log entries
and the log filename always use UTC.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-65
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41 describes the fields for the Windows Media Streaming transaction log.
Table 7-41
Windows Media Streaming Transaction Log Fields
Client Data
Reported
Field
Description
Sample Value
c-ip
The source Internet Protocol (IP) address of the connected socket.
This may be the IP address of a proxy server or firewall.
157.56.219.146
Unicast
Multicast
date
Date, in international date format, when a client is connected.
2001-04-19
Unicast
Multicast
time
Time when the client is connected. The time format is either in
15:30:30
Coordinated Universal Time (UTC) or local time, depending on how
the logging plug-in is configured.
Unicast
Multicast
c-dns
This field is always blank.
Unicast
Multicast
cs-uri-stem
The path (requested URL without the schema, host, port number,
/test/sample.wmv
and question mark) to the content that was requested. See cs-url for or
the full URL.
/broadcast
Note
—
Unicast
Multicast
This represents a change from Windows Media Services
version 4.1, in which this field contained the full URL.
c-starttime
Timestamp (in seconds, no fractions) indicating the point in the
39
stream when the client started to render content. For live broadcasts,
this field is set to 0.
Unicast
Multicast
x-duration
The x-duration field has the value based on the following:
Unicast
Multicast
c-rate
•
If the client does not report a value, indicated by a hyphen (-),
the server value is used.
•
If the value is reported as zero, then the server duration value is
used.
•
If the server compares the x-duration reported by the client with
the filelength and the difference is more than two minutes, then
the server's duration value is used.
The rate at which data is sent from the server to the client. The c-rate 1
field has the following possible values:
•
0.5—Half of the real-time rate
•
1—Real-time rate
•
2—Twice as fast as real-time rate
•
5—Fast forward
•
–5—Fast rewind
If you are using Fast Streaming, these values could be considerably
higher or lower depending on the content and the available
bandwidth.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-66
31
Unicast
Multicast
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41
Windows Media Streaming Transaction Log Fields (continued)
Field
Description
Sample Value
c-status
Codes that describe the client status. The c-status field has the
following possible codes:
200
•
200—Connection was successful
•
210—Client reconnected (after first disconnecting)
•
400—Requested URL was invalid
•
401—Client was denied access
•
404—Requested content was not found
•
408—Client failed to submit a log because the client
disconnected
•
420—Client was disconnected and attempted to reconnect but
failed. If the client attempts to reconnect, a new session is
started. This code reflects the client’s statistics when the client
was originally disconnected. For each log entry with this code,
there should be a 408 code that has the same session ID.
•
500—Windows Media server encountered an internal error and
stopped streaming
Client Data
Reported
Unicast
Multicast
c-playerid
{c579d042-cecc-1 Unicast
Globally unique identifier (GUID) of the client. For player log
1d1-bb31-00a0c9 Multicast
entries, if the player is configured to not send unique player
603954}
identification information to content providers, the value is:
{3300AD50-2C39-46c0-AE0A-xxxxxxxxxxxx}, where x is the
session ID of the client. For distribution server log entries, this value
is always a series of zeroes.
c-playerversion
For player log entries, this field represents the version number of the 6.2.5.415
player. For distribution server log entries, this field represents the
version number of the distribution server.
Unicast
Multicast
c-playerlanguage
Language and country or region code of the player.
en-US
Unicast
Multicast
cs(User-Agent)
Browser type used if the player was embedded in a browser. If the
player was not embedded, this field refers to the user agent of the
client that generated the log. The user-agent value is enclosed in
double quotes (“ “).
Mozilla/4.0_(com Unicast
patible;_MSIE_4.
01;_Windows_98)
cs(Referer)
URL to the web page in which the player was embedded (if it was
embedded). If this is unknown, the field is blank.
http://www.examp Unicast
le.microsoft.com
c-hostexe
For player log entries, this is the host program (.exe) that was started
(for example, a web page in a browser, a Microsoft Visual Basic
applet, or a stand-alone player). For distribution server log entries,
this is the name of the distribution server’s service program (.exe)
that was started.
iexplore.exe
vb.exe
mplayer2.exe
WMServer.exe
Unicast
Multicast
c-hostexever
Host program (.exe) version number.
4.70.1215
Unicast
Multicast
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-67
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41
Windows Media Streaming Transaction Log Fields (continued)
Client Data
Reported
Field
Description
Sample Value
c-os
Client operating system.
Windows_NT
Unicast
Multicast
c-osversion
Version number of the client operating system.
4.0.0.1381
Unicast
Multicast
c-cpu
Client CPU type.
Pentium
Unicast
Multicast
filelength
Length of the digital media file (in seconds). This value is zero for
a stream delivered from a broadcast publishing point.
60
Unicast
filesize
Size of the digital media file (in bytes). This value is zero for a
stream delivered from a broadcast publishing point.
86000
Unicast
avgbandwidth
Average bandwidth (in bits per second) used by the client when
connected to the server. The value is calculated across the entire
duration of the connection.
24300
Unicast
Multicast
protocol
MMST
Actual protocol used to access the content (may differ from the
protocol requested by the client). A value of “Cache” indicates that
a client played the content from its disk-based cache. A value of
“asfm” indicates that the content was delivered using multicast
transmission.
Unicast
Multicast
transport
Transport protocol used to stream the content. Multicast content is
always streamed using UDP.
Unicast
Multicast
UDP
TCP
audiocodec
Microsoft_Audio_ Unicast
For player log entries, this is the audio codecs used to encode the
Multicast
audio streams the client accessed. If multiple codecs were used, the Codec
values are delimited by a semicolon. This field contains a hyphen (-)
in distribution server log entries.
videocodec
Microsoft_MPEG Unicast
For player log entries, this is the video codecs used to encode the
video streams the client accessed. If multiple codecs were used, the -4_Video_Codec_ Multicast
values are delimited by a semicolon. This field contains a hyphen (-) V2
in distribution server log entries.
channelURL
URL to the multicast information file. This field contains a hyphen http://www.examp Unicast
(-) in a client receiving content as a unicast stream unless the unicast le.microsoft.com/ Multicast
stream is a result of a unicast rollover from a multicast stream.
channel.nsc
sc-bytes
Total number of bytes the server sent to the client. The value does 30000
not include any overhead that is added by the network stack.
However, protocols such as MMS, RTSP, and HTTP may introduce
some overhead. Therefore, the same content streamed by using
different protocols may result in different values.
This field contains a hyphen (-) in propagated cache or proxy logs
and in multicast log files.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-68
Unicast
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41
Windows Media Streaming Transaction Log Fields (continued)
Field
Description
c-bytes
Number of bytes received by the client from the server. The value 28583
does not include any overhead that is added by the network stack.
However, protocols such as MMS, RTSP, and HTTP may introduce
some overhead. Therefore, the same content streamed by using
different protocols may result in different values. If the c-bytes and
sc-bytes fields are not identical, packet loss occurred.
Note
Sample Value
Client Data
Reported
Unicast
Multicast
It may seem that if the sc-bytes and the c-bytes field are not
identical that it indicates packet loss. However, if the
c-status field contains “408,” the c-bytes and sc-bytes are
not identical, which does not indicate packet loss.
s-pkts-sent
Number of content packets sent by the server to a connected client. 55
The value does not include TCP or UDP packets. This field contains
a hyphen (-) in propagated cache or proxy logs and in multicast log
files.
Unicast
c-pkts-received
50
Number of packets from the server (s-pkts-sent) that are received
correctly by the client on the first try. Packets that are not received
correctly on the first try can be recovered if they are resent through
UDP. Packets that are not recovered through UDP resend are
considered lost in the network. You can recover these packets if
error correction is enabled. The value does not include TCP or UDP
packets.
Unicast
Multicast
c-pkts-lost-client
Packets lost that were not recovered at the client layer through error 5
correction or at the network layer through UDP resends during
transmission from server to client. These packets are sent by the
Windows Media server but never played by the client. The value
does not include TCP or UDP packets.
Unicast
Multicast
c-pkts-lost-net
Number of packets lost on the network layer. You can still recover
these packets if error correction is enabled. The value does not
include TCP or UDP packets.
2
Unicast
Multicast
c-pkts-lost-cont-net
Maximum number of continuously lost packets on the network layer 2
during transmission from server to client. If the value is high, the
network conditions were bad with long periods of time during which
the client received no packets. The value does not include TCP or
UDP packets.
Unicast
Multicast
c-resendreqs
Number of client requests to receive new packets. This field
contains a zero unless the client is using UDP resend.
5
Unicast
Multicast
c-pkts-recovered-ECC
Packets lost in the network (c-pkts-lost-net) that were repaired and 3
recovered at the client layer because error correction was enabled.
Error correction is the only means of packet recovery for multicast
streams. Packets repaired and recovered at the client layer are equal
to the difference between the c-pkts-lost-net and c-pkts-lost-client
fields. The value does not include TCP or UDP packets.
Unicast
Multicast
c-pkts-recovered-resent Number of packets recovered because they were resent through
UDP. The value does not include TCP or UDP packets. This field
contains a zero unless the client is using UDP resend.
5
Unicast
Multicast
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-69
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41
Windows Media Streaming Transaction Log Fields (continued)
Client Data
Reported
Field
Description
Sample Value
c-buffercount
Number of times the client buffered while playing the stream.
4
Unicast
Multicast
c-totalbuffertime
Time (in seconds) the client used to buffer the stream. If the client
buffers more than once before a log entry is generated,
c-totalbuffertime is the total amount of time the client spent
buffering.
6
Unicast
Multicast
c-quality
The lowest amount of stream quality reported by the player during
the playback of the stream.
96
Unicast
Multicast
s-ip
IP address of the server that received the log file. For multicast log 224.24.41.189
files, this value is the IP address of the web server on which
Wmsiislog.dll is installed.
Unicast
Multicast
s-dns
Domain Name System (DNS) name of the server that received the
log file. This field contains a hyphen (-) in multicast log files.
media.server.com
pany.com
Unicast
s-totalclients
Number of clients connected to the server (but not necessarily
streaming) at the time the event was logged. This field contains a
hyphen (-) in propagated cache or proxy logs and in multicast log
files.
20
Unicast
s-cpu-util
Average load on the server processor (0 to 100 percent). If multiple 40
processors exist, this value is the average for all processors. This
field contains a hyphen (-) in propagated cache or proxy logs and in
multicast log files.
Unicast
cs-username
The user name the client provided during authentication. This field JSmith
contains a value only if authorization and authentication plug-ins
are enabled. If an anonymous authentication method is used, this
field contains a hyphen (-).
Unicast
Note
s-sessionid
Windows Media Services Version 9.0 (standard and
extended) field.
A session identifier the server uses to track a stream session. This is 123456
important for tracking multiple log entries to the same session. Note
that if Windows Media Player version 6.4 received content over
HTTP, the s-sessionid value changes for each log entry, even if the
entries are for the same session.
Note
s-contentpath
Windows Media Services Version 9.0 (standard and
extended) field.
The actual content that streamed. A plug-in may resolve a requested file://C:\WMPub\ Unicast
path to another path. If the client was redirected, this field represents WMRoot\Encoder
the location to which the client was redirected.
_ad.wmv
Note
Windows Media Services Version 9.0 (standard and
extended) field.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-70
Unicast
or
http://www.examp
le.microsoft.com/
speech.wma
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41
Windows Media Streaming Transaction Log Fields (continued)
Sample Value
Client Data
Reported
Field
Description
cs-url
In general, the cs-url has the SE name in the URL, but in the case of mms://microsoft.co Unicast
IPFWD or DNS-based routing, the redirection URL without the SE m/mycontent.wmv Multicast
name is included. Basically, the cs-url has the full URL requested
asfm://206.73.118.2
by the client.
54:26502
For multicast clients, this value is the multicast IP address and port.
For Windows
However, Windows Media Player 9 Series and the Windows Media
Media Player 9
Player 9 Series ActiveX control multicast clients submit the
Series clients:
multicast IP address and port, followed by the IP address of the
network interface from which the server broadcasts the multicast. asfm://multicast IP
address:port/Server
Note
Windows Media Services Version 9.0 (standard and
IP address
extended) field.
cs-media-name
If the client was receiving content from a playlist, this is the media /ads/MyAd2.asf
element the client was receiving. The value is derived from the
mediaName attribute of the playlist media element. If the
mediaName attribute is not present, the value in this field is derived
from the file name value. This field is blank if the client was not
receiving content from a playlist.
Unicast
Alternatively, this entry can be specified in the announcement file to
classify logs according to user or content.
Note
c-max-bandwidth
The maximum bandwidth rate (in bits per second) of the client. This 384000
value can be used to determine whether clients have the capacity for
higher bandwidth content. The value recorded for this field can have
the following types of values:
•
Valid number of bps reported from the client, such as 38400.
•
Undetermined amount, logged as 0.
•
Very large amount that cannot be accurately measured but is
greater than 1000000 and less than 1000000000 bps, logged as
a hyphen (-).
•
Hyphen (-), when a file is being played from the local cache and
no bandwidth is used.
Note
cs-media-role
Windows Media Services Version 9.0 (standard and
extended) field.
Windows Media Services Version 9.0 (standard and
extended) field.
A user-defined value that identifies the role of a media element in a Ad
playlist. Typically, this field is used to enable advertisement
logging. If the media element does not have a role attribute, or if the
client was not receiving content from a playlist, this field is blank.
Alternatively, this entry can be specified in the announcement file to
classify logs according to user or content.
Note
Unicast
Multicast
Unicast
Windows Media Services Version 9.0 (standard and
extended) field.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-71
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-41
Windows Media Streaming Transaction Log Fields (continued)
Field
Description
s-proxied
1
Indicates whether the client connected through a cache or proxy
server. A value of 0 indicates no cache or proxy server was involved.
A value of 1 indicates a cache or proxy server was involved.
Note
SE-action
Sample Value
SE-bytes
•
CACHE_MISS—Request is served by SE as cache-miss or
partial cache-hit
•
CACHE_HIT—Request is served by SE as cache-hit, which
means all of bytes are served from SE local cache.
•
VOD—Request is served by SE as prefetched-hit.
•
live_create—Request is served by SE as live content
Username
Unicast
Extended Windows Media Services (Version 4.1 and
Version 9.0) field.
The user name the client provided during authentication from SE
side of view. This value should be a duplicate of cs-username, the
only difference is cs-username is provided by the client, and this
value is determined by the SE during the SE authentication and
authorization of the client.
Note
Unicast
Extended Windows Media Services (Version 4.1 and
Version 9.0) field.
Bytes sent from the SE local cache. This value is “–” if the SE-action 9600
is CACHE_MISS or live_create.
Note
Unicast
Windows Media Services Version 9.0 (standard and
extended) field.
Indicates the service type from the SE perspective. The value is one VOD
of the following:
Note
Client Data
Reported
JSmith
Unicast
Extended Windows Media Services (Version 4.1 and
Version 9.0) field.
entry-gen-time
Time, in common log time format, that the log entry was generated. [21/Mar/2012:04:
05:45.337+0000]
Note
Extended Windows Media Services Version 9.0 field.
Unicast
mime-type
MIME type.
application/octetstream
Unicast
Note
client-type
Extended Windows Media Services Version 9.0 field.
Client that set up the transport session for the request. The value is External
one of the following:
•
Local—Request is from this SE.
•
Internal—Request is from other SE
•
External—Request is from end user
Note
Extended Windows Media Services Version 9.0 field.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-72
Unicast
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Windows Media Ingest Transaction Log
The Windows Media Ingest transaction log is a new log file that is used to record the details about
dynamically ingested content. The Windows Media Ingest transaction log can be used by the CDNM to
generate statistics on gigabytes used for cache-fill of dynamically ingested content by the Windows
Media Streaming engine.
The Windows Media Ingest transaction log filename has the following format:
wmt_ingestlog_clf_<ipaddr>_yyyymmdd_hhmmss_<>, where
•
<ipaddr> represents the IP address of the SR
•
yyyymmdd_hhmmss represents the date and time when the log was created
The Windows Media Ingest transaction log file is located in the /local/local1/logs/wmt_ingest_clf/
directory on the SE.
Table 7-39 describes the fields for the Windows Media Ingest transaction log.
Table 42
Ingest Transaction Log Fields
Field
Description
Time
Time the request was sent by Windows Media Streaming to the upstream
SE or origin server.
URL
Requested URL, including the query string, sent by Windows Media
Streaming.
FailOverSvrList
Hierarchical route look-up information to the upstream SE or origin
server. When a cache route look-up is performed for the request, the list
of upstream SEs and origin server contacted to fetch the content is
included in the log entry.
ServerIP
IP address of the SE or origin server from which the content is
downloaded. This is obtained from the FailOverSvrList.
BytesRead
Number of bytes downloaded from the upstream SE or origin server.
AssetSize
Size of the asset (in bytes) requested.
DownloadTime(Seconds)
Time, in seconds, to download the incoming stream.
Status-Returned
Status code returned from the upstream SE or origin server.
ConnectionInfo(LocalPort| Connection information. This field has the following values:
ConnectTime|Retry|Reuse)
• LocalPort—Local port used by the SE to talk to upstream
IngestStatus
•
ConnectTime—Time at which the connection was established
•
Retry—Number of retries on the connection
Displays the ingest status. This field has the following value:
•
FAIL
•
SUCCESS
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-73
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Movie Streamer Transaction Log Fields
Note
Changing the time zone on an SE does not affect the log entry nor the log filename. Both the log entries
and the log filename always use UTC.
Table 7-43 describes the fields for the Movie Streamer transaction log.
Table 7-43
Movie Streamer Transaction Log Fields
Field
Description
c-ip
Client IP address.
date
Current log entry creation date.
time
Current log entry creation time.
c-dns
Always returns a dash (-).
cs-uri-stem
Client-requested URL.
c-starttime
The play start time related to session start time in seconds.
x-duration
Current session duration in seconds.
c-rate
Play rate (trick mode). Currently, this field has a fixed value of 1.
c-status
RTSP status code.
c-playerid
Client IP address (used for identification).
c-playerversion
The version of the client media player.
c-playerlanguage
The language of client media player.
cs(User-Agent)
The user-agent description of the client media player.
c-os
The operating system description of the client media player.
c-osversion
The operating system version of the client media player.
c-cpu
This field contains a hyphen (-) at all times.
filelength
Content duration in seconds.
filesize
Content file size in bytes.
avgbandwidth
Content bitrate in bits per second (bps).
protocol
Media data transport protocol (RTP or RTSP).
transport
Media data transport type (UDP or TCP).
audiocodec
Audio codec information.
videocodec
Video codec information.
sc-bytes
Bytes sent from the server to the client.
cs-bytes
Bytes sent from the client to the server.
c-bytes
Bytes received by the client.
s-pkts-sent
Packets sent by the server.
c-pkts-received
Packets received by the client.
c-pkts-lost-client
Client packets lost.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-74
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-43
Movie Streamer Transaction Log Fields (continued)
Field
Description
c-buffercount
Client buffer count. Currently, this field has a fixed value of 1.
c-totalbuffertime
Client buffer delay time in seconds.
c-quality
Client QoS level in current session.
s-ip
Server IP address.
s-dns
Server DNS.
s-totalclients
Current number of clients connecting to server.
s-cpu-util
Current CPU usage. Currently, this field has a fixed value of 0.
cs-uri-query
The query URI sent from the client.
c-username
The username sent from the client
sc(Realm)
The server’s realm.
Flash Media Streaming Transaction Log Fields
The Flash Media Streaming transaction logs consist of the access log. Table 7-44 describes the fields for
the Flash Media Streaming access log.
Note
The data in a field can contain a space. The only supported delimiter is a Tab. This applies to the tz, x-ctx,
x-adaptor, x-vhost, s-uri, c-referrer, c-user-agent, cs-bytes, sc-bytes, and x-sname fields.This applies to
the tz, x-ctx, x-adaptor, x-vhost, s-uri, c-referrer, c-user-agent, cs-bytes, sc-bytes, and x-sname fields.
The following formats apply to the fields in Table 7-44:
Date—YYYY-MM-DD
Time—hh:mm:ss
Time zone—Contains a string such as “UTC,” “Pacific Daylight Time,” or “Pacific Standard Time”
Note
Changing the time zone on an SE does not affect the log entry nor the log filename. Both the log entries
and the log filename always use UTC.
Table 7-44
Flash Media Streaming Access Log Fields
Field
Description
x-event
Type of event. See Table 7-46 for a list of the event types.
x-category
Event category. See Table 7-46 for a list of the event categories.
date
Date of the event.
time
Time the event occurred.
tz
Time zone information.
x-ctx
Event-dependent context information.
s-ip
IP address or addresses of the server.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-75
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-44
Flash Media Streaming Access Log Fields (continued)
Field
Description
x-pid
Server process ID.
x-cpu-load
CPU load.
x-mem-load
Memory usage (as reported by the getServerStats() method).
x-adaptor
Adaptor name.
x-vhost
Virtual host name.
x-app
Application names.
x-appinst
Application instance names.
x-duration
Duration of a stream or session event.
x-status
The status code. The status code is a ten-character string that represents the
severity, category, and message ID.
Note
For information on the event status codes for the access log, see the
“Event Status Codes in Flash Media Streaming Access Logs” section
on page 7-79.
The first three characters represent severity and have the following values:
x-status
•
(w)—Warning
•
(d)—Debug
•
(e)—Error
•
(s)—Trace from server-side script
•
(i)—Information
•
(_)—Unknown
The next three characters represent the category and have the following values:
•
257—TCService
•
265—TCApplication
•
258—TCServer
•
266—TCConnector
•
259—Presence
•
267—Admin
•
260—Storage
•
268—SharedObject
•
261—Stream
•
269—Configuration
•
262—SMTP
•
270—VirtualHost
•
263—Adaptor
•
271—SSL
•
264—JavaScript
The last four characters represent the message ID. The message ID records
information about operation of the Flash Media Server. For more information,
see the Adobe Flash Media Server 3.5 Configuration and Administration
Guide.
c-ip
Client IP address.
c-proto
Connection protocol (RTMP or RTMPT).
c-proto-ver
Connection protocol version.
s-uri
URI of the Flash Media Server application.
cs-uri-stem
The stem portion of the s-uri field.
cs-uri-query
The query portion of the s-uri field.
c-referrer
URI of the referrer.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-76
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-44
Flash Media Streaming Access Log Fields (continued)
Field
Description
c-user-agent
User agent. The user-agent value is enclosed in double quotes (“ “).
c-client-id
Client ID.
cs-bytes
This field shows the number of bytes transferred from the client to the server.
This information can be used to bill customers per session. To calculate the
bandwidth usage per session, subtract the cs-bytes value in the “connect” event
from the cs-bytes value in the “disconnect” event.
sc-bytes
This field shows the number of bytes transferred from the server to the client.
This information can be used to bill customers per session. To calculate the
bandwidth usage per session, subtract the sc-bytes value in the “connect” event
from the sc-bytes value in the “disconnect” event
c-connect-type
Type of connection received by the server:
•
Normal—Connection from a client, such as Flash Player
•
Group—Connection between an edge server and an origin server
•
Virtual—Client connection that goes through an edge server, using the
group connection between the servers for transmission
x-sname
Stream name.
x-sname-query
Query portion of the stream URI specified in play or publish.
x-suri-query
Same as x-sname-query.
x-suri-stem
This is a composite field made up of cs-uri-stem + x-sname + x-file-ext.
x-suri
This is a composite field made up of cs-uri-stem + x-sname + x-file-ext +
x-sname-query.
x-file-name
Full path of the file representing the x-sname stream.
x-file-ext
Stream type (FLV or MP3).
x-file-size
Stream size in bytes.
x-file-length
Stream length in seconds.
x-spos
Stream position.
c-spos
The client stream position when a “client-pause” or “client-seek” event is
logged.
cs-stream-bytes
This field shows the number of bytes transferred from the client to the server
per stream.
To calculate the bandwidth usage per stream, subtract the cs-stream-bytes
value in the “publish” event from the cs-stream-bytes value in the “unpublish”
event.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-77
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-44
Flash Media Streaming Access Log Fields (continued)
Field
Description
sc-stream-bytes
This field shows the number of bytes transferred from the server to the client
per stream. To calculate the bandwidth usage per stream, subtract the
sc-stream-bytes value in the “play” event from the sc-stream-bytes value in the
“stop” event.
The value of sc-stream-bytes can be greater than x-file-size when streaming
files that are not encoded in FLV format, such as MP3 files.
Note
The value of sc-stream-bytes is not necessarily the same as the value
of the QoS ByteCount property.
x-service-name
Name of the service providing the connection (only applicable to certain
connection types).
x-sc-qos-bytes
Number of bytes sent to the client for quality of service.
x-comment
Comments.
x-eid
An event ID received by Authorization plug-in. This event is visible only in the
auth.log file. This field is empty in the access.log file.
x-sid
The ID of a stream. This ID is unique for the client session but not across
sessions.
x-trans-sname
The name of the stream that the server transitions from (the original stream).
x-trans-sname-query
The query stream portion of the stream name for the stream that the server
transitions from.
x-trans-file-ext
The file extension portion of the stream name for the stream that the server
transitions from.
x-trans-mode
The transition mode sent by the client in the NetStream.play2() call.
x-soffset
When a stream is reconnected, the offset value indicates where to resume
streaming.
x-codec-type
Codec type of the frame retrieved in the Authorization plug-in’s E_CODEC
event. This event is visible only in the auth.log file. This field is empty in the
access.log file.
x-codec
Codec value of the “x-codec-type” retrieved in the Authorization plug-in’s
E_CODEC_CHANGE event. This event is visible only in the auth.log file.
This field is empty in the access.log file.
x-plugin
Name of the plug-in. This field is only available in authorization (auth-) events.
x-page-url
The URL of the web page in which the client SWF file is embedded.
x-smax-rec-size
The maximum file size of a recorded stream.
x-smax-rec-duration
The maximum duration of a recorded stream.
x-forwarded-for
A string inserted by an HTTP proxy that usually contains the IP address of the
originating client. This string can contain several IP address or other values.
Flash Media Server copies the string and reports it unchanged.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-78
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Event Status Codes in Flash Media Streaming Access Logs
The event status codes are based on HTTP response codes. Table 7-45 describes the status codes for the
Flash Media Streaming access log.
Table 7-45
Flash Media Streaming Event Status Codes
Field
Status
Code Description
Symbol
connect pending status_continue
100
Waiting for the application to authenticate.
disconnect
status_admin_command
102
Client disconnected due to admin
command.
disconnect
status_shutdown
103
Client disconnected due to server
shutdown (or application unloaded).
connect,
publish,
unpublish, play,
record, record
stop, stop
status_OK
200
Successful.
play, stop
status_transition
210
A transition between streams has occurred.
connect
status_unavailable
302
Application currently unavailable.
connect,
publish, play
status_bad_request
400
Bad request; invalid parameter or client
connected to server using an unknown
protocol.
connect, play,
publish
status_unauthorized
401
Connection rejected by application script
or access denied by application.
connect
status_forbidden
403
Connection rejected by Authorization
plug-in or connection rejected due to
invalid URI.
connect, play
object_not_found
404
Application or stream not found.
play
client_disconnect
408
Stream stopped because client
disconnected.
connect, publish status_conflict
409
Resource limit exceeded or stream is
already being published. Can also mean
that a change has been made by the
Authorization plug-in.
connect
status_lic_limit_exceeded
413
License limit exceeded.
play, publish
unsupported_type
415
Unsupported media type.
disconnect
data_exceeded
416
Message queue too large; disconnect the
client.
connect
chunkstream_error
417
Unable to process unknown data type.
disconnect
cannot_broadcast
418
Client does not have privilege to broadcast.
disconnect
cannot_screenshare
419
License to receive screen sharing video
failed.
disconnect
remote_link_closed
420
Close downstream connection.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-79
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-45
Flash Media Streaming Event Status Codes (continued)
Field
Symbol
Status
Code Description
connect
process_msg_failed
422
Unable to process message received when
client connection was in pending or closed
state.
disconnect
process_msg_exception
423
Error handling message.
disconnect
process_remote_msg_failed
424
Expected response not provided when
command was issued.
disconnect
process_admin_msg_failed
425
Expected response not provided when
issued an admin command.
disconnect
process_rtmp_S2S_msg_failed 426
Expected response not provided when
command was issued.
disconnect
write_error
427
Client is not connected or client
terminated; unable to write data.
disconnect
invalid_session
428
Client connection invalid; closed due to
inactive or idle status.
disconnect
gc_client
429
Unable to obtain ping response or client
states not connected.
disconnect
remote_onstop
430
Upstream connection closed.
disconnect
remote_on_client_disconnect
431
Upstream connection closed because the
last client disconnected.
disconnect
gc_idle_client
432
Flash Media Server autoclose feature
automatically closed the connection.
disconnect
swf_hash_fail
433
SWF verification failure.
disconnect
swf_hash_timeout
434
SWF verification timeout.
disconnect
encoding_mismatch_error
435
Client disconnected due to incompatibility
with object encoding.
disconnect, play server_internal_error
500
Server internal error.
connect
bad_gateway
502
Bad gateway.
connect
service_unavailable
503
Service unavailable; for instance, too many
connections pending for authorization by
access module.
disconnect
js_disconnect
600
Application disconnect.
disconnect
js_close_previous_client
601
Network connection was closed or reused.
disconnect
js_exception
602
An unknown exception is thrown from the
JS engine.
disconnect
js_chunkstream_error
603
Bad application data.
disconnect
js_debug_forbidden
604
Application does not allow debug
connections.
play
js_gc_object
605
~fcstreamjshook() clean up.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-80
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Events in Flash Media Streaming Access Logs
Table 7-46 describes the event types in the Flash Media Streaming access log and the associated category
for each event.
Table 7-46
Flash Media Streaming Access Logs—Events
Event
Category
Description
connect-pending
session
Client connects to the server, waiting for the client to be
authenticated.
connect
session
Client connects to the server.
connect-continue
session
A checkpoint event that provides updates of a corresponding
connect event at intervals. Use the c-client-id field to find the
corresponding connect event.
disconnect
session
Client disconnects.
publish
stream
Client publishes a live stream.
unpublish
stream
Client unpublishes a live stream.
publish-continue
stream
A checkpoint event that provides updates of a corresponding
publish event at intervals. Use the x-sid field (stream id) and the
c-client-id field to find the corresponding publish event.
play
stream
Client plays a stream.
play-continue
stream
A checkpoint event that provides updates of a corresponding
play event at intervals. Use the x-sid field (stream id) with the
c-client-id field to find the corresponding play event.
pause
stream
Client pauses stream.
unpause
stream
Client resumes playing stream.
client-pause
stream
Client smart pauses a stream. The stream is paused but the server
still sends data to the client so the player has enough data to play
when the client unpauses.
client-unpause
stream
Client smart unpauses a stream.
seek
stream
Client seeks in a stream.
stop
stream
Client stops playing or publishing a stream.
record
stream
Client begins recording a stream.
recordstop
stream
Client stops recording a stream.
start-transmit
stream
The server received a “startTransmit” command. This command
asks the server to transmit more data because the buffer is
running low.
stop-transmit
stream
The server received a “stopTransmit” command. This command
asks the server to suspend transmission until the client sends a
“startTransmit” event because there is enough data in the buffer.
server-start
server
Server has started.
server-stop
server
Server has stopped.
vhost-start
vhost
A virtual host has started.
vhost-stop
vhost
A virtual host has stopped.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-81
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-46
Flash Media Streaming Access Logs—Events (continued)
Event
Category
Description
app-start
application
An application instance has started.
app-stop
application
An application instance has stopped.
auth-connect
authorization
Client connects to server. This event occurs if an Authorization
plug-in is present to handle the event.
auth-play
authorization
Client plays a stream. This event occurs if an Authorization
plug-in is present to handle the event.
auth-publish
authorization
Client publishes a live stream. This event occurs if an
Authorization plug-in is present to handle the event.
auth-seek
authorization
Client jumps to a new location within a recorded stream. This
event occurs if an Authorization plug-in is present to handle the
event.
filenametransform authorization
A virtual stream path has been mapped to a physical location.
This event occurs if an Authorization plug-in is present to handle
the event.
auth-record
authorization
Client begins recording a stream. This event occurs if an
Authorization plug-in is present to handle the event.
codechange
authorization
The publisher codec changes during a live event. Logs data to the
x-codec-type and x-codec fields. This event occurs if an
Authorization plug-in is present to handle the event.
Service Router Transaction Log Fields
Note
Changing the time zone on an SE does not affect the log entry nor the log filename. Both the log entries
and the log filename always use UTC.
The Service Router transaction logs are located in the /local1/logs/service_router directory. Table 7-47
describes the fields for the Service Router transaction log.
Table 7-47
Service Router Transaction Log Fields
Field
Description
c-ip
Source Internet Protocol (IP) address of the connected socket. This may be the
IP address of a proxy server or firewall.
user-agent
Browser type used if the player was embedded in a browser. If the player was
not embedded, this field refers to the user agent of the client that generated the
log. The user-agent value is enclosed in double quotes (“ “).
date
Date, in international date format, when a client is connected.
time
Time when the client is connected. The time format is either in Coordinated
Universal Time (UTC) or local time, depending on how the logging plug-in is
configured.
url
URL requested by the client.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-82
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-47
Note
Service Router Transaction Log Fields (continued)
Field
Description
protocol
Protocol used to access the content.
server-picked
Service Engine selected by the Service Router.
routed-path
Path of the redirected URL that is used for last-resort error-domain redirects
and last-resort translator API requests.
status
Status code.
routing-method
Routing method chosen. The routing-method field has the following possible
values:
•
Last-Resort
•
Network
•
Proximity
•
Zero-Network
•
Geo-Location
For cross-domain requests, the crossdomain.xml or clientaccesspolicy.xml file served by the SR is
logged as 200 OK, and the request redirect is logged as a 302. For more information about cross-domain,
see the “Cross-Domain Policy” section on page 1-45.
Service Monitor Transaction Logs
Service Monitor transaction logs provide a tool for analyzing the health history of a device and the
protocol engines, to ensure the device is within the configured capacity limits.
The device and service health information are periodically logged on the device in transaction log files.
Transaction logs provide a useful mechanism to monitor and debug the system. The transaction log fields
include both device and protocol engine information applicable to Service Engines and Service Routers
that are useful for capacity monitoring. Additionally, when a device or protocol engine threshold is
exceeded, detailed information is sent to a file (threshold_exceeded.log) to capture the processes that
triggered the threshold alarm. To configure threshold settings, see the “Setting Service Monitor
Thresholds” section on page 4-85.
The Service Monitor transaction log filename has the following format:
service_monitor_<ipaddr>_yyyymmdd_hhmmss_<>, where:
•
<ipaddr> represents the IP address of the SE, SR, or CDSM.
•
yyyymmdd_hhmmss represents the date and time when the log was created.
For example, service_monitor_192.168.1.52_20110630_230001_00336 is the filename for the log file
on the device with the IP address of 192.168.1.52 and a time stamp of June 30, 2011 at 3:36 AM.
The Service Monitor transaction log file is located in the /local1/logs/service_monitor directory.
An entry to the Service Monitor transaction log is made every two seconds.
Note
The following rules apply to Service Monitor transaction logs:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-83
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
•
A transaction log value is only logged if the Service Monitor is enabled for that component or
protocol engine on the device. For example if CPU monitoring is not enabled, the transaction log
value “–” is displayed.
•
If Service Monitor is enabled for a protocol engine, but the protocol engine is not enabled, the value
is not displayed in the log file.
•
If a log field can have more than one value, the values are delimited by the pipe (|) character.
•
If a value can have sub-values, the sub-values are delimited by the carrot (^) character.
•
Some of the fields display aggregate values. If the statistics are cleared using the clear statistics
command, the value after clearing the statistics may be less than the previous values, or may be zero
(0).
Table 7-48 describes the fields for the Service Monitor transaction log on an SE.
Table 7-48
SE Service Monitor Transaction Log Fields
Field
Sample Output
Description
Corresponding CLI Command
date
2011-06-30
Date of log.
–
time
22:52:02
Time of log.
–
cpu_avg
21
Moving average value in percentage of show service-router service-monitor
CPU usage.
Device status—CPU—Average load
mem_avg
44
Moving average value in percentage of show service-router service-monitor
memory usage.
Device status—Mem—Average used
memory
kernel-mem-avg
11
Moving average value in percentage of show service-router service-monitor
kernel memory.
Device status—KMEM—Average
kernel memory
disk_avg
2
Moving average value in percentage of show service-router service-monitor
disk usage.
Device status—Disk—Average load
disk_fail_count_
threshold
Y
Boolean value to indicate if disk fail
count threshold has been reached.
per_disk_load
disk03-01^2|
disk04-02^5
Current load per disk, as a percentage. –
The sample output indicates that
disk03–partition01 has a 2 percent load
and disk04–partition02 have a 5 percent
load.
bandwidth_avg
Port_Channel_
1^2^4|
Port_Channel_
2^0^0
Moving average bandwidth used, as a show service-router service-monitor
Device status—NIC—Average BW
percentage, of bandwidth in and
In/ Average BW Out
bandwidth out per interface. The
sample output indicates that port
channel 1 has an average bandwidth of
2 percent for receiving and 4 percent for
transmitting, and port channel 2
average bandwidth usage is 0.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-84
show service-router service-monitor
Device status—Device
Status—Disk—Status
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-48
SE Service Monitor Transaction Log Fields (continued)
Field
Sample Output
Description
Corresponding CLI Command
file-desc-count
1023
Total count of file descriptors open on show statistics lsof
the device. File descriptors are internal
data structures maintained by the Linux
kernel for each open file.
tcp_server_connections
35
Number of TCP server connections
open.
show statistics tcp
TCP Statistics—Server connection
openings
tcp_client_connections
24
Number of TCP client connections
open.
show statistics tcp
TCP Statistics—Client connection
openings
processes_count
42
Number of processes running on the
device.
show processes
dataserver-cpupercentage
1
Percentage of the CPU used for the
dataserver process.
–
movie-streamerthreshold-exceeded
–
Boolean value to indicate if the Movie show service-router service-monitor
Streamer threshold has been exceeded. Services status—MS—Threshold
movie-streamer-augment
-threshold-exceeded
–
–
Boolean value to indicate if Movie
Streamer augmentation alarm threshold
has been exceeded.
movie-streamer-stopped
–
Boolean value to indicate if the Movie
Streamer protocol engine has stopped.
show service-router service-monitor
Services status—MS—Stopped
movie-streamer-rtspsessions-count
–
Total Movie Streamer RTSP session
count (aggregate value).
show statistics movie-streamer all
Total RTSP sessions
movie-streamer-rtpsessions-count
–
Total Movie Streamer RTP session
count (aggregate value).
show statistics movie-streamer all
Total RTP connections
fms_threshold_
exceeded
N
Boolean value to indicate if threshold is show service-router service-monitor
exceeded.
Services status—FMS—Threshold
fms-augment-thresholdexceeded
N
Boolean value to indicate if Flash
Media Streaming augmentation alarm
threshold has been exceeded.
–
fms_stopped
N
Boolean value to indicate if Flash
Media Streaming has stopped.
show service-router service-monitor
Services status—FMS—Stopped
fms_connections_count
2
Total Flash Media Streaming
connection count (aggregate value).
show statistics
flash-media-streaming
Connections—Total
web_ engine_
threshold_exceeded
Y
Boolean value to indicate if the Web
Engine threshold has been exceeded.
show service-router service-monitor
Services status—Web—Threshold
web-engine-augmentthreshold-exceeded
Y
Boolean value to indicate if Web
Engine augmentation alarm threshold
has been exceeded.
–
web_ engine_stopped
N
Boolean value to indicate if Web
Engine has stopped.
show service-router service-monitor
Services status—Web—Stopped
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-85
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-48
SE Service Monitor Transaction Log Fields (continued)
Field
Sample Output
Description
web-engine-cpupercentage
3
Percentage of the CPU used by the Web –
Engine.
web_engine_mem
3500
Memory (in bytes) used by the Web
Engine.
show web-engine health
Total memory usage
web_engine_get_
requests
250
Count of get requests received by the
Web Engine (Aggregate value)
show statistics web-engine detail
HTTP Request Type Statistics—Get
requests
web_engine_sessions
5
Count of HTTP connections.
show statistics web-engine detail
Web-Engine Detail Statistics—Total
HTTP Connection + Active Session
web_engine_upstream_
connections
2
Count of HTTP connections to
upstream SE or origin server.
show statistics web-engine detail
Web-Engine Detail Statistics—Total
HTTP Connection
wmt_threshold_
exceeded
N
Boolean value to indicate if Windows
Media Streaming threshold has been
exceeded.
show service-router service-monitor
Services status—WMT—Threshold
wmt-augment-thresholdexceeded
N
–
Boolean value to indicate if the
Windows Media Streaming
augmentation alarm threshold has been
exceeded.
wmt_stopped
Y
Boolean value to indicate if Windows
Media Streaming has stopped.
show service-router service-monitor
Services status—WMT—Stopped
wmt-ml-cpu-percentage
21
Percentage of the CPU used by the
WMT_ML process.
–
wmt-ml-mem
32456
Memory (in bytes) used by WMT_ML
process
–
wmt-core-cpu-percentage 21
Percentage of the CPU used by the
WMT_Core process.
–
wmt-core-mem
32456
Memory (in bytes) used by the
WMT_Core process.
–
wmt-unicast-sessions
22
Number of current concurrent unicast
client sessions.
show statistics wmt usage
Concurrent Unicast Client
Sessions—Current
wmt-remote-sessions
24
Number of current concurrent remote
server sessions.
show statistics wmt usage
Concurrent Remote Server Sessions
wmt_live_requests
21
Total count of Windows Media
Streaming live requests (Aggregate
value).
show statistics wmt requests
By Type of Content—Live content
wmt_vod_requests
22
Total count of Windows Media
Streaming VOD requests (Aggregate
value).
show statistics wmt requests
By Type of Content—On-Demand
Content
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-86
Corresponding CLI Command
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-48
SE Service Monitor Transaction Log Fields (continued)
Field
Sample Output
Description
Corresponding CLI Command
wmt_http_requests
11
Total count of Windows Media
Streaming HTTP requests (Aggregate
value).
show statistics wmt requests
By Transport Protocol—HTTP
wmt_rtsp_requests
8
Total count of Windows Media
Streaming RTSP requests (Aggregate
value).
show statistics wmt requests
By Transport
Protocol—RTSPT/RTSPU
rtspg_tps
12
Current RTSP Gateway transactions per –
second (TPS).
uns-cpu-percentage
3
Percentage of CPU used by the Unified –
Namespace (UNS) process.
uns_mem
3500
Memory used by the UNS process.
–
Table 7-49 describes the fields for the Service Monitor transaction log on a SR.
Table 7-49
SR Service Monitor Transaction Log Fields
Field
Sample Output Description
Corresponding CLI Command
date
2011-06-30
Date of log.
–
time
22:52:02
Time of log.
–
cpu_avg
21
Moving average value in percentage of show service-router service-monitor
CPU usage.
Device status—CPU—Average load
mem_avg
44
Moving average value in percentage of show service-router service-monitor
memory usage.
Device status—Mem—Average used
memory
kernel-mem-avg
11
Moving average value in percentage of show service-router service-monitor
kernel memory.
Device status—KMEM—Average
kernel memory
disk_avg
2
Moving average value in percentage of show service-router service-monitor
disk usage.
Device status—Disk—Average load
disk_fail_count_
threshold
Y
Boolean value to indicate if disk fail
count threshold has been reached.
file-desc-count
1023
Total count of file descriptors open on –
the device. File descriptors are internal
data structures maintained by the Linux
kernel for each open file.
tcp_server_connections
35
Number of TCP server connections
open.
show statistics tcp
TCP Statistics—Server connection
openings
tcp_client_connections
24
Number of TCP client connections
open.
show statistics tcp
TCP Statistics—Client connection
openings
show service-router service-monitor
Device status—Device
Status—Disk—Status
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-87
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-49
SR Service Monitor Transaction Log Fields (continued)
Field
Sample Output Description
Corresponding CLI Command
processes_count
42
Number of processes running on the
device.
show processes
dataserver-cpupercentage
1
Percentage of the CPU used for the
dataserver process.
–
sr-cpu-percentage
12
Cpu percentage used by SR.
–
sr_mem
750000
Memory (in bytes) used by SR.
show processes memory and search
for service_router
requests_received
34
Total count of requests received by SR
(aggregate value)
show statistics service-router
summary
Requests Received
http_normal_requests_
received
5
Total count of normal HTTP requests
received by SR (aggregate value).
show statistics service-router
summary
HTTP Requests (normal)
http_asx_requests_
received
5
Total count of ASX HTTP requests
received by SR (aggregate value).
show statistics service-router
summaryHTTP Requests (ASX)
rtsp_requests_received
5
Total count of RTSP requests received
by SR (aggregate value).
show statistics service-router
summary
RTSP Requests
rtmp_requests_received
5
Total count of RTMP requests received show statistics service-router
by SR (aggregate value).
summary
RTMP Requests
dns_requests_received
6
Total count of DNS requests received
by SR (aggregate value).
show statistics service-router dns
Total DNS queries
Content Manager Transaction Log Fields
The Content Manager transaction log filename has the following format:
content_mgr__<ipaddr>_yyyymmdd_hhmmss_<>, where:
•
<ipaddr> represents the IP address of the SE, SR, or CDSM.
•
yyyymmdd_hhmmss represents the date and time when the log was created.
The Content Manager transaction log file is located in the /local1/logs/content_mgr directory.
Table 7-50 describes the fields for the Service Monitor transaction log on an SE.
Table 7-50
Content Manager Transaction Log Fields
Field
Description
Date
Date of log entry.
Time
Time of log entry.
ContentType
Type of content, which is either cached or prepos-content (prefetched).
Operation
Content Manager operation, which is addition, deletion, update, or eviction.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-88
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-50
Content Manager Transaction Log Fields (continued)
Field
Description
Priority
Prefetched content always has a priority of 0, which means ignore. The lower the
number, the lower the priority.
CreationDate
Date the content object was created.
CreationTime
Time the content object was created.
FileSize
File size, in bytes, of the content object.
HitCount
Number of times the content object was accessed.
URL
URL of the content object. If Content Manager cannot retrieve the URL by using the
FastCAL lookup of the disk path, then the ContentType field has a value of
“unknown-content” and the URL field displays “-.”
Path
Disk path of the content object.
Web Engine User Level Session Transaction Logs
Web Engine User Level Session Transaction Logs consists of two aspects:
1.
Adding optional fields that provides information on User Level Session HTTP transactions to the
custom format transaction logs for the Web Engine.
2.
Enabling the new log file, the Per Session log, which significantly reduces the log message volume
by combining per-transaction logs for each session.
Enabling Per Session Log
To enable Per Session log, the following needs to be configured:
•
Each device needs to have transaction logs and per Session logs enabled
•
Each delivery service must have session tracking enabled
•
Service Rule XML file must have a SessionResolveRule configured
Enabling Per Session Log on a Device
The transaction logs and Per Session Log must be enabled on each SE participating in session logging.
For more information, see the “Configuring Transaction Logs” section on page 4-31.
Enabling Session Tracking for a Delivery Service
To enable session tracking for a delivery service, the following must be enabled:
•
Enable Generic Session Tracking—Enables Generic session tracking at the edge location
•
Enable HSS Session Tracking—Enables HSS session tracking at the edge location
•
Enable HLS Session Tracking—Enables HLS session tracking at the edge location
See the “Location Settings” section on page 5-26. for more information.
Adding a SessionResolveRule to the Service Rule XML File
At least one SessionResolveRule is required to enable the Session log. The Origin server (OFQDN) and
Service Routing Domain Name (RFQDN) must be specified as the pattern lists to match for the
SessionResolveRule. Following is an example of the SessionResolveRule.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-89
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
<Revision>1.0</Revision>
<CustomerName>Demo</CustomerName>
<ApplyAllTier>yes</ApplyAllTier>
<Rule_Patterns>
<PatternListGrp id = "grp1">
<Domain>msi-cds.com</Domain>
</PatternListGrp>
<PatternListGrp id = "grp2">
<Domain>os-msi-cds.com</Domain>
</PatternListGrp>
</Rule_Patterns>
<Rule_Actions>
<Rule_Allow matchGroup="grp1,grp2" protocol="http"/>
<Rule_SetAction name="Rule_DSConfig" matchGroup="grp1,grp2" protocol="http">
<SetParameter name="SessionResolveRule#1" value="(.*)m3u8(.*):none"/>
</Rule_SetAction>
</Rule_Actions>
</CDSRules>
Note
In this Service Rule XML file example, the StreamerSecretKey SetParameter for the Rule_DSconfig
Rule_SetAction is not configured, which results in a warning message. The StreamerSecretKey is used
to generate and validate the session cookie MD5 hash. If the StreamerSecretKey parameter is not
configured, the default is NULL.
Web Engine Custom Formats for ABR and Generic Session HTTP Transactions
Each user level streaming session consists of multiple HTTP transactions. Reflected in the transaction
logs for Web Engine, there are multiple transaction log entries for one streaming session.
The following custom format tokens have been added to the Web Engine custom format to provide
information on User Session HTTP transactions:
•
%i—Session ID
•
%S—Session status
•
%y—Session protocol
•
%E—Encryption type (none, AES256CTR, AES256CBC)
•
%k—Method of session tracking (cookie, URL query)
•
%B—Bitrate in bits per second (bps)
•
%P—Profile string retrieved from URL
Use the transaction-logs format custom command to modify the custom log format.
The custom transaction logs are located in the /local1/logs/webengine_clf/ directory.
Per Session Log
Typically, Session HTTP transaction log volume is very large because of the number of fragments for
each session. The Per Session log reduces log message volume by consolidating per-transaction (per
fragment) log entries for each session. All Session-related HTTP transactions are logged in the Per
HTTP transaction log and session log entries are only generated on session events. The Per Session log
is located in the /local1/logs/webengine_abr directory.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-90
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Session Events
HTTP is a stateless protocol. HTTP User Level session does not have a counterpart of states as does the
traditional streaming protocol such as RTSP. Session events are defined to help understand when and
how session-based transaction log are generated.
Table 7-51 describes the session events for HTTP User level session.
Table 7-51
Session Events
Session Event
Description
Session Start
First request for the session is received.
Session Play
First fragment request is received, or first fragment request after a stop event is
received.
Bitrate Upshift
Bitrate of requested fragment is faster than the previously requested fragment.
Bitrate Downshift Bitrate of requested fragment is slower than the previously requested fragment.
Session Stop
Client has not sent a request for the last ten seconds.
Session Close
There has been no session activity for the duration of the configured session idle
time (SessionIdleTimeout parameter is configured in Service Rule XML file).
The following events generate a transaction log entry:
•
Session Start
•
Session Play
•
Bitrate Upshift
•
Bitrate Downshift
•
Session Stop
•
Session Close
The transaction log format for session logging is as follows:
client-ip abr-protocol session-id manifest-uri asset-id bytes-sent bytes-recvd status time-recvd
time-to-serve bitrate encryption session-tracking-mode status-code user-agent entry-gen-time
mime-type profile
A transaction log file example triggered by Session Start event looks like this:
10.140.8.24 hls 6a8-I-617F442F03277469298A3C17657B56C43529
http://hls.abr.com/sample/sample.m3u8 - 0 0 start [25/Sep/2012:11:11:59.326+0000] 0 0 none
cookie 0 "AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; zh_cn)"
[25/Sep/2012:11:11:59.350+0000] - -
A transaction log file example triggered by Session Play event looks like this:
10.140.8.24 hls 6a8-I-617F442F03277469298A3C17657B56C43529
http://hls.abr.com/sample/sample.m3u8 - 235 436 play [25/Sep/2012:11:11:59.890+0000] 2155
96000 none cookie 200 "AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X;
zh_cn)" [25/Sep/2012:11:11:59.914+0000] video/MP2T H1QVGAH264
A transaction log file example triggered by Session Bitrate shift (Session Profile shifted) event looks like
this:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-91
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
10.140.8.24 hls 6a8-I-617F442F03277469298A3C17657B56C43529
http://hls.abr.com/sample/sample.m3u8 - 7368325 7837 bitrate_shift
[25/Sep/2012:11:11:59.998+0000] 67253471 96000 none cookie 200 "AppleCoreMedia/1.0.0.9B206
(iPad; U; CPU OS 5_1_1 like Mac OS X; zh_cn)" [25/Sep/2012:11:15:32.391+0000] video/MP2T
H2QVGAH264
A transaction log file example triggered by Session Bitrate shift event looks like this:
10.140.8.24 hls 6a8-I-617F442F03277469298A3C17657B56C43529
http://hls.abr.com/sample/sample.m3u8 - 7368325 7837 bitrate_shift
[25/Sep/2012:11:11:59.998+0000] 67253471 126000 none cookie 200
"AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; zh_cn)"
[25/Sep/2012:11:15:32.391+0000] video/MP2T H1QVGAH264
A transaction log file example triggered by Session Stop event looks like this:
10.140.8.24 hls 6a8-I-617F442F03277469298A3C17657B56C43529
http://hls.abr.com/sample/sample.m3u8 - 6279214 6748 success
[25/Sep/2012:11:15:59.895+0000] 56254582 300000 none cookie 200
"AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; zh_cn)"
[25/Sep/2012:11:16:01.825+0000] video/MP2T H1QVGAH264
A transaction log file example triggered by Session Close event looks like this:
10.140.8.24 hls 6a8-I-617F442F03277469298A3C17657B56C43529
http://hls.abr.com/sample/sample.m3u8 - 0 0 close - 0 0 none cookie 200
"AppleCoreMedia/1.0.0.9B206 (iPad; U; CPU OS 5_1_1 like Mac OS X; zh_cn)"
[25/Sep/2012:11:17:01.867+0000] video/MP2T -
Per Session Transaction Log Fields
Table 7-52 describes the Per Session transaction log fields.
Table 7-52
Per Session Transaction Log Fields
Field
Description
client-ip
Client IP address.
abr-protocol
Type of session protocol.
session-id
Unique string generated by server to identify the session.
manifest-uri
URI of manifest file. If it is a failover session and the CDE does not receive
request for master manifest file, this field is the asset URL (URL without asset
filename).
asset-id
Not supported in Release 3.1. This field always returns a dash (-).
bytes-sent
Bytes sent to client. If this is session close log directly following a session
stop, the field is 0 as nothing is sent since last log.
bytes-recvd
Bytes received from client. If the log entry consists of a session stop directly
followed by a session close, the bytes-recvd field is 0.
status
Status of the session.
time-recvd
If this is the first log entry for the transaction, it is the time stamp of when this
session is received; otherwise, it is the time stamp of when the first HTTP
transaction is received since last log message. If this is a session close log
entry directly following a session stop log entry, the field is blank (-) because
no request was received since last log.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-92
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 7-52
Per Session Transaction Log Fields (continued)
Field
Description
time-to-serve
If this is the first log entry for the transaction, it is the time, in microseconds,
taken since this session started; otherwise, it is the time when the first HTTP
transaction is received since the last log message. If this is session stop log
entry directly followed by a session stop, the field is 0.
bitrate
Current stream bitrate in bits per second (bps). A value of zero (0) means “not
applicable” or “not available.” For HSS, the video bitrate is used as the overall
stream bitrate.
encryption
Indicate the session encryption type.
session-tracking-mode Method of tracking the session.
status-code
Status code added for not enough bandwidth (453) and not enough session
(499).
user-agent
Description of client media player. All user-agent values are enclosed in
double quotes (“ “).
entry-gen-time
Time, in common log time format, that the log entry was generated.
mime-type
MIME type.
profile
The profile string retrieved from URL
Snapshot Counter Transaction Logs
The Snapshot Counter transaction logs for the SR and the SE record usage information per delivery
service and can be sent to the CDNM for analytic reporting and billing purposes. For information on
configuring the export of these transaction logs, see the “Real-Time Exporting of Transaction Logs for
Billing and Analytic Reports” section on page 7-95.
Snapshot Counter Transaction Logs on SR for Session and Bandwidth
The SR Snapshot Counter transaction log records the session and bandwidth usage on the SEs in each
delivery service. Each SE sends its own per-delivery service session and bandwidth counters in the
keep-alive messages to the SR. Once the SR receives this information, it aggregates the values across all
the SEs in the delivery service. Every five seconds the SR writes a log entry to the Snapshot Counter
transaction log.
The Snapshot Counter transaction log filename has the following format:
sr_ds_counter_<ipaddr>_yyyymmdd_hhmmss_<>, where
•
<ipaddr> represents the IP address of the SR
•
yyyymmdd_hhmmss represents the date and time when the log was created
The Snapshot Counter transaction log file is located in the /local/local1/logs/ds_snapshot_counter/
directory on the SR.
Table 53 describes the fields for the Snapshot Counter transaction log.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-93
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Table 53
SR Snapshot Counter Transaction Log Fields
Field
Description
time
Time, in common log time format, the per-delivery service counters were
generated on the SE.
se-name
Name of the SE. A value of “–” means the log entry is aggregated for the
delivery service.
ds-id
Delivery service ID with “Channel_” as the prefix string.
active-sessions
Number of active sessions for the delivery service.
allocated-bandwidth
Average allocated bandwidth (in kilo bits per second) for the active sessions.
Snapshot Counter Transaction Logs on SE for Storage Usage
The SE Snapshot Counter transaction log on the SE records the storage usage for prefetched content and
dynamically cached content. Every 30 seconds the SE writes a log entry to the Snapshot Counter
transaction log to record the per-delivery service storage usage.
The snapshot counter transaction log filename has the following format:
se_ds_counter_<ipaddr>_yyyymmdd_hhmmss_<>, where
•
<ipaddr> represents the IP address of the SE
•
yyyymmdd_hhmmss represents the date and time when the log was created
The Snapshot Counter transaction log file is located in the /local/local1/logs/ds_snapshot_counter/
directory on the SE.
Table 54 describes the fields for the Snapshot Counter transaction log.
Table 54
SE Snapshot Counter Transaction Log Fields
Field
Description
time
Time, in common log time format, the per-delivery service counters
were generated on the SE.
se-name
Name of the SE.
ds-id
Delivery service ID with “Channel_” as the prefix string.
storage-quota-usage-prep
Amount of storage used (in bytes) for prefetched content.
storage-quota-usage-dynamic Amount of storage used (in bytes) for dynamically ingested content.
Enabling the Snapshot Counter Transaction Log
The per-delivery service snapshot counter transaction log is disabled by default. To enable the
per-delivery service snapshot counter transaction log function of a device, use the Transaction Logging
page for the SE and the SR. For an SE, choose Devices > Devices > Service Control > Transaction
Logging. For an SR, choose Devices > Devices > General Settings > Notification and Tracking >
Transaction Logging.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-94
Chapter 7
Monitoring the Internet Streamer CDS
Transaction Logs
Real-Time Exporting of Transaction Logs for Billing and Analytic Reports
Transaction logs can be sent real-time from the SE and SR to the CDNM or other export server for use
in analytic reports, summary billing records, and detailed transaction records on a per-delivery service
basis. The SE and SR use the Splunk Universal Forwarder (UF) to push the transaction logs to the Splunk
Lightweight Forwarder (LWF) on the CDNM.
Note
The export server, whether the CDNM, other CDN, or different server; must have the Splunk LWF
running and configured to receive the transaction log files.
These log files can be opened with a text editor, saved to a local hard drive, and used to generate monthly
reports of charges for delivered content for each content provider.
To configure the real-time exporting of the transaction logs, use the Transaction Logging page for the
SE and the SR. For an SE, choose Devices > Devices > Service Control > Transaction Logging. For
an SR, choose Devices > Devices > General Settings > Notification and Tracking > Transaction
Logging.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-95
Chapter 7
Transaction Logs
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
7-96
Monitoring the Internet Streamer CDS
CH A P T E R
8
Maintaining the Internet Streamer CDS
This chapter explains how to perform common administrative tasks including updating system software,
hard disk drive maintenance, and rebooting and deleting devices. The following major topics are
covered:
•
Software Upgrade, page 8-1
•
Rebooting Devices, page 8-9
•
Deleting a Device, page 8-10
•
Replacing a Device, page 8-13
•
Backup and Recovery Procedures, page 8-15
•
Disk Maintenance, page 8-26
For information about database maintenance, see the “Scheduling Database Maintenance” section on
page 4-63.
Software Upgrade
The software upgrade section covers the following topics:
•
Getting a Software File from Cisco.com
•
Finding the Software Version of the Devices
•
Configuring the Software Image Settings
•
Upgrading the Software
•
Software Upgrades by Device
Getting a Software File from Cisco.com
To get a software file from Cisco.com, do the following:
Step 1
Launch your web browser and enter the following URL:
http://www.cisco.com/cisco/software/navigator.html
The Select a Product page is displayed if you have recently logged in; otherwise, the Log In page is
displayed.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-1
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
Step 2
Log in to Cisco.com using your designated username and password. The Video and Content Delivery
page is displayed, listing the available software products.
Step 3
Choose Products > Video and Content Delivery > Content Delivery Systems > Content Delivery
Applications > Cisco Internet Streamer Application. The Downloads page is displayed.
Step 4
Click the software release you want. The page refreshes and the software image files are displayed.
Step 5
Click the link for the software image file you want.
•
If this is the first time you have downloaded a file from Cisco.com, the Cisco Systems Inc.,
Encryption Software Usage Handling and Distribution Policy is displayed. Read the policy, fill in
the unfilled fields, and click Accept.
•
If you previously filled out the Encryption Software Usage and Handling and Distribution form, the
form does not display again.
The Download page is displayed with the information about the software image file and a Download
link.
Step 6
Click Download Now to download the file, or click Add to cart to select more image files before
downloading them. The Download Cart page is displayed.
Step 7
Click Proceed With Download. The Cisco End User Software License Agreement is displayed.
Step 8
Read the agreement and click Agree. The Download Software page is displayed.
Step 9
Choose a download option, either Download Manger Option or Non Java Download Option. A new
window displays the filename of the ISO image file.
Step 10
Click Download. The File Download dialog box is displayed.
Step 11
Click Save. The Save As dialog box is displayed.
Step 12
Navigate to the location where you want to save the file and click Save. The file downloads.
Pre-positioning a Software File
A software file is pre-positioned in the same manner as any other content item. Pre-positioning allows
you to conserve bandwidth usage across the WAN and avoid congesting your network during updates.
The software file is fetched one time from the origin server, replicated across your network, and stored
in Service Engine caches in your LAN.
To pre-position a software file, you must complete the following tasks:
•
Define a delivery service.
•
Assign devices to the delivery service.
•
Define the software file that you want to pre-position by using a Manifest file or the CDSM delivery
service content page.
•
Check the device replication status.
See Chapter 5, “Configuring Services” for more information.
Note
Only Service Engines that are assigned to the delivery service can be updated using pre-positioned
software files. Service Routers and CDSMs do not have pre-positioned content; therefore, you cannot
use the pre-positioned method for device updates for these devices.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-2
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
Sample Manifest File to Pre-position a Software File
You can use the following sample Manifest file to pre-position a software file by replacing the URL with
a valid software file URL:
<CdnManifest>
<item src="http://your-web-server.com/folder/upgrade.bin" />
</CdnManifest>
The server name or IP address of the URL in the Manifest file (and in the Software File URL field in the
Software File Settings page must match either the Origin Server field or the Service Router Domain
Name field in the Content Origin page).
Finding the Software Version of the Devices
The CDSM Home page gives a brief summary of the software versions in use on all the devices in the
CDS network.
To view the software version running on a particular device, choose Devices > Devices. The Devices
Table page displays the software version for each device listed.
Clicking the Edit icon next to the device name in the Devices Table page displays the Devices home
page, which shows the software version for that device.
Note
The software version is not upgraded until a software upgrade has been successfully completed.
If a software upgrade is in progress, the version number displayed is the base version, not the
upgraded version number.
Configuring the Software Image Settings
To upgrade your CDS software release, you must first configure the software image settings.
To configure the software image settings, do the following:
Step 1
Choose System > Software Image Management. The Software Files Table page is displayed.
Step 2
Click the Create New icon in the task bar. The Software Image page is displayed (Figure 8-1).
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-3
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
Figure 8-1
Step 3
Software Image Page
In the Software Image URL field, enter the URL for the .bin software file that you downloaded from
Cisco.com.
a.
Choose a protocol (http or ftp) from the drop-down list.
b.
Enter the URL of the software file; for example, a valid URL might look like this:
http://internal.mysite.com/cds/CDS-2.x.x-K9.bin
In this URL, CDS-2.x.x-K9 is the name of the software upgrade file. (The filename might include
the version number.)
Note
If you are using a pre-positioned software file and you are entering the URL manually (rather
than using the Select File from Delivery Service option), the server name or IP address of
the URL in the Software Image URL field must match either the Origin Server field or the
Service Routing Domain Name field in the Content Origin page of the delivery service. This
is not a requirement if you are downloading the software file directly from the origin server.
(See the “Pre-positioning a Software File” section on page 8-2 for details.)
Alternatively, click Select File from Delivery Service. A separate window displays that allows you to
choose a delivery service, set criteria, search the delivery service, and select the software file that you
want to use for the software upgrade. (You must first pre-position the software file in the delivery service.
See the “Pre-positioning a Software File” section on page 8-2.)
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-4
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
Step 4
If your server requires user login authentication, enter your username in the Username field and enter
your login password in the Password field. Enter the same password in the Confirm Password field.
Step 5
Enter the software version number in the Software Version field. You can copy this number from the
version portion of the software filename in the software file URL.
Specify the version in one of two formats: X.Y.Z-bB or X.Y.Z.b.B, where X = major version, Y = minor
version, Z = maintenance version, b = build letter, and B = build number.
Step 6
If you want the size of the software file considered during validation, enter a file size (in bytes) in the
File Size field. If you leave this field blank, the URL is checked without regard to the software file size.
Step 7
To validate the Software Image URL, Username, and Password fields, click the Validate Software
Image Settings button.
When you click the Validate Software Image Settings button, the following occurs:
•
Software file URL is resolved.
•
Connection to the software file URL is established using the username and password, if specified.
•
If a file size is specified, the actual size of the software file is obtained and compared against the
value in the File Size field.
•
Message is returned, indicating success or errors encountered.
Step 8
In the Advanced Settings section, check the Auto Reload check box to automatically reload a device
when you upgrade the software.
Step 9
If you want, you can choose one of three download methods:
•
Default—Uses pre-positioned content but always falls back to direct download.
•
Prepositioned Only—Uses the local file copy if the software file URL references pre-positioned
content and its replication status is complete.
•
Direct Download Only—Directly downloads the file using the software file URL.
Note
Step 10
If you choose Prepositioned Only, the software file settings that you define in this page
cannot be used to upgrade a CDSM or an SR, because these devices do not have
pre-positioned content.
For downgrades only, specify the CDSM IP address to be used for device registration in the CDSM IP
Address field.
The CDSM IP Address field is the IP address of a CDSM after the software is downgraded. (This field
is optional and only applies for downgrades.) After the downgrade, the SE registers with the CDSM with
the IP address specified in this field.
Step 11
Click Submit.
To delete a software file, click the Delete icon in the task bar.
Caution
If your browser is configured to save the username and password for the CDSM, the browser
auto-populates the Username and Password fields in the Software Image page. You must clear these
fields before you click Submit.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-5
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
The software file that you want to use is now registered with the CDSM. When you perform the software
upgrade or downgrade, the URL that you just registered becomes one of the choices available in the
Update Software page. (See the “Upgrading the Software” section on page 8-6.)
Upgrading the Software
When upgrading software in your CDS network, begin with Service Engines and Service Routers before
upgrading the CDSM. The CDSM reboots at the conclusion of the upgrade procedure, causing you to
temporarily lose contact with the device and the user interface. After the CDSM has upgraded its
software and rebooted, it may be unable to communicate with devices running different versions of the
CDS software.
Caution
Primary and standby CDSMs must be running the same version of CDS software. If they are not, the
standby CDSM detects this and does not process any configuration updates it receives from the primary
CDSM. You need to upgrade your standby CDSM first, and then upgrade your primary CDSM. We also
recommend that you create a database backup for the primary CDSM and copy the database backup file
to a safe place before you upgrade the software.
Caution
To upgrade the software image on a server, you first need to offload a server for maintenance. Once the
server has been fully offloaded, you can upgrade the software. After updating the software, uncheck the
Server Offload check box to allow the server to receive client requests from the Service Router. See the
Server Offload field in Table 4-6 on page 4-11 for more information.
Downgrading the Software
For software downgrades of systems with primary and standby CDSMs, you need to do the following:
1.
If you are using the CDSM GUI, downgrade the standby CDSM first, followed by the primary
CDSM.
If you are using the CLI, downgrade the primary CDSM first, followed by the standby CDSM.
2.
After downgrading the primary and standby CDSMs, using the CLI, log in to each CDSM and run
the following commands:
cms database downgrade
cms enable
3.
Downgrade the software on the Service Routers.
4.
Downgrade the Content Acquirers.
5.
Downgrade the middle-tier Service Engines.
6.
Downgrade the edge Service Engines.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-6
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
Interoperability Considerations
In general, a CDS network is upgraded gradually, so that your network might consist of nodes with
different software versions for the duration of time it takes to upgrade all nodes. Dissimilar software
versions are not supported in the long term, and only the interoperability considerations listed below are
supported until all devices are running the same software version. You can expect the following behavior
during an upgrade or downgrade of your network:
•
CDS 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 CDS network
upgrade is complete, but no existing features are affected.
•
While being upgraded, a node is 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 a delivery service.
•
All logs are preserved during an upgrade or downgrade, unless you change the disk configuration.
Anytime disk space is reconfigured, the logs are automatically removed.
We strongly recommend that you upgrade your CDS network devices in the following order:
1.
Multicast sender Service Engines
2.
Multicast receiver Service Engines
3.
Edge Service Engines
4.
Middle-tier Service Engines
5.
Content Acquirers
Note
Note
When upgrading the Content Acquirers in a delivery service, to avoid having a critical alarm
generated while the Content Acquirer is being upgraded, temporarily set the
System.datafeed.pollRate field to 200 seconds or higher. When the upgrade is complete,
reset the field to the original value. See the “System Properties” section on page 6-8 for more
information.
6.
Service Routers
7.
Standby CDSMs (Upgrade before primary when using the GUI only.)
8.
Primary CDSM
When you upgrade CDSMs using the CLI, we recommend that you upgrade your primary CDSM first,
and then upgrade your standby CDSM. Primary and standby CDSMs must be operating with exactly the
same software release as each other for failover to be successful.
Upgrading Software by Device Groups
Note
This procedure is for Service Engines only. Service Routers and CDSMs cannot be associated with
device groups.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-7
Chapter 8
Maintaining the Internet Streamer CDS
Software Upgrade
To upgrade your software on multiple Service Engines, do the following:
Step 1
Choose Devices > Device Groups. The Device Groups Table page is displayed.
Step 2
Click the Edit icon next to the name of the device group that you want to upgrade. The Device Group
page is displayed.
Step 3
From the left-panel menu, choose Software Update. The Software Update for Device Group page is
displayed.
Step 4
Choose the software file URL from the Software File URL list by clicking the radio button next to the
filename.
Step 5
Click Submit.
To view progress on an upgrade, go to the Devices Table page (Devices > Devices). Software upgrade
status messages are displayed in the Software Version column. These intermediate messages are also
written to the system log on the Service Engines. See Table 8-1 for a description of upgrade status
messages.
Table 8-1
Upgrade Status Messages
Upgrade Status Message
Condition
Pending
The request has yet to be sent from the CDSM to the
device, or receipt of the request has yet to be acknowledged
by the device.
Downloading
The download method for the software file is being
determined.
Proceeding with Pre-positioned
Download
The download method for the software file is detected as
pre-positioned. Proceeding with download of a
pre-positioned software file.
Proceeding with Download
The download method for the software file is detected as
direct download. Proceeding with the request for direct
download of the software file.
Download in Progress (Completed …)
Direct download of the software file is being processed.
“Completed” indicates the number of megabytes
processed.
Download Successful
The direct download of the software file has been
successful.
Download Failed
The direct download of the software file cannot be
processed. Further troubleshooting is required; see the
device system message log.
Proceeding with Flash Write
A request has been made to write the software file to the
device flash memory.
Flash Write in Progress (Completed …)
The write of the device flash memory is being processed.
“Completed” indicates the number of megabytes
processed.
Flash Write Successful
The flash write of the software file has been successful.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-8
Chapter 8
Maintaining the Internet Streamer CDS
Rebooting Devices
Table 8-1
Upgrade Status Messages (continued)
Upgrade Status Message
Condition
Reloading
A request to reload the device has been made to complete
the software upgrade. The device may be offline for several
minutes.
Reload Needed
A request to reload the device has not been made. The
device must be reloaded manually to complete the software
upgrade.
Canceled
The software upgrade request was interrupted, or a
previous software upgrade request was bypassed from the
CLI.
Update Failed
The software upgrade could not be completed.
Troubleshooting is required; see the device system
message log.
Software Upgrades by Device
Use this upgrade procedure for Service Routers and CDSMs. You can also use this upgrade procedure
to upgrade Service Engines one at a time.
To upgrade your software on a single device, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed.
Step 2
Click the Edit icon of the device that you want to upgrade. The Devices home page is displayed.
Step 3
Verify that the device is not already running the version that you plan to upgrade to, and that the current
version has an upgrade path to the version that you plan to upgrade to.
Step 4
Click Update Software. The Software Update page is displayed.
Step 5
Choose the software file URL from the Software Files list by clicking the radio button next to the
filename.
Step 6
Click Submit, and then click OK to confirm your decision.
The Devices Table page is displayed again. You can monitor the progress of your upgrade from this page.
Software upgrade status messages are displayed in the Software Version column. These intermediate
messages are also written to the system log on the Service Engines. See Table 8-1 for a description of
upgrade status messages.
Rebooting Devices
You can reboot a device or device group. The CDSM performs a controlled shutdown of all devices and
then restarts the operating system on each device.
To reboot an individual device, do the following:
Step 1
Choose Devices > Devices.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-9
Chapter 8
Maintaining the Internet Streamer CDS
Deleting a Device
Step 2
Click the Edit icon next to the device name that you want to reboot. The Devices home page is displayed
Step 3
In the task bar, click the Reload icon. You are prompted to confirm your decision.
Step 4
To begin rebooting the device, click OK.
To reboot an entire device group, do the following:
Step 1
Choose Devices > Device Groups.
Step 2
Click the Edit icon next to the name of the device group that you want to reboot. The Device Group page
is displayed.
Step 3
In the task bar, click the Reboot All Devices in Device Group icon. You are prompted to confirm your
decision.
Step 4
To begin rebooting each SE in the device group, click OK.
Deleting a Device
You can delete a device if the device is experiencing unresolvable problems or when its network address
or configuration has changed and you need to add the device back to the CDS network using its new
address and configuration information.
Caution
If you delete the only SR in your CDS network, you are removing the ability of your CDS network to
fill user requests.
When you delete an SE from the CDS network, you are removing that device and the content it contains
from the routing scheme that the CDS uses to fill user requests. Although the CDS routes
requests around SEs that are busy, offline, or missing, removing an SE may affect the speed at which the
CDS network can serve user requests.
Note
You cannot delete an SE if it is the only device assigned to a location that is designated as the root
location (Content Acquirer) for a delivery service and there are other SEs associated with the delivery
service. You can delete the Content Acquirer for a delivery service if the Content Acquirer is the only
SE associated with that delivery service. However, deleting the only SE in a delivery service makes the
delivery service unable to deliver content. If you receive an error message referencing the Content
Acquirer for a delivery service, add more SEs to that location, or change the root location by choosing
an SE in a different location to be the Content Acquirer for the delivery service before attempting to
delete the SE again.
Removing the device from the CDS network involves using the CLI to shut down CDS network services
and deregister the node. If you are removing the device because of hardware failure and it cannot be
accessed through its CLI, you can remove the device by using the CDSM; however, the device continues
to store its registration information until you deregister it by using the CLI.
Before a device can be removed from the CDS network, the following conditions must be met:
•
Device must have been activated in the CDSM.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-10
Chapter 8
Maintaining the Internet Streamer CDS
Deleting a Device
•
CDSM must be operating.
•
Device must have the correct CDSM IP address or hostname configured.
•
CDSM IP address or hostname must be that of the primary CDSM.
•
Device must not be the Content Acquirer for any delivery service.
Deleting a device from the CDS network involves using the CLI to remove the registration information
from the device itself and removing the registration record from the CDSM.
Note
Do not use the CDSM to delete a device while the device is still active and registered. The CDSM delete
feature removes only the device’s registration record from the CDSM; it does not deregister the device.
The device retains its registration information and continues to contact the CDSM; however, the CDSM
no longer recognizes the device.
If for some reason the CDSM loses the registration record of a device, use the cms deregister force
command on the device to remove all its registration information. Then use the cms enable command
to reregister the device with the CDSM as though it were a new node in the CDS network.
To remove and deregister a device, do the following:
Step 1
Open an SSH session to the device CLI.
Step 2
In global configuration mode, enter the no cms enable command.
SE# configure
SE(config)# no cms enable
Note
Step 3
Issuing the no cms enable command does not disable acquisition and distribution services on
the device; however, issuing the cms deregister command does. The cms deregister command
disables the CMS, all acquisition and distribution services, and all routing communications to
and from this device.
In EXEC mode, enter the cms deregister command.
SE(config)# exit
SE# cms deregister
Note
The cms deregister command cleans up the database automatically. You do not need to use the
cms database delete command.
If the deregistration fails, the best practice is to resolve any issues that caused the deregistration
failure; for example, the Service Engine is the Content Acquirer of a delivery service and cannot
be deleted or deactivated. In this case, assign a different SE as the Content Acquirer in each
delivery service where this SE is assigned as the Content Acquirer and try the cms deregister
command again.
Step 4
If for some reason the deregistration fails, you can force the deregistration by using the cms deregister
force command.
SE# cms deregister force
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-11
Chapter 8
Maintaining the Internet Streamer CDS
Deleting a Device
Note
Step 5
Take note of any messages stating that the deregistration failed and make sure to resolve them
before reregistering the device with the same CDSM or registering the device to another CDSM.
The cms deregister force command forces the deregistration to continue.
To add the device back into the CDS network, reregister the device with the CDSM by using the cms
enable command in global configuration mode.
SE# configure
SE(config)# cms enable
In case of a hardware failure, you might need to remove the device from the CDS network routing
scheme by using the CDSM.
Before a device can be removed from the CDS network through the CDSM, the following conditions
must be met:
•
•
•
Device must have been activated in the CDSM.
CDSM must be running.
Device must have the correct CDSM IP address or hostname configured.
•
CDSM IP address or hostname must point to the primary CDSM.
•
Device must not be the Content Acquirer for any delivery service.
To delete a device using the CDSM, do the following:
Step 1
Choose Devices > Devices. The Devices Table page is displayed. The online status of the device is listed
in the Status column.
Step 2
Click the Edit icon next to the device name you want to delete. The Devices home page is displayed.
Step 3
In the task bar, click the Delete Device icon. You are prompted to confirm your decision.
Step 4
To execute your request, click OK. The device is removed from the CDSM.
Step 5
If possible, access the device CLI to deregister the device.
Step 6
In the CLI, enter the cms deregister force command.
Note
Step 7
You must use the cms deregister force command after deleting a device in the CDSM. This is
because once the device has been deleted, the CDSM no longer has a record of the device.
To add the device back in to the CDS network, reregister the device with the CDSM by using the cms
enable command in global configuration mode.
Deleting a Warm Standby CDSM
You can delete a warm standby CDSM from the CDS network at any point after you have registered the
device and before the device has come online as the primary CDSM. Once the device has been called
into use as the primary CDSM, however, you cannot delete it by using the CDSM.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-12
Chapter 8
Maintaining the Internet Streamer CDS
Replacing a Device
Delete a warm standby CDSM when the device is experiencing unresolvable problems or when its
network address or configuration has changed and you need to add the device back to the CDS network
by using its new address and configuration information.
To delete a warm standby CDSM, do the following:
Step 1
Log in directly to the CDSM CLI, and enter the cms deregister command.
If for some reason the deregistration fails, you can force the deregistration by using the cms deregister
force command.
Step 2
From the CDSM GUI, choose Devices > Devices.
The browser refreshes, listing the CDSMs on your CDS network. The warm standby CDSM is identified
as Standby.
Step 3
Click the Edit icon next to the name of the warm standby CDSM. The Devices home page is displayed.
Step 4
From the left-pane menu, choose Device Activation. The Activation page is displayed.
Step 5
In the task bar, click the Delete icon. You are prompted to confirm your decision.
Step 6
To execute your request, click OK.
Replacing a Device
The procedure to replace a device in the CDS is different depending on the type of the device being
replaced. This section covers the following procedures:
•
Replacing a CDSM
•
Replacing an SE or SR
Replacing a CDSM
To replace a CDSM in a CDS you must first add the new CDSM into the network as a standby CDSM.
For procedural information, see the “Configuring Primary and Standby CDSMs” section on page 3-11.
Note
The primary and standby CDSMs must be running the same version of software. You must first add the
new CDSM with the same version as the existing CDSM. Once the standby CDSM has been added, you
must wait at least two polling intervals (10 minutes) for the databases to synchronize before you can
begin the upgrade procedure.
Note
After you have activated the standby CDSM using the primary CDSM web interface and the device
shows as online in the Devices Table page, wait at least two polling intervals (10 minutes) before
changing roles to ensure that the standby CDSM has a record of the most recent configuration changes.
To promote the standby CDSM to primary, first stop the primary CDSM using the cdsm role standby
command. For procedural information, see the “Changing a Standby to a Primary CDSM” section on
page 3-12.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-13
Chapter 8
Maintaining the Internet Streamer CDS
Replacing a Device
After the primary CDSM has been stopped, and the standby CDSM has taken the role of primary, wait
at least two polling intervals (10 minutes) before logging in to the new primary CDSM. The new primary
CDSM is accessible by entering the IP address of the CDSM with port 8443 in a web browser. For
example, if the IP address of your CDSM is 192.168.0.236, enter https://192.168.0.236:8443.
It is now safe to deactivate the old primary CDSM in the CDSM web interface and remove it from the
CDS network.
Note
Do not try to take a back up of the old CDSM database and restore it on the new CDSM. This may lead
to problematic issues.
Replacing an SE or SR
Note
If you replace a Content Acquirer with an SE that was not previously assigned to the delivery service,
all content is reacquired and old content is deleted.
Note
To prevent the reacquisition of content when replacing a Content Acquirer, make one of the receiver SEs
in the same delivery service the replacement Content Acquirer. Add the new SE as a receiver SE, wait
until replication is complete for the newly added SE, and then designate it as the Content Acquirer.
When you replace a Content Acquirer in this manner, the SEs in the delivery service synchronize with
the new Content Acquirer through the metadata poll. Content is not redistributed to the other SEs in the
delivery service unless the content has changed since the last metadata poll.
To replace an SE or SR, do the following:
Step 1
Open an SSH session to the device being replaced.
Step 2
In global configuration mode, enter the no cms enable command to disable CMS on the device that
needs to be replaced.
SE# configure
SE(config)# no cms enable
Step 3
From the CDSM, choose Devices > Devices > Device Activation. The Device Activation page is
displayed.
Step 4
Uncheck the Activate check box and click Submit. The page refreshes and displays a Replaceable
check box.
Step 5
Check the Replaceable check box and click Submit.
Step 6
Choose System > Configuration > System Properties. The System Properties page is displayed.
Step 7
Click the edit icon next to the System.devivce.recovery.key property. The Modify Config Property page
is displayed.
Step 8
In the Value field, enter a key and click Submit. The default value is default.
Step 9
Follow the instructions for configuring a device using the setup utility. The instructions can be found in
Cisco Content Delivery Engine Hardware Installation Guide that is applicable to your device.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-14
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
Note
The replacement device must be the same hardware model as that of the device being replaced.
a.
When prompted by the setup utility, configure the basic network settings.
b.
When prompted by the setup utility for the hostname of the new device, use the same hostname of
the device being replaced. For example, if the old device has a hostname of “SE1,” the new device
must have a hostname of “SE1.”
c.
When prompted by the setup utility for the IP address of the CDSM, enter the IP address of the
CDSM.
Step 10
Open an SSH session to the new device.
Step 11
In EXEC mode, enter the cms recover identity command with the key parameter you set in Step 8.
SE# cms recover identity <key>
On successful registration to the CDSM, a message similar to the following is displayed:
DT-7326-4#cms recover identity sr
Registering this node as Service Router...
Sending identity recovery request with key sr
Node successfully registered with id CrConfig_291
Registration complete.
Step 12
Register the device with the CDSM by using the cms enable command in global configuration mode.
SE# configure
SE(config)# cms enable
Step 13
From the CDSM, choose Devices > Devices > Device Activation. The Device Activation page is
displayed.
Step 14
Check the Activate check box and click Submit.
After a few minutes, approximately two polling intervals, the device status shows online and all
configurations (delivery service assignments, programs, and so on) are the same as those on the device
that was replaced.
Step 15
Once the new device is up and running, as noted by the online status, the old device can be removed from
the CDS network.
Backup and Recovery Procedures
This section provides CDSM database backup and CDS software recovery procedures. This section
contains the following sections:
•
Performing Backup and Restore on the CDSM Database, page 8-16
•
Using the Cisco CDS Software Recovery CD-ROM, page 8-17
•
Recovering the System Software, page 8-18
•
Recovering a Lost Administrator Password, page 8-21
•
Recovering from Missing Disk-Based Software, page 8-22
•
Recovering CDS Network Device Registration Information, page 8-25
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-15
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
Performing Backup and Restore on the CDSM Database
The CDSM stores CDS network-wide device configuration information in its Centralized Management
System (CMS) database. You can manually back up the CMS embedded database contents for greater
system reliability.
To back up the CMS database for the CDSM, use the cms database backup EXEC command.
Note
The naming convention for backup files includes the timestamp.
To back up and restore the CMS database on the CDSM, do the following:
Step 1
Back up the CMS database to a file.
CDE# cms database backup
creating backup file backup-db-11-06-2007-13-10.dump
backup file local1/backup-db-11-06-2007-13-10.dump is ready.
Please use ‘copy’ commands to move the backup file to a remote host.
Step 2
Save the file to a remote server by using the copy disk ftp command. This command copies the file from
the local disk to a remote FTP server, as shown in the following example:
CDE# cd /local1
CDE# copy disk ftp 10.86.32.82 /incoming cds-db-9-22-2002-17-36.dump
cds-db-9-22-2002-17-36.dump
Enter username for remote ftp server:ftp
Enter password for remote ftp server:*******
Initiating FTP upload...
Sending:USER ftp
10.86.32.82 FTP server (Version wu-3.0.1-18) ready.
Password required for ftp.
Sending:PASS *******
User ftp logged in.
Sending:TYPE I
Type set to I.
Sending:PASV
Entering Passive Mode (10,86,32,82,112,221)
Sending:CWD /incoming
CWD command successful.
Sending PASV
Entering Passive Mode (10,86,32,82,203,135)
Sending:STOR cds-db-9-22-2002-17-36.dump
Opening BINARY mode data connection for cds-db-9-22-2002-17-36.dump.
Transfer complete.
Sent 18155 bytes
Step 3
Delete the existing CMS database.
CDE# cms database delete
Step 4
Restore the CMS database contents from the backup file.
CDE# cms database restore cds-db-9-22-2002-17-36
Step 5
Enable CMS.
CDE# cms enable
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-16
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
Using the Cisco CDS Software Recovery CD-ROM
A software recovery CD-ROM image (.iso file) is available for each software release. The recovery
CD-ROM can be used to recover system software that must be completely reimaged. The recovery
CD-ROM image contains the system software for a single software release and a single application
software.
This section presents instructions for creating and using the software recovery CD-ROM to reinstall your
system software if for some reason the software that is installed has failed.
Caution
If you upgraded your software with a later release than the software recovery CD-ROM image file you
downloaded, using the CD-ROM software recovery images may downgrade your system.
System Software Components
Cisco CDS software consists of three basic components:
•
Disk-based software
•
Flash-based software
•
Hardware platform cookie (stored in flash memory)
All these components must be correctly installed for Cisco CDS software to work properly.
The software is contained in two types of software images provided by Cisco:
•
A .bin image containing disk and flash memory components
An installation containing only the CDS flash memory-based software, without the corresponding
disk-based software, boots and operates in a limited mode, allowing for further disk configuration
before completing a full installation.
•
A .sysimg image containing a flash memory component only
The .sysimg component is provided for recovery purposes, and allows for repair of flash memory
only, without modifying the disk contents.
Getting the Cisco CDS Software Recovery File from Cisco.com
To get a software file from Cisco.com, do the following:
Step 1
Launch your web browser and enter the following URL:
http://www.cisco.com/kobayashi/sw-center/sw-video.shtml
The Log In page is displayed.
Step 2
Log in to Cisco.com using your designated username and password. The Video and Content Delivery
page is displayed, listing the available software products.
Step 3
Click Cisco Content Delivery Systems (CDS). The Downloads page is displayed.
Step 4
Click the Cisco Content Delivery Applications folder to expand it, and click the Cisco Internet
Streamer Application. The page refreshes and the software releases are displayed.
Step 5
Click the link for the software recovery file you want to download.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-17
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
•
If this is the first time you have downloaded a file from Cisco.com, the Cisco Systems Inc.,
Encryption Software Usage Handling and Distribution Policy is displayed. Read the policy, fill in
the unfilled fields, and click Accept.
•
If you previously filled out the Encryption Software Usage and Handling and Distribution form, the
form does not display again.
The Download page is displayed with the information about the software image file and a Download
link.
Step 6
Click Download. The Cisco End User Software License Agreement is displayed.
Step 7
Read the agreement and click Agree. The File Download dialog box is displayed.
Step 8
Click Save. The Save As dialog box is displayed.
Step 9
Navigate to the location where you want to save the file and click Save. The file downloads.
Step 10
Burn the software recovery image file onto a CD-ROM.
Installing the Software Using the Recovery CD-ROM
To install the system software by using the recovery CD-ROM, perform the following steps:
Step 1
Plug a USB CD-ROM drive into a USB port on the device.
Step 2
Insert the recovery software CD-ROM into the USB CD-ROM drive, and boot the device.
Step 3
When the installer menu appears, choose 2 Install all Software.
Step 4
Wait for the process to complete.
Step 5
Before you reboot the device, remove the USB CD-ROM drive from the USB port so that the device
boots from flash memory.
Step 6
Reboot the device.
Recovering the System Software
The Service Engine, Service Router, and CDSM have a resident rescue system image that is invoked
should the image in flash memory be corrupted. A corrupted system image can result from a power
failure that occurs while a system image is being written to flash memory. The rescue image can
download a system image to the main memory of the device and write it to flash memory.
Note
The .sysimg file is located under the images folder on the Recovery CD-ROM. If you have upgraded the
CDS software, download the corresponding rescue CD iso image, copy to a CD and use the rescue iso
image.
To install a new system image using the rescue image, do the following:
Step 1
Download the system image file (*.sysimg) to a host that is running an FTP server.
Step 2
Establish a console connection to the device and open a terminal session.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-18
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
Step 3
Reboot the device by toggling the power switch.
The rescue image dialog appears. The following example demonstrates how to interact with the rescue
dialog and use a port channel for the network connection (user input is denoted by entries in bold
typeface). This example is for the CDE220-2G2, which has 10 gigabit Ethernet interfaces. The CDE110
and CDE205 have 2 gigabit Ethernet interfaces and the CDE220-2S3i has 14 gigabit Ethernet interfaces.
This is the rescue image. The purpose of this software is to let
you download and install a new system image onto your system's
boot flash device. This software has been invoked either manually
(if you entered `***' to the bootloader prompt) or has been
invoked by the bootloader if it discovered that your system image
in flash had been corrupted.
To download an image, this software will request the following
information from you:
- which network interface to use
- IP address and netmask for the selected interface
- default gateway IP address
- FTP server IP address
- username/password on FTP server
- path to system image on server
System
1.
2.
3.
Choice
Recovery Menu:
Configure Network
Download and install system image
Exit (and reboot)
[1]: 1
Network Configuration Menu:
1. Configure ethernet interface
2. Configure portchannel interface
3. Exit to main menu
Choice [1]: 2
Please enter an interface from the following list:
0. GigabitEthernet 1/0
1. GigabitEthernet 2/0
2. GigabitEthernet 3/0
3. GigabitEthernet 4/0
4. GigabitEthernet 5/0
5. GigabitEthernet 6/0
6. GigabitEthernet 7/0
7. GigabitEthernet 8/0
8. GigabitEthernet 9/0
9. GigabitEthernet 10/0
10. Done
0
Please select an interface from the list below:
0. GigabitEthernet 1/0 [Use]
1. GigabitEthernet 2/0
2. GigabitEthernet 3/0
3. GigabitEthernet 4/0
4. GigabitEthernet 5/0
5. GigabitEthernet 6/0
6. GigabitEthernet 7/0
7. GigabitEthernet 8/0
8. GigabitEthernet 9/0
9. GigabitEthernet 10/0
10. Done
Choice [1]: 1
Please select an interface from the list below:
0. GigabitEthernet 1/0 [Use]
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-19
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
1. GigabitEthernet
2. GigabitEthernet
3. GigabitEthernet
4. GigabitEthernet
5. GigabitEthernet
6. GigabitEthernet
7. GigabitEthernet
8. GigabitEthernet
9. GigabitEthernet
10. Done
Choice [2]: 10
2/0 [Use]
3/0
4/0
5/0
6/0
7/0
8/0
9/0
10/0
Please enter the local IP address to use for this interface:
[Enter IP Address]: 172.16.22.22
Please enter the netmask for this interface:
[Enter Netmask]: 255.255.255.224
Please enter the IP address for the default gateway:
[Enter Gateway IP Address]: 172.16.22.1
Network Configuration Menu:
1. Configure ethernet interface
2. Configure portchannel interface (done)
3. Exit to main menu
Choice [3]: 3
System
1.
2.
3.
Choice
Recovery Menu:
Configure Network (done)
Download and install system image
Exit (and reboot)
[2]: 2
Please enter the IP address for the FTP server where you wish
to obtain the new system image:
[Enter Server IP Address]: 172.16.10.10
Please enter your username on the FTP server (or 'anonymous'):
[Enter Username on server (e.g. anonymous)]: anonymous
Please enter the password for username 'anonymous' on FTP server (an email address):
Please enter the directory containing the image file on the FTP server:
[Enter Directory on server (e.g. /)]: /
Please enter the file name of the system image file on the FTP server:
[Enter Filename on server]: CDS24.sysimg
Here is the configuration you have entered:
Current config:
IP Address: 172.16.22.22
Netmask: 255.255.255.224
Gateway Address: 172.16.22.1
Server Address: 172.16.10.10
Username: anonymous
Password:
Image directory: /
Image filename: CDS-24.sysimg
Attempting download...
Downloaded 34234368 byte image file
A new system image has been downloaded.
You should write it to flash at this time.
Please enter 'yes' below to indicate that this is what you want to do:
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-20
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
[Enter confirmation ('yes' or 'no')]: yes
Ok, writing new image to flash
..................................................................................Finished
writing image to flash.
Enter 'reboot' to reboot, or 'again' to download and install a new image:
[Enter reboot confirmation ('reboot' or 'again')]: reboot
Restarting system.
Initializing memory. Please wait.
System Recovery Menu:
1. Configure Network (done)
2. Download and install system image (done)
3. Exit (and reboot)
Choice [3]: 3
Restarting system.
Step 4
Log in to the device as username admin. Verify that you are running the correct version by entering the
show version command.
Username: admin
Password:
Console> enable
Console# show version
Content Delivery System Software (CDS)
Copyright (c) 2007 by Cisco Systems, Inc.
Content Delivery System Software Release 3.0.0 (build b460 July 5 2011)
Version: se507-2.4.0
Compiled 02:34:38 July 15 2009 by (cisco)
Compile Time Options: PP SS
System was restarted on Thu July 15 16:03:51 2009.
The system has been up for 4 weeks, 1 day, 6 hours, 7 minutes, 23 seconds.
Recovering a Lost Administrator Password
If an administrator password is forgotten, lost, or misconfigured, you need to reset the password on the
device.
Note
There is no way to restore a lost administrator password. You must reset the password to a new one, as
described in this procedure.
To reset the password, do the following:
Step 1
Establish a console connection to the device and open a terminal session.
Step 2
Reboot the device.
While the device is rebooting, watch for the following prompt and press Enter when you see it:
Cisco CDS boot:hit RETURN to set boot flags:0009
Step 3
When prompted to enter bootflags, enter the 0x800 value.
Available boot flags (enter the sum of the desired flags):
0x0000 - exit this menu and continue booting normally
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-21
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
0x2000 - ignore Carrier Detect on console
0x4000 - bypass nvram config
0x8000 - disable login security
[SE boot - enter bootflags]:0x8000
You have entered boot flags = 0x8000
Boot with these flags? [yes]:yes
[Display output omitted]
Setting the configuration flags to 0x8000 lets you into the system, bypassing all
security. Setting the configuration flags field to 0x4000 lets you bypass the NVRAM
configuration.
Step 4
When the device completes the boot sequence, you are prompted to enter the username to access the CLI.
Enter the default administrator username (admin).
Cisco Service Engine Console
Username: admin
Step 5
When you see the CLI prompt, set the password for the user using the username password command
in global configuration mode.
ServiceEngine# configure
ServiceEngine(config)# username admin password 0 password
You can specify that the password be either clear text or encrypted. Zero (0) means the password is
displayed as a plain word; one (1) means the password is encrypted.The password strength must be a
combination of alphabetic character, at least one number, at least one special character, and at least one
uppercase character.
Note
Step 6
Do not set the user ID (uid).
Save the configuration change by using the write memory command in EXEC mode.
ServiceEngine(config)# exit
ServiceEngine# write memory
Step 7
Optionally, reboot your device by using the reload command.
ServiceEngine# reload
Rebooting is optional; however, you might want to reboot to ensure that the boot flags are reset, and to
ensure that subsequent console administrator logins do not bypass the password check.
Note
In CDS software, the bootflags are reset to 0x0 on every reboot.
Recovering from Missing Disk-Based Software
This section describes the recovery procedures to use if for some reason the software installation on both
system disks is corrupt or missing.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-22
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
There are two types of disk volumes in the CDS: system disk volumes (which contain all of the system
volumes plus the sysfs volume) and cdnfs disk volumes. A disk is either allocated as a system disk or a
cdnfs disk (on some CDEs, a system disk might contain a cdnfs volume). The system volumes, contain
data and applications that are critical to the system’s basic functionality.
The system volumes are stored in a two-disk RAID-1 (mirrored) array. RAID-1 duplicates data between
each of the disks in the array. The two-disk scheme allows for either of the drives in the system volumes
array to fail without sustaining data loss or incurring system errors.
The status of the volumes can be seen through the show disk raid-state command, and can be in any of
the following states:
Note
•
Normal—Both drives are attached, and data is mirrored between them.
•
Syncing—Data is being copied between the drives to restore the volumes to a normal state. This
typically happens when a new drive is added to repair degraded volumes.
•
Degraded—One of the disks has failed. It is highly recommended that a new disk is added to repair
the volumes.
•
Bad—Both disks have failed. The system has likely lost all but basic functionality.
If both system disks fail, a CDS state of “missing disk-based software” occurs.
Normally, when a problem occurs on one system disk, a disk failure or RAID alarm is triggered. If this
occurs, replace the failed disk. See the “Disk Maintenance” section on page 8-26.
The CDS state of “missing disk-based software” is most likely to occur if you replaced both system disks
in your Service Engine, Service Router, or CDSM. By design, the software installation on the system
disks cannot be corrupted by a system failure or a power failure.
If both system disks fail or are missing, the software continues to run. However, it runs in a basic
functionality mode in which HTTP proxy and related HTTP features still work, but most other features
fail.
The compact flash functionality is merged on to the system disk in a non-CDE platform. If both system
disks fail or are missing on a non-CDE platform, the non-CDE device can not function and needs to have
the CDS software reinstalled by using the Recovery CD-ROM. For more information, see the “Using the
Cisco CDS Software Recovery CD-ROM” section on page 8-17.
Caution
This procedure should only be used as a last-resort method to recover the system software on a unit.
Typically, the system automatically repairs itself across a reboot if any new disks are detected.
If the volumes are degraded and a new disk is present at reboot, the new disk is added to the existing
array (sync starts). If the volumes are “bad” and a new disk is present at reboot, the initial system volume
is built on the disk.
To recover from this condition, do the following:
Step 1
Remove the Service Engine record from the CDSM.
a.
Choose Devices > Devices.
b.
Click the Edit icon next to the name of the Service Engine that you want to delete. The Devices
home page is displayed.
c.
Click the Delete icon. You are prompted to confirm your decision.
d.
Click OK to execute your request. The Service Engine is removed from the CDSM.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-23
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
Note
The Service Engine registration record needs to be deleted from the CDSM for the Service
Engine to complete reregistration after it comes back online. The CDSM does not register a
device if the device already appears in the record as registered.
Step 2
Power down the device and replace the failed or missing system disks with new, blank disks.
Step 3
After the new disks are installed, power up the device.
Step 4
From a console or through an SSH session, check the startup messages that appear on your screen.
If there is a problem with the system disk or the disk-based software, a message similar to the following
appears:
Jan 21 21:55:45 (none) ruby_disk:%SE-DISK-2-200024:First disk not in standard
configuration. Run 'disk recover-system-volumes' command and re-install software.
ruby_disk:Your first disk is not in standard configuration.
ruby_disk:Run 'disk recover-system-volumes' from the CLI
********************************************
System software is missing.
Check whether first-disk is bad, or
use 'disk recover-system-volumes' to recover first-disk.
********************************************
Step 5
Log in as admin.
Cisco Service Engine Console
Username: admin
Password:
System Initialization Finished.
SE-507 con now available
Press RETURN to get started!
Step 6
After logging in to a console or SSH session, enter the copy ftp install or copy http install EXEC
command to download and install a new system image.
ServiceEngine# copy ftp install ftp-server remotefiledir remotefilename
For example:
SE# copy ftp install vista /CDS/upgrades CDS-2.0.0.2-K9.bin
Enter username for remote ftp server: biff
Enter password for remote ftp server:
Initiating FTP download...
printing one # per 1MB downloaded
Reclaiming unused safe state sectors...
############################################################################
###########
############################################################################
###########
Installing phase3 bootloader...
Installing system image to flash: done
The new software will run after you reload.
#
ServiceEngine# show flash
CDS software version (disk-based code): CDS-2.0.1-b130
System image on flash:
Version: 2.0.1.2
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-24
Chapter 8
Maintaining the Internet Streamer CDS
Backup and Recovery Procedures
System flash directory:
System image: 98 sectors
Bootloader, rescue image, and other reserved areas: 26 sectors
128 sectors total, 4 sectors free.
Step 7
Reboot the software with the new disk and new system image by entering the reload EXEC command.
SE# reload
Step 8
Register the device with the CDSM by using the cms enable command in global configuration mode.
SE# configure
SE(config)# cms enable
Recovering CDS Network Device Registration Information
Device registration information is stored both on the device itself and on the CDSM. If a device loses its
registration identity or needs to be replaced because of hardware failure, the CDS network administrator
can issue a CLI command to recover the lost information or, in the case of adding a new device, assume
the identity of the failed device.
To recover lost registration information, or to replace a failed node with a new one having the same
registration information, do the following:
Step 1
Mark the failed device as “Inactive” and “Replaceable” in the CDSM.
a.
Choose Devices > Devices.
b.
Click the Edit icon next to the name of the Service Engine you want to deactivate. The Devices home
page is displayed.
c.
From the left-panel menu, choose Device Activation.
d.
Uncheck the Activate check box. The page refreshes, displaying a check box for marking the device
as replaceable.
e.
Check the Replaceable check box and click Submit.
Note
Step 2
This check box only displays when the device is inactive.
Configure a system device recovery key.
a.
Choose System > Configuration.
b.
Click the Edit icon next to the System.device.recovery.key property. The Modifying Config
Property page is displayed.
c.
Enter a password in the Value field and click Submit. The default password is default.
Step 3
Configure the basic network settings for the new device.
Step 4
Open an SSH session to the device CLI and enter the cms recover identity keyword EXEC command,
where keyword is the device recovery key that you configured in the CDSM.
When the CDSM receives the recovery request from the Service Engine, it searches its database for the
Service Engine record that meets the following criteria:
•
Record is inactive and replaceable.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-25
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
•
Record has the same hostname as given in the recovery request.
•
Device is the same hardware model as the device in the existing record.
•
File system allocations for the device are the same as or greater than the device in the
existing record.
If the recovery request matches the Service Engine record, then the CDSM updates the existing record
and sends the requesting Service Engine a registration response. The replaceable state is cleared so that
no other device can assume the same identity. When the Service Engine receives its recovered
registration information, it writes it to file, initializes its database tables, and starts.
Step 5
Note
Return to the CDSM and activate the device.
a.
Choose Devices > Devices.
b.
Click the Edit icon next to the name of the Service Engine you want to activate. The Devices home
page is displayed.
c.
From the left-panel menu, choose Device Activation. The Service Engine status should be Online.
d.
Check the Activate check box and click Submit.
If you are replacing an old device with a different hardware model, check the following hardware-related
settings and adjust them according to your needs, after the new device is online in CDSM GUI:
•
IP Access List settings associated with network interfaces
•
Disk quota settings of VOD-type delivery services
•
Default and maximum bandwidth setting of Windows Media Streaming and Movie Streamer
•
Service Monitor Disk Failure Percent Settings
Disk Maintenance
This section covers the following topics:
•
Disk Error Handling
•
Removing and Replacing Disk Drives
•
Removing Content
Disk Error Handling
When sector I/O errors on a disk exceed the Disk Error Handling Thresholds, the disk is marked bad.
The following tasks are performed when a disk is marked bad:
•
Raise a disk_failure alarm
•
Forcibly unmount the disk
•
Inform the CAL/UNS layer of any CDNFS partitions that are marked bad so that they cannot be used
for streaming (CDNFS partitions only)
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-26
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
•
Intentionally invalidate the Master Boot Record (MBR) of the disk, thereby destroying any cached
content. This eliminates the possibility of reusing potentially corrupt cached content. This
essentially removes the disk from the CDNFS file-system.
The disk must be repaired before it can be reused by the Internet Streamer CDS system software.
For information about disk error handling thresholds, see the “Enabling Disk Error Handling” section
on page 4-64.
The following sections cover detecting disk sector errors and repairing them:
•
Disk Latent Sector Error Handling
•
SMART Sector Errors
•
disk repair Command
Disk Latent Sector Error Handling
Latent Sector Errors (LSEs) are when a particular disk sector cannot be read from or written to, or when
there is an uncorrectable ECC error. Any data previously stored in the sector is lost. There is also a high
probability that sectors in close proximity to the known bad sector have as yet undetected errors, and
therefore are included in the repair process.
The syslog file shows the following disk I/O error message when there are disk sector errors:
Apr 28 21:00:26 U11-CDE220-2 kernel: %SE-SYS-4-900000: end_request: I/O error, dev sdd,
sector 4660
Apr 28 21:00:26 U11-CDE220-2 kernel: %SE-SYS-3-900000: Buffer I/O error on device sdd,
logical block 582
SMART Sector Errors
Typically, the indication that a hard disk drive (HDD) is bad and needs to be replaced is if the show disk
SMART-info detail command output exceeds the values described in Table 8-2. Solid State Drives
(SSDs) do not report pending errored sector attributes in the output for the show disk SMART-info
detail command.
Table 8-2
Output Values of show disk SMART-info detail Command Indicating Disk
Replacement
Field
CDNFS and SYSTEM Drives—Threshold Raw Values
Reallocated_Sector_Ct raw_value
128
Current_Pending_Sector raw_value
30
Offline_Uncorrectable raw_value
30
A drive needs to be replaced if any of the RAW_VALUEs listed in Table 8-2 are exceeded.
The show disk SMART-info command (without the detail keyword), provides information on the
overall health of each HDD or SSD. The following example of the show disk SMART-info command
output shows that disk08 is bad:
# show disk SMART-info
… etc …
=== disk08 ===
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-27
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
smartctl 5.40 2010-10-16 r3189 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family:
Seagate Barracuda ES.2
Device Model:
ST3500320NS
Serial Number:
9QM92HZ0
Firmware Version: SN05
User Capacity:
500,107,862,016 bytes
Device is:
In smartctl database [for details use: -P show]
ATA Version is:
8
ATA Standard is: ATA-8-ACS revision 4
Local Time is:
Tue Jul 19 04:42:16 2011 PDT
==> WARNING: There are known problems with these drives,
see the following Seagate web pages:
http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207931
http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207963
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME
FLAG
VALUE WORST THRESH TYPE
5 Reallocated_Sector_Ct
0x0033
025
025
036
Pre-fail
UPDATED
Always
WHEN_FAILED RAW_VALUE
FAILING_NOW 1548
The show disk SMART-info command is repeated for each drive. If the overall-health assessment of a
drive indicates “FAILED,” then the drive should be replaced. The output of the show disk SMART-info
command also shows the SMART attributes that indicate drive failure (in the above example, the
Reallocated_Sector_Ct attribute indicates FAILING_NOW).
If the show disk SMART-info details command output values for Current_Pending_Sector and
Offline_Uncorrectable for an HDD are below the threshold described in Table 8-2, then monitor these
values over several days. The Latent Sector Error feature attempts to repair such errored sectors in a
background process by deleting (evicting) corrupted content. If after several days of monitoring the
values for Current_Pending_Sector and Offline_Uncorrectable have not decreased, consider running the
disk repair command. After the disk repair command completes, we recommend that you reboot the
SE to ensure all CDS software services are functioning correctly.
If the output values for Current_Pending_Sector and Offline_Uncorrectable for an HDD are above the
threshold described in Table 8-2, then you need to replace the disk.
Note
The disk repair command deletes all cached video content on the drive and takes approximately three
hours to complete per HDD. The disk repair command takes approximately 30 minutes on a solid-state
drive (SSD).
Table 8-3 provides an example of the last part of the output of the show disk SMART-info detail
command. The attributes that need to be reviewed to determine if the drive needs to be replaced or
repaired are highlighted in bold. A drive needs to be replaced if any of the RAW_VALUEs listed in
Table 8-2 are exceeded. In this example, because the Reallocated_Sector_Ct value is greater than 128,
this drive should be replaced.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-28
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
Table 8-3
ID#
RMA Case—Replace HDD Example
ATTRIBUTE_NAME
FLAG
VALUE
WORST THRESH
TYPE
UPDATED RAW_VALUE
1
Raw_Read_Error_Rate
0x000f
072
063
044
Pre-fail
Always
59861501
3
Spin_Up_Time
0x0003
099
099
000
Pre-fail
Always
0
4
Start_Stop_Count
0x0032
100
100
020
Old_age Always
12
5
Reallocated_Sector_Ct
0x0033
099
099
036
Pre-fail
Always
130
7
Seek_Error_Rate
0x000f
072
060
030
Pre-fail
Always
17169006
9
Power_On_Hours
0x0032
090
090
000
Old_age Always
9010
10
Spin_Retry_Count
0x0013
100
100
097
Pre-fail
0
12
Power_Cycle_Count
0x0032
100
037
020
Old_age Always
12
184
Unknown_Attribute
0x0032
100
100
099
Old_age Always
0
187
Reported_Uncorrect
0x0032
093
093
000
Old_age Always
7
188
Unknown_Attribute
0x0032
100
100
000
Old_age Always
0
189
High_Fly_Writes
0x003a
100
100
000
Old_age Always
0
190
Airflow_Temperature_Cel
0x0022
071
069
045
Old_age Always
29 (Lifetime Min/Max
28/29)
194
Temperature_Celsius
0x0022
029
040
000
Old_age Always
29 (0 22 0 0)
195
Hardware_ECC_Recovered
0x001a
052
011
000
Old_age Always
59861501
197
Current_Pending_Sector
0x0012
100
100
000
Old_age Always
1
198
Offline_Uncorrectable
0x0010
100
100
000
Old_age Offline
1
199
UDMA_CRC_Error_Count
0x003e
200
200
000
Old_age Always
0
Always
Table 8-4 provides an example of the last part of the output of the of the show disk SMART-info detail
command. The attributes that need to be reviewed to determine if the drive needs to be replaced or
repaired are highlighted in bold. In this example, the Current_Pending_Sector and
Offline_Uncorrectable each have a value greater than one, so monitor these values over several days. The
Latent Sector Error feature attempts to repair such errored sectors in a background process by deleting
(evicting) corrupted content. If after several days of monitoring the values for Current_Pending_Sector
and Offline_Uncorrectable have not decreased, consider running the disk repair command.
Table 8-4
ID#
Disk Repair Case—Repair HDD Example
ATTRIBUTE_NAME
FLAG
VALUE WORST
THRESH TYPE
UPDATED RAW_VALUE
1
Raw_Read_Error_Rate
0x000f
072
063
044
Pre-fail
Always
59861501
3
Spin_Up_Time
0x0003 099
099
000
Pre-fail
Always
0
4
Start_Stop_Count
0x0032 100
100
020
Old_age
Always
12
5
Reallocated_Sector_Ct
0x0033 099
099
036
Pre-fail
Always
5
7
Seek_Error_Rate
0x000f
072
060
030
Pre-fail
Always
17169006
9
Power_On_Hours
0x0032 090
090
000
Old_age
Always
9010
10
Spin_Retry_Count
0x0013 100
100
097
Pre-fail
Always
0
12
Power_Cycle_Count
0x0032 100
037
020
Old_age
Always
12
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-29
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
Table 8-4
Disk Repair Case—Repair HDD Example
ID#
ATTRIBUTE_NAME
FLAG
THRESH TYPE
UPDATED RAW_VALUE
184
Unknown_Attribute
0x0032 100
100
099
Old_age
Always
0
187
Reported_Uncorrect
0x0032 093
093
000
Old_age
Always
0
188
Unknown_Attribute
0x0032 100
100
000
Old_age
Always
0
189
High_Fly_Writes
0x003a 100
100
000
Old_age
Always
0
190
Airflow_Temperature_Cel
0x0022 071
069
045
Old_age
Always
29 (Lifetime Min/Max
28/29)
194
Temperature_Celsius
0x0022 029
040
000
Old_age
Always
29 (0 22 0 0)
195
Hardware_ECC_Recovered
0x001a 052
011
000
Old_age
Always
59861501
197
Current_Pending_Sector
0x0012 100
100
000
Old_age Always
3
198
Offline_Uncorrectable
0x0010 100
100
000
Old_age Offline
3
199
UDMA_CRC_Error_Count
0x003e 200
200
000
Old_age
0
Note
VALUE WORST
Always
The Latent Sector Error feature attempts to repair errored sectors in a background process by deleting
(evicting) corrupted content. If after several days of monitoring the values for Current_Pending_Sector
and Offline_Uncorrectable have not decreased, consider running the disk repair command.
The show disk SMART-info detail command only reports sector errors that have been detected; there
may be more sectors in error adjacent to the reported bad sector. Repairing the drive also proactively
repairs unreported sector errors. However, because repairing a drive is a time-consuming process, it may
be easier to just replace the drive if a spare drive is available.
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-30
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
Table 8-5 provides detailed description of the Attribute Names that could indicate disk problems
primarily applicable to HDDs.
Table 8-5
Attribute Names Descriptions—Disk Problem Indicators
ID
Attribute Name Description
5
Reallocated
Sectors Count
Count of reallocated sectors. When the hard drive finds a read/write/verification error, it marks that
sector as "reallocated" and transfers data to a special reserved area (spare area). This process is also
known as remapping, and reallocated sectors are called remaps. The raw value normally represents a
count of the bad sectors that have been found and remapped; thus, the higher the attribute value, the
more sectors the drive has had to reallocate. This allows a drive with bad sectors to continue operation;
however, a drive that has had any reallocations at all is significantly more likely to fail in the near
future. While primarily used as a metric of the life-expectancy of the drive, this number also affects
performance. As the count of reallocated sectors increases, the read/write speed tends to worsen
because the drive head is forced to seek to the reserved area whenever a remap is accessed. A
workaround, which preserves drive speed at the expense of capacity, is to create a disk partition over
the region that contains remaps and instruct the operating system to not use that partition.
If the drive can repair the sector without remapping it, then the Reallocated Sectors Count is not
incremented. If the drive must remap the sector, the Reallocated Sectors Count is incremented.
197
Current
Count of “unstable” sectors (waiting to be remapped, because of read errors). If an unstable sector is
Pending Sector subsequently read successfully, this value is decreased and the sector is not remapped. Read errors on
a sector do not cause a remap of the sector, because the sector might be readable later. Instead, the
Count
drive firmware remembers that the sector needs to be remapped, and remaps it the next time it is
written.
Running the disk repair command resolves these counts.
198
Uncorrectable
Sector Count
or
The total count of uncorrectable errors when reading/writing a sector. A rise in the value of this
attribute indicates defects of the disk surface, problems in the mechanical subsystem, or both.
Running the disk repair command resolves these counts.
Offline
Uncorrectable
or
Off-Line Scan
Uncorrectable
Sector Count
Other Disk-Related show Commands
Additionally, the CDSM GUI and the CLI on the SEs display information about the disk-related alarms
with the show alarms command, and information about the disk and sector related errors with the show
disks error-handling command and the show disks error-handling details command. If sector alarms
have occurred, enter the show disk SMART-info details command on the SE to determine the state of
the drive and whether the drive needs to be replaced or potentially manually repaired using the disk
repair command.
Following is an example of the show alarms command output:
Minor Alarms:
------------Alarm ID
-------------------1 badsector
2 badsector
Module/Submodule
-------------------sysmon
sysmon
Instance
------------------------disk01
disk08
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-31
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
Following is an example of the show disks error-handling command output:
# show disks error-handling
disk05: Total bad sectors = 1, total errors = 2
disk10: Total bad sectors = 3, total errors = 9
Total failed disks = 0
Following is an example of the show disks error-handling details command;
# show disks error-handling details
disk05: Total bad sectors = 1, total errors = 2
disk05: sector (LBA): 3000005
errors: 2
disk10: Total bad sectors = 3, total errors = 9
disk10: sector (LBA): 16000
errors: 3
disk10: sector (LBA): 170001
errors: 4
disk10: sector (LBA): 180001
errors: 2
Total failed disks = 0
The details keyword displays the logical block address (LBA) for each bad sector along with the
corresponding I/O error count.
disk repair Command
This section describes the disk repair command.
Caution
The device should be offline before running the disk repair command. Because this command involves
complex steps, we recommend you contact Cisco Technical Support before running it.
The disk repair command not only repairs the bad sectors, but reformats the entire drive, so all data on
the drive is lost. The difference between the disk repair command and the disk reformat command is
that the disk format command only reinitializes the file system and does not repair bad sectors.
The disk repair command takes approximately three hours to complete per disk. The disk repair
command takes approximately 30 minutes on a solid-state drive (SSD).
Running the disk repair command erases all content on the drive. Never run the disk repair command
on a “live” system.
Overview
The disk repair command detects and repairs bad sectors across an entire drive on an SE, SR and
CDSM, then reformats the drive. All data on the drive is lost, but the sectors are repaired and available
for data storage again.
Usage
The disk repair command has the following syntax:
# disk repair disk_name sector sector_address_in_decimal
For example, the following command repairs the sector 4660 on disk 02:
# disk repair disk02 sector 4660
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-32
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
The sector keyword is optional. If the sector keyword is omitted, the entire disk is repaired. If the sector
keyword is specified along with the sector_address_in_decimal, then only a small area of the disk is
repaired (approximately 2 GB on either side of the sector address specified). The sector keyword should
only be used if the disk has a single sector error; that is, if the output of the show disk SMART-info
details command shows 1 unrecoverable pending sector in error; otherwise, omit the sector keyword to
repair the entire disk drive.
A minor alarm is set when an LSE is detected. After the sector is repaired with the disk repair command,
the alarm is turned off.
Minor Alarms:
------------Alarm ID
Module/Submodule
-------------------- -------------------1 badsector
sysmon
May 19 20:40:38.213 UTC, Equipment Alarm,
"Device: /dev/sdl, 1 Currently unreadable
Instance
------------------------disk11
#000003, 1000:445011
(pending) sectors"
The command is limited to repairing one disk at a time. Supplying multiple disk names to the disk repair
command is considered invalid input, and results in the command displaying the syntax information.
Output
Following is an example of the output displayed when the disk repair command is running:
Repairing disk01 [140013/140013] (100%) rate: 51(MB/s) eta: 4(s)
Repaired LBA 286747000 (total: 1)
Repaired LBA 286747999 (total: 2)
Repairing disk01 [140014/140013] (100%) rate: 51(MB/s) eta: 4(s)
Recovery complete (2 sectors repaired)
Check syslog for more details
Progress Indicator
The progress indicator is frequently updated to provide the user with up-to-date statistics and progress
of the repair. Following is an example of the progress indicator:
Repairing disk01 [140013/140013] (100%) rate: 51(MB/s) eta: 4(s)
Repairing disk01 [140013/140013] (100%) rate: 51(MB/s) eta: 4(s)
Note
Rate and ETA fields provide approximate estimates. The rate field does not indicate the top performance
of the drive.
Performance of low-level utilities can vary as much as 30 percent across different Internet Streamer CDS
releases.
Repair Notice
Each time the disk repair command detects and repairs a sector, a simple message is displayed that
describes the location of the repair as well as the cumulative total of repairs. Following is an example:
Repaired LBA 286747000 (total: 1)
Syslog
To provide a history of the repair, the disk repair command logs basic test information (start / stop /
failures) along with the address of every sector repaired.
repair-disk disk01: %SE-UNKNOWN-5-899999: Starting recovery
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-33
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
repair-disk disk01: %SE-UNKNOWN-5-899999: Repaired LBA 286747000 (total: 1)
repair-disk disk01: %SE-UNKNOWN-5-899999: Repaired LBA 286747999 (total: 2)
repair-disk disk01: %SE-UNKNOWN-5-899999: Recovery complete (2 sectors repaired)
Removing and Replacing Disk Drives
In brief, the procedure for replacing a disk is simply to enter the disk unuse command, optionally power
down the unit, remove the disk, insert the new disk, and reboot. During the reboot, the system
automatically detects any new disks and seamlessly allocates their space according to a simple
disk-policy heuristic.
The disk policy’s design, when adding new disks, is to always favor safety. If when a new disk is added,
the disk manager detects “degraded” or “bad” system volumes, the new disk is used to repair the system
volumes. Thus, the disk manager always strives to have two disks allocated to the system volumes. If
when a new disk is added, the system volumes are “normal” or “syncing,” the new disk is added to the
cdnfs volume.
For non-CDEs, the system disk cannot be easily replaced. If a system disk needs to be replaced on a
non-CDE, it needs to have the CDS software reinstalled by using the Recovery CD-ROM. For more
information, see the “Using the Cisco CDS Software Recovery CD-ROM” section on page 8-17.
The CDE250-2S6 and CDE25-2S3i have fixed bay mappings for internal drives. If the internal drives
show as “degraded” or “bad” on these platforms and a new drive is inserted into one of the external slots,
the disk manager allocates the disk as CDNFS, not SYSTEM. A failed internal drive requires that the
CDE be replaced.
Note
For the CDE220-2S3i, CDE250-2S6, CDE250-2S8, CDE250-2S9, and CDE250-2S10, because the
system disks are internal drives, if the system disk is “bad,” the CDE should be replaced. However, it
may be possible to repair the internal drive using the disk repair command, and let the system rebuild
the SYSTEM RAID drives.
The disk numbering on the CDE250 starts on the left side at disk00, with the last disk being disk23.
Figure 8-2 shows the disk numbering on a CDE220.
RESET
Disk Numbering on a CDE220
disk3
disk6
disk9
disk12
disk2
disk5
disk8
disk11
disk1
disk4
disk7
disk10
205500
Figure 8-2
Figure 8-3 shows the disk numbering on a CDE205.
Figure 8-3
Disk Numbering on a CDE205
disk2
RESET
disk0
Cisco Internet Streamer CDS 3.2 Software Configuration Guide
8-34
204744
disk1
Chapter 8
Maintaining the Internet Streamer CDS
Disk Maintenance
Replacing a Disk
When replacing a disk, the new disk is recognized and for SYSTEM drives, the RAID is rebuilt. After
inserting the new disk, enter the disk policy apply command to force the Internet Streamer CDS
software to detect the new disk and rebuild the RAID. After replacing the disk, we recommend that you
reboot the SE to ensure all CDS software services are functioning correctly.
To replace a disk on a device, do the following:
Step 1
Offload the device. In the CDSM GUI, choose Devices > Devices > Device Activation, check the Server
Offload check box, and click Submit.
Step 2
Enter the show disk details command to see if the drive is mounted. If the drive is mounted, enter the
disk unuse command to fully unuse the drive. The disk unuse command safely shuts down the drive,
guaranteeing all back">