Cisco ACNS キャッシング/ストリーミング コンフィギュレーション ガイド
基本概念について
基本概念について
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

基本概念について

ACNS ソフトウェアのキャッシングの基本概念

キャッシングに関する用語

キャッシングとは

キャッシング可能なコンテンツ

ネットワーク プロトコルとキャッシング

HTTP およびキャッシング

HTTPS およびキャッシング

FTP およびキャッシング

TFTP およびキャッシング

DNS キャッシング

透過キャッシング階層

高度な透過キャッシング サービス

ACNS ストリーミング メディアの基本概念

ストリーミング メディア サービスとは

ストリーミング メディアのキャッシングとは

サポートされるストリーミング メディア プロトコル

WMT ストリーミングとは

WMT キャッシングの概要

WMT キャッシング プロキシの概要

WMT キャッシング プロキシの機能

RTSP とは

RealProxy ストリーミング ソリューションとは

RealProxy ソフトウェアの設定

RealProxy 統計情報

IP マルチキャスティングの基本概念

安全に問題のあるサービス

サーバとクライアント間のファイルのコピー

限定スコープ アドレス

ソース固有マルチキャスト アドレス

GLOP アドレス

レイヤ 2 マルチキャスト アドレス

ユーザ アカウントと特権プロファイル

ユーザ アカウントの管理

ContentEngine GUI を使用したユーザ アカウントの管理

CLI コマンドを使用したユーザ アカウントの管理

CLI コマンドを使用したユーザ アカウントの管理の例

ContentEngine の管理機能

Content Engine 上での設定のタイプ

ContentEngine のリブート

ContentEngine の取り外しまたは交換

ContentEngine GUI の操作

ContentEngine GUI へのアクセスのイネーブル化

ContentEngine GUI への保護されたアクセスのイネーブル化

ContentEngine GUI への保護されていないアクセスのイネーブル化

ContentEngine GUI へのアクセス

ContentEngine GUI へのログイン

ContentEngine GUI のログアウト

ContentEngine GUI のディセーブル化

ContentEngine GUI とは

ContentEngine GUI のタブ

ContentEngine GUI のボタン

ContentEngine GUI のナビゲーション

ACNS ソフトウェアの CLI の操作

ACNS ソフトウェアの CLI の開始

ACNS ソフトウェアの CLI コマンド モード

オンライン ヘルプとキーボードのショートカット

ACNS ソフトウェアのデバイス モード

ログインに対するセキュア シェル バージョン 1 のサポート

基本概念について

この章では、キャッシングおよびストリーミング用に Content Engine をローカル側で設定する前に、理解しておく重要な基本概念の概要を説明します。

この章の構成は、次のとおりです。

「ACNS ソフトウェアのキャッシングの基本概念」

「ACNS ストリーミング メディアの基本概念」

「ユーザ アカウントと特権プロファイル」

「Content Engine の管理機能」

「Content Engine GUI の操作」

「ACNS ソフトウェアの CLI の操作」

ACNS ソフトウェアのキャッシングの基本概念

この項では、ACNS ソフトウェア キャッシングに関する次の基本概念を説明します。

キャッシングに関する用語

キャッシングとは

キャッシング可能なコンテンツ

ネットワーク プロトコルとキャッシング

透過キャッシング階層

高度な透過キャッシング サービス

キャッシングに関する用語

表 2-1 では、キャッシングで使用される基本的な用語を説明します。

 

表 2-1 キャッシングに関する用語

用語
定義

オンデマンド コンテンツ

ユーザ要求によって取得されるコンテンツ。

クライアント

コンテンツまたは情報を要求するデバイス。

要求

コンテンツを取得するためのデバイス(クライアント)からの通信。

Web クライアント

Web ブラウザを使用してコンテンツを要求する(たとえば、オリジン Web サーバから Web オブジェクトを要求する)エンド ユーザ。 Web ユーザまたはエンド ユーザとも呼ばれます。

オリジン Web サーバ

Web クライアントが要求したオブジェクトを保存するオリジン サーバ。

テキスト オブジェクト

HTML ページを意味する用語。

バイナリ オブジェクト

テキスト オプション以外のすべての Web オブジェクトのタイプ(たとえば、GIF、JPEG)を意味する用語。

Web オブジェクト

Web 経由で転送できるオブジェクト(たとえば、Web ページ)。 テキスト オブジェクトおよびバイナリ オブジェクト全般を意味する用語。

キャッシング

以降の検索に備えて Web オブジェクトを保存する機能。

キャッシュ ヒット

要求されたコンテンツ(Web オブジェクト)が Content Engine のキャッシュにある状態。

キャッシュ ミス

要求されたコンテンツ(Web オブジェクト)が Content Engine のキャッシュにない状態。

明示プロキシ

エンド ユーザ(Web クライアント)が開始したすべての要求に対して、クライアントのブラウザは Content Engine の特定 IP アドレスに設定されている。 非透過キャッシングまたはプロキシスタイル キャッシングとも呼ばれます。

透過エッジ代行受信

WCCP を使用したエッジ キャッシング。 WCCP は、転送メカニズムの役目をします。 WCCP 対応ルータまたはスイッチは、オリジン サーバがユーザの要求を受信する前にその要求を代行受信し、ローカル キャッシング デバイスの役目をする WCCP 対応 Content Engine にその要求を転送します。

キャッシングとは

キャッシングとは、Web ページなどの Web オブジェクトを以降の検索に備えて保存しておく機能を指します。 一般に Web クライアントは、Web ブラウザを使用して Web サーバにオブジェクトを要求します(図 2-1 を参照)。

図 2-1 基本的な Web 要求

 

それぞれの Web オブジェクトには、独自に定義されたアドレス(URL)があり、このアドレスによって Web ブラウザは、Web オブジェクトを検索できます。この検索の際には、サーバ アドレスは、DNS 空間に存在するものと想定されます。 URL アドレスの基本コンポーネントを図 2-2 に示します。

図 2-2 URL アドレスの基本コンポーネント

 

Web ブラウザを使用してキャッシングを実行するには、Web ブラウザ側にローカル キャッシュを用意し、Web 閲覧プロセス中に迅速にアクセスできるように、ユーザが最近閲覧したページをブラウザのキャッシュ内に保存するようにセットアップします(図 2-3 を参照)。 たとえば、ブラウザ上で Back ボタンをクリックしたときには、ローカル キャッシングが利用され、直前に表示されていたページが迅速に表示されます。

図 2-3 ローカルでのブラウザ キャッシュの設定

 

ローカルでキャッシュを使用しても、キャッシュ本来の利点が得られますが、Content Engine を使用すると、特別のキャッシング機能を多くのユーザが利用できます。

Content Engine が以降の検索に備えて大量の情報を保存しておく機能には、ユーザおよびインターネット トラフィックの両方に対して、全般的に次のような重要な利点があります。

1. Web オブジェクトをユーザに近い場所に保存しておくため、同じコンテンツをネットワーク経由でアクセスする必要がなくなり、ネットワークの輻輳が減少する。

2. Web ページはローカルに、またはユーザに近い場所に保存されるので、Web ページの表示に必要な時間が短くなる。

3. サーバが最近配信したコンテンツを再配信する必要がなくなるため、オリジン Web サーバの負荷が減少する。

このシナリオでは、あるユーザが Web オブジェクトを Web サーバから取得しようとします。 ブラウザは、ローカルのキャッシュ内にページを保存してないので、Web 要求の際にプロキシ(代理)の役割をする Content Engine を使用して、オリジン Web サーバに要求を送ります。 この配置では、Content Engine は Web クライアントのプロキシの役割をし、最初は§Content Engine のキャッシュ内に保存しているオブジェクト中から、このWeb 要求を満たそうとします。

キャッシング可能なコンテンツ

キャッシング可能なコンテンツは、一般的にスタティック アプリケーション データであり、 表 2-2 で説明されているようなファイル タイプ、およびファイル拡張子に関連付けることができます。

 

表 2-2 キャッシング可能なコンテンツのファイル タイプとファイル拡張子

ファイル タイプ
ファイル拡張子

グラフィック ファイル

gif、jpeg、bmp

圧縮ファイル

zip、gz、tar

文書ファイル

text、txt、pdf

マルチメディア ファイル

avi、mov、mpeg、wav

ネットワーク プロトコルとキャッシング

Web ブラウザと Web サーバ間の対話は、既存の標準アプリケーション層インターネット プロトコルを使用し、そのプロトコルには HTTP、Microsoft Media Server(MMS)、および Real-Time Streaming Protocol(RTSP)などがあります。 Content Engine は、これらのすべての Web アクセス プロトコルを使用して、Web オブジェクトを Web クライアントに配信できる必要があります。

表 2-3 では、ACNS 5.1 ソフトウェアを稼働している Content Engine が、コンテンツを Web クライアントに配信する際に使用されるネットワーク プロトコルをリストしています。

表 2-3 ネットワーク プロトコルとキャッシング

ネットワーク
プロトコル
詳細

HTTP

「HTTP およびキャッシング」

HTTPS

「HTTPS およびキャッシング」

FTP

「FTP およびキャッシング」

TFTP

「TFTP およびキャッシング」

MMS

Windows Media Technologies(WMT)は、Microsoft Media Server(MMS)と呼ばれるアプリケーション レベルのプロトコルを使用して、インターネット上に Active Streaming Format(ASF)ファイルを送信します。 WMT の詳細は、「WMT ストリーミングとは」を参照してください。

RTSP

Real-Time Streaming Protocol(RTSP)は、ストリーミング メディア プロトコルの 1 つで、IP ネットワークを介して双方向にストリーミング メディアを配信する際に使用されます。 RTSP の詳細は、「RTSP とは」を参照してください。

HTTP およびキャッシング

HTTP は、クライアントとサーバ間でメッセージを送受信する際に使用される要求/応答プロトコルです。HTTP は、Web サーバ アドレスの定義、およびクライアントが検索するオブジェクトを定義する目的で URL を使用します。 要求/応答プロセスで仲介者の役割を担っている Content Engine がある場合、このプロセス中でキャッシングが行われます。

Content Engine は、次の状況で仲介者の役割を担います。

透過キャッシング エージェントとして、WCCP 対応ルータ、またはレイヤ 4 スイッチのいずれかを経由して送信されるトラフィックを代行受信する場合

直接プロキシ(非透過キャッシング)として、要求 Web クライアントの代わりに動作する場合

リバース プロキシ キャッシング エージェントとして、オリジン Web サーバの代わりのプロキシとして動作する場合

HTTP メッセージは、HTTP ヘッダとエンティティ本体で構成されています。HTTP メッセージには HTTP 要求と HTTP 応答の 2 つのタイプがあり、クライアントとサーバ間の対話に直接関係しています。

HTTP 要求

HTTP 応答

HTTP 要求

HTTP 要求は、ヘッダ フィールドとエンティティ本体で構成されています。ヘッダ フィールドでは、Request 行は、要求された URL などの、サーバからの要求項目から構成されています。General ヘッダは、コンテンツの形式などの要求の種類を限定します。Request ヘッダは、許可クレデンシャルに関連しています。Entity ヘッダは、要求に含まれるデータの記述に関係しています。特に Request ヘッダは、許可クレデンシャル情報を提供する際に重要な役割をもちます。この情報は、HTTP 要求が出されたときに、キャッシングを許すかどうかを管理します。

HTTP 要求認証の場合は、サーバは、サーバが要求に答える前に、クライアントがユーザ名とパスワードを送信するように要求できます。 ユーザ名とパスワードによる認証方式では、特定の Web サイトを閲覧するユーザを簡単にトラッキングしたり、情報を制限したりできます。

HTTP メッセージ内の認証要求を処理するために、Content Engine が認証サーバを使用する方法については、「HTTP 要求認証の概要」を参照してください。

HTTP 応答

HTTP 応答の構造は、HTTP 要求の構造と類似しています。 両者の主な違いは、HTTP 応答の Header フィールドに Status 行があることです。この Status 行には、応答コード、および使用されるコードを説明する記述があります。たとえば OK 200 ステータス コードは、正常な応答を示すときに使用され、404 Not Found ステータス コードは、サーバまたはリソースが存在しないときに必ず送信されます。 HTTP 応答ステータス コードに対する応答カテゴリを、次に示します。

1xx-情報連絡

2xx-正常

3xx -リダイレクション

4xx -クライアント エラー

5xx-サーバ エラー

HTTPS およびキャッシング

HTTPS を使用して中央側に配置した HTTPS サーバ上のコンテンツにアクセスする営業所が数多くあるカスタマーの場合、HTTPS キャッシング ソリューションが重要になります。 これらの営業所と中央側に配置された HTTP サーバの間は、WAN 接続であるため、このカスタマーにとっては、WAN トラフィック量と遅延が重大な問題となります。 そのため、カスタマーは、WAN トラフィックと遅延を少なくするために、各営業所に配置できる HTTPS キャッシング ソリューションに関心をもちます。

ACNS 5.1 ソフトウェアは、そのような環境に理想的な HTTPS キャッシング ソリューションを提供します。このソリューションを使用して、次のように Content Engine をキャッシング HTTPS プロキシとして、カスタマーの営業所に配置できます。

1. ACNS 管理者は、各営業所の Content Engine 上で HTTPS キャッシングを使用できます。 HTTPS プロキシ モードにすると、HTTPS プロキシ サーバを使用できるように設定されているContent Engine は、Web クライアントによって送信される HTTPS 要求を処理できます。

2. 管理者は、企業の中央側に配置された HTTPS サーバ(HTTPS サイト)の適切な証明書を、各営業所の Content Engine にインポートします。


ヒント デジタル証明書とは、HTTPS クライアントに対して Content Engine が自身をオリジン HTTPS サーバとして提示するクレデンシャル(信用証明書)のことです。 Content Engine は、HTTPS サーバに要求している HTTPS クライアントにそのデジタル証明書を提示します。

3. 管理者は、特定の HTTPS サイト(カスタマーの中央側に配置された HTTPS サーバ)をキャッシュできるように、各営業所の Content Engine を設定します。

4. このようにして、営業所の Content Engine が HTTPS キャッシング エンジンとして設定されるので、Content Engine は、WCCP によって Content Engine に転送されるすべての HTTPS トラフィックを終端し、キャッシングします。 その他のすべての透過的に転送された HTTPS トラフィックは、バイパスされます。 HTTPS トンネリング トラフィックは、HTTPS トンネリングによって処理されます。


) また、Content Engine は、HTTPS トンネリングを経由した HTTPS キャッシング(HTTPS over HTTP)もサポートします。 ACNS 5.1 ソフトウェアでは、HTTPSトンネリングを使用して HTTPSトンネリング トラフィックを処理します。


SSL を使用した透過 HTTPS キャッシング

SSL を使用した透過 HTTPSキャッシングは、次のように動作します。

1. Content Engine は、HTTPS サーバとして設定され、WCCP 対応ルータ経由で転送された HTTPS 要求を受信します。

2. Content Engine は、SSL 証明書(オリジン サーバから取得した)を要求クライアントに戻して、SSL 接続を折衝します。

3. クライアントは、折衝された SSL 接続内で HTTPS 要求を送信します。

4. Content Engine は、その要求をチェックし、キャッシュを調べ、通常の HTTP 要求処理を実行します。

5. Content Engine は、ローカル ストレージから要求を実行できる場合(キャッシュ ヒット)、SSL 接続を使用して、要求されたコンテンツをクライアントに送ります。

6. Content Engine が、ローカル ストレージから要求を実行できない場合(キャッシュ ミス)、オリジン サーバへの接続を開始し、SSL 接続を使って、要求されたコンテンツを取得します。

7. Content Engine は、要求されたコンテンツをキャッシュし(可能な場合)、さらに折衝された SSL 接続を使用して、コピーを要求クライアントに送信します。


) 要求された特定のコンテンツをキャッシングする場合、それらのサイトの証明書およびキーを Content Engine にインポートし、それらのサイトをキャッシングするように Content Engine に指示する必要があります。


Content Engine を HTTPS プロキシ キャッシングに設定する方法については、「HTTPS 関連パラメータの設定」を参照してください。

FTP およびキャッシング

ACNS 5.x ソフトウェアは、URL で FTP プロトコルが指定されている場合(たとえば、
ftp://ftp.mycompany.com/ftpdir/ftp_fil
e )、プロキシモードの HTTP 要求を使用した、FTP URL クライアント要求の代理処理およびキャッシングをサポートしています。これらの要求では、クライアントは、Content Engine とのトランスポート プロトコルとして HTTP を使用します。一方、Content Engine は、FTP サーバとのトランスポート プロトコルとして FTP を使用します。

ACNS ソフトウェア リリース 5.1は、HTTP を使用して送信されるクライアントからの FTP 要求だけでなく、ネイティブ FTP プロトコルで送信されるクライアントからの FTP 要求もサポートしています。

FTP over HTTP:エンド ユーザは、Web ブラウザを使用してリモート FTP サーバ上のファイルにアクセスできます(ファイルの送受信)。 たとえば、次は、エンド ユーザが FTP サーバ上のパブリック ファイルにアクセスできる FTP over HTTP 要求の例を示します。

ftp://ftp.funet.fi/pub/cbm/crossplatform/converters/unix/
 

ネイティブ FTP キャッシング:ネイティブ FTP プロトコルで送信されるクライアントからの FTP要求をサポートしています。 一般的に FTP を使用すると、アプリケーション ソフトウェアの配信に役立つので、ネイティブ FTP が FTP プロキシ プロトコル要求を拡張できるようにする一方で、これらの要求のキャッシンッグ サービスを行います。

FTP プロキシとして動作している Content Engine は、ファイルおよびディレクトリのフェッチに対して、パッシブ モードとアクティブ モードをサポートしています。 デフォルトの FTP モードは、パッシブ モードです。 FTP サーバでパッシブ モードがサポートされていない場合には、Content Engine は自動的にアクティブ モードに変わります。 ftp proxy active-mode enable コマンドが設定されている場合、FTP はアクティブ モードでファイルのフェッチを試みます。 アクティブ モードで失敗した場合、パッシブ モードでファイルのフェッチを再度試みます。

Content Engine は、ファイルが HTTP またはネイティブ FTP を使用してトランスポートされたかどうかに関係なく、キャッシュ ファイル システム(cfs)のディスク パーティションに、FTP ファイル オブジェクトとディレクトリ リストをキャッシングします。 Content Engine は、HTTPを使用する場合、ファイルをダウンロードするためにクライアント ユーザがポイントしてクリックするリンクを使用して、FTP サーバからの通常のディレクトリ リストを HTML に変換します。

Content Engine が Web クライアントから FTP 要求を受信すると、まず、キャッシュを調べます。オブジェクトがキャッシュ内に無い場合、アップストリーム FTP プロキシ サーバ(設定されている場合)から、またはオリジン FTP サーバから直接、オブジェクトを取得します。

FTP プロキシは、認証されている FTP 要求だけでなく、匿名 FTP 要求もサポートします。認証には base64 エンコーディングだけがサポートされます。 FTP プロキシは、RFC 1738 で定義されているすべての FTP URL 方式を受け入れます。 ftp://user@site/dir/file 形式の URL の場合、プロキシは認証の失敗応答を戻し、ブラウザは、ユーザがログイン情報を入力するポップアップ ウィンドウを表示します。

FTP プロキシは、一般的に使用される MIME タイプをサポートし、対応するヘッダーをクライアントに接続します。また、FTP プロキシは、適切な転送タイプ(バイナリまたは ASCII)を選択して、ブラウザが設定されたアプリケーションを使って FTP ファイルをブラウザで開けるようにします。 ファイル タイプが不明な場合、FTP プロキシはバイナリ転送をデフォルトとして使用し、ダウンロード ファイルを開かずに保存するようにブラウザに指示します。 FTP サーバが既知の形式のディレクトリ リストを使用して応答した場合、FTP プロキシは、形式設定されたディレクトリ リストをクライアントに戻します。 形式設定されたディレクトリ リストには、ファイルまたはディレクトリに関する詳細情報が含まれ、ユーザがダウンロードの転送タイプを選択するのに利用できます。

Content Engine が FTP トラフィックをキャッシュに保存するのは、クライアントが、FTP 要求のプロキシ サーバとして Content Engine を使用する場合だけです。 Web クライアントから FTP サーバに直接送信された FTP トラフィックが、透過的に Content Engine によって代行受信された場合、それらのトラフィックはすべて、非 HTTP トラフィックとして扱われます。

FTP プロキシは、最高 8 つの着信プロキシ ポートをサポートします。 これらの着信プロキシ ポートは、透過モード サービスと共用でき、Content Engine がサポートしているその他のプロキシ モード プロトコル(たとえば、HTTP や HTTPS)とも共用できます。 プロキシ モードでは、Content Engine は、FTP プロキシ用に設定されたポート上だけで FTP 要求を受け入れ、処理します。 他のプロキシ モード ポート上の FTP 要求はすべて、Content Engine 上のエラー処理設定に従って拒否されます。

Content Engine は、サーバ名、ドメイン名、サーバの IP アドレスとポート、クライアントの IP アドレス、および URL に基づいて、FTP 要求に Rules Template を適用できます。

Content Engine は、Squid 構文に従って、FTP トランザクションをトランザクション ログに記録します。 URL トラッキングが使用可能である場合、Content Engine は FTP トランザクション情報を syslog に記録します。 syslog エントリには、プレフィックス <ftp> が付きます。


) Content Engine を FTP プロキシ キャッシングに設定する方法については、「FTP 接続の設定」を参照してください。FTP プロキシの設定例については、「FTP プロキシの設定例」を参照してください。


TFTP およびキャッシング

ACNS ソフトウェア リリース 5.1 には、TFTP(Trivial File Transfer Protocol)ゲートウェイ機能が追加されました。 この機能により、Content Engine は、ネイティブ TFTP プロトコルを使用するネットワーキング デバイスによって要求されるコンテンツ ファイルを配信できるようになります。 これによって、Content Engine は、TFTP to HTTP トランザクションまたは FTP トランザクションを実行できるようになるため、システム管理者は専用 TFTP サーバを設定および管理して、TFTP 要求を処理する必要がなくなります。 この機能により、Content Engine はフロント エンドでクライアントからネイティブ TFTP 要求を受け入れ、バック エンドで HTTP または FTP プロトコルを使用してその要求を処理します。このため、この機能は TFTP ゲートウェイと呼ばれます。

コンテンツ ファイルには、ルータ ソフトウェア イメージ、ルータ構成、セット トップ ボックス イメージ、IP 電話の構成ファイルなどが含まれています。 要求されたファイルが Content Engine に保存されていない場合、Content Engine はオリジン サーバからリアルタイムでそのファイルをキャッシュします。 ACNS キャッシング システムは、デバイスの代わりにインターネットからそのファイルを取得し、そのファイルをデバイスに転送します。 それ以降、デバイスが同じファイルを要求する場合、そのファイルは Content Engine キャッシュから転送されます。


) Content Engine は、透過的に代理受信された TFTP 要求をサポートしていません。 Content Engine にアドレス設定される各 TFTP サーバ要求の宛先アドレスは、Content Engine の IP アドレスにする必要があります。


TFTP サーバおよびゲートウェイの動作

Content Engine 上で TFTP がイネーブルになり、クライアントが、ファイルの TFTP 要求を送信すると、次のイベントが発生します。

1. Content Engine 上の TFTP サーバは、認証のために TFTP アプリケーションに割り当てられるアクセス コントロール リストをチェックします。

2. 要求が認証されると、TFTP サーバは、コンテンツ ファイルの TFTP 要求に指定されたディレクトリをチェックします。 その要求にディレクトリ パスがない場合、サーバは、ファイルのデフォルト ローカル ディレクトリを検索します。

3. 要求されたファイルがローカル ディレクトリにない場合、Content Engine 上の TFTP サーバ モジュールは、HTTP または FTP URL を作成して、それをキャッシング アプリケーションに送信します。

4. キャッシング アプリケーションは、要求されたファイルを最初にキャッシング ファイル システム ディレクトリ(cfs)、次に事前配信されたコンテンツ ディレクトリ(cdnfs)の中で検索します。 ファイルが見つかった場合、Content Engine 上の TFTP サーバにそのファイルが送信されます。

5. 要求されたファイルがみつからなかった場合、キャッシング アプリケーションは、URL で指定されたサーバに要求して、コンテンツをキャッシュします。

6. その後、キャッシュされたファイルは、Content Engine 上の TFTP サーバに送信され、TFT サーバは、ファイルを TFTP クライアントに送ります。 ファイルが見つからなかった場合は、「File not found(ファイルが見つかりません)」メッセージがクライアントに送信されます。


) ネイティブ TFTP キャッシングをサポートできるように、Content Engine を設定する方法については、「TFTP サーバおよびゲートウェイの設定」を参照してください。


DNS キャッシング

ローカル側に配置する Content Engine 上の DNS(ドメイン ネーム システム)をイネーブルにしている場合は、Content Engine は、最近実行された DNS クエリーの結果をキャッシング以降の同じクエリーを迅速に解決できるようにします。このキャッシュ済みの情報は、クライアントの要求が以降にあるときに再度利用されます。 DNS 情報を保存し、その情報を要求するクライアントに配信できる機能をもつことにより、Content Engine は DNS キャッシング サーバにもなります。 DNS キャッシング用に Content Engine を設定する方法については、「インターフェイスおよびコンテンツ サービスの帯域幅の設定」を参照してください。


) ACNS 5.1 ソフトウェア リリースの新機能には、WCCP を使用して DNS 要求を透過的に代行受信できることがあります。 このトピックの詳細は、「DNS WCCP 透過代行受信の概要」を参照してください。


透過キャッシング階層

Cisco Content Engine は、クライアントおよびネットワーク オペレーションに対して透過的にできるので、ユーザは、Content Engine を階層的に複数のネットワーク ロケーションに容易に配置できます。 たとえば、ISP が、インターネットはアクセスが集中するメイン ポイントに Content Engine を配置すると、要求されたコンテンツがインターネットを経由することなく、このメイン ポイントから得られるので、すべての Point of Presence(POP)が利益を受けます(図 2-4 を参照)。

図 2-4 ISP 配置での透過キャッシング階層

 

クライアントからの要求は Content Engine に着信し、その Content Engine のストレージから要求に応答されます。 特定のクライアント グループに対してサービスを改善するために、ISP は各 POPに Content Engine(Content Engine B および C)を配置できます。 この場合、クライアントがインターネットにアクセスすると、要求はまず、POP の Content Engine に宛先変更されます。 この POP Content Engine が、ローカル ストレージから要求に応じられない場合、エンド サーバに通常の Web 要求を行います。

この要求は、アップストリームに送信され、インターネットのメイン アクセス ポイントにある Content Engine(Content Engine A)に宛先変更されます。 要求がこの Content Engine で満たされると、インターネットのメイン アクセス リンク上のトラフィックは回避され、オリジン Web サーバへの要求が減少し、クライアントへのネットワーク応答時間が短くなります。

企業ネットワークでも、同じようにこの階層化透過アーキテクチャが適用できます(図 2-5 を参照)。

図 2-5 エンタープライズ配置での透過キャッシングの階層

 

高度な透過キャッシング サービス

表 2-4 で示すように、Cisco Content Engine は、高度な透過キャッシング技術(サービス)を提供します。これには、いくつかの大きな利点があります。

 

表 2-4 高度な透過キャッシング技術

技術サービス
利点

過負荷バイパス

トラフィック負荷が Content Engine の容量を超えたときに、Content Engine がボトルネックになるのを防ぎます。

ダイナミック クライアント バイパス

選択的にクライアントをオリジン Web サーバに直接接続させることにより、ソース IP 認証問題の発生を防止します。

WCCP フロー保護

Content Engine をクラスタに追加、またはクラスタから除去することにより、WCCP クラスタ負荷分散が変化するときに、既存のフローがとぎれるのを防止します。

WCCP スロー スタート

新しい Content Engine が重い負荷のクラスタに追加されるときに、クラスタが不安定になるのを防ぎます。

Rules Template

キャッシング ポリシーまたはルールの柔軟な作成を可能にします。たとえば、「キャッシュなし」ポリシー、リフレッシュ ポリシー、アップストリーム プロキシ選択ルール、および URL 再書き込みルールなどです。

これらの機能の詳細は、「拡張透過キャッシング機能」を参照してください。

ACNS ストリーミング メディアの基本概念

この項では、Content Engine 上でWMT ストリーミング メディア サービスをサポートする方法を説明します。ここで説明する内容は、次のとおりです。

ストリーミング メディア サービスとは

ストリーミング メディアのキャッシングとは

WMT ストリーミングとは

RTSP とは

「IP マルチキャスティングの基本概念」


) この章で使用される CLI コマンドの構文と使用法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


ストリーミング メディア サービスとは

ストリーミングとは、すべてのメディア パケットを受信し終わる前に、コンテンツにアクセスまたはコンテンツを表示できる技術です。これに対し、キャッシングの場合、コンテンツにアクセスする前にコンテンツ全体を受信する必要があります。 ビデオ オンデマンド(VOD)など、ライブ コンテンツまたはオンデマンド コンテンツとして、ストリーミング メディアを配信できます。 Cisco ACNS ソフトウェアは、Cisco Streaming Engine、RealNetworks RealMedia、Microsoft WMT、Apple QuickTime などの各種のストリーミング メディア サービスをサポートしています。

ストリーミング メディアのキャッシングとは

図 2-6 で示すように、ストリーミング メディア ファイルはネットワークからユーザに送信されるファイルで、ユーザは、そのファイルを受信しながらメディア プレーヤー上で再生します。ストリーミング メディア ファイルは、データ パケットの連続ストリームとしてリアルタイムに表示されるので、ファイルを表示するための待ち時間を必要としません。このストリーミングにより、再生前に大量の表示用メディア ファイルを保存したり、そのメディア ファイルにストレージ スペースを割り当てたりする必要がありません。

図 2-6 Content Engine を手入力プロキシとして使用するストリーミング メディア モデル

 

図 2-6 では、あるイベント会場の模様が音声と映像の両方で記録されています。この記録は、後で VOD として、またはライブとしてユーザのネットワークに配信される予定です。信号はエンコーダ ソフトウェアとハードウェアでストリーミング可能なファイルに圧縮され、ファイルは、メディア ファイル サーバに送信されます。メディア ファイル サーバは、以降に、パーソナル コンピュータやその他の電子デバイス上に特定のメディア ソフトウェアを備えたユーザに、ライブまたはオンデマンドでそのメディア ファイルを配信します。 図 2-6 では、Content Engine は、その特定ネットワーク内のユーザのキャッシング プロキシになるように手作業で設定されていることに注意してください。

サポートされるストリーミング メディア プロトコル

表 2-5 では、ACNS 5.x ソフトウェアがサポートしている、さまざまなタイプのストリーミング メディア プロトコル、制御チャネル、対応するデータ形式、およびトランスポート タイプをリストしています。

 

表 2-5 ストリーミング メディア プロトコル

ストリーミング メディア
プロトコル
制御チャネル
データ形式
トランスポート プロトコル

Windows Media 形式

TCP

MMS1

UDP2、TCP、HTTP、IP マルチキャスト

RealNetworks メディア形式

TCP

RTSP、PNA3

UDP、TCP、HTTP、IP マルチキャスト

1.MMS = Microsoft Media Server

2.User Datagram Protocol

3.PNA = Progressive Networks Audio

MMS プロトコルは、ストリーミング メディアを配信するために、次の順序で最適の送信法を探します。

User Datagram Protocol(UDP)

Transmission Control Protocol(TCP)

HTTP

UDP は、コネクションレス型のトランスポート層で作動するプロトコルであり、配信が保証されていないので、リアルタイム メディアに対しては理想的なプロトコルです。この特性は、利点ではなく欠点のように聞こえますが、ストリーミング メディアにはきわめて適している特性です。ストリーミング メディアのデータの価値は、たとえ伝送時間が長くなっても完全な形で配信される必要がある、E メールのようなデータとは違って、時間によって制約を受けます。ビデオの 1 フレームが失われるような場合でも、そのフレームは、正規の時間内に到着しなかったので、無価値になります。


) マルチキャスト配信は、ストリーミング メディアを配信する伝送方式で、IP マルチキャスト上のさまざまな受信デバイスが単一のメディア コンテンツ ストリームを Content Engine から同時に受信できます。 このトピックの詳細は、「IP マルチキャスティングの基本概念」を参照してください。


WMT は、インターネット上でデジタル メディア ファイルの作成、配信、および再生を行うための、Microsoft の一連のストリーミング ソリューションです。 このストリーミング メディア プロトコルの詳細は、「WMT ストリーミングとは」を参照してください。 ローカル側に配置する Content Engine での WMT ストリーミングの設定の詳細は、「ストリーミング メディア サービスの設定」を参照してください。

RTSP は、標準のインターネット ストリーミング制御プロトコル(RFC 2326)です。 RTSP は、アプリケーション レベルのプロトコルで、リアルタイム性をもつビデオやオーディオなどのストリーミング メディアの配信を制御します。また、このプロトコルは、キャッシングおよび ACNS 環境でのストリーミングメディア プロトコルとして広く普及しています。Apple QuickTime、RealProxy、および Cisco Streaming Engine はすべて、このストリーミング メディア プロトコルを使用するコンテンツ ディストリビュータです。 このストリーミング プロトコルの詳細は、「RTSP とは」を参照してください。 ローカル側に配置する Content Engine 上で使用する RTSP ストリーミング メディア サービスの設定の詳細は、「ストリーミング メディア サービスの設定」を参照してください。

WMT ストリーミングとは

Microsoft WMT バージョン 9.0 は、インターネット上でデジタル メディア ファイルの作成、配信、および再生を行うための一連のストリーミング ソリューションです。


) ACNS 5.1 ソフトウェアは、WMT Version 9 Windows Media Player、Windows Media Encoder、および Windows Media Server と相互運用できますが、Content Engine は、WMT Version 9 Windows Media Server の完全な機能を提供しないため、このリリースでそのサーバーを完全に置き換えることができません。


ライブの事前配信 Windows Media コンテンツを ACNS ネットワークに配信するには、Content Engine 上に WMT キャッシング プロキシとサーバの機能が必要です。 このマニュアルでは、Content Engine の WMT キャッシング プロキシ機能を中心に説明します。その理由は、WMT サーバ機能は、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』に記述されているからです。


ヒント WMT 製品はライセンス ソフトウェアです。WMT プロキシを使用可能にするには、ライセンス キーワードが必要です。このキーワードは、Content Engine に付属の証明書に表示されています。ACNS 5.1 ソフトウェアをダウンロードする場合は、Cisco.com Web サイトから WMT ライセンスを購入できます。


表 2-6 では、WMT の主要なコンポーネントを説明します。

 

表 2-6 WMT のコンポーネント

WMT コンポーネント
説明

エンド ユーザ アプリケーション(Windows Media Player)

要求したデジタル メディア ファイルを再生するために、ユーザが使用するデスクトップ アプリケーション。

サーバと配信アプリケーション(Windows Media Server)

WMT は、Microsoft Media Server(MMS)と呼ばれるアプリケーション レベルのプロトコルを使用して、インターネット上に Active Streaming Format(ASF)ファイルを送信します。ストリーミング ASF ファイルを指定する URL には、次の例のように、MMS がプロトコルとして使用されます。

mms://servername/filename.asf

WMT キャッシングの概要

繰り返しアクセスされるコンテンツを Web クライアント(エンド ユーザ)の近くにキャッシングしておくと、ストリームの品質が安定し、ネットワーク帯域幅を節約できます。 プロキシとして作動する Content Engine が、Web クライアントにサービスされるコンテンツをオリジン WMT サーバから取得するとき、Content Engine は、キャッシング可能なストリームをメディア ファイル システム(mediafs)上に保存します。プロキシは、ストリームを部分的にキャッシングすることもできます。 キャッシングされてないストリーム部分を Web クライアントが要求すると、プロキシは、後続の部分をオリジン WMT サーバから取得します。 キャッシュ ヒットがある場合であっても、クライアントの使用状況統計を報告するために、オリジン WMT サーバとの接続は保持されます。この統計情報は、オリジン WMT サーバがアカウンティングやその他の目的に使用します。

Content Engine 上で WMT キャッシングをイネーブルにするには、 wmt cache enable グローバル設定コマンドを使用します。ストリーミング メディア オブジェクトの最大オブジェクト サイズを設定するには、 wmt cache max-obj-size コマンドを使用します。この値の範囲は、1 ~ 1,000,000 MB です。デフォルト 値は、1024 MB です。

キャッシュからサービスされたストリームは、新鮮であることが保証されます。これは、Content Engine が、適切なキャッシュ パラメータ設定値を使用して、常にオリジン WMT サーバをチェックしているからです。キャッシュのストレージが限界に達すると、ヒット率を適切に確保するために、適切な置換アルゴリズムを使用して古いオブジェクトが置き換えられます。 キャッシュ パラメータの適切な設定については、「HTTPS 関連パラメータの設定」を参照してください。

プロキシは、認証済みストリームをキャッシングできます。キャッシュ ヒット時には、要求側クライアントの認証クレデンシャルがオリジン サーバに対して再検証された後、コンテンツがサービスされます。

WMT キャッシングは、非透過(手入力)プロキシ モードでも、透過プロキシ モードでもサポートされます。


) キャッシングのサポートには、Moving Picture Experts Group-Audio Layer-3(MP3)、WAV、および MMS を介した AVI ファイルが含まれます。Windows Media Player が要求して、非ストリーミング HTTP サーバが取得した Windows Media コンテンツは、キャッシングされません。ライブ ストリームは、記録もキャッシングもされません。


WMT キャッシング プロキシの概要

WMT キャッシング プロキシとして動作する Content Engine は、基本プロキシ機能をサポートします。すなわち、着信 WMT ストリーミング要求を Web クライアント(エンド ユーザ)から受け入れ、それらのクライアントに代わってオリジン WMT サーバと通信します。 WMT キャッシング プロキシは、MMS プロトコル、および HTTP プロトコルを介してストリーミング要求を受け入れ、処理します。MMS は、WMT がプレーヤーとサーバ間の通信に使用するプロトコルです (図 2-7 を参照)。

図 2-7 従来型 WMT キャッシング プロキシとしての Content Engine

 


) TCP および UDP 上で MMS を使用する場合、キャッシュに保存されたファイルが後の配信時に信頼性のある完全な状態であるように、プロキシは、常に TCP (MMST) を使用してサーバからストリームを取得します。HTTP を使用して要求されたストリームは、HTTP を使用して取得されます。


WMT キャッシングは、透過プロキシ モードでも、非透過(手入力)プロキシ モードでもサポートされます。 また可能であれば、WMT キャッシング プロキシは、ストリーミング コンテンツのキャッシングも行い、オリジン WMT サーバに代わってキャッシュから要求を処理します。

Content Engine は、WMT キャッシング プロキシとして動作し、透過的に代理処理された要求を次のようにして受け入れます。

WCCP または L4 リダイレクト(WCCP 対応ルータまたはレイヤ 4 CCS スイッチからのリダイレクト)を経由

手入力プロキシ要求(Web クライアントがアップストリーム プロキシを使用できるように設定されている場合)

WMT キャッシング プロキシは、ライブ ストリームの分割(つまり、1 つの受信ストリームを分割して、複数のクライアントに提供)、およびマルチキャスティングもサポートします。


ヒント プロキシとして作動する Content Engine と要求側クライアントの間にファイアウォールが置かれている場合は、Content Engine の外部 IP アドレスを設定時に割り当て済みであることを確認してください。


WMT キャッシング プロキシの要件

Content Engine が WMT キャッシング プロキシとして機能するには、次の要件を満たしておく必要があります。

相互運用性:WMT ソフトウェア コンポーネントにとって最も重要な要件です。 WMT キャッシング プロキシは、すべてのバージョンの Microsoft Windows Media Player、Windows Media Server、Windows Media Encoder、およびサードパーティ製 Windows メディアのアプリケーションと問題なく作動する必要があります。

WCCP:透過モードで WMT キャッシングをサポートするには、WCCP が Content Engine 上で作動している必要があります(「ストリーミング メディア サービスの設定」 を参照)。

WMT キャッシング プロキシの機能

この項では、次の WMT キャッシング プロキシ機能の概要を説明します。

可変ビット レートのサポート

ライブ分割

プロキシ認証

WMT ストリーミングのトランザクション ロギング

WMT ストリーミングのエラー ロギング

可変ビット レート

コンテンツ プロバイダーは、異なるビット レートで複数のストリーミング メディア ファイルを作成できます。この理由は、クライアントの接続方式が、モデム、DSL、LAN などのように一様ではなく、個々のクライアントが選択するビット レートでファイルを取り扱えるようにするためです。WMT キャッシング プロキシは、マルチプル ビット レート ファイル、つまり可変ビット レート (VBR)ファイルをキャッシングできます。また、クライアントが指定するビット レートに基づいて、適切なビット ストリームで配信します。可変ビット レート ファイルを作成するもう 1 つの利点は、ストリーミング メディアの配信には URL を 1 つだけ指定すればよいという点です。

要求クライアントに配信できる最高のストリーミング ビット レートを設定するには、 wmt max-bitrate グローバル設定コマンドを使用します。 この値の範囲は、0 ~ 2,147,483,647 Kb/秒です。デフォルト値は 0(ビット レート制限なし)です。

ライブ分割

Content Engine では、ライブ ストリームに対する要求を分割します。つまり、オリジン ストリーミング サーバからの単一ストリームは、その同一ストリームを要求する各クライアントに分割して送信されます(図 2-8 を参照)。 WMT キャッシング対応の Content Engine がプロキシとして作動している場合、クライアントが ASF ファイルを指定せずにサーバ上のパブリッシング ポイントを要求するときは、Content Engine は、エーリアス ファイルを動的に作成します。エーリアス ファイルは、リモート ストリーミング サーバを参照します。 そのリモート ストリーミング サーバに対する以降の要求はすべて、ストリームの分割によって処理されます。

オリジナル ストリームを要求した最初のクライアント(クライアント 1)がネットワークとの接続を解除しても、すべてのクライアントがネットワークとの接続を解除するまでは、プロキシは、他のクライアント(クライアント 2 とクライアント 3)に引き続き送信することに注意してください。

図 2-8 ライブ分割

 

プロキシ(WMT 対応 Content Engine)でのライブ分割は、リモート ストリーミング サーバでの分割よりも優れています。これは、プロキシの方がクライアントに近いので、クライアントとオリジン ストリーミング サーバ間のネットワーク帯域幅使用を相当に節約する可能性があるからです。


) ライブ分割は、さまざまなデータ パケット トランスポート プロトコル(たとえば、HTTP、MMS TCP [MMST]、MMS UDP [MMSU]、および IP マルチキャストなど)でサポートされています。


プロキシ認証

WMT 対応 Content Engine は、オリジン サーバによる基本認証と NTLM 認証の両方をサポートします。 クライアントが、ユーザ認証を必要とするコンテンツを要求する場合、Content Engine は、エージェントとして作動し、クライアントとサーバ間で認証情報を送受信して、クライアントを認証します。クライアントが認証されると、コンテンツは通常どおりにストリーミングされます。キャッシングされたコンテンツと、キャッシングされてない VOD コンテンツの両方に対して、認証が行われます。

プロキシ認証方式は、次の 2 つのタイプがあります。

基本認証:サーバが、エンコードされたユーザ名とパスワードの形式でクライアントの ID を要求する認証方式。認証が失敗すると、その状況がクライアントに通知されます。この場合、クライアントは認証プロセスを再試行するか、接続を解除します。認証が成功すると、ストリーミング メディアがクライアントに送信されます。この認証では、HTTP と MMS の両方に対して、手入力プロキシ モードが透過プロキシ モードと同様にサポートされます。

Windows NTLM 認証:接続ベースで身元証明要求と応答を行う認証方式。 NTML プロトコルがすべての接続を認証するので、プロキシは、オリジン サーバとの新しい接続を任意に開始することはできず、クライアントが開始した接続を再使用する必要があります。

ファイルがキャッシュから提供されるのは、完全なキャッシュ ヒット、つまりファイル全体がディスク上に存在する場合だけです。ファイルが完全なヒットでない場合、ファイル全体が NTLM の場合はオリジン サーバから取り出されます。NTLM 認証は、HTTP と MMS の両方に対して、手動プロキシ モードでも透過プロキシ モードと同様にサポートされます。プロキシは、Digital Rights Management(DRM)で保護されている Windows Media ファイルのキャッシング、および配信をサポートします。 オリジン サーバが使用するアクセス コントロール リスト(ACL)は、自動的にプロキシでも使用されます。


ユーザ ID に基づくフィルタリングもサポートされています。プロキシは、オリジン サーバによる認証だけをサポートします。プロキシによる認証、またはユーザがプロキシを使用するための認証は、今後のリリースでサポートされる予定です。ACNS 5.1 ソフトウェアでは、クライアントに分割されるライブ ストリームも、オリジン サーバで認証されます。


WMT ストリーミングのトランザクション ロギング

WMT ストリーミングに対する Content Engine のロギング形式は、Windows Media サーバのロギング形式、および World Wide Web Consortium(W3C)対応のロギング形式との整合性があります。クライアントがアクセスするどのストリームに対しても、ログ行が書き込まれます。ログの場所は設定できません。これらのログは、FTP を使用してエクスポートできます。トランザクション ログ内のすべてのクライアント情報は、デフォルトでオリジン サーバに送信されます。

WMT ストリーミングのエラー ロギング

WMTストリーミングに対する Content Engine のエラー ログは、アプリケーションによって書き込まれたデバッグ ログで構成されます。エラー ログは、形式も保存場所も syslog と同じです。

RTSP とは

RTSP は、標準のインターネット ストリーミング制御プロトコル(RFC 2326)です。 RTSP は、アプリケーション レベルのプロトコルで、リアルタイム性をもつビデオやオーディオなどのストリーミング メディアの配信を制御します。また、このプロトコルは、キャッシングおよび ACNS 環境でのストリーミングメディア プロトコルとして広く普及しています。Apple QuickTime、RealProxy、および Cisco Streaming Engine はすべて、このストリーミング メディア プロトコルを使用するコンテンツ ディストリビュータです。

Content Engine は、RTSP クライアント ソフトウェアからの従来のプロキシ スタイルの RTSP 要求はもとより、透過的にリダイレクトされる RTSP 要求も受け入れるように設定できます。 Content Engine メディア キャッシュへの RTSP トラフィックのリダイレクトは、Content Engine のGUI または CLI を使用して行います。 RealProxy ソフトウェアは、RealAdministrator GUI を用いて設定され、Content Engine GUI の RealProxy ページからアクセスされます。

Content Engine 上の RTSP エージェントは、標準 RTSP ポート(デフォルトでは 554)上で受信(リスン)し、そのポートを通過する受信 RTSP トラフィックを集中させて取り込み、RTSP 要求に対してルールベースを適用し、URL フィルタリングを行います。ユーザ クライアントが使用するプレーヤー、最終的宛先、メディア ファイル タイプなどを含む受信要求のプロパティに基づいて、RTSP エージェントは要求をコンテンツ ディストリビュータの 1 つに送り込みます。 ローカル側に配置する Content Engine で RTSP ストリーミング メディア サービスを使用可能にする方法の詳細は、「ローカルに配置されている Content Engine への RTSP サービスの設定」を参照してください。

ACNS 5.x ソフトウェアでは、RTSP ストリーミング メディア コンテンツ ディストリビュータとして、RealNetworks RealProxy のみが使用できます。 Content Engine が、ACNS 環境でデバイス グループの一部である場合、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』で説明されているように、RealSubscriber とCisco Streaming Engine サーバは、RTSP コンテンツ ディストリビュータとして動作します。


ヒント RTSP エージェントは常時使用可能の状態であるため、Content Engine の GUI または GLI によって使用不可にすることはできません。


RealProxy ストリーミング ソリューションとは

ACNS 5.x ソフトウェアは、ストリーミング メディア エンジンとして使用されるオプション コンポーネントとして、RealServer バージョン 9 を組み込んでいます。

RealNetworks, Inc. 製の RealProxy ソフトウェアは、ACNS 5.x ソフトウェアのソフトウェア オプションとして組み込まれています。RealProxy ソフトウェアは、Real-Time Streaming Protocol (RTSP) ベースの形式で、ライブ分割(ライブ ストリームの分割同時配信)、およびストリーミング メディア キャッシング(オンデマンド コンテンツ)の両方をサポートします。

RealProxy は、ストリーム分割を実行する際に、RealServer からライブ ストリームを受け入れ、複数の要求側 RealPlayer クライアントにそのストリームを再配信するので、RealServer との複数の接続が不要になります。 RealServer は、RealMedia 送信装置の役目をするように事前設定され、RealProxy は、RealMedia 受信装置の役目をするように事前設定されます。


) RealNetworks, Inc. の RealProxy 製品は、ライセンス ソフトウェアです。RealProxy をアクティブにするには、ライセンス キーワードが必要です。このキーワードは、Content Engine に付属の証明書に表示されています。 ACNS 5.x ソフトウェアをダウンロードする場合は、Cisco.com Web サイトから RealProxy ライセンスを購入できます。


ストリーミング メディア キャッシングは、オンデマンドでコンテンツを配信します。あるユーザが、キャッシングされたストリーミング メディア ファイルを視聴した場合、以後のユーザは、オリジン サーバに接続しなくても、そのファイルのサービスが受けられます。ライブ ブロードキャストは、ファイルではないため、キャッシングはされません。

表 2-7 では、RealProxy ソフトウェアの機能と利点を説明します。

表 2-7 RealProxy の機能と利点

RealProxy の機能
説明
利点

RealPlayer 9.0 用のプロキシ

RealProxy は、クライアントの RealPlayer ユーザに代わってコンテンツを要求する。

同様のコンテンツに対する要求を調整して、ファイアウォール内部でトラフィックを管理する。

エンド ユーザの IP アドレスをマスクする。

ライブ ブロードキャストに対する分割サポート

RealProxyは、複数のクライアント RealPlayer に供給される単一の受信ライブ ブロードキャストを「分割」する。 このライブ分割の詳細は、「ライブ分割」を参照してください。

ライブ イベント中に、コンテンツを単一ストリームにして、受信帯域幅の使用を減らす。

RealSystem G2 および PNA(Progressive Network Audio)コンテンツのキャッシング

RealProxy は、RealNetworks サーバから送信され、代理処理されたすべてのストリーミング メディア トラフィックをキャッシングする。RealProxyは、オリジン RealNetworks サーバに対して認証された後に、ローカル側でコンテンツをキャッシングします。

ネットワーク上の冗長なファイル伝送をなくすことによって、受信帯域幅の使用を大幅に減少させる。

認証およびアカウンティング

RealProxy は、キャッシングされたコンテンツをクライアントに配信する前に、オリジン RealNetworks サーバからすべてのコンテンツ要求の認証を受ける。

Broadcaster の一般使用状況データへのアクセスを保持する。

ユーザを適宜認証する。

エンド ユーザに最新のコンテンツを保証する。

集合帯域幅のしきい値

RealProxy に対する受信帯域幅および発信帯域幅の上限を設定する。

ネットワーク内の集合帯域幅使用を管理し、基幹業務アプリケーションへ過度な負荷がかからないようにする。

プロキシ ルーティング

RealProxy は、ネットワーク内の下位ノードでプロキシを積み重ね、帯域幅を管理できる。ダウンストリーム プロキシに関連する一連の論理的な規則に基づいて、「親」プロキシを選択できます。

ネットワーク管理者が、ルート要求を代理処理し、別の管理レベルを提供できるようにする。


ストリーミング メディア技術の概要については、「ストリーミング メディアのキャッシングとは」を参照してください。


RealProxy ソフトウェアの設定

Content Engine は、RealPlayer クライアント ソフトウェアからの従来型のプロキシ スタイル RTSP 要求だけでなく、透過リダイレクト RTSP 要求も受け入れるように設定できます。 Content Engine メディア キャッシュへの RTSP トラフィックのリダイレクトは、Content Engine CLI を使用してイネーブルにされます。 RealProxy ソフトウェアは、RealAdministrator GUI を用いて設定され、Content Engine 管理 GUI の RealProxy ページからアクセスされます。

設定と統計情報の詳細、および RealProxy 状況の報告は、RealAdministrator GUI から入手可能です。表 2-8 には、RealProxy 関連の CLI コマンドをリストしています。

 

表 2-8 RealProxy 関連の CLI コマンド

コマンド
目的

rtsp port incoming ports

RTSP 要求を受信するポートを指定する。RTSP ゲートウェイはデフォルトでポート 554 トラフィックを受信します。

rtsp L4-switch enable

Cisco CSS 11000 シリーズ スイッチなどのレイヤ 4 スイッチを使用したリダイレクトを使用可能にする。

rtsp proxy media-real enable

RealProxy を使用可能にする。

rtsp ip-address ipaddress

RealProxy の IP アドレスを指定する。

rtsp proxy media-real license-key keyword

RealProxy ソフトウェアのロックを解除するライセンス キーワードを指定する。

wccp rtsp . . .

WCCP RTSP リダイレクトサービス用の Content Engine をルータに登録する。

Content Engine GUIには、図 12-1 で示されている RealProxy ウィンドウがあります。このウィンドウを使用すると、ローカルに配置する Content Engine 上に RealProxy をイネーブルにできます。 RealProxy ソフトウェアがインストール済みで、イネーブルになっている場合には、Content Engine GUI 上の Admin ボタンはアクティブになっています。 Content Engine GUI からこの管理(administration)ページにアクセスするときは、デフォルトのユーザ ID およびパスワードが事前定義としてユーザに与えられます。


ヒント Content Engine 上で RTSP トラフィックを処理するには、disk config EXEC コマンドを使用してmediafs ストレージ用のディスク スペースを確保しておき、mediafs-division グローバル コマンドを使用して、WMT と RealProxy の間で mediafs スペースを(百分率で)分割する必要があります。


rtsp proxy グローバル設定コマンドを使用すると、Layer-4 対応スイッチ、または WCCP 対応ルータのいずれかからリダイレクトされた RTSP トラフィックを受け入れられるように Content Engine を設定するか、または RealProxy クライアントからの RTPS プロキシ スタイル要求を受信するメディア プロキシとして Content Engine を設定できます。 RealPlayer クライアント以外からの RTSP 要求は、指定のオリジン サーバにリダイレクトされます。

wccp rtsp グローバル設定コマンドは、Content Engine を WCCP バージョン 2 対応のルータに登録します。このルータは、RTSP トラフィックを透過的に Content Engine にリダイレクトできます。

rtsp L4-switch グローバル設定コマンドを使用して、レイヤ 4 スイッチを RTSP を使用するメディア キャッシングと相互運用するよう設定できます。

RTSP プロキシ リダイレクタは、ポート 554 のトラフィック、またはこのトラフィックを受信するように設定された他のすべてのポートに到達するトラフィックを受信します。プレーヤーが RealPlayer である場合、プレーヤーは RTSP 要求をリダイレクトして、RealMedia トラフィックに RealProxy を使用します。

RealProxy 統計情報

RealProxy 統計情報を表示するには、次の CLI コマンドを使用します。 show statistics コマンドの出力例については、「RealProxy の例」を参照してください。

ContentEngine# show statistics rtsp proxy media-real requests
ContentEngine# show statistics rtsp proxy media-real savings
 

rtsp proxy 統計情報は、RealPlayer クライアントによって要求されたオブジェクトの内、RTSP を介してトランスポートされたオブジェクトだけに関連したものです。HTTP を介してトランスポートされたオブジェクトは、HTTP 統計情報にカウントされます。 他のクライアントによって要求されたストリーミング オブジェクト、または MMS 以外のプロトコルを介してトランスポートされたストリーミング オブジェクトは、Content Engine をバイパスします。


IP マルチキャスティングの基本概念

マルチキャスト配信は、ストリーミング メディアを配信する伝送方式で、IP マルチキャスト上のさまざまな受信デバイスは、Content Engine から送信される単一のメディア コンテンツ ストリームを同時に受信できます。これにより、ストリームが要求されるたびに単一のストリームを単一のデバイスに送信するのでなく、単一のストリームを複数のデバイスに送信するので、ネットワーク帯域幅の使用量を大幅に節約できます。

このマルチキャスト配信機能を使用するには、同一チャネルからコンテンツを受信するように各デバイスを設定し、これらのデバイスがサブスクライブできる Content Engine 上でマルチキャスト アドレスを設定します。配信側のデバイスは、Content Engine にセットアップされているマルチキャスト アドレスにコンテンツを送信します。このアドレスから、サブスクライブされている受信側のデバイスのすべてにコンテンツが配信されます。

マルチキャストを利用するには、すべてのデバイス(Content Engine、ルータ、およびクライアントを含む)がマルチキャスト対応でなければなりません。このため、マルチキャストは、ルータをマルチキャスト用に設定できるローカル ネットワーク内で最もよく使用されます。インターネット経由でのマルチキャスト配信は、マルチキャストが行われる経路上のすべてのデバイスがマルチキャスト対応になってはじめて可能になります。

IP マルチキャスト アドレスの割り当ては、Internet Assigned Numbers Authority(IANA)によって管理されています。 IANA は、IP マルチキャスト用に IPv4 クラス D アドレス スペースを割り当てています。 このため、すべての IP マルチキャスト グループ アドレスは、 224.0.0.0 ~ 239.255.255.255 の範囲内にあります。 ただし、ソースとグループ アドレスの組み合わせの中には、マルチキャスト用にルートしてはいけないものがあります。 表 2-9 では、マルチキャストで使用できないアドレス範囲、およびその理由を説明します。


) クラス D のアドレス範囲は、IP マルチキャスト トラフィックのグループ アドレス、または宛先アドレス用に限って使用されます。マルチキャスト データグラムに対するソース アドレスは、常にユニキャスト ソース アドレスになります。


 

表 2-9 使用できないマルチキャスト アドレスの割り当て

アドレス範囲
理由

224.0.1.2/32

既知の安全でないサービス アドレス。「安全に問題のあるサービス」を参照してください。

224.0.1.3/32

管理ドメイン内のリソースのディスカバリ用に予約済み。「限定スコープ アドレス」を参照してください。

224.0.1.22/32

既知の安全でないサービス アドレス。

224.0.1.35/32

管理ドメイン内のリソースのディスカバリ用に予約済み。

224.0.1.39/32

管理ドメイン内のリソースのディスカバリ用に予約済み。

224.0.1.40/32

管理ドメイン内のリソースのディスカバリ用に予約済み。

224.0.2.2./32

既知の安全でないサービス アドレス。

224.77.0.0/16

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。「サーバとクライアント間のファイルのコピー」を参照してください。

224.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。「レイヤ 2 マルチキャスト アドレス」を参照してください。

225.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

225.1.2.3/32

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

225.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

226.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

226.77.0.0/16

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

226.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

227.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

227.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

228.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

228.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

229.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

229.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

230.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

230.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

231.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

231.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

232.0.0.0/24

ソース固有マルチキャスト アドレス。「ソース固有マルチキャスト アドレス」を参照してください。

232.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

233.0.0.0/8

GLOP アドレス。「GLOP アドレス」を参照してください。

233.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

233.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

234.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

234.42.42.42/32

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

234.142.142.42/31

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.142.142.44/30

ローカル ネットワーク内でクライアントとサーバ間のファイルの複製に使用。

234.142.142.48/28

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.142.142.64/26

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.142.142.128/29

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.142.142.136/30

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.142.142.140/31

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

234.142.142.142/32

ローカル ネットワーク内でサーバとクライアント間のファイルのコピーに使用。

235.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

235.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

236.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

236.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

236.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

236.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

237.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

237.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

238.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

238.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

239.0.0.0/8

管理ドメイン間で受け渡しできない管理用スコープのアドレス。「限定スコープ アドレス」を参照してください。

239.0.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

239.128.0.0/24

イーサネット マルチキャスト アドレス範囲にマップしていて、LAN スイッチのマッピング テーブルをあふれさせる可能性があるローカル アドレス。

IANA は、これらのアドレスの一部をマルチキャスト アプリケーション用に予約しています。 例として、IP アドレスの 224.0.1.1 は Network Time Protocol(NTP)に予約されています。

IP マルチキャスト用に予約されている IP アドレスは、RFC 1112(Host Extensions for IP Multicasting)に定義されています。予約済み IP マルチキャスト アドレスの詳細については、次の Web サイトをご覧ください。
http://www.iana.org/assignments/multicast-addresses


ヒント RFC と Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)の草案は、すべて IETF Web サイト(http://www.ietf.org)に掲載されています。


安全に問題のあるサービス

マルチキャスト アドレスの 224.0.1.2/32、224.0.1.22/32、および 224.0.2.2/32 の範囲を使用するアプリケーションは、悪意の攻撃に弱いことは周知であり、安全性の点で重大な問題があります。

サーバとクライアント間のファイルのコピー

アプリケーションの中には、サーバとクライアント間のファイルのコピーに使用される場合と、そのほかにもパーソナル コンピュータ間のグループの維持に使用される場合があります。これらのアプリケーションは、ローカル サブネット上または管理ドメイン内で使用されることを想定していますが、デフォルトではソフトウェアが使用するアドレスは、表 2-9 に示されている管理スコープのアドレスの範囲内に含まれていません。

限定スコープ アドレス

限定スコープ アドレスも管理用スコープのアドレスと呼ばれます。これらの限定アドレスは、RFC 2365 の Administratively Scoped IP Multicast の項にローカルまたは組織に限定するとの記載があります。企業や大学などの組織は、ドメインの外部に転送されないローカル マルチキャスト アプリケーションにこの限定スコープ アドレスを使用できます。通常は、このアドレス範囲内のマルチキャスト トラフィックが自律システム(AS; Autonomous System)、またはユーザ定義のドメインの外部に流れないように、フィルタを使用してルータが設定されます。自律システムやドメインの内部では、限定スコープ アドレスの範囲をさらに細分化することによって、ローカル マルチキャスト境界を定義できます。このアドレス スコープと呼ばれる小区分により、こうした小規模なドメイン間でアドレスの再使用が可能になります。

ソース固有マルチキャスト アドレス

アドレスの 232.0.0.0/8 範囲は、ソース固有マルチキャスト(SSM; source-specific multicast)に予約済みです。SSM は、Protocol-Independent Multicast (PIM)プロトコルを拡張したもので、一対多(one-to-many)通信での効果的なデータ配信メカニズムです。

GLOP アドレス

RFC 2770(GLOP Addressing in 233/8)は、すでに予約済みの AS 番号をもつ組織が静的に定義するアドレス用に、233.0.0.0/8 のアドレス範囲を予約済みにするように提案しています。この手法は GLOP アドレス指定と呼ばれます。 ドメインの AS 番号は、233.0.0.0/8 アドレス範囲の 2 番目と 3 番目のオクテットに埋め込まれます。たとえば、AS 番号 62010 は F23A のように 16 進形式で書き込まれます。これを 2 つのオクテット F2 と 3A に分割すると、10 進形式の 242 と 58 が得られます。 これらの値により、サブネット 233.242.58.0/24 が AS 62010 用にグローバルに予約されます。

レイヤ 2 マルチキャスト アドレス

従来、LAN セグメント上のネットワーク インターフェイス カード(NIC; Network Interface Card)は、バーンイン(burned-in)MAC アドレス、またはブロードキャスト MAC アドレスを宛先とするパケットのみを受信できました。IP マルチキャストでは、複数のホストが共通の宛先 MAC アドレスをもつ単一データ ストリームを受信できることが必要です。複数のホストが同じパケットを受信でき、しかも複数のマルチキャスト グループを区別できるように、何らかの手段を考慮する必要がありました。

これを実現する方法の 1 つに、IP マルチキャスト クラス D アドレスを MAC アドレスに直接マップすることがあります。 現在では、NIC はこの方法を使用して、さまざまな MAC アドレス(NIC 固有のユニキャスト アドレス、ブロードキャスト アドレス、およびマルチキャスト アドレスの範囲)を宛先とするパケットを受信できます。

IEEE LAN 仕様では、ブロードキャスト パケットとマルチキャスト パケットの伝送を規定しています。802.3 規格では、最初のオクテットのビット 0 は、ブロードキャストまたはマルチキャストのどちらのフレームであるかを示すために使用されます。図 2-9 では、イーサネット フレーム内にあるブロードキャスト、またはマルチキャストのビットの位置を示しています。

図 2-9 IEEE 802.3 MAC アドレス形式

 

このビットは、フレームの宛先がネットワーク上のホストのグループ、またはすべてのホスト(ブロードキャスト アドレス 0xFFFF.FFFF.FFFF の場合)であることを示します。

IP マルチキャストでは、IP パケットを LAN セグメント上のホストのグループに送信する際にこの機能が使用されます。

イーサネット MAC アドレスのマッピング

IANA は、16 進形式の 01:00:5E から始まるイーサネット MAC アドレスのブロックを所有しています。このブロックの半分は、マルチキャスト アドレス用に割り当てられています。0100.5e00.0000 ~ 0100.5e7f.ffff の範囲が、IP マルチキャスト用に使用できるイーサネット MAC アドレスの範囲です。

この割り当てにより、イーサネット アドレス内の 23 ビットが IP マルチキャスト グループ アドレスに対応します。 IP マルチキャスト グループ アドレスの下位 23 ビットが、イーサネット アドレスに使用されるこれらの 23 ビットにマップされます(図 2-10 を参照)。

図 2-10 IP マルチキャスト アドレスのイーサネット MAC アドレス、または FDDI MAC アドレスへのマッピング

 

IP マルチキャスト アドレスの上位 5 ビットはこのマッピングで除外されるため、得られるアドレスは固有になりません。 実際には、32 の異なるマルチキャスト グループ ID が同じイーサネット アドレスにマップされます(図 2-11 を参照)。ネットワーク管理者は、IP マルチキャスト アドレスを割り当てる際にこの点を考慮する必要があります。 たとえば、224.1.1.1 と 225.1.1.1 は、レイヤ 2 スイッチ上で同じマルチキャスト MAC アドレスにマップされます。 あるユーザがグループ A(224.1.1.1 によって指定)にサブスクライブし、他のユーザがグループ B(225.1.1.1 によって指定)にサブスクライブした場合、両ユーザとも A と B の両方のストリームを受信します。このような状況では、このマルチキャスト配置の有効性は限られたものになります。

図 2-11 MAC アドレスのあいまいさ

 

ユーザ アカウントと特権プロファイル

ACNS ソフトウェアでは、特権プロファイルを使用して、ユーザが実行できる作業の種類、およびアクセスできるレベルを指定します。

事前に定義されるプロファイルには、次の 2 つのタイプがあります。

一般ユーザ:これらのユーザには、読み取りアクセス権があり、Content Engine 設定の一部を表示できます。

スーパーユーザ:これらのユーザには、新規ユーザの作成、Content Engine 設定の変更などの管理特権があります。

特権プロファイルは、各新規ユーザ アカウントに割り当てる必要があります。 ACNS ソフトウェアを実行する Content Engine には、スーパーユーザ アカウントが事前に定義されています。このアカウントを使用して、最初に Content Engine にアクセスし、他のユーザを追加することができます。

Content Engine GUI へのアクセスは、ユーザ名およびパスワードを使用してアクセスするレベルを階層化することによって管理できます。また、アクセスを IP アドレス(ホスト)のサブセットだけに制限できます。 これらのアクセス制御は、Content Engine の GUI および CLI を使って設定されます。

ユーザ アカウントの管理

ACNS ソフトウェアを実行する Content Engine には、1 つのスーパーユーザ アカウント(ルート管理者)が事前に定義されています。 この事前に定義されているアカウントを使用して、最初に Content Engine GUI にアクセスし、Content Engine を設定できます。その後で他のユーザ アカウントを追加できます。 この事前に定義されているスーパーユーザのユーザ アカウントのユーザ名は admin 、デフォルトのパスワードは default です。 ACNS システム管理者がこれらのデフォルトを変更している場合は、変更後のユーザ名とパスワードを入手する必要があります。

管理権限をもつユーザは、Content Engine の GUI または CLI を使用して、ユーザ アカウントの追加、削除、および変更ができます。

Content Engine GUI を使用したユーザ アカウントの管理

Content Engine GUI から、 System > Routing の順に選択します。 表示された Users ページを使用して、ユーザの追加や削除、またはユーザの権限の変更を行います。 ユーザを追加すると、そのユーザが Users ページにリストされます(図 2-12 を参照)。 たとえば、次の例では、 dd という名前の一般ユーザの権限をもつユーザが定義されています。

図 2-12 Content Engine GUI を使用したユーザ アカウントの管理

 


ヒント Users ウィンドウに表示されるフィールドについては、HELP ボタンをクリックして、コンテキスト依存ヘルプを表示してください。


Content Engine GUI へのアクセスの詳細は、「Content Engine GUI へのアクセス」を参照してください。

CLI コマンドを使用したユーザ アカウントの管理

管理権限をもつユーザは、 username コマンドを使用してContent Engine 上でユーザ アカウントの追加、削除、および変更ができます。


) Content Engine CLI へのアクセスの詳細は、「ACNS ソフトウェアの CLI の操作」を参照してください。


CLI を使用して ACNS システムのユーザ アカウントを追加または変更する手順は、次のとおりです。


ステップ 1 グローバル設定コードで Content Engine CLI にアクセスします。

ステップ 2 username コマンドを使用して、グループ名ベースのアクセス リストのエントリを設定します。

ContentEngine(config)# username name {cifs-password | samba-password {0 plainword | 1 lancrypto ntcrypto} | password {0 plainword | 1 cryptoword} uid uid} | privilege {0 | 15}}
 

表 2-10 では、 username CLI コマンドのパラメータを説明します。

 

表 2-10 username CLI コマンドのパラメータ

パラメータ
説明

username

ユーザ名を設定します。

name

ユーザ名を指定します。

cifs-password

Windows ユーザのパスワードを設定します。

samba-password

このコマンドは推奨されません。 cifs-password と同様にパスワードを設定します。

0

クリア テキスト パスワードを指定します。 これが、デフォルトのパスワード設定です。

plainword

ユーザのクリア テキスト パスワード。

1

タイプ 1 の暗号化パスワードを指定します。

lancrypto

LAN Manager ネットワークの暗号化パスワード。

ntcrypto

Windows NT ネットワークの暗号化パスワード。

cryptoword

ユーザの暗号化パスワード。

password

ユーザ パスワードを設定します。

uid

パスワードのユーザ ID を設定します。

uid

テキスト パスワードのユーザ ID(2001 ~ 65535)。

uid

暗号化パスワードのユーザ ID を設定します。

uid

暗号化パスワードのユーザ ID(2001 ~ 65535)。

privilege

ユーザ特権レベルを設定します。

0

一般ユーザ用のユーザ特権レベル。

15

スーパーユーザ用のユーザ特権レベル。


 

CLI コマンドを使用したユーザ アカウントの管理の例

この例では、Content Engine 上で username コマンドを使用して、ユーザ アカウントのパスワードおよび特権レベルを変更する方法を示します。

ContentEngine# show user username abeddoe
Uid : 2003
Username : abeddoe
Password : ghQ.GyGhP96K6
Privilege : normal user
ContentEngine# show user username bwhidney
Uid : 2002
Username : bwhidney
Password : bhlohlbIwAMOk
Privilege : normal user
ContentEngine(config)# username bwhidney password 1 victoria
ContentEngine(config)# username abeddoe privilege 15
User's privilege changed to super user (=15)
ContentEngine# show user username abeddoe
Uid : 2003
Username : abeddoe
Password : ghQ.GyGhP96K6
Privilege : super user
 
ContentEngine# show user username bwhidney
Uid : 2002
Username : bwhidney
Password : mhYWYw.7P1Ld6
Privilege : normal user

Content Engine の管理機能

次の方法を使用して、Content Engine をキャッシングおよびストリーミング用に設定できます。

Content Distribution Manager GUI を使用した Content Engine の中央側での設定:Content Engineが ACNS ネットワーク デバイス グループの一部である場合には、Content Dustribution Manager を使用してローカル側で管理できます。

Content Engine の GUI(図 2-13 に示す)または CLI を使用して、Content Engine をスタンドアロン キャッシング エンジンとしてローカル側で設定します。

図 2-13 Content Engine GUI の例

 

このマニュアルでは、ローカル側に配置する Content Engine をキャッシングおよびストリーミング用に設定する方法を中心に説明するため、CLI または Content Engine GUI を使用する方法がこのマニュアル全体で採用されています。


) Content Distribution Manager を使用して、ACNS ソフトウェア(たとえば、Content Routers)を実行する Content Engine、およびその他のデバイスを中央側で設定する方法については、『Cisco ACNS ソフトウェア デプロイメント コンフィギュレーション ガイド Release 5.1』を参照してください。


Content Engine 上での設定のタイプ

ローカル側で設定される Content Engine には、2 つのタイプのシステム設定があります。

不揮発性メモリに格納される始動システム設定

実行システム設定

Content Engine の GUI または CLI を使用して、実行システム設定を更新し、実行システム設定を始動システム設定として保存できます。

Content Engine GUI を使用して、現在の実行設定を始動設定として保存する方法は、次のとおりです。

1. Content Engine GUI ウィンドウの Update ボタンをクリックして、実行システム設定を更新します。

2. Content Engine GUI (図 2-14 に示す)のメイン ウィンドウの Save Config ボタンをクリックします。

CLI を使用して、現在の実行設定を始動設定として保存するには、 copy running-config グローバル設定コマンドを使用します。 実行システム設定は、sysfs パーティション、フラッシュ メモリ、または TFTP サーバに保存できます。 たとえば、次のコマンドを入力して、実行設定をフラッシュ メモリに保存します。

ContentEngine (config)# copy running-config startup-config

ヒント copy running-config startup-config コマンドは、write memory コマンドに相当します。

Content Engine のリブート

Content Engine GUI を使用して、Content Engine をローカル側でリブートできます。 Content Engine のメイン ウィンドウ(図 2-14 に示す)の Reboot ボタンをクリックすると、Content Engine は管理シャットダウンを実行してから、Content Engine 上でオペレーティング システムをリブートします。 Content Engine は、次の状況の場合、リブート プロセス時にすべての WCCP 接続をルータに解放します。

Content Engine GUI のメイン ウィンドウの Clean WCCP shutdown チェックボックスにチェックマークが付いている場合。

WCCP バージョン 2 が使用可能になっている場合。


ヒント Content Engine のメイン ウィンドウ(図 2-14 に示す)がブラウザに表示されない場合、Content Engine GUI ウィンドウの左上隅に表示された「Content Engine」をクリックすると、Content Engine のメイン ウィンドウに戻ります。


ローカル側に配置された Content Engine をリブートする手順は、次のとおりです。


ステップ 1 Content Engine のメイン ウィンドウの Reboot ボタンをクリックします。リブートを確認するメッセージが表示されます。

ステップ 2 OK をクリックして Content Engine のリブートを開始します。


 

Content Engine の取り外しまたは交換

アクティブ ネットワークから Content Engine を物理的に取り外す方法については、Content Engine のハードウェア資料を参照してください。

WCCP が使用可能であるときは、ルータと Content Engine は常に通信しています。したがって、ルータはContent Engine が応答しなくなったことを感知すると、その時点で Content Engine への要求の送信を停止します。この機能は、ユーザには透過的に行われます。 他にもルータに Content Engine が接続されている場合、ルータは、通信可能な他の Content Engine に引き続き要求を送信します。

Content Engine GUI の操作

この項では、ローカル側に配置する Content Engine 上に ACNS ソフトウェア GUI をイネーブルにしてアクセスするなどの基本的なタスクの実行方法を説明します。 この GUI は、以降、「Content Engine GUI」と呼ばれます。

Content Engine GUI へのアクセスのイネーブル化

ACNS 5.1 ソフトウェア リリースでは、Content Engine への保護された(secured)アクセスが追加されています。 そのため、保護されたアクセスまたは保護されていないアクセスのために、ローカル側に配置する Content Engine に Content Engine GUI を設定できます。 保護された Content Engine GUI がデフォルトです。

Content Engine GUI への保護された、または保護されていないアクセスのいずれかを選できますが、それらの両方を選択することはできません。 たとえば、保護された Content Engine GUI が使用可能な場合(たとえば、ポート 8003 上の https:// アクセス)、保護されていない Content Engine GUI(たとえば、ポート 8001 上の http:// アクセス)は使用できません。

Content Engine GUI サーバのポート番号をイネーブルにする、または指定するには、 gui-server グローバル設定コマンドを使用します。

gui-server {enable | port port | secure {enable | port port}}

Content Engine GUI への保護されたアクセスのイネーブル化

Content Engine GUI への保護されたアクセスを使用可能にするには、 gui-server グローバル設定コマンドを使用します。

ContentEngine(config)# gui-server secure enable port 8003
 

指定可能なポート番号は、1 ~ 65535 です。 GUI への保護されたアクセスのデフォルト ポートは 8003 です。

たとえば、Content Engine GUI への保護されたアクセスは、デフォルトのポート番号 8003 でイネーブルになっています。

このように、Content Engine GUI への保護されたアクセスをイネーブルにすると、「Content Engine GUI へのアクセス」 で説明されているように、GUI にアクセスできます。

Content Engine GUI への保護されていないアクセスのイネーブル化

Content Engine GUI への保護されていないアクセスをイネーブルにするには、 gui-server グローバル設定コマンドを使用します。

ContentEngine(config)# gui-server enable port 8001
 

指定可能なポート番号は、1 ~ 65535 です。 GUI への保護されていないアクセスのデフォルト ポートは 8001 です。

たとえば、Content Engine GUI への保護されていないアクセスは、デフォルトのポート番号 8001 でイネーブルになっています。

このように、Content Engine GUI への保護されていないアクセスをイネーブルにすると、「Content Engine GUI へのアクセス」 で説明されているように、GUI にアクセスできます。

Content Engine GUI へのアクセス

Content Engine GUI(図 2-14)は、ローカル側に配置する Content Engine をキャッシング エンジン、およびストリーミング エンジンとして設定するための Web ポータルです。

図 2-14 Content Engine GUI

 


) Content Engine GUI を使用すると、この GUI にログインする特定のユーザがアクセスできるすべての管理用およびオペレータ機能にアクセスできます。 ユーザ アカウントおよびアクセス制御の詳細は、「ユーザ アカウントと特権プロファイル」を参照してください。


Content Engine に ACNS ソフトウェアをインストールした後、標準の Web ブラウザを使用して、Content Engine GUI にログインしてアクセスします。

Content Engine GUI へのログイン

Content Engine GUI には、事前に定義されている 1 つのユーザ アカウント(ルート管理者)があります。そのユーザ アカウントを使用して、最初に Content Engine にアクセスし、他のユーザをシステムに追加できます。 この事前に定義されているユーザ アカウントのユーザ名は admin 、デフォルトのパスワードは default です。 ACNS システム管理者がこれらのデフォルトを変更している場合は、変更後のユーザ名とパスワードを入手する必要があります。

Content Engine GUI にログインする前に、次の情報を入手していることを確認します。

ログイン先の Content Engine の名前または IP アドレス。

ログインに使用するユーザ アカウント(ユーザ名とパスワード)。 ユーザ アカウントがない場合には、ACNS システム管理者にユーザ アカウントの作成を依頼する必要があります。

Content Engine GUI でイネーブルなアクセスのタイプ(保護された、または保護されていない)。


) Content Engine GUI への保護された、または保護されていないアクセスの詳細は、「Content Engine GUI へのアクセスのイネーブル化」を参照してください。


Content Engine GUI にアクセスするには、Content Engine の URL または IPアドレスとポート番号を入力する必要があります。 Content Engine の URL(ロケーション)は、ACNS ソフトウェアのインストール時に指定されます。 現在使用中のネットワークが DNS をサポートしており、Content Engine の IP アドレスが DNS テーブルに追加されている場合、Content Engine の DNS 名を使用して、Content Engine GUI にアクセスできます。

Content Engine GUI のポート番号は、Content Engine に ACNS ソフトウェアをインストールするときに指定されます。 保護されていないアクセスのデフォルトのポート番号は、8001 です。 保護されたアクセスのデフォルトのポート番号は、8003 です。 Content Engine GUI への保護されたアクセスは、デフォルトのポート番号 8003 でイネーブルになっています。 HTTP は保護されていないアクセス用に、HTTPS は保護されたアクセス用に使用されるので注意してください。

Content Engine GUI にログインする手順は、次のとおりです。


ステップ 1 Content Engine が置かれているネットワークにアクセスできるデバイス上で、Web ブラウザを始動します。


ヒント Microsoft Internet Explorer(IE)を使用している場合、IE で Java、JavaScript、および Cascading Style Sheets が使用可能であることを確認します。 Netscape を使用している場合には、バージョン 4.0 以降を使用してください。

ステップ 2 Web ブラウザで、Content Engine の URL または IP アドレスを入力します。 ポート番号を付加します。

たとえば、保護されていないモードで GUI にアクセスする場合、次の URL を入力します。

http://<Name_of_Content_Engine>:8001
 

または、次のように IP アドレスを入力します。

http://<IP_address_of_Content_Engine>:8001
 

前述の例では、Content Engine GUI への保護されていないアクセスは、デフォルトのポート番号 8001 でイネーブルです。

たとえば、保護されたモードで GUI にアクセスする場合、次の URL を入力します。

https://<Name_of_Content_Engine>:8003
 

または、次のように IP アドレスを入力します。

https://<IP_address_of_Content_Engine>:8003
 

ステップ 3 保護されたアクセスを指定した場合、Security Alert ウィンドウが表示されます。 Yes をクリックして、セキュリティ証明書を受け入れます。Enter Network Password ウィンドウが表示されます。

ステップ 4 Username フィールドにユーザ名を入力します。 Password フィールドにパスワードを入力し、 OK をクリックします。

Username:admin
Password:<password>
 

ステップ 5 指定されたログイン情報をシステムが確認した後、Content Engine GUI のメイン ウィンドウが Web ブラウザに表示されます。 これらを入力する管理者がデフォルトの管理者である場合、ACNS システム管理者およびユーザに対して、ユーザ アカウントを作成する必要があります。


 


) アカウント作成の詳細は、「ユーザ アカウントの管理」を参照してください。


Content Engine GUI のログアウト

Content Engine GUI からログアウトする手順は、次のとおりです。


ステップ 1 Content Engine GUI から Update ボタンをクリックして、現在の Content Engine ウィンドウの変更内容を保存するか、 Cancel をクリックして、それらの変更内容をキャンセルします。

ステップ 2 Content Engine のメイン ウィンドウ(図 2-14)に戻るには、現在の Content Engine ウィンドウの左上隅に表示されている「Content Engine」をクリックします。

ステップ 3 このセッション時に変更した内容を保存してからログアウトする場合には、Content Engine ホーム ページの Save Config ボタンをクリックします。

ステップ 4 File > Close の順に選択するか、ブラウザの Close ボタンをクリックします。


 

Content Engine GUI のディセーブル化

Content Engine GUI をディセーブルにするには、次のように no gui-server グローバル設定コマンドを使用します。

no gui-server { enable | port port | secure { enable | port port }}

たとえば、GUI への保護されたアクセスがポート 8003 でイネーブルな場合、次のコマンドを使用して、Content Engine GUI をディセーブルにします。

ContentEngine(config)# no gui-server secure enable port 8003
 

次の例では、Content Engine 上のポート 8001 への保護されていないアクセスがディセーブルになります。

ContentEngine(config)# no gui-server enable port 8001
 

Content Engine GUI とは

Content Engine GUI にアクセスすると、Content Engine メイン ウィンドウと呼ばれるウィンドウ(ページ)が表示されます 図 2-15 を参照)。

図 2-15 Content Engine GUI メイン ウィンドウ

 

図 2-15 で示すように、Content Engine GUI には、一連のタブとボタンがあります。


ヒント ブラウザ ウィンドウの右下隅にあるロック アイコンは、Content Engine GUI が保護されていないモードではなく、保護されたモードでアクセスされていることを示します。 Content Engine GUI への保護された、または保護されていないアクセスをイネーブルにする方法については、「Content Engine GUI へのアクセスのイネーブル化」を参照してください。


Content Engine GUI のタブ

表 2-11 では、4 つの機能タブ、およびそれらに関連する機能を説明します。 Content Engine GUI のタブおよびサブタブ オプションの詳細は、 付録 A「Content Engine GUI のメニュー オプション」 を参照してください。

 

表 2-11 Content Engine GUI の機能タブ

タブ
説明

WCCP

Content Engine 上で WCCP をイネーブルにし、WCCP 関連のパラメータおよびサービスを設定します(たとえば、Web キャッシュ サービスをサポートするために Content Engine を設定)。

Caching

Content Engine 上でキャッシュ関連のパラメータ(たとえば、コンテンツ事前ローディング)を設定します。

System

Content Engine 上でシステム関連のパラメータ(たとえば、アクセス リスト、DNS、Websense サーバ パラメータ)を設定します。

Reporting

Content Engine によって収集された統計情報(たとえば、ディスク統計情報、パフォーマンス統計情報、WMT ストリーミング統計情報)を表示します。

Content Engine のハードウェア プロファイル(モデル番号、CPU、メモリ、ディスク、SCSI、NIC)、およびContent Engine で現在実行されている ACNS ソフトウェアのバージョンを表示します。

Content Engine GUI のボタン

表 2-12 では、Content Engine GUI の主なボタン、およびそれらに関連する機能を説明します。

 

表 2-12 Content Engine GUI のボタン

ボタン
説明

Clear

Content Engine のメモリおよびハード ディスクから、キャッシュ可能なオブジェクトをすべて削除します。

Reboot

Content Engine をリブートします。

Save Config

実行システム設定を始動システム設定に保存します。

Update

現在の Content Engine GUI ウィンドウで指定した変更内容を、実行システム設定に適用します。

Help

特定の Content Engine GUI ウィンドウのコンテキスト依存ヘルプを表示します。 Help ウィンドウの Back ボタンをクリックして、コンテキスト依存ヘルプを開始した場所から Content Engine GUI ウィンドウに戻ります。

Content Engine GUI のナビゲーション

Content Engine GUI を使用する際には、次の内容がナビゲーションする上でのヒントとなります。

図 2-16 で示すように、Content Engine ページの上部は、「Content Engine」という語と、GUI を使用してナビゲーションする一連のタブ(たとえば、WCCP、CACHING)で構成されています。

図 2-16 Content Engine GUI のナビゲーション バー

 

メイン ウィンドウに戻るには、Content Engine ウィンドウの左上隅に表示されている(図 2-16 に示す)「 Content Engine 」をクリックします。

Content Engine GUI で別のウィンドウにナビゲーションするには、いずれか 1 つのタブをクリックしてそのサブタブを表示します。 サブタブを選択して、クリックします(図 2-17 に示す)。

図 2-17 Content Engine GUI のタブとサブタブ

 


) Content Engine GUI のタブおよびサブタブ オプションの説明は、付録 A「Content Engine GUI のメニュー オプション」を参照してください。


ACNS ソフトウェアの CLI の操作

この項では、ACNS ソフトウェア CLI の操作方法の概要を説明します。 詳細は、『Cisco ACNS Software Command Reference,Release 5.1』を参照してください。

ACNS ソフトウェアの CLI は、Cisco IOS ソフトウェアに類似しています。 Cisco IOS ソフトウェアと同様に、ACNS ソフトウェアの CLI は、異なるコマンド モードに分類されており、各モードを使用して特定のコマンド セットにアクセスできます。

ACNS ソフトウェアの CLI の開始

Content Engine で ACNS ソフトウェアの CLI を開始する手順は、次のとおりです。


ステップ 1 Content Engine シリアル ポートに接続された Telnet またはコンソールを使用して、Content Engine にログインします。 たとえば、Telnet セッションを開始した後、 open コマンドを使用してログイン先の Content Engine を指定します。

Microsoft Telnet> open IP_address_of_Content_Engine
 

ステップ 2 ログインのプロンプト画面が表示されたら、ユーザ名とパスワードを入力します(図 2-18 を参照)。

図 2-18 Telnet Session Login ウィンドウの例

 

ステップ 3 正常にログインした後、CLI には、ユーザ アカウントの特権レベルに応じて、次のいずれか 1 つのプロンプトが表示されます。

特権 EXEC モード:

ContentEngine#
 

ユーザ EXEC モード:

ContentEngine>
 

ここで、 ContentEngine は、Content Engine のホスト名です。

図 2-19 では、特権 EXEC モードのシステム プロンプトの例を示しています。

図 2-19 特権 EXEC モードの CLI システム プロンプト

 

ステップ 4 任意の時点で CLI セッションを終了するには、EXEC モードで logout または exit コマンドを入力します (CLI モードは、次の「ACNS ソフトウェアの CLI コマンド モード」に説明します)。


 

ACNS ソフトウェアの CLI コマンド モード

表 2-13 では、ACNS ソフトウェアの CLI を使用して、ローカル側に配置する Content Engine を設定する場合に、作業可能な各種コマンド モードを説明します。 コマンド モードの詳細は、『Cisco ACNS Software Command Reference,Release 5.1』を参照してください。


) グローバル設定コマンドはデバイスレベルのコマンドであるのに対し、サブグローバル設定コマンドはデバイスレベルではありません。 サブグローバル設定モードの例としては、 インターフェイス設定モード、HTTPS サーバ設定モード、標準 IP ACL 設定モード、拡張 IP ACL 設定モードがあります。


 

表 2-13 ACNS ソフトウェアの CLI コマンド モード

CLI コマンド モード
目的
アクセス
プロンプト
終了

ユーザEXEC

装置(ローカル側に配置するContent Engine)の操作を監視し、
telnet
traceroute
ping
などの一部のシステム コマンドを発行します。

スーパーユーザ特権をもたないアカウントを使用してログインした場合、次の CLI プロンプトが表示されます。

ContentEngine>

特権 EXEC モードから ユーザ EXEC モードにアクセスするには、次のコマンドを入力します。

ContentEngine# disable

ここで、 ContentEngine は、Content Engine のホスト名です。

ContentEngine>

次のように、 exit または end コマンドを使用します。

ContentEngine> exit

特権 EXEC

ユーザ EXEC モードのすべてのコマンドを含み、Content Engine のセットアップ、監視、デバッグを行います。

ユーザ EXEC モードから、次のコマンドを入力します。

ContentEngine> enable
 

スーパーユーザ特権をもつアカウントを使用して CLI にログインすることで、特権 EXEC モードにもアクセスできます。4

ContentEngine#

diable コマンドを使用して、ユーザ EXEC モードに戻ります。

ContentEngine# disable
 

グローバル設定

装置全体の ACNS ソフトウェア機能パラメータの設定、表示、およびテストを行います。

特権 EXEC モードから、次のコマンドを入力します。

ContentEngine# configure
ContentEngine(config)#

exit または end マンドを使用して、特権 EXEC モードに戻ります。

または、 Ctrl-Z を押して、特権 EXEC モードに戻ることができます。

インターフェイス設定

Content Engine 上で特定のインターフェイスを設定します。

グローバル設定モードから、 interface グローバル設定コマンドを使用します。 たとえば、次のようにコマンドを入力します。

ContentEngine(config)# interface FastEthernet 0/1

ContentEngine(config-if)#

ContentEngine(config-if)#

exit コマンドを使用して、前の設定モードに戻ります。

end コマンドを使用して、特権 EXEC モードを直接終了します。

HTTPS サーバ設定

Content Engine 上で HTTPS サーバを設定します。

グローバル設定モードから、次のコマンドを入力します。

ContentEngine(config)# https server HTTPS_server_name

ContentEngine(config-https)#

exit コマンドを使用して、前の設定モードに戻ります。

end コマンドを使用して、特権 EXEC モードを直接終了します。

標準 IP ACL 設定

Content Engine 上で標準 IP アクセス コントロール リスト(ACL)を設定します。

グローバル設定モードから、次のコマンドを入力します。

ContentEngine(config)# ip access-list standard acl-name | acl-num

ContentEngine(config-std-nacl)#

exit コマンドを使用して、前の設定モードに戻ります。

end コマンドを使用して、特権 EXEC モードを直接終了します。

拡張 IP ACL 設定

Content Engine 上で拡張 IP ACL を設定します。

グローバル設定モードから、次のコマンドを入力します。

ContentEngine(config)# ip access-list extended acl-name | acl-num

ContentEngine(config-ext-nacl)#

exit コマンドを使用して、前の設定モードに戻ります。

end コマンドを使用して、特権 EXEC モードを直接終了します。

4.スーパーユーザ特権(たとえば、事前に定義されている admin スーパーユーザ アカウント)をもつアカウントを使用して、CLI にログインすることで、特権モードにアクセスすることもできます。この事前に定義されている admin スーパーユーザ アカウントの場合、デフォルトでは、ユーザ名はadmin、パスワードは default です。

オンライン ヘルプとキーボードのショートカット

CLI オンライン ヘルプを表示するには、次のように ? を入力します。

プロンプトの後に、現在のモードで使用可能なコマンドのリストが表示されます。

ContentEngine(config-std-nacl)#?
 
delete Delete a condition
deny Specify packets to reject
exit Exit from this submode
insert Insert a condition
list List conditions
Move Move a condition
no Negate a command or set its defaults
permit Specify packets to accept
ContentEngine(config-std-nacl)#
 

コマンドを入力した後、使用可能なパラメータが表示されます。

ContentEngine(config)# ip access-list extended ?
<100-199> Extended IP access-list number
WORD Access-list name (max 30 characters)
 

キーワードの一部分を入力すると、予測される完全な語が表示されます。

ACNS ソフトウェアの CLI のオンライン ヘルプの説明を表示するには、 help コマンドを入力します。

ショートカットとして、コマンドを一意と判断できる最小限の文字数までコマンドを省略できます。 たとえば、 show コマンドの場合、 sho と入力できます。

特定の EXEC コマンドを入力すると、画面の下部に次のプロンプトを含む複数の画面が表示されます。

--More--
 

出力を続ける場合には スペースバー を押すか、次行を表示する場合には Return を押します。 何らかのキーを押すと、プロンプトに戻ります。 また、 --More-- プロンプトで、 ? を入力してヘルプ メッセージを表示できます。

表 2-14 では、キーボードのショートカットの要約を示します。

 

表 2-14 コマンド行処理のキー入力の組み合せ

キー入力の組み合せ
機能

Ctrl-A

コマンド行の最初の文字にジャンプします。

Ctrl-B または左矢印キー

カーソルを 1 文字前に移動します。

Ctrl-C

プロンプトおよびタスクを終了します。

Ctrl-D

カーソル上の文字を削除します。

Ctrl-E

現在のコマンド行の終りにジャンプします。

Ctrl-F または右矢印キー5

カーソルを 1 文字後に移動します。

Ctrl-K

カーソル上からコマンド行の終りまでを削除します。

Ctrl-L

現在のコマンドを新しい行に繰り返します。

Ctrl-N または下矢印キー 1

履歴バッファに次のコマンド行を入力します。

Ctrl-P または上矢印キー 1

履歴バッファに前のコマンド行を入力します。

Ctrl-T

カーソル上にある文字をカーソルの左側にある文字に置き換えます。

Ctrl-U ; Ctrl-X

カーソル上からコマンド行の始まりまでを削除します。

Ctrl-W

最後に入力した語を削除します。

Esc-B

カーソルを 1 語前に移動します。

Esc-D

カーソル上から語の終りまでを削除します。

Esc-F

カーソルを 1 語後ろに移動します。

Delete キーまたは Backspace キー

コマンドの入力時に誤入力を削除し、このキーを使用した後にコマンドを再入力します。

5.VT 100 などの ANSI 準拠ターミナルに限定される矢印キー機能。

ACNS ソフトウェアのデバイス モード

ACNS ソフトウェアのデバイス モードは、ACNS ネットワーク デバイスが Content Engine、Content Distribution、Content Router、または IP/TV Program Manager のどのデバイスとして機能するかを決定します。 特定の CLI モードから使用できるコマンドは、有効な ACNS ソフトウェアのデバイス モードによって決定されます。


ヒント デフォルトのデバイス動作モードは、Content Engine です。


device mode グローバル設定コマンドを使用して、現在のデバイス モードを別の設定に変更します。 デバイス モードのコマンドの詳細は、『Cisco ACNS Software Command Reference,Release 5.1』を参照してください。

ログインに対するセキュア シェル バージョン 1 のサポート

セキュア シェル(SSH)は、暗号化された保護チャネルを介した Content Engine へのログイン アクセスを可能にします。SSH は、サーバ プログラムとクライアント プログラムから構成されています。Telnet の場合のように、クライアント プログラムを使用して、SSH サーバを実行している装置にリモートからログオンできます。しかし、Telnet の場合と異なり、クライアントとサーバ間に伝送されるメッセージは、暗号化されます。SSH の機能には、ユーザ認証、メッセージ暗号化、およびメッセージ認証が含まれます。

sshd コマンドを使用可能にする場合は、事前に、 ssh-key-generate コマンドを使用して、秘密キーおよび公開ホスト キーを生成します。これらのキーは、クライアント プログラムがサーバの ID を確認するために使用します。

ユーザが SSH クライアントを実行し、Content Engine にログインすると、Content Engine 上で実行されている SSH デーモンの公開キーが、ユーザのホーム ディレクトリ内にある、クライアント マシンの known_hosts ファイルに記録されます。 Content Engine の管理者が、これ以降に ssh-key-generate コマンドを実行してホスト キーを再生成する場合、ユーザは、SSH クライアント プログラムを実行して Content Engine にログインする前に、known_hosts ファイル内の、Content Engine に関連付けられている古い公開キー エントリを削除しておく必要があります。 ユーザがこの古いエントリを削除後に SSH クライアント プログラムを実行するときには、known_hosts ファイルは、Content Engine 用の新しい SSH 公開キーに更新されます。


) Telnet デーモンは、Content Engine で引き続き使用できます。SSH は Telnet に置き換わりません。


次の例では、SSH 公開キーを生成した後、SSH サービスを使用可能にしています。

Console(config)# ssh-key-generate
Ssh host key generated successfully
Saving the host key to box ...
Host key saved successfully
 
Console(config)# sshd enable
Starting ssh daemon ...
Ssh daemon started successfully