この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco CNS Configuration Engine 1.4 の概要について説明します。この章は、次の項で構成されています。
• 操作モード
• 暗号化
• Cisco CNS Configuration Engine 1.4 の仕組み
• ConfigID と EventID の変更のダイナミックな同期化
Cisco CNS Configuration Engine 1.4 は、ネットワーク デバイスおよびサービスの配置および管理を自動化する設定サービスとして機能するネットワーク管理アプリケーションです(図 1-1 を参照)。Cisco CNS Configuration Engine 1.4 は、Cisco CNS 2100 Series Intelligence Engine(CNS 2100 Series システム)ハードウェア プラットフォームで動作します。
図 1-1 Cisco CNS Configuration Engine 1.4 アーキテクチャの概要
Cisco CNS Configuration Engine 1.4 はそれぞれ、配送する Cisco デバイスおよびサービスのグループを管理し、必要に応じて設定を保存して配送します。Cisco CNS Configuration Engine 1.4 は、デバイス固有の設定変更を生成することによって初期設定および設定更新を自動化し、それらをデバイスへ送信、設定変更を実行し、結果をログに記録します。
(注) 以前のバージョンの Cisco IOS または別のオペレーティング システム(Catalyst など)を使用するデバイスを実行している場合は、Intelligent Modular Gateway を起動してデバイスと通信する必要があります。Intelligent Modular Gateway の詳細については、「Intelligent Modular Gateway」を参照してください。
Cisco CNS Configuration Engine 1.4 は、次の一般的な業界標準とテクノロジーを使用します。
• eXtensible Markup Language(XML; 拡張マークアップ言語)
• Java Naming Directory Interface(JNDI)
• Hypertext Transport Protocol(HTTP; ハイパーテキスト転送プロトコル)
• Lightweight Directory Access Protocol(LDAP)
Cisco CNS Configuration Engine 1.4 は、2 つの操作モード(内部ディレクトリと外部ディレクトリ)をサポートし、また次の Cisco CNS コンポーネントを組み込んでいます。
• 設定サービス(Web サーバ、ファイル マネージャ、およびネームスペース マッピング サーバ)
• データ サービス ディレクトリ(データ モデルおよびスキーマ)
• Intelligent Modular Gateway(IMGW)
Cisco CNS Configuration Engine 1.4 は、カスタマー開発アプリケーションを配置するための実行時コンポーネントとして使用できます。これらのアプリケーションは、Cisco CNS SDK 1.5.4 を使用して配置できます。
表 1-1 に、Cisco IOS バージョンとそれに対応する CNS Configuration Engine のバージョンおよび各バージョンに関連する機能の制約を示します。
|
|
|
---|---|---|
Cisco CNS Configuration Engine 1.4 には、次の 2 つのシステム操作モードがあります。
内部ディレクトリ モードでは、Cisco CNS Configuration Engine 1.4 は組み込み CNS Directory Service をサポートします。このモードでは、外部ディレクトリや他のデータ ストアは必要ありません。デバイス設定情報を保存するために、Cisco CNS Configuration Engine 1.4 は、CNS Directory Service に拡張 X.500 ディレクトリ スキーマとして実装されている CNS データ モデルを使用します。
外部ディレクトリ モードでは、Cisco CNS Configuration Engine 1.4 は、ユーザ定義の外部ディレクトリの使用をサポートします。このモードでは、Cisco CNS Configuration Engine 1.4 は次のディレクトリ サービスをサポートします。
CNS Configuration Service は、Cisco CNS Configuration Engine 1.4 のコア コンポーネントです。これは、各ルータに配置されたコンフィギュレーション エージェントとともに動作するコンフィギュレーション サーバで構成されます。CNS Configuration Service は、論理グループによる初期設定および大量の再設定のために、Cisco IOS デバイスにデバイスおよびサービス設定を配送します。ルータは、ネットワーク上で最初に起動するときに、CNS Configuration Service から初期設定を受信します。
CNS Configuration Service は、CNS Event Service を使用して設定変更の適用に必要なイベントを送受信し、成功または失敗の通知を送信します。
コンフィギュレーション サーバは、設定テンプレートおよび組み込み(内部ディレクトリ モード)またはリモート(外部ディレクトリ モード)ディレクトリに保存されているデバイス固有の設定情報を使用する Web サーバで構成されます。
設定テンプレートはテキスト ファイルで、コマンドライン インターフェイス(CLI)コマンドの形式で静的な設定情報を含んでいます。テンプレートでは、変数はディレクトリに保存されているデバイス固有設定情報を参照する Lightweight Directory Access Protocol(LDAP)URL を使用して指定されます。
設定テンプレートには追加機能が組み込まれていて、設定テンプレートの構造およびモジュラ サブテンプレートの単純な条件制御ができます(「テンプレートとテンプレート管理」を参照)。
コンフィギュレーション サーバは HTTP を使用して、管理対象の Cisco IOS デバイスで実行している CNS Configuration Agent と通信します。また、XML 形式でデータを転送します。ルータのコンフィギュレーション エージェントは、独自の XML パーサーを使用して設定データを解釈し、受信した設定から XML タグを除去します。
コンフィギュレーション エージェントはまた、受信した設定ファイルの構文チェックも行います。さらに、イベント ゲートウェイ経由でイベントをパブリッシュして、構文チェックの成功または失敗を示すこともできます。
コンフィギュレーション エージェントは、設定をただちに適用するか、またはコンフィギュレーション サーバから同期イベントを受信するまで適用を遅延することができます。
Cisco CNS Configuration Engine 1.4 は、CNS Event Service を使用してイベントを受信および生成します。CNS Event Agent は Cisco IOS デバイスに常駐して、ルータと Cisco CNS Configuration Engine 1.4 上のイベント ゲートウェイとの間の通信を簡素化します。
CNS Event Service は、拡張が非常に容易なパブリッシュおよびサブスクライブ通信方式です。CNS Event Service は、サブジェクト ベースのアドレッシングを使用してメッセージが宛先に到達できるようにします。サブジェクト ベースのアドレッシング規則では、メッセージおよびその宛先について単純で一様のネームスペースを定義します。
CNS イベント サブジェクト ネームスペースの基本要素は、Cisco IOS 12.3 のサポートで、cisco.cns.* から cisco.mgmt.cns.* に変更されました。
CNS イベント サブジェクト ネームスペースは、新規の Cisco サブジェクト命名規則に従って変更されました。新規のサブジェクト命名規則に準拠するために、Cisco IOS の CNS エージェントは変更されて、12.3 Cisco IOS トレーニングでリリースされました。この変更は、CNS エージェントがサブスクライブおよびパブリッシュするサブジェクト名に影響します。
Cisco IOS 12.3 に関連する新規のイベント サブジェクト名は次のとおりです。
cisco.mgmt.cns.event.id-changed
cisco.mgmt.cns.image.* :イメージ配布エージェントに関連するイベント
cisco.mgmt.cns.image.checkServer
cisco.mgmt.cns.image.inventoryRequest
cisco.mgmt.cns.image.upgradeRequest
cisco.mgmt.cns.exec.* :exec コマンド型の機能に関連するイベント
cisco.mgmt.cns.config.complete
cisco.mgmt.cns.config.sync-status
cisco.mgmt.cns.config.reboot:推奨しない。代わりに cisco.mgmt.cns.exec.reload を使用。
cisco.mgmt.cns.config.load
cisco.mgmt.cns.config.id-changed
cisco.mgmt.cns.config-changed.lost
cisco.mgmt.cns.inventory.device-details
cisco.mgmt.cns.mibaccess.request
cisco.mgmt.cns.mibaccess.response
IMGW Device Module Development Toolkit に関連する新規のイベント サブジェクト名は次のとおりです。
cisco.mgmt.cns.imgw.devicemodule.request.register
cisco.mgmt.cns.imgw.devicemodule.request.deregister
次の一覧は、Cisco IOS リリース 12.3 および CNS Configuration Engine リリース 1.3.2 より前のリリースで使用されているすべてのサブジェクト名です。Cisco IOS リリース 12.3 および CNS Configuration Engine リリース 1.3.2 から、次に示すすべてのサブジェクトのプレフィックスが cisco.cns から cisco.mgmt.cns に変更されます。
IOS 12.3 より前のリリースで使用されていたサブジェクト名は次のとおりです。
cisco.cns.inventory.device-details
CNS Namespace Mapping Service(NSM)を使用すると、パブリッシュまたはサブスクライブ イベントの単一ポストで複数のネットワーク デバイスをアドレスできます。また、ネットワーク管理者がシスコ標準のイベント名を任意の名前にマッピングできます。
たとえば、100 台のルータで構成されるネットワークで、そのうちの 10 台のルータを管理者が VPN(バーチャル プライベート ネットワーク)として設定するとします。これらの各デバイスに設定をロードするには、クライアント アプリケーションで cisco. mgmt. cns.config.load イベントを 10 件パブリッシュするか、または管理者が 10 台のデバイスを共通のグループ名に関連付けて、クライアント アプリケーションでイベントを 1 度ポストします。管理者は、 cisco. mgmt. cns. mgmt. config.load サブジェクトの名前を application.load に変更し、また西海岸のすべてのデバイスを「westcoast」という名前でグループ化します。次に、アプリケーションで application.load.westcoast をパブリッシュすると、「westcoast」グループのデバイスはイベントを取得します。
NameSpace Mapper は、次の 2 つの NSM モードのいずれかで操作できます。
NSM モードは、 Setup プログラム(『 Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux 』を参照)を実行すると設定されます。
デフォルト モードでは、ディレクトリのセットアップは必要ありません。このモードでは、サブジェクト マッピングは設定ファイルに指定されます。サブジェクト マップは、アプリケーションが使用するネームスペースに適合するように調整できます。
デフォルト モードに設定するには、 Setup プログラムの NSM Directive パラメータの値として default を指定します(『 Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux 』を参照)。
プロバイダー モードでは、ディレクトリのセットアップが必要です。NSM は、ディレクトリからデバイスのサブジェクト マッピングを検索します。このモードでは、デバイスのグループを 1 つのイベントにアドレスできます。
プロバイダー モードに設定するには、 Setup プログラムの NSM Directive パラメータの値として http を指定します。
NSM の詳細については、『 CNS SDK 1.5.4 API Reference and Programmer Guide 』を参照してください。
ディレクトリのセットアップは、ディレクトリ管理ツール(「ディレクトリ管理ツール」を参照)を使用して実行できます。
CNS Event Gateway は、CNS Integration Bus と CNS エージェント対応デバイス間のリレーとして機能し、イベント ベースの通信が可能です。
CNS Event Gateway は、NSM を使用してサブジェクトをマップします。操作モードは、 Setup の NSM Directive パラメータの値セットによって決まります(『 Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux 』を参照)。
(注) このモードは、ユーザのアプリケーションが NSM に使用するモードと一致する必要があります。
プロバイダー モード( http )を選択する場合は、サブジェクト マッピングに使用するアプリケーション ネームスペースを示すパラメータを、イベント ゲートウェイに指定する必要があります。Cisco CNS Configuration Engine 1.4 では、セットアップ時に、このパラメータ値の入力を要求するプロンプトが次のメッセージで表示されます。
このパラメータのデフォルト値は、 default です。ただし、セットアップ時に、独自の値でこの値を上書きできます。
イベント ゲートウェイ プロセスは、それぞれ 500 台のデバイスまで対応できます。500 を超えるデバイスに対応するには、複数のゲートウェイ プロセスを実行します。セットアップ中に、次のプロンプトのいずれかまたは両方で、開始する同時実行ゲートウェイ プロセスの数を設定できます。数は SSL(「暗号化」を参照)通信のセットアップ方法により異なります。
オリジナル サーブレット(com.cisco.cns.config.Config)は、コンフィギュレーション サーバのデータ ストア(LDAP サーバ)内のデバイス オブジェクトの属性値から設定テンプレートを取得して、テンプレートを構文解析し、テンプレート内のパラメータの文字列を置換します。これは、デバイスおよびデバイス オブジェクトの属性に割り当てられているテンプレートと密に結合しています。
新規のサーブレット(DynaConfig)は、テンプレートをダイナミックに割り当て、パラメータ値をデータ ストア内の別のオブジェクトから取得できるように制約が緩和されています。
このサーブレットは HttpServletRequest.getPathInfo() を使用して PathInfo 情報を取得し、構文解析して、関連テンプレート名とオブジェクト参照を取得します。PathInfo の構造は、次のとおりです。
ダイナミック テンプレートおよびオブジェクトの機能は、クライアント側からサーブレットに渡される PathInfo を使用します。サーブレットが認識できる PathInfo の構造は、次の形式です。
ダイナミック テンプレートおよびオブジェクトの引数および形式は、次のとおりです。
ダイナミック テンプレートおよびオブジェクトの詳細については、『Cisco CNS SDK 1.5.4 API
Reference and Programmer Guide』を参照してください。
CNS Image Service は、Cisco IOS イメージと関連ソフトウェア アップデートを、Cisco Intelligence Agent(CIA)を持つ Cisco IOS デバイスに配布するように設計された、自動化され、拡張が可能な、保護されたメカニズムです。
CNS Image Service の使用方法の詳細については、「CNS Image Service」を参照してください。
CIA のないデバイス、Cisco IOS 以外のデバイス、および Cisco 以外のデバイスの場合は、IMGW
Toolkit を使用して、CNS Configuration Engine 1.4 との間の SSH セッションをサポートするスクリプトを作成できます。
IMGW Device Module Toolkit の詳細については、「IMGW Device Module Development Toolkit」を参照してください。
Cisco CNS Configuration Engine 1.4 には、Cisco PIX ファイアウォール デバイス(PIX デバイス)に対する設定管理およびイメージ サービスが用意されています。
PIX ファイアウォール サポートの詳細については、「Cisco PIX ファイアウォール デバイスのサポート」を参照してください。
Intelligent Modular Gateway(IMGW)を使用すると、Cisco CNS Configuration Engine 1.4 を実行して、12.2(2)T より前のバージョンの Cisco IOS を実行する Cisco IOS ネットワーク デバイス、Catalyst スイッチ、CCS 11k デバイス、Cache Engine、および PIX ファイアウォールに設定ファイルを自動的に配布できます。
(注) Cisco IOS バージョン 12.2(2)T 以降を使用するデバイスには、CNS Event Gateway を使用する必要があります。
Intelligent Modular Gateway は、そのソフトウェアに CNS エージェントのないデバイスに代替アクセス方式を使用して接続する機能を追加して、この作業を完了します。現在のアクセス方式は SSH です。
Intelligent Modular Gateway のインターフェイスは、CNS Event Gateway と同じです。同じイベントにも対応します。NameSpace Mapper も同様に動作します。したがって、一部の初期セットアップ作業が実行されると、イベント ゲートウェイによるエージェント対応デバイスとの通信と Intelligent Modular Gateway による非エージェント デバイスとの通信の違いをアプリケーションで認識する必要はありません。
SSH トランスポートで Intelligent Modular Gateway を使用すると、Cisco CNS Configuration Engine 1.4 アーキテクチャの使用方法について一部の制限が発生します。
• トランスポートとして SSH を使用すると、適用する前の設定について構文チェックは行われません。
Cisco CNS Configuration Engine 1.4 アーキテクチャでの構文チェックは、内部パーサー機能にアクセスできるデバイスのインテリジェント エージェントにより実行されます。SSH インターフェイスには、この機能にアクセスできる手段は用意されていません。したがって、構文チェックの属性はすべて無視されます。設定が実際に適用されるときにエラーが検出されただけで、エラー前の設定行が実行されたことについては、アプリケーションで対処する必要があります。
• 論理はすべてデバイスの外部にあるため、ネットワーク管理ソフトウェアのスコープ外で行われる設定変更を監視することはできません。
たとえば、ネットワーク管理者が標準 SSH クライアントを使用してネットワーク要素に直接アクセスし、設定を変更する場合、その要素はネットワーク管理インフラストラクチャと同期化されず、変更内容によっては、管理不能になる場合があります。これは特に、ログイン メカニズム(ユーザ名およびパスワード)が変更された場合に発生します。競合条件の発生を防ぐため、ログイン メカニズムの変更はメンテナンス ウィンドウ内で、イベント ベースの設定が発生していない間に処理する必要があります。新規の部分設定が送信される前にデバイス情報データベースを適切に更新するため、このような変更はすべてプロビジョニング システムのデバイス情報画面に反映する必要があります。
• 設定ロード時のエラー チェックのスコープは、構文チェックに限定されます。
意味エラーは検出できません。出力はバッファに戻され、アプリケーションでログに記録する必要があります。適切に動作しない場合、ネットワーク管理者は手動でデバイスがレポートしているログ内容を参照して、意味エラーが発生しているかどうか判別できます。
• Cisco CNS Configuration Engine 1.4 アーキテクチャで定義されている初期設定メカニズムはサポートされません。
このメカニズムを使用すると、ルータが cns config initial コマンドで事前に設定されるため、コンフィギュレーション サーバに接続してルータの初期設定を検索します。ただし、古いデバイスにはエージェント コードが存在しないため、コンフィギュレーション サーバに接続できません(古いデバイスは設定コマンドを認識しません)。したがって、このメカニズムは、SSH をトランスポートとして使用する場合は意味がありません。初期設定を Cisco CNS Configuration Engine 1.4 で配送する場合は、部分設定メカニズムを経由する必要があります。
• デバイス情報データベースを除き、ゲートウェイはステートレスです。
適用を確認するための、設定の読み戻しはありません。また、失敗しても設定は自動的にロールバックされません。
• デバイスが管理ネットワークに直接接続されていない場合は、Cisco 通信サーバ経由で接続する必要があります。
API を使用すると、任意のネットワーク トポロジをセットアップしてデバイスに到達できます。ただし、このリリースでは 2 つのトポロジしかサポートされません。つまり、デバイス ネットワーク インターフェイスのいずれかへの直接接続、または 2511 などの Cisco アクセス サーバ経由のコンソール アクセスです。
• デバイス障害は、ユーザ指定のポーリング間隔内でのみ検出されます。
これは、標準イベント ゲートウェイではルータがイベント ゲートウェイへの接続を維持する必要があるので(その接続の切断が問題を示すため)、SSH インターフェイスが一時接続で実装されるためです。したがって、ゲートウェイはあるユーザ指定の間隔ですべてのデバイスをポーリングして、それらが応答していることを確認する必要があるため、障害検出は即時には行われません。
• エージェント対応デバイスと古いデバイスの両方が同じネットワーク上に存在する場合は、両方のゲートウェイを同時に実行することをお勧めします。
標準(CNS)のイベント ゲートウェイは、エージェント対応デバイスと通信し、Intelligent Modular Gateway は古いデバイスと通信します。
(注) 両方のゲートウェイがルータの制御を試みて、予期しない結果が起こる可能性があるため、エージェント対応済みのルータのエントリをデバイス情報データベースに設定しないでください。
IMGW Device Module Toolkit を使用すると、ユーザ独自のデバイス モジュールを開発して、Cisco CNS Configuration Engine 1.4 にプラグインし、次にそれらを使用してデバイスを設定できます。
IMGW Device Module Toolkit の詳細については、「IMGW Device Module Development Toolkit」、および 付録 B「IMGW Device Module Development Toolkit の使用方法」 を参照してください。
Cisco CNS Configuration Engine 1.4 は、モジュラ ルータをサポートします。モジュラ ルータのシャーシには、ラインカードおよびネットワーク インターフェイス カードをインストールできるスロットがあります。たとえば、Cisco 3660(図 1-2 を参照)には、6 個のネットワーク モジュール スロットがあります。シャーシの有効なスロットであれば、任意のモジュールを取り付けることができます。2 Ethernet 2 WAN カード スロット モジュールなどの一部のモジュールにもサブスロットがあり、ネットワーク インターフェイス カードまたはラインカードを取り付けできます(図 1-3 を参照)。デバイス管理では、これらのラインカードおよびネットワーク カードを表すサブデバイスをサポートします。
図 1-3 インターフェイス カードまたはラインカード スロット
メイン デバイスまたはサブデバイスを表す構造と同じにするため、ラインカード タイプやサブデバイスを表す追加属性が、ディレクトリ サーバの既存のデバイス オブジェクト構造に追加されました。
モジュラ ルータの場合、インターフェイスを設定する必要があり、またスロットによりインターフェイス番号が変化するすべてのネットワーク モジュールに対して、サブデバイス設定オブジェクトと設定テンプレートが定義されます。次に、メイン デバイスについてデバイス設定オブジェクトとテンプレートが定義されます。メイン デバイス テンプレートには、固定インターフェイス番号を設定できます。
モジュラ ルータ イベントはイベント バスにパブリッシュされ、バスに接続されたアプリケーションにアクセスできます。Cisco IOS デバイスは、ハードウェア検出後、 cisco.mgmt.cns.config.device-
details イベントでシステム ハードウェア設定をパブリッシュします。このイベントの聴取、取得、およびデバイスのハードウェア設定の抽出は、Cisco CNS Configuration Engine 1.4 で設定します。
内部ディレクトリ モードでは、モジュラ ルータは両モードで NSM を使用するセッションをサポートします(「NSM モード」を参照)。
ディレクトリ管理ツール(DAT)には、ディレクトリへのデータの読み込みやディレクトリ内のデータの管理を可能にする Web ベースのユーザ インターフェイスが提供されています。デバイス(CNS エージェントが有効なデバイス。「Intelligent Modular Gateway」を参照)、デバイスのグループ、およびディレクトリ内のアプリケーションを表示、追加、削除、更新できます。また、各アプリケーションに固有のイベントを表示、追加、削除、更新することもできます。
さらに、DAT にはバルク データをアップロードする追加機能もあります。
(注) DAT を使用してスキーマを変更(拡張)することはできません。スキーマは、ディレクトリ サーバに手動で読み込む必要があります。
DAT の使用方法については、「ディレクトリ管理ツール」を参照してください。
コンフィギュレーション エージェントとコンフィギュレーション サーバ間の HTTP セッション、および CNS Event Gateway とイベント エージェント間の TCP セッションの暗号化メカニズムとして、Secure Socket Layer(SSL; セキュア ソケット レイヤ)方式が採用されました。
暗号化を使用するには、Cisco IOS デバイスが crypto イメージと Cisco IOS バージョン 12.2(11)T を実行している必要があります。
コンフィギュレーション サーバと CNS Event Gateway には、認証局(CA)サーバで生成された X.509 証明書が備わっています。CA サーバを設定して証明書の生成および取り消しを管理するのは、ネットワーク管理者の責任です。
Cisco IOS デバイスは、CA によって認識される(設定される)必要があります。Cisco IOS デバイスには、クライアント側の証明書はありません。
コンフィギュレーション サーバの場合、Cisco IOS デバイスが証明書を確認すると、
cns_id:cns_password を暗号化パイプで送信します。このデバイスは Cisco CNS Configuration Engine 1.4 で認証される CNS パスワードを使用します。
(注) また、認証はリンクがクリア テキストの場合にも行われます。
さらに、セキュア接続に設定されたサーバは、ノンセキュア(クリア テキスト)セッションを実行することもできます。暗号化を使用するかどうかに関係なく、パスワード チェックが行われます。
サーバが保護されると、サーバはパスワードのない要求を処理できません。セキュア環境のデバイスからのクリア テキスト要求と、ノンセキュア環境のデバイスからのクリア テキスト要求の区別はできません。
CNS Event Gateway の場合、Cisco IOS デバイスが証明書を検証すると、デバイスの CNS パスワードを持つ暗号化パイプを通して、DeviceID 制御メッセージを送信します。event_id:cns_password は、認証 API を使用して検証されます。一致しない場合、SSL セッションは終了し、セキュリティ ログにエントリが作成されます。適切に認証が行われることにより、許可された Customer Premises Equipment(CPE; 顧客宅内機器)だけが CNS Event Gateway に接続され、CNS Integration Bus を使用できるようになります。
Cisco CNS Configuration Engine 1.4 には、複数のデバイスをバッチで配置する場合に使用されるブートストラップ パスワードが用意されています。この場合、特定のバッチにあるすべてのデバイスに対して、初めてネットワークで起動する時に使用するものと同じ(ブートストラップ)パスワードが与えられます。
ブートストラップ パスワードは、ユーザ インターフェイスのセキュリティ マネージャの BootStrap 機能を使用して、それぞれのデバイスのバッチごとに変更できます(「セキュリティ マネージャ」を参照)。
デバイスの cns_password が破壊され、デバイスと CNS Configuration Engine 1.4 ディレクトリの対応するパスワード情報ヘルプが一致しない場合は、ユーザ インターフェイスの Resync Device 機能を使用して、デバイスを CNS Configuration Engine 1.4 と同期化できます(「デバイスの再同期化」を参照)。
Cisco CNS Configuration Engine 1.4 は、Cisco IOS 設定ファイル(ドキュメント)をダイナミックに生成して、これらのファイルを XML 形式でパッケージし、Web/HTTP で配送します(図 1-4を参照)。これは pull (get) 操作への応答において行われます。
Cisco IOS デバイスは、ネットワークに最初に現れるとき( cns config init... )、またはサブスクライブ イベントによって設定更新が通知されたとき( cns config partial... )に get 操作を開始します。
(注) これらのコマンドおよびその他の関連する CLI コマンドの詳細については、Cisco IOS 設定ガイドおよびコマンド参照資料を参照してください。
Cisco IOS デバイスからデバイス設定ファイルの要求が発行される場合、その要求には、ディレクトリ サーバ上のこのデバイスに関する設定ファイル パラメータの検出に使用される固有の ID(configID = ホスト名)が含まれています。図 1-5 に、設定ロード操作のプロセス フローを示します。
Web サーバは、設定ファイルの要求を受信すると、Java サーブレットを起動して組み込みコードを実行します。組み込みコードを実行することにより、Web サーバは、ディレクトリ サーバとファイル システムにアクセスして、このデバイスおよびテンプレートの設定参照を読み込むよう指示されます。コンフィギュレーション サーバは、テンプレートに指定されているすべてのパラメータ値をこのデバイスの有効な値に置換して、インスタンス化された設定ファイルを準備します。コンフィギュレーション サーバは、この設定ファイルを Cisco IOS デバイスへ転送するために、Web サーバに転送します。
ルータのコンフィギュレーション エージェントは Web サーバから設定ファイルを受信して、XML 解析、構文解析(オプション)を行い、設定ファイルをロードします。ルータは設定ロードの状況を、ネットワーク モニタまたはワークフロー アプリケーションでサブスクライブできるイベントとして報告します。
1. Cisco CNS Configuration Engine 1.4 は、テンプレート ファイルを読み込みます。
2. Cisco CNS Configuration Engine 1.4 は、パラメータ置換を行います。
3. Cisco CNS Configuration Engine 1.4 は、Cisco IOS デバイスにデバイス設定を送信します。
1. モジュラ ルータは、初期設定のためにハードウェア設定を含む HTTP 要求を Cisco CNS Configuration Engine 1.4 にポストします。
2. Cisco CNS Configuration Engine 1.4 はデバイスのハードウェア設定を HTTP 要求から読み込み、最新設定でディレクトリ サーバを更新します。
3. Cisco CNS Configuration Engine 1.4 は、テンプレート ファイルを読み込みます。
4. Cisco CNS Configuration Engine 1.4 は、パラメータ置換を行います。
5. Cisco CNS Configuration Engine 1.4 は、Cisco IOS デバイスにデバイス設定を送信します。
1. ユーザは、Cisco CNS Configuration Engine 1.4 ユーザ インターフェイスでテンプレートを変更します。
2. テンプレートの内容は、Cisco CNS Configuration Engine 1.4 に渡されます。
3. Cisco CNS Configuration Engine 1.4 は、そのファイル システムでテンプレートを保存します。
4. ユーザ インターフェイスのデバイス更新ボタンをクリックします。
5. Cisco CNS Configuration Engine 1.4 は、 cisco.mgmt.cns.config.load イベントを発行します。
6. Cisco IOS デバイスは cisco.mgmt.cns.config.load イベントを取得し、このイベントの応答としてサーバに接続してその設定を要求します。
7. Cisco CNS Configuration Engine 1.4 は、テンプレート ファイルを読み込みます。
8. Cisco CNS Configuration Engine 1.4 は、パラメータ置換を行います。
9. Cisco CNS Configuration Engine 1.4 は、Cisco IOS デバイスにデバイス設定を送信します。
1. ユーザは、Cisco CNS Configuration Engine 1.4 ユーザ インターフェイスでテンプレートを変更します。
2. テンプレートの内容は、Cisco CNS Configuration Engine 1.4 に渡されます。
3. Cisco CNS Configuration Engine 1.4 は、そのファイル システムでテンプレートを保存します。
4. ユーザ インターフェイスのデバイス更新ボタンをクリックします。
5. Cisco CNS Configuration Engine 1.4 は、 cisco.mgmt.cns.config.load イベントを発行します。
6. モジュラ ルータは cisco.mgmt.cns.config.load イベントを取得し、このイベントの応答としてサーバに接続してその設定を要求します。
7. Cisco IOS デバイスは、部分設定のためにハードウェア設定を含む HTTP 要求を Cisco CNS Configuration Engine 1.4 にポストします。
8. Cisco CNS Configuration Engine 1.4 は、テンプレート ファイルを読み込みます。
9. Cisco CNS Configuration Engine 1.4 は、パラメータ置換を行います。
10. Cisco CNS Configuration Engine 1.4 は、デバイス設定をモジュラ ルータに送信します。
Cisco CNS Configuration Engine 1.4 は、次の 2 つのネームスペース ドメインを使用します。
CNS Configuration Engine 1.4 は、デバイスがコンフィギュレーション サーバと通信する場合は、設定ドメインを使用します。デバイスが CNS Integration Bus のパブリッシュおよびサブスクライブ メカニズムを使用して Cisco CNS Configuration Engine 1.4 と通信する場合は、イベント ドメインを使用します。
デバイスは、これらのネームスペースで一意に識別される必要があります。ConfigID は、設定ドメイン内でデバイスを一意に識別します。EventID は、イベント ドメイン内でデバイスを一意に識別します。
Cisco CNS Configuration Engine 1.4 が CNS Integration Bus(イベント バス)とコンフィギュレーション サーバの両方を使用してデバイスに設定を提供するため、設定済みの各 Cisco IOS デバイスに対して EventID と ConfigID の両方が定義されている必要があります。
各デバイスの EventID と ConfigID の値は同一でも構いません。あるいはユーザ インターフェイスを使用してデバイス情報を追加または編集するときに、これらの値を変更できます(「デバイスの管理」を参照)。
Cisco IOS バージョン 12.2.(11)T に新規の CLI ID コマンドが追加されたことにより、EventID および ConfigID を変更して、デバイスを新規 ID で Cisco CNS Configuration Engine 1.4 に再接続できるようになりました。
CNS 2100 Series プラットフォームには、Tivoli Management Agent(TMA)が組み込まれています。Tivoli 製品には著作権があり、ライセンス供与されている(販売されない)ため、転送できません。
Tivoli 製品の所有者は、商品性の保証および特定目的適合性を含む、Tivoli 製品の使用についてのすべての保証責任を負わないものとします。
Tivoli Management Agent の初期化については、『 Cisco CNS Configuration Engine 1.4 Installation & Setup Guide For Linux 』を参照してください。