Cisco Prime Provisioning 6.3ユーザ ガイド
サービス要求の管理
サービス要求の管理
発行日;2013/02/25 | 英語版ドキュメント(2012/10/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 15MB) | フィードバック

目次

サービス要求の管理

[Service Request Manager] ウィンドウへのアクセス

サービス要求の詳細の表示

サービス要求リンクの詳細の表示

サービス要求履歴情報の表示

監査レポートのサービス要求の表示

設定監査報告の表示

機能監査レポートの表示

サービス要求コンフィグレットの表示

IOS XR デバイスでのコンフィグレットの表示

設定ファイルの編集

サービス要求のステータスの表示

リンクの表示

ログの表示

コンフィグレットのプレビュー

サービス要求の編集

サービス要求の展開

サービス展開

サービス要求のモニタリング

サービス要求のシミュレートされた展開

サービス要求のデコミッション

サービス要求の削除

サービス要求状態

サービス要求の管理

この章では、[Service Request Manager] ウィンドウを使用して Prime Provisioning のサービス要求を管理する方法について説明します。次の事項について説明します。

「[Service Request Manager] ウィンドウへのアクセス」

「サービス要求の詳細の表示」

「サービス要求のステータスの表示」

「コンフィグレットのプレビュー」

「サービス要求の編集」

「サービス要求の展開」

「サービス要求のデコミッション」

「サービス要求の削除」

「サービス要求状態」

[Service Request Manager] ウィンドウへのアクセス

サービス要求を管理するには、[Operate] > [Service Requests] > [Service Request Manager] を選択します。

図 8-1 は、[Service Request Manager] ウィンドウを示しています。

図 8-1 [Service Request Manager] ウィンドウ

[Service Request Manager] ウィンドウには、このユーザ名のサービス要求の現在のリストが表示されます。このウィンドウには、各サービス要求に関する次の情報が表示されます。

[JobID]:Prime Provisioning によってサービス要求に割り当てられたジョブ番号。

[Data Files]:データ ファイルがサービス要求に関連付けられているかどうかを示します。サービス要求に 1 つ以上のテンプレートが関連付けられている場合、[Data Files] カラムにペーパー クリップ アイコンが表示されます。サービス要求と連携したテンプレートおよびデータ ファイルの使用方法の詳細については、 を参照してください。

[State]:サービス要求の遷移状態。 詳細については、「サービス要求状態」を参照してください。

[Type]:サービス要求のタイプ。 たとえば、[MPLS VPN]、[L2VPN]、[VPLS]、[VRF]、[TE]、または [EVC] などがあります。

[Operation Type]:サービス要求の操作タイプ。 たとえば、[ADD] はこのサービス要求を追加することを意味し、[MODIFY] はサービス要求が以前の状態から変更されたことを意味し、[DELETE] はこのサービス要求をデコミッションすることを意味します。

[Creator]:サービス要求を作成した、または最後に変更したユーザのユーザ名 ID。

[Customer Name]:サービス要求のカスタマー名。

[Policy Name]:このサービス要求に割り当てられたポリシーの名前。

[Last Modified]:サービス要求が作成または最後に変更された日付と時間。

[Description]:サービス要求のオプションのテキスト説明。

[Service Request Manager] ウィンドウの最下部にあるボタンを使用して、サービス要求に対して次の操作を実行できます。

[Create]:Prime Provisioning サービス要求を作成します。 特定のサービスのサービス要求の作成の詳細については、このマニュアルの他の章を参照してください。

[Details]:サービス要求の履歴レポートの表示、サービス要求の監査、およびコンフィグレットの表示を実行します。 詳細については、「サービス要求の詳細の表示」を参照してください。

[Status]:選択されたサービス要求のリンクの表示および利用可能なログへのアクセスを実行します。 詳細については、「サービス要求のステータスの表示」を参照してください。

[Configlet Preview]:特定のサービス要求に対してデバイスに送信されたコンフィグレットをプレビューします。詳細については、「コンフィグレットのプレビュー」を参照してください。

[Edit]:サービス要求を編集します。 詳細については、「サービス要求の編集」を参照してください。

[Deploy]:サービス要求を展開します。 詳細については、「サービス要求の展開」を参照してください。

[Decommission]:サービス要求をデコミッションします。 詳細については、「サービス要求のデコミッション」を参照してください。

[Delete]:サービス要求を削除します。 詳細については、「サービス要求の削除」を参照してください。

サービス要求の詳細の表示

サービス要求の詳細には、サービス要求の展開操作の過程で生成されたサービス要求、履歴、およびコンフィグレットのリンクの終端が含まれます。サービス要求の詳細を使用して、サービス要求の問題やエラーのトラブルシューティングに役立てたり、コンフィグレットのコマンドを確認したりできます。

この項では、履歴、リンク詳細、およびコンフィグレットを含むサービス要求の詳細を表示する方法について説明します。

サービス要求の詳細を表示するには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

ステップ 2 サービス要求を選択し、[Details] をクリックします。

[Service Request Details] ウィンドウが表示されます。

[Service Request Details] ページから、次の項目の詳細な情報を表示できます。

[Details] > [Links]:サービス要求でレポートをリンクします。

[Details] > [History]:サービス要求の履歴のレポート。

[Details] > [Audit]:Prime Provisioning ではサポートされません。

[Details] > [Configlets]:サービス要求に対して Prime Provisioning により生成されたコンフィグレットを表示します。


 

次の項では、サービス要求のリンク、履歴、監査、およびコンフィグレットの詳細について説明します。

サービス要求リンクの詳細の表示

サービス要求リンクの詳細には、リンクの終端、PE 保護インターフェイス、VLAN ID、および CE の存在有無が含まれます。

この情報を表示するには、次のステップを実行します。


ステップ 1 [Service Request Details] ウィンドウで [Links] をクリックします。

[Service Request Link] ウィンドウが表示されます。

ステップ 2 リンクを選択して、[Details] をクリックします。

[Service Request Link Details] ウィンドウが表示されます。

ステップ 3 [OK] をクリックして、[Service Request Link] ウィンドウに戻ります。

ステップ 4 別のリンクを選択して表示するか、[OK] をクリックして [Service Request Details] ウィンドウに戻ります。


 

サービス要求履歴情報の表示

サービス要求に関する履歴情報を表示するには、次のステップを実行します。


ステップ 1 [Service Request Details] ウィンドウで [History] をクリックします。

[Service Request State Change Report] ウィンドウが表示されます。

履歴レポートでは、サービス要求に関する次の情報が示されます。

[Element name]:サービス要求に含まれるデバイス、インターフェイス、およびサブインターフェイス。

[State]:要素が経過した遷移状態。

[Create Time]:このサービス要求に対して要素が作成された時間。

[Report]:このサービス要求の要素に対する Prime Provisioning の操作。

ステップ 2 [OK] をクリックして、[Service Request Details] ウィンドウに戻ります。


 

監査レポートのサービス要求の表示

この項では、Prime Provisioning サービス要求のコンフィギュレーションおよび機能監査レポートを表示する方法について説明します。

設定監査報告の表示

設定監査では、サービス(サービス インテント)のすべてのコマンドが、サービスに参加しているネットワーク要素に含まれているかどうかが確認されます。サービス要求が Prime Provisioning に展開されるたびに、設定監査が行われます。設定監査が行われると、Prime Provisioning はすべての Cisco IOS コマンドが存在し、正しい構文であることを確認します。監査では、展開の過程でエラーが発生しなかったことも確認します。デバイス コンフィギュレーションがサービス リクエストの定義と一致していない場合、監査は警告フラグを付け、サービス リクエストを Failed Audit 状態または Lost 状態に設定します。

設定監査は、プロビジョニングの後に一部のコマンドがネットワーク要素から削除された場合、失敗する可能性があります。これはコマンドが手動で削除されるか、他のサービスのプロビジョニングの一部として削除された場合に発生する可能性があります。設定監査が失敗する可能性がある別の理由としては、Prime Provisioning がコンフィギュレーション ファイルのコマンドを認識できない場合があります。Prime Provisioning のデフォルトの動作では、設定監査中にコンフィギュレーション ファイル内の認識されないコマンドはスキップされます。このような認識されないコマンドは、既存のコンフィギュレーションに存在していたか、コンフィギュレーション ファイルに手動で挿入された可能性があります。認識されないコマンドがコマンド ブロックの先頭にある場合、Prime Provisioning は initial コマンドを省略し、ブロック内でサブコマンドを解析します。これにより、Prime Provisioning はコンフィギュレーション ファイル内の論理フローにエラーがあると想定し、その結果監査は失敗します。

[Prime Provisioning Task Manager] を使用して、設定監査を手動で実行できます。設定監査を手動でスケジュールするためのタスクを作成する方法については、を参照してください。

サービス要求の設定監査レポートを表示するには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

[Service Request Manager] ウィンドウが表示されます。

ステップ 2 設定監査を行うサービス要求を選択します。

ステップ 3 [Details] をクリックします。

[Service Request Details] ウィンドウが表示されます。

ステップ 4 [Audit] ボタンをクリックして、ドロップダウン リストから [Config] を選択します。

[Service Request Audit Report] ウィンドウが表示されます。

ウィンドウには、デバイス名、ロール、および設定監査のステータスに関するメッセージが表示されます。監査に失敗した場合、メッセージ フィールドには失敗した監査の詳細が表示されます。監査失敗メッセージには、見つからないコマンドおよび設定の問題が表示されます。メッセージ フィールドの情報をよく注意して確認します。監査に失敗した場合、すべてのエラーを修正して、サービス要求を再展開する必要があります。

ステップ 5 [OK] をクリックして、[Service Request Details] ウィンドウに戻ります。


 

機能監査レポートの表示

機能監査によって、サービス要求または VPN のリンクが正常に動作していることが検証されます。監査では、PE デバイスの VRF ルート テーブルでのリモート CE へのルートが確認されます。Prime Provisioning は、サービス要求が展開、または強制的に再展開するたびに自動的に監査機能を行います。監査機能は、BGP ピアリングが正しくない、コアでの MPLS 設定が間違っている、またはリモート リンクがダウンしている場合に失敗する可能性があります。

[Prime Provisioning Task Manager] を使用して、機能監査を手動で実行できます。機能監査を手動でスケジュールするためのタスクを作成する方法については、を参照してください。

サービス要求の機能監査レポートを表示するには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

[Service Request Manager] ウィンドウが表示されます。

ステップ 2 機能監査を行うサービス要求を選択します。

ステップ 3 [Details] をクリックします。

[Service Request Details] ウィンドウが表示されます。

ステップ 4 [Audit] ボタンをクリックして、ドロップダウン リストから [Functional] を選択します。

[Service Request Audit Report] ウィンドウが表示されます。

ウィンドウには、デバイス名、ロール、および設定監査のステータスに関するメッセージが表示されます。監査に失敗した場合、メッセージ フィールドには失敗した監査の詳細が表示されます。監査失敗メッセージには、見つからないコマンドおよび設定の問題が表示されます。メッセージ フィールドの情報をよく注意して確認します。監査に失敗した場合、すべてのエラーを修正して、サービス要求を再展開する必要があります。

ステップ 5 [OK] をクリックして、[Service Request Details] ウィンドウに戻ります。


 

サービス要求コンフィグレットの表示

サービス要求を展開したら、Prime Provisioning は Cisco IOS または IOS XR コマンドを生成して、サービス要求に関係するすべてのネットワーク デバイス上で、該当するサービスをオンにします。


) IOS デバイスの場合、コンフィグレットは CLI コマンドとして表示されます。IOS XR デバイスの場合、コンフィグレットは XML または CLI 形式で表示できます。IOS XR デバイスのコンフィグレットの表示については、「IOS XR デバイスでのコンフィグレットの表示」を参照してください。


生成されたコンフィグレットを表示するには、次のステップを実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択して、使用可能なサービス要求を表示します。

ステップ 2 該当するチェックボックスをオンにして、関連付けられたコンフィグレットを表示するサービス要求を選択します。

ステップ 3 [Details] ボタンをクリックします。

[Service Request Details] ウィンドウが表示されます。

ステップ 4 [Configlets] ボタンをクリックします。

[Service Request Configlets] ウィンドウが表示されます。このウィンドウには、コンフィグレットが生成されたデバイスのリストが表示されます。

ステップ 5 デバイスに対して生成されたコンフィグレットを表示するには、デバイスを選択し、[View Configlet] ボタンをクリックします。

[Service Request Configlet] ウィンドウで、コンフィグレットの表示が更新されます。デフォルトでは、直近で生成されたコンフィグレットが表示されます。

 

ステップ 6 必要に応じて、作成時間に基づいてデバイスのコンフィグレットを表示できます。サービス要求に対してコンフィグレットが生成された時間に基づいて特定のコンフィグレットを表示するには、[Create Time] リストで目的の作成時間を選択します。

ステップ 7 コンフィグレットの表示が完了したら、[OK] をクリックします。


 

IOS XR デバイスでのコンフィグレットの表示

デフォルトでは、IOS XR デバイスのサービス要求では、XML 形式でデバイスに送信される設定をログに記録します。したがって、コンフィグレットが IOS XR デバイスに表示される場合は、未加工の XML 形式で表示されます。Prime Provisioning では、コンフィグレットを CLI 形式で表示することもできます。この機能は、DCPL プロパティ DCS/getCommitCLIConfigAfterDownload を True に設定することでイネーブルになります(デフォルト設定)。


) コンフィグレットを CLI 形式で表示するには、DCPL プロパティ DCS/getCommitCLIConfigAfterDownload を True に設定する必要があります。DCPL プロパティを True に設定する場合、CLI コンフィグレットは後続のサービス要求の展開に対してのみ使用できるようになります。これらは、DCPL プロパティが True に設定される前に展開されたコンフィグレットには使用できなくなります。


IOS XR デバイスのコンフィグレットを XML 形式または CLI 形式で表示するには、次のステップを実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択して、使用可能なサービス要求を表示します。

ステップ 2 該当するチェックボックスをオンにして、関連付けられたコンフィグレットを表示するサービス要求を選択します。

ステップ 3 [Details] ボタンをクリックします。

[Service Request Details] ウィンドウが表示されます。

ステップ 4 [Configlets] ボタンをクリックします。

[Service Request Configlets] ウィンドウが表示されます。このウィンドウには、コンフィグレットが生成されたデバイスのリストが表示されます。

ステップ 5 IOS XR デバイスに対して生成されたコンフィグレットを表示するには、IOS XR デバイスを選択し、[View Configlet] ボタンをクリックします。

CLI 形式でコンフィグレットが示された [Service Request Configlet] ウィンドウが表示されます。デフォルトでは、直近で生成されたコンフィグレットが表示されます。

ステップ 6 必要に応じて、作成時間に基づいてデバイスのコンフィグレットを表示できます。サービス要求に対してコンフィグレットが生成された時間に基づいて特定のコンフィグレットを表示するには、[Create Time] リストで目的の作成時間を選択します。

ステップ 7 XML 形式でコンフィグレットを表示するには、[XML Configlet] オプション ボタンをクリックします。

ウィンドウが更新され、XML 形式でコンフィグレットが表示されます。

ステップ 8 異なる形式に切り替えるには、次のオプション ボタンを使用します。

[XML Configlet]:XML 形式でコンフィグレットを表示します。

[CLI Configlet]:CLI 形式でコンフィグレットを表示します。これがデフォルトの選択肢です。

[Both] :XML と CLI の両方の形式で、コンフィグレットを並べて表示します。

ステップ 9 コンフィグレットの表示が完了したら、[OK] をクリックします。


 

設定ファイルの編集

既存のルータ コンフィギュレーション ファイルを表示または編集するには、次の手順を実行します。


) 特に、編集したファイルを実行コンフィギュレーション ファイルにするように選択した場合、コンフィギュレーション ファイルを編集するときには慎重に行ってください。



ステップ 1 [Inventory] > [Physical Inventory] > [Devices] をクリックします。

[Devices Inventory] ウィンドウが表示されます。

ステップ 2 デバイス名の横にあるチェックボックスをオンにして、表示するコンフィギュレーション ファイルのバージョンを選択します。

ステップ 3 [Config] をクリックします。

[Device Configurations] ウィンドウが表示されます。

[Device Configurations] ウィンドウに、選択したデバイスのコンフィギュレーション ファイルの現在のバージョンのリストが表示されます。設定は日時ごとに表示されます。最初にリストされているコンフィギュレーション ファイルが最新バージョンです。

ステップ 4 表示するコンフィギュレーション ファイルのバージョンを選択し、[Edit] をクリックします。

選択されているコンフィギュレーション ファイルの内容が表示されます。

表示されたデバイスのコンフィギュレーション ファイルを表示または編集できます。

ステップ 5 必要に応じて、コンフィギュレーション ファイルを編集します。

ステップ 6 ファイルの編集が完了したら、[Save] をクリックします。


 

サービス要求のステータスの表示

[Service Request Manager] ウィンドウから、次の項で説明されているように、サービス要求のステータス情報を取得できます。

リンクの表示

サービス要求に関連付けられたリンクに関する情報を表示するには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択して、使用可能なサービス要求を表示します。

ステップ 2 該当するチェックボックスをオンにして、関連付けられたリンクを表示するサービス要求を選択します。

ステップ 3 [Status] ボタンをクリックして、[Links] を選択します。

[SR Link] ウィンドウが表示されます。

このウィンドウには、このサービス要求に関連付けられたリンクのリストが表示されます。

ステップ 4 情報の確認が終わったら、[Return to SRs] ボタンをクリックします。


 

ログの表示

サービス要求に関連付けられたログを表示するには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択して、使用可能なサービス要求を表示します。

ステップ 2 該当するチェックボックスをオンにして、関連付けられたリンクを表示するサービス要求を選択します。

ステップ 3 [Status] ボタンをクリックして、[Logs] を選択します。

[Task Logs] ウィンドウが表示されます。

このウィンドウには、タスクの [Runtime Task Name]、[Action]、[Start Time]、[End Time]、および [Status] ごとにタスクが表示されます。このウィンドウを使用して、ログを表示または削除できます。

ステップ 4 ログを表示するには、タスクを表す行にあるチェックボックスをオンにして、[View Log] ボタンをクリックします。

[Task Log] ページが表示されます。

表示するログ レベルのタイプを設定できます。[Log Level] を指定し、[Filter] ボタンをクリックして表示する情報を表示します。

ステップ 5 [Return to Logs] をクリックして、表示する別のログを指定します。

ステップ 6 ログ情報の確認が終わったら、[Close] ボタンをクリックします。


 

コンフィグレットのプレビュー

コンフィグレットのプレビュー操作では、デバイスが実際にプロビジョニングされる前に選択したサービス要求のデバイスに送信されるコンフィグレットをプレビューすることができます。これにより、適用される可能性のあるすべてのテンプレートを含む必要なコンフィグレットがサービス要求で生成されることを確認することができます。

次の警告に注意してください。

コンフィグレットのプレビュー機能は、[In Progress] および [Closed] を除くすべての状態でサービス要求に使用できます。

コンフィグレットのプレビュー機能は、TEM サービス要求ではサポートされていません。

サービス要求のコンフィグレットをプレビューするには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

ステップ 2 [Service Request Manager] ウィンドウで、サービス要求を選択し、[Configlet Preview] をクリックします。

ステップ 3 ドロップダウン リストから、次のいずれかのオプションを選択します。

[For Deploy]:[Deploy] 操作によって生成されるコンフィグレットを生成します。

[For Force Deploy] :[Force Deploy] 操作によって生成されるコンフィグレットを生成します。

これらの選択肢では、利用可能な 2 つの異なる展開オプションを疑似します。これは、展開のタイプが生成されるコンフィグレットに影響を与える可能性があるためです。

[Configlet Preview] ウィンドウが表示されます。ウィンドウには、サービス要求で生成された各デバイスのコンフィグレットが含まれます。


) コンフィグレットはデバイスからアップロードする必要があるため、この操作には少し時間がかかる場合があります。


ステップ 4 コンフィグレットを確認したら [OK] をクリックして、[Service Request Manager] ウィンドウに戻ります。


 

選択されたサービス要求を展開するタスクが作成されると、この機能は [Deploy Service Request] ウィンドウからも利用できます。[Service Request Manager] ウィンドウで 1 つ以上のサービス要求を選択して、[Deploy Service Request] ウィンドウに移動します。次に、[Deploy] > [Deploy] または [Deploy] > [Force Deploy] を選択します。表示される [Deploy Service Request] ウィンドウには、選択されたサービス要求を示すテーブルが含まれます。このテーブルの [Configlet Preview] リンクをクリックして、プレビューのコンフィグレットを表示します。

サービス要求の編集

サービス要求を編集するには、次のステップを実行します。


ステップ 1 [Service Operate] > [Service Requests] > [Service Request Manager] を選択します。

ステップ 2 変更するサービス要求を選択して、[Edit] をクリックします。

[Service Request Editor] ウィンドウが表示されます。


) このウィンドウの正確な名前と内容は、編集されるサービス要求のタイプに応じて異なります。


ステップ 3 エディタで必要な変更を加え、[Save] をクリックします。

対応するサービス要求の状態が [In Progress] に設定され、[Operation Type] が [Modify] に変更された [Service Requests] ウィンドウが再び表示されます。


 

ネットワークに変更をプロビジョニングするには、サービス要求を展開する必要があります。サービス要求を展開する方法については、「サービス要求の展開」を参照してください。展開後、サービス要求の状態が [Deployed] に遷移したら、展開は正常に完了したことを示しています。

サービス要求の展開

ポリシーをネットワーク デバイスに適用するには、サービス要求を展開する必要があります。サービス要求を展開する際、Prime Provisioning はリポジトリ(Prime Provisioning データベース)のデバイス情報と現在のデバイス設定を比較して、コンフィグレットを生成します。

デバイスの変更をネットワーク デバイスに適用するには、サービス要求を展開する必要があります。サービス要求を展開する際、Prime Provisioning はリポジトリ(Prime Provisioning データベース)のデバイス情報と現在のデバイス設定を比較して、コンフィグレットを生成します。

サービス展開

サービス要求をすぐに展開するか、展開をスケジュール設定するには、次のステップを実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

[Service Requests Manager] ウィンドウが表示されます。

ステップ 2 展開するサービス要求のジョブ ID の横にあるチェックボックスをオンにします。

ステップ 3 [Deploy] ドロップダウン リストをクリックします。

次の 2 つの展開オプションがあります。

[Deploy]:サービス要求の状態が [Requested] または [Invalid]の場合、[Deploy] を使用します。

[Force Deploy]:サービス要求の状態が [Deployed] または [Failed Audit] の場合は、[Force Deploy] を使用します。

ステップ 4 [Deploy] を選択します。

[Deploy Service Request] ダイアログボックスが表示され、選択されたサービス要求を展開するスケジュールの設定ができます。

ステップ 5 必要に応じて、このダイアログボックスのフィールドに入力して、サービス要求のスケジュールを設定します。

ステップ 6 スケジュール設定が終わったら、[Save] をクリックします。

[Service Request Manager] ウィンドウに戻ります。

ウィンドウの下部隅にあるポップアップ ウィンドウで [Status] の表示を確認します。サービス要求が正常に完了した場合、[Status] ディスプレイが表示され、[Succeeded] チェックボックスがオンになっています。

ステップ 7 [State] を [Requested] から [Deployed] に更新するには、[Auto Refresh] チェックボックスをオンにします。


) ログを表示して、タスクのステータスとタスクが正常に完了したかどうかを確認します。ログの表示については、「ログの表示」を参照してください。



 

サービス要求のモニタリング

展開中のサービス要求をモニタするには、タスク ログを使用する必要があります。タスク ログでは、サービス要求が失敗した理由のトラブルシューティングを実施したり、サービス要求の詳細を表示したりできます。

サービス要求をモニタするには、次のステップを実行します。


ステップ 1 [Operate] > [Tasks] > [Task Manager] を選択します。

[Task Logs] ウィンドウが表示されます。

ステップ 2 ウィンドウを更新するには、[Find] をクリックします。

Prime Provisioning で実行されているタスクのリストの中で、処理中のタスクが最初に表示されます。

ステップ 3 モニタするタスクを選択して、[Logs] をクリックします。

ステップ 4 モニタする実行中のタスクを選択して、[View Log] をクリックします。

ステップ 5 [Log Level] ドロップダウン リストからログ レベルを選択して、[Filter] をクリックします。

ログ レベルには、[All]、[Severe]、[Warning]、[Info]、[Config]、[Fine]、[Finer]、および [Finest] があります。

ステップ 6 [Return to Logs] をクリックします。

ステップ 7 [Task Logs] ウィンドウで [Close] をクリックします。


 

サービス要求のシミュレートされた展開

サービス要求を展開する場合、[Simulate deploy] オプションを使用することもできます。この機能を使用するには、まず、DCPL プロパティ Services\Common\allowSimulateDeploy を True に設定する必要があります。イネーブルにすると、標準の導入操作によって展開できるすべてのサービス要求(たとえば、[Requested] 状態から [Deployed] 状態にサービス要求を移行する操作)は、シミュレーション モードでも展開することもできます。シミュレートされた展開で、プロビジョニング フローはコンフィグレットがデバイスにダウンロードされる時点まで、通常どおり続行します。たとえば、ライブ設定はデバイスからアップロードされます。ただし、コンフィグレットをダウンロードするときに、Prime Provisioning はエコー モードであるかのように動作します(つまり、設定は実際のデバイスにダウンロードされません)。実際に、これはサービス要求ベースごとにエコー モードです。標準およびシミュレートの両方で、エコー ベースの転送とライブ デバイス対話の組み合わせを使用し、複数の展開操作を同時に実行することができます。

サービス要求の展開をシミュレートするには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

[Service Requests Manager] ウィンドウが表示されます。

ステップ 2 展開するサービス要求のジョブ ID の横にあるチェックボックスをオンにします。

ステップ 3 [Deploy] ドロップダウン リストをクリックします。

DCPL プロパティ Services\Common\allowSimulateDeploy が True に設定されていると想定すると、次の 3 つの展開オプションを使用できます。

Deploy

Force Deploy

Simulate Deploy

ステップ 4 [Simulate Deploy] を選択します。

[Deploy Service Request] ダイアログボックスが表示され、選択されたサービス要求の展開をシミュレーションするスケジュールの設定を行えるようになります。

ステップ 5 必要に応じて、このダイアログボックスのフィールドに入力して、サービス要求のスケジュールを設定します。

ステップ 6 スケジュール設定が終わったら、[Save] をクリックします。

[Service Request Manager] ウィンドウに戻ります。

ウィンドウの下部隅にあるポップアップ ウィンドウで [Status] の表示を確認します。サービス要求が正常に完了した場合、[Status] ディスプレイが表示され、[Succeeded] チェックボックスがオンになっています。

ステップ 7 [State] を [Requested] から [Deployed] に更新するには、[Auto Refresh] チェックボックスをオンにします。


) ログを表示して、タスクのステータスとタスクが正常に完了したかどうかを確認します。ログの表示については、「ログの表示」を参照してください。



 

サービス要求のデコミッション

サービス要求をデコミッションするには、次のステップを実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

ステップ 2 [Service Request Manager] ウィンドウで、デコミッションするサービス要求を選択して [Decommission] をクリックします。

[Confirm Decommission Service Request(s)] ウィンドウが表示されます。

ステップ 3 [OK] をクリックして、サービス要求のデコミッションを確認します。

対応する [Operation Type] が [Delete] に変更された [Service Request Manager] ウィンドウが再び表示されます。

ステップ 4 サービス要求を選択して、[Deploy] > [Deploy] をクリックすることで、サービス要求を展開します。

この作業は、ネットワークに変更をプロビジョニングするために必要です。

ステップ 5 [Deploy Service Request] ウィンドウで、展開を実行する時間(デフォルトは即時)を選択して、[Save] をクリックします。

ステップ 6 展開後、サービス要求の状態が [Closed] に遷移したら、サービス要求のデコミッションが正常に完了したことを示しています。


 

サービス要求の削除

削除操作は、ネットワークに影響を与えずにリポジトリからサービス要求を削除するように設計されています。

サービス要求を削除するには、次の手順を実行します。


ステップ 1 [Operate] > [Service Requests] > [Service Request Manager] を選択します。

ステップ 2 [Service Request Manager] ウィンドウで、デコミッションするサービス要求を選択して [Delete] をクリックします。

ドロップダウン リストから、次のいずれかを選択します。

[Delete]:通常の削除は、[Closed] 状態にあるサービス要求のみに使用できます。


) 通常の削除は、TE Resource、TE Tunnel、TE Protection サービス要求には使用できません。これらのサービスはデコミッションできないためです。これらの 3 つのサービス要求タイプは、強制削除のみ可能です。


[Force Purge]:強制削除では、リポジトリでサービス要求に対する必要な依存関係を検査してから削除が可能になります。したがって、サービス要求を削除できない場合は、エラー メッセージが出されます。

[Delete Service Request(s)] ウィンドウが表示されます。

ステップ 3 [OK] をクリックして、削除または強制削除の操作を確認します。


 

サービス要求状態

サービス要求の遷移状態は、プロビジョニングのプロセスでサービス要求が遷移するさまざまな段階を示しています。たとえば、サービス要求を導入すると、Prime Provisioning はリポジトリ(Prime Provisioning データベース)内のデバイス情報を現在のデバイスのコンフィギュレーションと比較して、コンフィグレットを生成します。コンフィグレットが生成され、デバイスにダウンロードされると、サービス リクエストは [Pending] 状態になります。デバイスが監査されると、サービス要求は [Deployed] 状態に遷移します。

Prime Provisioning サービス要求は、複数のサービス要求が同一のデバイスを設定しようとしている場合を除き、並列に処理されます。この場合、サービス要求はシーケンシャルに処理されます(つまり、デバイスへの書き込みは一度に 1 つだけ実行されます)。

図 8-2 サービス要求状態遷移図は、Prime Provisioning サービス要求の状態間の関係および移行に関する概要図を示しています。

図 8-2 サービス要求状態遷移図

 

表 8-1 「Prime Provisioning サービス要求状態の概要」 は、Prime Provisioning サービス要求の状態ごとの機能を示しています。これらの機能は、アルファベット順に記載されています。

 

表 8-1 Prime Provisioning サービス要求状態の概要

サービス要求タイプ
説明

Broken

(MPLS サービスの場合のみ有効)

ルータは正しく設定されていますが、サービスは利用できません(ケーブルの損傷やレイヤ 2 の問題などが原因)。

このサービスのルーティングおよび転送テーブルがオーディタによって検出され、サービスの目的と一致しない場合、MPLS サービス要求は [Broken] に移行します。

Closed

サービス要求がプロビジョニングまたは監査のプロセスで使用されなくなった場合、そのサービス要求は [Closed] に移行します。サービス要求は、サービス要求の中止の監査が正常に終了した場合のみ、[Closed] 状態に移行します。Prime Provisioning は、サービス要求をさらに監査できるように、データベースからサービス要求を削除しません。特定の管理者の削除操作のみによって、サービス要求を削除できます。

Deployed

サービス要求の目的がルータのコンフィギュレーション ファイルに見つかった場合、サービス要求は [Deployed] に移行します。[Deployed] は、コンフィギュレーション ファイルがルータにダウンロードされ、リクエストの目的がコンフィギュレーション レベルで確認されたことを示します。つまり、Prime Provisioning がコンフィグレットをルータにダウンロードし、サービス要求が監査プロセスを通過したことを示します。

Failed Audit

この状態は、Prime Provisioning はルータにコンフィグレットを正常にダウンロードしたが、サービス要求が監査を通過しなかったことを示しています。そのため、サービスは [Deployed] 状態に移行しませんでした。[Failed Audit] 状態は、[Pending] 状態から開始されます。サービス要求は、正常に導入された後に再び [Failed Audit] 状態になることはありません(サービス要求が再導入された場合を除く)。

Failed Deploy

[Failed Deploy] 状態の原因は、(接続の切断、正しくないパスワードなどによる)初期コンフィギュレーション ファイルのルータからのアップロード失敗、またはコンフィギュレーション更新のルータへのダウンロード失敗のいずれかを DCS がレポートしていることです。

Functional

(MPLS サービスの場合のみ有効)

このサービスの VPN Routing and Forwarding(VRF; VPN ルーティング/転送)テーブルがオーディタによって検出され、サービスの目的と一致する場合、MPLS サービス要求は [Functional] に移行します。この状態は、コンフィギュレーション ファイル監査とルーティング監査が両方とも正常に完了している必要があります。

Invalid

[Invalid] は、サービス要求の情報が正しくないことを示します。リクエストがそれ自体矛盾している場合、または他の既存のネットワークやルータのコンフィギュレーションと不整合である場合(たとえば、ルータ上で使用できるインターフェイスがない場合など)、サービス要求は [Invalid] に移行します。プロビジョニング ドライバは、この要求に提供するコンフィギュレーション アップデートを生成できません。

Lost

オーディタがルータのコンフィギュレーション ファイル内でコンフィギュレーション レベルでの目的の確認を検出できなかった場合、サービス要求は [Lost] に移行します。サービス要求は [Deployed] 状態でしたが、一部または全部のルータのコンフィギュレーション情報が見つかりません。サービス要求が [Deployed] となっていた場合のみ、[Lost] 状態に移行する可能性があります。

Pending

プロビジョニング ドライバが、リクエストが一致していると見なし、このリクエストに必要なコンフィギュレーション更新を生成できた場合、サービス要求は [Pending] に移行します。[Pending] は、サービス要求がコンフィギュレーション更新を生成し、コンフィギュレーション更新がルータに正常にダウンロードされていることを示します。

保留中のサービス要求を新規の要求と見なして、監査が開始されます。サービスが新規にプロビジョニングされ、監査されていない場合は、エラーにはなりません(監査の保留)。ただし、監査が実行され、サービスが保留中のままである場合は、エラー状態です。

Requested

サービスが新規登録され、まだ展開されていない場合は、エラーにはなりません。ただし、[Deploy] が実行され、[Requested] のままである場合は、サービスはエラー状態です。

In Progress

現在の状態に関係なく、展開にサービス要求が要求されるたびに、[In Progress] 状態が表示されます。[In Progress] 状態は、[Requested] および [Deployed] の中間の状態です。複数のサービス要求の展開が同時に要求されるたびに、すべてのサービス要求に対して [In Progress] 状態が表示されます。

Wait Deploy

このサービス要求状態は、Cisco Configuration Engine を使用してコンフィグレットをダウンロードしている場合のみに関連します。[Wait Deploy] は、コンフィグレットは生成されたが、デバイスが現在オンラインでないためダウンロードされていないことを示します。コンフィグレットは、Cisco Configuration Engine が Prime Provisioning にデバイスが稼働中であることを通知するまで、レポジトリに一時保管されます。[Wait Deploy] 状態のコンフィグレットが、デバイスにダウンロードされます。

表 8-2 「Prime Provisioning サービス要求に対するユーザ操作」 は、ユーザ操作と Prime Provisioning サービス要求に与える影響について示しています。

 

表 8-2 Prime Provisioning サービス要求に対するユーザ操作

ユーザ操作
説明

Decommission

このユーザ操作は、サービス要求のすべてのデバイスからサービスを削除します。

Force Deploy

このユーザ操作により、[Closed] を除くすべての状態からサービス要求を [Deploy] できます。これは、状態図の再起動と同等の操作です。サービス要求は、現在の状態からその他のあらゆる状態に移行できます。ただし、[Requested] 状態に移行することはありません。

Force Delete

このユーザ操作は、サービス要求の状態にかかわらず、データベースからサービス要求を削除します。サービス要求をデコミッションする前に Prime Provisioning リポジトリからサービス要求を強制削除([Force Purge])した場合、サービスはネットワーク上で稼働し続けたままになります(具体的には、サービスがプロビジョニングされたデバイス上にコンフィギュレーションは残ったままになります)。ただし、サービスを作成したサービス要求のすべてのレコードは Prime Provisioning から削除されます。

Delete

サービス要求が削除されると、Prime Provisioning データベースからサービス要求が削除されます。