製品概要
ここでは、Cisco Configuration Engine 3.5 の概要を説明します。この章は次のように構成されています。
• Cisco IOS の依存関係
• 動作モード
• ユーザ認証モード
• コンフィギュレーション サービス
• イベント サービス
• 動的なテンプレートとオブジェクト
• イメージ サービス
• PIX ファイアウォール サポート
• Intelligent Modular Gateway
• IMGW Device Module Toolkit
• モジュラ ルータのサポート
• 暗号化
• Cisco Configuration Engine の仕組み
• ConfigID および EventID の変更の動的な同期
• 共通ログ ファイルの場所
Cisco Configuration Engine は、ネットワーク デバイスとサービスの展開および管理を自動化するためのコンフィギュレーション サービスとして動作するネットワーク管理アプリケーションです(図 1-1 を参照)。
Cisco Configuration Engine は Linux および Solaris ハードウェア プラットフォーム上で実行されます。『 Cisco Configuration Engine Installation and Configuration Guide 3.5 』を参照してください。
図 1-1 Cisco Configuration Engine のアーキテクチャ上の概要
各 Cisco Configuration Engine は、シスコ デバイスおよびこの製品が提供するサービスのグループを管理します。管理上、構成を保存して必要に応じて提供します。Cisco Configuration Engine では、デバイス固有の設定変更を生成することによって、初期設定と設定の更新が自動化され、それらのデバイスへの送信、設定変更の実行、結果のログへの記録が行われます。
(注) 以前のバージョンの Cisco IOS、または Catalyst などの異なるオペレーティング システムを使用するデバイスを実行している場合、そのデバイスとの通信のために Intelligent Modular Gateway を起動する必要があります。Intelligent Modular Gateway の詳細については、「Intelligent Modular Gateway」を参照してください。
Cisco Configuration Engine では、普及している次の業界標準および技術が利用されています。
• eXtensible Markup Language(XML; 拡張マークアップ言語)
• Java Naming Directory Interface(JNDI)
• Hypertext Transport Protocol(HTTP)
• Java サーブレット
• Lightweight Directory Access Protocol(LDAP)
Cisco Configuration Engine は 2 つの動作モード(内部ディレクトリおよび外部ディレクトリ)をサポートしており、次の Cisco Configuration Engine コンポーネントが含まれます。
• コンフィギュレーション サービス(Web サーバ、ファイル マネージャ、および名前空間マッピング サーバ)
• イメージ サービス(Cisco IOS イメージ)
• イベント サービス(イベント ゲートウェイ)
• データ サービス ディレクトリ(データ モデルおよびスキーマ)
• Intelligent Modular Gateway(IMGW)
Cisco Configuration Engine はお客様が開発するアプリケーションの展開のためのランタイム コンポーネントとして使用できます。これらのアプリケーションは、Cisco Configuration Engine Software Development Kit API Reference and Programmer Guideを使用して開発できます。
サポートされているインターフェイス
Cisco Configuration Engine のソフトウェア外部インターフェイスには、次が含まれます。
• Unix ログイン
• Telnet
• Secure Shell(SSH; セキュア シェル)
Cisco IOS の依存関係
表 1-1 に、Cisco IOS バージョン、および Cisco Configuration Engine の対応するバージョンと、各バージョンに関連する機能制限を示します。
表 1-1 Cisco Configuration Engine 3.5 と Cisco IOS の依存関係
|
Cisco Configuration Engine
|
|
12.3 |
1.3.2 以降 |
-- |
12.2(11)T |
1.2 以降 |
-- |
12.2(2)T |
1.2 以降(認証なし) |
アプリケーションは、EXEC コマンドまたはポイントツーポイント メッセージを使用できません。 |
サードパーティ製ソフトウェア
表 1-2 サードパーティ製ソフトウェア
|
|
|
|
Tibco |
7.2 |
7.2 |
7.2 |
Apache |
2.2.11 |
2.0.52 |
2.2.3 |
Mod_ssl |
2.2.11 |
2.0.52 |
2.2.3 |
Velocity |
1.4 パッチ |
1.4 パッチ |
1.4 パッチ |
Log4j |
1.2.14 |
1.2.14 |
1.2.14 |
Jakarta-tomcat |
4.1.30 |
4.1.30 |
4.1.30 |
HTTPClient |
2.0 |
2.0 |
2.0 |
Digester |
1.5 |
1.5 |
1.5 |
Regular Express |
1.1.4 |
1.1.4 |
1.1.4 |
Strut |
1.1. プラス |
1.1. プラス |
1.1. プラス |
Displaytag |
1.0 |
1.0 |
1.0 |
XERCES |
2.6.2 |
2.6.2 |
2.8.0 |
Xalan |
2.7.1 |
2.7.1 |
2.7.1 |
Expect |
5.43 |
5.42.1 |
5.42.1 |
Freemarker |
2.3.11 |
2.3.11 |
2.3.11 |
Java JDK |
1.6.0_05 |
1.6.0_05 |
1.6.0_05 |
ACE |
5.6 |
5.6 |
5.6.0 |
PERL |
5.8 |
5.8.5 |
5.8.8 |
TCL |
8.3 |
8.3 |
8.4.13 |
Openssl |
0.9.8g |
0.9.7a |
0.9.8b |
Openssh |
5.01pl |
3.9.p1 |
4.3.p2 |
J2ssh |
- |
- |
0.2.9 |
Axis |
1.4 |
1.4 |
1.4 |
JavaMail |
1.3 |
1.3 |
1.3 |
Junit |
3.8.1 |
3.8.1 |
3.8.1 |
Wutka(Jox) |
1.16 |
1.16 |
1.16 |
XSLT LotusXSL |
2.3.2 |
2.3.2 |
2.3.2 |
OpenLDAP |
2.2.26 |
2.2.26 |
2.2.26 |
unixODBC |
2.2.11 |
2.2.11 |
2.2.11 |
Berkeley DB |
4.3 |
4.3 |
4.3 |
jakarta-commons-beanutils |
1.6.1 |
1.6.1 |
1.6.1 |
jakarta-commons-cli |
1.0 |
1.0 |
1.0 |
jakarta-commons-collections |
3.1 |
3.1 |
3.1 |
jakarta-commons-lang |
2.0 |
2.0 |
2.0 |
jakarta-commons-logging |
1.0.4 |
1.0.4 |
1.0.4 |
jakarta-commons-net |
1.0.0 |
1.0.0 |
1.0.0 |
jfreechart |
0.9.20 |
0.9.20 |
0.9.20 |
pja |
2.5 |
2.5 |
2.5 |
rhino |
1.5.3 |
1.5.3 |
1.5.3 |
rss4j |
0.92 |
0.92 |
0.92 |
動作モード
Cisco Configuration Engine のシステム動作には、次の 2 種類のモードがあります。
• 内部ディレクトリ モード
• 外部ディレクトリ モード
ユーザ認証モード
Cisco Configuration Engine のユーザ認証には、次の 2 種類のモードがあります。
• 内部ユーザ認証
• 外部ユーザ認証
Cisco Configuration Engine のユーザは、内部的、または外部的に認証できます。ログインする Cisco Configuration Engine のユーザは、外部アプリケーションに対して認証されます。外部認証に失敗した場合、そのユーザは Cisco Configuration Engine LDAP サーバに対して内部的に認証されます。ユーザ認証の詳細については、「ユーザ認証」を参照してください。
ディレクトリ
Cisco Configuration Engine は OpenLDAP をディレクトリ サービスのために使用します。
OpenLDAP は、ディレクトリのためのデータ リポジトリとして内部または外部データベースを使用するように設定できます。内部データベースを使用するように(内部ディレクトリ モード)設定した場合、OpenLDAP は Berkeley DB ライブラリを使用してデータをプレーン ファイルとして保存します。外部データベースを使用するように(外部ディレクトリ モード)設定した場合、OpenLDAP は ODBC ライブラリを使用してデータをリレーショナル テーブルとして保存します。
また、OpenLDAP は、受信 LDAP 要求を別の外部 LDAP サーバに転送するプロキシとして動作するように設定できます。これにより、iPlanet などの外部 LDAP サーバ内の文字列データに別の可能性が提供されます。
(注) User Manager および Directory Manager にアクセスするための GUI は、外部ディレクトリ モードで動作する場合は使用できません。
コンフィギュレーション サービス
コンフィギュレーション サービスは Cisco Configuration Engine のコア コンポーネントです。各ルータに配置されたコンフィギュレーション エージェントと連携して動作する、1 つのコンフィギュレーション サーバから構成されます。コンフィギュレーション サービスは、論理グループによる初期設定と大規模な再設定のため、Cisco IOS デバイスに対してデバイス設定およびサービス設定を提供します。ネットワーク上での最初の起動時に、ルータはコンフィギュレーション サービスから初期設定を受信します。
コンフィギュレーション サービスは、設定変更の適用と、成功通知および失敗通知の受信に必要なイベントの送信のために、イベント サービスを使用します。
コンフィギュレーション サーバは、設定テンプレートを使用する 1 台の Web サーバと、内蔵ディレクトリ(内部ディレクトリ モード)またはリモート ディレクトリ(外部ディレクトリ モード)に保存されているデバイス固有の設定情報から構成されます。
設定テンプレートは、スタティックな設定情報を Command-line Interface(CLI; コマンドライン インターフェイス)コマンドの形式で格納したテキスト ファイルです。このテンプレート内では、変数はディレクトリに保存されているデバイス固有の設定情報を参照する(LDAP)URL を使用して指定されます。
設定テンプレートには、単純な条件付きコントロール構造とモジュラ サブテンプレートを設定テンプレート内で使用できる追加機能が含まれます(「テンプレート」を参照)。
コンフィギュレーション サーバでは、管理対象 Cisco IOS デバイス上で実行されているコンフィギュレーション エージェントとの通信に HTTP を使用します。コンフィギュレーション サーバは XML 形式でデータを転送します。ルータ内のコンフィギュレーション エージェントは、そのエージェントの独自の XML 解析を使用して設定データを解釈し、XML タグを受信した設定から削除します。
また、コンフィギュレーション エージェントは構文チェックを受信したコンフィギュレーション ファイル上で実行できます。コンフィギュレーション エージェントは、構文チェックの成功または失敗を示すため、イベント ゲートウェイを介してイベントを発行することもできます。
イベント サービス
Cisco Configuration Engine はイベントの受領および生成のためにイベント サービスを使用します。イベント エージェントは Cisco IOS デバイス上に配置され、ルータと Cisco Configuration Engine 上のイベント ゲートウェイとの間の通信に役立ちます。
イベント サービスは拡張性の高い publish-subscribe 型の通信方式です。イベント サービスはサブジェクトベースのアドレス指定を使用し、メッセージを宛先に届けることを支援します。サブジェクトベースのアドレス指定規則によって、メッセージとその宛先に対する簡単で一貫した名前空間が定義されます。
名前空間マッパー
Namespace Mapping Service(NSM; 名前空間マッピング サービス)を使用すると、発行または加入イベントの 1 回のポストによって、複数のネットワーク デバイスを指定できます。また、ネットワーク管理者は、シスコ標準イベント名と管理者が選択した名前とをマッピングできます。
たとえば、100 台のルータがあるネットワーク内に、管理者が Virtual Private Network(VPN; 仮想プライベート ネットワーク)として設定するルータが 10 台あるとします。それらの各デバイスに設定をロードするには、クライアント アプリケーションは 10 件の cisco. mgmt. cns.config.load.<deviceId> イベントを発行する、または管理者は 10 台のデバイスを共通グループ名と関連付けてクライアント アプリケーションがイベントを 1 回発行できるようにします。関連する管理手順は、次のようになります。
1. デバイス管理インターフェイスを使用し、すべてのデバイス オブジェクトを定義します(「Device/Subdevice Manager」を参照)。
2. NSM 管理インターフェイスを使用し、 cisco.mgmt.cns.mgmt.config.load の application.load を対象とする subscribe-publish 型マップの両方を再マップします(「Namespace Manager」を参照)。
3. たとえば、グループ管理インターフェイスを使用し、西海岸のすべてのデバイスを「westcoast」という名前のグループにグループ化します(「グループ」を参照)。
4. クライアント アプリケーションは、イベント バス上のマップされたサブジェクト application.load./config/westcoast を発行し、「westcoast」グループ内のデバイスがイベントを取得するようにします。 cisco.mgmt.cns.config.load イベントの発行マッピングに対してクエリを送信する際に、NSM の動作 API によってマップされたサブジェクトがクライアント アプリケーションに返されます。
イベント ゲートウェイ
イベント ゲートウェイは、Integration Bus とエージェントが有効化されたデバイスとの間の中継として機能します。これにより、イベントベースの通信が可能になります。イベント ゲートウェイはサブジェクトをマップするために NSM を使用します。
各イベント ゲートウェイ プロセスは、最大 500 台のデバイスをサポートできます。500 台を超えるデバイスをサポートするには、複数のゲートウェイ プロセスを実行する必要があります。
セットアップ 中に、Secure Socket Layer(SSL)(「暗号化」を参照)通信の設定方法に応じて次のプロンプトのいずれか、または両方を開始するための同時ゲートウェイ プロセス数を設定できます。
Enter number of Event Gateways that will be started with crypto operation:
Enter number of Event Gateways that will be started with plaintext operation:
ポート 11011 および 11012 をリッスンするイベント ゲートウェイは、デバイス接続をそれぞれ通常のプレーン テキスト、または暗号化が有効なイベント ゲートウェイにリダイレクトするディスパッチャ イベント ゲートウェイです。詳細については、『Cisco Configuration Engine Installation and Configuration Guide』の第 6 章「Scalability among Event Gateways」を参照してください。
イベント ゲートウェイ ポートの自動割り当て
各イベント ゲートウェイは、最大 500 台のデバイスをサポートできます。Zero Touch Deployment(ZTD; ゼロタッチ展開)中、展開を実施するエンジニアは、ブートストラップ コンフィギュレーション ファイルを 500 台のデバイスすべてで更新する必要があります。イベント ゲートウェイ ポートの自動割り当てプロセスは、手動プロセスの解消に役立ちます。Cisco Configuration Engine サーバが前のセクションにあるように設定されている場合、30,000 台のすべてのデバイスは、同じブートストラップ コンフィギュレーション ファイルを使用して展開できます。次に、ブートストラップ コンフィギュレーション ファイルの例を示します。太字の行は、ポートの自動割り当てをサポートするために必須のコマンドです。
cns trusted-server all-agents ce-host
cns id hardware-serial event
cns config initial ce-host status http://ce-host/cns/PostStatus
cns event ce-host keepalive 120 1 reconnect 10
cns config partial ce-host
ネットワーク要素がディスパッチャ イベント ゲートウェイを介して Cisco Configuration Engine に接続する場合、Cisco Configuration Engine はネットワーク要素に対してポートを自動的に割り当てます。ネットワーク要素はその情報を保存し、指定された Cisco Configuration Engine ポートに接続します。Cisco Configuration Engine は、デバイスが非 Cisco Configuration Engine の既知のポート(11011 および 11012 以外のポート)に接続したあと、デバイスを管理できます。
動的なテンプレートとオブジェクト
従来のサーブレット(com.cisco.cns.config.Config)は、コンフィギュレーション サーバ データ ストア(LDAP サーバ)内のデバイス オブジェクトのアトリビュート値から設定テンプレートを取得し、テンプレートを解析し、テンプレート内部のパラメータ上の文字列置換を行います。デバイスに割り当てられたテンプレート、およびデバイス オブジェクトのアトリビュートと強固に結びつけられます。
新しいサーブレットである DynaConfig では、テンプレートを動的に割り当て、パラメータ値をデータ ストア内の他のオブジェクトから取得できるように、制限事項が緩和されています。
このサーブレットは HttpServletRequest.getPathInfo() によって PathInfo 情報を取得し、その情報を解析し、関連付けられたテンプレート名とオブジェクト参照を取得します。PathInfo の構造は次のとおりです。
/<argument name>=<argument value>
データ構造
動的なテンプレート/オブジェクト機能では、PathInfo が利用されます。この情報は、クライアント側からサーブレットに渡されます。サーブレットで認識できる PathInfo の構造は次の形式です。
[/<argument name>=<value>]*
動的なテンプレート/オブジェクトの引数と形式は次のとおりです。
[/cfgtpl=value[/object=value]]
動的なテンプレートとオブジェクトの詳細については、『 Cisco Configuration Engine Software Development Kit API Reference and Programmer Guide 』を参照してください。
イメージ サービス
イメージ サービスは自動化されたスケーラブルで安全なメカニズムであり、Cisco IOS イメージおよび関連するソフトウェア更新を Cisco Intelligence Agents がある Cisco IOS デバイスに展開するために設計されています。
イメージをアップグレードするすべての決定は、イメージ サーバが行います。これらの決定は、イメージ エージェントが返すインベントリ応答情報に基づきます。
imageInventoryResponse メッセージ
imageInventoryResponse メッセージには、imageInventoryReport XML ドキュメントが含まれます。このレポートには、次に関する情報が含まれます。
• システム上で実行中のイメージ
• システム ハードウェア リソース
• デバイス上の各種ファイル システムとファイル
imageInventoryResponse は、imageInventoryRequest に対する応答です。要求内のタグで要求されたリソースは、 imageInventoryResponse メッセージ内で送信されます。要求からの messageID 要素は、応答メッセージの messageID 要素内に含まれます。
デバイス ハードウェア リソースの場合、次の情報が最低限報告されます。
• イメージの実行に使用できるシステム RAM のサイズ。
• システムの名前(hostname および imageID)。
• デバイス ハードウェアのタイプ。
• 各種ハードウェア コンポーネントのシリアル番号。
• 現在管理対象デバイス上で実行中のシステム イメージは、次の情報を提供します。
– イメージのファイル名と場所(たとえば flash:/c2600-is-mz )
– 計算できる場合、イメージ ファイルの MD5 ハッシュ
– バージョン文字列(たとえば IOS (tm) C2600 Software (C2600-IS-M) Version 12.2(10.7)T, MAINTENANCE INTERIM SOFTWARE )
• イメージがブートされた日時
• さらに、デバイス上の永続的な各ローカル ファイル システムについて、次の情報が報告されます。
– ファイル システムの名前
– ファイル システムのタイプ
– ファイル システムのサイズ
– 使用可能な空きディスク容量
– 読み取り/書き込み保護フラグ
• レポートされる各ファイル システムのそれぞれのファイルについて、次の情報がレポートされます。
– 名前(ファイル名と完全修飾パス名の両方)
– サイズ
– R/W アクセス権限フラグ
– 変更日
• ファイル システム内のそれぞれのディレクトリについて、次の情報が報告されます。
– 名前(ディレクトリ名と完全修飾パス名の両方)
– R/W アクセス権限フラグ
イメージ更新基準
イメージ サービスが、配信および(または)アクティベーションについて所定のデバイスを評価するように指示された場合、 ImageCheckServer メッセージをイベント バス上に送信し、この比較にどのアトリビュートを使用するかを決定するため、インベントリを取得してインベントリの内容を分析します。
現在、使用する比較クラスを決定するために、インベントリからの次の値が使用されます。
• MD5
• ImageFile
• File System
配信決定キー
次のファイル システム アクティベーション決定キー
• ImageFile
• MD5
• Version String
イメージ サービスでの決定は、次の順番で行われます。
1. MD5 および File System がある場合:
a. 配信:
–Inventory 内の File System に Distribution オブジェクトの Destination がある場合、 Overwrite フラグが設定されていなければ、このファイルを配信する必要はありません。たとえば、 Destination が slot0:pf-1.img4 の場合、デバイスで返されるインベントリにファイル pf-1.img4 が slot0 上にあれば、サーバでこの配信は不要と判断されます。
–Inventory 内の File System に Destination がない場合、その場所にこのファイルのための十分な空き領域が残っているかどうかの確認が開始されます。
Erase がオンになっている場合、サーバはそのファイル システム(slot0)の合計サイズを取得し、ファイルがこのファイル システムに適合するかどうかを確認します。たとえば、slot0 に 1000 バイトの空き領域があり、合計 2000 バイトで、配信時のファイル サイズが 100 バイトの場合、結果が >0 であることを確認するため、サーバは 2000 - 100 を実行します。>0 の場合、配信できます。
Overwrite の場合、サーバはそのファイル システムの残りの空き領域のサイズを取得し、インベントリ上の元のファイル サイズを追加し、ファイルがこのファイル システムに適合することを確認します。たとえば、slot0 に 1000 バイトの空き領域があり、インベントリ上のファイルが 100 バイト、配信時のファイル サイズが 200 バイト、 Overwrite が設定されている場合、slot0 の残りの空き領域が >0 であることを確認するため、サーバは 1000 + 100 - 200 を実行します。
>0 の場合、配信できます。
b. アクティベーション:
サーバは MD5 を使用し、Inventory からの RunningImageInfo とサーバ側の ImageObject を比較します。これらが同じ場合、アクティベーションは必要ありません。
2. ImageFile と File System がある場合:
a. 配信:(1a と同じ)
b. アクティベーション:
サーバは Inventory からの RunningImageInfo 内の ImageFile とサーバ側の Distribution オブジェクトの Destination アトリビュートを比較します。これらが同じ場合、アクティベーションは必要ありません。
3. Version String と File System がある場合:
a. 配信:(1a と同じ)
b. アクティベーション:
サーバは Inventory からの RunningImageInfo 内の Version String とサーバ側の Image Object の Description アトリビュートを比較します。これらが同じ場合、アクティベーションは必要ありません。
4. ImageFile だけがある場合:
a. 配信:
サーバは常に配信が必要と判断します(サーバは ImageStatus メッセージを使用して、配信の結果が成功であることを確認するため)。
b. アクティベーション:(2b と同じ)
5. Version String だけがある場合:
a. 配信:(4a と同じ)
b. アクティベーション:(3b と同じ)
6. File System だけがある場合:
a. 配信:(1a と同じ)
b. アクティベーション:
サーバは常にアクティベーションが不要と判断します(アクティベーションの結果が成功であることを確認する方法がないため)。
7. これらのアトリビュートが Inventory にない場合:
a. 配信 :
サーバは常に配信が不要と判断します。
b. アクティベーション:
サーバは常にアクティベーションが不要と判断します
イメージ サービスの使用方法の詳細については、「イメージ サービス」を参照してください。
このような Cisco イメージ エージェントがないデバイス、非 Cisco IOS デバイス、およびシスコ製以外のデバイスの場合、IMGW Toolkit を使用し、これらのデバイスと Cisco Configuration Engine との間の SSH セッションをサポートするスクリプトを作成します。
IMGW Device Module Toolkit の詳細については、「IMGW Device Module Development Toolkit」を参照してください。
PIX ファイアウォール サポート
Cisco Configuration Engine は、設定管理およびイメージ サービスを Cisco PIX ファイアウォール デバイス(PIX デバイス)に提供します。
PIX ファイアウォール サポートの詳細については、「PIX ファイアウォール デバイスのサポート」 を参照してください。
Intelligent Modular Gateway
Intelligent Modular Gateway(IMGW)を使用すると、12.2(2)T 以前の Cisco IOS を実行する Cisco IOS ネットワーク デバイス、Catalyst スイッチ、CCS 11k デバイス、Cache Engine および PIX ファイアウォールに対し、コンフィギュレーション ファイルを自動的に配信するために、Cisco Configuration Engine を実行できます。
(注) Cisco IOS バージョン 12.2(2)T 以降を使用するデバイスを実行している場合、イベント ゲートウェイを使用する必要があります。
IMGW は、Cisco Configuration Engine エージェントがソフトウェアに含まれないデバイスに接続するための代替アクセス方式(Telnet および SSH)を使用する機能を追加することで、このタスクを実行します。
IMGW へのインターフェイスは、イベント ゲートウェイのインターフェイスと同じです。同じイベントに応答します。NSM は同じ方法で動作します。そのため、いくつかの初期設定作業の実施後、アプリケーションでは、イベント ゲートウェイを使用するエージェントが有効化されたデバイスと、IMGW を使用する非エージェント デバイスとの間の通信の違いを認識する必要がありません。
制約事項
SSH トランスポートと IMGW を使用すると、Cisco Configuration Engine アーキテクチャの使用方法の点でいくつかの制限事項が発生します。
• SSH をトランスポートとして使用する場合、設定が適用される前に設定の構文チェックを実施できません。
Cisco Configuration Engine アーキテクチャでの構文チェックは、内部解析機能にアクセスできるデバイス内のインテリジェント エージェントによって実施されます。SSH インターフェイスには、この機能にアクセスするための手段が用意されていません。そのため、すべての構文チェック アトリビュートは無視されます。エラーが検出されるのは、設定が実際に適用され、エラーが実行されたよりも前の設定行をアプリケーションが処理する必要があるときだけです。
• すべてのロジックはデバイスの外部のため、ネットワーク管理ソフトウェアの対象外で実施される設定の変更を監視する手段はありません。
たとえば、ネットワーク管理者が標準 SSH クライアントを使用し、直接ネットワーク要素にアクセスして設定を変更する場合、その要素はネットワーク管理インフラストラクチャと同期されず、変更内容によっては管理できなくなります。ログイン メカニズム(ユーザ名とパスワード)が変更された場合、特にこれに当てはまります。ログイン メカニズムの変更は、競合状態が発生しないように、イベントベースの設定が発生していない間にメンテナンス ウィンドウ中に処理される必要があります。このような任意の変更は、新しい部分的な設定が送信される前に、デバイス情報データベースが適切に更新されるように、プロビジョニング システムのデバイス情報画面に反映される必要があります。
• 設定のロード時のエラー チェックは、構文チェックに制限されています。
意味論的エラーは検出できません。この出力は、アプリケーションがログに記録する必要があるバッファ内に返されます。何かが適切に動作していない場合、ネットワーク管理者はデバイスが報告するログを手動で見て、意味論的エラーが発生しているかどうかを判断できます。
• Cisco Configuration Engine アーキテクチャ内に定義されているような初期設定メカニズムはサポートされません。
このメカニズムでは、ルータは cns config initial コマンドを使用してあらかじめ設定でき、これにより、初期設定を取得するためにコンフィギュレーション サーバにアクセスします。しかし、レガシー デバイスにはエージェント コードが含まれないため、コンフィギュレーション サーバにアクセスできません(コンフィギュレーション コマンドを認識しません)。そのため、このメカニズムは SSH をトランスポートとして使用している場合は意味がありません。初期設定を Cisco Configuration Engine で提供する必要がある場合、部分的な設定メカニズムを介して実行する必要があります。
• デバイス情報データベースは別として、ゲートウェイはステートレスです。
設定が適用されたことを確認するための設定の読み返しはなく、障害が発生した場合の設定の自動ロールバックもありません。
• デバイスが直接管理ネットワークに接続されていない場合、シスコの通信サーバを介して関連付ける必要があります。
API を使用し、デバイスに到達するための任意のネットワーク トポロジを設定できます。しかし、このリリースではデバイス ネットワーク インターフェイスの 1 つへの直接接続、またはシスコのアクセス サーバ(2511 など)を使用するコンソール アクセスの 2 種類の可能なトポロジだけをサポートしています。
• デバイス障害は、ユーザが指定したポーリング間隔の間だけ検出されます。
これは、標準のイベント ゲートウェイでは、接続が切断されると問題があることが示されるように、イベント ゲートウェイへの接続をルータが管理する必要があるため、SSH インターフェイスは一時的な接続を介して実装されます。そのため、このゲートウェイは、ユーザが指定した間隔ですべてのデバイスにポーリングしてデバイスが応答することを確認する必要があり、障害検出は即時には行われません。
• エージェントが有効化されたデバイスとレガシー デバイスの両方が同じネットワーク上に共存している場合、両方のゲートウェイを同時に実行することを推奨します。
標準のイベント ゲートウェイが、エージェントが有効化されたデバイスと通信し、Intelligent Modular Gateway がレガシー デバイスと通信します。
(注) 両方のゲートウェイがルータを制御しようとすると、予測できない結果が生じる可能性があるため、すでにエージェントが有効化されたルータのデバイス情報データベースにエントリを入力しないでください。
IMGW Device Module Toolkit
IMGW Device Module Toolkit を使用すると、独自のデバイス モジュールを開発し、それらを Cisco Configuration Engine に接続し、デバイスの設定に使用できます。
IMGW Device Module Toolkit の詳細については、「IMGW Device Module Development Toolkit」 を参照してください。
モジュラ ルータのサポート
Cisco Configuration Engine はモジュラ ルータをサポートしています。モジュラ ルータのシャーシには、ラインおよびネットワーク インターフェイス カードを装着するためのスロットが備わっています。
モジュラ ルータの場合、サブデバイス設定オブジェクトと設定テンプレートはネットワーク モジュールごとに定義されます。これらのモジュールのインターフェイスは設定される必要があり、各スロットに基づく変数をインターフェイス番号に使用できます。次に、デバイス設定オブジェクトとテンプレートがメイン デバイスに対して定義されます。固定インターフェイス番号は、メイン デバイス テンプレート内で設定できます。
モジュラ ルータ イベントがイベント バスに発行され、そのバスに接続するアプリケーションからアクセス可能になります。Cisco IOS デバイスは、ハードウェアの検出後にシステム ハードウェア設定を cisco.mgmt.cns.inventory.device-details イベント内で発行します。Cisco Configuration Engine はこのイベントをリッスンし、イベントを取得してデバイスのハードウェア設定を抽出するように設定されます。
暗号化
SSL 方式は、コンフィギュレーション エージェントとコンフィギュレーション サーバとの間の HTTP セッション用、およびイベント ゲートウェイとイベント エージェントとの間の TCP セッション用の暗号化メカニズムとして採用されました。
暗号化を使用するには、Cisco IOS デバイスは、crypto イメージおよび Cisco IOS バージョン 12.2(11)T を実行している必要があります。
デバイス認証
コンフィギュレーション サーバとイベント ゲートウェイに、Certificate Authority(CA; 認証局)サーバが生成した X.509 証明書が提供されます。CA サーバを用意し、証明書の生成と失効を制御することは、ネットワーク管理者の責任です。
設定されるようにするには、Cisco IOS デバイスは CA に認識される必要があります。Cisco IOS デバイス内にクライアント側の証明書はありません。
コンフィギュレーション サーバの場合、Cisco IOS デバイスが証明書を検証したあと、暗号化されたパイプ上でパスワードを送信します。デバイスは Cisco Configuration Engine で認証されるパスワードを使用します。
(注) また、認証はリンクがクリア テキストの場合にも実行されます。
セキュア接続用に設定されたサーバも、セキュアでない(クリア テキスト)セッションを実施できます。パスワード チェックは、暗号化が使用されているかどうかにかかわらず実行されます。
サーバが保護されたあとは、パスワードがない要求を処理できなくなります。保護された環境内のデバイスからのクリア テキスト要求と、保護されていない環境内のデバイスからの要求の違いは識別できません。
Cisco IOS デバイスが証明書を検証したあと、デバイスの Cisco Configuration Engine パスワードがある、暗号化されたパイプ上で DeviceID コントロール メッセージを送信します。event_id:cns_password は、認証 API を使用して検証されます。一致しない場合、SSL セッションは終了し、セキュリティ ログにエントリが作成されます。これにより、認証された Customer Premises Equipment(CPE; 宅内装置)デバイスだけがイベント ゲートウェイに接続し、Integration Bus を使用できることが保障されます。
ブートストラップ パスワード
Cisco Configuration Engine は複数のデバイスがバッチで展開される際に使用するためのブートストラップ パスワードを提供します。この場合、特定のバッチに含まれるすべてのデバイスに、ネットワーク上でのそれぞれの最初の起動時に使用するための、同じ(ブートストラップ)パスワードが与えられます。
このブートストラップ パスワードは、ユーザ インターフェイスの Security Manager(「Security Manager」を参照)にある BootStrap 機能を使用することで、デバイスの別々のバッチに合わせて変更できます。
cns_password の再同期
デバイスのパスワードが破損したために、デバイスとそれに対応する Cisco Configuration Engine ディレクトリ内のパスワード情報との間に不整合が生じた場合、ユーザ インターフェイスの Resync Device 機能を使用してデバイスと Cisco Configuration Engine を再同期できます(「デバイスの再同期」を参照)。
Cisco Configuration Engine の仕組み
Cisco Configuration Engine では、Cisco IOS コンフィギュレーション ファイル(ドキュメント)が動的に作成され、それらのファイルが XML 形式でパッケージ化され、Web/HTTP を使用して配布されます(図 1-2 を参照)。この処理は、pull(get)操作に応じて実行されます。
図 1-2 Configuration Engine の機能図
Cisco IOS デバイスは、ネットワークに最初に接続されるとき( cns config init... )、または加入イベントによって設定の更新が通知された場合( cns config partial... )に get 操作を開始します。
(注) これらとその関連 CLI コマンドに関する詳細については、Cisco IOS コンフィギュレーション ガイドとコマンド リファレンスに関する資料を参照してください。
Cisco IOS デバイスは、デバイス コンフィギュレーション ファイルについての要求を発行します。この要求には、一意の識別子(configID = hostname)が含まれており、ディレクトリ サーバ上のこのデバイスのための関連するコンフィギュレーション ファイル パラメータを検索するために使用されます。図 1-3 に、設定のロード操作のためのプロセス フローを示します。
図 1-3 設定のロード操作プロセス フロー
Web サーバがコンフィギュレーション ファイルの要求を受信すると、Java サーブレットを起動し、埋め込みコードを実行します。これにより、Web サーバに対し、ディレクトリ サーバとファイル システムにアクセスしてこのデバイスとテンプレートに対する設定参照を読み込むように指示されます。コンフィギュレーション サーバは、テンプレート内でこのデバイスに対して有効な値を使用して指定されたすべてのパラメータ値を置き換えることで、指示されたコンフィギュレーション ファイルを準備します。コンフィギュレーション サーバは、Cisco IOS デバイスへの送信のため、このコンフィギュレーション ファイルを Web サーバに転送します。
ルータのコンフィギュレーション エージェントは、このコンフィギュレーション ファイルを Web サーバから受け入れ、XML 解析、構文チェック(省略可能)、およびコンフィギュレーション ファイルのロードを実行します。ルータは設定のロード ステータスをネットワーク モニタリングまたはワークフロー アプリケーションでサブスクライブできるイベントとして報告します。
初期設定のロード
1. Cisco Configuration Engine はテンプレート ファイルを読み取ります。
2. Cisco Configuration Engine はパラメータの置換を行います。
3. Cisco Configuration Engine はデバイス設定を Cisco IOS デバイスに送信します。
4. Cisco IOS デバイスは初期設定のロードを試行します。
5. Cisco IOS デバイスはロード設定ステータス イベントをイベント ゲートウェイに発行します。
モジュラ ルータ
1. モジュラ ルータは、初期設定のためのハードウェア設定を含む HTTP 要求を Cisco Configuration Engine にポストします。
2. Cisco Configuration Engine はデバイスのハードウェア設定を HTTP 要求から読み取り、最新の設定を使用してディレクトリ サーバを更新します。
3. Cisco Configuration Engine はテンプレート ファイルを読み取ります。
4. Cisco Configuration Engine はパラメータの置換を行います。
5. Cisco Configuration Engine はデバイス設定を Cisco IOS デバイスに送信します。
6. モジュラ ルータは初期設定のロードを試行します。
7. モジュラ ルータはロード設定ステータス イベントをイベント ゲートウェイに発行します。
部分的な設定のロード
1. ユーザが Cisco Configuration Engine ユーザ インターフェイスでテンプレートを変更します。
2. このテンプレートの内容は、Cisco Configuration Engine に渡されます。
3. Cisco Configuration Engine はテンプレートをファイル システムに保存します。
4. ユーザがユーザ インターフェイスにあるデバイスの更新ボタンをクリックします。
5. Cisco Configuration Engine は cisco.mgmt.cns.config.load イベントを発行します。
6. Cisco IOS デバイスは cisco.mgmt.cns.config.load イベントを受信し、このイベント要求に応じ、サーバと通信することでそのデバイスの設定を要求します。
7. Cisco Configuration Engine はテンプレート ファイルを読み取ります。
8. Cisco Configuration Engine はデバイス設定を Cisco IOS デバイスに送信します。
9. Cisco IOS デバイスは部分的な設定のロードを試行します。
10. Cisco IOS デバイスはロード設定ステータス イベントをイベント ゲートウェイに発行します。
モジュラ ルータ
1. ユーザが Cisco Configuration Engine ユーザ インターフェイスでテンプレートを変更します。
2. このテンプレートの内容は、Cisco Configuration Engine に渡されます。
3. Cisco Configuration Engine はテンプレートをファイル システムに保存します。
4. ユーザがユーザ インターフェイスにあるデバイスの更新ボタンをクリックします。
5. Cisco Configuration Engine は cisco.mgmt.cns.config.load イベントを発行します。
6. モジュラ ルータは cisco.mgmt.cns.config.load イベントを取得し、このイベント要求に応じ、サーバと通信することでそのルータの設定を要求します。
7. Cisco IOS デバイスは、部分的な設定のためのハードウェア設定を含む HTTP 要求を Cisco Configuration Engine にポストします。
8. Cisco Configuration Engine はデバイスのハードウェア設定を HTTP 要求から読み取り、最新の設定を使用してディレクトリ サーバを更新します。Cisco Configuration Engine はパラメータの置換を行います。
9. Cisco Configuration Engine はテンプレート ファイルを読み取ります。
10. Cisco Configuration Engine はパラメータの置換を行います。
11. Cisco Configuration Engine はデバイス設定をモジュラ ルータに送信します。
12. モジュラ ルータは部分的な設定のロードを試行します。
13. モジュラ ルータはロード設定ステータス イベントをイベント ゲートウェイに発行します。
EventID と ConfigID
Cisco Configuration Engine は次の 2 つの名前空間ドメインに接続します。
• コンフィギュレーション ドメイン
• イベント ドメイン
Cisco Configuration Engine はデバイスのコンフィギュレーション サーバとの通信時、コンフィギュレーション ドメインを使用します。デバイスの Cisco Configuration Engine との通信時、Integration Bus の publish-subscribe 型のメカニズムを使用することで、イベント ドメインを使用します。
デバイスはこれらの名前空間の中で一意に識別される必要があります。ConfigID はコンフィギュレーション ドメイン内のデバイスを一意に識別します。EventID はイベント ドメイン内のデバイスを一意に識別します。
Cisco Configuration Engine は設定をデバイスに提供する目的で Integration Bus(イベント バス)とコンフィギュレーション サーバの両方を使用するため、EventID と ConfigID は設定された各 Cisco IOS デバイスに対して設定される必要があります。
ユーザ インターフェイスを使用して(「デバイスの編集」を参照)デバイス情報を追加または変更する際、各デバイスの EventID と ConfigID の値は同一にする、または別々にすることができます。
ConfigID および EventID の変更の動的な同期
Cisco IOS バージョン 12.2.(11)T には、EventID および ConfigID を変更し、そのデバイスを新しい ID で Cisco Configuration Engine に再接続できる新しい CLI ID コマンドが導入されて強化されています。
共通ログ ファイルの場所
Cisco Configuration Engine では、すべてのログ ファイルは /var/log/CNSCE/<modulename> に保存されます。すべての Cisco Configuration Engine ログについて、この機能には、 /etc/logrotate.d/cnsce ディレクトリにあるカスタムの logrotate スクリプトも組み込まれています。
logrotate は、コンフィギュレーション ファイルに指定した条件に基づいて、指定したログ ファイルを循環させることができるシステム ユーティリティです。各モジュールに対して定義されたコンフィギュレーション ファイルがあります(「logrotate コンフィギュレーション ファイルの例」を参照)。管理者レベルのユーザは、これらのコンフィギュレーション ファイルを使用して任意のモジュールのログをいつでも循環させることができます。
たとえば、 logrotate -f /etc/logrotate.d/cnsce/imgw コマンドを使用すると、すべての IMGW ログが循環し、 /var/log/CNSCE_ROTATED_LOGS ディレクトリにあるすべての既存のログがバックアップされます。このディレクトリは、すべてのモジュールの循環されるすべてのログがダンプされる、共通バックアップ ディレクトリです。
共通ディレクトリがあることで、バックアップ ログのためのパーティション(または領域)を分けて設定できます。
logrotate コンフィギュレーション ファイルの例
#------------------------------------------------------------------
# Copyright (c) 2002, 2003, 2004 by Cisco Systems, Inc.
#------------------------------------------------------------------
olddir /var/log/CNSCE_ROTATED_LOGS
動的なログ レベル更新
このリリースでは、Web サービスを使用してログ レベルをプログラムによって変更できるようになりました。新しい API は setLogLevel(int level, Token token) Admin Web Service で定義されます。
/**
* Changes the logging level of CE components.
*
* @param level, the logging level. Allowed values debug, info, warn, error
*, fatal
* @param token a Token object.
* @return int, the new Log level.
* @throws AdminServiceException if there is an error setting the log level.
* @throws RemoteException if there is an error communicating with the service.
*/
int setLogLevel(int level, Token token)
throws AdminServiceException, RemoteException ;
モニタリング サービス
このリリースでは、Cisco Configuration Engine のさまざまなサービスを監視するためにラッパー モニタリング サービスが提供されています。Cisco Configuration Engine のいずれかのプロセスが停止した場合、モニタリング サービスは終了します。
他のアプリケーションは、依存関係があるすべての Cisco Configuration Engine サービスを監視するのでなく、この単一の Cisco Configuration Engine プロセスを監視できます。障害が発生した場合、再起動スクリプトを起動するなど、適切な処理を実行できます。
他のアプリケーションは、このラッパー モニタリング プロセスがあるかどうかをチェックすることで、すべての Cisco Configuration Engine サービスが活動化されていることを確認できます。プロセスが実行されていない場合、1 つ以上の Cisco Configuration Engine サービスがダウンしていることを示します。
このサービスは、ログ ファイル内のさまざまな Cisco Configuration Engine プロセスの健全性を報告します。障害が発生した場合、このサービスはエラーがあることを報告して終了します。タイム スタンプが各報告に付加されます。
このサービスを開始、停止、またはステータスを確認するためのプロビジョニングがあります。次の Cisco Configuration Engine プロセスが監視されます。
• HTTP/Tomcat
• イベント ゲートウェイ
• IMGW
• Web サービス
• Tibco Rendezvous Daemon
ヘルス チェック ユーティリティ
ラッパー リソースのヘルス チェック ユーティリティは、イベント ゲートウェイおよび Tibco Rendezvous Daemon の健全性を監視するため、リリース 3.5 で提供されています。任意のプロセスが停止した場合、ヘルス チェック ユーティリティがそのプロセスを再起動し、メッセージを /var/log/CNSCE/ce_resource/ce_resource.log ファイルに記録します。このユーティリティ(resource_monitor_daemon)は Cisco Configuration Engine セットアップ中に開始し、Cisco Configuration Engine サーバが停止すると停止します。
ソフトウェア アーキテクチャ
モニタリング サービスは、Cisco Configuration Engine ホスト システムでデーモンとして実行される単一のプロセスです。このデーモンは、さまざまな Cisco Configuration Engine プロセスの状態を定期的な間隔でチェックします。この間隔は設定できます。Cisco Configuration Engine の任意のプロセスが停止した場合、このデーモンは終了します。このデーモンを開始、停止、またはステータスを確認するためのシェル スクリプトが提供されています。アプリケーションはこのシェル スクリプトを使用して Cisco Configuration Engine の健全性をチェックできます。
デーモンの開始および停止スクリプト
MonitorCE シェル スクリプトはこのデーモンを開始および停止します。このスクリプトは、デーモン スクリプトのステータス情報も提供します。統合されるアプリケーションは、このシェル スクリプトを使用して Cisco Configuration Engine サービスの状態を監視します。
このスクリプトは、 chkconfig ユーティリティを使用してローカル OS 上の起動時のスクリプトとして登録されます。この方法で、このスクリプトはホスト システムの再起動後に自動的に起動します。このスクリプトは /etc/rc.d/init.d ディレクトリにあります。
ロギング
このデーモンは、各 Cisco Configuration Engine プロセスの健全性をチェックし、それをログ ファイル内で報告します。このログ ファイルは、 /var/log/CNSCE/ce_health/ce_monitor.log にあります。タイム スタンプが各報告に付加されます。
ログ ファイルの例を次に示します。
07/14/2005-06:53 HTTP/Tomcat is UP in plain-text mode.
07/14/2005-06:53 HTTP/Tomcat is UP in ssl mode.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11011 is UP.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11013 is UP.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11015 is UP.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11017 is UP.
07/14/2005-06:53 Event Gateway (crypto operation) at port 11012 is UP.
07/14/2005-06:53 Event Gateway (crypto operation) at port 11014 is UP.
07/14/2005-06:53 Event Gateway (crypto operation) at port 11016 is UP.
07/14/2005-06:53 IMGW is UP.
07/14/2005-06:53 Cisco-CE Event Bus is UP.
07/14/2005-06:53 CEAdminService web service is UP in plain-text mode.
07/14/2005-06:53 CEConfigService web service is UP in plain-text mode.
07/14/2005-06:53 CEImageService web service is UP in plain-text mode.
07/14/2005-06:53 CEExecService web service is UP in plain-text mode.
HTTP の停止時
HTTP の停止時の例を次に示します。
07/14/2005-06:53 HTTP/Tomcat is DOWN in plain-text mode.
HTTP GET failed on URL http://infystorm5:80/cns/Config
07/14/2005-06:53 HTTP/Tomcat is DOWN in ssl mode.
HTTP GET failed on URL https://infystorm5:444/cns/Config
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11011 is UP.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11013 is UP.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11015 is UP.
07/14/2005-06:53 Event Gateway (plaintext operation) at port 11017 is UP.
07/14/2005-06:53 Event Gateway (crypto operation) at port 11012 is UP.
07/14/2005-06:53 Event Gateway (crypto operation) at port 11014 is UP.
07/14/2005-06:53 Event Gateway (crypto operation) at port 11016 is UP.
07/14/2005-06:53 IMGW is UP.
07/14/2005-06:53 Cisco-CE Event Bus is UP.
07/14/2005-06:53 CEAdminService web service is DOWN in plain-text mode.
HTTP GET failed on URL http://infystorm5:80/cns/services/CEAdminService?wsdl
07/14/2005-06:53 CEConfigService web service is DOWN in plain-text mode.
HTTP GET failed on URL http://infystorm5:80/cns/services/CEConfigService?wsdl
07/14/2005-06:53 CEImageService web service is DOWN in plain-text mode.
HTTP GET failed on URL http://infystorm5:80/cns/services/CEImageService?wsdl
07/14/2005-06:53 CEExecService web service is DOWN in plain-text mode.
HTTP GET failed on URL http://infystorm5:80/cns/services/CEExecService?wsdl
07/14/2005-06:54 Exiting the CE-Health Beep Daemon.
また、コンフィギュレーション ファイル( /etc/logrotate.d/cnsce/ce_health )が上記のログ ファイルの循環のために提供されています。
エンド ユーザ インターフェイス
MonitorCE というスクリプトを使用し、このデーモンを開始、停止、またはステータスを確認できます。このスクリプトは /etc/rc.d/init.d にあります。Cisco Configuration Engine サービスのステータスを確認するには、統合されるアプリケーションは次のコマンドを発行する必要があります。
/etc/rc.d/init.d/MonitorCE status
使用目的
MonitorCE {start|stop|restart|reload|status}
• start :MonitorCE サービスを開始します。MonitorCE サービスがすでに開始されている場合、何も実行されません。
• stop :MonitorCE サービスを停止します。
• restart :サービスをいったん停止してから、再び開始します。
• reload :サービスをいったん停止してから、再び開始します。
• status :サービスが活動状態か停止状態かを確認します。
ユーザ認証
Cisco Configuration Engine は外部認証アプリケーションを使用してユーザを認証できます。Cisco Configuration Engine LDAP サーバを使用してユーザを認証するのでなく、ユーザが Cisco Configuration Engine にログインする場合、Cisco Configuration Engine は認証要求を外部認証アプリケーションに転送します。Cisco Configuration Engine は LDAP ベースの認証をサポートでき、Microsoft Active Directory と統合できます。
Cisco Configuration Engine は Cisco Configuration Engine セットアップ中のユーザの選択に基づき、ユーザを内部および外部の両方で認証できます。
Cisco Configuration Engine セットアップ中、管理者は認証モードを選択できます。Cisco Configuration Engine はリモートの LDAP サーバに対する IP アドレスとユーザ資格情報の入力を要求します。
システムの認証モードを 0= 内部モード、1= 外部モードから選択します。
この例に、外部認証設定の設定方法を示します。
Enter IP Address of external directory server: 10.1.2.3
Enter port number of external directory server: [389]
Enter prefix for user name in external directory server: [cn]
Enter suffix for user name in external directory server: o=myorg,c=us
また、ユーザは許可を有効または無効にできます。
この例に、外部許可設定の設定方法を示します。
Do you want to enable authorization? (y/n) [n] y
Enter UserDN for external directory server: cn=simpleuser,o=myorg,c=us
Enter password for the above user: *****
Re-enter password for the above user: *****
Enter role attribute name in user objectclass which defines the role: description
Enter role attribute value which defines the role of an administrator: administrator
許可
Cisco Configuration Engine はリソースベースの許可をサポートしていません。しかし、Cisco Configuration Engine GUI には管理者レベルとオペレータ レベルが用意されています。ユーザのロールに基づいて、適切な GUI 画面がユーザに対して表示されます。アクセス レベルの詳細については、「アクセスのレベル」を参照してください。
認証および許可のバックアップ
既存の Cisco Configuration Engine ユーザをサポートするには、外部の認証メカニズムのために認証および許可のバックアップがサポートされています。ログインする Cisco Configuration Engine のユーザは、外部アプリケーションに対して認証されます。外部認証に失敗した場合、そのユーザは Cisco Configuration Engine LDAP サーバに対して認証されます。フォールバック サーバは Cisco Configuration Engine(内部または外部)で使用される LDAP ディレクトリになります。ユーザが内部認証を選択した場合、Cisco Configuration Engine LDAP が認証に使用され、フォールバック認証サーバは使用されません。
マルチゾーン システムのセットアップ
Cisco Configuration Engine ソフトウェアのインストールでは、デフォルトではマルチゾーン システムのセットアップは提供されません。マルチゾーン システムのセットアップが必要な場合、システムのセットアップ中にマルチゾーン機能を有効にする必要があります。複数の IP アドレスを Cisco Configuration Engine サーバ上で設定するには、複数の IP アドレスを持つようにサーバのネットワーク パラメータを手動でカスタマイズする必要があります。複数の IP アドレスは、ネットワーク インターフェイス カード上の IP エイリアスを使用して設定できます。詳細については、『Cisco Configuration Engine Installation and Configuration Guide』の第 6 章「Setting Up a Multizone System」を参照してください。