-
Cisco ACNS Software Caching and Streaming Configuration Guide, Release 5.1
-
Index
-
Title Page
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Content Engine Configuration Overview
-
Chapter 4: Transparent Caching
-
Chapter 5: Proxy-Style Caching
-
Chapter 6: Reverse Proxy Caching
-
Chapter 7: Configuring Login Authentication and Authorization
-
Chapter 8: Configuring Content Authentication and Authorization
-
Chapter 9: Configuring a Primary Proxy Server
-
Chapter 10: Configuring Caching Protocols
-
Chapter 11: Configuring Content Service Protocols
-
Chapter 12: Configuring Streaming Media Services
-
Chapter 13: Configuring URL Filtering
-
Chapter 14: Configuring the Rules Template
-
Chapter 15: Creating and Managing IP Access Control Lists
-
Chapter 16: Configuring TCP Stack Parameters
-
Chapter 17: Monitoring and Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Web Cache Communication Protocol Version 1
-
Appendix C: Web Cache Communication Protocol Version 2
-
Table Of Contents
Understanding Some Basic ACNS Software Caching Concepts
Advanced Transparent Caching Services
Understanding Some Basic ACNS Streaming Media Concepts
Understanding Streaming Media Services
Understanding Streaming Media Caching
Supported Streaming Media Protocols
Overview of the WMT Caching Proxy
Understanding the RealProxy Streaming Media Solution
Configuring RealProxy Software
Understanding IP Multicasting Fundamentals
Copying Files Between Servers and Clients
Source-Specific Multicast Addresses
Understanding the Different Types of Authentication and Authorization
User Accounts and Privilege Profiles
Managing User Accounts Using the Content Engine GUI
Managing User Accounts Using CLI Commands
Example of Managing User Accounts Using CLI Commands
Types of Configurations on a Content Engine
Removing or Replacing a Content Engine
Working with the Content Engine GUI
Enabling Access to the Content Engine GUI
Enabling Secure Access to the Content Engine GUI
Enabling Nonsecure Access to the Content Engine GUI
Accessing the Content Engine GUI
Logging In to the Content Engine GUI
Logging Out of the Content Engine GUI
Disabling the Content Engine GUI
Understanding the Content Engine GUI
Navigating Around the Content Engine GUI
Working with the ACNS Software CLI
Starting the ACNS Software CLI
ACNS Software CLI Command Modes
Online Help and Keyboard Shortcuts
Using Secure Shell Version 1 Support for Login
Understanding the Basics
This chapter provides an overview of some basic concepts that are important to understand before locally configuring a Content Engine for caching and streaming.
This chapter contains the following sections:
•
Understanding Some Basic ACNS Software Caching Concepts
•
•
•
•
Understanding Some Basic ACNS Software Caching Concepts
This section describes the following fundamentals about ACNS software caching:
•
•
•
Caching Terminology
Table 2-1 describes some basic terminology commonly encountered in caching.
Introduction to Caching
Caching refers to the ability to store web objects such as web pages for later retrieval. Typically a web client requests an object from a web server using a web browser. (See Figure 2-1.)
Figure 2-1 Basic Web Request
Every web object has a uniquely defined address (URL) that allows the web browser to retrieve web objects, assuming that the server address exists in the DNS space. The basic components of a URL address are shown in Figure 2-2.
Figure 2-2 Basic Components of URL Address
To implement caching using web browsers, browsers have a local cache that the user can set up to help retain recently viewed pages for easier access during the web viewing process. (See Figure 2-3.) For instance, clicking the Back button on a browser takes advantage of local caching, because this recently viewed page is rapidly displayed.
Figure 2-3 Local Browser Cache Configuration
Despite the inherent advantages obtained using a local cache, a Content Engine is often used to provide specialized caching features to many users.
The ability of the Content Engine to store information on a large scale for later retrieval has significant advantages for the user and Internet traffic on the whole:
1.
2.
3.
In this scenario, a user attempts to retrieve a web object from a web server. Because the local browser does not have the page stored in its cache, the browser sends the request to the origin web server using the Content Engine as its proxy for the web request. In this deployment, the Content Engine serves as a proxy to the web client, and it first tries to satisfy the web request from its cache of stored objects.
Cacheable Content
Cacheable content is typically static application data and can be associated with a file type and file extension, as described in Table 2-2.
Network Protocols and Caching
The interaction between a web browser and a web server uses the existing standard application-layer Internet protocols such as HTTP, Microsoft Media Server (MMS), and Real-Time Streaming Protocol (RTSP). The Content Engine has to be able to serve web objects to the web client using all of these web access protocols.
Table 2-3 lists the network protocols that a Content Engine, which is running the ACNS 5.1 software, can use to serve content to the web client.
Table 2-3 Network Protocols and Caching
HTTP
HTTPS
FTP
TFTP
MMS
Windows Media Technologies (WMT) uses an application-level protocol called Microsoft Media Server (MMS) to send active streaming format (ASF) files across the Internet. For more information about WMT, see the "Understanding WMT Streaming" section.
RTSP
Real-Time Streaming Protocol (RTSP) is a streaming media protocol used to deliver two-way streaming media over IP networks. For more information about RTSP, see the "Understanding RTSP" section.
HTTP and Caching
HTTP is a request-response protocol used to send and receive messages between clients and servers. HTTP uses URLs to define web server addresses and objects that clients can retrieve. Caching is involved in this request-response process if there is a Content Engine that is acting as an intermediary in this process.
The Content Engine can serve as an intermediary in the following situations:
•
•
•
An HTTP message consists of an HTTP header and an entity body. Two types of messages in HTTP are directly related to the exchange between a client and a server:
•
•
HTTP Request
An HTTP request consists of a header field and an entity body. Within the header field, the request line consists of what is requested from the server, such as the URL requested. The general headers qualify the nature of the request, such as content format. The request header pertains mainly to authorization credentials. The entity header is concerned with the description of the data contained in the request. In particular, the request headers play an important role in providing the authorization credentials information that controls whether or not caching can be authorized when an HTTP request is made.
In the case of HTTP request authentication, a server can require that a client supply a username and a password before the server can satisfy the request. Such authentication allows for restricted information and easier tracking of users visiting particular web sites.
For more information about how the Content Engine uses authentication servers to handle authentication requests in an HTTP message, see the "Understanding HTTP Request Authentication" section.
HTTP Response
The structure of the HTTP response is similar to the structure of the HTTP request. The main difference between the two is the presence of the status line in the header field of the HTTP response. Here, the status line provides a response code and a descriptive explanation of the code used. For instance, the OK 200 status code is used to indicate a successful response, and the 404 Not Found status code is sent whenever the server or resource is not present. The following are the HTTP response status codes for different responses.
•
•
•
•
•
HTTPS and Caching
For customers who have numerous branch offices that use HTTPS to access content on their centrally located HTTPS servers, an HTTPS caching solution is critical. Because the connections between these branch offices and centrally located HTTPS servers are through the WAN, the amount of WAN traffic and latency are a serious concern to such customers. Consequently, they are interested in HTTPS caching solutions that they can deploy at their branch offices in order to reduce WAN traffic and latency.
ACNS 5.1 software provides an HTTPS caching solution that is ideally suited for such environments; it allows such customers to deploy Content Engines as a caching HTTPS proxy at their branch offices, as follows.
1.
2.
Tip
3.
4.
Note
Transparent HTTPS Caching Using SSL
Transparent HTTPS caching using SSL works as follows:
1.
2.
3.
4.
5.
6.
7.
Note
For information about how to configure a Content Engine for HTTPS proxy caching, see the "Configuring HTTPS-Related Parameters" section.
FTP and Caching
ACNS 5.1 software supports FTP requests from clients that are sent in the native FTP protocol, as well as those sent using HTTP.
•
•
ftp://ftp.funet.fi/pub/cbm/crossplatform/converters/unix/
Note
The Content Engine caches FTP traffic only when the client uses the Content Engine as a proxy server for FTP requests. All FTP traffic that was sent directly from the web client to an FTP server, if transparently intercepted by the Content Engine, is treated as non-HTTP traffic.
The Content Engine caches FTP file objects and directory listings in the cache file system (cfs) disk partition whether the files were transported using HTTP or native FTP. The Content Engine transforms regular directory listings from the FTP server into HTML if HTTP is used, with links that the client users can point to and click to download files.
The FTP proxy supports up to eight incoming ports. It can share the ports with transparent-mode services and also with the other proxy-mode protocols supported by the Content Engine, such as HTTP and HTTPS. In proxy mode, the Content Engine accepts and services the FTP requests only on the ports configured for FTP proxy. All the FTP requests on other proxy-mode ports are rejected in accordance with the error-handling settings on the Content Engine.
The Content Engine can apply the Rules Template to FTP requests based on server name, domain name, server IP address and port, client IP address, and URL.
The Content Engine logs FTP transactions in the transaction log, in accordance with the Squid syntax. When URL tracking is enabled, the Content Engine logs FTP transaction information to the syslog. The syslog entries are prefixed with <ftp>.
Note
Native FTP Caching
The Content Engine operating as an FTP proxy supports passive and active mode for fetching files and directories. Passive mode is the default FTP mode. The Content Engine automatically changes to active mode if passive mode is not supported by the FTP server. If the ftp proxy active-mode enable command is configured, FTP first attempts to fetch the file in active mode. If active mode fails, FTP attempts to fetch the file again in passive mode.
The following examples demonstrate the use of native FTP with the Content Engine.
ContentEngine# ftp server.cisco.comConnected to server.cisco.com.220 server.cisco.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.Name (server:huff): huff331 Password required for myserver.Password:230 User huff logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> pwd257 "/home/huff" is current directory.ftp> get /tmp/test.c200 PORT command successful.150 Opening BINARY mode data connection for /tmp/test.c (645 bytes).226 Transfer complete.645 bytes received in 0.00077 seconds (8.2e+02 Kbytes/s)ftp> quitContentEngine#ContentEngine# ftp server.cisco.comConnected to server.cisco.com.220 server.cisco.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.Name (server:huff): anonymous331 Guest login ok, send your complete e-mail address as password.Password: test@cisco.com230 Guest login ok, access restrictions apply.Remote system type is UNIX.Using binary mode to transfer files.ftp> pwd257 "/" is current directory.ftp>ftp> get(remote-file) /tmp/test.c(local-file) test.clocal: test.c remote: /tmp/test.c227 Entering Passive Mode (172.31.255.255)550 /tmp/test.c: No such file or directory.ftp>ContentEngine#FTP over HTTP Caching
The ACNS 5.1 software supports proxying and caching of FTP URL client requests using proxy-mode HTTP requests when URLs specify the FTP protocol (for example, ftp://ftp.mycompany.com/ftpdir/ftp_file). For these requests, the client uses HTTP as the transport protocol with the Content Engine, whereas the Content Engine uses FTP with the FTP server. When the Content Engine receives an FTP request from the web client, it first looks in its cache. If the object is not in its cache, it fetches the object from an upstream FTP proxy server (if one is configured), or directly from the origin FTP server.
The FTP proxy supports anonymous as well as authenticated FTP requests. Only base64 encoding is supported for authentication. The FTP proxy accepts all FTP URL schemes defined in RFC 1738. In the case of a URL in the form ftp://user@site/dir/file, the proxy sends back an authentication failure reply and the browser supplies a popup window for the user to enter login information.
The FTP proxy supports commonly used MIME types, attaches the corresponding header to the client, chooses the appropriate transfer type (binary or ASCII), and enables the browser to open the FTP file with the configured application. For unknown file types, the proxy uses binary transfer as the default and instructs the browser to save the download file instead of opening it. The FTP proxy returns a formatted directory listing to the client if the FTP server replies with a known format directory listing. The formatted directory listing has full information about the file or directory and provides the ability for users to choose the download transfer type.
TFTP and Caching
The Trivial File Transfer Protocol (TFTP) gateway feature has been added to ACNS software, Release 5.1. This feature provides a way for Content Engines to serve content files requested by networking devices that use the native TFTP protocol. Content Engines now perform TFTP to HTTP or FTP translation, eliminating the need for the system administrator to configure and manage a dedicated TFTP server to serve TFTP requests. This feature allows the Content Engine to accept native TFTP requests from the client at the front end, and serve the request using HTTP or FTP protocol at the back end; hence the feature is called the TFTP gateway.
Content files include router software images, router configurations, set top box images, IP phone configuration files, and so forth. If the requested file is not available on the Content Engine, the Content Engine caches the file on the fly from the origin server. The ACNS caching system retrieves the file from the Internet on behalf of the device and forwards it to the device. Future requests by any devices for the same file are satisfied by forwarding the file from the Content Engine cache.
Note
How the TFTP Server and Gateway Work
After the TFTP server has been enabled on the Content Engine, and a client sends a TFTP request for a file, the following events occur:
1.
2.
3.
4.
5.
6.
Note
DNS Caching
When you enable Domain Name System (DNS) caching on a locally deployed Content Engine, the Content Engine caches the results of recent DNS queries for faster resolution of identical queries in the future. This cached information is then made available to clients making future requests. The ability to store DNS information that can then be distributed to requesting clients turns the Content Engine into a DNS caching name server. For more information about how to configure the Content Engine for DNS caching, see the "Configuring Bandwidth for Interfaces and Content Services" section.
Note
Transparent Caching Hierarchy
Because a Cisco Content Engine can be transparent to the client and to network operation, customers can easily place Content Engines in several network locations in a hierarchical fashion. For example, if an ISP deploys a Content Engine at its main point of access to the Internet, all of its points of presence (POPs) benefit, because requested content can be available at this main point of access without going through the Internet. (See Figure 2-4.)
Figure 2-4 Transparent Caching Hierarchy in ISP Deployments
Client requests reach the Content Engine and are fulfilled from its storage. To further improve service to certain clients, ISPs can deploy Content Engines at each POP (Content Engine B and C). Then, when a client accesses the Internet, the request is first redirected to the POP Content Engine. If the POP Content Engine is unable to fulfill the request from local storage, it makes a normal web request to the end server.
Upstream, this request is redirected to the Content Engine at the main Internet access point (Content Engine A). If the request is fulfilled by this Content Engine, traffic on the main Internet access link is avoided, the origin web servers experience lower demand, and the client experiences better network response times.
Enterprise networks can apply this hierarchical transparent architecture in the same way. (See Figure 2-5.)
Figure 2-5 Transparent Caching Hierarchy in Enterprise Deployments
Advanced Transparent Caching Services
As Table 2-4 indicates, Cisco Content Engines offer advanced transparent caching technologies (services), which provide some important benefits.
For more information on these features, see the "Advanced Transparent Caching Features" section.
Understanding Some Basic ACNS Streaming Media Concepts
This section describes how WMT streaming media services are supported on the Content Engine, and covers the following topics:
•
•
•
Note
Understanding Streaming Media Services
Streaming is a technology that allows content to be accessed or viewed before all the media packets have been received, whereas with caching, the content must be received in its entirety before it can be accessed. Streaming media can be delivered as live content or as on-demand content, such as video on demand (VOD). Cisco ACNS software supports several types of streaming media services, including Cisco Streaming Engine, RealNetworks RealMedia, Microsoft WMT, and Apple QuickTime.
Understanding Streaming Media Caching
As Figure 2-6 shows, streaming media files are files that are sent to the user and played on the user's media player as the files are received from the network. Streaming media files avoid a waiting period for viewing these files because they are immediately available as a continuous stream of data packets. This eliminates the need to store large media files for viewing purposes or the need to allocate storage space for these files before playing them.
Figure 2-6 Streaming Media Model with Content Engine as Manual Proxy
In Figure 2-6 both audio and video are being recorded from an event to be distributed later either as VOD or live to a network of users. The encoder software and hardware compress the signal into streamable files, which are then sent to a media file server. This media server in turns delivers the media files on a live or on-demand basis to users with the particular media software on their personal computers or other electronic devices. Note that in Figure 2-6 the Content Engine is manually configured to be the caching proxy for the users in that particular network.
Supported Streaming Media Protocols
Table 2-5 lists the different types of streaming media protocols, control channels, the corresponding data format, and transport types supported by ACNS 5.x software.
Table 2-5 Streaming Media Protocols
Windows Media format
TCP
MMS1
UDP,2 TCP, HTTP, IP multicast
RealNetworks media format
TCP
RTSP, PNA3
UDP, TCP, HTTP, IP multicast
1 MMS = Microsoft Media Server
2 User Datagram Protocol
3 PNA = Progressive Networks Audio
The MMS protocol automatically looks for the optimal transport to deliver the streaming media in the following order:
•
•
•
UDP is a connectionless, transport-layer protocol that is ideal for real-time media because it does not guarantee delivery. Although this sounds like a drawback rather than an advantage, it is a characteristic particularly suited for streaming media. Unlike data such as files or e-mail, which must be delivered in their entirety no matter how long the transmission time, the value of streaming media data is constrained by time. If a frame of video is lost, it is worthless because it will not arrive within the correct time frame.
Note
WMT is Microsoft's set of streaming solutions for creating, distributing, and playing back digital media files on the Internet. For more information on this streaming media protocol, see the "Understanding WMT Streaming" section. For information about configuring WMT streaming media services on a locally deployed Content Engine, see "Configuring Streaming Media Services."
RTSP is a standard Internet streaming control protocol (RFC 2326). It is an application-level protocol that controls the delivery of streaming media data with real-time properties, such as video and audio, and has been widely adopted as a streaming media protocol in the caching and ACNS environments. Apple QuickTime, RealProxy, and Cisco Streaming Engine are all content distributors that use RTSP as the streaming media protocol. For more information on this streaming protocol, see the "Understanding RTSP" section. For information about configuring RTSP streaming media services using on a locally deployed Content Engine, see "Configuring Streaming Media Services."
Understanding WMT Streaming
Microsoft WMT Version 9.0 is a set of streaming solutions for creating, distributing, and playing back digital media files on the Internet.
Note
To disseminate live and pre-positioned Windows Media content on an ACNS network, you need WMT caching proxy and server capabilities on the Content Engine. This guide focuses on the WMT caching proxy capabilities of the Content Engine, because the WMT server capabilities are discussed in the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.
Tip
Table 2-6 describes the major components of WMT.
Overview of WMT Caching
Caching frequently accessed content closer to the web client (end user) provides better-quality streams and saves network bandwidth. When the Content Engine acting as a proxy fetches the content from the origin WMT server to be served to the web client, it stores the cacheable stream on the media file system (mediafs). The proxy can cache partial streams. When a web client requests a part of the stream that has not been cached, the proxy fetches the missing portions from the origin WMT server. Even when there is a cache hit, a connection is maintained with the origin WMT server in order to report client usage statistics, which can be used for accounting and other purposes by the origin WMT server.
To enable WMT caching on the Content Engine, use the wmt cache enable global configuration command. To set the maximum object size for streaming media objects, use the wmt cache max-obj-size command. The range of values is between 1 and 1,000,000 megabytes. The default value is 1024 megabytes.
Streams served from the cache are guaranteed to be fresh because the Content Engine always checks with the origin WMT server, using the appropriate cache parameter settings. When the storage limit is reached, older objects are replaced using an appropriate replacement algorithm to ensure a proper hit ratio. For more information regarding the appropriate cache parameter settings, see the "Configuring HTTPS-Related Parameters" section.
The proxy can cache authenticated streams, and on a cache hit, the authentication credentials of the requesting client are revalidated against the origin server before the content is served.
WMT caching is supported in nontransparent (manual) proxy as well as transparent proxy modes.
Note
Overview of the WMT Caching Proxy
The Content Engine acting as a WMT caching proxy supports a basic proxy feature; it accepts incoming WMT streaming requests from web clients (end users) and acts on behalf of these clients communicating with the origin WMT server. The WMT caching proxy accepts and serves the streaming requests over the MMS protocol as well as the HTTP protocol. MMS is the protocol that WMT uses for communication between players and servers. (See Figure 2-7.)
Figure 2-7 Content Engine as a Conventional WMT Caching Proxy
Note
WMT caching is supported in transparent proxy mode as well as nontransparent (manual) proxy mode. When possible, the WMT caching proxy also caches the streaming content and serves the request from its cache instead of retrieving it from the origin WMT server.
The Content Engine, which is acting as the WMT caching proxy, accepts transparently intercepted requests as follows:
•
•
The WMT caching proxy also supports splitting of live streams (that is, it splits a single inbound feed to multiple clients) and multicasting.
Tip
WMT Caching Proxy Requirements
The following are requirements for a Content Engine that will be functioning as a WMT caching proxy:
•
•
WMT Caching Proxy Features
This section provides an overview of the following WMT caching proxy features:
•
•
•
•
•
Variable Bit Rates
A content provider can create streaming media files at different bit rates to ensure that different clients who have different connections—for example, modem, DSL, or LAN—can handle a particular bit rate of their choice. The WMT caching proxy can cache multiple bit rate or variable bit rate (VBR) files, and based on the bit rate specified by the client, it serves the appropriate stream. Another advantage of creating variable bit rate files is that a single URL is all that must be specified for the delivery of streaming media.
Use the wmt max-bitrate global configuration command to set the maximum streaming bit rate that can be delivered to a requesting client. The range of values is between 0 and 2,147,483,647 kilobits per second. The default value is 0 (no bit rate limit).
Live Splitting
The Content Engine splits requests for live streams. That is, a single stream from the origin streaming server is split to serve each client that requested the stream. (See Figure 2-8.) In the case of a WMT caching-enabled Content Engine acting as proxy, when the client requests a publishing point on a server (without specifying an ASF file), then the Content Engine dynamically creates an alias file that references the remote streaming server. All further requests to that remote streaming server are served by splitting the stream.
Note that when the first client (Client 1) that requested the original stream disconnects from the network, the proxy continues to serve the other clients (Client 2 and Client 3), until all clients disconnect from the network.
Figure 2-8 Live Splitting
Live splitting at the proxy (the WMT- enabled Content Engine) is better than at the remote streaming server, because the proxy is closer to the clients, thereby potentially saving considerable network bandwidth between the client and the origin streaming server.
Note
Proxy Authentication
The WMT-enabled Content Engine supports both basic and NTLM authentication by the origin server. When a client requests content that needs user authentication, the Content Engine acts as an agent, conveying the authentication information to and from the client and server to authenticate the client. Once the client is authenticated, the content is streamed as usual. The authentication is performed for both cached content as well as noncached VOD content.
The following are the two types of proxy authentication methods.
•
•
A file is served from the cache only if it is a complete cache hit; that is, the complete file is present on disk. If the file is not a complete hit, then the entire file is fetched from the origin server in the case of NTLM. NTLM authentication is supported in manual as well as transparent proxy mode, over both HTTP and MMS. The proxy supports caching and delivery of Digital Rights Management (DRM)-protected Windows Media files. Access control lists (ACLs) enforced by the origin server are automatically enforced by the proxy.
Note
Transaction Logging for WMT Streaming
The Content Engine's logging format for WMT streaming is consistent with that of the Windows Media server 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. All client information in the transaction logs is sent to the origin server by default.
Error Logging for WMT Streaming
The Content Engine's error log for WMT streaming consists of the debugging logs written by the application. Error logs are in the same format and location as syslogs.
Understanding RTSP
RTSP is a standard Internet streaming control protocol (RFC 2326). It is an application-level protocol that controls the delivery of streaming media data with real-time properties, such as video and audio, and has been widely adopted as a streaming media protocol in the caching and ACNS environments. Apple QuickTime, RealProxy, and Cisco Streaming Engine are all content distributors that use RTSP as the streaming media protocol.
The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RTSP client software. The redirection of RTSP traffic to the Content Engine media cache is enabled with the Content Engine GUI or CLI. The RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy page of the Content Engine GUI.
An RTSP agent on the Content Engine listens on the standard RTSP port (default port 554) and funnels incoming RTSP traffic through it to enforce rules-based implementation and URL filtering of RTSP requests. Based on the properties of the incoming request, including such properties as user client player, final destination, and media file type, the RTSP agent sends the request to one of the content distributors. For more information about enabling RTSP streaming media services on a locally deployed Content Engine, see the "Configuring RTSP Services on a Locally Deployed Content Engine" section.
The ACNS 5.x software offers only the RealNetworks RealProxy as an RTSP streaming media content distributor. If your Content Engine is part of a device group in an ACNS environment, then RealSubscriber and the Cisco Streaming Engine server also serve as RTSP content distributors as described in the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.
Tip
Understanding the RealProxy Streaming Media Solution
ACNS 5.x software includes RealServer Version 9 as an optional component that is used as a streaming media engine.
The RealProxy software from RealNetworks, Inc., included as a software option in the ACNS 5.x software, supports both live splitting (distributing live feeds) and streaming media caching (on-demand content) in an RTSP-based format.
When performing stream splitting, the RealProxy accepts a live stream from a RealServer and re-serves the stream to multiple requesting RealPlayer clients, thus eliminating multiple connections to the RealServer. The RealServer is preconfigured to act as a RealMedia transmitter, and the RealProxy is preconfigured to act as a RealMedia receiver.
Note
Streaming media caching provides content on demand. If one user has viewed a cached streaming media file, it can be served to subsequent users without the requirement to connect with the origin server. Live broadcasts are not files and are not cached.
Table 2-7 describes the features and benefits of RealProxy software.
Table 2-7 RealProxy Features and Benefits
Proxy for RealPlayer 9.0
The RealProxy makes requests for content on behalf of client RealPlayer users.
Manages traffic inside the firewall by coordinating requests for similar content.
Masks end user IP addresses.
Splitting support for live broadcasts
The RealProxy "splits" a single inbound live broadcast feed to multiple client RealPlayers. For more information on live splitting, see the "Live Splitting" section.
Reduces inbound bandwidth usage to a single stream of content during a live event.
Caching of RealSystem G2 and PNA (Progressive Network Audio) content.
The RealProxy caches all proxied streaming media traffic from RealNetworks servers. The RealProxy caches content locally after authentication with the origin RealNetworks server.
Significantly reduces inbound bandwidth usage by eliminating redundant file transmissions across the network.
Authentication and accounting
The RealProxy authenticates every content request with the origin RealNetworks server before delivering the cached content to the client.
Retains access to general usage data for the broadcaster.
Appropriately authenticates users.
Guarantees the freshest content for the end users.
Aggregate bandwidth thresholds
Setting thresholds caps inbound and outbound bandwidth to the RealProxy.
Provides control over aggregate bandwidth usage within the network and prevents stress on mission-critical applications.
Proxy routing
The RealProxy can tier proxies and manage bandwidth at lower nodes in the network. "Parent" proxies can be chosen based on logical sets of rules on the downstream proxy.
Allows network administrators to proxy route requests, providing an additional level of control.
Note
Configuring RealProxy Software
The Content Engine can be configured to accept transparently redirected RTSP requests as well as traditional proxy-style RTSP requests from RealPlayer client software. The redirection of RTSP traffic to the Content Engine media cache is enabled with the Content Engine CLI. The RealProxy software is configured with the RealAdministrator GUI, accessed from the RealProxy page of the Content Engine management GUI.
Detailed configuration, statistics, and reporting of RealProxy status are obtained through the RealAdministrator GUI. Table 2-8 lists RealProxy-related CLI commands.
The Content Engine GUI has a RealProxy window (as shown on Figure 12-1) that allows you to enable RealProxy on a locally deployed Content Engine. The Admin button is active on the Content Engine GUI when the RealProxy software is installed and enabled. You will be provided with a default user and password to access this administration page from the Content Engine GUI.
Tip
Use the rtsp proxy global configuration command to configure the Content Engine to accept redirected RTSP traffic from either a Layer 4-enabled switch or a WCCP-enabled router, or to configure the Content Engine as a media proxy to receive RTSP proxy-style requests from RealPlayer clients. RTSP requests not from RealPlayer clients are directed to the specified origin server.
The wccp rtsp global configuration command registers the Content Engine with WCCP Version 2-enabled routers that can transparently redirect RTSP traffic to the Content Engine.
The rtsp L4-switch global configuration command enables the configuration of Layer 4 switch interoperability for media caching using RTSP.
The RTSP proxy redirector listens to port 554 traffic or any other port configured to listen to this traffic, and if the player is a RealPlayer, it redirects the RTSP request to use the RealProxy for RealMedia traffic.
RealProxy Statistics
Use the following CLI commands to display RealProxy statistics. For sample outputs of the show statistics command, see the "RealProxy Examples" section.
ContentEngine# show statistics rtsp proxy media-real requestsContentEngine# show statistics rtsp proxy media-real savings
Note
Understanding IP Multicasting Fundamentals
Multicast delivery enables the distribution of streaming media by allowing different receiving devices on the IP multicast to receive a single stream of media content from the Content Engine simultaneously. This can save significant network bandwidth consumption, because a single stream is sent to many devices, rather than sending a single stream to a single device every time that this stream is requested.
This multicast delivery feature is enabled by setting up a multicast address on the Content Engine to which different devices, configured to receive content from the same channel, can subscribe. The delivering device sends content to the multicast address set up at the Content Engine, from which it becomes available to all subscribed receiving devices.
To take advantage of multicasting, all devices (including Content Engines, routers, and clients), must be multicast-enabled. For this reason, multicasting is mostly used in local networks where routers can be configured for multicasting. Multicast delivery over the Internet can only be accomplished when all the devices that participate in the multicast have been enabled for multicasting.
The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast addresses. The IANA has assigned the IPv4 Class D address space to be used for IP multicast. Therefore, all IP multicast group addresses fall in the range from 224.0.0.0 through 239.255.255.255. However, some combinations of source and group address should not be routed for multicasting purposes. Table 2-9 lists the unusable multicast address ranges and the reasons they should not be used.
Note
Table 2-9 Unusable Multicast Address Assignments
224.0.1.2/32
Known insecure service address. See the "Insecure Services" section.
224.0.1.3/32
Reserved for the discovery of resources within the administrative domain. See the "Limited Scope Addresses" section.
224.0.1.22/32
Known insecure service address.
224.0.1.35/32
Reserved for the discovery of resources within the administrative domain.
224.0.1.39/32
Reserved for the discovery of resources within the administrative domain.
224.0.1.40/32
Reserved for the discovery of resources within the administrative domain.
224.0.2.2./32
Known insecure service address.
224.77.0.0/16
Used to copy files between servers and clients in a local network. See the "Copying Files Between Servers and Clients" section.
224.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches. See the "Layer 2 Multicast Addresses" section.
225.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
225.1.2.3/32
Used to copy files between servers and clients in a local network.
225.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
226.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
226.77.0.0/16
Used to copy files between servers and clients in a local network.
226.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
227.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
227.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
228.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
228.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
229.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
229.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
230.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
230.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
231.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
231.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
232.0.0.0/24
Source-specific multicast address. See the "Source-Specific Multicast Addresses" section.
232.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
233.0.0.0/8
GLOP address. See the "GLOP Addresses" section.
233.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
233.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
234.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
234.42.42.42/32
Used to copy files between servers and clients in a local network.
234.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
234.142.142.42/31
Used to copy files between servers and clients in a local network.
234.142.142.44/30
Used to duplicate files between clients and servers in a local network.
234.142.142.48/28
Used to copy files between servers and clients in a local network.
234.142.142.64/26
Used to copy files between servers and clients in a local network.
234.142.142.128/29
Used to copy files between servers and clients in a local network.
234.142.142.136/30
Used to copy files between servers and clients in a local network.
234.142.142.140/31
Used to copy files between servers and clients in a local network.
234.142.142.142/32
Used to copy files between servers and clients in a local network.
235.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
235.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
236.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
236.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
236.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
236.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
237.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
237.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
238.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
238.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
239.0.0.0/8
Administratively scoped address that should not be passed between administrative domains. See the "Limited Scope Addresses" section.
239.0.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
239.128.0.0/24
Local address that maps to an Ethernet multicast address range and may overwhelm the mapping table of LAN switches.
Some of these addresses have been reserved for use by multicast applications through the IANA. For example, IP address 224.0.1.1 has been reserved for the Network Time Protocol (NTP).
IP addresses reserved for IP multicast are defined in RFC 1112, Host Extensions for IP Multicasting. More information about reserved IP multicast addresses can be found at the following location:
http://www.iana.org/assignments/multicast-addresses.
Tip
Insecure Services
Applications that use multicast addresses in the 224.0.1.2/32, 224.0.1.22/32, and 224.0.2.2/32 ranges have been demonstrated to be vulnerable to exploitation, which has led to serious security problems.
Copying Files Between Servers and Clients
Some applications are used to copy files between servers and clients and to otherwise maintain groups of personal computers. These applications are intended to be used on a local subnet or within an administrative domain, but the default addresses used by the software are not within the administrative addresses used by the administratively scoped addresses listed in Table 2-9.
Limited Scope Addresses
Limited scope addresses are also called administratively scoped addresses. These addresses are described in RFC 2365, Administratively Scoped IP Multicast, to be restricted to a local group or organization. Companies, universities, or other organizations can use limited scope addresses to have local multicast applications that will not be forwarded outside their domain. Routers typically are configured with filters to prevent multicast traffic in this address range from flowing outside an autonomous system (AS) or any user-defined domain. Within an autonomous system or domain, the limited scope address range can be further subdivided so that local multicast boundaries can be defined. This subdivision is called address scoping and allows for address reuse between these smaller domains.
Source-Specific Multicast Addresses
Addresses in the 232.0.0.0/8 range are reserved for source-specific multicast (SSM). SSM is an extension of the Protocol-Independent Multicast (PIM) protocol that allows for an efficient data delivery mechanism in one-to-many communications.
GLOP Addresses
RFC 2770, GLOP Addressing in 233/8, proposes that the 233.0.0.0/8 address range be reserved for statically defined addresses by organizations that already have an AS number reserved. This practice is called GLOP addressing. The AS number of the domain is embedded into the second and third octets of the 233.0.0.0/8 address range. For example, the AS number 62010 is written in hexadecimal format as F23A. Separating the two octets F2 and 3A results in 242 and 58 in decimal format. These values result in a subnet of 233.242.58.0/24 that would be globally reserved for AS 62010 to use.
Layer 2 Multicast Addresses
Historically, network interface cards (NICs) on a LAN segment could receive only packets destined for their burned-in MAC address or the broadcast MAC address. In IP multicast, several hosts need to be able to receive a single data stream with a common destination MAC address. Some means had to be devised so that multiple hosts could receive the same packet and still be able to differentiate between several multicast groups.
One method to accomplish this is to map IP multicast Class D addresses directly to a MAC address. Today, using this method, NICs can receive packets destined to many different MAC addresses—their own unicast, broadcast, and a range of multicast addresses.
The IEEE LAN specifications made provisions for the transmission of broadcast and multicast packets. In the 802.3 standard, bit 0 of the first octet is used to indicate a broadcast or multicast frame. Figure 2-9 shows the location of the broadcast or multicast bit in an Ethernet frame.
Figure 2-9 IEEE 802.3 MAC Address Format
This bit indicates that the frame is destined for a group of hosts or all hosts on the network (in the case of the broadcast address 0xFFFF.FFFF.FFFF).
IP multicast makes use of this capability by sending IP packets to a group of hosts on a LAN segment.
Ethernet MAC Address Mapping
The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal format. Half of this block is allocated for multicast addresses. The range from 0100.5e00.0000 through 0100.5e7f.ffff is the available range of Ethernet MAC addresses for IP multicast.
This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group address. The mapping places the lower 23 bits of the IP multicast group address into these available 23 bits in the Ethernet address. (See Figure 2-10.)
Figure 2-10 IP Multicast to Ethernet or FDDI MAC Address Mapping
Because the upper five bits of the IP multicast address are dropped in this mapping, the resulting address is not unique. In fact, 32 different multicast group IDs map to the same Ethernet address. (See Figure 2-11.) Network administrators should consider this fact when assigning IP multicast addresses. For example, 224.1.1.1 and 225.1.1.1 map to the same multicast MAC address on a Layer 2 switch. If one user subscribed to Group A (as designated by 224.1.1.1) and the other users subscribed to Group B (as designated by 225.1.1.1), they would both receive both A and B streams. This situation limits the effectiveness of this multicast deployment.
Figure 2-11 MAC Address Ambiguities
Understanding the Different Types of Authentication and Authorization
ACNS 5.x software provides authentication, authorization, and accounting (AAA) support for users who have external access servers (for example, RADIUS or TACACS+ servers), and for users who need a local access database with AAA features.
•
•
–
–
–
Note
•
In ACNS 5.x environments that have a locally deployed Content Engine, there are two main types of authentication and authorization:
•
The Content Engine verifies the user's username and password with either its local database or with a remote user database (RADIUS or TACACS+). You can configure the Content Engine to use the following login authentication methods: local, RADIUS, or TACACS+. By default, the Content Engine uses the local login authentication method as the primary login authentication method. For more about this topic, see "Configuring Login Authentication and Authorization."
•
As organizations extend the use of web applications and Internet access to their employees, they are confronted with the following challenges:
–
–
Organizations can use HTTP authentication as a mechanism to restrict access to online content. If HTTP authentication is configured on a locally deployed Content Engine, the Content Engine checks a remote database (for example, a RADIUS, TACACS+, or LDAP database) for user password authentication. If the password authentication is successful, then the Content Engine grants the user access to the requested content; otherwise, the user is denied access to the content.
To implement another level of access control to content that is served through the Content Engine, you can configure a Content Engine for group-based authorization (for NTLM and LDAP users). With group-based authorization, the Content Engine checks its access lists to determine if the group that the user belongs to should be granted or denied access to the content. This type of content authentication, which is referred to as "group-based authorization," only occurs after HTTP request authentication has occurred. For more about this topic, see the "Configuring Group-Based Authorization" section.
Note
The Content Engine can be configured as a proxy caching engine that will store and serve authorized, scrubbed, and filtered content to only authorized users.
User Accounts and Privilege Profiles
ACNS software uses privilege profiles to determine which tasks a user can perform, and the level of access provided.
The two types of predefined privilege profiles are:
•
•
A privilege profile must be assigned to each new user account. A Content Engine that is running ACNS software comes with a predefined superuser account that can be used initially to access the Content Engine and add other users.
Access to the Content Engine GUI can be controlled with multiple levels of username and password access, and access can be restricted to a subset of IP addresses (hosts). These access controls are configured through the Content Engine GUI and CLI.
Managing User Accounts
A Content Engine that is running ACNS software comes with a single predefined superuser user account (root administrator). This predefined account can be used to initially access the Content Engine GUI in order to initially configure the Content Engine and then add other user accounts. The username for this predefined superuser user account is admin and the default password is default. If these defaults have been changed by another ACNS system administrator, you need to obtain the new username and password.
Users with administrative privileges can add, delete, or modify user accounts through the Content Engine GUI or CLI.
Managing User Accounts Using the Content Engine GUI
From the Content Engine GUI, choose System > Users. Use the displayed Users page to add or delete users, or modify their privileges. After you add users, they are listed on the Users page. (See Figure 2-12.) For instance, in the following example a user named dd with normal user privileges has been defined.
Figure 2-12 Managing User Accounts through the Content Engine GUI
Tip
For more information about accessing the Content Engine GUI, see the "Accessing the Content Engine GUI" section.
Managing User Accounts Using CLI Commands
Users with administrative privileges can add, delete, or modify the user accounts on a Content Engine through the username command.
Note
To use the CLI to add or modify an ACNS system user account, follow these steps:
Step 1
Step 2
ContentEngine(config)# username name {cifs-password | samba-password {0 plainword | 1 lancrypto ntcrypto} | password {0 plainword | 1 cryptoword} uid uid} | privilege {0 | 15}}Table 2-10 describes the parameters for the username CLI command.
Example of Managing User Accounts Using CLI Commands
This example shows how passwords and privilege levels for user accounts on a Content Engine can be changed with the username command.
ContentEngine# show user username jrdoeUid : 2003Username : jrdoePassword : ghQ.GyGhP96K6Privilege : normal userContentEngine(config)# username jrdoe privilege 15User's privilege changed to super user (=15)ContentEngine# show user username jrdoeUid : 2003Username : jrdoePassword : ghQ.GyGhP96K6Privilege : super userContent Engine Management
You can use the following methods to configure a Content Engine for caching and streaming:
•
•
Figure 2-13 Example of the Content Engine GUI
Because this guide focuses on how to configure a locally deployed Content Engine for caching and streaming, the CLI or Content Engine GUI method is used throughout this guide.
Note
Types of Configurations on a Content Engine
A locally configured Content Engine has two types of system configuration:
•
•
You can use the Content Engine GUI or CLI to update the running system configuration and save the running system configuration as the startup system configuration.
To use the Content Engine GUI to save the current running configuration as the startup configuration, follow these steps:
1.
2.
To use the CLI to save the current running configuration as the startup configuration, use the copy running-config global configuration command. The running system configuration can be saved to the sysfs partition, flash memory, or TFTP server. For example, enter the following to save the running configuration to flash memory:
ContentEngine (config)# copy running-config startup-config
Tip
Rebooting the Content Engine
Using the Content Engine GUI, you can locally reboot a Content Engine. Clicking the Reboot button in the Content Engine main window (Figure 2-14) causes the Content Engine to perform a controlled shutdown and then restarts the operating system on the Content Engine. The Content Engine releases all WCCP connections to a router during the reboot process if these conditions exist:
•
•
Tip
To reboot a locally deployed Content Engine, follow these steps:
Step 1
Step 2
Removing or Replacing a Content Engine
Refer to the Content Engine hardware documentation for instructions on physically removing a Content Engine from an active network.
The router and the Content Engine are in constant communication when WCCP is enabled; thus, when the router notices that the Content Engine is no longer responding to it, the router stops sending requests to the Content Engine. This is transparent to users. If other Content Engines are attached to the router, the router continues sending requests to the other Content Engines.
Working with the Content Engine GUI
This section describes how to perform such basic tasks as enabling and accessing the ACNS software GUI on locally deployed Content Engines. This GUI is referred to as the "Content Engine GUI" throughout the rest of this guide.
Enabling Access to the Content Engine GUI
In the ACNS 5.1 software release, secured access to the Content Engine GUI has been added. Consequently, you can configure the Content Engine GUI on a locally deployed Content Engine for secured or nonsecure access. The secured Content Engine GUI is the default.
Either secure or nonsecure access to the Content Engine GUI is possible but not both. For example, if the secured Content Engine GUI is enabled (for example, https:// access on port 8003) , then nonsecure access to the Content Engine GUI (for example, http:// access on port 8001) is not allowed.
To enable or specify the port number of the Content Engine GUI server, use the gui-server global configuration command.
gui-server {enable | port port | secure {enable | port port}}Enabling Secure Access to the Content Engine GUI
To enable secure access to the Content Engine GUI, use the gui-server global configuration command.
ContentEngine(config)# gui-server secure enable port 8003
The port number can be between 1 and 65535. The default port for secure access to the GUI is 8003.
In this example, secure access to the Content Engine GUI is enabled on the default port number 8003.
Now that secure access to the Content Engine GUI is enabled, you can access the GUI as described in the "Accessing the Content Engine GUI" section.
Enabling Nonsecure Access to the Content Engine GUI
To enable nonsecure access to the Content Engine GUI, use the gui-server global configuration command.
ContentEngine(config)# gui-server enable port 8001
The port number can be between 1 and 65535. The default port for nonsecure access to the GUI is 8001.
In this example, nonsecure access to the Content Engine GUI is enabled on the default port number 8001.
Now that the nonsecure access to Content Engine GUI is enabled, you can access the GUI as described in the "Accessing the Content Engine GUI" section.
Accessing the Content Engine GUI
The Content Engine GUI (Figure 2-14) is the web portal for configuring a locally deployed Content Engine as a caching and streaming engine.
Figure 2-14 Content Engine GUI
Note
After the ACNS software is installed on the Content Engine, use a standard web browser to log in and access the Content Engine GUI.
Logging In to the Content Engine GUI
The Content Engine GUI comes with a single predefined user account (root administrator) that can be used to access the Content Engine initially and then add other users to the system. The username for this predefined user account is admin and the default password is default. If these defaults have been changed by another ACNS system administrator, you need to obtain the new username and password.
Before logging in to the Content Engine GUI, check that you have the following information:
•
•
•
Note
To access the Content Engine GUI, you must enter the URL or IP address of the Content Engine and the port number. The URL (location) of of the Content Engine is determined during the installation of the ACNS software. If your network supports DNS and the IP address of the Content Engine has been added to your DNS table, you can access the Content Engine GUI by using the DNS name of the Content Engine.
The port number of the Content Engine GUI is determined when the ACNS software is installed on the Content Engine. The default port number for nonsecure access is 8001. The default port number for secure access is 8003. Secure access to the Content Engine GUI is enabled on the default port number 8003. Note that HTTP is used for non-secure access and HTTPS is used for secure access.
To log in to the Content Engine GUI, follow these steps:
Step 1
Tip
Step 2
For example, if you are accessing the GUI in nonsecure mode, enter the URL:
http://<Name_of_Content_Engine>:8001Alternatively, enter the IP address:
http://<IP_address_of_Content_Engine>:8001In the preceding examples, nonsecure access to the Content Engine GUI is enabled on the default port number 8001.For example, if you are accessing the GUI in secure mode, enter the URL:
https://<Name_of_Content_Engine>:8003Alternatively, enter the IP address:
https://<IP_address_of_Content_Engine>:8003Step 3
Step 4
Username: adminPassword: <password>Step 5
Note
Logging Out of the Content Engine GUI
To log out of the Content Engine GUI, follow these steps:
Step 1
Step 2
Step 3
Step 4
Disabling the Content Engine GUI
To disable the Content Engine GUI, use the no gui-server global configuration command:
no gui-server {enable | port port | secure {enable | port port}}
For example, if secure access to the GUI is enabled on port 8003, enter the following command to disable it:
ContentEngine(config)# no gui-server secure enable port 8003
In the following example, nonsecure access to the Content Engine on port 8001 is being disabled:
ContentEngine(config)# no gui-server enable port 8001
Understanding the Content Engine GUI
When you access the Content Engine GUI, it opens with a window (page) that is referred to as the Content Engine main window. (see Figure 2-15.)
Figure 2-15 Content Engine GUI Main Window
As Figure 2-15 shows, the Content Engine GUI has a set of tabs and buttons.
Tip
Content Engine GUI Tabs
Table 2-11 describes the four feature tabs and their associated functions. For more information about the tabs and subtab options in the Content Engine GUI, see "Content Engine GUI Menu Options."
Content Engine GUI Buttons
Table 2-12 describes the main buttons of the Content Engine GUI and their associated function.
Navigating Around the Content Engine GUI
The following are some navigational tips when using the Content Engine GUI.
•
Figure 2-16 Content Engine GUI Navigation Bar
•
•
Figure 2-17 Content Engine GUI Tabs and Subtabs
Note
Working with the ACNS Software CLI
This section provides an overview of how to work with the ACNS software CLI. For more detailed information, refer to the Cisco ACNS Software Command Reference, Release 5.1.
The CLI for the ACNS software is similar to the CLI for Cisco IOS software. Like Cisco IOS software, the ACNS software CLI is organized into different command modes, and each mode provides access to a specific set of commands.
Starting the ACNS Software CLI
To start the ACNS software CLI on the Content Engine, follow these steps:
Step 1
Microsoft Telnet> open IP_address_of_Content_EngineStep 2
Figure 2-18 Example of the Telnet Session Login Window
Step 3
•
ContentEngine#•
ContentEngine>where ContentEngine is the host name of the Content Engine.
Figure 2-19 shows an example of the system prompt for privileged EXEC mode.
Figure 2-19 CLI System Prompt for Privileged EXEC Mode
Step 4
ACNS Software CLI Command Modes
Table 2-13 describes the different command modes you can work in when using the ACNS software CLI to configure a locally deployed Content Engine. For more detailed information about these modes, refer to the Cisco ACNS Software Command Reference, Release 5.1.
Note
Table 2-13 ACNS Software CLI Command Modes
User EXEC
Used to monitor the operation of the unit (the locally deployed Content Engine) and issue some system commands such as telnet, traceroute, and ping.
If you log in using an account that does not have superuser privileges, the following CLI prompt is displayed:
ContentEngine>
To access user EXEC mode from privileged EXEC mode, enter:
ContentEngine# disable
where ContentEngine is the host name of the Content Engine.
ContentEngine>
Use the exit or end command:
ContentEngine> exit
Privileged EXEC
Used to set up, monitor, and debug the Content Engine, including all commands in user EXEC mode.
From user EXEC mode, enter:
ContentEngine> enableCan also access privileged EXEC mode by logging into the CLI with an account with superuser privileges.1
Use the disable command to return to user EXEC mode.
ContentEngine# disableGlobal configuration
Used to set, view, and test the configuration of ACNS software features for the entire unit.
From privileged EXEC mode, enter:
ContentEngine# configure
ContentEngine(config)#
Use the exit or end command to return to privileged EXEC mode.
Alternatively, press Ctrl-Z simultaneously.
Interface configuration
Used to configure a particular interface on a Content Engine.
From global configuration mode, use the interface global configuration command. For example, enter:
ContentEngine(config)# interface FastEthernet 0/1ContentEngine(config-if)#
ContentEngine(config-if)#
Use the exit command to return to the previous configuration mode.
Use the end command to exit directly to privileged EXEC mode.
HTTPS server configuration
Used to configure the HTTPS server on a Content Engine.
From global configuration mode, enter:
ContentEngine(config)# https server HTTPS_server_name
ContentEngine(config-https)#
Use the exit command to return to the previous configuration mode.
Use the end command to exit directly to privileged EXEC mode.
Standard IP ACL configuration
Used to configure standard IP access control lists (ACLs) on a Content Engine.
From global configuration mode, enter:
ContentEngine(config)# ip access-list standard acl-name | acl-num
ContentEngine(config-std-nacl)#
Use the exit command to return to the previous configuration mode.
Use the end command to exit directly to privileged EXEC mode.
Extended IP ACL configuration
Used to configure extended IP ACLs on a Content Engine.
From global configuration mode, enter:
ContentEngine(config)# ip access-list extended acl-name | acl-numContentEngine(config-ext-nacl)#
Use the exit command to return to the previous configuration mode.
Use the end command to exit directly to privileged EXEC mode.
1 Privileged mode can also be accessed by logging in to the CLI with an account that has superuser privileges (for example, the predefined admin superuser account). predefined admin account .By default, the username is admin and password is default for this predefined admin superuser account.
Online Help and Keyboard Shortcuts
To view the CLI online help, enter a ? as follows:
•
ContentEngine(config-std-nacl)#?delete Delete a conditiondeny Specify packets to rejectexit Exit from this submodeinsert Insert a conditionlist List conditionsMove Move a conditionno Negate a command or set its defaultspermit Specify packets to acceptContentEngine(config-std-nacl)#•
ContentEngine(config)# ip access-list extended ?<100-199> Extended IP access-list numberWORD Access-list name (max 30 characters)•
To view a description of the online help for the ACNS software CLI, enter the help command.
As a shortcut, you can abbreviate commands to the fewest letters that make them unique. For example, the letters sho can be entered for the show command.
Certain EXEC commands display multiple screens with the following prompt at the bottom of the screen:
--More--Press the Spacebar to continue the output, or press Return to display the next line. Press any other key to return to the prompt. Also, at the --More-- prompt, you can enter a ? to display the help message.
Table 2-14 summarizes the keyboard shortcuts.
Table 2-14 Command-Line Processing Keystroke Combinations
Ctrl-A
Jumps to the first character of the command line.
Ctrl-B or the Left Arrow key
Moves the cursor back one character.
Ctrl-C
Escapes and terminates prompts and tasks.
Ctrl-D
Deletes the character at the cursor.
Ctrl-E
Jumps to the end of the current command line.
Ctrl-F or the Right Arrow key1
Moves the cursor forward one character.
Ctrl-K
Deletes from the cursor to the end of the command line.
Ctrl-L
Repeats the current command line on a new line.
Ctrl-N or the Down Arrow key1
Enters the next command line in the history buffer.
Ctrl-P or the Up Arrow key1
Enters the previous command line in the history buffer.
Ctrl-T
Transposes the character at the cursor with the character to the left of the cursor.
Ctrl-U; Ctrl-X
Deletes from the cursor to the beginning of the command line.
Ctrl-W
Deletes the last word typed.
Esc-B
Moves the cursor back one word.
Esc-D
Deletes from the cursor to the end of the word.
Esc-F
Moves the cursor forward one word.
Delete key or Backspace key
Erases a mistake when entering a command; reenter the command after using this key.
1 The arrow keys function only on ANSI-compatible terminals such as VT100s.
ACNS Software Device Mode
The ACNS software device mode determines whether the ACNS network device is functioning as a Content Engine, Content Distribution Manager, Content Router, or IP/TV Program Manager. The commands available from a specific CLI mode are determined by the ACNS software device mode in effect.
Tip
Use the device mode global configuration command to change the current device mode to another configuration. For more information about the device mode command, refer to the Cisco ACNS Software Command Reference, Release 5.1.
Using Secure Shell Version 1 Support for Login
Secure Shell (SSH) enables login access to the Content Engine through a secure and encrypted channel. SSH consists of a server and a client program. Like Telnet, you can use the client program to remotely log on to a machine that is running the SSH server, but unlike Telnet, messages transported between the client and the server are encrypted. The functionality of SSH includes user authentication, message encryption, and message authentication.
Before you enable the sshd command, use the ssh-key-generate command to generate a private and a public host key, which the client programs use to verify the server's identity.
When a user runs an SSH client and logs in to the Content Engine, the public key for the SSH daemon running on the Content Engine is recorded in the client machine known_hosts file in the user's home directory. If the Content Engine administrator subsequently regenerates the host key by issuing the ssh-key-generate command, the user must delete the old public key entry associated with the Content Engine in the known_hosts file before running the SSH client program to log in to the Content Engine. When the user runs the SSH client program after deleting the old entry, the known_hosts file is updated with the new SSH public key for the Content Engine.
Note
This example generates an SSH public key and then enables the SSH service.
Console(config)# ssh-key-generateSsh host key generated successfullySaving the host key to box ...Host key saved successfullyConsole(config)# sshd enableStarting ssh daemon ...Ssh daemon started successfully
